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

の世界へようこそ ソフトウェアテスト の品質と信頼性を保証します。 ソフトウェアアプリケーション 。さまざまな種類のソフトウェアテストを理解することは、開発者と品質保証の専門家にとって同様に不可欠です。

このガイドでは、単体テストからセキュリティテストまで、ソフトウェアテストの基本的なカテゴリについて説明し、ソフトウェアが最高のパフォーマンスと機能の基準を満たしていることを確認してナビゲートするのに役立ちます。

ソフトウェアテストの原則
さまざまな種類のソフトウェアテスト
手動テストの種類
ブラックボックステストの種類
機能テストの種類
結合テストの種類
非機能テストの種類
他の種類のテスト
ソフトウェアテストの利点
ソフトウェアテストの欠点
練習用の質問
ソフトウェアテストの種類に関するよくある質問

ソフトウェアテストの原則

すべてのテストは顧客の要件を満たしている必要があります。
ソフトウェアのテストを行うには、第三者によるテストが必要です。
徹底的なテストは不可能です。アプリケーションのリスク評価に基づいて最適な量のテストが必要であるためです。
実施するすべてのテストは、実装する前に計画する必要があります
これは、エラーの 80% がプログラムコンポーネントの 20% から発生するというパレートの法則 (80/20 の法則) に従います。
小さな部品からテストを開始し、大きな部品に拡張します。
テストの種類

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

さまざまな種類のソフトウェアテスト

手動テスト
自動化テスト

1. 手動テスト

手動テスト アプリケーションの機能や特徴を使用して実行されるソフトウェアをテストする手法です。手動ソフトウェアテストでは、テスターは事前に定義された一連のテストケースに従ってソフトウェアのテストを実行します。このテストでは、テスターはコードのテストケースを作成し、ソフトウェアをテストし、そのソフトウェアに関する最終レポートを作成します。手動テストは人間が行うため時間がかかり、人的ミスが発生する可能性があります。

手動テストの利点

迅速かつ正確な視覚的フィードバック: ソフトウェアアプリケーションのほぼすべてのバグを検出し、レイアウトやテキストなど、動的に変化する GUI デザインをテストするために使用されます。
より安価な： 高度なスキルや特定の種類のツールを必要としないため、コストが安くなります。
コーディングは必要ありません。 ブラックボックステスト方法を使用する場合、プログラミングの知識は必要ありません。新しいテスターにとっても簡単に学ぶことができます。
計画外の変更に対して効率的: 手動テストは簡単に導入できるため、アプリケーションに計画外の変更が加えられた場合に適しています。

2. 自動化テスト

自動テスト テスターが独自にスクリプトを作成し、適切なソフトウェアまたは自動化ツールを使用してソフトウェアをテストする手法です。これは手動プロセスの自動化プロセスです。これにより、手動テスターの介入なしで反復的なタスクを実行できます。

自動テストの利点:

テストケースの実行を簡素化します。 自動化テストは事実上無人で行うことができるため、プロセスの最後に結果を監視できます。したがって、全体的なテストの実行が簡素化され、アプリケーションの効率が向上します。
テストの信頼性の向上: 自動テストにより、テストのすべての領域に均等に焦点が当てられるため、最高品質の最終製品が保証されます。
テスト範囲の増加: 自動テストを使用すると、テスト対象のアプリケーションに対してより多くのテストケースを作成して実行できます。したがって、テストのカバレッジが向上し、より多くのバグが検出されます。これにより、より複雑なアプリケーションのテストが可能になり、より多くの機能をテストできます。
人間の介入を最小限に抑える: 自動テストでは、テストケースの作成から実行まですべてが自動化されるため、放置による人的ミスによる変更はありません。これにより、リリース後の段階で不具合を修正する必要性が減ります。

手動テストの種類

ホワイトボックステスト
ブラックボックステスト
グレーボックステスト

1. ホワイトボックステスト

ホワイトボックステスト この技術は、ブラックボックステストのような機能だけでなく、使用されているデータ構造、内部設計、コード構造、およびソフトウェアの動作を分析します。ガラスボックス試験、クリアボックス試験、構造試験とも呼ばれます。ホワイトボックステストは、透過的テストまたはオープンボックステストとも呼ばれます。

ホワイトボックステストは、ソフトウェアアプリケーションの内部構造と動作をテストするソフトウェアテスト手法です。テスターはソースコードにアクセスでき、この知識を使用して、コードレベルでソフトウェアの正しさを検証できるテストケースを設計します。

ホワイトボックステストの利点:

徹底したテスト : ホワイトボックステストは、コード全体と構造全体がテストされるため、徹底的です。
コードの最適化: これにより、コードが最適化されてエラーが削除され、余分なコード行を削除するのに役立ちます。
欠陥の早期検出: ブラックボックステストの場合のようにインターフェイスを必要としないため、より早い段階で開始できます。
SDLC との統合: ホワイトボックステストは、ソフトウェア開発ライフサイクルで簡単に開始できます。
複雑な欠陥の検出: テスターは、他のテスト手法では検出できない欠陥を特定できます。

2. ブラックボックステスト

ブラックボックステストは、テスターがソフトウェアの内部知識や実装の詳細には関心がなく、提供された仕様や要件に基づいて機能を検証することに重点を置くソフトウェアテストの一種です。

ブラックボックステストの利点:

テスターは、ブラックボックステストを実装するために、それ以上の機能的な知識やプログラミングスキルを持っている必要はありません。
大規模なシステムでテストを実装する場合に効率的です。
テストはユーザーまたはクライアントの観点から実行されます。
テストケースは簡単に再現できます。
機能仕様のあいまいさや矛盾を見つけるために使用されます。

3. グレーボックステスト

グレーボックステスト を組み合わせたソフトウェアテスト手法です。ブラックボックステストテクニックとホワイトボックステスト技術。

ブラックボックステスト手法では、テスターはテスト対象のアイテムの内部構造を知りませんが、ホワイトボックステストでは内部構造がテスターに知られています。
内部構造は、Gray Box Testing で部分的に判明しています。
これには、テストケースを設計するための内部データ構造とアルゴリズムへのアクセスが含まれます。

グレーボックステストの利点:

目標の明確さ: ユーザーと開発者はテストを行う際に明確な目標を持っています。
ユーザーの観点から次のことを行います。 グレーボックステストは主にユーザーの観点から行われます。
高度なプログラミングスキルは必要ありません: このテストでは、テスターに高度なプログラミングスキルは必要ありません。
非侵入型: グレーボックステストは非侵入的です。
製品品質の向上: 製品の全体的な品質が向上します。

ブラックボックステストの種類

機能テスト
非機能テスト

1. 機能テスト

機能テストは、システムが機能要件と仕様に照らしてテストされるソフトウェアテストの一種です。機能テストでは、アプリケーションが要件または仕様を適切に満たしていることを確認します。このタイプのテストは、特に処理の結果に関係します。実際のシステム使用状況のシミュレーションに重点を置いていますが、システム構造の仮定は作成しません。この記事では、機能テストについて説明することに重点を置いています。

機能テストの利点

バグのない製品: 機能テストにより、バグのない高品質の製品が確実に提供されます。
顧客満足： すべての要件が満たされていることを確認し、顧客が満足していることを確認します。
仕様に重点を置いたテスト: 機能テストは、顧客の使用状況に応じた仕様に焦点を当てています。
アプリケーションの適切な動作: これにより、アプリケーションが期待どおりに動作し、アプリケーションのすべての機能が適切に動作することが保証されます。
製品の品質が向上します。 機能テストは製品の安心・安全を確保し、製品の品質を向上させます。

2. 非機能テスト

非機能テスト の一種ですソフトウェアテストこれは、アプリケーションの非機能要件を検証するために実行されます。システムの動作が要件どおりであるかどうかを検証します。機能テストではテストされないすべての側面をテストします。非機能テストは、システムの非機能属性をチェックするソフトウェアテスト手法です。非機能テストは、ソフトウェアアプリケーションの非機能的な側面をチェックするソフトウェアテストの一種として定義されます。これは、機能テストでは決して対処されない非機能パラメータに従ってシステムの準備状況をテストするように設計されています。非機能テストは機能テストと同じくらい重要です。

非機能テストの利点

パフォーマンスを向上させた： 非機能テストでは、システムのパフォーマンスをチェックし、パフォーマンスに影響を与える可能性のあるパフォーマンスのボトルネックを特定します。
時間がかからない: 非機能テストは、他のテストプロセスよりも全体的に時間がかかりません。
ユーザーエクスペリエンスを向上させます: ユーザビリティテストなどの非機能テストでは、ソフトウェアがユーザーにとってどれだけ使いやすく、使いやすいかをチェックします。したがって、アプリケーションの全体的なユーザーエクスペリエンスを向上させることに重点を置きます。
より安全な製品: 非機能テストには、アプリケーションのセキュリティボトルネックと、内部および外部ソースからの攻撃に対してアプリケーションがどの程度安全であるかをチェックするセキュリティテストが特に含まれます。

機能テストの種類

単体テスト
統合テスト
システムテスト

1.単体テスト

単体テストソフトウェアアプリケーションの個々のユニットまたはコンポーネントをテストする方法です。これは通常、開発者によって行われ、ソフトウェアの個々のユニットが意図したとおりに動作していることを確認するために使用されます。単体テストは通常自動化されており、特定の関数やメソッドなど、コードの特定の部分をテストするように設計されています。単体テストは最下位レベルで行われます。ソフトウェア開発プロセスここでは、コードの個々のユニットが分離してテストされます。

単体テストの利点:

単体テストの利点のいくつかを以下に示します。

これは、修正がより困難になり、コストがかかるようになる前に、開発プロセスの早い段階でバグを特定するのに役立ちます。
これは、コードへの変更によって新たなバグが発生しないようにするのに役立ちます。
これにより、コードがよりモジュール化され、理解と保守が容易になります。
ソフトウェアの全体的な品質と信頼性の向上に役立ちます。

注記： 単体テストに使用される一般的なフレームワークとツールには、次のようなものがあります。 JUnit 、 NUユニット、 そして x単位。

単体テストはソフトウェアテストの 1 つの側面にすぎず、ソフトウェアがユーザーのニーズを満たしていることを確認するために、統合テスト、機能テスト、受け入れテストなどの他の種類のテストと組み合わせて使用する必要があることに留意することが重要です。。

ソフトウェア設計の最小単位に焦点を当てます。ここでは、個々のユニットまたは相互に関連するユニットのグループをテストします。多くの場合、これはプログラマがサンプル入力を使用し、それに対応する出力を観察することによって行われます。

例：

プログラムでは、ループ、メソッド、または関数が正常に動作しているかどうかをチェックしています。

誤解または不正確な算術優先順位。

初期化が正しくありません。

2. 結合テスト

結合テストソフトウェアアプリケーションのさまざまなユニットまたはコンポーネントがどのように相互作用するかをテストする方法です。これは、ソフトウェアの異なるユニットを組み合わせるときに発生する可能性のある問題を特定し、解決するために使用されます。統合テストは通常、単体テストの後、機能テストの前に行われ、ソフトウェアのさまざまなユニットが意図したとおりに連携して動作することを検証するために使用されます。

統合テストを実行するさまざまな方法:

統合テストのさまざまな方法については、以下で説明します。

トップダウンの統合テスト: 最上位のモジュールから開始して、それらを下位レベルのモジュールと区別します。
ボトムアップ統合テスト: 最下位レベルのモジュールから開始し、それらを上位レベルのモジュールと統合します。
ビッグバン統合テスト: すべてのモジュールを組み合わせて一度に統合します。
増分統合テスト: モジュールを小さなグループに統合し、追加される各グループをテストします。

統合テストの利点

これは、ソフトウェアの異なるユニットを組み合わせるときに発生する可能性のある問題を特定して解決するのに役立ちます。
これは、ソフトウェアのさまざまなユニットが意図したとおりに連携して動作することを確認するのに役立ちます。
これは、ソフトウェアの全体的な信頼性と安定性の向上に役立ちます。
さまざまなコンポーネントが統合されている複雑なシステムには、統合テストが不可欠であることに留意することが重要です。
単体テストと同様、統合テストはソフトウェアテストの 1 つの側面にすぎず、ソフトウェアがユーザーのニーズを満たしていることを確認するために、単体テスト、機能テスト、受け入れテストなどの他の種類のテストと組み合わせて使用する必要があります。

の 客観的 単体テストされたコンポーネントを取得し、設計によって指示されたプログラム構造を構築することです。統合テストは、コンポーネントのグループを組み合わせて出力を生成するテストです。

統合テストには 4 つのタイプがあります: (i) トップダウン (ii) ボトムアップ (iii) サンドイッチ (iv) ビッグバン

例：

ブラックボックステスト: 検証に使用されます。ここでは、内部の動作メカニズムを無視し、出力が何であるかに焦点を当てます。

ホワイトボックステスト: 検証に使用されます。ここでは、内部メカニズム、つまり出力がどのように達成されるかに焦点を当てます。

3. システムテスト

システムテストは、完全に統合されたソフトウェアソリューションの全体的な機能とパフォーマンスを評価するソフトウェアテストの一種です。システムが指定された要件を満たしているかどうか、またエンドユーザーへの配信に適しているかどうかをテストします。このタイプのテストは、統合テストの後、受け入れテストの前に実行されます。

システムテスト の一種ですソフトウェアテストこれは、システムが対応する要件に準拠しているかどうかを評価するために、完全に統合されたシステム上で実行されます。システムテストでは、統合テストに合格したコンポーネントが入力として取得されます。統合テストの目的は、統合されたユニット間の不規則性を検出することです。

システムテストの利点:

テスターは、このテストを実行するためにプログラミングの知識をさらに必要としません。
製品またはソフトウェア全体をテストするため、単体テストや結合テストでは特定できないエラーや欠陥を簡単に検出できます。
テスト環境は、リアルタイムの実稼働環境またはビジネス環境と似ています。
さまざまなテストスクリプトを使用してシステムの機能全体をチェックし、クライアントの技術要件とビジネス要件もカバーします。
このテストの後、製品は考えられるすべてのバグやエラーをほぼカバーするため、開発チームは自信を持って受け入れテストを続行します。

結合テストの種類

増分テスト
非増分テスト

1. 増分テスト

開発と同様に、テストも次のフェーズです。 SDLC (ソフトウェア開発ライフサイクル) 。開発サイクルのさまざまな段階でさまざまなテストが実行されます。インクリメンタルテストは、ソフトウェア分野のテスト段階で一般的に使用されるテストアプローチの 1 つです。統合テスト後に実行される単体テスト。いくつかのスタブとドライバーを使用してモジュールを 1 つずつテストし、特定のモジュールのエラーや欠陥を発見するのに役立ちます。

増分テストの利点

各モジュールには固有の重要性があります。それぞれが個別に増加するため、テスト中に果たすべき役割が与えられます。
欠陥は、エラーを示してから大きなファイルを編集して再修正するのではなく、より小さなモジュールで検出されます。
要件と範囲に応じて、より柔軟でコスト効率が高くなります。
顧客は各建物に対応する機会を得ることができます。

2種類あります増分テスト

トップダウンの統合テスト
ボトムアップ統合テスト

1. トップダウンの統合テスト

トップダウンテスト インクリメンタルの一種です統合テストアーキテクチャ構造の制御フローを上から下に移動することにより、2 つ以上のモジュールを統合または結合することによってテストが実行されるアプローチ。これらでは、最初に高レベルのモジュールがテストされ、次に低レベルのモジュールがテストされます。そして最後に、システムが適切に動作することを確認するために統合が行われます。このプロジェクトを実行するには、スタブとドライバーが使用されます。この手法は、下位レベルに統合されていないモジュールの動作を増加または刺激するために使用されます。

利点トップダウンの統合テスト

ドライバーを作成する必要はありません。
インターフェースのエラーは早い段階で特定され、障害の特定も容易になります。
重要ではない低レベルのユーティリティは十分にテストされませんが、高レベルのテスターは適切な方法で十分にテストされます。
入出力関数を追加すると、テストケースの表現がより簡単かつシンプルになります。

2. ボトムアップ結合テスト

ボトムアップテスト インクリメンタルの一種です統合テストアーキテクチャ構造の制御フローを通じて下から上に移動することにより、2 つ以上のモジュールを統合または結合することによってテストが実行されるアプローチ。これらでは、低レベルのモジュールが最初にテストされ、次に高レベルのモジュールがテストされます。このタイプのテストまたはアプローチは帰納的推論とも呼ばれ、多くの場合合成の同義語として使用されます。ボトムアップテストはユーザーフレンドリーなテストであり、ソフトウェア開発全体の増加につながります。このテストでは高い成功率が得られ、結果は長期間持続します。

ボトムアップ結合テストの利点

試験条件の作成と開発が簡単かつ簡単です。
テスト結果の観察も容易です。
構造設計の詳細を知る必要はありません。
低レベルのユーティリティも十分にテストされており、オブジェクト指向構造とも互換性があります。

非機能テストの種類

性能試験
ユーザビリティテスト
互換性テスト

1. パフォーマンステスト

性能試験 ソフトウェアテストの一種で、ソフトウェアアプリケーションが予想されるワークロードの下で適切に動作することを確認します。これは、特定のワークロード下での感度、反応性、安定性の観点からシステムのパフォーマンスを判断するために実行されるテスト手法です。

パフォーマンステストは、システムまたはアプリケーションのパフォーマンスとスケーラビリティの評価に焦点を当てたソフトウェアテストの一種です。パフォーマンステストの目的は、ボトルネックを特定し、さまざまな負荷や条件下でシステムパフォーマンスを測定し、システムが予想されるユーザー数またはトランザクション数を処理できることを確認することです。

パフォーマンステストの利点

パフォーマンステストでは、システムの速度、負荷能力、精度、その他のパフォーマンスを確認します。
問題が発生した場合は、問題を特定、監視し、解決します。
これにより、ソフトウェアが大幅に最適化され、多くのユーザーが同時にソフトウェアを使用できるようになります。
それはクライアントだけでなく最終顧客の満足も保証します。パフォーマンステストには、ソフトウェアテストの重要な側面となるいくつかの利点があります。
ボトルネックの特定 : パフォーマンステストは、データベースクエリの遅さ、メモリ不足、ネットワークの輻輳など、システムのボトルネックを特定するのに役立ちます。これは、開発者がシステムを最適化し、予想されるユーザー数またはトランザクション数を確実に処理できるようにするのに役立ちます。

2. ユーザビリティテスト

製品 (冷蔵庫など) を設計し、完全に準備が整ったら、潜在的な顧客にテストして動作を確認する必要があります。機械が市場に投入される準備ができているかどうかを理解するために、潜在的な顧客は機械をテストします。同様に、ユーザビリティテストの最良の例は、ソフトウェアが市場に投入される前に潜在的なユーザーによって実行されるさまざまなテストプロセスを受ける場合です。これはソフトウェア開発ライフサイクル (SDLC) の一部です。

ユーザビリティテストの長所と短所

ユーザビリティテストは、適切なユーザーを対象に製品やサービスをテストすることによって評価することが推奨されます。ユーザビリティテストでは、開発チームと設計チームがコーディング前に問題を特定するために使用します。その結果、問題が早期に解決されます。ユーザビリティテスト中にできることは、

参加者が特定のタスクを完全に完了できるかどうかを確認します。
特定のタスクを完了するまでにどれくらい時間がかかるかを特定します。
製品に優れた特徴と機能性を与える
ユーザーの満足度を向上させ、ユーザーのフィードバックに基づいて要件を満たします
製品はより効率的かつ効果的になります

3. 互換性テスト

互換性テストは、以下に該当するソフトウェアテストです。非機能テストカテゴリに分類され、さまざまなプラットフォーム/環境での互換性 (実行能力) をチェックするためにアプリケーション上で実行されます。このテストは、アプリケーションが安定した場合にのみ実行されます。これは、単にこの互換性テストが、さまざまなソフトウェア、ハードウェアプラットフォーム、ネットワークブラウザーなどで開発されたソフトウェアアプリケーションの機能をチェックすることを目的としているということを意味します。この互換性テストは、将来の互換性に関する問題を回避するために実行されるため、製品の製造および実装の観点から非常に重要です。

互換性テストの利点

顧客に完全な満足を保証します。
複数のプラットフォームにわたってサービスを提供します。
開発プロセス中にバグを特定します。

4種類あります性能試験

負荷テスト
ストレステスト
スケーラビリティテスト
安定性試験

1. 負荷テスト

負荷テストは、複数のユーザーが同時にアプリケーションを使用したときのアプリケーションの動作を決定します。これは、さまざまな負荷条件下で測定されたシステムの応答です。

負荷テストは、通常の負荷条件と極端な負荷条件で実行されます。
負荷テストは、システムまたはアプリケーションに対する実際の負荷をシミュレートして、ストレス下でどのように動作するかを確認するパフォーマンステストの一種です。
負荷テストの目的は、ボトルネックを特定し、システムが処理できるユーザーまたはトランザクションの最大数を決定することです。
これは、システムが予想される使用レベルに対応できることを確認し、システムを実稼働環境に導入する前に潜在的な問題を特定するのに役立つため、ソフトウェアテストの重要な側面です。

負荷テストの利点:

負荷テストには、ソフトウェアテストの重要な側面となるいくつかの利点があります。

ボトルネックの特定: 負荷テストは、データベースクエリの遅さ、メモリ不足、ネットワークの輻輳など、システムのボトルネックを特定するのに役立ちます。これは、開発者がシステムを最適化し、予想されるユーザー数またはトランザクション数を確実に処理できるようにするのに役立ちます。
スケーラビリティの向上: 負荷テストは、システムの最大容量を特定することで、時間の経過とともに増加するユーザーまたはトランザクションをシステムが処理できることを確認するのに役立ちます。これは、大量のトラフィックを処理することが予想される Web ベースのシステムおよびアプリケーションにとって特に重要です。
信頼性の向上: 負荷テストは、エラー率の増加や応答時間の遅さなど、高負荷条件下で発生する可能性のある潜在的な問題を特定するのに役立ちます。これにより、システムを運用環境に導入する際に、システムの信頼性と安定性を確保できます。

2. ストレステスト

でストレステスト、システムに不利な条件を与え、その条件下でシステムがどのように動作するかを確認します。

例：

最大のメモリまたはその他のリソースを必要とするテストケースが実行されます。

仮想オペレーティングシステムでスラッシングを引き起こす可能性のあるテストケース。

過剰なディスク要件を引き起こす可能性のあるテストケースのパフォーマンステスト。

これは、統合システムのコンテキスト内でソフトウェアの実行時のパフォーマンスをテストするように設計されています。プログラムの速度と有効性をテストするために使用されます。負荷テストとも呼ばれます。その中で、特定の負荷におけるシステムのパフォーマンスがどのようなものであるかを確認します。

例：

いくつかのプロセッササイクルをチェックしています。

3. スケーラビリティテスト

スケーラビリティテスト 非機能テストの一種で、ソフトウェアアプリケーション、システム、ネットワーク、またはプロセスのパフォーマンスを、ユーザーリクエストの負荷数やその他のパフォーマンス属性をスケールアップまたはスケールダウンする機能の観点からテストします。これは、ハードウェア、ソフトウェア、またはデータベースのレベルで実行できます。スケーラビリティテストは、増大するニーズを満たすためにシステムのサイズや容量が変更された場合に、ネットワーク、システム、アプリケーション、製品、またはプロセスが機能を正しく実行する能力として定義されます。これにより、ソフトウェア製品は、ユーザートラフィック、データ量、トランザクションカウントの頻度、その他多くの予定された増加を確実に管理できるようになります。増大するニーズを満たすシステム、プロセス、データベースの能力をテストします。

データ構造 Java

スケーラビリティテストの利点

これにより、製品へのアクセスが容易になります。
Web ページの読み込みに関する問題やその他のパフォーマンスの問題を検出します。
製品の問題を早期に発見して修正するため、時間を大幅に節約できます。
これにより、特定の負荷下でのエンドユーザーエクスペリエンスが保証されます。顧客満足を提供します。
ツールの効果的な使用状況を追跡するのに役立ちます。

4. 安定性試験

安定性試験 ソフトウェアテストの一種で、さまざまな環境パラメーターの下でソフトウェアの品質と動作をチェックします。これは、製品が長期間にわたって故障することなく機能し続ける能力として定義されます。

これは、ソフトウェアコンポーネントに最大限のストレスを与えることに焦点を当てた非機能テスト手法です。安定性テストは、ブレークポイントとして知られる通常の動作能力を超えた開発製品の効率をチェックするために行われます。これは、通常の状況でのシステムの動作をチェックすることよりも、高負荷時の製品のエラー処理、ソフトウェアの信頼性、堅牢性、スケーラビリティにおいてより重要性が高くなります。

安定性テストでは、安定性の問題を評価します。このテストは主に、アプリケーションが任意の時点でクラッシュするかどうかを確認することを目的としています。

安定性試験の利点

これは、システムが実際に処理できるデータの制限を示します。
これにより、システムのパフォーマンスに対する信頼が得られます。
これは、負荷時のシステムの安定性と堅牢性を決定します。
安定性テストは、エンドユーザーエクスペリエンスの向上につながります。

他の種類のテスト

煙試験
健全性テスト
回帰試験
受け入れ試験
ユーザー受け入れテスト
探索的テスト
アドホックテスト
セキュリティテスト
グローバリゼーションテスト
回帰試験
煙試験
アルファテスト
ベータテスト
オブジェクト指向テスト

1. 煙試験

煙試験テスト中のソフトウェアがさらなるテストの準備ができているか、安定していることを確認するために行われます。
初期パスのテストは、最初のスイッチオンで発火または発煙しなかったかどうかを確認するために行われるため、スモークテストと呼ばれます。

例：

If the project has 2 modules so before going to the module make sure that module 1 works properly.>

煙試験の利点

煙テストは簡単に実行できます。
初期段階で欠陥を特定するのに役立ちます。
システムの品質が向上します。
スモークテストにより、失敗のリスクが軽減されます。
スモークテストにより、進捗状況にアクセスしやすくなります。

2. 健全性テスト

それは サブセット の回帰試験。健全性テストは、行われたコード変更が適切に機能することを確認するために実行されます。サニティテストは、ビルドのテストが続行できるかどうかを確認するための停止です。健全性テストプロセス中のチームの焦点は、詳細なテストではなく、アプリケーションの機能を検証することです。健全性テストは通常、重大なバグ修正など、すぐに運用環境への展開が必要なビルドに対して実行されます。

健全性テストの利点

健全性テストは、コア機能の欠陥を迅速に特定するのに役立ちます。
健全性テストには文書が必要ないため、より短時間で実行できます。
健全性テスト中に欠陥が見つかった場合、プロジェクトは拒否されるため、回帰テストの実行時間を節約できます。
このテスト手法は、他のタイプのテストと比較すると、それほど高価ではありません。
これは、依存している欠落しているオブジェクトを特定するのに役立ちます。

3. 回帰テスト

コードの変更された部分と、変更によって影響を受ける可能性のある部分をテストするプロセスにより、変更が行われた後にソフトウェアに新たなエラーが導入されていないことが保証されます。回帰とは何かが戻ってくることを意味し、ソフトウェアの分野ではバグが戻ってくることを指します。

回帰テストの利点

これにより、システムに新しい機能を追加した後に新しいバグが導入されていないことが保証されます。
回帰テストで使用されるテストケースのほとんどは既存のテストスイートから選択されており、期待される出力はすでにわかっています。したがって、自動化ツールによって簡単に自動化できます。
ソースコードの品質を維持するのに役立ちます。

4. 受け入れテスト

受け入れ試験納品された製品が要件に記載されているように、希望のタスクを実行するかどうかを顧客が確認するために行われます。私たちは、テスト計画の議論とプロジェクトの実行にオブジェクト指向テストを使用します。

受け入れテストの利点

このテストは、テストにユーザーが関与するため、プロジェクトチームがユーザーのさらなる要件を直接知るのに役立ちます。
自動テスト実行。
クライアントはテストプロセスに直接関与するため、クライアントに自信と満足をもたらします。
ユーザーが自分の要件を説明しやすくなります。
ブラックボックステストプロセスのみをカバーしているため、製品の機能全体がテストされます。

5. ユーザー受け入れテスト

ユーザー受け入れテスト クライアント/エンドユーザーが製品テストに参加して、要件に対して製品を検証するテスト方法論です。これは、開発者のサイト上のクライアントのサイトで行われます。医療や航空宇宙などの業界では、契約および規制への準拠テスト、運用受け入れテストもユーザー受け入れテストの一環として実行されます。 UAT はコンテキスト依存であり、UAT 計画は要件に基づいて作成され、あらゆる種類のユーザー受け入れテストを実行する必要はなく、テストチームによって調整および提供されることもあります。

6. 探索的テスト

探索的テスト の一種ですソフトウェアテストこの場合、テスターはソフトウェアをテストするために考えられる方法を自由に選択できます。これは、ソフトウェアテストに対するスクリプトのないアプローチです。探索的テストでは、ソフトウェア開発者は学習、知識、スキル、能力を活用して、自分で開発したソフトウェアをテストします。探索的テストでは、ソフトウェアの機能と動作をチェックし、ソフトウェアの機能的および技術的欠陥を特定します。探索的テストは、あらゆる可能な方法でソフトウェアを最適化し、改善することを目的としています。

探索的テストの利点

必要な準備が少なくなります: スクリプトのないテスト手法であるため、準備は必要ありません。
重大な欠陥を見つけます: 探索的テストには、重大な欠陥を迅速に発見するのに役立つ調査プロセスが含まれます。
生産性の向上: 探索的テストでは、テスターは知識、スキル、経験を活用してソフトウェアをテストします。より多くのテストケースを実行することでテスターの想像力を広げることができ、ソフトウェアの全体的な品質が向上します。

7. アドホックテスト

アドホックテストは、正式なテストの完了後にシステムの抜け穴を見つけるために非公式かつランダムに実行されるソフトウェアテストの一種です。このため、ランダムテストまたはモンキーテストとも呼ばれます。アドホックテストは構造化された方法で実行されないため、方法論的なアプローチに基づいていません。そのため、アドホックテストは非構造化ソフトウェアテストの一種です。

アドホックテストの利点

書かれたテストケースでは特定できないエラーは、アドホックテストによって特定できます。
非常に限られた時間内で実行できます。
独自のテストケースの作成に役立ちます。
このテストは、将来的に問題が発生しにくい強力な製品を構築するのに役立ちます。
このテストは、期間中いつでも実行できます。ソフトウェア開発ライフサイクルプロセス (SDLC)

8. セキュリティテスト

セキュリティテスト の一種ですソフトウェアテストシステムの脆弱性を発見し、システムのデータとリソースが侵入者から保護されていることを確認します。これにより、ソフトウェアシステムとアプリケーションが損失を引き起こす可能性のある脅威やリスクから解放されることが保証されます。あらゆるシステムのセキュリティテストは、組織の情報や評判の損失につながる可能性のあるシステムのすべての抜け穴や弱点を見つけることに重点を置いています。

セキュリティテストの利点

脆弱性の特定: セキュリティテストは、脆弱なパスワード、パッチが適用されていないソフトウェア、誤って設定されたシステムなど、攻撃者によって悪用される可能性のあるシステムの脆弱性を特定するのに役立ちます。
システムのセキュリティの向上: セキュリティテストは、脆弱性と潜在的な脅威を特定して修正することで、システム全体のセキュリティを向上させるのに役立ちます。
コンプライアンスの確保: セキュリティテストは、システムが HIPAA、PCI DSS、SOC2 などの関連するセキュリティ標準および規制を満たしていることを確認するのに役立ちます。

9. グローバリゼーションテスト

グローバリゼーションテストは、システムまたはソフトウェアアプリケーションが地理的および文化的環境に関係なく機能できることを確認するために実行されるソフトウェアテストの一種です。これにより、アプリケーションが世界中で使用でき、すべての言語のテキストを受け入れることが保証されます。現在、さまざまなテクノロジーの進歩に伴い、すべてのソフトウェア製品はグローバル化されたソフトウェア製品となるように設計されています。

グローバリゼーションテストの利点

スケーラブルな製品の作成に役立ちます。 これにより、ソフトウェア製品の柔軟性と拡張性が向上します。
時間を節約する： ソフトウェアテストにかかる全体的な時間と労力が節約されます。
ローカリゼーションテストの時間を短縮します。 グローバリゼーションテストは、ローカリゼーションテストの時間とコストを削減するのに役立ちます。

10. 回帰テスト

回帰試験ソフトウェアに加えられた変更によって新しいバグが発生したり、既存の機能が壊れたりしないことを確認するために使用されるテスト方法です。これは通常、バグ修正や新機能などのコードに変更が加えられた後に行われ、ソフトウェアが引き続き意図したとおりに動作することを確認するために使用されます。

回帰テストは、次のようなさまざまな方法で実行できます。

再テスト : これには、変更の影響を受けるアプリケーション全体または特定の機能のテストが含まれます。
リ – 実行 : これには、以前に実行したテストスイートを実行して、変更によって既存の機能が損なわれていないことを確認することが含まれます。
比較 : これには、ソフトウェアの現在のバージョンと以前のバージョンを比較して、変更によって既存の機能が損なわれていないことを確認することが含まれます。

回帰テストの利点

これは、ソフトウェアに加えられた変更によって新しいバグが発生したり、既存の機能が壊れたりしないようにするのに役立ちます。
これは、変更が加えられた後もソフトウェアが意図したとおりに動作し続けることを確認するのに役立ちます。
これは、ソフトウェアの全体的な信頼性と安定性の向上に役立ちます。
回帰テストは継続的なプロセスであり、システム全体を通じて実行する必要があることに留意することが重要です。ソフトウェア開発
ソフトウェアが意図したとおりに動作し続けることを保証するライフサイクル。時間とリソースを節約するには、可能な限り自動化する必要があります。さらに、以下をカバーする明確に定義された回帰テストスイートを用意することが重要です。

新しいモジュールが追加されるたびに、プログラムが変更されます。このタイプのテストでは、完全なプログラムにコンポーネントを追加した後でも、コンポーネント全体が適切に動作することを確認します。

例：

学校の記録では、モジュールのスタッフ、生徒、財務担当者がこれらのモジュールを組み合わせ、回帰テストでこれらのモジュールの統合が正常に機能するかどうかをチェックしているとします。

11. 煙試験

例：

プロジェクトに 2 つのモジュールがある場合は、モジュールに進む前にモジュール 1 が適切に動作することを確認してください。

12. アルファテスト

アルファテスト検証テストの一種です。受け入れテストの一種ですこれは、製品が顧客にリリースされる前に行われます。通常、これは QA 担当者によって行われます。

例：

ソフトウェアのテストが組織内で実行される場合。

13. ベータテスト

のベータテストソフトウェアのエンドユーザーによって 1 つ以上の顧客サイトで実行されます。このバージョンは、リアルタイム環境でのテストを目的として、限られた数のユーザー向けにリリースされています。

例：

ソフトウェアテストを限られた人数で実施する場合。

14. オブジェクト指向テスト

オブジェクト指向テストテストは、オブジェクト指向ソフトウェアの検証と検証に役立つさまざまなテスト手法を組み合わせたものです。このテストは次の方法で行われます。

要件のテスト、
テストの設計と分析、
コードのテスト、
統合テスト、
システムテスト、
ユーザーテスト。

ソフトウェアテストの利点

ソフトウェアの品質と信頼性が向上しました。
欠陥の早期特定と修正。
顧客満足度の向上。
ステークホルダーの信頼の向上。
メンテナンスコストの削減。
顧客満足
費用対効果の高い
高品質の製品
低故障
バグのないアプリケーション
安全
開発プロセスのスピードアップ
欠陥の早期検出
信頼できる製品

ソフトウェアテストの欠点

時間がかかり、プロジェクトコストが増加します。
これにより、開発プロセスが遅くなる可能性があります。
すべての欠陥が見つかるわけではありません。
複雑なシステムを完全にテストするのは難しい場合があります。
テストプロセス中に人的ミスが発生する可能性。

練習用の質問

1. ソフトウェアテストに関して、1 つの接続コンポーネントを持つフローグラフ G を考えてみましょう。 G のエッジの数を E、ノードの数を N、述語ノードの数を P とします。次の 4 つの式を考えてみましょう。 [GATE IT -2006]

I.E-N+P
II. E-N+2
Ⅲ． P+2
IV. P+1

G の循環複雑性は次のように与えられます。

(A) ⅠまたはⅢ
(B) ⅡまたはⅢ
(C) IIまたはIV
(D) ⅠまたはⅣ

解決： 正解は (C)。