インターフェイスのテストに関しては、どのツールが優れていて使いやすいかということに誰もが注目します。しかし、インターフェースのテストケースの設計上の問題に注目している人はほとんどいませんし、インターフェースのユースケースを書く人もほとんどいません。
これは本当に正しいのでしょうか? 私たちは何かを見落としていませんか？回帰テスト中に、数百または数千のインターフェイスが実行され、エラーが報告されなかった場合、そのシステムに本当に自信を持っていますか? インターフェイスのテストに加えて、インターフェイスの実装ができない、または実装が難しいシナリオを検証するには、どのような機能のユースケースを追加する必要がありますか?
個人的には、スクリプト レベルでの記述に加えて、インターフェイスのユースケースの設計も非常に重要なテスト作業であると考えています。特定のインターフェイスのユースケース設計を通じて、私たちが作成するスクリプトはより目的を持った信頼性の高いものになり、単に量で勝つのではなく、インターフェイス テストの価値と重要性を反映できるようになります。テストの目的は明確であり、インターフェイス テストの基本原則に準拠しており、明確なインターフェイス自動化スクリプトが優れたスクリプトであると主張しています。
1. 特定のユースケースをテストする目的は何ですか?
インターフェイス テスト スクリプトを作成する前に、これらのスクリプトの目的と検証する目的を明確にする必要があります。個人的な経験に基づいて、インターフェイスの使用例は通常、次の 3 つのカテゴリに分類されます。
単一インターフェイスの検証: 主にインターフェイスのパラメーター、権限、戻り値を検証して、インターフェイスが「使用できる」ことを確認します。このタイプのユースケースは通常、インターフェイスの設計が完了した後にモック サービスを使用して作成できます。シナリオ ロジックの検証: ユーザー シナリオに基づく
基本: インターフェイスとビジネス プロセス間のパラメーター転送が正常に行われることを確認する ユース ケースの複雑さは高く、ビジネスとインターフェイスの関係をよく理解する必要があります。これはインターフェイス テストの核となる価値です。
例外検証: 主に、インターフェイスがパラメータ例外やロジック例外などの場合に、わかりやすいエラー メッセージを処理して表示できるかどうかを検証します。通常、パラメータの異常に焦点を当てたシナリオが多くあり、これは同値クラスや境界値などによって処理できます。注意する必要があるのは、異常戻り情報が何であるか、情報が明確であるか、プロンプトが親切であるかなどです。
2. インターフェース情報のソース
テストの目標を明確にしてテスト ケースの作成を開始したら、より的を絞った方法でテスト データとインターフェイスの組み合わせを設計します。次の質問は何ですか? インターフェース情報が有効であることはどこで確認できますか? 基本的に次の 2 つのパスがあります。
インターフェースのドキュメント: 開発者は自分自身でドキュメントを書くことを好みませんし、他の人がドキュメントを書かないことも嫌います。したがって、テスト担当者にとって、実際の有効なインターフェイス ドキュメントを入手することは非常に面倒です。一般に、チーム内には統一されたインターフェイス ドキュメント管理ツールが存在します (そうでない場合は、開発者を見つけて入手するように依頼することは難しくありません)。インターフェイス ドキュメントの有効性と適時性に注意を払う必要があります。現在、Swaager、apidoc など、開発者がインターフェイス ドキュメントを自動的に生成するのに役立つプラグインやツールが多数あります。
インターフェイスのパケット キャプチャ: 何もない場合は、自分の努力に頼って、Fiddler などのツールを使用してパケット キャプチャ分析を通じてインターフェイスを取得します。そのようなシナリオが多数ある場合は、Fiddler によってキャプチャされたインターフェイスをエクスポートしてから、A smallプログラムは、インターフェイス プラットフォームで認識できるスクリプトに直接変換できるため、より効率的になります。
インターフェイス情報を取得した後、ターゲットを絞った方法でテスト ケースを設計できるように、開発者とさらにコミュニケーションをとってパラメーターの意味とソースを明確にする必要があります。このリンクではあまり推測しないでください (多くのテスターはよく推測します)彼ら自身）、直接開発者に問い合わせてください。このセクションでは、インターフェイスの重要性と優先順位を整理して区別することも必要です。このようにして、ユースケースの設計においてどのインターフェイスが優先されるのか、どのインターフェイスを最初に脇に置いてもよいのかを確認し、限られた時間内で最も価値のあることを行うことができます。
3. いくつかの基本原則
インターフェイスを取得し、パラメーターの説明を明確にし、テストの目標を組み合わせたら、テスト ケースの設計と作成を開始できます。機能テスト ケースとは異なり、インターフェイス テスト ケース (スクリプト) では、いくつかの原則に注意する必要があります。
自動化: それはナンセンスのようです。すべてのユースケースは非対話型テストである必要があります。最も一般的なのは、自動的に処理する必要があるトークンの生成です (トークンを手動で生成して貼り付ける必要があるスクリプトを見たことがあります)ユースケースを実行する前に実行してください。特に異なる環境で実行する場合です)。
独立性: 各ユースケースは独立しており、依存関係がない必要があります。前提条件は、複数のユースケースが相互に依存するのではなく、1 つのユースケースで処理される必要があります。
反復可能: ユースケース テストは繰り返し実行できるため、パラメーターの生成方法に注意する必要があります。
持続性: コードの変更により既存のインターフェイス テストが失敗する場合は、コードの問題を修正するか、コード ロジックをテストする必要があります。
4. それらのことを主張する
テスト ケースを設計するときは、アサーションの設計にも注意を払う必要があります。適切なアサーションは、問題の発見に役立ちます。アサーションのないユース ケース (スクリプト) は単なる不正で、まったく意味がありません。個人的に、スクリプトをレビューするときはこれに焦点を当てます (多くのテスターは、データの見栄えを良くするため、または事後的に記述されているため、記述が非常に単純であると主張します。このタイプのスクリプトは、実際には純粋に無駄な作業を行っています) KPIの場合)。
インターフェイス レベルからは、少なくとも 2 つの点を確認する必要があります。
データ構造の検証: インターフェイスから返されたデータ構造が事前に定義されたデータ構造と同じであるかどうかを検証します。呼び出し元がデータを処理するときは、事前に定義されたデータ構造に基づいてデータを解析する必要があります。データ構造が変更されると、呼び出し元にとって致命的な事態になります (コントラクト テストを考慮してください)。
コア値の検証: ビジネス シナリオに応じて、特定のキーの値が期待どおりであるかどうかを意図的に検証したり、データベース クエリを組み合わせて検証したりできます (自動テスト フレームワークが異なれば実装方法も異なります)。これは、テスターのビジネスの理解に大きく依存します。実態に応じた柔軟な設計検証ポイント。
上記 2 点に加えて、他者を巻き込んだデータ転送、返された URL にアクセスできるか、返されたデータが本当に必要かどうかなど、必要に応じて追加の検証ポイントがいくつかあります（これは非常に重要です）。重要) 重要、返品が多すぎると予期せぬ問題が発生する可能性があります) など。実情に応じて補足します。
このように、一連の方法で設計されたインターフェイスのユースケースは、一定のビジネス価値を持ち、チームを真に助け、テスト効率を向上させることができ、そのようなテスト スクリプトでは、すべて PASS の結果が得られ、人々は安心します。(アサーションのないすべてのスクリプトが通過することを想像できますか。まだ安心していますか?)
5. スクリプトの事後メンテナンス
テストケース（スクリプト）を書いたら、インターフェースのテストが完了したわけではありません。他のテストリンクで、インターフェイスの問題 (応答例外、データが返されないなど) によって引き起こされるバグを見つけた場合は、それらをインターフェイスのユースケースに適切に追加して、検証せずに同様の状況が再び発生するのを避ける必要があります。一定の高品質なユースケース (スクリプト) を蓄積した後、オンライン ビジネス監視用のスクリプトに変換したり、正確なテストの基礎に変換したりするなど、その価値をさらに探求できます。よりハイエンドなプレイ方法もあります。これは、カオス テストのアイデアを使用してブランチを個別に引き出し、いくつかの例外を意図的に変更して、テスト ケースでこれらのバグが見つかるかどうかを検証できるようにすることです。テストケースの有効性。発見できない場合は、テスト スクリプトを改善する方法を考える必要があります (同様のプラットフォームはすでに業界に登場しています)。
6. テストデータの準備
テスト データの準備について詳しく話しましょう。これは実際、インターフェイス テストにおいて非常に重要なリンクです。スクリプトを複数の環境で実行する場合は、テスト データを厳密に記述しすぎてはなりません。環境や価値観。テスト データを準備するには、次の 3 つの一般的なゲームプレイ タイプがあります。
パブリック パラメータ: さまざまなスコープと識別子の区別を通じて、さまざまな環境でのユーザー名などの一部の共通データの保存を処理する特別なファイルがあります。
データ収集: 特定の API または SQL を通じて必要なデータを事前に生成し、それを指定されたコレクション (パラメーターまたはファイル) に入れ、必要に応じてここから対応するデータ値を取得します。
データ テンプレート: これはデータ コレクションのアップグレード バージョンです。ビジネス データ フローによれば、いくつかの簡単な情報を入力するだけで、完全なビジネス データ セットが自動的に生成されます (たとえば、私が個人的に行ったことは、学校の基本情報を通じて一連のビジネス データを生成します。学校、クラス、教科、生徒などに関する完全なデータ セットを含む一連の対象データ）。
【2023年最新】Python自動テスト、60の実践的なプロジェクトを7日間で完了し、プロセス全体を通して実践的な情報を提供します。【自動テスト/インターフェーステスト/パフォーマンステスト/ソフトウェアテスト】
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
この情報は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。また、皆さんのお役に立てれば幸いです。