Skip to content

MS_UnitAndIntegrationTestMethods

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

単体・結合テスト方式

概要（疑問）

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

  • これを真に受けると、

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

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

詳細

テスト方式

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

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

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

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

オール・アップ方式

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

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

結果

  • アポロ計画では、

    工期の短縮に成功した。

  • また、それだけではなく、
    部品１つ１つの信頼性を高めることにも成功している（理由は以下）。

参考

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

カバレッジの観点

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

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

説明可能である。

以下、これを説明する。

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

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

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

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

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

結論

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

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

    コスト的に有利である。

  • これにより、

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

参考

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

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

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

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally