ソフトウェア工学 開発管理
テストのレベルと計画
以下はそれぞれ目的が異なる別々のテスト。一緒くたにはできない。
受入れテスト
– 顧客の要求を満たしているかを確かめる
– 要求獲得・分析工程の成果としてテスト計画ができる
システムテスト
– システム全体として要求仕様を満たすかを確かめる
– 要求分析工程の成果としてテスト計画ができる
統合テスト
– モジュールの組合わせが正しく機能するかを確かめる
– モジュール設計工程の成果としてテスト計画ができる
単体テスト
– モジュールが単体で正しく機能するかを確かめる
– アルゴリズム設計工程の成果としてテスト計画ができる
テスト計画書には規格があり、代表的なものにIEEE829-1988がある。（後述）
テストパラダイム
テストを作成するタイミングには2つの考え方がある。
どちらか1つのみではなく、2つを組み合わせて行うことが現実的。
– 古典的テスト計画（スクリプトテストパラダイム）
システムが出来上がってテストが可能になるずっと以前の段階でテストの手順，テストケース，テスト報告のやり方
などを事前に定義する。テストケースを作ること自体が分析の結果や設計の結果にあいまいな点をなくす効果があるため、テストの計画をできるだけ早い段階で行うことを重視する。
ただし、システム仕様（要求定義）の品質に大きく依
存することや、事前に計画を立てるので柔軟性に欠けること、定型かつ大量のテスト実行により，テストのス
キルを低下させる場合があるなどの欠点がある。
– 適応型テスト計画（探索的テストパラダイム）
• 計画できるときに計画できるところまでを計画
し，計画できるようになるまでは計画しない。
システムの適切な振舞いに対する仮説を作成
→仮説を反証するようなテストをいくつか設計
→それらのテストケースを実行し結果を観察
→仮説に反する結果を評価
→仮説が証明されるか反証されるまで上を繰り返す
これらをテストのみに割り当てられた時間枠（1～２時間）内で集中的に行う。どのテストをどういう順番でテストすべきかが分かっている場合にはかえって非効率になる。
ただし、事前に計画が不在なことから，欠陥を予防する効果は期待できないという欠点がある。
信頼性のメトリクス
信頼度成長曲線
テスト実行週間と発見されたバグの数を記録していくことで、信頼度成長曲線を描くことができ、バグの数が予測できるのでテスト工程をマネージメントするのに役立つ。
信頼性のメトリクスを用いて検証の結果達成される信頼性を測る。測る際に誤差や属人性が少なく、開発対象の品質を代表するものが好ましい。完璧なメトリクスは存在しないので、実際には、いくつかのメトリクスを組み合わせて判断をする。
バグメトリクス
・発見されるバグ（欠陥）の数
– 時間経過に従って累積
– ある期間毎の発見数
– 重要度別に分類
– モジュール別に分類（ＬＯＣごとに正規化）
など
・バグの修正に必要な時間
– 平均バグ修正時間
コードカバレッジメトリクス
・文カバレッジ（Ｃ０），分岐カバレッジ（Ｃ１）などの基準に従ってどれだけ網羅的にテストされているか
– 時系列に沿って計測
– 単調増加ではない場合もある
・特定のテストケース集合のどれくらいの割合を通過したか
ソースコードメトリクス
・行数（ＬＯＣ）とそれに関わるメトリクス
– バグ密度（千行あたりいくつのバグが潜む？）
バグの数／ＫＬＯＣ
複雑度メトリクス
複雑なプログラムほどバグが出やすいため、複雑度を図り、テストを慎重に行う目安になる。
・サイクロマチック数
– １～１０：シンプルなプログラム，バグのリスクはほとんどない
– １１～２０：多少複雑で，バグのリスクが存在
– ２１～５０：複雑，バグのリスクが高い
– ５１～：管理・テストは不可能，バグのリスクが著しく高い
テストの終了判定
どこまでテストすればよいのか？テストにはキリがない。テストする前にテストの終了基準を設ける。
• カバレッジの目標値
• 欠陥検出率
• 限界コスト
• チームの合意
• その他の要因
テスト文章
テスト文書の標準規格（IEEE829-1988）より、ソフトウェアテストで利用可能な八つの文書
– テスト計画書 テストのレベルごとに作られる。
– テスト設計仕様書 テスト項目ごとに作られ、テストの集合が作られる。
– テストケース仕様書 テスト項目をテストケースにする。
– テスト手順書
– テスト項目移管レポート
– テストログ タイムスタンプ、誰が何をやって合格したか？
– テスト不具合レポート テストに合格しなかった場合
– テストサマリレポート テスト実行割合、合格割合など
これらの文章はテスト管理ソフトで管理されることが多い。バグトラッキング機能などと連携し文章作成の支援機能がある。
