- 追加された行はこの色です。
- 削除された行はこの色です。
Open棟梁Project - マイクロソフト系技術情報 Wiki
「[[マイクロソフト系技術情報 Wiki>http://techinfoofmicrosofttech.osscons.jp/]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。
-[[戻る>テスト]]
* 目次 [#nf2b5925]
#contents
* クラス・メソッド単位テスト方式 [#t71b8f53]
*概要(疑問) [#mab2cb9f]
-予算に余裕の無い案件の単体テストでは、イベント単位テストが慣例であるが、~
予算が潤沢な案件では、クラス・メソッド単位テストが慣例となっている。
**疑問 [#mab2cb9f]
予算に余裕の無い産業系案件の単体テストでは、イベント単位テストが慣例であるが、~
予算が潤沢な金融系の案件では、クラス・メソッド単位テストが慣例となっている。
これを真に受けると、
-これを真に受けると、
>クラス・メソッド単位テスト方式の方が品質が出る様に見える。
しかし、実際は逆に問題の方が多いと考えている。
>しかし、品質要件や、予算に適合する方式を採用すべきと考える。
これに合致する、事例をサンプリングする。
*詳細 [#e3242c65]
**オール・アップ方式 [#wc78fc91]
アポロ計画を成功させたオール・アップ方式をサンプリングして説明する。
**テスト方式 [#wc78fc91]
-一般的だった、[[ステップ・バイ・ステップ方式>#r7dfcf5b]]と
-アポロ計画を成功させた[[オール・アップ方式>#x918beb8]]を
サンプリングして説明する。
***ステップ・バイ・ステップ方式 [#r7dfcf5b]
>ロケット機体を一段ずつ開発し、~
上の方はダミーを使って組み立て・発射テストを繰り返すというステップ・アップ方式
+ロケット機体を一段ずつ開発し、
+上の方はダミーを使って組み立て
+発射テストを繰り返す
というステップ・バイ・ステップ方式
***オール・アップ方式 [#x918beb8]
>すべての段をしっかりした検証をしながら製作して~
ダミーを使わず一気に全体を試験するというオール・アップ方式
+すべての段をしっかりした検証をしながら製作して
+ダミーを使わず一気に全体を試験する
というオール・アップ方式
***結果 [#c734243b]
アポロ計画では、
-アポロ計画では、
-すべての段をダミーを使用しつつ順次検証していくステップ・バイ・ステップ方式から、
-一気に全体を試験するというオール・アップ方式に切り替え、
--すべての段をダミーを使用しつつ~
順次検証していく[[ステップ・バイ・ステップ方式>#r7dfcf5b]]から、
--一気に全体を試験するという[[オール・アップ方式>#x918beb8]]に切り替え、
工期の短縮に成功する。
>工期の短縮に成功した。
また、それだけではなく、~
-また、それだけではなく、~
部品1つ1つの信頼性を高めることにも成功している(理由は以下)。
-ステップ・バイ・ステップ方式では、各ステップの準備の~
--[[ステップ・バイ・ステップ方式>#r7dfcf5b]]では、各ステップの準備の~
余計な工数に忙殺され部品の品質作り込みが困難になる。
-オール・アップ方式では、品質の作り込みに十分な時間を割くことができる。~
--[[オール・アップ方式>#x918beb8]]では、品質の作り込みに十分な時間を割くことができる。~
これにより、部品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]
**[[カバレッジ>#e04fc6a4]]の観点 [#b59f5147]
オール・アップ方式の利点は、
-カバレージ率の観点からも、
-カバレージ率が適用できないプログラミング・パラダイム上からも
-[[カバレッジ>#e04fc6a4]]率の観点からも、
-[[カバレッジ>#e04fc6a4]]率が適用できない~
イベント・ドリブン・プログラミングなどの~
プログラミング・パラダイム上からも
説明可能である。
以下、これを説明する。
カバレージ率(コード網羅率)
-コード網羅率 - 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]
-フレームワークのテスト(品質保証)は、
-システムとの一体のテスト(品質保証)で、
フレームワークのテスト(品質保証)は、
当該システムで実行され得る
-システムとの一体のテストで、
-カバレッジも網羅され、
-問題の摘出&対策が可能であるので、
-当該システムで実行され得る
--[[カバレッジ>#e04fc6a4]]も網羅され、
--問題の摘出&対策が可能であるので、
データパターンを考慮したテストが必要な機能を除いて~
-データパターンを考慮したテストが必要な機能を除いて~
フレームワーク単独の単体テストを行わなくてもほぼ問題が出ない。~
(と、前述の[[オール・アップ方式>#x918beb8]]と同じ結論になる)
(と、前述のオール・アップ方式と同じ結論になる)
***イベント・ドリブン・プログラミングの例 [#mbd0fcfc]
また、イベント・ドリブン・プログラミングの~
プログラミング・パラダイム上で動作するカスタムコントロールなどは、
+イベント・ドリブン・プログラミングの~
プログラミング・パラダイム上で動作する~
[[カスタム・コントロール>.NETコントロールのカスタマイズ方法]]などは、
+[[カバレッジ>#e04fc6a4]]の指標だけでは十分ではなく、~
+ユーザ、ユーザ・プログラム側から十分に叩かれる必要がある。~
(こちらも、前述の[[オール・アップ方式>#x918beb8]]と同じ結論になる)
カバレージの指標だけでは十分ではなく、~
システムによって(ユーザ、ユーザ・プログラムが側から)~
十分に叩かれる必要がある。~
(こちらも、前述のオール・アップ方式と同じ結論になる)
**結論 [#g8a0a8e7]
-品質作り込みでの対応は、
-テストによるバグ抽出での対応より
>「テストによるバグ抽出での対応より」
コスト的に有利である。
>コスト的に有利である。
これにより、
-これにより、
--クラス・メソッド単位テスト([[ステップ・バイ・ステップ方式>#r7dfcf5b]])より
--イベント単位テスト([[オール・アップ方式>#x918beb8]])の方が
-イベント単位テスト(オール・アップ方式)の方が
-クラス・メソッド単位テスト(ステップ・バイ・ステップ方式)より
>工数・工期を品質作り込みに利用し、品質の向上を図ることができるものと考える。
工数・工期を品質作り込みに利用し、品質の向上を図ることができるものと考える。
*参考 [#vf863bde]
従って、検査(バグ抽出)は
**[[カバレッジ>https://dotnetdevelopmentinfrastructure.osscons.jp/index.php?%E9%AB%98%E5%BA%A6%E5%8D%88%E5%89%8D%E2%85%A0%20-%20%E5%BF%9C%E7%94%A8%E6%83%85%E5%A0%B1%E3%81%AE%E9%81%8E%E5%8E%BB%E5%95%8F%EF%BC%88%EF%BC%93%E5%B9%B4%E5%88%86%EF%BC%89#jd86cf07]] [#e04fc6a4]
-バグ抽出を主要な役割と考えずに、
-品質の測定を主要な役割に据える必要がある。
----
Tags: [[:テスト]], [[:デバッグ]], [[.NET開発]]