◆テストの本質
・バグ
* ソフトウェアは人間が記述するものである。
* 人間には以下のような特性がある。
- 間違える/ 忘れやすい/ 曖昧である
- 嘘をつく/ 勝手に脚色する/ 手を抜く
- 常に変化する/ 効率が不安定
従って、ソフトウェアには期待された動きとは異なる動作としての
「バグ」が必ず「作り込まれる」。
* 設計や製造で作り込まれたバグは、レビューやテストによって
検出され、デバッグされねばならない。
・テスト
* 実際にソフトウェアを実行させ、仕様とは異なる動作をする、すなわち
バグが確かに存在することを示す作業。
* 仕様が曖昧であればテストも曖昧になる。
・デバッグ
* 再現可能なバグは、二分法などにより比較的容易に原因究明可能である。
・証明
* ある動作を多数回行っても、バグが無いことを保証することはできない。
* プログラムが可能とする全ての実行に対して、仕様に反する動作すなわち
バグがない事を示すことにより、バグが無いことが証明できる。
しかし、これは現実的には（不可能ではないが）極めて困難である。
・検証
* 要求に対してソフトウェアが整合性を保持しているかを確認する作業で、
設計に対してはレビュー、プログラムに対してはテストが相当する。
・品質保証 Quality Assurance
* ソフトウェアが要求品質を十分に満たしていることを保証するために、
開発者が行う体系的活動を指す。（バグが無いことを請け合う、という
意味ではない。）
* 品質保証は大きくは以下の活動要素から成る。
(1)要求品質を正確に掴み、仕様化（明文化）する。
(2)要求品質、利用時品質を十分に反映するように、ソフトウェアの品質が
仕様に適合するように製造工程を管理するとともに、
検証活動を通して保証を行う。
(3)ソフトウェアのライフサイクルを通して、一定の品質条件を満たす。
即ち、納品後も性能や信頼性を含む品質が維持される保証やサービスを
提供する。
・ソフトウェアの品質
* 機能性
* 信頼性
* 使用性
* 効率性
* 保守性
* 移植性
・単体テスト
* ロジック確認テスト
* 条件分岐確認テスト
* 代表値テスト
* 上位インタフェース確認テスト (ドライバによるインタフェース確認)
* 下位インタフェース確認テスト (スタブによるインタフェース確認)
・結合テスト
* モジュール間インタフェース確認テスト
* 外部リンク動作確認テスト
* バリエーションテスト（入力・出力・設定）
* 起動・終了動作テスト
・総合テスト（システムテスト）
* 疎通確認テスト
* 導入確認テスト
* 障害時動作テスト、障害時復旧手順確認テスト
* 正常時運用手順確認テスト
* 負荷テスト、ラッシュテスト、ロングランテスト
* パフォーマンス測定、リソース測定
* 他システム連携テスト
・運用テスト
* 本番移行基準確認
* 移行テスト
* 保守性テスト
* 運用効率測定、業務効率測定
* ユーザビリティテスト
・ソフトウェアの品質
・テスト計画
・テストケース
* ホワイトボックステストにおいて、条件判定の両方を実行させる
テストデータの１組を「１種類のテストケース」と数える。
・テストデータ
・ブラックボックステスト black-box text
* 同値分割
一般的には機能仕様の入力条件から、
- 条件を満足する範囲＝「有効同値クラス」
- 条件を満足しない範囲＝「無効同値クラス」
を識別して、テストケースを作成していく。
* 限界値分析
* 原因・結果グラフ
* ＣＦＤテスト
* 実験計画法
・ホワイトボックステスト white-box test (制御網羅法)
* 命令網羅／節点網羅 statement coverage (C0 coverage)
プログラムの条件文以外の全命令の何割が実行されたかを計測する
網羅率＝実行済みステートメント ÷ 全ステートメント数
* 判定条件網羅／分岐網羅 edge coverage (C1 coverage)
判定状況の個々について真・偽を実行させることを基準とする。
網羅率＝通過した枝 ÷ 全枝数
※フローチャートを描いてみて、先に飛んだり戻ったりする
枝の全てを通過したことを確認する必要があり、
単に命令を１度通ったことを確認する命令網羅より
条件は格段に厳しい。
* 条件網羅 condition coverage
全ての判定条件で、真・偽の全ての組合せを実行させることを
基準とする。
※例えば if (Ｐ or Ｑ) という条件文があった場合には、
(Ｐ,Ｑ)＝{(真,真),(真,偽),(偽,真),(偽,偽)}
の４つのパターン全てを検証する必要がある。
* 複数条件網羅
各条件の起りうる真・偽の組み合わせと、
それに伴う全ての分岐を網羅するテストケースの実施を基準とする。
網羅基準の中では最も厳しい基準。
※この網羅条件を「条件網羅」と呼んで C2 coverage と
定義することもある。
* 経路組み合わせ網羅 path coverage
判定条件間の依存関係（条件の組合せ）まで考慮し、
複数の命令や条件をまたがる実行経路を洗い出し、
それらの経路（パス）をテストケースの実施基準とする。
網羅率＝実行したパス÷全パス数
(注)ある分岐の両方を試すテストデータのペアを、
一つのテストケースと数える。
一般に、条件判定がｎ箇所ある場合、
テストデータは２ｎ個必要である。
テストケースはｎ組必要である。
・結合テスト integration test
モジュールインタフェースに関するエラーを検出するテスト、
* ボトムアップテスト bottom-up test
* トップダウンテスト top-down test
* 混合テスト mixed integration
* ビッグバンテスト big-bang test
