Vietnamese
Englishホワイトボックスと経験ベーステスト
①ホワイトボックス
ホワイトボックステストとは、対象となるシステムやコードの内部構造に基づいて行うテストです。このテストはあらゆるテストレベルで活用できますが、特にコンポーネントテストで用いられる、コードを基にした2つの手法に焦点を当てています。これらの手法では、コード内でどの要素に注目するかによって種類が異なります。また、注目した要素がどの程度実行されたかを示す「カバレッジ」（コードカバレッジ）の測定が重要な役割を果たします。
ステートメントテストとカバレッジ
ステートメントテストでは、コード内の実行可能な命令文（ステートメント）を対象としてテストケースを設計します。このテストで測定されるカバレッジは「ステートメントカバレッジ」と呼ばれ、以下の式で算出されます。
ステートメントカバレッジ（％） = 実行されたステートメントの数 / テスト対象の総ステートメント数 × 100
デシジョンテストとカバレッジ
デシジョンテストとは、コード内の分岐条件やその結果に基づいてテストケースを設計する手法です。分岐条件の記述はプログラミング言語によって異なりますが、典型的な例として if-else文、switch-case文、do-while文 などが挙げられます。
このテストで計測されるカバレッジは「デシジョンカバレッジ」と呼ばれ、以下の計算式を用いて求められます。
デシジョンカバレッジ（％） = 実行された分岐結果の数 / 分岐結果の総数 × 100
前述のステートメントカバレッジと同様に、以下のコードを例にデシジョンカバレッジを解説します。
public void foo(int x) {
if (x != 0) {
x = 1 / x;
}
}
デシジョンカバレッジを100%にするには、if文の分岐結果が真の場合と偽の場合の両方をテストで実行する必要があります。この例では、変数 x に対して以下の2つのテストケースが必要です。
- x が 0 の場合（偽の結果）
- x が 0 以外の場合（真の結果）
ステートメントテストとデシジョンテストの重要性
ステートメントテストとデシジョンテストにはそれぞれ独自の価値があります。デシジョンカバレッジを100%達成すれば、ステートメントカバレッジも必然的に100%達成されますが、その逆は保証されません。この違いは、具体例を見れば明確です。たとえば、if文にelse文がない場合、つまり偽の条件に対応する明示的なステートメントが存在しないコードでは、ステートメントテストとデシジョンテストで必要なテストケースが異なります。これは、両者の手法が異なる視点からコードを評価しているためです。
ステートメントテストは、コード内の実行可能な命令が期待通りに動作するかを確認し、実行中に意図しない結果を引き起こす欠陥を見つけることを目的としています。一方、デシジョンテストは、分岐条件の真と偽の両方のケースを網羅し、それぞれで期待とは異なる動作が生じる可能性を探ります。
ただし、これらのテストケースをコードに基づいて作成する場合、コード自体に誤りが含まれていると、テストで想定される期待結果も誤ってしまう可能性があります。この問題を解消するため、ホワイトボックステストであっても、期待結果を決定する際に仕様書を利用することが必要となる場合があります。
②経験ベースのテスト
経験ベースのテスト技法は、テスト担当者のスキルや直感、さらにはこれまでの類似アプリケーションや技術における経験を活かしてテストケースを設計する方法です。この技法は、ブラックボックステスト技法やホワイトボックステスト技法と併用されることが一般的です。
たとえば、仕様書に明記されていない「暗黙の仕様」に関連するテストは、ブラックボックステスト技法だけでは対応が難しい場合があります。この「暗黙の仕様」は明記されていないがゆえに欠陥が発生しやすい領域であり、経験ベースのテスト技法はそのような欠陥を見つける上で非常に有効です。
しかし、この技法には課題もあります。経験ベースのテストは担当者の進め方や過去の経験に大きく依存するため、その効果にばらつきが生じやすいという特性があります。また、テストのカバレッジも担当者ごとに差が出やすく、さらにカバレッジを測定すること自体が難しいため、カバレッジに基づいた評価が困難なケースが多い点も注意が必要です。
エラー推測
エラー推測は、テスト担当者の知識をもとに、誤りや欠陥、故障が発生する可能性を予測するテスト手法です。この知識には、例えば以下のようなものが含まれます。
- アプリケーションの過去の挙動や動作履歴
- 開発者がよく犯しやすいミスの傾向
- 他のアプリケーションで発生した故障の事例
これらの知識は、テスト担当者の経験により得られるものであり、個々のテスト担当者の知識や経験には限界があるため、起こりうる誤りや欠陥、故障のリスクを一覧化し、そのリストをもとにテストケースを設計することが推奨されます。このリストをテスト担当者間で共有することで、スキルに依存しないテストが可能になり、さらに開発担当者と共有することで、設計や実装段階で早期に欠陥を防ぐことができます。
エラー推測の典型的な例として、以下のようなケースが挙げられます。
- 数値の0
0で除算を行うと例外が発生する - ヌル (null)
ヌルの値を参照しようとすると例外が発生する - 要素数が0または1のリスト
通常、リストは複数の要素を持つことを前提にコーディングされがち - うるう年 (2月29日)
特殊な日付に関する問題
これらのテストケースが失敗しやすいことは経験的に知られており、同様に、対象の操作順序やタイミング、あるいはテスト対象の特性によっても典型的なエラー推測のパターンが存在します。
探索的テスト
探索的テストは、テスト設計、実行、ログ記録、振り返り、そして改善の過程を通じてシステムを学びながら進めるテスト手法です。この方法では、テストケースを事前に作成せず、テストを実行しながらテスト対象をより深く理解することを目指します。探索的テストは、形式的な手法とは異なり、事前に計画されたテストケースに依存しませんが、何らかの基準に基づいてテストを進めることがあります。ただし、体系的な方法とは言えず、テスト担当者はテストチャーターに基づいてテストを実行します。テストチャーターは、テストを導くためのガイドとなり、形式的なテストケース作成に代わる指針として機能します。セッションベースのテストには以下の特徴もあります。
・決められた時間内（セッション）でテストを行う
・実行した手順や発見した事象をテストセッションノートに記録する
探索的テストは、仕様が不十分で事前にテストケースを作成できない場合や、スケジュールに余裕がない場合に特に有効です。この手法により、テスト設計と実行を同時に進めることで、効率よくテストを実施できます。また、形式的なテスト手法を補完する形で実施されることもあり、形式的なテストの後や並行して探索的テストを行うことで、仕様漏れや誤った仕様に基づく欠陥を発見することができます。しかし、もし探索的テストで本来形式的なテストで発見すべき欠陥が見つかれば、テストプロセスに問題がある可能性があります。さらに、仕様が不明瞭な場合には、探索的テストを実施する際に予測しながらテストを行う必要があり、これはテスト担当者のスキルや経験に大きく依存します。探索的テストは重大な欠陥を発見するのに効果的ですが、スキルや経験の差が結果に影響を与える点には注意が必要です。
チェックリストベースドテスト
チェックリストベースドテストでは、テストケースを設計するためにチェックリストを使用します。チェックリストにはテスト条件が記載されており、日本ではこれを「テスト観点」としてリスト化し、テスト設計に活用することが一般的です。チェックリストは、テスト対象に合わせて作成する必要があります。新しくゼロから作成する場合もあれば、既存のチェックリストをそのまま使用したり、カスタマイズして使用することもあります。どちらの場合でも、チェックリストはテスト分析の一部として準備されます。
チェックリストはエラー推測と同様に、テスト担当者の経験を基に作成されます。さらに、以下のような情報も考慮されることがあります。
・ユーザーにとって重要な要素
・ソフトウェアが不合格となる理由やその仕組みについての理解
チェックリストベースドテストは、機能テストだけでなく非機能テストにも使用できます。非機能テストは機能テストに比べて専門的な知識が必要であり、仕様が不明確なことが多いため、チェックリストベースドテストが効果的に活用される場面が多いと考えられます。
チェックリストは高い抽象度で記述されているため、適切なチェックリストを基にテストケースを設計してテストを実施します。場合によっては、チェックリストから直接テストを実行することもあります。この方法では、広範囲なテストを行えるという利点がある一方で、チェックリストの解釈がテスト担当者によって異なるため、テスト実行にバラツキが生じる可能性が高くなります。また、テストの再現性が低くなるため、注意が必要です。
※練習問題：