complete non functional testing guide
非機能テストの完全ガイド：その目的、タイプ、ツール、例を含むテストケース
非機能テストとは何ですか？
非機能テストは、パフォーマンス、ユーザビリティなどのアプリケーションの非機能要件を検証するために行われます。
システムの動作が要件どおりであるかどうかを確認します。それはでカバーされていないすべての側面をカバーしています 機能テスト 。 私たちの日々のテストでは、機能テストと機能要件に多くの注意が払われています。
クライアントは、アプリケーションの機能に直接関連する機能要件を満たすことにも関心があります。ただし、実際のフェーズ、つまり機能テストが行われると、ソフトウェアが市場に登場し、実際のエンドユーザーによって使用されるため、パフォーマンスに関連するいくつかの問題に直面する可能性があります。
これらの問題はシステムの機能とは関係ありませんが、ユーザーエクスペリエンスに悪影響を与える可能性があります。したがって、顧客体験の低下を避けるために、ソフトウェアまたはアプリケーションの非機能要件もテストすることが重要です。
テストは大きく2つのタイプに分類されます。
- 機能テスト
- 非機能テスト
学習内容：
- 重要性
- 目的
- 例
- 利点
- 非機能要件をキャプチャする方法は？
- 機能要件と非機能要件の違い
- これはブラックボックステストですか、それともホワイトボックステストですか？
- 機能しないテストケースのチェックリスト
- アプローチ文書
- 非機能テストタイプ
- 非機能テストツール
- 結論
- 推奨読書
重要性
このテストは、システムの機能に影響を与えていないことを考えると、十分な注意が払われていませんでした。
非機能要件も、初期のテストサイクルでは適切な注意が払われていませんでした。ただし、これは現在変更されています。非機能テストは、最近のすべてのアプリケーションのパフォーマンスとセキュリティの問題を考慮しているため、現在最も重要です。
このテストは、ユーザートラフィックが多い場合のアプリケーションのパフォーマンスに関して、アプリケーションに大きな影響を与えます。このテストにより、アプリケーションが安定しており、極端な条件下で負荷を処理できることが確認されます。
名前自体が示すように、このテストはアプリケーションの非機能的側面に焦点を当てています。 では、機能しない側面は何ですか？または、アプリケーションの機能に関連しない機能は何ですか？
さて、ここにそれらへの答えがあります：
- アプリケーションは通常の状況でどのように動作しますか？
- 同時にログインするユーザーが多すぎる場合、アプリケーションはどのように動作しますか？
- アプリケーションはストレスを処理できますか？
- アプリケーションはどの程度安全ですか？
- アプリケーションは災害から回復できますか？
- アプリケーションは、別の環境またはOSで同じように動作できますか？
- アプリケーションを別のシステムに移植するのはどのくらい簡単ですか？
- アプリケーションに付属のドキュメント/ユーザーマニュアルはわかりやすいですか？
リストは続きます。しかし、ここでのポイントは、これらの機能がアプリケーションの品質に貢献していないということです。答えはイエスです。これらの機能も同様に重要です。
アプリケーションがすべてのユーザー要件を完全に満たしているが、許可されていないユーザーが簡単にアクセスしてアプリケーションに入力したデータを解読したり、5BBを超えるファイルがアップロードされたときにアプリケーションが停止したりするとします。それで、あなたはアプリケーションが良い品質であると言いますか？明らかに正しくありません!!
目的
このタイプのテストの唯一の目的は、アプリケーションの非機能的側面がテストされ、アプリケーションが同じコンテキストで適切に機能することを確認することです。
目的は、ビジネスの期待に応えるアプリケーションを提供するのに役立つ、アプリケーションのすべての特性のテストをカバーすることです。
例
これは重要なテストタイプです。
機能テストは、アプリケーションの機能をテストし、期待どおりに機能することを確認しますが、非機能テストは、アプリケーションがビジネスの期待に十分に対応できることを確認します。
その重要性を理解するために、簡単な例を見てみましょう。
アプリケーションが開発され、機能が完全にテストされますが、機能以外のテストは実行されません。
一方、アプリケーションが稼働すると、アプリケーションの負荷が増加したり、速度が遅くなり、開くのに時間がかかるなど、重大または重大な問題が発生する可能性があります。
応答時間が長くなるか、負荷がある程度大きくなると、アプリケーションがクラッシュする可能性があります。これは、アプリケーションの非機能的側面をテストすることがいかに重要であるかを示しています。
利点
非機能テストの利点のいくつかを以下に示します。
- 機能テストではカバーできないテストをカバーしています。
- これにより、アプリケーションが効率的に実行され、十分な信頼性が確保されます。
- アプリケーションのセキュリティを確保します。
非機能要件をキャプチャする方法は？
私たちがテストを行う間、焦点は主に製品の機能をテストする機能テストにあります。ただし、非機能テストは機能テストと同じくらい重要であり、その要件は製品の最初から考慮に入れる必要があります。
非機能要件は、非機能テストを実行するために使用されます。これらの要件には、テスト対象のアプリケーションまたはソフトウェアから期待されるパフォーマンス出力が含まれます。これには基本的に、ソフトウェアが特定のシステムを操作するのにかかる時間が含まれます。
非機能要件は、多数の人々が同時にソフトウェアを使用している場合の動作もキャプチャします。ほとんどの場合、サーバーがビジーであるか、負荷が高いために使用できないことがあります（つまり、より多くの人が同時にサーバーを使用しています）。オンラインの鉄道チケットを予約するのが一番です 例 そのような状況の。
したがって、非機能要件を適切に文書化し、テストを正しく実行することで、潜在的な顧客による使いやすさの点で高い満足度が保証されます。
このテストは、システムの機能に直接的なビジネス上の影響を与えることはありませんが、ユーザーエクスペリエンスと使いやすさを大幅に向上させることができ、その結果、ソフトウェアの品質に大きな影響を与えることになります。
例：
同じFacebookログインページの例を考えてみましょう。この場合、非機能テストの範囲は、有効な資格情報を入力した後、システムがFacebookにログインするのに必要な時間を記録することです。
また、ユーザーが同時にログインするとき（たとえば、100）、Facebookでユーザーにログインするのにかかる時間としてテストすることもできます。
これにより、システムが負荷とトラフィックを処理できるようになり、ユーザーエクスペリエンスが向上します。
アジャイルでは、非機能要件は入力を使用してキャプチャする必要があります。
非機能要件は、次のように捉える必要があります。
- ユーザー/テクニカルストーリー
- 合格基準
- アーティファクトで
9
＃1）ユーザー/テクニカルストーリー
非機能要件は、次を使用して取得できます。 ユーザーストーリー または技術的な話。非機能要件をユーザーストーリーとしてキャプチャすることは、他の要件をキャプチャすることと同じです。ユーザーストーリーとテクニカルストーリーの唯一の違いは、ユーザーストーリーにはディスカッションが必要であり、可視性があることです。
＃2）合格基準
合否基準 は、顧客が製品を受け入れるために定義されたポイントです。つまり、定義されたポイントに製品を受け入れるには、合格状態である必要があります。
非機能要件を受け入れ基準に含める必要がありますが、すべてのストーリー、つまりすべての反復で非機能要件をテストできない場合があります。したがって、要件は、関連するイテレーションでのみ追加またはテストする必要があります。
＃3）アーティファクト
非機能要件のために別のアーティファクトを準備する必要があります。これにより、何をテストする必要があり、どのように反復で実行できるかをよりよく理解するのに役立ちます。
機能要件と非機能要件の違い
機能要件と非機能要件の間にはいくつかの違いがあり、それらのいくつかを以下に示します。
| S.No. | 機能要件 | 非機能要件 |
|---|---|---|
| パフォーマンス | テスターがすべてのロジスティクスを分析している間に、操作を特定の数の同時ユーザーによって実行されるトランザクションとして扱うツールを介したパフォーマンステスター | 反応時間 |
| 1 | 機能要件は顧客ベースです。 | 非機能要件は、開発者とチームの技術的知識に基づいています。 |
| 二 | 機能要件は、考慮すべき機能、つまり何をテストする必要があるかを指定します。 | 非機能要件は、テストの必要性を指定します。 |
| 3 | 機能テストは、アプリケーションが稼働する前に実行されます。 | 非機能要件には、メンテナンステスト、実行中は不要であるがアプリケーションが稼働しているドキュメントテストが含まれます。 |
| 4 | これは、機能要件としてのみ知られています。 | 品質要件とも呼ばれます。 |
| 5 | 機能要件の実装計画は、システム設計ドキュメントで定義されています。 | 非機能要件の実装計画は、システムアーキテクチャで定義されています。 |
| 6 | 機能要件には、システムの技術的機能のテストが含まれます。 | 非機能要件には、セキュリティ、使いやすさなどの品質が含まれます。 |
さらに読む=> 機能テストと非機能テストの違い
これはブラックボックステストですか、それともホワイトボックステストですか？
非機能テストは、 ブラックボックステスト 技術。
この手法は、機能のみをテストするだけでなく、非機能要件やパフォーマンス、使いやすさなどのテストにも使用できます。ブラックボックステスト手法は、内部システムの知識を必要としません。つまり、必要ありません。テスターへのコードの知識。
機能しないテストケースのチェックリスト
チェックリストは、テストなしで重要な側面が残されていないことを確認するために使用されます。
チェックリストは通常、文書化する時間がなく、製品をテストする必要がある場合、または時間の制約がある場合に使用され、すべての重要な側面がカバーされていることを確認するためにチェックリストを使用できます。
見てみましょう例パフォーマンス、セキュリティ、およびドキュメントのテストチェックリスト。
パフォーマンステストのチェックリスト
- 応答時間 アプリケーションの内容を確認する必要があります。つまり、アプリケーションの読み込みにかかる時間、アプリケーションに入力された入力は、どのくらいの時間で出力を提供するか、ブラウザを更新するなどです。
- スループット 負荷テスト中に完了したトランザクションの数を確認する必要があります。
- 環境 セットアップはライブ環境と同じである必要があります。そうでない場合、結果は同じになりません。
- 処理時間 – Excelのインポートとエクスポートなどのプロセスアクティビティ、アプリケーションでの計算をテストする必要があります。
- 相互運用性 検証する必要があります。つまり、ソフトウェアが他のソフトウェアまたはシステムと相互運用できる必要があります。
- ETL 時間を確認する必要があります。つまり、あるデータベースから別のデータベースへのデータの抽出、変換、およびロードにかかる時間です。
- 負荷の増加 アプリケーションで確認する必要があります。
セキュリティテストのチェックリスト
- 認証： 本物のユーザーのみがログインできる必要があります。
- 承認済み： ユーザーは、自分が許可されているモジュール、またはユーザーにアクセスが許可されているモジュールにのみログインできる必要があります。
- パスワード： パスワード要件を確認する必要があります。つまり、パスワードは、要件の定義方法（長さ、特殊文字、数字など）に準拠している必要があります。
- タイムアウト： アプリケーションが非アクティブの場合、指定された時間内にタイムアウトする必要があります。
- データバックアップ： データのバックアップは指定された時間に実行し、安全な場所にコピーする必要があります。
- 内部リンク ブラウザに直接配置した場合、Webアプリケーションにアクセスできないようにする必要があります。
- すべての通信は暗号化する必要があります。
ドキュメントテストのチェックリスト
- ユーザーとシステムのドキュメント。
- トレーニング用のドキュメント。
アプローチ文書
全体的なテスト戦略を改善することにより、パフォーマンステスト段階の特定のアプローチドキュメントを作成します。このテストアプローチは、すべてのパフォーマンステストタスクの計画と実行をガイドします。
面接の質問をテストする安らかなWebサービス
- テスト範囲
- テストメトリクス
- テストツール
- 重要な日付と成果物
テスト範囲
ユーザーパフォーマンス、ビジネスプロセス、システムの安定性、リソース消費など、さまざまな観点からパフォーマンステストを実施します。実行するパフォーマンステストの種類については、記事の上記のセクションで説明しています（負荷テスト、ストレステストなど）。
テストメトリクス
テストアプローチでは、次のように、テスト中に測定およびレポートするメトリックを改良します。
- 応答時間（オンライン）
- バッチウィンドウ（バッチ）
- スループット（ 例えば 、単位時間あたりのトランザクション数）
- 利用（ 例えば 、使用されたリソースの割合）
テストツール
ほとんどの場合、パフォーマンステストでは、適切なツールを使用する必要があります。
- 負荷生成ツール
- パフォーマンス監視ツール
- パフォーマンス分析ツール
- アプリケーションプロファイリングツール
- ベースライニングツール。
重要な日付と成果物
パフォーマンステストアプローチドキュメントでは、次のことを説明する必要があります。
- 各パフォーマンステストの実施日時。
- 各パフォーマンステストの実施に含まれるテストの種類と機能の組み合わせ。
- パフォーマンステストの完了日。
非機能テストタイプ
次の画像は、非機能テストのタイプを示しています。
性能試験：
主な要素は次のとおりです。
- システムが予想される応答時間を満たしていることを検証します。
- アプリケーションの重要な要素が目的の応答時間を満たしていることを評価します。
- また、統合テストおよびシステムテストの一部として実行することもできます。
負荷テスト：
システムのパフォーマンスが通常および予想される条件下で期待どおりであるかどうかを評価します。
キーポイントは次のとおりです。
- 同時ユーザーがアプリケーションにアクセスし、期待される応答時間を取得したときに、システムが期待どおりに動作することを検証します。
- このテストは、応答時間とスループットを取得するために複数のユーザーで繰り返されます。
- テストの時点で、データベースは現実的である必要があります。
- テストは、実際の環境を刺激する専用サーバーで実行する必要があります。
ストレステスト：
リソースが不足しているときに、システムのパフォーマンスが期待どおりであるかどうかを評価します。
キーポイントは次のとおりです。
- クライアント/サーバーのメモリ不足またはディスク容量不足でテストし、通常の状態では検出できない欠陥を明らかにします。
- 複数のユーザーが同じデータに対して同じトランザクションを実行します。
- 複数のクライアントが異なるワークロードのサーバーに接続されています。
- 思考時間を「ゼロ」に減らして、サーバーに最大のストレスをかけます。
考える時間： ユーザーとパスワードを入力する時間間隔と同じです。
ボリュームテスト：
大量のデータが含まれる場合のソフトウェアの動作を評価します。
キーポイントは次のとおりです。
- ソフトウェアが大量のデータにさらされている場合は、ソフトウェアが失敗する限界を確認してください。
- 最大データベースサイズが作成され、複数のクライアントがデータベースにクエリを実行するか、より大きなレポートを作成します。
- 例 –アプリケーションがデータベースを処理してレポートを作成している場合、ボリュームテストでは、大きな結果セットを使用して、レポートが正しく印刷されているかどうかを確認します。
ユーザビリティテスト：
人間が使用できるようにシステムを評価するか、システムが使用に適しているかどうかを確認します。
キーポイントは次のとおりです。
- 出力は正しくて意味があり、ビジネスで期待されていたものと同じですか？
- エラーは正しく診断されていますか？
- GUIは正しく、標準と一致していますか？
- アプリケーションは使いやすいですか？
ユーザーインターフェイステスト：
GUIを評価します。
キーポイントは次のとおりです。
- GUIは、使いやすくするためのヘルプとツールチップを提供する必要があります。
- その外観に一貫性がありますか？
- データはあるページから別のページに正しく移動しますか？
- GUIは、ユーザーを苛立たせたり、理解しにくくしたりしてはなりません。
互換性テスト：
アプリケーションが最小および最大構成で他のハードウェア/ソフトウェアと互換性があることを評価します。
キーポイントは次のとおりです。
- 最小構成と最大構成で各ハードウェアをテストします。
- さまざまなブラウザでテストします。
テストケースは、機能テスト中に実行されたものと同じです。 - ハードウェアとソフトウェアの数が多すぎる場合は、OATS手法を使用してテストケースに到達し、最大限のカバレッジを得ることができます。
回復テスト：
障害が発生した場合にアプリケーションが正常に終了し、ハードウェアおよびソフトウェアの障害からデータが適切に回復されることを評価します。
テストは以下の点に限定されません。
- CURDアクティビティの実行中のクライアントへの電源遮断。
- 無効なデータベースポインタとキー。
- データベースプロセスが中止されるか、途中で終了します。
- データベースのポインタ、フィールド、およびキーは、データベース内で手動および直接破損しています。
- 通信を物理的に切断し、電源を切り、ルーターとネットワークサーバーの電源を切ります。
不安定性テスト：
ソフトウェアが正しくインストールおよびアンインストールされるかどうかを評価および確認します。
経験豊富なPLSQL開発者インタビューの質問と回答
キーポイントは次のとおりです。
- システムコンポーネントが指定されたハードウェアに正しくインストールされていることを検証します。
- 新しいマシンのナビゲーションが既存のインストールと古いバージョンを更新することを検証します。
- ディスク容量が不足している場合、許容できない動作がないことを検証します。
ドキュメントテスト：
ドキュメントやその他のユーザーマニュアルを評価します。
キーポイントは次のとおりです。
- 記載されているドキュメントが製品で利用可能であることを検証します。
- すべてのユーザーガイド、セットアップ手順、Read meファイル、リリースノート、オンラインヘルプを検証します。
フェイルオーバーテスト：
フェイルオーバーテストは、システム障害が発生した場合に、システムがサーバーなどの追加のリソースを処理するのに十分な能力があることを確認するために行われます。
このような状況を防ぐために、バックアップテストが大きな役割を果たします。バックアップシステムの作成は、プロセスのすべてです。バックアップが利用可能な場合は、システムを元に戻すのに役立ちます。
セキュリティテスト：
セキュリティテスト データの損失や脅威につながる可能性のある抜け穴がアプリケーションにないことを確認するために行われます。これは、機能しないテストの重要な側面の1つであり、適切に実行されない場合、セキュリティの脅威につながる可能性があります。
これには、認証、承認、整合性、および可用性のテストが含まれます。
スケーラビリティテスト：
スケーラビリティテストは、アプリケーションがトラフィックの増加、トランザクションの数、データ量などを処理するのに十分な能力があるかどうかを確認するために行われます。データの量またはデータのサイズの変更が行われると、システムは期待どおりに機能するはずです。
コンプライアンステスト：
コンプライアンステストは、定義された基準が守られているかどうかを確認するために行われます。同じことを検証するために監査が行われます。
ために 例 、 監査は、テストケース/テスト計画を作成し、実行されているかどうかに関係なく、共有の場所に配置するプロセスを検証するために実行されます。 QCでは、テストケースに名前を付ける際に、標準のテストケース名に従うかどうかを決定します。ドキュメントが完全で承認されているかどうか。
これらは、監査中にカバーされるいくつかの指針です。
耐久性テスト：
耐久性試験 負荷が長時間増加した場合のシステムの動作を検証するために行われます。
ソークテストおよび容量テストとも呼ばれます。システムにメモリリークがあるかどうかを確認するのに役立ちます。耐久性テストは、負荷テストのサブセットです。
ローカリゼーションテスト：
ローカリゼーションテスト さまざまな言語、つまりさまざまなロケールでアプリケーションを検証するために行われます。アプリケーションは、特定の文化またはロケールについて検証する必要があります。主な焦点は、アプリケーションのコンテンツ、GUIをテストすることです。
国際化テスト：
国際化テスト i18nテストとも呼ばれます。
I18nはI–18文字– Nを表します。これは、アプリケーションがすべての言語設定で期待どおりに機能するかどうかを確認するために行われます。機能やアプリケーション自体が壊れていないことを確認します。つまり、アプリケーションはすべての国際設定を処理するのに十分な機能を備えている必要があります。
また、アプリケーションが問題なくインストールされていることも確認します。
信頼性テスト：
信頼性テストは、アプリケーションが信頼できるかどうかを検証するために行われ、定義された環境で特定の期間テストされます。アプリケーションは毎回期待どおりの出力を提供する必要があります。そうしないと、信頼できると見なすことができません。
移植性テスト：
移植性テストは、ソフトウェア/アプリケーションが別のシステムまたは別のプラットフォームにインストールされている場合に、期待どおりに実行できるかどうか、つまり環境の変化によって機能が影響を受けないかどうかを確認するために行われます。
テスト中は、ハードディスクスペース、プロセッサなどのハードウェア構成、およびさまざまなオペレーティングシステムを使用して変更をテストし、アプリケーションの正しい動作と期待される機能が損なわれていないことを確認する必要もあります。
ベースラインテスト：
ベースラインテストは、 ベンチマークテスト テストする新しいアプリケーションのベースを作成するためです。
例えば： 最初の反復では、アプリケーションの応答時間は3秒でした。これが次の反復のベンチマークとして設定され、次の反復で応答時間が2秒に変更されます。これは基本的に、将来の参照のベースとして使用される検証ドキュメントです。
効率テスト：
効率テストは、アプリケーションが効率的に機能するかどうか、必要なリソースの数、必要なツール、複雑さ、顧客の要件、必要な環境、時間、プロジェクトの種類などを確認するために行われます。
これらは、考慮されるすべてのパラメーターが期待どおりに機能する場合にアプリケーションがどの程度効率的に機能するかを定義するのに役立つポインターの一部です。
災害復旧テスト：
このテストは、重大な障害が発生した場合のアプリケーションまたはシステムの回復の成功率、およびシステムがデータとアプリケーションを復元できるかどうか、またはシステムが以前の動作状態に簡単に対応できるかどうかを確認するために行われます。運用面。
保守性テスト：
アプリケーション/製品が稼働すると、稼働環境で問題が発生する可能性があります。または、顧客は、すでに稼働しているアプリケーションの拡張機能を必要とする場合があります。
この場合、メンテナンステストチームが上記のシナリオをテストするために利用できます。アプリケーションが稼働した後も、メンテナンステストチームが作業するメンテナンスが必要です。
非機能テストツール
パフォーマンス（負荷とストレス）テスト用に市場で入手可能なツールがいくつかあります。
それらのいくつかを以下に示します。
- JMeter
- ロードスター
- ロードランナー
- ロードストーム
- ネオロード
- 予報
- ロード完了
- Webサーバーストレスツール
- WebLoad Professional
- ロードトレーサー
- vPerformer
非機能テストは常にドキュメントやテストケースなしで実行されますか？どうして？
「私たちは常に機能テストケースの書き方を教えられています。何故ですか？ 「非機能テスト」は、ドキュメントなしで（つまり、アドホックベースで）実行されますか、それとも、理解するのがはるかに難しい別個のプロセスですか？アプリケーションで行われるさまざまな種類のテストのテストケースはどのように作成されますか？」
これは、私が最近尋ねられた、最も独創的で、特徴的で、すぐに使える質問の1つです。答えを見つけましょう。
機能しないテストケースの作成を見て練習することができないのはなぜですか？
私たちが知っていることから始めましょう。いつものように実際的なシナリオです。
例： 転送を実行するためにオンラインバンキングアプリケーションで実行する手順は次のとおりです。それを参考のためのテストとして使用しましょう。
- サイトにログインします。
- 銀行口座を選択します。
- 受取人を選択します（この受取人は同じ銀行または別の銀行に属している可能性があります。これは、このステップを実行するためのデータの選択によって異なります。いずれの場合も、1つを選択してください。また、受取人はすでに追加されていると想定します。） 。
- 送金する金額を入力します（正の値、制限内、正しい形式など）。
- (転送)をクリックして、確認が受信されたかどうか、アカウントの残高が更新されたかどうかなどを確認します。
これは機能テストケースですよね？
同じアプリケーションで、同じ転送のページで、実行しているとしましょう パフォーマンス、セキュリティ、およびユーザビリティテスト 。 これらは機能しないタイプですよね？
テストケースをどのように作成しますか？
＃1）ユーザビリティテストテストケース
ユーザビリティテストは、ユーザーエクスペリエンスを扱うソフトウェアテストのジャンルです。これらは私たちが答えようとしている質問のいくつかです。
- アプリケーションはどのくらい簡単に使用できますか？
- システムの使用経験はどの程度満足していますか？
- すぐに慣れていない場合、学ぶのはどれくらい簡単ですか？
詳細はこちら： ユーザビリティテストガイド
ユーザビリティテストのコンテキストで、ユーザーは上記の質問に対する回答をどのように決定しますか？
ユーザーは、機能テストケースとまったく同じ手順を実行します。私は正しいですか？
＃2）パフォーマンステストテストケース
パフォーマンステストにはいくつかのバリエーションがありますが、基本的には、さまざまな負荷ポイントでのシステム、リソース使用率、応答時間、ネットワーク消費量などに関する統計を取得するために使用されます。
私たちをチェックしてください パフォーマンステストのチュートリアル それについてもっと知るために。
さて、転送のトランザクションのパフォーマンスをテストする場合、10、20、30、100…1000などのユーザーに、ターゲットにしてデータを収集する対象に応じて、転送操作を同時にまたは段階的に実行させます。
パフォーマンステストの進行中に転送を使用するために、各ユーザーはどのような手順を実行しますか？
機能テストとまったく同じ手順ですよね？
＃3）セキュリティテストのテストケース
セキュリティテストは、ソフトウェアシステムをハッキング防止にするのに役立つQAのブランチです。脆弱性（ソフトウェアシステムの潜在的な問題領域）を特定し、侵入またはホワイトハットテスト手法を通じてそれらを悪用し、抜け穴が見つかった場合はそれらに取り組みます。
転送がハッキング防止であり、目的の受信者に正しく送信されているかどうか、およびプロセス全体にブラックスポットがないかどうかをいつ確認する必要がありますか？セキュリティリークの監視プロセスを並行して実行しながら、転送を実行します。
したがって、実際には、機能テストケースの場合に通常行うのとまったく同じ手順を実行しています。
私たちは、すべての状況での手順が同じであることを確立するのに十分だと思います。プロセスの背後にある方法と意図が異なります。
比較してみましょう：
| テストの種類 | WHO？ | どうして？意図 |
|---|---|---|
| 機能テスト | QAテスター | 正確さ |
| 効率 | ||
| ビジネスへの適用性 | ||
| 使いやすさ | QAテスターまたはリアルタイムユーザー | 使いやすさ |
| 学習のしやすさ | ||
| 効率 | ||
| ネットワークの使用状況など | ||
| セキュリティ | 専門のセキュリティ専門家によるスキャンツールおよびその他の監視システム | 安全なハック |
| 受取人と支払人の身元保護など。 |
注意すべき興味深いのは、 どのような形式のテストを実行する場合でも、すべての手順は同じです。 。
本当の違いは次のとおりです。
- 誰がこれらのステップを実行しますか？
- 意図は何ですか、言い換えれば、このテストで何を達成しようとしていますか？
- 使用したツールとテクニック。
私たちの質問に戻って、なぜ私たちはそれにあるすべての詳細なステップで機能しないテストケースを書くことを決して学ばないのですか？
その理由は 、本質的に、特定の機能のテストタイプのバリエーションのテスト手順は、機能的かどうかにかかわらず、すべて同じです。違いを生むのは意図であり、おそらく方法です。
結論
非機能テストを実行する前に、適切なテストを確実にするためにテスト戦略を正しく計画することが不可欠です。 Load Runner、RPTなど、このタイプのテストを実行するために市場で入手できるさまざまなツールがあります。
このテストは、アプリケーションの成功と良好な顧客関係の構築に大きな役割を果たします。したがって、このテストを怠ってはなりません。これはソフトウェアテストの重要な部分の1つであり、これなしではテストは完了したとは見なされません。
機能しないテストの詳細をテスト計画に含めることも、別の戦略を作成することもできます。いずれの場合も、目標はソフトウェアの非機能的側面を適切にカバーすることです。
このトピックを深く掘り下げるこのプロセスが、皆さんに提示されたのと同じくらい楽しいものであったことを願っています。この件に関するフィードバックやご意見をお待ちしております。
チームで機能しないテストをどのように処理しますか？そしていつものように、あなたが同意するか、同意しないか、または私たちがここで行っていることに追加する何かがあるかどうかを私たちに知らせてください。