インターフェースの自動化とは何ですか? なぜそうするのでしょうか?そしてインターフェースを自動化するにはどうすればよいでしょうか?

サーバーインターフェイステストの概要

サーバーとは何ですか?

一般的に、サーバーとは、ユーザーがAPPまたはPCで使用するインターネット機能にデータサービスを提供する背後にあるすべてのものを指します。Tmall Elf スマート スピーカー シリーズの製品リンクを例にとると、サーバーはゲートウェイ (ゲートウェイを含む) の後のリンクです。

インターフェースとは何ですか?

正式には、これはコンピュータ システム内の 2 つの独立したコンポーネント間の情報交換のための共有境界です。平たく言えば、これはサーバーが外部にデータ サービスを提供するために使用する最も一般的な情報交換方法です。データ サービスを提供するサーバーは、大小さまざまな組織です。ほとんどの場合、複数のことを実行します。非常に多くのことを実行しました。最終的な目標は、APP または他の呼び出し元によって使用されることであるため、サーバーは数人の代表者を派遣しました。たとえば、API 1 はユーザー情報の提供を担当し、API 2 はデバイス情報の提供を担当し、API 3 は再生されたオーディオ情報の提供を担当します。皆さん、サーバーは、API 1 と通信するためのコネクタ パスワードが param1、param2...、API 2 と通信するためのコネクタ パスワードが param3、param4... であると規定しています。params はインターフェイス パラメータであり、これを伝えるために使用されます。サーバーにどのようなサービスが必要か、具体的にはどのような要件があるか。インターフェイスは通常、プロトコル、アドレス、パラメータの 3 つの部分で構成されます。

インターフェーステストとは何ですか?

一般に、インターフェイス テストとは、さまざまなパラメーターが入力されたときにインターフェイスの戻り値が正しいかどうかを判断する、特定のインターフェイスの機能テストを指します。下の図は、古典的なテストのピラミッド モデルです。

このモデルでは、下に行くほど割合が高くなります。つまり、製品テストでは単体テストの割合が最も高く、次にインターフェイス テスト、UI 自動化テスト、手動テスト部分が上位になります。サーバー インターフェイス テストは中間にあり、前と後を接続しており、その重要性が示されています。

现在我也找了很多测试的朋友,做了一个分享技术的交流群,共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源,没人解答问题,坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化,性能,安全,测试开发等等方面有一定建树的技术大牛
分享他们的经验,还会分享很多直播讲座和技术沙龙
可以免费学习!划重点!开源的!!!
qq群号:110685036

なぜインターフェーステストを行う必要があるのでしょうか?

一般に、インターフェイスのテストは次の理由で行われます。

  • インターフェイスは、サーバーが外部データ サービスを提供するために最も一般的に使用される情報交換方法です。インターフェイスのコンテンツの大部分はデータです。データの比較を通じて、システムのロジックを推測できます。インターフェイスのテストは、実際にはロジックをテストすることになります。
  • インターフェイス テストは自動化と継続的インテグレーションの実装が比較的簡単で、UI 自動化と比較して比較的安定しているため、手動回帰テストの人件費と時間を削減し、テスト サイクルを短縮し、バックエンドの迅速なリリース要件をサポートできます。

インターフェイスのテストはどうやって行うのですか?

前述したように、インターフェイスはインターフェイス アドレス、リクエスト プロトコル、リクエスト パラメーター、および期待される結果のコンポーネントで構成されます。インターフェイスをテストするための一般的な手順は、リクエストの送信 -> 結果の解析 -> 結果の検証です。

簡単に言うと、インターフェイス テストとは、インターフェイス ドキュメントを参照し、インターフェイスを呼び出し、返された結果がドキュメントの記述と一致するかどうかを確認すること、さらに、不正なパラメータや境界値などの異常なロジックに対するインターフェイスの処理をテストすることです。

インターフェイス テストの焦点を詳しく説明すると、次のとおりです。

1. インターフェースのデータロジックが正しいかどうか。私たちはインターフェースの機能、内部にどのようなデータロジックがあるのか​​、上流および下流とどのような情報やリソースを交換するのかを完全に理解する必要があり、パラメータ呼び出しやプログラムから返される表面的なデータだけにとどまるのではありません。平たく言えば、このインターフェイスが何に使用されるのか、どこで使用されるのか、呼び出されるたびに何が起こるのかを理解し、変更が行われたかどうかを確認する必要があります。

2. 例外パラメータおよびアップストリームおよびダウンストリーム サービスのフォールト トレランスに対するインターフェイスの処理メカニズム。次の図に示すように、テスト対象のインターフェイス A は上流のサービス A に依存しているため、サービス A が異常な場合にテスト対象のインターフェイスがフォールト トレラントであるかどうかは非常に重要です。フォールト トレラントでない場合、サービスがハングまたはクラッシュする可能性があります。さらに、サービス プロバイダー インターフェイス B として、さまざまな使用シナリオやさまざまなバージョンの呼び出し元の使用と完全な互換性がある必要があり、サービス E のニーズを満たすために E 以外の他のサービス ユーザーが使用することはできません。一般に、「上流は信頼できないため、下流は互換性がなければならない」という原則があります。

インターフェイステスト自動化の概要

インターフェーステストの自動化とは何ですか?

インターフェイス テストの自動化とは、簡単に言えば、機能テスト ケースのスクリプトを作成し、そのスクリプトを実行して視覚的なテスト レポートを生成することを意味します。

なぜインターフェースのテストを自動化する必要があるのでしょうか?

どのようなテスト方法であっても、機能を検証し、バグを見つけることです。では、なぜインターフェイスのテストを自動化する必要があるのでしょうか? 一言で言えば人件費の節約です。具体的には次のような点が挙げられます。

  • 自分自身の作業負荷を軽減し、退屈で反復的な手動テストからテストを解放します。
  • シミュレーションが困難または不可能なタスクを完了するために手動テストを支援します。
  • 自動化されたコンパイル、パッケージ化、展開、継続的統合、さらにはテスト環境の継続的配信など、作業効率を向上させます。
  • 問題の特定に役立ちます。たとえば、インターフェイス層で問題が見つかった場合は、追加された TraceID を通じてログ エラーまたはエラー コード行を特定できます。
  • できるだけ早くバグを発見し、テスターに​​自動的に通知します。問題が発見されると、テスターに​​は即座に、迅速かつ効率的に通知が届きます。

インターフェーステスト自動化仕様

ここでは、インターフェイス テストにおける私の通常の経験と組み合わせて、インターフェイス テスト自動化の仕様をいくつかまとめました。これらに追加することは歓迎です。

  • 書類の準備

ナイフを研ぐことで木材を切る時間を無駄にせず、インターフェイス関連の詳細なドキュメントを準備することで、その後のインターフェイス自動テスト作業を効率的に実行できます。関連する文書には次のものが含まれますが、これらに限定されません。

1. 「要件ドキュメント」は、インターフェイスの背後にあるビジネス シナリオ、つまり、インターフェイスが何に使用されるか、どこで使用されるか、呼び出されるたびに何が起こるかなどを明確に定義します。

2. 「インターフェース文書」は、インターフェース名、各入力パラメータ値、各戻り値、およびその他の関連情報を明確に定義します。

3. 「UI インタラクション図」では、各ページに表示されるデータ、ページ間のインタラクションなどを明確に定義します。

4. 「データ テーブル設計ドキュメント」では、テーブル フィールドのルール、テーブルの N 対 N 関係 (1 対 1、1 対多、多対多) などを明確に定義します。

ドキュメント内の情報が信頼でき、最新のものであることを関連する需要当事者に必ず確認してください。信頼できるドキュメントに依存することによってのみ、正しく詳細なインターフェイスのユースケースを設計し、最も正確な結果を得ることができます。

  • インターフェーステスト自動化に必要な機能を明確にする

1. 検証(主張)

テスト アサーションは自動テストのテスト合格条件であり、テスト ケースが期待を満たしているかどうかを判断するために使用されます。したがって、戻り値検証のサポートは必要な機能です。

2. データの分離

データの分離とは、特定のリクエスト インターフェイス、パラメーター、検証、およびその他のデータがコードから分離されることを意味し、メンテナンスが容易になります。インターフェイスのユース ケースを調整する必要がある場合、または新しいインターフェイスのユース ケースを追加する必要がある場合は、その場所をすぐに見つけることができます。分離のもう 1 つの利点は再利用可能であることです。フレームワークを他のチームに昇格させることができます。ユーザーは同じコードを使用でき、テストに必要な独自のユース ケースを入力するだけで済みます。

3. データ転送

データの分離と保守性が達成された後は、データ転送がさらに重要な要件になります。インターフェイスのテストでは、最初に単一インターフェイスのデカップリングを実装し、次にビジネス シナリオに従って複数のインターフェイスを組み合わせます。データ転送は複数のインターフェイスを組み合わせるために必要な条件であり、これによりインターフェイスのユースケース間でパラメーターを渡すことができます。たとえば、デバイス情報クエリ インターフェイスを通じて現在の Tmall Genie スピーカーのデバイス情報をクエリします。このインターフェイスは UUID を返します。次に、ユーザー情報クエリ インターフェイスを通じて現在のデバイスにバインドされているユーザー情報をクエリする必要があります。今回は、2 つのインターフェイスのリクエスト データを最初のインターフェイスの使用例の戻り値から抽出する必要があります。

4. 機能機能

実際のビジネスシナリオのテストでは、ランダムに生成されたタイムスタンプ、リクエストID、ランダムな携帯電話番号や位置情報など、さまざまな補助機能のサポートが必要になります。このとき、対応するキーワードを特定する際の実行をサポートできるコードが必要です。対応する関数 function を入力します。

5. 設定可能

現在のテスト環境には、毎日、プレリリース 1、プレリリース 2、オンラインなどが含まれますが、これらに限定されません。デイリー、プレリリース、オンラインなどあらゆる環境で実行可能。したがって、フレームワークは構成可能であり、切り替えが容易である必要があり、さまざまな環境で実行するためにさまざまな構成ファイルを呼び出すことができます。6. ログ ログには、特定の実行インターフェイス、リクエスト メソッド、リクエスト パラメータ、戻り値、検証インターフェイス、リクエスト時間、消費時間などの重要な情報が含まれています。ログの利点は、新たな使用時に問題を迅速に特定できることです。次に、バグが発見されたときに開発フィードバックにデータを提供すると、開発者はトリガー時間、パラメーター、その他の情報から問題を迅速に特定できるため便利です。

7. 視覚的なレポート

ユース ケースが実行された後、チームに結果を表示するときです。視覚的なレポートにより、チーム メンバーは自動化されたインターフェイス ユース ケースの実行ごとの成功数、失敗数、その他のデータを容易に理解できます。

8. 持続可能な統合

すでにテスト ケースがあり、テスト済みのインターフェイスについては、回帰ユース ケースを形成したいと考えています。次のバージョンのイテレーションまたはリリースの前に、既存のユース ケースを通じて回帰テストが実施され、新しく開始された機能が既存の機能に影響を与えないことを確認します。 。したがって、これには、インターフェイス自動化テストを 1 回限りではなく継続的に統合する必要があります。

  • インターフェーステスト自動化フレームワークの選択

インターフェイス テスト自動化フレームワークに対する当社のニーズと、現在市場に出ている多くのテスト ツールの特性を組み合わせると、次の表にまとめられます。

以下に簡単なリストを示します。

1、バイオリン弾き

fiddler は、Web テストとモバイル テストの両方に使用される HTTP プロトコル デバッグ プロキシ ツールであり、インターフェイス テストもサポートしています。コンピューターとインターネット間のすべての http 通信を記録および検査し、ブレークポイントを設定し、Fiddler の「入出力」すべてのデータ (Cookie、html、js、css およびその他のファイルを参照) を表示できます。

2、郵便配達員

これは Google によって開発され、Chrome ブラウザにインストールされるプラグインで、さまざまなインターフェイス テスト リクエストをサポートし、テスト スイートを管理し、操作を自動化できます。弱点は、自動アサーション機能が強力ではなく、Jenkins やコード管理ライブラリとの継続的統合テストに使用できないことです。

3、ワイヤーシェイク

これは、TCP、UDP、HTTP およびその他のプロトコルをサポートするパケット キャプチャ ツールです。低レベルのネットワーク データ テストを行う場合は、通常、これを使用する必要がありますが、インターフェイス テストに使用する場合は少し不親切です。データの更新が速すぎるため、各操作に対応するインターフェイスを見つけるのが困難です。

4、スープUI

soapUI は、soap/http を介して Web サービスの機能/負荷/準拠テストをチェック、呼び出し、実装するオープン ソース テスト ツールです。このツールは、スタンドアロンのテスト ソフトウェアとして使用することも、プラグインを使用して Eclipse、maven2.X、Netbeans、および Intellij に統合することもできます。1 つ以上のテスト スイート (TestSuite) をプロジェクトに編成します。各テスト スイートには 1 つ以上のテスト ケース (TestCase) が含まれます。各テスト ケースには、リクエストの送信、応答の受信、結果の分析などの 1 つ以上のテスト ステップが含まれます。テストを変更します。実行プロセスなど このツールは、インターフェイス自動化テストとインターフェイス パフォーマンス テストをサポートし、Jenkins との継続的統合テストもサポートします。

5. インターフェーステスト用の Java コード

自動インターフェイステストにコードを使用する理由は何ですか? ツールの機能には制限があり、多くの企業ではツールでサポートされていない特定の機能が必要なため、コードを使用して開発する必要があります。一般に、Java は自動テストに使用されます。主に httpclient.jar パッケージを使用し、次に JUnit や TestNG などの単体テスト ツールを使用してテスト ケースを開発し、継続的統合テスト用に Jenkins または aone でジョブを作成します。

6. インターフェイステスト用の Python コード

Java と同様に、インターフェースのテストに Python を使用する場合は、インターフェース自動化のユースケースを簡単に作成できる強力なサードパーティ ライブラリである Requests を使用できます。Python での単体テスト フレームワークは通常、unittest を使用します。テスト レポートを生成するには、通常、HTMLTestRunner.py を選択します。同様に、Jenkins を使用して継続的統合テストを行うことができます。

インターフェーステスト自動化の実践

TestNG と JUnit の比較

  • 総合的な比較

私が日々のテスト業務で使用する最も自動化されたテスト ツールはインターフェイス テスト用の Java コードですが、ここではまず単体テスト ツール TestNG と Junit の比較を紹介します。まず、表を使用してそれらの特性の比較をまとめます。

TestNG と JUnit の類似点は次のとおりです。

1. すべてに注釈があります。つまり、すべてが注釈を使用しており、注釈のほとんどは同じです。

2. 単体テストを実行できます。

3. これらはすべて Java テスト用のツールです。

TestNG と JUnit の違いは次のとおりです。

1. TestNG は、@ExpectedExceptions、@DataProvider などのより多くのアノテーションをサポートします。

2. JUnit 4 では、@BeforeClass メソッドと @AfterClass メソッドを静的に宣言する必要があり、メソッドで使用される変数が静的に制限されます。TestNG の @BeforeClass によって変更されたメソッドは、通常の関数とまったく同じにすることができます。

3. JUnit は IDE を使用してのみ実行できます。TestNG はコマンド ライン、ant、および IDE で実行できます。

4. JUnit 4 は非常に依存しており、テスト ケース間には厳密な順序があります。前のテストが失敗した場合、後続のすべての依存関係テストは失敗します。TestNG は @Test の dependOnMethods 属性を利用してテストの依存関係を処理します。メソッドが失敗したメソッドに依存している場合、そのメソッドは失敗としてマークされずにスキップされます。

5. n 個の異なるパラメーターの組み合わせをテストするには、JUnit 4 は n 個のテスト ケースを作成する必要があります。各テスト ケースで完了するタスクは基本的に同じですが、メソッドのパラメーターのみが異なります。TestNG のパラメーター化されたテストでは、1 つのテスト ケースのみが必要です。その後、必要なパラメーターを TestNG xml 構成ファイルに追加するか、@DataProvider メソッドを使用してさまざまなパラメーターを挿入します。この利点は、パラメータがテスト コードから分離されており、プログラマでなくても、テスト コードを再コンパイルせずにパラメータを変更できることです。

6. JUnit 4 のテスト結果は緑/赤のバーに反映されます。緑/赤のバーに加えて、TestNG 結果にはコンソール ウィンドウとテスト出力フォルダーも表示されます。テスト結果はさらに詳しく説明されています。エラーを見つけやすくなります。

最後に、私の記事をよく読んでくださった皆様に感謝申し上げます。ファンの増加と注目度を見ると、常に礼儀があります。それほど価値のあるものではありませんが、使用できる場合は直接受け取ることができます!

ソフトウェアテスト面接文書

私たちは高給の仕事を見つけるために勉強しなければなりません。以下の面接の質問は、アリババ、テンセント、バイトなどの一流インターネット企業の最新の面接資料からのものであり、バイトの上司の中には権威ある回答をしている人もいます。 set 面接情報に基づいて、誰もが満足のいく仕事を見つけることができると思います。
 

ここに画像の説明を挿入します

おすすめ

転載: blog.csdn.net/myh919/article/details/132918727
おすすめ