テストと検証の設計

テストと検証の設計とは、ソフトウェアが仕様どおりに動くことを確かめるために、検証の方式、網羅の基準、静的解析や形式手法といった手段を目的に応じて選ぶことである。プログラムを実行して確かめるテストと、実行せずに確かめる検証を区別し、それぞれの根拠と限界を理解することが重要である。

静的解析と形式手法による検証

静的解析は、プログラムを実行せずにソースコードを解析して問題を見つける手法である。ソースコードを静的解析するOSSのツールは、バグ、重複コード、脆弱性につながるコードを自動で検出できる 。アジャイル開発で品質を継続的に高める場面では、こうした検出ツールの導入が適切な判断となる。一方、変更履歴を管理するバージョン管理システムや、ビルドとテストを自動化するツールは、コード品質を解析する専用ツールではない 。

形式手法は、厳密な意味を持つ言語で仕様を記述し、ソフトウェアが満たすべき性質と仕様が整合するかを論理的に検証する方法である 。仕様を読んで進行役や記録役を置いて成果物を確認するレビューとは異なり、論理による裏付けを得る点に特徴がある。

網羅の基準と最小のテストケース

網羅の基準は、テストがプログラムの構造のどこまでを通ったかを示す尺度である。判定条件網羅（分岐網羅）では、各判定の真と偽の両方の分岐を少なくとも一度ずつ通す必要がある。二つの判定を含む流れ図では、両判定の真と偽をそれぞれ通す二つのテストケースの組合せが最少となった 。これより少ない組合せでは、どちらかの判定で片方の分岐が抜けるため、網羅とは認められない。

複合条件を含む判定でも、判定全体として真になる場合と偽になる場合の両方を通すことが判定条件網羅の基本である 。判定条件網羅では個々の条件の組合せまで網羅する必要はない点に注意する。

命令網羅は、全ての命令を少なくとも一度実行すればよいという基準である。判定の分岐の構造と、先行する命令の結果が後続の判定に影響するかによって必要な件数が変わるため、流れ図を見て件数を見積もる必要がある。問題文の前提により各判定結果が先行命令の影響を受けない場合、先頭と末尾の判定にそれぞれ3個の命令があり、1件のテストで各判定から通る命令は1個ずつであるため、最少は3件となった 。