ソフトウェアテストの種類

原寸大の図を開く ↗

ソフトウェアテストの種類

機能テスト

機能テストでは、ブラックボックス技法や仕様に基づくテストケースをよく用い、ソフトウェアが顧客の要件を満たすか確認します。次の確認が役立ちます。

1. アプリケーションが何をするべきかを正確に把握します。
2. 有効な入力と無効な入力を含む適切なテストデータを用意します。
3. 入力データに対する出力を機能仕様と照合します。
4. 必要なシナリオを網羅し、最も重大なリスクを優先します。考えられるすべてのシナリオを試すのは、通常は現実的ではありません。
5. 入力ごとに実際の結果を記録し、期待される出力と比較します。

さまざまなテストレベルで、また変更後に、機能を確認します。

1. 単体テスト
2. 結合テスト
3. システムテスト
4. 回帰テスト
5. 受け入れテスト

非機能テスト

性能、セキュリティ、ユーザーインターフェースの品質は、重要な非機能要件です。非機能テストは、こうした特性を確認します。主な種類は次のとおりです。

1. 性能テスト
2. ユーザビリティテスト
3. セキュリティテスト
4. 移植性テスト

ユーザビリティテスト

ユーザビリティテストでは、ソフトウェアの使いやすさを確認します。このブラックボックス手法では、便利か、操作できるか、使い方を学べるかという三つの点を確認します。ユーザビリティには次の側面があります。

• 初めてシステムを使うとき、どれだけ容易に慣れるか。
• 利用者が作業を効率よく、どれだけ速く終えられるか。
• 長い間使っていなかったシステムを、どれだけ容易に再び使えるか。
• エラーに遭遇するか、遭遇した場合にどれだけ容易に作業を再開できるか。
• 利用者が体験に満足するか。

ユーザビリティテストは、品質と使いやすさに対する信頼を高めます。顧客の満足につながり、費用に見合う効果が得られるよう、丁寧に計画しましょう。テスト中に不規則な操作を試すと、通常のテストが見落とす欠陥が見つかることがあります。

グラフィカルユーザーインターフェースのテスト

グラフィカルユーザーインターフェース（GUI）のテストでは、インターフェースが正しく動作し、定められた品質基準を満たすかを確認します。次の要素を調べます。

• レイアウト
• 色
• フォント
• 文字サイズ
• ラベル
• テキストボックスの機能
• テキストの書式
• キャプション
• ボタン
• リスト
• アイコン
• リンク
• コンテンツ
• ショートカットキー
• 処理中に表示される砂時計などの処理インジケーター

GUIテストは、担当者に適した方法で手動でも自動でも行えます。自社の開発チームやテストチームに代わり、外部組織が行う場合もあります。

グラフィカルユーザーインターフェース以外のテスト

GUIはアプリケーションの見た目と操作感を決めます。GUI以外のテストでは、コマンドラインインターフェース、バッチ処理、ユースケースを起動するイベントなど、視覚的な画面以外のやりとりを扱います。

移植性テスト

移植性テストでは、環境の変更がソフトウェアの動作や性能にどう影響するかを確認します。例えば、アプリケーションを異なるOSで試したり、ウェブアプリケーションを異なるブラウザーで試したりします。顧客が複数のプラットフォームを使う場合に重要です。

移植性テストはシステムテストの一部です。ソフトウェアを複数の環境にインストールするか、異なるプラットフォームで実行ファイルをビルドして実行します。設計と開発の段階から移植性の要件を考慮します。結合テスト後に、適切な環境で実施します。

セキュリティ、認証、認可のテスト

セキュリティテストは弱点を探し、必要に応じて顧客の機密情報を保護できるか確認します。認証と認可は、特に重要な領域です。

認証は、アプリケーションにアクセスしようとする人が本人かを確かめます。ユーザー名とパスワードを使う方法が一例です。組み合わせが違う場合は本人であることを確認できないため、アクセスを拒否します。

認可は、制限されたデータ、機能、ユースケースへのアクセスを制御します。認証に成功しても、すべてにアクセスできるわけではありません。例えば、ソーシャルメディアにサインインすると自分のアカウント情報を見られます。他人のアカウントは引き続き保護されます。

セキュリティテストには、機密性、完全性、可用性、否認防止、データの安全性、SQLインジェクション、クロスサイトスクリプティング（XSS）などの課題も含まれます。独立した専門分野です。

データとデータベースの完全性テスト

データ完全性テストは、保存されたデータが正確で、期待どおりの結果になるかを確認します。空のデータを取得できるか、保存前にデータを検証するか、保存したデータを更新できるか、必要なデータファイルの種類がテスト対象に含まれるかを確認します。目的は、ライフサイクル全体でデータの正確さと一貫性を保つことです。

データベース完全性テストは、データベースへのアクセスやデータの管理、処理に用いる方法と手順を確認します。データが破損したり、意図せず作成、更新、削除されたりしてはいけません。それぞれの条件を確認するテストケースを用意します。

耐障害性テストとフェイルオーバーテスト

耐障害性テストでは、実際の条件で障害が起きたときにアプリケーションがどう反応するかを確認します。ネットワーク接続エラー、アプリケーションサーバーへの接続問題、データベースへの接続障害などを想定します。

フェイルオーバーテストは、ハードウェア障害やクラッシュなどの重大な障害後に、システムが待機中のコンポーネントやサービスに切り替わるかを確認します。切り替え中に重要な処理を継続できるかも確かめます。その後、復旧テストで元のサービスが期待どおりの状態に戻るかを確認できます。

構成テストとデプロイテスト

構成テストは、システムの構成が異なるときの性能を確認します。テスト環境での応答時間と、期待される性能を達成するために必要な構成を調べます。新しい環境やハードウェア仕様との互換性を確認し、別のプラットフォームへの移行にも役立ちます。

デプロイテストは、デプロイしたシステムが正しく動くかを確認します。動作の遅さやクラッシュがないか調べ、実際の条件での動作と、予定したフォルダーに正しく配置されたことを確かめます。

回帰テスト

見つかった欠陥は修正を依頼します。修正で元の問題が解消されたことを確認します。次に回帰テストを行い、変更箇所、アプリケーションの別の部分、または業務ロジックに望ましくない影響がないか調べます。結果をもとに、次のテスト段階へ進めるかを判断します。

性能テスト

性能テストは、ネットワークの遅延、データの描画、データベースのトランザクション処理、サーバー間の負荷分散を調べます。個々の機能の欠陥に限らず、性能上の問題に注目します。安定性、拡張性、速度、応答時間、データの描画を評価するために使います。

負荷テストと性能ベンチマーク

負荷テストでは、最大負荷やピーク負荷でのソフトウェアの動作を確認します。JMeter、LoadRunner、Silk Performer などのツールは仮想ユーザーを作成し、スクリプトを実行して同時アクセスを再現します。テスト担当者は仮想ユーザー数を調整し、システムの挙動を観察します。

ストレステスト

ストレステストでは、意図的に通常と異なる条件を作り、性能を観察します。許容範囲を超える負荷をかけたり、資源を減らしたりして、障害が起こる点を調べます。例えば、データベースの停止と再起動、ネットワークポートの無作為な閉鎖や再起動、大量の資源を消費するプロセスの実行などです。

Testing Type	Unit Testing	Integration Testing	System Testing	Acceptance Testing
Functional Testing	Yes	Yes	Yes	Yes
Configuration Testing	No	No	Yes	Yes
User Interface Testing	No	No	Yes	Yes
Usability Testing	No	No	Yes	Yes
Installation Testing	No	No	Yes	Yes
Document Testing	Yes	Yes	Yes	Yes
Performance Testing	Yes	Yes	Yes	Yes
Security Testing	No	Yes	Yes	Yes
Scalability Testing	No	Yes	Yes	No

原寸大の図を開く ↗

ソフトウェアテストの種類のまとめ