types software testing
ソフトウェアテストの種類は何ですか?
テスターとして、機能テスト、非機能テスト、自動化テスト、アジャイルテスト、およびそれらのサブタイプなど、さまざまなタイプのソフトウェアテストを認識しています。
私たち一人一人は、私たちのテストの旅の中でいくつかのタイプのテストに出くわしたでしょう。聞いたことがあるかもしれませんし、取り組んだこともあるかもしれませんが、すべてのテストタイプについてすべての人が知っているわけではありません。
各タイプのテストには、独自の機能、長所、および短所もあります。ただし、この記事では、日常のテストで通常使用するすべての種類のソフトウェアテストについて説明しました。
行って見てみましょう。
学習内容:
- さまざまな種類のソフトウェアテスト
- #1)アルファテスト
- #2)検収試験
- #3)アドホックテスト
- #4)アクセシビリティテスト
- #5)ベータテスト
- #6)バックエンドテスト
- #7)ブラウザの互換性テスト
- #8)下位互換性テスト
- #9)ブラックボックステスト
- #10)境界値テスト
- #11)ブランチテスト
- #12)比較テスト
- #13)互換性テスト
- #14)コンポーネントテスト
- #15)エンドツーエンドのテスト
- #16)等価パーティショニング
- #17)テスト例
- #18)探索的テスト
- #20)機能テスト
- #21)グラフィカルユーザーインターフェイス(GUI)テスト
- #22)ゴリラテスト
- #23)ハッピーパステスト
- #24)インクリメンタル統合テスト
- #25)テストのインストール/アンインストール
- #26)統合テスト
- #27)負荷テスト
- #28)モンキーテスト
- #29)ミューテーションテスト
- #30)ネガティブテスト
- #31)非機能テスト
- #32)パフォーマンステスト
- #33)回復テスト
- #34)回帰テスト
- #35)リスクベーステスト(RBT)
- #36)健全性テスト
- #37)セキュリティテスト
- #38)スモークテスト
- #39)静的テスト
- #40)ストレステスト
- #41)システムテスト
- #42)ユニットテスト
- #43)ユーザビリティテスト
- #44)脆弱性テスト
- #45)ボリュームテスト
- #46)ホワイトボックステスト
- 結論
- 推奨読書
さまざまな種類のソフトウェアテスト
以下に、ソフトウェアテストの一般的なタイプのリストを示します。
機能テストの種類は次のとおりです。
- ユニットテスト
- 統合テスト
- システムテスト
- 健全性テスト
- スモークテスト
- インターフェイステスト
- 回帰試験
- ベータ/検収試験
機能しないテストの種類は次のとおりです。
- 性能試験
- 負荷テスト
- ストレステスト
- ボリュームテスト
- セキュリティテスト
- 互換性テスト
- テストのインストール
- 回復テスト
- 信頼性テスト
- ユーザビリティテスト
- コンプライアンステスト
- ローカリゼーションテスト
これらのテストタイプの詳細を見てみましょう。

#1)アルファテスト
これは、ソフトウェア業界で使用される最も一般的なタイプのテストです。このテストの目的は、市場またはユーザーにリリースする前に、考えられるすべての問題または欠陥を特定することです。
アルファテストは、ソフトウェア開発フェーズの最後で、ベータテストの前に実行されます。それでも、そのようなテストの結果として、マイナーな設計変更が行われる可能性があります。
アルファテスト 開発者のサイトで実施されます。このタイプのテスト用に、社内の仮想ユーザー環境を作成できます。
#2)検収試験
アン 検収試験 クライアントによって実行され、システムのフローのエンドツーエンドがビジネス要件に従っているかどうか、およびエンドユーザーのニーズに従っているかどうかを確認します。クライアントは、すべての機能が期待どおりに機能する場合にのみソフトウェアを受け入れます。
これはテストの最後のフェーズであり、その後ソフトウェアが本番環境に移行します。これは、ユーザー受け入れテスト(UAT)とも呼ばれます。
#3)アドホックテスト
名前自体は、このテストが実行されることを示唆しています アドホック 根拠、つまり、テストケースへの参照がなく、そのようなタイプのテストのための計画や文書もありません。
このテストの目的は、アプリケーションのフローまたはランダムな機能を実行することにより、欠陥を見つけてアプリケーションを破壊することです。
アドホックテストは、欠陥を見つけるための非公式な方法であり、プロジェクトの誰でも実行できます。テストケースなしで欠陥を特定することは困難ですが、アドホックテスト中に見つかった欠陥が既存のテストケースを使用して特定されなかった可能性があります。
#4)アクセシビリティテスト
の目的 アクセシビリティテスト ソフトウェアまたはアプリケーションが障害者にアクセス可能かどうかを判断することです。
ここで、障害とは、聴覚障害、色覚異常、精神障害、視覚障害、老年およびその他の障害者グループを意味します。視覚障害者のフォントサイズ、色覚異常の色とコントラストなど、さまざまなチェックが実行されます。
#5)ベータテスト
ベータテスト は、お客様が実施する正式なタイプのソフトウェアテストです。それはで実行されます 実環境 実際のエンドユーザー向けに製品を市場にリリースする前に。
ベータテストは、ソフトウェアまたは製品に大きな障害がなく、エンドユーザーの観点からビジネス要件を満たしていることを確認するために実行されます。ベータテストは、顧客がソフトウェアを受け入れると成功します。
通常、このテストは通常、エンドユーザーまたは他のユーザーによって実行されます。これは、商用目的でアプリケーションをリリースする前に行われる最終テストです。通常、リリースされるソフトウェアまたは製品のベータ版は、特定の地域の特定の数のユーザーに制限されています。
したがって、エンドユーザーは実際にソフトウェアを使用し、フィードバックを会社に共有します。その後、会社はソフトウェアを世界中にリリースする前に必要な措置を講じます。
#6)バックエンドテスト
入力またはデータがフロントエンドアプリケーションに入力されると、データベースに保存され、そのようなデータベースのテストはデータベーステストまたはバックエンドテストと呼ばれます。
SQL Server、MySQL、Oracleなどのさまざまなデータベースがあります。データベーステストには、テーブル構造、スキーマ、ストアドプロシージャ、データ構造などのテストが含まれます。
バックエンドテストGUIは関与せず、テスターは適切なアクセスでデータベースに直接接続され、テスターはデータベースでいくつかのクエリを実行することでデータを簡単に検証できます。
このバックエンドテスト中に、データ損失、デッドロック、データ破損などの問題が特定される可能性があります。これらの問題は、システムが本番環境に移行する前に修正するために重要です。
#7)ブラウザの互換性テスト
これは互換性テストのサブタイプであり(以下で説明します)、テストチームによって実行されます。
ブラウザの互換性テスト はWebアプリケーションに対して実行され、ソフトウェアが異なるブラウザとオペレーティングシステムの組み合わせで実行できることを保証します。このタイプのテストでは、Webアプリケーションがすべてのブラウザのすべてのバージョンで実行されるかどうかも検証されます。
#8)下位互換性テスト
これは、新しく開発されたソフトウェアまたは更新されたソフトウェアが古いバージョンの環境で適切に機能するかどうかを検証するテストの一種です。
下位互換性テストでは、新しいバージョンのソフトウェアが、古いバージョンのソフトウェアで作成されたファイル形式で正しく機能するかどうかを確認します。また、そのソフトウェアの古いバージョンで作成されたデータテーブル、データファイル、データ構造でもうまく機能します。
ソフトウェアのいずれかが更新された場合、そのソフトウェアの以前のバージョンの上でうまく機能するはずです。
#9)ブラックボックステスト
このタイプのテストでは、内部システム設計は考慮されません。テストは、要件と機能に基づいています。
長所、短所、およびに関する詳細情報 ブラックボックステストの種類 見られます ここに 。
#10)境界値テスト
このタイプのテストは、境界レベルでアプリケーションの動作をチェックします。
境界値テスト 境界値に欠陥が存在するかどうかをチェックするために実行されます。境界値テストは、さまざまな範囲の数値をテストするために使用されます。各範囲には上限と下限があり、これらの境界値に対してテストが実行されます。
テストに1から500までの数値のテスト範囲が必要な場合、境界値テストは0、1、2、499、500、および501の値に対して実行されます。
#11)ブランチテスト
これはホワイトボックステストの一種であり、ユニットテスト中に実行されます。ブランチテスト、名前自体は、コードがすべてのブランチでトラバースすることによって徹底的にテストされることを示唆しています。
#12)比較テスト
製品の長所と短所を以前のバージョンまたは他の同様の製品と比較することを、比較テストと呼びます。
#13)互換性テスト
これは、ソフトウェアがさまざまな環境、Webサーバー、ハードウェア、およびネットワーク環境でどのように動作および実行されるかを検証するテストタイプです。
互換性テスト ソフトウェアが異なる構成、異なるデータベース、異なるブラウザー、およびそれらのバージョンで実行できることを保証します。互換性テストは、テストチームによって実行されます。
#14)コンポーネントテスト
これは主に、単体テストの完了後に開発者によって実行されます。 コンポーネントテスト 複数の機能を単一のコードとしてテストすることを含み、その目的は、それらの複数の機能を相互に接続した後に欠陥が存在するかどうかを識別することです。
#15)エンドツーエンドのテスト
システムテストと同様に、 エンドツーエンドのテスト データベースとの対話、ネットワーク通信の使用、または必要に応じて他のハードウェア、アプリケーション、またはシステムとの対話など、実際の使用を模倣する状況での完全なアプリケーション環境のテストが含まれます。
#16)等価パーティショニング
これはテスト手法であり、ブラックボックステストの一種です。この間 等価分割 、グループのセットが選択され、テストのためにいくつかの値または数値が取得されます。そのグループのすべての値が同じ出力を生成することが理解されます。
このテストの目的は、同じ出力を生成するが欠陥は生成しない特定のグループ内の冗長なテストケースを削除することです。
アプリケーションが-10から+10までの値を受け入れると仮定すると、等価分割を使用して、テスト用に取得された値はゼロ、1つの正の値、1つの負の値になります。したがって、このテストの等価パーティション化は-10から-1、0、および1から10です。
#17)テスト例
これは、リアルタイムのテストを意味します。テストの例には、リアルタイムシナリオが含まれます。また、テスターの経験に基づくシナリオも含まれます。
#18)探索的テスト
探索的テストは、テストチームによって実行される非公式のテストです。このテストの目的は、アプリケーションを調査し、アプリケーションに存在する欠陥を探すことです。
このテスト中に発見された重大な欠陥がシステム障害を引き起こすことさえある場合があります。
探索的テスト中は、テストしたフローと、特定のフローの開始前に実行したアクティビティを追跡することをお勧めします。
探索的テスト手法 ドキュメントやテストケースなしで実行されます。
#20)機能テスト
このタイプのテストでは、内部パーツを無視し、出力のみに焦点を当てて、要件どおりかどうかを確認します。これは、アプリケーションの機能要件に合わせたブラックボックスタイプのテストです。機能テストの詳細については、をクリックしてください ここに 。
#21)グラフィカルユーザーインターフェイス(GUI)テスト
このGUIテストの目的は、ビジネス要件に従ってGUIを検証することです。アプリケーションの予想されるGUIは、詳細設計ドキュメントとGUIモックアップ画面に記載されています。
GUIテストには、画面に表示されるボタンと入力フィールドのサイズ、すべてのテキスト、テーブル、およびテーブル内のコンテンツの配置が含まれます。
また、アプリケーションのメニューを検証し、さまざまなメニューおよびメニュー項目を選択した後、ページが変動せず、メニューまたはサブメニューにマウスを置いた後も配置が同じままであることを検証します。
#22)ゴリラテスト
Gorilla Testingは、テスターによって実行されるテストタイプであり、開発者によって実行されることもあります。 Gorilla Testingでは、1つのモジュールまたはモジュール内の機能が徹底的かつ徹底的にテストされます。このテストの目的は、アプリケーションの堅牢性を確認することです。
#23)ハッピーパステスト
Happy Path Testingの目的は、ポジティブフローでアプリケーションを正常にテストすることです。ネガティブまたはエラー状態を検索しません。焦点は、アプリケーションが期待される出力を生成するための有効で正の入力のみにあります。
#24)インクリメンタル統合テスト
インクリメンタル統合テスト は、テストのためのボトムアップアプローチです。つまり、新しい機能が追加されたときのアプリケーションの継続的テストです。アプリケーションの機能とモジュールは、個別にテストできるように十分に独立している必要があります。これは、プログラマーまたはテスターによって行われます。
#25)テストのインストール/アンインストール
インストールとアンインストールのテスト さまざまなハードウェアまたはソフトウェア環境のさまざまなオペレーティングシステムで、完全、部分的、またはアップグレードのインストール/アンインストールプロセスで実行されます。
#26)統合テスト
統合後の結合された機能を検証するためのすべての統合モジュールのテストは、次のように呼ばれます。 統合テスト 。
モジュールは通常、コードモジュール、個々のアプリケーション、ネットワーク上のクライアントおよびサーバーアプリケーションなどです。このタイプのテストは、クライアント/サーバーおよび分散システムに特に関係があります。
#27)負荷テスト
これは非機能テストの一種であり、負荷テストの目的は、パフォーマンスを低下させることなくシステムが処理できる負荷または最大ワークロードの量を確認することです。
負荷テストは 特定の負荷およびソフトウェアパフォーマンスの低下を引き起こす問題の下でのシステムの最大容量を見つけるため。負荷テストは、次のようなツールを使用して実行されます JMeter 、LoadRunner、WebLoad、Silkパフォーマーなど。
#28)モンキーテスト
モンキーテスト サルがアプリケーションを使用する場合、どのようにランダムな入力であるかを想定してテスターによって実行されます。値は、アプリケーションの知識や理解なしにサルによって入力されます。
Monkey Testingの目的は、ランダムな入力値/データを提供することにより、アプリケーションまたはシステムがクラッシュするかどうかを確認することです。モンキーテストはランダムに実行され、テストケースはスクリプト化されておらず、実行する必要はありません。
最高の無料の音楽ダウンローダーアプリは何ですか
モンキーテストはランダムに実行され、テストケースはスクリプト化されておらず、システムの全機能を認識する必要はありません。
#29)ミューテーションテスト
ミューテーションテスト は、プログラムの1つのソースコードが変更され、既存のテストケースがシステムのこれらの欠陥を識別できるかどうかを検証するホワイトボックステストの一種です。
プログラムのソースコードの変更はごくわずかであるため、アプリケーション全体に影響を与えることはありません。影響を与える特定の領域と関連するテストケースのみが、システム内のこれらのエラーを識別できるはずです。
#30)ネガティブテスト
「壊れる態度」の考え方を持ち、ネガティブテストを使用するテスターは、システムまたはアプリケーションが壊れた場合にそれを検証します。 ネガティブテスト手法 不正なデータ、無効なデータ、または入力を使用して実行されます。システムが無効な入力のエラーをスローし、期待どおりに動作するかどうかを検証します。
#31)非機能テスト
これは、通常、非機能テスト(NFT)チームまたはパフォーマンスチームと呼ばれる個別のチームを持つすべての組織のテストの一種です。
非機能テスト 負荷テスト、ストレステスト、セキュリティ、ボリューム、リカバリテストなどの非機能要件のテストが含まれます。NFTテストの目的は、ソフトウェアまたはアプリケーションの応答時間がビジネス要件に従って十分に速いかどうかを確認することです。
ページやシステムの読み込みにそれほど時間はかからず、読み込みのピーク時にも持続するはずです。
#32)パフォーマンステスト
この用語は、「ストレス」および「負荷」テストと同じ意味で使用されることがよくあります。 性能試験 システムがパフォーマンス要件を満たしているかどうかを確認するために行われます。このテストには、さまざまなパフォーマンスツールとロードツールが使用されます。
#33)回復テスト
これは、アプリケーションまたはシステムがクラッシュや災害からどの程度回復するかを検証するテストの一種です。
回復テストは、システムが災害後も運用を継続できるかどうかを判断します。アプリケーションがネットワークケーブルを介してデータを受信していて、突然ネットワークケーブルが抜かれたと仮定します。
しばらくしてから、ネットワークケーブルを接続します。次に、システムは、ネットワークケーブルが抜かれたために接続が失われた場所からデータの受信を開始する必要があります。
#34)回帰テスト
モジュールまたは機能の変更についてアプリケーション全体をテストすることを、回帰テストと呼びます。すべてのシステムをカバーすることは困難です 回帰試験 、通常は 自動化テストツール これらのタイプのテストに使用されます。
#35)リスクベーステスト(RBT)
に リスクベーステスト 、機能または要件は、それらの優先順位に基づいてテストされます。リスクベーステストには、ビジネスに最も大きな影響を与え、障害の可能性が非常に高い、非常に重要な機能のテストが含まれます。
優先度の決定はビジネスニーズに基づいているため、すべての機能に優先度を設定すると、優先度の高い機能またはテストケースが最初に実行され、次に優先度の高い機能が実行されます。
優先度の低い機能は、利用可能な時間に基づいてテストされる場合とされない場合があります。
リスクベーステストは、ソフトウェア全体をテストするのに十分な時間がなく、ソフトウェアを遅滞なく時間どおりに実装する必要がある場合に実行されます。このアプローチの後には、クライアントと組織の上級管理職の話し合いと承認のみが続きます。
#36)健全性テスト
健全性テスト 新しいソフトウェアバージョンが、主要なテスト作業でそれを受け入れるのに十分なパフォーマンスを発揮しているかどうかを判断するために行われます。アプリケーションが最初の使用のためにクラッシュしている場合、システムはさらにテストするのに十分なほど安定していません。したがって、ビルドまたはアプリケーションが割り当てられて修正されます。
#37)セキュリティテスト
これは、特別なテスターチームによって実行されるテストの一種です。システムは、あらゆるハッキング方法で侵入される可能性があります。
セキュリティテスト ソフトウェア、アプリケーション、またはWebサイトが内部および外部の脅威からどのように保護されているかを確認するために行われます。このテストには、悪意のあるプログラムやウイルスからどれだけのソフトウェアが安全であるか、および承認と認証のプロセスがどれだけ安全で強力であるかが含まれます。
また、ハッカーの攻撃や悪意のあるプログラムに対してソフトウェアがどのように動作するか、およびそのようなハッカーの攻撃後のデータセキュリティのためにソフトウェアがどのように維持されるかを確認します。
#38)スモークテスト
開発チームによって新しいビルドが提供されるたびに、ソフトウェアテストチームはビルドを検証し、大きな問題が存在しないことを確認します。
テストチームは、ビルドが安定していることを確認し、詳細なレベルのテストをさらに実行します。 スモークテスト ビルドにショーストッパーの欠陥がないことを確認します。これにより、テストチームはアプリケーションを詳細にテストできなくなります。
テスターが主要な重要な機能が初期段階で壊れていることに気付いた場合、テストチームはビルドを拒否し、それに応じて開発チームに通知することができます。スモークテストは、機能テストまたは回帰テストの詳細レベルで実行されます。
#39)静的テスト
静的テストは、コードなしで実行されるテストの一種です。実行は、テスト段階でドキュメントに対して実行されます。
これには、プロジェクトの成果物のレビュー、ウォークスルー、および検査が含まれます。静的テストでは、コード構文の代わりにコードが実行されず、命名規則がチェックされます。
静的テスト テストケース、テスト計画、設計ドキュメントにも適用できます。このタイプのテスト中に特定された欠陥はプロジェクトの観点から費用効果が高いため、テストチームによる静的テストを実行する必要があります。
#40)ストレステスト
このテストは、システムが仕様を超えてストレスを受けたときに、いつどのように障害が発生するかを確認するために実行されます。これは、ストレージ容量を超える多数の書き込み、複雑なデータベースクエリ、システムへの継続的な入力、またはデータベースの負荷などの重い負荷の下で実行されます。
#41)システムテスト
下 システムテスト手法 、システム全体が要件に従ってテストされます。これは、全体的な要件仕様に基づいており、システムのすべての組み合わせ部分をカバーするブラックボックスタイプのテストです。
#42)ユニットテスト
個々のソフトウェアコンポーネントまたはモジュールのテストは、次のように呼ばれます。 ユニットテスト 。内部プログラムの設計とコードに関する詳細な知識が必要なため、通常はテスターではなくプログラマーが行います。また、テストドライバーモジュールまたはテストハーネスの開発が必要になる場合もあります。
#43)ユーザビリティテスト
下 ユーザビリティテスト 、使いやすさチェックを行います。アプリケーションフローは、新しいユーザーがアプリケーションを簡単に理解できるかどうかを知るためにテストされます。ユーザーがどこかで行き詰まった場合の適切なヘルプが文書化されています。基本的に、このテストではシステムナビゲーションがチェックされます。
#44)脆弱性テスト
ソフトウェア、ハードウェア、およびネットワークの弱点を特定することを含むテストは、脆弱性テストとして知られています。悪意のあるプログラムであるハッカーは、そのような種類の攻撃、ウイルス、およびワームに対して脆弱である場合、システムを制御する可能性があります。
そのため、これらのシステムが本番環境の前に脆弱性テストを受けているかどうかを確認する必要があります。重大な欠陥、セキュリティの欠陥を特定する場合があります。
#45)ボリュームテスト
ボリュームテスト は、パフォーマンステストチームによって実行される非機能テストの一種です。
ソフトウェアまたはアプリケーションは大量のデータを受け取り、ボリュームテストは、システムがそのような大量のデータに遭遇したときのシステムの動作とアプリケーションの応答時間をチェックします。この大量のデータは、システムのパフォーマンスと処理時間の速度に影響を与える可能性があります。
#46)ホワイトボックステスト
ホワイトボックステスト アプリケーションのコードの内部ロジックに関する知識に基づいています。
ガラスボックステストとも呼ばれます。このタイプのテストを実行するには、内部ソフトウェアとコードの動作を知っておく必要があります。これらのテストでは、コードステートメント、ブランチ、パス、条件などの範囲に基づいています。
結論
上記のソフトウェアテストタイプは、テストの一部にすぎません。ただし、100を超えるタイプのテストのリストはまだありますが、すべてのタイプのプロジェクトですべてのテストタイプが使用されているわけではありません。そこで、テストのライフサイクルで主に使用されるいくつかの一般的なタイプのソフトウェアテストについて説明しました。
また、さまざまな組織で使用される代替の定義またはプロセスがありますが、基本的な概念はどこでも同じです。これらのテストの種類、プロセス、およびそれらの実装方法は、プロジェクト、要件、およびスコープが変更されると、変更され続けます。
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- アルファテストとベータテスト(完全ガイド)
- ソフトウェアテストQAアシスタントジョブ
- ソフトウェアテストコース:どのソフトウェアテスト機関に参加する必要がありますか?
- キャリアとしてのソフトウェアテストの選択
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- ソフトウェアプロジェクトにおけるリスクの種類
- SoftwareTestingHelpの最高のQAソフトウェアテストサービス