ソフトウェアテストの種類 (100 例)
トーマス・ハミルトン
ソフトウェアテストタイプとは何ですか?
ソフトウェア テスト タイプは、さまざまなテスト活動をカテゴリに分類したもので、それぞれに定義されたテスト目的、テスト戦略、およびテスト成果物があります。 テスト タイプを設定する目的は、定義されたテスト目的に対してテスト対象アプリケーション (AUT) を検証することです。
たとえば、アクセシビリティ テストの目的は、障害のある人が AUT にアクセスできることを検証することです。 したがって、ソフトウェア ソリューションを無効化に対応する必要がある場合は、アクセシビリティ テスト ケースと照らし合わせてチェックします。
ソフトウェアテストの種類
の一覧 100種類のソフトウェアテスト 定義も一緒に。 QA プロフェッショナルにとって必読の書です。 これは、すべての種類のソフトウェア テストに関するガイドであると考えてください。
- 受け入れ試験： システムが受け入れ基準を満たしているかどうかを判断し、顧客がシステムを受け入れるかどうかを決定できるようにするために実施される正式なテスト。 通常、お客様が実行します。 続きを読む 受け入れ試験
- アクセシビリティテスト: 障害のある人 (聴覚障害者、視覚障害者、精神障害者など) に対する製品の使いやすさを判断するテストの種類。 評価プロセスは障害のある人によって行われます。 続きを読む アクセシビリティテスト
- アクティブなテスト: テストデータを導入し、実行結果を分析するテストの種類。 通常、テスト チームによって実施されます。
- アジャイルテスト: アジャイルマニフェストの原則に従い、システムを利用する顧客の視点からのテストを重視したソフトウェアテストの実践。 通常、これは QA チームによって実行されます。 続きを読む アジャイルテスト
- 年齢検査: 将来のシステムの実行能力を評価するテストの種類。 評価プロセスはテスト チームによって実行されます。
- アドホック テスト: 計画や文書化を行わずに実行されるテスト – テスターはシステムの機能をランダムに試してシステムを「破壊」しようとします。 これはテストチームによって実行されます。 続きを読む アドホックテスト
- アルファテスト： アルファテストは、製品をベータテスト用にリリースする前に、バグ、ユーザビリティの問題、機能のギャップを特定するために開発者のサイトで実施されるソフトウェアテストの一種です。開発者やQAチームなどの社内テスターが関与し、場合によっては制御された環境でエンドユーザーを選抜します。詳細はこちら アルファテスト
- アサーションテスト: 条件が製品要件を確認しているかどうかを検証するテストの種類。 これはテストチームによって実行されます。
- APIテスト： コードレベルを対象とするという点で単体テストに似たテスト手法。 API テストは、通常、開発者のタスクではなく QA タスクであるという点で単体テストとは異なります。 続きを読む APIテスト
- 全ペアテスト: 入力パラメータの可能なすべての離散的な組み合わせをテストする組み合わせテスト方法。 これはテストチームによって実行されます。
- 自動テスト: 自動テスト ツールを使用して環境のセットアップ、テストの実行、結果レポートを制御するテスト手法。 これはコンピュータによって実行され、テスト チーム内で使用されます。 続きを読む 自動テスト
- 基礎パスのテスト: 手順設計の論理的複雑さの尺度を導き出し、これを実行パスの基本セットを定義するためのガイドとして使用するテストメカニズム。テストチームがテストケースを定義するときに使用します。詳細はこちら 基底パスのテスト
- 下位互換性テスト: 開発したソフトウェアの動作を古いバージョンのテスト環境で検証するテスト方法。 これはテストチームによって実行されます。
- ベータテスト： 商用目的でアプリケーションをリリースする前の最終テスト。 通常、これはエンドユーザーまたは他のユーザーによって行われます。
- ベンチマークテスト: 特定の構成におけるコンピューターのハードウェアとソフトウェアのパフォーマンスを評価するために設計された、代表的なプログラムとデータのセットを使用するテスト手法。 これはテストチームによって実行されます。 続きを読む ベンチマークテスト
- ビッグバン統合テスト: すべての準備が整った場合にのみ、個々のプログラム モジュールを統合するテスト手法。 これはテストチームによって実行されます。
- バイナリ移植性テスト: 実行可能アプリケーションのシステム プラットフォームおよび環境間での移植性 (通常は ABI 仕様への適合性) をテストする手法。 これはテストチームによって実行されます。
- 境界値テスト: 境界値の代表を含むようにテストを設計するソフトウェア テスト手法。 これは QA テスト チームによって実行されます。 続きを読む 境界値テスト
- ボトムアップ統合テスト: ボトムアップ統合テストでは、最下位レベルのモジュールが最初に開発され、「メイン」プログラムに向かう他のモジュールが一度に XNUMX つずつ統合およびテストされます。 通常、これはテスト チームによって実行されます。
- ブランチテスト: プログラムのソース コード内のすべての分岐を少なくとも XNUMX 回テストするテスト手法。 これは開発者によって行われます。
- 範囲テスト: 製品の完全な機能を実行しますが、機能の詳細はテストしないテスト スイート。 これはテストチームによって実行されます。
- ブラックボックステスト: アプリケーションのコードや内部構造に関する特別な知識がなくても、アプリケーションの機能を検証するソフトウェア テストの方法。 テストは要件と機能に基づいて行われます。 これは QA チームによって実行されます。 続きを読む ブラックボックステスト
- コード駆動型テスト: テスト フレームワーク (xUnit など) を使用するテスト手法。単体テストを実行して、コードのさまざまなセクションがさまざまな状況下で期待どおりに動作するかどうかを判断できます。 それは開発チームによって実行されます。
- 互換性テスト: 特定のハードウェア/ソフトウェア/オペレーティングシステム/ネットワーク環境でソフトウェアがどの程度うまく機能するかを検証するテスト手法。テストチームによって実行されます。詳細はこちら 互換性テスト
- 比較テスト: 製品の長所と短所を以前のバージョンや他の類似製品と比較するテスト手法。テスター、開発者、製品マネージャー、または製品所有者が実行できます。詳細はこちら コンポーネントテスト
- コンポーネントのテスト: 単体テストに似たテスト手法ですが、より高いレベルの統合が行われます。テストは、特定のメソッドを直接テストするだけではなく、アプリケーションのコンテキストで実行されます。 テストまたは開発チームが実行できます。
- 構成テスト: ハードウェアとソフトウェアの最小かつ最適な構成、およびメモリ、ディスク ドライブ、CPU などのリソースの追加または変更の影響を判断するテスト手法。 通常、これはパフォーマンス テスト エンジニアによって実行されます。 続きを読む 構成テスト
- 条件範囲テスト: 各条件を true および false にすることで、それぞれの方法で少なくとも XNUMX 回実行するソフトウェア テストのタイプ。 通常、これは自動テスト チームによって作成されます。
- コンプライアンステスト： システムが標準、手順、ガイドラインに従って開発されたかどうかを確認するテストの種類。 通常、これは「認定 OGC 準拠」ブランドを提供する外部企業によって実行されます。
- 同時実行テスト: 同じアプリケーション コード、モジュール、またはデータベース レコードにアクセスした場合の影響を判断することを目的としたマルチユーザー テスト。 通常、これはパフォーマンス エンジニアによって行われます。 続きを読む 同時実行テスト
- 適合性テスト: 実装がそのベースとなる仕様に準拠していることをテストするプロセス。 通常、テスト チームによって実行されます。 続きを読む 適合性テスト
- コンテキスト駆動型テスト: 明らかになった潜在的な情報と、特定の瞬間における組織にとってのその情報の価値を考慮して、テスト機会を継続的かつ創造的に評価することを推奨するアジャイル テスト手法。 通常、これはアジャイル テスト チームによって実行されます。
- 変換テスト: 代替システムで使用するために既存のシステムからデータを変換するために使用されるプログラムまたは手順のテスト。 通常、これは QA チームによって実行されます。
- 意思決定カバレッジのテスト: 各条件/決定を true/false に設定することで実行するソフトウェア テストのタイプ。 通常、これは自動化テスト チームによって作成されます。
- 破壊試験: さまざまな荷重下での試験片の構造性能や材料の挙動を理解するために、試験片が破壊されるまで試験を実行する試験の種類。 通常、これは QA チームによって実行されます。
続きを読む 破壊試験 - 依存関係のテスト: 適切な機能を維持するために、既存のソフトウェア、初期状態、構成に対するアプリケーションの要件を検査するテスト タイプ。 通常、テスト チームによって実行されます。
- 動的テスト: コードの動的な動作のテストを説明するためにソフトウェア エンジニアリングで使用される用語。 通常、これはテスト チームによって実行されます。 続きを読む 動的テスト
- ドメインのテスト: プログラムが有効な入力のみを受け入れるかどうかのチェックを含むホワイト ボックス テスト手法。通常はソフトウェア開発チームによって実行されますが、場合によっては自動テスト チームによっても実行されます。
- エラー処理テスト: システムがエラーのあるトランザクションを適切に処理できるかどうかを判定するソフトウェア テストの種類。通常はテスト チームによって実行されます。
- エンドツーエンドのテスト: システム テストと同様に、データベースとの対話、ネットワーク通信の使用、または必要に応じて他のハードウェア、アプリケーション、またはシステムとの対話など、実際の使用を模倣した状況で完全なアプリケーション環境をテストすることが含まれます。 これは QA チームによって実行されます。 続きを読む エンドツーエンドのテスト
- 耐久試験: 長時間の実行で発生する可能性のあるメモリ リークやその他の問題をチェックするテストの種類。 通常、これはパフォーマンス エンジニアによって実行されます。 続きを読む 耐久試験
- 探索的テスト: ブラックボックステスト手法は、計画や文書化なしで実行されます。通常は手動テスト担当者によって実行されます。詳しくは 探索的テスト
- 等価分割テスト: ソフトウェア ユニットの入力データをデータのパーティションに分割し、そこからテスト ケースを導き出すソフトウェア テスト手法。 通常、QA チームによって実行されます。 続きを読む 等価分割テスト
- フォールト挿入テスト: テスターがテスト対象のアプリケーションが例外を処理できる方法に集中できるようにする、包括的なテスト戦略の要素。 これは QA チームによって実行されます。
- 正式な検証テスト: 数学の形式的手法を使用して、特定の形式仕様またはプロパティに関して、システムの基礎となる意図されたアルゴリズムの正しさを証明または反証する行為。通常は QA チームによって実行されます。
- 機能テスト テスト対象のソフトウェアコンポーネントの仕様に基づいてテストケースを作成するブラックボックステストの一種。テストチームによって実行されます。詳細はこちら 機能テスト
- ファズテスト: 無効なデータ、予期しないデータ、またはランダムなデータをプログラムの入力に提供するソフトウェア テスト手法。突然変異テストの特別な領域です。 ファズテストはテストチームによって実行されます。 続きを読む ファジングテスト
- ゴリラのテスト: 特定の XNUMX つのモジュールのテストに重点を置くソフトウェア テスト手法。 通常、完全なテストを実行するときに、品質保証チームによって実行されます。
- グレー Box テスト： ブラックの組み合わせ Box と白 Box テスト方法: 仕様に照らしてソフトウェアをテストしますが、その内部動作に関する知識を使用します。 これは、開発チームまたはテスト チームのいずれかが実行できます。
- ガラスボックステスト: ホワイト ボックス テストに似ていますが、アプリケーション コードの内部ロジックに関する知識に基づいています。開発チームによって実行されます。
- GUI ソフトウェアのテスト: グラフィカル ユーザー インターフェイスを使用する製品をテストし、書面に記載された仕様を満たしていることを確認するプロセス。 これは通常、テスト チームによって行われます。 続きを読む GUIソフトウェアのテスト
- グローバリゼーションテスト: 可能なあらゆる種類の国際入力を使用して、任意の文化/ロケール設定で製品の適切な機能をチェックするテスト方法。 これはテストチームによって実行されます。 続きを読む グローバリゼーションテスト
- ハイブリッド統合テスト: この種のテストの利点を活用するために、トップダウンとボトムアップの統合手法を組み合わせたテスト手法。 通常、これはテスト チームによって実行されます。
- 統合テスト: ソフトウェア テストのフェーズ。個々のソフトウェア モジュールを組み合わせてグループとしてテストします。 通常、テスト チームによって実施されます。 続きを読む 統合テスト
- インターフェイスのテスト: システムまたはコンポーネントが相互にデータと制御を正しく受け渡すかどうかを評価するために実施されるテスト。 通常、これはテスト チームと開発チームの両方によって実行されます。 続きを読む インターフェイステスト
- インストール/アンインストールのテスト: 新しいソフトウェアを正常にインストールしてセットアップするために顧客が行う必要がある作業に重点を置いた品質保証作業。これには、完全、部分的、またはアップグレードのインストール/アンインストール プロセスが含まれる場合があり、通常はソフトウェア テスト エンジニアが構成マネージャーと協力して行います。
- 国際化テスト: さまざまな言語やロケールで使用した場合でも、製品の機能が壊れず、すべてのメッセージが適切に外部化されることを保証するプロセス。 通常、これはテスト チームによって実行されます。
- システム間テスト: アプリケーション間の相互接続が正しく機能しているかどうかを確認することに重点を置いたテスト手法。通常はテスト チームによって実行されます。
- キーワード主導のテスト: テーブル駆動テストまたはアクションワード テストとも呼ばれる、自動テストのためのソフトウェア テスト方法論であり、テスト作成プロセスを計画段階と実装段階の XNUMX つの異なる段階に分割します。 手動または自動のテスト チームが使用できます。 続きを読む キーワード主導のテスト
- 負荷テスト: システムまたはデバイスに要求を与え、その応答を測定するテスト手法。 通常、これはパフォーマンス エンジニアによって実施されます。 続きを読む 負荷テスト
- ローカリゼーションテスト: ソフトウェア テスト プロセスの一部は、グローバル化されたアプリケーションを特定の文化/ロケールに適応させることに重点を置いています。 通常、これはテスト チームによって行われます。 続きを読む ローカリゼーションテスト
- ループテスト: プログラムループを実行するホワイトボックステスト手法。開発チームによって実行されます。詳しくはこちら ループテスト
- 手動によるスクリプト化されたテスト: テストケースを設計し、実行前にチームでレビューするテスト方法。 これは手動テスト チームによって行われます。
- 手動サポートテスト: データを準備し、自動システムからのデータを使用しながら、人が実行するすべての機能をテストするテスト手法。 それはテストチームによって実施されます。
- モデルベースのテスト: ソフトウェアテストを実行するために必要なアーティファクトを設計および実行するためのモデルベースの設計のアプリケーション。 通常、テスト チームによって実行されます。 続きを読む モデルベースのテスト
- 突然変異テスト: 通常のテスト実行中にほとんど、またはまったくアクセスされないコードのセクションをテストするために、プログラムのソース コードまたはバイト コードを少し変更することを含むソフトウェア テストの方法。 通常、テストはテスターによって行われます。 続きを読む 突然変異テスト
- モジュール性主導のテスト: テスト対象のアプリケーションのモジュール、セクション、機能を表す小さな独立したスクリプトの作成を必要とするソフトウェア テスト手法。 通常、これはテスト チームによって実行されます。
- 非機能テスト: ソフトウェア アプリケーションの非機能要件のテストに焦点を当てたテスト手法。 パフォーマンス エンジニアまたは手動テスト チームが実施できます。 続きを読む 非機能テスト
- 陰性検査: 「失敗テスト」とも呼ばれるテスト方法で、コンポーネントまたはシステムが動作しないことを示すことを目的としたテスト方法です。手動または自動テスト担当者によって実行されます。詳しくはこちら 陰性検査
- Opera試験: システムまたはコンポーネントを運用環境で評価するために実施されるテスト手法。通常はテストチームによって実行されます。詳細はこちら Opera試験
- 直交配列テスト: ユーザー インターフェイス テスト、システム テスト、回帰テスト、構成テスト、パフォーマンス テストに適用できる、体系的で統計的なテスト方法。 これはテストチームによって実行されます。 続きを読む 直交配列テスト
- ペアテスト: XNUMX 人のチーム メンバーが XNUMX つのキーボードで協力してソフトウェア アプリケーションをテストするソフトウェア開発手法。 XNUMX 人はテストを実行し、もう XNUMX 人はテストを分析またはレビューします。 これは、XNUMX 人のテスターと開発者またはビジネス アナリストの間で行うことも、XNUMX 人のテスターの間で両方の参加者が交代でキーボードを操作して行うこともできます。
- パッシブテスト: 特別なテスト データを導入せずに、実行中のシステムの結果を監視するテスト手法。 これはテストチームによって実行されます。
- 並列テスト: 古いバージョンを置き換える新しいアプリケーションがインストールされ、正しく実行されていることを確認することを目的としたテスト手法。 これはテストチームによって実施されます。 続きを読む 並列テスト
- パステスト: プログラムの各論理パスのカバレッジ基準を満たすことを目的とした典型的なホワイトボックステスト。通常は開発チームによって実行されます。詳しくはこちら パステスト
- ペネトレーションテスト： 悪意のあるソースからの攻撃をシミュレートすることによって、コンピュータ システムまたはネットワークのセキュリティを評価するテスト方法。 通常、侵入テストは専門の会社によって実施されます。 続きを読む 侵入テスト
- 性能試験： システムまたはコンポーネントが指定されたパフォーマンス要件に準拠しているかを評価するために実施される機能テスト。 通常、これはパフォーマンス エンジニアによって実施されます。 続きを読む 性能試験
- 資格試験: 以前のリリースの仕様に対するテスト。通常、ソフトウェアが指定された要件を満たしていることを実証するために、開発者によって消費者向けに実施されます。
- Ramp テスト： システムが故障するまで入力信号を継続的に発生させるテストのタイプ。 これは、テスト チームまたはパフォーマンス エンジニアによって実行される場合があります。
- 回帰試験： プログラムに変更 (バグ修正や新機能など) を加えた後、プログラムを再テストすることでソフトウェア エラーを発見しようとするソフトウェア テストの種類。 これはテストチームによって実行されます。 続きを読む 回帰テスト
- 回復テスト： システムがクラッシュ、ハードウェア障害、またはその他の致命的な問題からどの程度回復するかを評価するテスト手法。 これはテストチームによって実行されます。 続きを読む 回復テスト
- 要件のテスト: 要件が正しく、完全で、明確で、論理的に一貫していることを検証し、それらの要件から必要かつ十分なテスト ケースのセットを設計できるようにするテスト手法。 これは QA チームによって実行されます。
- セキュリティテスト： 情報システムがデータを保護し、意図したとおりの機能を維持しているかどうかを判断するプロセス。 これは、テスト チームまたは専門のセキュリティ テスト会社によって実行できます。 続きを読む セキュリティテスト
- 健全性テスト: 新しいソフトウェア バージョンが大規模なテスト作業に使用できるほど十分にパフォーマンスが優れているかどうかを判断するテスト手法。 これはテストチームによって実行されます。 続きを読む 健全性テスト
- シナリオのテスト: 架空のストーリーに基づいたシナリオを使用して、テスト環境の複雑な問題やシステムをじっくり考えるためのテスト活動。テストチームによって実行されます。詳細はこちら シナリオのテスト
- スケーラビリティテスト: 一連の非機能テストの一部。サポートされるユーザー負荷、トランザクション数、データ量などのスケールアップ能力を測定するためにソフトウェア アプリケーションをテストします。これはパフォーマンス エンジニアによって実施されます。 続きを読む スケーラビリティテスト
- ステートメントのテスト: プログラムテスト中にプログラム内の各ステートメントが少なくとも 1 回実行されるという基準を満たすホワイト ボックス テスト。通常は開発チームによって実行されます。
- 静的テスト: ソフトウェアが実際に使用されないソフトウェア テストの形式で、主にコード、アルゴリズム、ドキュメントの健全性がチェックされます。 コードを作成した開発者によって使用されます。 続きを読む 静的テスト
- 安定性試験: アプリケーションがクラッシュするかどうかを判断しようとするテスト手法。 通常、これはパフォーマンス エンジニアによって実施されます。 続きを読む 安定性試験
- 煙試験: ソフトウェア システムのすべての基本コンポーネントを検査して、それらが適切に動作することを確認するテスト手法。 通常、スモーク テストは、ソフトウェアのビルドが行われた直後に、テスト チームによって実施されます。 続きを読む スモークテスト
- ストレージテスト: テスト対象のプログラムがデータ ファイルを正しいディレクトリに保存していること、および領域不足による予期しない終了を防ぐために十分な領域が確保されていることを検証するテスト タイプ。 通常、これはテスト チームによって実行されます。 続きを読む ストレージテスト
- ストレステスト: システムまたはコンポーネントを、指定された要件の制限内またはそれを超えて評価するテスト手法。 通常、これはパフォーマンス エンジニアによって実施されます。 続きを読む ストレステスト
- 構造試験: システムまたはコンポーネントの内部構造を考慮し、各プログラム ステートメントが意図した機能を実行することを確認するホワイト ボックス テスト手法。通常はソフトウェア開発者によって実行されます。
- システムテスト: 統合されたハードウェアおよびソフトウェア システムをテストして、システムが指定された要件を満たしていることを確認するプロセス。 これは、開発環境とターゲット環境の両方でテスト チームによって実施されます。 続きを読む システムテスト
- システム統合テスト: ソフトウェア システムが他のシステムと共存できるかどうかをテストするテスト プロセス。 通常、これはテスト チームによって実行されます。 続きを読む システム統合テスト
- トップダウンの統合テスト: ユーザー インターフェイスのシステム階層の最上位から開始し、システム全体が実装されるまでスタブを使用して上から下にテストするテスト手法。 これはテストチームによって実施されます。
- スレッドのテスト: トップダウン テスト手法のバリエーション。要件のサブセットの実装に続いてコンポーネントを段階的に統合します。 通常、これはテスト チームによって実行されます。 続きを読む スレッドのテスト
- Upgrade テスト： 古いバージョンで作成されたアセットが適切に使用でき、ユーザーの学習に支障がないことを検証するテスト手法。 これはテストチームによって実行されます。
- 単体テスト： プログラマーがソース コードの個々のユニットが使用に適しているかどうかをテストする、ソフトウェアの検証および検証方法。 通常、これは開発チームによって実施されます。 続きを読む 単体テスト
- ユーザーインターフェイスのテスト: アプリケーションの使いやすさを確認するために実行されるテストの種類。 これはテストチームによって実行されます。 続きを読む ユーザーインターフェイスのテスト
ボーナス!!! いくつかの追加情報を知っておくことは常に良いことです
- ユーザビリティテスト： ユーザーがシステムまたはコンポーネントの操作、入力の準備、出力の解釈を習得しやすくなるかどうかを検証するテスト手法。通常はエンドユーザーが実行します。詳細はこちら ユーザビリティテスト
- ボリュームテスト: 時間の経過とともに大きくなる可能性のある値（累積カウント、ログ、データ ファイルなど）がプログラムで処理可能であり、プログラムの動作が停止したり、動作が何らかの形で低下したりしないことを確認するテストです。通常はパフォーマンス エンジニアによって実施されます。詳しくは、 ボリュームテスト
- 脆弱性テスト: アプリケーションのセキュリティに関連し、アプリケーションの完全性と安定性に影響を与える可能性のある問題を防止することを目的としたテストの種類。 社内のテストチームが実行することも、専門会社に委託することもできます。 続きを読む 脆弱性テスト
- ホワイトボックステスト: アプリケーションのコードの内部ロジックの知識に基づくテスト手法。コード ステートメント、分岐、パス、条件のカバレッジなどのテストが含まれます。 それはソフトウェア開発者によって実行されます。 続きを読む ホワイトボックステスト
- ワークフローのテスト: エンドユーザーが利用すると予想される特定のワークフローを複製する、スクリプト化されたエンドツーエンドのテスト手法。 通常、テスト チームによって実施されます。 続きを読む ワークフローのテスト
これでリストは終わりです。読んで楽しんでいただけたでしょうか。このタイプのテストやその他のテストに適したツールを見つけるには、このコレクションをご覧ください。 テストツール.
