Open棟梁Project - マイクロソフト系技術情報 Wiki -[[戻る>テスト]] * 目次 [#nf2b5925] #contents * クラス・メソッド単位テスト方式 [#t71b8f53] **疑問 [#mab2cb9f] 予算に余裕の無い案件の単体テストでは、イベント単位テストが慣例であるが、~ 予算が潤沢な案件では、クラス・メソッド単位テストが慣例となっている。 これを真に受けると、 >クラス・メソッド単位テスト方式の方が品質が出る様に見える。 しかし、品質要件や、予算に適合する方式を採用すべきと考える。 **オール・アップ方式 [#wc78fc91] アポロ計画を成功させたオール・アップ方式をサンプリングして説明する。 ***ステップ・バイ・ステップ方式 [#r7dfcf5b] >ロケット機体を一段ずつ開発し、~ 上の方はダミーを使って組み立て・発射テストを繰り返すというステップ・アップ方式 ***オール・アップ方式 [#x918beb8] >すべての段をしっかりした検証をしながら製作して~ ダミーを使わず一気に全体を試験するというオール・アップ方式 ***結果 [#c734243b] アポロ計画では、 -すべての段をダミーを使用しつつ順次検証していくステップ・バイ・ステップ方式から、 -一気に全体を試験するというオール・アップ方式に切り替え、 工期の短縮に成功する。 また、それだけではなく、~ 部品1つ1つの信頼性を高めることにも成功している(理由は以下)。 -ステップ・バイ・ステップ方式では、各ステップの準備の~ 余計な工数に忙殺され部品の品質作り込みが困難になる。 -オール・アップ方式では、品質の作り込みに十分な時間を割くことができる。~ これにより、部品1つ1つの99.999%の信頼性を実現した。 ***参考 [#uea4d963] -ステップ・バイ・ステップ方式の作業重複は、~ 「[[設計書作成と作業形骸化]]」で説明した以下の観点での工程圧迫と似ている。 --フォワードし過ぎ( ≒ 詳細設計書の書き過ぎ)による作業形骸化 -また、アポロ計画の事例では、コミュニケーションの重要性が指摘されている。 --大きな組織が動き出す知恵 - PageTAKA's blog~ http://pagetaka.hatenablog.com/entry/2013/01/17/%E5%A4%A7%E3%81%8D%E3%81%AA%E7%B5%84%E7%B9%94%E3%81%8C%E5%8B%95%E3%81%8D%E5%87%BA%E3%81%99%E7%9F%A5%E6%81%B5 **カバレージの観点 [#b59f5147] オール・アップ方式の利点は、 -カバレージ率の観点からも、 -カバレージ率が適用できないプログラミング・パラダイム上からも 説明可能である。 以下、これを説明する。 カバレージ率(コード網羅率) -コード網羅率 - Wikipedia~ http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%BC%E3%83%89%E7%B6%B2%E7%BE%85%E7%8E%87 ***フレーワーク品質保証の例 [#ub7c5828] -フレームワークのテスト(品質保証)は、 -システムとの一体のテスト(品質保証)で、 当該システムで実行され得る -カバレッジも網羅され、 -問題の摘出&対策が可能であるので、 データパターンを考慮したテストが必要な機能を除いて~ フレームワーク単独の単体テストを行わなくてもほぼ問題が出ない。~ (と、前述のオール・アップ方式と同じ結論になる) ***イベント・ドリブン・プログラミングの例 [#mbd0fcfc] また、イベント・ドリブン・プログラミングの~ プログラミング・パラダイム上で動作するカスタムコントロールなどは、 カバレージの指標だけでは十分ではなく、~ システムによって(ユーザ、ユーザ・プログラムが側から)十分に叩かれる必要がある。 (こちらも、前述のオール・アップ方式と同じ結論になる) **結論 [#g8a0a8e7] -品質作り込みでの対応は、 -テストによるバグ抽出での対応より コスト的に有利である。 これにより、 -イベント単位テスト(オール・アップ方式)の方が -クラス・メソッド単位テスト(ステップ・バイ・ステップ方式)より 工数・工期を品質作り込みに利用し、品質の向上を図ることができるものと考える。