4.1. テスト開発プロセス ★★★
テスト計画で定義したテスト戦略やポリシーに基づき、テスト条件を決定し、テストケースの設計をどのように行うかなどのテスト開発プロセスについて説明する。
4.1.1. テスト設計のステップ ★★
テスト計画：テストの目的をまず明らかにする。そして、その目的を達成するためのテスト戦略やポリシーが導かれる。
テスト設計では、このテスト戦略に基づいて「どうやって」テストを実施するのかといった具体的なテスト戦術やアプローチを明らかにしていく。
基本的には、テスト計画が示されていなければ、テスト設計はできない。ただ、テスト計画書が作成されない場合はあり得る。
テスト開発プロセスにおけるテスト分析やテスト設計について、以下のステップとなる。
- テスト条件を決定し、テストを設計する
- テストケースを定義する
- テスト手順仕様を定義する
4.1.2. テスト条件を決定し、テストを設計する ★★
IEEE 829というテストの標準文書のドキュメント体系がある。
IEEE 829はテストのドキュメント、つまりテストウェアに関する標準として広く参照されている。
テストウェアの基本方針となるのはテスト計画で、テストの目的や戦略、アプローチ、スケジュールや体制、環境などといったテストプロセスの全体像が示されている。テスト計画(Test Plan)のインプットは、プロジェクト計画(Project Doc)と開発関連ドキュメント(Item Doc)となる。テスト計画をベースにテスト設計仕様(Test Design Spec)を作成し、テスト設計をもとにテストケース仕様(Test Case Spec)やテスト手順仕様(Test Proc Spec)を作成するという文書体系になっている。
・テスト条件を決定するためにテストアイテムを分析する
テストの実施対象は「テストアイテム」と定義されている。
テスト条件は、テストの目的に応じてどのようにテストを割り付けるのかを決めるもの。テストアイテムをどのように区切るかによって変わる。
シラバスでは、機能や構造的要素、トランザクション、品質特性をテスト条件の例としている。
テスト分析作業の進め方：まずはテスト設計の材料集めから始める。RFP（提案依頼書）、購買仕様、開発契約、議事録、仕様を記載した開発文書などの明文化された文書。これらのうち、テストの元とするものは「テストベース」と呼ぶ。
「テストベース」を使って「テストアイテム」を分析し、「テスト条件」を洗い出していく。
材料集めが不十分だと、テスト条件と要求や仕様間のトレーサビリティが確保できなくなる。
テスト対象となるテストアイテムを定義し、テスト条件の整理ができた段階で、どのようなテストを実施すべきかを定義するテスト設計段階に移る。
・テストを設計する
テスト設計では、テスト条件すべてに対してテストを実施すべきかどうか、どういった順番でテスト実施を進めればよいかを判断できるよう、優先度や重みづけを行っておくことが重要。
テスト設計では、テストを実施すべきテスト条件に対し、どのテスト設計技法を適用するかを選択・決定していく。テスト設計技法は、テスト条件に対し網羅的かつ効率的に故障や欠陥を見つけることができるようテストケースを定義するために適用する。このため、テスト設計仕様には、テスト条件が含まれる。
4.1.3. テストケースを定義する ★★
テストケースの定義は、抽象度の高いテストを実際にテスト実施できるように、テスト設計時に定義し、適用することにしたテスト設計技法を用いて記述していく作業のこと。テスト設計に基づき、テストアイテムから導かれたテスト条件を目的に合ったレベルで網羅できるようテストケースを定義していく。テストケースは1つのテスト条件に対して1つ以上作成する。
・テストケースを書く
テストケースの構成要素には、入力データ群、実行のための事前条件、期待結果、実行後の条件(事後条件)がある。
テストケースを記述する上で最低限押さえておくべきこととして、以下2点を挙げる。
・仕様や要件との間に明確なトレーサビリティがあること
テストケースがどの要件に基づいているかの関係を確実に分かるようにすること。
トレーサビリティマトリクスを用いて、テストケースと要件の結びつきを示すのが一般的。
・期待する出力も記述してあること
期待結果があいまいなことが非常に多く、どういった条件の時、どのような出力結果であればテストを合格にすればよいか、テストを実施する担当者によって判断にバラツキが出てしまう可能性がある。
期待結果に書くべき事項として、「出力、データや状態の変化、その他、テストにより発生する結果を記す」とシラバスに定義されている。
4.1.4. テスト手順仕様を定義する ★★★
テスト手順仕様では、テストケースを実行するステップを規定する。メリットは以下。
- テストケースに手順を記載しないで済む。
- 要求や仕様の変化に伴うテスト条件の見直しなどでテスト手順が変わった時でも、変更箇所を影響する範囲の手順だけに抑えることができる。
- テスト手順を用いてテストケースを分類することで、テストの実施順序を効率的に決めることができ、テストの準備や後片付けを考慮したテスト計画が策定しやすくなる。
デメリットは以下。
- テストケースを見ただけではテスト内容が分かりにくくなる。
テスト手順仕様は必ず作るものではなく、メリデメを考慮して判断する。
作成する場合、以下2点を考慮すること。
- テストケースを構造化されたテスト手順仕様に変換し、テスト担当者に必要な知識レベルで詳細化する。
- 優先順位や、回帰テスト、テスト間の技術的および論理的依存性を考慮してテストケースの実行スケジュールを立てる
4.2. テスト設計技法のカテゴリ ★★
シラバスでは3つのカテゴリとしてテスト設計技法が分類されている。
4.2.1. テスト設計技法のカテゴリ ★
代表的な分け方
- ホワイトボックステスト：内部構造を見る、内面に着目する、中身や作りについても検証する。
- ブラックボックステスト：内部構造を見ない、外見に着目する、インプットを処理した結果であるアウトプットを検証する。
シラバスでの分け方
- 経験ベース
- 仕様ベース ⇒ ブラックボックステスト技法
- 構造ベース ⇒ ホワイトボックステスト技法
4.2.2. 仕様ベースのテスト設計技法 ★★
テストアイテムやテスト条件に対する要件、つまり仕様が明らかになっていることが前提。
インプットとなるドキュメントの種類は、テストアイテムをどのように定義するかによって異なる。
文章や箇条書きもあれば、UMLのような図表を用いてモデル化されている場合もある。こういった情報をもとにリストやマトリクスを作成する。リストやマトリクスによって、テストケースの作成を容易にし、仕様や設計のカバレッジとしての網羅度を確保する。
4.2.3. 構造ベースのテスト設計技法 ★★
ソフトウェアの設計／実装に関する詳細情報が必要となる。そこから構造をテストで検証できるパスやデータの組み合わせやパターンを導き出すことでテストケースに変換し、コードカバレッジとしての網羅度を確保する。
4.2.4. 経験ベースのテスト設計技法 ★★
アドホックなテストになりがちで、テストケースがかかれないことも多い。
作業者のスキルに依存するテスト設計となる。テスト対象に対する理解が深く、経験豊富であれば、最終確認的な位置づけとして一定の効果が期待できる。このようなベテランによるテストを「探索的テスト」と呼ぶ。
4.3. 仕様ベース、ブラックボックスのテスト技法 ★★★
ソフトウェアの内部構造を参照しない。
ドキュメントに基づいてテスト条件やテストケースを作成する。
ISTQBでは次の5種類の技法を取り上げる。
- 同値分割法
- 境界値分析
- デシジョンテーブルテスト
- 状態遷移テスト
- ユースケーステスト
4.3.1 同値分割法 ★★★
入力データを同じ処理が行われるグループに分割し、同じものとみなす（同値という）。
・同値クラス
同値分割したグループのこと。有効／無効のグループがある。
入力データだけでなく、出力データにも同値クラスがある。
・テストレベル
すべてのテストレベルに適用できる。
・カバレッジ
入出力のカバレッジ目標を達成する場合に使用できる。同値クラスを網羅するようにテストケースを設計する。
カバレッジは以下の式で求める。
カバレッジ = テスト実施した同値クラス ÷ 全同値クラス
珍しいところでは、時間に依存する値にも同値クラスがある。例えば、文書の保存前と保存後といったようなイベントの前と後で同値クラスを設定する。
4.3.2 境界値分析 ★★★
同値クラスの境界上のデータに、欠陥が多く潜んでいることが多い。
・境界値
同値分割した領域の端の値のこと。
・境界値分析のテストケース
以下の仕様について考える。
【仕様】
年齢を入力し、女性でかつ20～34歳であったら「F1層」と画面に表示する。
ISTQBの境界値の定義は以下。
同値分割した領域の端、あるいは端のどちらか側で最小の増加的距離にある入力値または出力値。たとえば、ある範囲の最小値または最大値。これをどのように解釈するかによって、複数の考え方があります。
①境界値の範囲に含まれる値と含まれない値をテストケースとする
⇒ 19歳、20歳、34歳、35歳がテストすべき値となる。
ISTQBにおける正式な考え方となっている。
②境界値とその両端をテストケースとする
⇒ 19歳、20歳、21再、33歳、34歳、35歳がテストすべき値となる。
ISTQBの考え方とは異なるが、認識違いで考慮漏れをする恐れがなくなる。
③無効なデータのグループ（同値クラス）の端もテストケースとする
⇒ -1歳、0歳、19歳、20歳、34歳、35歳、120歳、121歳がテストすべき値となる。
・テストレベル
すべてのテストレベルに適用することができる。
・カバレッジ
テストすべき境界値の数は2n+2になる。
※n=同値クラスの数
4.3.3 デシジョンテーブルテスト ★★★
デシジョンテーブルとは、入力データや入力条件の組み合わせに対する処理や出力結果を表にまとめたもの。
・デシジョンテーブル
複数の条件が重なり合うときに、分かりやすくまとめることができるのがデシジョンテーブル。
構成は以下の通り。
①条件の一覧（条件記述部）
②結果の一覧（動作記述部）
③条件の組み合わせ（条件指定部）
⇒ 大部分は、真か偽（ブール値）で表現する。表し方の例は以下。
- 真／偽
- Y／N
- T／F
- 1／0
④組み合わせに対応する結果（動作指定部）
⇒ 動作結果の表現方法の例は以下。
- 真／偽
- X(eXecute)／空白
⑤規則
条件の組み合わせとそれに対応する動作結果へ組み合わせたもの、つまり表の縦列のこと。
ISTQBでは次のように定義されている。
構築するシステムの複雑なビジネスルールを記録するために使用することがある。
（中略）
デシジョンテーブルの各列は、特定の条件の組み合わせを定義するビジネスルールと、ルールに対応した行動から構成される。
・デシジョンテーブルテスト
デシジョンテーブルの各列、つまり規則をテストケースとして扱う技法のこと。
・テストレベル
すべてのテストレベルで適用可能。
・カバレッジ
カバレッジは規則、つまり列。カバレッジは以下式。
カバレッジ = テスト実施した規則数 ÷ 全規則数
4.3.4 状態遷移テスト ★★★
システムの状態によって、システムがまったく異なる動作をすることがある。
このような場合、状態を考慮したテスト設計をする必要がある。
このためのテストを状態遷移テストという。
・状態遷移図
システムが状態を持つ場合、必ず複数の状態を持つ。複数の状態をどのように遷移するのかを表現した図を状態遷移図という。
・状態遷移表
状態とイベントのマトリクスで表したもの。状態とイベントの組み合わせをもれなく検討できる。
・状態遷移テスト
状態遷移図または状態遷移表を用いてテスト設計をする。
・テストレベル
すべてのテストレベルで適用可能。
・カバレッジ
- chowのカバレッジメトリクス ⇒ 状態遷移図の1つの繊維とその前の状態と後の状態を組み合わせとするカバレッジ基準。
- セル網羅基準 ⇒ 状態遷移表のセルのパターンを全部テストすればカバレッジ100%とする。
4.3.5. ユースケーステスト ★★★
ビジネスシナリオやシステムの使い方に基づいてテスト設計を行う。
・ユースケース
ユーザおよびシステム（アクターという）と、テスト対象となるシステムとの間の相互作用を記述したもの。
すべてのやり取りを記したものではなく、ユーザや顧客にとって価値のある結果が得られる物を記述する。
・ユースケースの種類
ビジネスユースケース：ビジネスレベルで顧客と企業との相互作用を記述する。
システムユースケース：ユーザとテスト対象のシステムとの相互作用を記述する。
・ユースケース記述
アクターとシステムのやり取りを記述したもの。（図ではない）
一般的に次のようなフォーマットがある。
- ユースケース名
- 目的
- アクター
- 事前条件
- 事後条件
- 基本フロー ⇒ ユースケースの目的を達成するために最も頻繁に実行されるシナリオ。
- 代替フロー ⇒ 基本フロー以外のアクションを行うが、基本フローと同じ事後条件になる。
- 例外フロー ⇒ アクションだけでなく、事後条件も基本フローと異なる。
- 備考
・ユースケーステスト
ユースケーステストで用いるのは、ユースケース図ではなく、ユースケース記述になる。
他の仕様ベースのテスト技法と組み合わせることができる。
・テストレベル
コンポーネントテストでは適用しない。
・カバレッジ
明示的な記述がない。
4.4. 構造ベース、ホワイトボックスのテスト技法 ★★★★
ソフトウェアやシステムの特定の構造に着目したテスト。
4.4.1. テストレベル別の構造ベースの技法 ★★
すべてのテストレベルで実施することができる。
どの構造に着目するかは、テストレベルによって異なる。
- コンポーネントテスト：ソフトウェアコンポーネント（ステートメント、判定、分岐等）
- 統合テスト：コールツリー（モジュールの呼び出し関係を示した図）
- システムテスト：メニューの構造、ビジネスプロセス、Webページの構造
・コードカバレッジのためのテスト設計技法
コンポーネントテストにおいてコードの構造をベースとした技法、すなわちコードカバレッジのためのテスト技法について説明する。
- ステートメント
- 判定
- 分岐
4.4.2. ステートメントテストとカバレッジ ★★★★
ステートメントカバレッジ：テスト対象のコード中の実行可能ステートメント（命令文）のうち、テストによって何%実行されたかを評価するもの。
・ステートメントカバレッジの例
以下のコードを例とする。
public void foo(int x, int y) {
if (x != 0 ) {
y = y / x;
}
if (y > 0 ) {
y = y – 1;
}
}
・最適なテストケースの考え方
「x != 0」かつ「y > 0」のケース1つでカバレッジ100%となる。
4.4.3. デシジョンテストとカバレッジ ★★★★
デシジョンカバレッジ：コード中のすべての判定の結果のうち、テストによって何%実行したかを評価する。分岐網羅、ブランチカバレッジとも呼ばれる。
・デシジョンカバレッジの例
ステートメントカバレッジと同じ例で考える。
2つのif分があり、それぞれの結果がTrue/Falseになるケースを実施する必要がある。最少のケース数で実現するためには以下2通りが考えられる。
- 「x ! = 0」かつ「y > 0」と「x = 0」かつ「y <= 0」
- 「x != 0」かつ「y <= 0」と「x != 0」かつ「y > 0」
・ステートメントカバレッジとデシジョンカバレッジの関係
100%デシジョンカバレッジは、必ず100%ステートメントカバレッジとなる。逆は成り立たない。
よって、デシジョンカバレッジはステートメントカバレッジよりも厳しい評価基準となる。
4.4.4. その他構造ベース技法 ★
・その他のカバレッジの種類
デシジョンカバレッジよりも厳しい評価基準として、条件カバレッジおよび複合条件カバレッジがある。
- 条件カバレッジ
- 複数の条件文がAND／ORで結合された場合、それぞれの条件文の真／偽の結果を網羅する。
- 複合条件カバレッジ
- 複数の条件文がAND／ORで結合された場合、1つ目の条件文の結果が偽の場合、2つ目の条件文が評価されない場合もある。そこまでを網羅したもの。
4.4.5. コンポーネントテスト以外のテストレベルでのカバレッジ -
要件、機能、処理、ユースケースなど、実体のないものに対しても、カバレッジを考えることができる。
4.4.6. カバレッジ計測ツール -
4.5. 経験ベースのテスト技法 ★★
4.5.1. 経験ベースのテスト技法 ★
仕様ベースおよび構造ベースのような体系的なテスト技法は使用せず、経験をベースにテストケースを設計する手法。
・メリットとデメリット
体系的な技法でテストケースを設計した後で、補強的に経験ベースの技法を使用するのは非常に有効なアプローチ。
仕様に書かれていない暗黙の仕様などの欠陥を検出できる。
一方、担当者のスキルや経験に大きく依存するので、効果に大きなばらつきがある。
4.5.2. エラー推測 ★★
・フォールト攻撃
構造的、体系的なアプローチ。
過去に発生した欠陥や故障、および有識者の経験やソフトウェアの故障に対する一般知識をリスト化する。
・エラー推測の例
直感や経験に基づいてテストケースを設計するのがエラー推測。
代表的な例が以下。
- 数値の「0」
- 0による割り算でエラーが起きる
- ヌル(null)
- ヌルの参照で例外が発生する
- 空白のリスト、要素数が1つのリスト
- リストは複数の要素があることを前提としてコーディングしがち
- うるう日(2/29)
- 特殊な日付
4.5.3. 探索的テスト ★★
テストの目的が記録されたテストチャータを基にして、テスト設計、テスト実行、テストの記録や学習を並行に実施する。つまり、あるテストを実施し、その結果をベースにして次にどのようなテストを行えばよいかを考え、実行する。文字通り「手探りで」行っていく。
・メリットとデメリット
仕様が十分に書かれておらず、テストケースを事前に設計できない場合に有効。
また、スケジュール的な余裕がない場合に、テスト設計とテスト実行を同時並行的に行うことで、効率良くテストを進めることができる。
形式的な技法でのテストケース設計の後に補完的に使用することで、仕様漏れや仕様の誤りに基づく欠陥を検出できる。
仕様があいまいな場合、仕様を予想しながらテストを実施する必要があり、スキルや経験を必要とする。
4.6. テスト技法の選択 ★★
4.6.1. テスト技法選択のポイント ★
どのテスト技法を選ぶかは様々な要素に依存する。以下に例を示す。
・システムの種類
組み込み系、エンタープライズ系、オンラインかバッチか、クライアントがリッチかWebかなど。
・規則や標準
プロジェクトや組織の開発基準や規則に、使用するテストの技法が規定されている場合など。
・顧客や契約上の要件
例えば、デシジョンカバレッジ100%を顧客から要求される場合など。
・リスクのレベルや種類
リスクの高い機能は重点的に、リスクの低い機能は動作確認程度まで省くといったアプローチ。
・テストの目的
欠陥を検出することが目的であれば、エラー推測を使用して特殊ケースまでテストし、要求や仕様通りに動作することが目的であれば、仕様ベースの技法を使って確認すればよい。
・入手可能なドキュメント
ドキュメントがない場合、仕様ベースの技法は使えないといった例がある。
・テスト担当者の知識
特に経験ベースの技法は担当者の高いスキルや経験が必要。
・時間と予算
時間や予算が不足していて、最低限必要なテストに限定したい場合、最適なテスト技法を選択する。
・開発ライフサイクル
アジャイル開発では、テストファーストの場合コーディングの前にテストケース設計を行うので、そもそも構造ベースの技法は適用できない。
・ユースケースモデル
ユースケースの想定ユーザや機能に応じて、どのようなシナリオをテストすべきかを考える。
・様々な種類の欠陥を摘出した過去の経験
4.6.2. テスト技法の一般的な組み合わせ ★★
次の手順でテスト設計を行うことを推奨している。
- 仕様が入力条件の組み合わせを含んでいる場合は、原因-結果グラフの作成から行う。
- どんな場合でも境界値分析を行う。
- 入力と出力の有効と無効の同値クラスを見分け、必要ならテストケースを補足する。
- エラー推測技法により、テストケースを補足する。
- 構造ベースの技法により、要求されるカバレッジ基準が、1～4で満たされていない場合は、この基準を満たすようなテストケースを補足する。
Follow me!
