ソフトウェアテスト技法とは？: 代表的な技法を解説
今回はソフトウェアテストにおける代表的な技法について詳しく解説していきます。
目次
ソフトウェアテスト技法とは？: 代表的な技法を解説
1.テスト技法とは？
みなさんはテスト設計をする際に
「どこまで網羅してテストしたらいいのか」
「どういう考え方でテストに落とし込んでいけばいいのか」
と迷われた経験はないでしょうか？
テスト技法とは、そんなソフトウェアテストの「テスト設計」や「テストケース」を作成する上で
考え方の助けになる技法です。
テスト技法を選択する際には主に3つの視点があります。
「ブラックボックステスト（仕様ベースのテスト技法）」および
「ホワイトボックステスト（構造ベースのテスト技法）」、「経験ベースのテスト技法」です。
それぞれの視点から見えてくるテスト全体の視野は異なり、テスト設計者の視点と経験が品質保証に
大きな影響を与えます。
これらの視点のテスト技法を理解し、それぞれのテストケースの優先順位を決定することで、
テストを効率的に実施でき、より高い品質のソフトウェアを生み出すことが可能になります。
しかし、テスト設計者の経験とスキルも重要で、適切なテスト設計技法の選択には経験と
深い理解が必要です。
まずは、ブラックボックステストの技法を紹介します。
2.ブラックボックステストの解説
ソフトウェアテスト設計をする際によく使われる技法の一つにブラックボックステストがあります。
この技法は内部構造（ソースコードやプログラムの仕組み）を考慮せず、システムの入力と出力の
振る舞いを確認するテスト技法です。
テスト項目を洗い出す際は要件や仕様書などのテストアイテムをインプットとして使用します。
ブラックボックステストでは性能の確認だけではなく、ユーザーが使用する際の不便さがないか、
操作しやすいデザインになっているかなどのUI/UXについての確認も含んでいます。
以下は代表的なブラックボックステスト技法について説明します。
同値分割法
「同値分割法」は入力データを同じ結果をもたらすはずの入力値の集合
「同値パーティション（同値クラス）」に分割し、その代表値でテストを行う技法です。
例えば、1から２０を入力した結果が〇、それ以外の数字を入力した結果が×になるシステムがあったとすると1から２０までの代表有効値とそれ以外の無効値をそれぞれ選択することで、テストの工数削減を実現することができます。
境界値分析
「境界値分析」は、同値パーティションの境界部分がバグを引き起こす可能性が高いことに着目し、
境界値でテストを行います。
1から２０が入力できるシステムを例としましょう。
１から２０を「有効同値パーティション（正常動作する値）」、０以下または２１以上の値を
「無効同値パーティション（エラーが発生する値）」と仮定します。
この時に隣接する値、例えば１と０、２０と２１をテストすることで最小～最大範囲の不具合を
効率よく発見することができます。
デシジョンテーブルテスト
デシジョンテーブルテスト技法とは、システムの動作が複数の条件に基づいて決まる場合に使用される方法で、各条件とその結果をデシジョンテーブルにまとめます。テーブルは視覚的に理解しやすく、
全ての条件の組合せを網羅的にテストすることが可能です。
これにより、予期せぬ条件の組み合わせによるエラーの未然防止が可能となります。
また条件と動作の組み合わせを洗い出してデシジョンテーブルを作成する際にあり得ない
組み合わせパターンを抽出することで、不要なテストケースの作成・実行を防止し、
工数を削減することにも役立ちます。
原因結果グラフ法
ソフトウェアテストで利用できるブールグラフのことを使用したテスト技法を
「原因結果グラフ法」といいます。
デシジョンテーブルテストと同様に複数の条件と結果の組み合わせを考えるテスト設計技法ですが、
グラフを用いて視覚化します。各条件（原因）と結果がノード、その関係がエッジとなるグラフを
作成し、全てのパスをテストケースとすることで、複雑なシステムでもテストケースの洗い出しを
効率化します。
原因結果グラフは基本的には「ノード」「リンク」「制約」の３つの要素で構成されます。
・ノード
原因や結果を表し、真理値（真or偽）を持ちます。
・リンク
ノードとノード間を繋ぐ線のこといいます。この時に「原因」-「結果」や、
「原因」-「原因」間に論理関係を表す記号「AND」「OR」「NOT」を挿入します。
・制約
制約には大きく分けて「集合を表す制約」「順序を表す制約」があります。
集合を表す制約には「ONE」「EXCL」「INCL」があり、順序を表す制約には
「REQ」「MASK」があります。
デシジョンテーブルテストと原因結果グラフ法については、仕様が複雑なシステムにおいて
特に有用です。しかし、何をテストすればよいのか仕様から明確に理解できる場合には、
「同値分割法」や「境界値分析」などの技法がより効果的です。
状態遷移テスト
「状態遷移テスト」は、特に状態を持つシステムや機能のテストに役立つ技法です。
具体的な状態とその状態間の遷移を定義し、システムが予期された遷移パターンに従って機能する
か確認します。例えば、オンラインショッピングサイトのショッピングカートは、
「カートが空である」、「商品が1つ以上カートに入っている」、「注文が確定している」など、
複数の状態や状態間の遷移を持ちます。これらを対象にテストケースを作成し、
期待される動作を網羅的に検証します。
主に状態遷移テストでは以下の3つの視点からどう状態が変化するかを考えるようにしましょう。
・ハードウェアの状態
例えば「PCの電源がOFFになった際、HDDが止まる」「車でブレーキを踏んでいる」
のようなイベントによる状態
・ソフトウェアの状態
「画面遷移」や「イベントの処理中」の状態
・外の世界の状態
ハードやソフト以外の要因のことで「システムを利用する人の動き」の状態
ユースケーステスト
「ユースケーステスト」は、特定のユースケース（システムの使用例）に基づいてテストを行う手法です。具体的なユーザーシナリオに焦点を当てるため、システムが実際の操作環境でどのように機能するかを確認しやすいです。このテスト手法は、ユーザーの視点からシステムを評価し、利用者が直面する可能性のある問題を早期に発見するのに効果的です。
以上、ブラックボックステストについて解説してきましたが、これらの設計技法を併用することで、
バグのある条件やデータの組み合わせを網羅的に見つけ出し、ソフトウェアの品質を確保することが
可能になります。
しかし、全てのテスト設計技法が全ての状況に適しているわけではありません。
適切なテスト設計技法を選択し、適用することが、効率的かつ効果的なテストを行うための鍵となります。
これらのテスト設計の方法や考え方は、テストエンジニアだけでなく、開発者やプロダクトオーナーにも有益で、全体の作業効率とソフトウェア品質の向上に寄与します。
品質の高いソフトウェアを作成し、ユーザーの満足度を高めるために、これらのテスト設計技法を理解し、活用することが大切です。
3.ホワイトボックステスト技法の解説
前項ではブラックボックステスト技法について解説してきました。
ここではホワイトボックステスト技法について解説します。
内部構造を意識せず、システムの外部から見た振る舞い確認するブラックボックステストとは逆に、
ホワイトボックステストはソースコードやシステム構造に着目する「構造ベース」のテスト技法で、
開発者目線で確認するテスト技法となります。
ホワイトボックステスト技法には「ステートメントテスト」や「ブランチテスト」などが含まれ、
これらはプログラムの内部構造とコードの観点からテストケースを設計します。
以下にソフトウェアの内部構造に焦点を当てたホワイトボックステストの代表的な技法を紹介します。
制御フローテスト
「制御フローテスト」は、ソフトウェアの制御パスをテストする方法です。システムが各関数を
どのように通過するかをチェックし、なるべく全てのパスを網羅するようにテストケースを
設計します。このテストは、通常、コードの視覚的な表現またはフローチャートに基づいて行われます。
制御フローテストは以下の種類にわけられます。
・命令網羅（ステートメントカバレッジ）
全ての命令文（処理）を少なくとも1回ずつテストすることで、
ステートメントカバレッジ100％を達成することができます。
・分岐網羅（ブランチカバレッジ）
ソースコードの制御フローにおいて分岐条件のTrue/False少なくとも1回テストすることで、
ブランチカバレッジ100％を達成することができます。
・条件分岐（デシジョンカバレッジ）
ソースコード中の条件分岐の組み合わせを全て実行することで、デシジョンカバレッジ100％を達成
することができます。
・データフローテスト
「データフローテスト」は、アプリケーションのデータパスの動作をテストします。ソフトウェアの
信頼性やパフォーマンスを向上させるために重要な技法の一つです。
具体的には、データがソフトウェア全体でどのように移動するか、どのように変換されるかについてのテストを行います。
このテストは、データがシステム内を正しく流れるかを確認するために役立ちます。
データの流れを解析し、誤ったデータの混入を特定することでバグを発見しやすくします。
ホワイトボックステストは、主に単体テストでのソフトウェアの品質を向上させるために有効です。
品質保証の観点から見ると、システムの内部動作を理解し、それに基づいてテストを設計することで、システムの品質を確保し、潜在的な問題を事前に特定することが可能となります。
その結果、より安全で信頼性の高いソフトウェアを開発できます。
4.経験ベースのテストの活用
ソフトウェアテストの世界では、経験ベースのテスト技法が重要な役割を果たしています。
特に、「エラー推測」と「探索的テスト」は、テスト担当者の経験と直感を活かしつつテストを行う
ための手法です。
エラー推測
「エラー推測」は、テスト担当者が過去の経験に基づいてエラーが存在すると予想される部分を
特定し、重点的にテストを行うための手法です。
エラー推測を用いることで、過去のクラッシュやバグを考慮し、その発生を予防することが可能となります。また、複雑なソフトウェアシステムでは、全てを網羅的にテストすることはしばしば不可能
です。
そこで、エラー推測を使うことで、リソースの限られた状況下ででも有益なテスト結果を得られます。
具体的に使用する経験知識としては以下のようなものがあります。
・アプリケーションの過去の動作状況
・開発担当者が犯しやすい誤りの種類
・他のアプリケーションで発生した故障
探索的テスト
「探索的テスト」は、テストケースを前もって詳細に設計するのではなく、テストを行いながら
進行方向を決定する手法です。探索的テストは、テストケース設計とテスト実行が同時に進行し、
テスト担当者の知識や経験、直感に依存します。
探索的テストを用いることで、想定外の問題を発見したり、新たな視点でシステムを評価したりする
ことが可能となります。
とはいえ、何も準備せずにテストするわけではありません。
セッションベースドテスト・チェックリストベースドテストと呼ばれる体系的な探索テストの実施方法があります。
セッションベースドテスト
セッションベースドテストには以下のような特徴があります。
・あらかじめ決められた時間内で行う
・実行した手順や発見した事象を探索テストのシートに記載する
チェックリストベースドテスト
「チェックリストベースドテスト」は、テスト観点をリスト化してテストケースを作成します。
テスト対象に合わせて作成する必要がありますが、既存のチェックリストをそのまま流用するパターンと新規に作成しなければならないパターンがあります。
また、チェックリストベースドテストには以下の情報を使用します。
・ユーザーにとって何が重要であるかという知識
・ソフトウェアが不合格となる理由と仕組みについての理解
これらの手法は効果的ではありますが、テスト担当者のスキルと経験に大きく依存します。
そのため、これらの手法を適用するには十分なトレーニングと経験が必要となります。
それぞれの手法が持っている特徴を理解し、適切な場面で活用することが重要です。
エラー推測は、特定のエラーパターンを発見するのに役立ちます。
一方、探索的テストは、より包括的な視野でシステムを検証し、予期せぬエラーやバグを発見するのに有用です。このように、テスト戦略を設計する際には、様々なテスト手法を組み合わせることで、
より効果的な結果を得ることができます。
5.ソフトウェアテストの選び方とその重要性: まとめ
ソフトウェアテストは、ソフトウェアの品質を確保するための不可欠なプロセスです。
ソフトウェア開発の進行とともに、設計、コード、機能などの正しさと信頼性を検証するために使用
されます。テスト技法の選び方は、テストの目的、対象となるソフトウェアの特性、利用可能な
リソースなどによって異なります。
テスト技法の選択は、ソフトウェアの品質を最適なレベルに保つために重要です。
テスト技法は大きく三つの基準があり、「仕様ベース」、「構造ベース」、「経験ベース」に分けられます。
ブラックボックステストは、システムや機能の仕様書に基づいてテストケースを作成する手法であり、同値分割法や境界値分析などが含まれます。
一方、ホワイトボックステストは、システムやソフトウェアの内部構造に焦点を当て、コードの網羅率を確認することを目指す手法で、制御フローテストやデータフローテストが該当します。
経験ベースのテスト技法は、テストの経験と直感を活用したテスト手法で、エラー推測や探索的テストなどがあります。
しかし、どんなに強力なテスト技法でも、それ自体がソフトウェアの品質を保証するものではありません。ソフトウェアテストはあくまで問題を発見し、診断するものであり、問題の修正はその後のステップで必要となります。
また、テストは時間とリソースを必要とするため、効果的なテスト技法を選択することが重要です。
ソフトウェアテストでは、問題の早期発見、品質の向上、顧客満足度の向上などに寄与します。
適切なテスト技法を選択し、効果的なテスト戦略を開発することで、ソフトウェア開発プロジェクトの成功へと導くことができます。