テストレベル
4種類のテストレベルについて。
この各レベルのテストは上から順番に行うと決まっているものでなく、いろいろな要素により前後もするし、テスト対象を変えて何度も行う場合もある。
統合テスト
インタフェースに関するテスト。何のインタフェースをテストするかによりテスト対象や実施時期が異なる。
統合テストで行うのは、あくまで統合部分(インタフェース)のテストのみ。テスト対象の機能面については統合テストの前に終えておく。
システム統合テスト
他システムとの相互処理のテスト。システムテストより後に実施する。
システムテスト
システムやソフトウェアプロダクト全体のテスト。テスト環境は最終的なターゲットや運用環境、使用環境と極力同じにしないといけない。
受け入れテスト
システム全体、システムの一部、非機能的な特性が正しいことを確認することが目的。欠陥を検出することが目的ではない。
受け入れテストには以下の形がある。
運用受け入れテスト
システム管理者
による受け入れテスト。
ユーザー受け入れテスト
システムがビジネスで使えるかをユーザーがテストするもの。
契約による受け入れテスト
契約書に記述した判定条件を満たしているかを確認するテスト。
規定による受け入れテスト
法律や安全基準などに合致しているかを確認するテスト。
アルファテスト
社内ユーザーで実施するテスト。
ベータテスト
社外ユーザーによるテスト。
テストに関する用語
テストアイテム(test item)
テストを実施する個々の要素。テストの実施対象のこと。
テスト条件
コンポーネントやシステムのアイテムやイベントで、テストケースにより検証できるもの。例えば機能、トランザクション、品質特性、構造要素など。
テスト条件は、テストの目的に応じてどのようにテストを割り付けるのかを決めるもの。または、テストアイテムをどのように区切るか。
テストベース(test base)
テストの元となるすべての開発関連資料であり、テストの根拠(basis)となるもの。
ソフトウェア要求仕様書や設計書など、テストのスコープによりさまざまなものがある。
また、ドキュメントとして明文化されたもの以外にも、会議の議事録、メール、メモ書き等の正規のドキュメントではないものも含まれる。
テストケース(test case)
特定の目的やテスト条件のために開発される、入力値、実行前の状態、予想結果、実行後の状態のセット。
テストスイート(test suite)/テストセット(test set)
関連するテストケースのセット。あるテストの事後条件が次のテストの事前条件となるような複数のテストケースや、同一の目的である複数のテストケースを1つのテストセットにまとめる。これにより(無駄な準備が省かれるため)テストの実行効率が上がったり、プログラムに変更があった場合に、どのテストケースを再テストすればよいかが分かりやすくなる。
テストプロシージャ(test procedure)/テスト手順
テストケースを実行するための操作手順。これにはテストケースの事前手順を整えるまでの手順も含まれる。1つのテストケースに対して複数のテストプロシージャを参照するように記述することも可能。事前条件を1つのテストプロシージャに記載し、各テストケースで、そのテストプロシージャを参照したりする。
テストスクリプト。手動テストスクリプト。
テストベッド(test bed)/テスト環境(test environment)
テストの実行に必要なハードウェア、計装、シュミレータ、ソフトウェアツール、その他の支援要素を含む環境。
テストハーネス(test harness)
テスト実行に必要なスタブやドライバからなる、テスト環境。
ドライバ：テストアイテムを呼び出す、上位コンポーネントの代わりとなるコンポーネントやテストツール。
スタブ：テストアイテムが呼び出す他のコンポーネントの代わりをするコンポーネント。
テストウェア(testware)
テストプロセスを通じて作成される、テストの計画、設計、実行に不可欠なもの。
上記のもろもろのドキュメントを含め、テストに関するあらゆるものを指す。
ソフトウェアの欠陥の原因
まとめ
人間はエラーを起こす。エラーがコード、ソフトウェア、ドキュメントの欠陥になる。コードの欠陥が実行されると故障が起きる。
オペレータがソフトウェアを操作したら想定と違う動作(インシデント)を発見した。そのインシデントを調査した結果、故障だと判明。故障の原因はとあるコードのバグによるものだった。そのバグはAさんの誤りによりコードに埋め込まれていた。
エラー/誤り
間違った結果を生み出す人間の行為。
エラーがコード、ソフトウェア、システム、ドキュメントの欠陥となる。
バグ/欠陥/フォールト(fault)
要求された機能をコンポーネントまたはシステムに果たせなくする、コンポーネントまたはシステムの中の不備。
エラーによってプログラム中にフォールトを埋め込んで実装してしまう。
故障(failure)
コンポーネントやシステムが、期待した機能、サービス、結果を提供できないこと。
すべての欠陥が故障となるわけではない、欠陥の含まれたコードが実行されなければ、故障にはならない。
インシデント
ソフトウェア・システムを実際に使うユーザーやテスト担当者が期待する動きと、実際の動きが一致しない事象。
インシデントと故障は同じではない。インシデントを調査した結果、故障ではなくユーザーのオペミスという場合もありえる。
テスト設計技法のカテゴリ
仕様ベース
機能仕様や非機能仕様を分析することでテストケースを設計。
＝ブラックボックステスト設計技法
構造ベース
ソフトウェアの内部構造を検査する設計技法
＝ホワイトボックステスト設計技法
経験ベース
開発担当者のスキルや経験、ユーザーの利用実態に関する情報、勘などをもとに設計する技法。
探索的テストなど。
作業者のスキルに依存してしまい、スキルの低い作業者が行うとモンキーテストになりやすい。
コードカバレッジ技法
コードの構造をベースとした技法(コードカバレッジ技法)について。カタカナが多すぎてどれがどれだか分からなくなってた。
囲み内はJSTQBの用語集からの抜粋。
条件カバレッジ⊇デシジョンカバレッジ＝ブランチカバレッジ⊇ステートメントカバレッジ
デシジョンカバレッジ(decision coverage)
テストスイートによって用いられた判定結果のパーセンテージ。
ブランチカバレッジが「分岐」を主眼に考えるのに対して、デシジョンカバレッジは「判定条件の結果」を主眼に考える。結局のところはほぼ同じ意味と考えて大丈夫。
条件カバレッジ(condition coverage)
テストスイートが実施した条件のパーセンテージ。 条件カバレッジを100％にするには、各判定文のすべての単一条件に対して、真と偽をテストする必要がある。
複数の条件文が、AND/ORで結合されている場合に、個々の条件文の真/偽の結果を考慮した上で試験項目がどれだけカバーしているかの割合。デシジョンカバレッジ/ブランチカバレッジは個々の条件文を考慮しない。
判定条件カバレッジ(decision condition coverage)
テストスイートが実施した条件と判定のパーセンテージ
100％の判定条件カバレッジは100%の条件カバレッジと100%ののデシジョンカバレッジを意味する。
