Software-testing-levels
ソフトウェアテスト-レベル
テストのプロセスにはさまざまなレベルがあります。 この章では、これらのレベルについて簡単に説明します。
テストのレベルには、ソフトウェアテストの実施中に使用できるさまざまな方法が含まれます。 ソフトウェアテストの主なレベルは次のとおりです-
- 機能テスト *機能しないテスト
機能テスト
これは、テストされるソフトウェアの仕様に基づいたブラックボックステストの一種です。 入力を提供することでアプリケーションをテストし、目的の機能に適合する必要がある結果を調べます。 ソフトウェアの機能テストは、完全な統合システムで実施され、指定された要件に対するシステムのコンプライアンスを評価します。
アプリケーションの機能をテストする際に関与する5つのステップがあります。
| Steps | Description |
|---|---|
| I | The determination of the functionality that the intended application is meant to perform. |
| II | The creation of test data based on the specifications of the application. |
| III | The output based on the test data and the specifications of the application. |
| IV | The writing of test scenarios and the execution of test cases. |
| V | The comparison of actual and expected results based on the executed test cases. |
効果的なテストの実践では、上記の手順がすべての組織のテストポリシーに適用されるため、ソフトウェアの品質に関しては組織が最も厳しい基準を維持することが保証されます。
単体テスト
このタイプのテストは、セットアップがテストケースを正式に実行するためにテストチームに引き渡される前に、開発者によって実行されます。 ユニットテストは、それぞれの開発者がソースコードの割り当てられた領域の個々のユニットで実行します。 開発者は、品質保証チームのテストデータとは異なるテストデータを使用します。
単体テストの目標は、プログラムの各部分を分離し、個々の部分が要件と機能に関して正しいことを示すことです。
単体テストの制限
テストでは、アプリケーションのすべてのバグをキャッチできません。 すべてのソフトウェアアプリケーションのすべての実行パスを評価することは不可能です。 単体テストの場合も同じです。
開発者がソースコードの検証に使用できるシナリオとテストデータの数には制限があります。 すべてのオプションを使い果たした後、ユニットテストを停止し、コードセグメントを他のユニットとマージする以外に選択肢はありません。
統合テスト
統合テストは、アプリケーションの結合部分が正しく機能するかどうかを判断するためのテストとして定義されます。 統合テストは、ボトムアップ統合テストとトップダウン統合テストの2つの方法で実行できます。
| Sr.No. | Integration Testing Method |
|---|---|
| 1 |
このテストは、ユニットテストから始まり、モジュールまたはビルドと呼ばれるユニットの段階的により高度な組み合わせのテストが続きます。 |
| 2 |
Top-down integration このテストでは、最高レベルのモジュールが最初にテストされ、その後徐々に、下位レベルのモジュールがテストされます。 |
包括的なソフトウェア開発環境では、通常、ボトムアップテストが最初に行われ、続いてトップダウンテストが行われます。 プロセスは、できれば実際の状況を模倣するように設計されたシナリオで、完全なアプリケーションの複数のテストで終了します。
システムテスト
システムテストは、システム全体をテストします。 すべてのコンポーネントが統合されると、アプリケーション全体が厳密にテストされ、指定された品質基準を満たしていることが確認されます。 このタイプのテストは、専門のテストチームによって実行されます。
システムテストは次の理由で重要です-
- システムテストは、ソフトウェア開発ライフサイクルの最初のステップであり、アプリケーション全体がテストされます。
- アプリケーションは徹底的にテストされ、機能および技術仕様を満たしていることを確認します。
- アプリケーションは、アプリケーションがデプロイされる実稼働環境に非常に近い環境でテストされます。
- システムテストにより、ビジネス要件とアプリケーションアーキテクチャの両方をテスト、検証、および検証できます。
回帰試験
ソフトウェアアプリケーションに変更が加えられるたびに、アプリケーション内の他の領域がこの変更の影響を受ける可能性が非常に高くなります。 回帰テストを実行して、修正されたバグが別の機能やビジネスルール違反を引き起こしていないことを確認します。 回帰テストの目的は、バグ修正などの変更により、アプリケーションで別の障害が発見されないようにすることです。
次の理由により、回帰テストは重要です-
- 変更が加えられたアプリケーションをテストする必要がある場合、テストのギャップを最小限に抑えます。
- 新しい変更をテストして、変更がアプリケーションの他の領域に影響を与えなかったことを確認します。
- アプリケーションで回帰テストが実行されるときのリスクを軽減します。
- タイムラインを損なうことなくテスト範囲が拡大します。
- 製品の市場投入のスピードを上げます。
受け入れ試験
これはおそらく、アプリケーションが意図した仕様を満たし、クライアントの要件を満たしているかどうかを評価する品質保証チームによって実施されるため、最も重要なタイプのテストです。 QAチームには、アプリケーションのテストに使用される事前に作成された一連のシナリオとテストケースがあります。
アプリケーションについてより多くのアイデアが共有され、アプリケーションでより多くのテストを実行して、その精度とプロジェクトが開始された理由を評価できます。 受け入れテストは、単純なスペルミス、表面的なエラー、またはインターフェースのギャップを指摘するだけでなく、アプリケーションのシステムクラッシュや重大なエラーを引き起こすアプリケーションのバグを指摘することも目的としています。
アプリケーションで受け入れテストを実行することにより、テストチームは、運用環境でのアプリケーションの実行方法を削減します。 システムを受け入れるための法的および契約上の要件もあります。
アルファテスト
このテストはテストの第1段階であり、チーム（開発者およびQAチーム）の間で実行されます。 ユニットテスト、統合テスト、およびシステムテストを組み合わせた場合は、アルファテストと呼ばれます。 この段階では、次の側面がアプリケーションでテストされます-
- スペルミス
- 壊れたリンク
- 曇りの道順
- アプリケーションは、ロード時間と遅延の問題をテストするために、最も低い仕様のマシンでテストされます。
ベータテスト
このテストは、アルファテストが正常に実行された後に実行されます。 ベータテストでは、対象ユーザーのサンプルがアプリケーションをテストします。 ベータテストは、*プレリリーステスト*とも呼ばれます。 ソフトウェアのベータテストバージョンは、部分的にはプログラムに「現実の」テストを提供し、次のリリースのプレビューを提供するために、Web上の幅広い視聴者に理想的に配布されます。 このフェーズでは、聴衆は以下をテストします-
- ユーザーは、アプリケーションをインストールして実行し、フィードバックをプロジェクトチームに送信します。
- 誤植、混乱を招くアプリケーションフロー、さらにはクラッシュ。
- プロジェクトチームは、フィードバックを入手して、実際のユーザーにソフトウェアをリリースする前に問題を修正できます。
- 実際のユーザーの問題を解決する問題を修正すればするほど、アプリケーションの品質は向上します。
- 一般公開するときに高品質のアプリケーションを使用すると、顧客満足度が向上します。
非機能テスト
このセクションは、非機能属性からアプリケーションをテストすることに基づいています。 非機能テストでは、本来は機能しないがパフォーマンス、セキュリティ、ユーザーインターフェイスなどの重要な要件からソフトウェアをテストします。
重要で一般的に使用される非機能テストタイプのいくつかを以下で説明します。
性能試験
これは主に、ソフトウェアのバグを見つけるのではなく、ボトルネックやパフォーマンスの問題を識別するために使用されます。 ソフトウェアのパフォーマンスの低下に寄与するさまざまな原因があります-
- ネットワーク遅延
- クライアント側の処理
- データベーストランザクション処理
- サーバー間の負荷分散
- データレンダリング
パフォーマンステストは、次の側面の観点から重要かつ必須のテストタイプの一つとみなされます-
- 速度（つまり、 応答時間、データのレンダリングとアクセス）
- 容量
- 安定
- スケーラビリティ
パフォーマンステストは定性的または定量的であり、*負荷テスト*や*ストレステスト*などのさまざまなサブタイプに分けることができます。
負荷テスト
これは、ソフトウェアが大きな入力データにアクセスして操作するという点で最大負荷を適用することにより、ソフトウェアの動作をテストするプロセスです。 通常の負荷条件とピーク負荷条件の両方で実行できます。 このタイプのテストでは、ソフトウェアの最大容量とピーク時の動作を特定します。
ほとんどの場合、負荷テストは、Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio Load Testなどの自動化ツールを使用して実行されます。
仮想ユーザー（VUsers）は自動テストツールで定義され、ソフトウェアの負荷テストを検証するためにスクリプトが実行されます。 ユーザーの数は、要件に基づいて同時にまたは段階的に増減できます。
ストレステスト
ストレステストには、異常な状態でのソフトウェアの動作のテストが含まれます。 たとえば、一部のリソースを削除したり、実際の負荷制限を超えて負荷を適用したりすることが含まれます。
ストレステストの目的は、システムに負荷をかけ、ソフトウェアが使用するリソースを引き継いでブレークポイントを特定することにより、ソフトウェアをテストすることです。 このテストは、次のようなさまざまなシナリオをテストすることで実行できます-
- ネットワークポートのランダムなシャットダウンまたは再起動
- データベースをオンまたはオフにする
- CPU、メモリ、サーバーなどのリソースを消費するさまざまなプロセスを実行する
ユーザビリティテスト
ユーザビリティテストはブラックボックス技術であり、ユーザーの使用と操作を観察することにより、ソフトウェアのエラーや改善点を特定するために使用されます。
Nielsenによれば、使いやすさは5つの要素で定義できます。 使用効率、学習能力、記憶能力、エラー/安全性、満足度。 彼によると、製品の使いやすさは良好であり、システムが上記の要素を所有していれば使用可能です。
Nigel BevanとMacleodは、ユーザビリティはコンピューターシステムとの相互作用の結果として測定できる品質要件であると考えました。 適切なリソースを使用して目的の目標を効果的に達成できれば、この要件を満たし、エンドユーザーを満足させることができます。
2000年のMolichは、使いやすいシステムが次の5つの目標、つまり学習しやすく、覚えやすく、使いやすく、使いやすく、理解しやすいという5つの目標を達成する必要があると述べました。
ユーザビリティのさまざまな定義に加えて、ISO-9126、ISO-9241-11、ISO-13407、IEEE stdなどの属性およびサブ属性の形式でユーザビリティを定義する標準および品質モデルと方法がいくつかあります。 610.12など
UI対ユーザビリティテスト
UIテストには、ソフトウェアのグラフィカルユーザーインターフェイスのテストが含まれます。 UIテストにより、GUIが要件に従って機能し、色、配置、サイズ、およびその他のプロパティの観点でテストされることが保証されます。
一方、使いやすさのテストは、簡単に処理できる優れたユーザーフレンドリーなGUIを保証します。 UIテストは、ユーザビリティテストのサブパートと見なすことができます。
セキュリティテスト
セキュリティテストでは、セキュリティと脆弱性の観点から欠陥やギャップを特定するためにソフトウェアをテストします。 以下にリストされているのは、セキュリティテストで確認する必要がある主な側面です-
- 守秘義務
- 誠実さ
- 認証
- 可用性
- 承認
- 否認防止
- ソフトウェアは既知および未知の脆弱性に対して安全です
- ソフトウェアデータは安全です
- ソフトウェアはすべてのセキュリティ規制に従っています
- 入力チェックと検証
- SQL挿入攻撃
- 注入欠陥
- セッション管理の問題
- クロスサイトスクリプティング攻撃
- バッファオーバーフローの脆弱性
- ディレクトリトラバーサル攻撃
移植性テスト
移植性テストには、再利用性を確保し、他のソフトウェアからも移動できることを目的としたソフトウェアのテストが含まれます。 以下は、移植性テストに使用できる戦略です-
- インストールされたソフトウェアをあるコンピューターから別のコンピューターに転送する。
- さまざまなプラットフォームでソフトウェアを実行するための実行可能ファイル（.exe）の構築。
このテストタイプには、さまざまな環境での使用に関するソフトウェアの全体的なテストが含まれるため、移植性テストはシステムテストのサブパートの1つと見なすことができます。 移植性テストの主な焦点は、コンピューターハードウェア、オペレーティングシステム、およびブラウザーです。 移植性テストの前提条件の一部は次のとおりです-
- ソフトウェアは、移植性の要件を考慮して設計およびコーディングする必要があります。
- 関連するコンポーネントで単体テストが実行されました。
- 統合テストが実行されました。
- テスト環境が確立されました。
