マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要(疑問)

  • 予算に余裕の無い案件の単体テストでは、イベント単位テストが慣例であるが、
    予算が潤沢な案件では、クラス・メソッド単位テストが慣例となっている。
  • これを真に受けると、

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

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

詳細

テスト方式

サンプリングして説明する。

ステップ・バイ・ステップ方式

  1. ロケット機体を一段ずつ開発し、
  2. 上の方はダミーを使って組み立て
  3. 発射テストを繰り返す

というステップ・バイ・ステップ方式

オール・アップ方式

  1. すべての段をしっかりした検証をしながら製作して
  2. ダミーを使わず一気に全体を試験する

というオール・アップ方式

結果

  • アポロ計画では、

工期の短縮に成功した。

  • また、それだけではなく、
    部品1つ1つの信頼性を高めることにも成功している(理由は以下)。
  • オール・アップ方式では、品質の作り込みに十分な時間を割くことができる。
    これにより、部品1つ1つの99.999%の信頼性を実現した。

参考

  • ステップ・バイ・ステップ方式の作業重複は、
    設計書作成と作業形骸化」で説明した
    以下の観点での工程圧迫とも関連している。
  • フォワードし過ぎ( ≒ 詳細設計書の書き過ぎ)による作業形骸化
  • また、アポロ計画の事例では、
    コミュニケーションの重要性が指摘されている。

カバレッジの観点

オール・アップ方式の利点は、

  • カバレッジ率の観点からも、
  • カバレッジ率が適用できない
    イベント・ドリブン・プログラミングなどの
    プログラミング・パラダイム上からも

説明可能である。

以下、これを説明する。

フレーワーク品質保証の例

フレームワークのテスト(品質保証)は、

  • システムとの一体のテストで、
  • 当該システムで実行され得る
    • カバレッジも網羅され、
    • 問題の摘出&対策が可能であるので、
  • データパターンを考慮したテストが必要な機能を除いて
    フレームワーク単独の単体テストを行わなくてもほぼ問題が出ない。
    (と、前述のオール・アップ方式と同じ結論になる)

イベント・ドリブン・プログラミングの例

  1. イベント・ドリブン・プログラミングの
    プログラミング・パラダイム上で動作する
    カスタム・コントロールなどは、
  2. カバレッジの指標だけでは十分ではなく、
  3. ユーザ、ユーザ・プログラム側から十分に叩かれる必要がある。
    (こちらも、前述のオール・アップ方式と同じ結論になる)

結論

  • 品質作り込みでの対応は、

    「テストによるバグ抽出での対応より」

コスト的に有利である。

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

参考

カバレッジ


Tags: :テスト, :デバッグ, .NET開発


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2020-02-12 (水) 17:04:54 (289d)