1.「構造ベースのテスト技法」：ホワイトボックステスト

別名「ホワイトボックステスト」とも呼ばれるこの技法は、テスト対象の内部構造と処理内容に焦点を当てる技法です。

「作った通りに動作しているかどうか」を確認する、開発者視点のテストと言えるでしょう。

「カバレッジ（網羅率）」と呼ばれる指標を用いて、ソースコードのどの部分をテストしたのかを、定量的に表現できるメリットがあります。


代表的なホワイトボックステストである「制御フローテスト（制御パステスト）」では、ソフトウェアモジュールの構成要素（命令文、分岐構造、条件）に着目してカバレッジを計測します。

デメリットは、100%に近い高カバレッジを達成しようとすればするほど、工数が増加してしまう点です。

対策として、テスト対象の特徴やプロジェクトの状況に応じて、適切なカバレッジ基準を定めることが重要です。


また、仕様の解釈誤りやコーディングミスに起因する不具合の発見には、あまり適していません。

したがって、期待結果を設定する際は内部構造だけではなく、きちんと最新の仕様にも準拠する必要があります。

単体テストでの適用が一般的ですが、「内部構造を理解したうえで検証する」という意味で、モジュール間の結合テストでも使える技法です。

2.「仕様ベースのテスト技法」：ブラックボックステスト

一般的には「ブラックボックステスト」と呼ばれます。

その名前の通り、内部構造を参照できないブラックボックスとみなして外から見たテスト対象のふるまいが、仕様に沿っているかどうかを重視するテスト技法です。具体的には、テスト対象への入力と、入力に対する出力を検証します。

「使いたいように使えるかどうか」に着目する、ユーザー視点のテストといえます。

テスト設計の際にはデシジョンテーブルや状態遷移図、状態遷移表などを用いて、様々な角度からテスト対象を分析します。


その過程で、仕様の妥当性や考慮不足がないかを整理できる点がメリットです。

加えて、実装時の解釈誤りやコーディングミスの検出も期待できます。

一方、要件や仕様が明確になっていないケースでは有効な検証ができません。

さらに、開発ドキュメントに反映されていない実装によって、引き起こされる不具合の発見も困難です。

よって、最新の仕様に基づいたテスト設計が重要なポイントになります。

他にも、チェックすべき入力データや出力、条件のパターンが膨大になりがちです。


同値分割や境界値分析、デシジョンテーブルの簡略化などのテクニックを用いて、いかに効率的に試験項目を圧縮できるかが、テストエンジニアの腕の見せどころといえます。

アルゴリズムを用いて、自動的に組み合わせパターンを絞り込んでくれるツールも提供されています。

その特徴から、単体テストから総合テスト、ユーザー受け入れテストまで幅広い工程で用いられます。

また、機能テストに限らず非機能テストにも適用できる技法です。

3.「経験ベースのテスト技法」：探索的テスト（アドホックテスト）

経験ベースのテスト技法では、担当者の経験を活用しながら、テスト対象の学習とテスト設計・実行を並行して進めます。

そのため、事前のテスト設計はそれほど重視されないケースが多いです。

不具合が潜む箇所を探るように試験を進める様子から、「探索的テスト（アドホックテスト）」とも言われます。

担当者の経験によって、開発者視点とユーザー視点どちらの検証も可能です。


経験ベースのテストの最大のメリットは、効率よく不具合を発見でき、スケジュールを圧迫しない点です。

特に、過去のプロジェクトで蓄積された不具合情報を用いて、精度の高いエラー推測が可能な場合があります。

またスキルと経験、業務知識が豊富なテストエンジニアの支援が得られるケースでは、テスト工数を削減する有効な選択肢になりえます。

加えて、仕様確定が不十分な状況でも検証を進められます。


反面デメリットとして、担当者の経験やスキルに依存するので、期待したような効果が上がらないおそれがあります。

また、テスト実行を優先する目的で、テ

カバレジ基準とは、着目する要素のことを指し、それらをどれだけ網羅できているかを割合で示します。

　1.ステートメントカバレッジ
　フローチャート内から要素として，「命令文」を選択した場合

　2.デシジョンカバレッジ
　フローチャート内から要素として，「分岐した経路」を選択した場合

　3.複合条件カバレッジ
　条件に含まれる全てのパターンを満たす場合


これら全てのカバレッジは選択した経路を、最低一度は通らなくてはなりません。

これらのカバレッジ基準は、下に行くほどテスト回数が多くなります。

また上位のカバレッジは下位のカバレッジ基準を含んでいるため、上位のカバレッジ基準を満たすと、必然的に下位カバレッジ基準を満たすことになります。

1.単体テスト

単体テストとは，クラスや関数といった単位のプログラムのテストになります。

主に設計通りにこれらが動くかをテストし、論理構造が適切かを確認します。

・機能確認テスト
　1つのモジュールが設計書や仕様書通りに動作することを確認するテスト

・制御フローテスト
　プログラムの論理構造に沿って，「命令」や「分岐」などが実行されるかを確認するテスト

・データフローテスト
　データや変数が「定義」「使用」「消滅」の順に行われているかを確認するテスト

2.結合テスト

結合テストとは、単体テストで検証したプログラムを組みわせて行うテストになります。

・状態遷移テスト
　状態遷移図や状態遷移表に基づいて動作を確認するテスト

3.機能テスト

機能テストとは、結合したプログラムを1つの機能として行うテストです。

・機能確認テスト

4.システムテスト

システムテストは，個々のプログラムや機能を結合したプログラムが仕様通りに動くかを検証するためのテストです，

・確認テスト

・回帰テスト
　修正・変更した後に，変更箇所が正しく動くかを確認するテスト

・デグレードチェックテスト
　修正・変更を行った後に，新たな不具合が生まれていないかを確認するテスト

5.評価テスト

・増セキュリティテスト　
　悪意のある外部からの攻撃への対応や脆弱性が存在しないかを確認するためのテスト

・ユーザビリティテスト
　操作性，学習性，理解性，見やすさといったユーザーに対しての使いやすさを確認するテスト

・障害許容性テスト
　障害が発生した場合に指定された機能が維持されていることを確認するテスト

6.負荷テスト

・性能テスト
　処理能力が仕様を満たしているか確認するテスト

・ロングランテスト
　長時間の連続稼働によって処理能力や稼働率に問題が生じないかを確認するテスト

・負荷テスト
　極端に高い負荷をかけた状況下での動作を確認するテスト

etc.

・受け入れテスト
対象のシステムがユーザーの要求を満たしているのかを確認するテスト

・運用テスト
実際の操作環境下でシステムが正しく動くかを確認するテスト

・アルファテスト
開発者以外の人が操作して，不具合がないことを確認するテスト

・ベータテスト
発売・リリース前の製品を開発者以外の一般ユーザーが操作して，不具合がないことを確認するテスト