ログインテストについて話す
「ユーザーログイン」のテストオブジェクトは少し単純すぎると言えるかもしれません。ユーザーを見つけて、インターフェースにユーザー名とパスワードを入力させ、「確認」ボタンをクリックして、ログインが成功したかどうかを確認します。 。実際、これは最も基本的で典型的なテストケースであり、エンドユーザーがシステムを使用する場合の最も典型的なシナリオでもあります。
しかし、テストエンジニアとしての目標は、さまざまなアプリケーションシナリオでのシステムの機能が設計要件を満たしていることを確認することです。そのため、より包括的なテストケースを検討する必要があるため、「ユーザーログイン」に基づいている場合があります。一連のテストケースを設計するために、同等のクラス分割および境界値分析手法と組み合わせた機能要件の説明。
等価クラス、境界値
では、等価クラスの分割と境界値の分析方法とは何ですか？まず、どちらも最も一般的に使用され、最も典型的で、最も重要なブラックボックステスト方法に属しています。
等価クラスの分割方法は、すべての可能な入力データをいくつかのサブセットに分割することです。各サブセットで、入力データがプログラムの潜在的なエラーを明らかにする上で同じ効果を持っている場合、そのようなサブセットは等しい価格カテゴリ。その後、テストのために各等価クラスからランダムに値が選択される限り、少量の代表的なテスト入力を使用して、より優れたテストカバレッジ結果を取得できます。
境界値分析方法は、テスト用の入力および出力境界値を選択することです。通常、入力または出力範囲の境界で多数のソフトウェアエラーが発生するため、境界値に対して重要なテストを実行する必要があります。通常、境界と正確に等しいか、境界のすぐ上またはすぐ下の値がテストデータとして選択されます。方法論からわかるように、境界値分析は等価クラスの分割を補完するため、これらの2つのテスト方法はしばしば組み合わせて使用されます
ここで、「ユーザーログイン」機能について、等価クラスの分割と境界値の分析方法に基づいて、私たちが設計したテストケースには次のものが含まれます。
これらのテストケースをリストした後、独自のテストを行ったと感じるため、すでにより満足していると感じるかもしれませんこれらのユースケースの設計では知識が使用されます。
実際、上記のテストケースのセットは、すでに主要な機能テストシナリオをカバーしています。しかし、優れたテストエンジニアの目には、これらのユースケースはやっと合格する標準にしか到達できません。
何？合格した？このアイデアがある場合は、次のコンテンツを読み続ける前に慎重に検討することをお勧めします。これらのテストケースは本当に拡張する必要がありますか？
次に、経験豊富なテストエンジニアが追加するテストケースをいくつか共有します。
これらの使用例を読んだ後、次のように言うかもしれません。「うわー、単純なログイン機能についてテストする必要があるポイントがたくさんあります。」ただし、「ユーザーログイン」機能のテストはまだ終わっていません。
改善されたテストケースセットは、以前のテストカバレッジと比較して確かに大幅に改善されていますが、上級テスターの観点からは、設計する必要がある多くのユースケースがあります。
前述のように、上記のテストケースの設計はすべて、明示的な機能要件の検証に基づいていることがわかります。つまり、これらのテストケースは、「ユーザーログイン」機能の機能について直接検証されます。そしてテストした。
ただし、明示的な機能要件に加えて、他の非機能要件、つまり暗黙の機能要件も、優れた品質のソフトウェアシステムにとって重要です。明示的な機能要件の意味は、「通常のユーザーは正しいユーザー名とパスワードで正常にログインできる」、「未登録」など、ソフトウェア自体が実装する必要のある特定の機能を参照して、文字通り非常に理解できます。ユーザーは "etc."にログインできません。これらはすべて、典型的な明示的な機能要件の説明です。
非機能要件とは何ですか？ソフトウェアテストの観点から見ると、非機能要件には主にセキュリティ、パフォーマンス、互換性の3つの側面が関係しています。上記のすべてのテストケースの設計では、機能以外の要件のテストはまったく考慮していませんが、これらは多くの場合、ソフトウェアの品質を決定する重要な要素です。
非機能要件テストの重要性を理解した後、最初にどのテストケースを設計する必要があるかを考え、次にどのユースケースを提供するかを検討できます。この方法はさらに役立つと思います。
セキュリティテストケース：
パフォーマンステストケース：
互換性テストケース：
「ユーザーログイン」機能テストは非常に単純で価値がないとまだ思いますか？単純に見える機能テストは、明確な機能要件に加えて、実際には非常に多くのテストケースをカバーしています。考慮する必要がある他の多くの非機能要件があります。
さらに、これらのテストケースの設計を通じて、優れたテストエンジニアは非常に幅広い知識を持っている必要があることもわかります。テスト対象のシステムの設計を深く理解できない場合は、セキュリティ攻撃の基本原則を理解していません。パフォーマンステストの基本的な設計方法を習得すると、「対象を絞った」テストケースの設計が困難になります。
この例の「ユーザーログイン」機能のテストを通じて、テストについてより深く考える刺激となり、テストケースを設計するためのアイデアを引き出して、ブリックを投げる効果を達成できることを願っています。
これらのテストケースを読んだ後、まだカバーされていないいくつかの欠落したテストポイントがあり、この関数のテストポイントは十分に包括的ではない場合があります。
テストが尽きることがないということは、ほとんどの場合、徹底的なテストを実行することが不可能であることを意味します。
いわゆる「徹底的なテスト」とは、ソフトウェアの入力値と前提条件のすべての可能な組み合わせを含むテスト方法を指します。徹底的なテストを完了するシステムは、未知のソフトウェアの欠陥を残すべきではありません。未知のソフトウェアの欠陥がある場合、より多くのテストを実行することでそれらを見つけることができるため、テストは使い果たされていません。
ただし、ソフトウェアエンジニアリング手法の大部分では、テストは時間と経済的コストによって制限されており、すべての可能な組み合わせを網羅することは不可能です。代わりに、リスク主導のモデルが採用され、テストスコープが重点的に選択されていますまた、テストケースを設計して、欠陥リスクとR＆Dコストのバランスを見つけます。
まとめ
まず、高品質のソフトウェアテストの場合、ユースケース設計では明示的な明示的な機能要件を考慮する必要があるだけでなく、互換性、セキュリティ、パフォーマンスなどの一連の非機能要件も含まれます。これらの非機能要件品質が決定的な役割を果たす。
第2に、優れたテストエンジニアは、問題を見つけやすいターゲットテストケースを設計するための幅広い知識が必要です。
最後に、ソフトウェアテストのユースケース設計は尽きることがありません。エンジニアリングの実践では、時間コストと経済コストを回避することは難しいため、優れたテストエンジニアは、欠陥のリスクと研究開発のコストのバランスをとる必要があります。
————————————————
著作権に関する声明：この記事は、CSDNブロガー「yinlin330」のオリジナルの記事であり、CC 4.0 BY-SAの著作権契約に従います。元のソースリンクとこの声明を添付して転載してください。
元のリンク：https://blog.csdn.net/yinlin330/article/details/90607335
