Open棟梁Project - マイクロソフト系技術情報 Wiki

-[[戻る>テスト]]

* 目次 [#nf2b5925]
#contents

* クラス・メソッド単位テスト方式 [#t71b8f53]

**疑問 [#mab2cb9f]
予算に余裕の無い案件の単体テストでは、イベント単位テストが慣例であるが、~
予算が潤沢な案件では、クラス・メソッド単位テストが慣例となっている。

これを真に受けると、

>クラス・メソッド単位テスト方式の方が品質が出る様に見える。

しかし、品質要件や、予算に適合する方式を採用すべきと考える。


**オール・アップ方式 [#wc78fc91]
アポロ計画を成功させたオール・アップ方式をサンプリングして説明する。

***ステップ・バイ・ステップ方式 [#r7dfcf5b]

>ロケット機体を一段ずつ開発し、~
上の方はダミーを使って組み立て・発射テストを繰り返すというステップ・アップ方式

***オール・アップ方式 [#x918beb8]

>すべての段をしっかりした検証をしながら製作して~
ダミーを使わず一気に全体を試験するというオール・アップ方式

***結果 [#c734243b]
アポロ計画では、

-すべての段をダミーを使用しつつ順次検証していくステップ・バイ・ステップ方式から、
-一気に全体を試験するというオール・アップ方式に切り替え、

工期の短縮に成功する。

また、それだけではなく、~

部品１つ１つの信頼性を高めることにも成功している（理由は以下）。

-ステップ・バイ・ステップ方式では、各ステップの準備の~
余計な工数に忙殺され部品の品質作り込みが困難になる。

-オール・アップ方式では、品質の作り込みに十分な時間を割くことができる。~
これにより、部品１つ１つの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]
-品質作り込みでの対応は、
-テストによるバグ抽出での対応より

コスト的に有利である。

これにより、

-イベント単位テスト（オール・アップ方式）の方が
-クラス・メソッド単位テスト（ステップ・バイ・ステップ方式）より

工数・工期を品質作り込みに利用し、品質の向上を図ることができるものと考える。

従って、検査（バグ抽出）は

-バグ抽出を主要な役割と考えずに、
-品質の測定を主要な役割に据える必要がある。
トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS