ソフトウェアテスト-レベル

テストの過程でさまざまなレベルがあります。この章では、これらのレベルについて簡単に説明します。

テストのレベルには、ソフトウェアテストの実施中に使用できるさまざまな方法論が含まれます。ソフトウェアテストの主なレベルは次のとおりです。

機能テスト
非機能テスト

機能テスト

これは、テスト対象のソフトウェアの仕様に基づくブラックボックステストの一種です。アプリケーションは入力を提供することによってテストされ、次に、意図された機能に準拠する必要がある結果が調べられます。ソフトウェアの機能テストは、システムが指定された要件に準拠しているかどうかを評価するために、完全な統合システムで実行されます。

アプリケーションの機能をテストする際に必要な5つのステップがあります。

ステップ	説明
私	目的のアプリケーションが実行することを意図している機能の決定。
II	アプリケーションの仕様に基づいたテストデータの作成。
III	テストデータとアプリケーションの仕様に基づく出力。
IV	テストシナリオの作成とテストケースの実行。
V	実行されたテストケースに基づく実際の結果と期待される結果の比較。

効果的なテスト手法では、上記の手順がすべての組織のテストポリシーに適用されるため、ソフトウェアの品質に関して組織が最も厳しい基準を維持することが保証されます。

ユニットテスト

このタイプのテストは、セットアップがテストチームに渡されてテストケースが正式に実行される前に、開発者によって実行されます。ユニットテストは、ソースコードが割り当てられた領域の個々のユニットに対してそれぞれの開発者によって実行されます。開発者は、品質保証チームのテストデータとは異なるテストデータを使用します。

単体テストの目標は、プログラムの各部分を分離し、個々の部分が要件と機能の点で正しいことを示すことです。

ユニットテストの制限

テストでは、アプリケーションのすべてのバグを検出することはできません。すべてのソフトウェアアプリケーションのすべての実行パスを評価することは不可能です。ユニットテストの場合も同じです。

開発者がソースコードを検証するために使用できるシナリオとテストデータの数には制限があります。すべてのオプションを使い果たした後、ユニットテストを停止し、コードセグメントを他のユニットとマージする以外に選択肢はありません。

統合テスト

統合テストは、アプリケーションの結合された部分をテストして、それらが正しく機能するかどうかを判断することとして定義されます。統合テストは、ボトムアップ統合テストとトップダウン統合テストの2つの方法で実行できます。

シニア番号	統合テスト方法
1	Bottom-up integration このテストは、ユニットテストから始まり、モジュールまたはビルドと呼ばれるユニットの段階的に高いレベルの組み合わせのテストが続きます。
2	Top-down integration このテストでは、最高レベルのモジュールが最初にテストされ、その後、下位レベルのモジュールがテストされます。

包括的なソフトウェア開発環境では、通常、ボトムアップテストが最初に実行され、次にトップダウンテストが実行されます。プロセスは、できれば実際の状況を模倣するように設計されたシナリオで、アプリケーション全体の複数のテストで終了します。

システムテスト

システムテストは、システム全体をテストします。すべてのコンポーネントが統合されると、アプリケーション全体が厳密にテストされ、指定された品質基準を満たしていることを確認します。このタイプのテストは、専門のテストチームによって実行されます。

システムテストは、次の理由から重要です。

システムテストは、ソフトウェア開発ライフサイクルの最初のステップであり、アプリケーション全体がテストされます。
アプリケーションは徹底的にテストされ、機能および技術仕様を満たしていることを確認します。
アプリケーションは、アプリケーションがデプロイされる実稼働環境に非常に近い環境でテストされます。
システムテストにより、ビジネス要件とアプリケーションアーキテクチャの両方をテスト、検証、および検証できます。

回帰試験

ソフトウェアアプリケーションに変更が加えられるたびに、アプリケーション内の他の領域がこの変更の影響を受ける可能性があります。リグレッションテストは、修正されたバグが別の機能やビジネスルール違反を引き起こしていないことを確認するために実行されます。リグレッションテストの目的は、バグ修正などの変更によって、アプリケーションで別の障害が発見されないようにすることです。

次の理由により、回帰テストは重要です。

変更を加えたアプリケーションをテストする必要がある場合は、テストのギャップを最小限に抑えます。
新しい変更をテストして、加えられた変更がアプリケーションの他の領域に影響を与えていないことを確認します。
アプリケーションで回帰テストを実行する際のリスクを軽減します。
タイムラインを損なうことなく、テストカバレッジが拡大されます。
製品を販売するためのスピードを上げます。

受け入れ試験

これは、アプリケーションが意図した仕様を満たし、クライアントの要件を満たしているかどうかを判断する品質保証チームによって実施されるため、間違いなく最も重要なタイプのテストです。QAチームには、アプリケーションのテストに使用される一連の事前に作成されたシナリオとテストケースがあります。

アプリケーションについてより多くのアイデアが共有され、アプリケーションの精度とプロジェクトが開始された理由を評価するために、より多くのテストを実行できます。受け入れテストは、単純なスペルミス、外観上のエラー、またはインターフェイスのギャップを指摘するだけでなく、システムのクラッシュやアプリケーションの重大なエラーを引き起こすアプリケーションのバグを指摘することも目的としています。

アプリケーションで受け入れテストを実行することにより、テストチームはアプリケーションが本番環境でどのように実行されるかを削減します。システムを受け入れるための法的および契約上の要件もあります。

アルファテスト

このテストはテストの最初の段階であり、チーム（開発者チームとQAチーム）間で実行されます。ユニットテスト、統合テスト、およびシステムテストを組み合わせた場合、アルファテストと呼ばれます。このフェーズでは、次の側面がアプリケーションでテストされます。

スペルミス
壊れたリンク
曇りの方向
アプリケーションは、ロード時間と遅延の問題をテストするために、最も低い仕様のマシンでテストされます。

ベータテスト

このテストは、アルファテストが正常に実行された後に実行されます。ベータテストでは、対象読者のサンプルがアプリケーションをテストします。ベータテストは、pre-release testing。ソフトウェアのベータテストバージョンは、プログラムに「実際の」テストを提供し、次のリリースのプレビューを提供するために、Web上の幅広い対象者に理想的に配布されます。このフェーズでは、聴衆は以下をテストします-

ユーザーはアプリケーションをインストールして実行し、プロジェクトチームにフィードバックを送信します。
誤植、混乱するアプリケーションフロー、さらにはクラッシュ。
プロジェクトチームはフィードバックを取得して、実際のユーザーにソフトウェアをリリースする前に問題を修正できます。
実際のユーザーの問題を解決するために修正する問題が多いほど、アプリケーションの品質は高くなります。
一般に公開するときに高品質のアプリケーションを使用すると、顧客満足度が向上します。

非機能テスト

このセクションは、非機能属性からのアプリケーションのテストに基づいています。非機能テストには、本質的に非機能であるが、パフォーマンス、セキュリティ、ユーザーインターフェイスなどの重要な要件からソフトウェアをテストすることが含まれます。

重要で一般的に使用される非機能テストタイプのいくつかを以下で説明します。

性能試験

これは主に、ソフトウェアのバグを見つけるのではなく、ボトルネックやパフォーマンスの問題を特定するために使用されます。ソフトウェアのパフォーマンス低下に寄与するさまざまな原因があります-

ネットワーク遅延
クライアント側の処理
データベーストランザクション処理
サーバー間の負荷分散
データレンダリング

パフォーマンステストは、次の点で重要かつ必須のテストタイプの1つと見なされています。

速度（つまり、応答時間、データのレンダリングとアクセス）
Capacity
Stability
Scalability

パフォーマンステストは、定性的または定量的のいずれかであり、次のようなさまざまなサブタイプに分けることができます。 Load testing そして Stress testing。

負荷テスト

これは、ソフトウェアが大きな入力データにアクセスして操作するという点で最大の負荷をかけることにより、ソフトウェアの動作をテストするプロセスです。これは、通常の負荷条件とピーク負荷条件の両方で実行できます。このタイプのテストでは、ソフトウェアの最大容量とピーク時の動作を特定します。

ほとんどの場合、負荷テストは、Load Runner、AppLoader、IBM Rational Performance Tester、Apache JMeter、Silk Performer、Visual Studio LoadTestなどの自動ツールを使用して実行されます。

仮想ユーザー（VUsers）は自動テストツールで定義され、スクリプトが実行されてソフトウェアの負荷テストが検証されます。ユーザー数は、要件に基づいて、同時にまたは段階的に増減できます。

ストレステスト

ストレステストには、異常な条件下でのソフトウェアの動作のテストが含まれます。たとえば、一部のリソースを削除したり、実際の負荷制限を超える負荷を適用したりすることが含まれる場合があります。

ストレステストの目的は、システムに負荷をかけ、ソフトウェアが使用するリソースを引き継いでブレークポイントを特定することにより、ソフトウェアをテストすることです。このテストは、次のようなさまざまなシナリオをテストすることで実行できます。

ネットワークポートのランダムなシャットダウンまたは再起動
データベースをオンまたはオフにする
CPU、メモリ、サーバーなどのリソースを消費するさまざまなプロセスを実行します。

ユーザビリティテスト

ユーザビリティテストはブラックボックス手法であり、ユーザーの使用状況と操作を観察することにより、ソフトウェアのエラーや改善点を特定するために使用されます。

Nielsenによると、ユーザビリティは、使用効率、学習能力、記憶能力、エラー/安全性、満足度の5つの要素で定義できます。彼によると、製品の使いやすさは良好であり、システムは上記の要素を備えていれば使用可能です。

Nigel BevanとMacleodは、ユーザビリティはコンピュータシステムとの相互作用の結果として測定できる品質要件であると考えました。適切なリソースを使用して目的の目標を効果的に達成すれば、この要件を満たすことができ、エンドユーザーは満たされます。

2000年のMolichは、ユーザーフレンドリーなシステムは、次の5つの目標、つまり、習得しやすく、覚えやすく、効率的に使用でき、満足のいくものであり、理解しやすいものでなければならないと述べました。

ユーザビリティのさまざまな定義に加えて、ISO-9126、ISO-9241-11、ISO-13407、IEEE stdなどの属性とサブ属性の形式でユーザビリティを定義する、いくつかの標準と品質のモデルと方法があります。 610.12など

UIとユーザビリティテスト

UIテストには、ソフトウェアのグラフィカルユーザーインターフェイスのテストが含まれます。UIテストは、GUIが要件に従って機能し、色、配置、サイズ、およびその他のプロパティに関してテストされていることを確認します。

一方、ユーザビリティテストでは、簡単に処理できる優れたユーザーフレンドリーなGUIが保証されます。UIテストは、ユーザビリティテストのサブパートと見なすことができます。

セキュリティテスト

セキュリティテストでは、セキュリティと脆弱性の観点から欠陥やギャップを特定するためにソフトウェアをテストします。以下にリストされているのは、セキュリティテストで確認する必要がある主な側面です。

Confidentiality
Integrity
Authentication
Availability
Authorization
Non-repudiation
ソフトウェアは既知および未知の脆弱性に対して安全です
ソフトウェアデータは安全です
ソフトウェアはすべてのセキュリティ規制に準拠しています
入力のチェックと検証
SQL挿入攻撃
注入の欠陥
セッション管理の問題
クロスサイトスクリプティング攻撃
バッファオーバーフローの脆弱性
ディレクトリトラバーサル攻撃

移植性テスト

移植性テストには、再利用性を確認し、別のソフトウェアから移動できることを目的としたソフトウェアのテストが含まれます。以下は、移植性テストに使用できる戦略です。

インストールされたソフトウェアをあるコンピューターから別のコンピューターに転送する。
さまざまなプラットフォームでソフトウェアを実行するための実行可能ファイル（.exe）をビルドします。

移植性テストは、システムテストのサブパートの1つと見なすことができます。このテストタイプには、さまざまな環境での使用に関するソフトウェアの全体的なテストが含まれるためです。コンピュータハードウェア、オペレーティングシステム、およびブラウザは、移植性テストの主な焦点です。移植性テストの前提条件のいくつかは次のとおりです。

ソフトウェアは、移植性の要件を念頭に置いて設計およびコーディングする必要があります。
ユニットテストは、関連するコンポーネントで実行されました。
統合テストが実行されました。
テスト環境が確立されました。