テスト手法入門：初心者向けガイド

機能テスト

定義:ソフトウェアの特定の機能が期待通りに動作するかを確認するテスト。

例:想像してみてください。あなたがオンラインショッピングサイトを使っているとき、「カートに追加」ボタンをクリックしたら、商品がカートに追加されるかどうかを確認するのが機能テストです。

テスト手法:

• 境界値テスト
• 例外テスト
• 同値クラステスト
• デシジョンテーブルテスト
• ペアワイズテスト
• 状態遷移テスト

非機能テスト

定義: システムの性能、安定性、使用感など、具体的な機能以外の品質を評価するテスト。

例: オンラインショッピングサイトが、同時に多くのユーザーからのアクセスに耐えられるか、ページの読み込み速度が速いかどうかを確認するのが非機能テストです。

テスト手法:

• パフォーマンステスト
• ボリュームテスト
• ストレステスト
• ロードテスト
• ソークテスト
• セキュリティテスト
• ユーザビリティテスト

特定の状況・シナリオテスト

定義: ある特定の状況や条件下でシステムがどのように動作するかを評価するテスト。

例: 電子商取引のサイトで、商品が在庫切れの場合、ユーザーに適切なメッセージが表示されるかどうかを確認するのがシナリオテストです。

テスト手法:

• リグレッションテスト
• リカバリテスト
• バックアップ/リストアテスト
• コンプライアンステスト

探索的・直感的テスト

定義: スクリプトや詳細な計画に従わず、テスターの経験や直感に基づいてテストを行う方法。

例: 新しいゲームアプリを手に入れたとき、マニュアルを読まずに自由に遊ぶような感じで、ソフトウェアを自由に操作してみるのが探索的テストです。

テスト手法:

• 探索的テスト
• アドホックテスト
• ファジーテスト

基本的な評価・検証テスト

定義: システムの基本的な動作を迅速に確認するためのテスト。

例: 新しいアプリをインストールしたとき、まずアイコンをクリックしてアプリが開始されるか、初期画面が表示されるかを確認するのが基本的な評価テストです。

テスト手法:

• スモークテスト
• ベータテスト

互換性テスト

定義: ソフトウェアが異なる環境やデバイスで適切に動作するかを確認するテスト。

例: あなたの開発したモバイルアプリが、iPhoneだけでなく、SamsungやHuaweiなどのAndroidデバイスでも正しく動作するかを確認するのが互換性テストです。

テスト手法:

• 互換性テスト

各テスト手法の詳細

境界値テスト

入力データの範囲の境界値や、そのすぐ近くの値をテストするものです。多くのバグや問題は、入力データの許容範囲の境界で発生することが多いため、境界値テストは非常に効果的です。

■基本的な考え方

1. システムの仕様や要件を分析して、入力データの許容範囲や境界を特定します。
2. それらの境界値、そして境界のすぐ外側と内側の値を使用してテストケースを作成します。
3. テストを実行し、システムの動作を確認します。

■例

仕様: ユーザーが年齢を入力するフォームがあり、許容範囲は18歳から65歳までとする。

テストケース:

1. 18歳を入力（下限境界値）
2. 17歳を入力（下限のすぐ外側の値）
3. 19歳を入力（下限のすぐ内側の値）
4. 65歳を入力（上限境界値）
5. 66歳を入力（上限のすぐ外側の値）
6. 64歳を入力（上限のすぐ内側の値）

これらのテストケースによって、システムが境界値を適切に処理しているか、また許容範囲の外側の値に対して適切なエラーメッセージを表示するかなどを確認することができます。

境界値テストは、特定の範囲内でのシステムの動作を検証するための手法として、同値クラステストとよく組み合わせて使用されます。

例外テスト

ソフトウェアが異常な状況や想定外の入力値に対して適切に反応するかを確認するためのテストです。このテストの目的は、システムが例外、エラー、または異常な状況を適切に処理し、適切なエラーメッセージを表示するか、または適切な回復アクションをとるかを検証することです。

■基本的な考え方

1. ソフトウェアの仕様、要件、またはビジネスルールを分析して、想定外の入力や異常な状況を特定します。
2. それらの状況や入力に基づいてテストケースを作成します。
3. テストを実行し、ソフトウェアの反応やエラーメッセージを確認します。

■例

仕様: ユーザーがログインフォームにユーザー名とパスワードを入力してログインするシステムがある。

テストケース:

1. ユーザー名フィールドを空白にしてログインボタンをクリック -> エラーメッセージ「ユーザー名を入力してください」が表示されるべき。
2. 正しいユーザー名を入力し、パスワードフィールドを空白にしてログインボタンをクリック -> エラーメッセージ「パスワードを入力してください」が表示されるべき。
3. 存在しないユーザー名とパスワードを入力してログインボタンをクリック -> エラーメッセージ「ユーザー名またはパスワードが正しくありません」が表示されるべき。

このように、例外テストでは正常な動作ではなく、エラーや例外を引き起こす可能性のある状況をテストします。これにより、システムが想定外の入力や状況に対して適切に反応し、ユーザーに適切な情報を提供することが確認できます。

同値クラステスト

入力データを類似の動作をするグループ（またはクラス）に分割して、各グループから代表的なデータを選び、テストを行うものです。この手法の目的は、多数の入力値をテストするのではなく、各同値クラスから1つまたはいくつかの値をテストすることでテストケースの数を効果的に削減することです。

■基本的な考え方

1. 仕様を参考にして、入力データを正常な動作をするクラス（有効な同値クラス）と異常な動作をするクラス（無効な同値クラス）に分けます。
2. 各同値クラスから代表的な値を選びます。
3. 選ばれた値を使用してテストケースを作成し、テストを行います。

■例

仕様: 年齢を入力して、その人が成人か未成年かを判断するプログラムがある。成人は18歳以上、未成年は18歳未満とする。

同値クラス:

1. 有効な同値クラス: 18歳以上の年齢
2. 無効な同値クラス: 18歳未満の年齢

この同値クラスを基に、以下のようなテストケースを考えることができます：

1. 25歳（有効な同値クラスからの代表値） -> 成人と判断されるべき
2. 15歳（無効な同値クラスからの代表値） -> 未成年と判断されるべき

この手法により、たくさんの年齢をテストする代わりに、各同値クラスから代表的な値を選んでテストを行うことができ、効率的なテストが可能となります。

デシジョンテーブルテスト

特定のビジネスルールやシステムの動作が多数の入力条件や状態に基づいて異なる場合に使用されます。デシジョンテーブルは、それらの入力条件や状態と、それに基づく期待されるアクションや結果を表形式で整理します。この手法は、複雑なビジネスルールをシステマティックにテストするのに特に役立ちます。

■基本的な考え方

1. 入力条件や状態の組み合わせを特定します。
2. それぞれの組み合わせに対して期待されるアクションや結果を特定します。
3. テーブル形式でこれらの情報を整理します。
4. テーブルに基づいてテストケースを作成します。

■例

ビジネスルール: オンラインの本屋で、会員と非会員がいる。会員は新刊に10%の割引を受ける。非会員は割引を受けない。ただし、100ドル以上の購入で全員に5%の割引が適用される。

デシジョンテーブル:

会員?	購入額が100ドル以上?	割引
Yes	Yes	15%
Yes	No	10%
No	Yes	5%
No	No	0%

このデシジョンテーブルを使用して、テストケースを作成することができます。例えば:

1. 会員が90ドルの新刊を購入 -> 割引は10%
2. 会員が110ドルの新刊を購入 -> 割引は15%
3. 非会員が90ドルの新刊を購入 -> 割引は0%
4. 非会員が110ドルの新刊を購入 -> 割引は5%

デシジョンテーブルテストは、状態や条件の組み合わせが多く、それぞれが異なるアウトカムを持っている場合に特に有用です。

ペアワイズテスト

入力変数やオプションの組み合わせが多数存在するソフトウェアをテストする際の手法の一つです。このテスト手法の目的は、すべての可能な組み合わせをテストする代わりに、各組み合わせのペア（2つの組み合わせ）だけをテストすることで、テストケースの数を効果的に削減しつつ、十分なカバレッジを確保することです。

■基本的な考え方

実際のソフトウェアには、複数のパラメータやオプションが存在することが多く、それらのすべての組み合わせをテストしようとするとテストケースの数は指数関数的に増加してしまいます。しかし、多くのバグはパラメータやオプションの単一の値ではなく、その組み合わせによって発生するとされています。そのため、すべての組み合わせをテストする代わりに、2つのパラメータのすべてのペアをカバーするテストケースを選択することで、効果的にバグを検出できるという考えがペアワイズテストの基礎となっています。

■例

仮に、スマートフォンのショッピングアプリのテストを行うとします。このアプリには以下のオプションが存在するとしましょう。

1. OS: Android, iOS
2. 接続: Wi-Fi, 4G, 5G
3. 画面モード: ポートレート, ランドスケープ

これらのオプションの全ての組み合わせをテストしようとすると、2 × 3 × 2 = 12のテストケースが必要になります。

しかし、ペアワイズテストを適用すると、以下のようなテストケースが考えられます。

1. Android, Wi-Fi, ポートレート
2. Android, 4G, ランドスケープ
3. Android, 5G, ポートレート
4. iOS, Wi-Fi, ランドスケープ
5. iOS, 4G, ポートレート
6. iOS, 5G, ランドスケープ

状態遷移テスト

システムのオブジェクトやコンポーネントが持つ異なる状態と、それらの状態間の遷移をテストするものです。システムの動作が状態によって変わる場合、特定のイベントや条件に応じて状態が遷移することが想定されます。状態遷移テストは、これらの状態と遷移をシステマティックにテストすることを目的としています。

■基本的な考え方

1. システムの仕様や要件を分析して、可能な状態とそれらの状態間の遷移を特定します。
2. 状態遷移図やテーブルを作成して、状態と遷移を視覚的に表現します。
3. 状態遷移図に基づいてテストケースを作成します。
4. テストを実行し、システムの動作を確認します。

■例

仕様: オンラインショッピングのショッピングカート機能があり、以下の状態が考えられる。

1. カート空
2. カートに商品あり
3. 購入完了

遷移:

• カート空 -> 商品を追加 -> カートに商品あり
• カートに商品あり -> 商品を削除 -> カート空
• カートに商品あり -> 購入 -> 購入完了
• 購入完了 -> カートをクリア -> カート空

テストケース:

1. カートが空の状態から商品を追加して、カートに商品がある状態になるかを確認。
2. カートに商品がある状態から商品を削除して、カートが空になるかを確認。
3. カートに商品がある状態から購入操作を行い、購入完了状態になるかを確認。
4. 購入完了状態からカートをクリアする操作を行い、カートが空になるかを確認。

状態遷移テストは、特に状態が多く、それらの状態間の遷移が複雑なシステムで非常に有効です。

パフォーマンステスト

ソフトウェアのアプリケーションやシステムが特定の条件下でどれだけのパフォーマンスを持っているかを測定するためのテスト手法です。パフォーマンステストは、レスポンス時間、スループット、リソース利用率などの指標を用いてシステムの速度、スケーラビリティ、および安定性を評価します。

■目的

1. 性能要件を満たしているか確認する。
2. システムのボトルネックや弱点を特定する。
3. システムの最大容量や限界を識別する。
4. 異なる設定や環境でのパフォーマンスを比較する。

■主な種類

1. 負荷テスト: 特定の負荷レベルでのシステムの動作を評価します。
2. ストレステスト: システムの限界や崩壊点を見つけるために、過度な負荷やストレスをかけます。
3. エンドランステスト: 長期間の一定の負荷下でシステムの耐久性やメモリリークをチェックします。
4. スケーラビリティテスト: システムがスケーリングする際のパフォーマンスを評価します。
5. スパイクテスト: 短時間で大量のユーザーやリクエストが突然増加する場合のシステムの反応をテストします。

■例

あるオンラインショッピングサイトが「ブラックフライデー」のセールイベントを計画しているとしましょう。

• 負荷テスト: 通常のピーク時のユーザー数（例: 5,000人）がサイトを同時に利用する場合のレスポンス時間やサーバのリソース使用率を測定します。
• ストレステスト: システムがサポートする最大のユーザー数を超えた場合（例: 10,000人以上）の挙動やシステムのクラッシュする点を確認します。
• エンドランステスト: 24時間連続で1,000人のユーザーがサイトを利用する場合にメモリリークや性能の低下が発生するか確認します。

このように、パフォーマンステストはシステムの安定性や耐久性を確認し、リリース前に問題点を特定して改善するための重要なプロセスとなります。

ボリュームテスト

システムが大量のデータを処理する際のパフォーマンスや耐久性を確認するためのテストです。このテストは、データベース、メッセージキュー、ファイルシステムなどのデータを扱うコンポーネントにとって特に重要です。

■目的

1. システムが大量のデータを効果的に処理・格納できるかを確認する。
2. 大量のデータに対する操作（追加、更新、削除など）のパフォーマンスを評価する。
3. データが増加するにつれてのシステムの振る舞いを確認する。

■例

仕様： ある企業が顧客データベースアプリケーションを開発しているとします。このアプリケーションは、最大1億の顧客レコードを管理することを目標としています。

ボリュームテスト：

1. 初期ボリュームテスト：10万レコードでのシステムのレスポンスと動作を確認。
2. 中間ボリュームテスト：5000万レコードをデータベースに格納し、検索、更新、削除などの操作のパフォーマンスを評価。
3. 最大ボリュームテスト：1億レコードをデータベースに追加して、システムの反応やクエリの実行時間、データベースの負荷などをチェック。

このボリュームテストを通じて、システムが大量のデータを効果的に処理する能力や、特定のボリュームでの性能ボトルネックを識別することができます。

ストレステスト

ソフトウェアやシステムが想定される最大負荷やそれを超える負荷条件下でどのように動作するかを確認するテスティング手法です。ストレステストの主な目的は、システムの限界やブレークポイントを識別し、過度なストレスがかかった場合にシステムがどのように失敗するか（また、どのように回復するか）を確認することです。

■主な特徴

1. システムやアプリケーションに通常よりも高い負荷やリクエストを発生させます。
2. システムの弱点、ボトルネック、またはクラッシュの原因となる要素を特定します。
3. システムのリソース（CPU、メモリ、ディスクなど）の消費率を確認します。
4. システムが障害からどのように回復するか、または障害発生時の挙動を確認します。

■例

仕様： あるウェブアプリケーションが日常的に5,000の同時ユーザーをサポートできるとされているとします。

ストレステスト：

1. 増加的なストレス：5000ユーザーから始め、1000ユーザーずつ増やしていき、システムがクラッシュするまたは応答しなくなるポイントを特定します。
2. 突然のスパイク：通常のユーザー数から突然15,000のユーザーがアクセスするシナリオをシミュレートして、システムの反応を確認します。
3. リソース制限：CPUやメモリを意図的に制限した状態で高負荷をかけることで、リソースの不足時の挙動を確認します。

このストレステストを通じて、システムが過度な負荷下でどのように動作するか、どこがボトルネックになるか、また障害が発生した場合の対応方法や回復能力を評価することができます。

ロードテスト

ソフトウェアのアプリケーションやシステムが特定の期待される負荷レベルでの性能を評価するためのテスト手法です。主な目的は、システムが正常な運用条件下でどれだけのパフォーマンスを持っているかを確認することです。

■主な特徴

1. 実際のユーザー行動や取引を模倣するためのシナリオを定義します。
2. 予想される同時ユーザ数やトランザクション数をシステムにかけることで、その応答や性能を測定します。
3. システムの各部分のレスポンスタイム、データベースのクエリ速度、サーバのCPU使用率など、様々な指標をモニタリングします。

■例

仕様： あるEコマースウェブサイトがピーク時に1日に10万人の訪問者を受け入れる能力があるとします。一般的なユーザー行動は、サイトの閲覧、商品の検索、カートへの追加、そして購入のプロセスを含むとします。

ロードテスト：

1. ユーザーシナリオの定義：ユーザーがサイトにアクセスし、商品を検索、カートに追加、購入までの一連の行動を定義します。
2. 負荷の増加：開始時には1,000の同時ユーザーから始め、徐々に10万の同時ユーザーまで増加させます。
3. 指標のモニタリング：ページのロード時間、データベースの応答時間、サーバのリソース使用率など、重要な性能指標を継続的にモニタリングします。

このロードテストを通じて、ウェブサイトが予想される負荷レベルでの性能を確認することができ、必要に応じて最適化や改善のアクションをとることが可能となります。

ソークテスト

システムやアプリケーションが長期間の間、継続的な使用に耐えられるかを確認するための性能テストの一形態です。ソークテストの主な目的は、システムに潜在的なメモリリーク、データベース接続の問題、リソースの使用の不具合など、時間の経過とともに発生しうる問題を特定することです。

■主な特徴

1. 長期間にわたってシステムを一定の負荷で動作させる。
2. システムのリソース使用状況、特にメモリの使用量やデータベース接続などを継続的にモニタリングする。
3. 期間中の性能の劣化やシステムの不具合を検出する。

■例

仕様： クラウドベースのファイルストレージアプリケーションが、1日中断なく動作し、数千のユーザーが同時にファイルのアップロード、ダウンロード、編集を行うことが期待されている。

ソークテスト：

1. テストの設定：3000の仮想ユーザーを使用して、ファイルのアップロード、ダウンロード、編集などの一連のタスクをシミュレートします。
2. 実行期間：このテストを連続して48時間実行します。
3. モニタリング：テスト期間中、メモリ使用量、データベース接続、サーバのCPU使用率などの指標を継続的に監視します。
4. 結果の分析：48時間の経過後、リソースの消耗やシステムの応答時間の変動、エラーの発生などの問題を特定します。

このソークテストを通じて、長期間の連続運用におけるアプリケーションの耐久性やリソース使用の問題点を識別することができます。

セキュリティテスト

情報システムの脆弱性やセキュリティ上の欠陥を特定し、潜在的な脅威や攻撃からシステムを守る能力を評価するためのテスト手法です。主な目的は、データの機密性、完全性、可用性を保護すること、およびシステムのセキュリティポリシーや要件を確認することです。

■主な特徴

1. システムやアプリケーションの脆弱性を特定します。
2. 不正アクセス、データ漏洩、サービスの妨害などの潜在的な攻撃を模倣してシステムの反応を評価します。
3. セキュリティポリシーやプロセスの効果性を確認します。

■例

仕様： あるオンラインバンキングウェブサイトがあり、ユーザーは口座の情報を閲覧し、送金や支払いを行うことができます。

セキュリティテスト：

1. SQLインジェクション：入力フォームに特定のSQLクエリを入力することで、データベースに不正アクセスできるかどうかを試します。
2. クロスサイトスクリプティング：ウェブページに不正なスクリプトを埋め込むことができるかどうかをテストします。
3. セッションハイジャック：ユーザーのセッションを盗み取ることができるかを確認します。
4. DDoS攻撃：サーバーに大量のリクエストを送信してサービスを停止させることができるかを試します。
5. 不正アクセス：パスワードの強度を確認するためのブルートフォース攻撃や、ユーザーの認証情報が漏洩していないかをチェックします。
6. 暗号化の評価：データ転送中やデータベース内での情報の暗号化が適切に行われているかを確認します。

このセキュリティテストを通じて、オンラインバンキングウェブサイトの潜在的な脆弱性やセキュリティ上の欠陥を特定し、それらの問題を修正するための対策を立てることができます。

ユーザビリティテスト

製品、サービス、またはシステムがエンドユーザーにとってどれほど使いやすく効果的であるかを評価するためのテスト手法です。このテストの主な目的は、ユーザーの経験や満足度を向上させるための潜在的な問題や改善点を特定することです。

■主な特徴

1. 実際のユーザーまたは代表的なユーザーを対象とする。
2. タスクベースのシナリオや特定のゴールを持つテストが行われる。
3. ユーザーの行動や反応、感想などを観察し、データを収集する。
4. ユーザビリティの問題点や改善の提案がまとめられる。

■例

仕様： 新しいモバイルアプリのプロトタイプがあり、このアプリを使ってユーザーが商品を検索し、カートに追加し、購入するプロセスを完了することができる。

ユーザビリティテスト：

1. 参加者の選択：様々な年齢層や技術的なバックグラウンドを持つ10人のユーザーを選択。
2. テストシナリオ：ユーザーには「特定の商品を検索し、カートに追加し、購入プロセスを完了する」というタスクを依頼。
3. 観察：テスト中、ユーザーの動きや迷い、問題点、フィードバックを観察し、記録。
4. フィードバックの収集：テスト後、ユーザーからアプリの使用感や問題点、提案などのフィードバックを収集。
5. 結果の分析：観察やフィードバックから、アプリのユーザビリティに関する問題点や改善提案をまとめる。

このユーザビリティテストを通じて、アプリの使用中にユーザーが経験する問題点や不便さを特定し、より使いやすい製品を設計・開発するための情報を得ることができます。

リグレッションテスト

既存のソフトウェアの機能に変更や修正を加えた後、新しいバグが発生していないか、既存の機能が正常に動作しているかを確認するためのテスト手法です。主な目的は、新しいコードの変更がソフトウェアの既存部分に悪影響を及ぼしていないことを確認することです。