1. インターフェーステストの基礎理論
インターフェイス テスト: インターフェイス テストは、システム コンポーネント間のインターフェイスをテストするためのテストであり、主にシステムと他の外部システムの間のインターフェイス、およびシステム内のさまざまなサブモジュール間のインターフェイスをテストするために使用されます。- 百度百科事典
インターフェース原理: クライアントがサーバーにリクエストメッセージを送信し、サーバーがリクエストメッセージを受信した後に対応するメッセージを判断して最終結果をクライアントに返し、クライアントが返された結果を再度受信して応答するというプロセスをシミュレートします。
検査の焦点: テストの焦点は、インターフェイス パラメーターの転送、インターフェイス関数の実装、出力結果の正確性、およびさまざまな異常状況に対するフォールト トレラントな処理の完全性と合理性をチェックすることです。
インターフェイスの種類: 内部インターフェイスと外部インターフェイス、内部インターフェイスはプログラムによって開発されたインターフェイス、メソッドまたはモジュール間の呼び出し、外部インターフェイスは外部アクセス呼び出しインターフェイス (King Glory の WeChat ログインや支払い機能など) Alipayなどの外部インターフェース。
インターフェイスの分類: webservice インターフェイスと http api インターフェイス、webService インターフェイスは送信に SOAP プロトコルを使用し、http 経由で送信します。HTTP POST の特別なバージョンの 1 つであり、特別な XML メッセージ形式 (要求と戻り値の両方が xml) に従います。 API インターフェイス http プロトコルを使用すると、呼び出しメソッドはパスによって区別され、キーと値のリクエストが使用され、返されるメッセージは通常は json です。
インターフェイスの本質: インターフェイスの本質はパブリック関数クラスであり、データ送信を送受信するためのチャネルとして理解できます。get または post リクエストを送信するとき、実際にはチャネルからデータが送信されます。
テスト範囲: インターフェイス機能、インターフェイスのパフォーマンス、インターフェイスの安定性、インターフェイスのセキュリティなど。
インターフェイス自動テストを学習したい場合は、ここで一連のビデオをお勧めします。このビデオは、ステーション B のネットワーク全体でナンバー 1 のインターフェイス自動テスト チュートリアルであると言えます。同時に、オンラインの数はユーザーが 1,000 人に達し、メモを収集して使用することができます。各種マスターの技術交流: 798478386
2. インターフェーステストが必要な理由
1. コードの最下層を安定化する: 開発の初期段階では、最下層の内容はビジネスレベルで検出できず、コードの最下層は安定性と信頼性が低いため、インターフェースを実行する必要があります。最下層のコンテンツをテストしないと、最下層のコードのエラーにより、さらに外部システムや呼び出しモジュールのミスが発生する可能性があります。
2. 低コストかつ高効率:初期開発とリソース設計が完了していない場合、テスト作業に早期に介入することで問題を事前に明らかにし、品質向上の概念に適合し、大幅かつ効果的にテスト作業を制御できます。テストコストが削減され、インターフェイスは自動化および継続的に統合できるため、より高い長期利益が得られます。
3. テストの範囲が広い:インターフェーステストの多くは、ソフトウェアプロジェクトであってもゲームプロジェクトであっても、ユーザーの視点からシステムインターフェースのあらゆる側面をチェックしてテストします。ビジネス ロジック、つまりインターフェイス テストのテスト中にビジネス テストを支援することもできます。
4. インターフェースのセキュリティの向上: インターフェースのセキュリティのテスト範囲は上記の通りですが、インターフェースのセキュリティに関しては、クライアント側の制限は回避しやすいですが、サーバー側の制限もテストする必要があります。ユーザーのパスワード、ID カード、銀行カード情報などの暗号化された送信。
5. システムの安定性の保証: インターフェイス テストにより、システム間のデータ送信とフォールト トレランスが保証され、システム レベルの安定性が向上します。
要約:
インターフェイステストの利点: 全体的なテスト効率の向上、研究開発テストのコストの削減、製品品質の包括的な向上、フォローアップのメンテナンスリソースの削減。
3. インターフェーステストの実施方法
3.1. インターフェースの開発方法
ビジネスレベル:
一般的なインターフェイス テスト ツール: Postman、Jmeter、SoupUI など。
インターフェイス テスト ツールの原理: インターフェイス テスト ツールを通じてリクエストとデータ受信をシミュレートし、データ送信を実現します。
コードレベル:
インターフェイスの自動テスト: コード実装を通じて、コード アサーションを通じてインターフェイスの正しさを判断するリクエストを送信します。
ps: フォローアップの自動化記事では、教育インターフェース自動化フレームワークの構築、継続的インテグレーションなどについて説明します。
3.2. インターフェースのテストプロセス
実際のプロジェクト作業では、インターフェーステストのプロセスは大まかに次のステップに分かれています(企業によってプロセスに多少の違いがあります)。
1. 企業がインターフェイス テストの要件を持っている場合、またはテスト担当者がインターフェイス テストのタスクを受け取った場合、インターフェイス テストのプロセス段階に正式に介入し始めます。
2. 開発者はインターフェイスドキュメントを提供し、テスト担当者はインターフェイスドキュメントを入手した後、まず要件ドキュメントに精通し、各インターフェイスの機能と関連情報を理解します。(サーバーのアドレスとポート、リクエストメソッド、リクエストパラメータ、制約、戻りステータスコードなどが含まれますが、これらに限定されません)
3. テスターは要件文書を理解した後、テストケースの作成に介入しますが、ビジネステストと同様に、正常および異常なリクエストパラメータと、対応する応答メッセージデータの正確性を考慮する必要があります。
4. 最後に、Postman、Jmeter などのインターフェイス テスト ツールを使用してユース ケースを実行できます。例: Jmeter は最初にスレッド グループを確立し、http リクエストを追加し、関連するリクエスト アドレス、ポート、パラメータを要求し、パラメータ化を設定します アサーションを追加し、最後に実行前に結果ツリーを追加します Postman と Jmeter の原理は同じですが、操作方法が異なります ここでは詳しく説明しません 興味のある友人関連するツールの説明書や情報をオンラインで見つけることができます。
5. 操作が完了したら、インターフェイスが通過するかどうかを確認します。インターフェイスのテストが失敗した場合は、最初のステップとして、リクエストのメソッドやパラメータなどの情報に誤りがないかどうかを確認します。エラーがなければ、ネットワーク環境に問題がない場合は、インターフェース自体に問題がある可能性がありますので、まずはご自身の認識でフロントエンドの問題かバックエンドの問題かを判断してください。すべての確認が完了するまで、船荷の情報が開発部門に送信され、関連するログ情報が添付されます。ビジネス インターフェイスのテストのプロセスでは、不合格のインターフェイスにさらに注意が払われることになりますが、インターフェイスの自動化のプロセスでは、品質向上とレポート出力のためのテストに合格したインターフェイスにも注意を払う必要があることに注意してください。
3.3. インターフェースのテスト要件
インターフェイス要件ドキュメントのコア要素には主に次のものが含まれます。
文書の表紙:表紙は、xx 社のインターフェース要件文書であり、社名と会社のロゴがあり、機密文書であること、要件文書のバージョン番号、文書の作成日などが記載されています。
改訂記録:通常は表の形式で、少なくとも改訂版と改訂日、改訂の説明、改訂担当者、レビュー時刻、レビュー担当者などが含まれます。
インターフェースの説明:インターフェースのアクセスアドレス形式、インターフェースアドレスの例、戻り結果の説明など。(ステータスコードと関連コメント)
インターフェース情報:モジュール名、サブモジュール、業務説明、インターフェース名、リクエストメソッド、リクエストフォーマット、レスポンスフォーマット、リクエストパラメータ、結果説明、戻り例など。
インターフェース情報の対応する情報によって生成されるコンテンツを簡単に紹介します。
モジュール名: ログイン、支払いなど。
サブモジュール名: WeChat ログイン、QQ ログイン、携帯電話番号ログイン
事業内容:インターフェースの機能を簡潔にまとめたもの
インターフェース名:
/login/wechat,/payment/personal
リクエスト方法:GET/POSTなど
リクエスト形式: application/x-www-form-urlencoded
応答形式: application/json
リクエストパラメータ:携帯電話番号、ログインパスワード(変数名、型、説明、コメント、必須かどうかを含む)
結果の説明: パラメーターの内容、変数名、タイプ (文字列など)、戻りステータス コードなど。
戻りの例: 成功した戻りの例 (以下の 4.4 インターフェースのデモの図に示す)
会社のインターフェイスドキュメントに従うことができます。
3.4. インターフェースのデモンストレーション (王の栄光、エンタープライズ WeChat インターフェースのデモンストレーション)
著者はここで、インターフェースを理解し、インターフェースの要件と手順を理解するのに役立ついくつかのインターフェースをデモンストレーションします~
キングインターフェイスの栄光は次のようになります。
英雄のリスト:
インターフェースアドレス:
https://pvp.qq.com/web201605/js/herolist.json
リクエストメソッド:GET
入力パラメータ: なし
出力パラメータ:
返される結果 (部分表示):
エンタープライズ WeChat インターフェイスは次のように表示されます。
ファイルアップロードインターフェース:
素材は、media_id を取得するためにアップロードされます。この ID は 3 日間のみ有効です
media_id は、アップロードされたファイルに対応するロボットによってのみ使用できます
リクエストメソッド:POST(HTTPS)
インターフェースアドレス:
https://qyapi.weixin.qq.com/cgi-bin/webhook/upload_media?key=KEY&type=TYPE
マルチパート/フォームデータの使用
ファイルをアップロードするための POST、ファイル識別名は「media」です
パラメータの説明:
POST リクエスト パケットでは、form-data のメディア ファイル識別子に、ファイル名、ファイル長、コンテンツ タイプなどの情報が含まれている必要があります。
filename は、ファイル表示の名前を識別します。たとえば、この media_id を使用してメッセージを送信する場合、表示されるファイル名はこのフィールドによって制御されます。
リクエストの例:
役職
https://qyapi.weixin.qq.com/cgi-bin/webhook/upload_media?key=693a91f6-7xxx-4bc4-97a0-0ec2sifa5aaa&type=file HTTP/1.1
コンテンツ タイプ: multipart/form-data; 境界=---------------------------acebdf13572468
コンテンツの長さ: 220
------------------------acebdf13572468
コンテンツの配置: フォームデータ; 名前=「メディア」;ファイル名=「wework.txt」; ファイル長=6
Content-Type: application/octet-stream
私のテキスト
------------------------acebdf13572468–
戻りデータ (パラメータは渡されません):
{
「エラーコード」: 44001、
「errmsg」: 「空のメディア データ、ヒント: [1638347756075722279950035]、IP から: 183.14.133.153、詳細については https://open.work.weixin.qq.com/devtool/query?e=44001」
}
3.5. インターフェースのテストケースの設計
ユースケース設計フォーマット:
ユースケースのシリアル番号: プロジェクト名_モジュール名_シリアル番号
インターフェースモジュール: ヒーローリスト、サマナースキル、WeChatログインモジュール、音声モジュールなどの対応するインターフェースモジュール。
リクエストメソッド: 通常、リクエストメソッドは GET、POST です。
インターフェイス アドレス: 通常、インターフェイスの自動テストを容易にするための固定アドレス形式があります (図の完全なアドレス)。
インターフェイス パラメーターの入力: 一部のインターフェイスではインターフェイス パラメーターの入力が必要ありませんが、一部のインターフェイスではインターフェイス入力が必要です。その場合は、入力するだけです。
ユースケース設計の重要なポイントと懸念事項:
(1) サーバーに送信されたリクエストデータが正しいかどうか。
(2) サーバーからクライアントに返されたデータが要件と一致しており、期待を満たしているかどうか。
(3) データベース内のインターフェイスが対応する機能を実装しているかどうかを確認します。
(4) インターフェースの応答時間が要件文書の要件を満たしているか
インターフェイスのユースケース設計の考慮事項の範囲:
1. ビジネス機能:機能が実現されているかどうか
2. ビジネスルール: 定義された説明が期待を満たしているかどうか
3. リクエストパラメータ: パラメータの長さ、サイズ、形式など。
4. 異常なシナリオ: パラメータ渡し例外、操作例外、サービス例外など。
5. データ送信:データ送信結果の正確性
6. インターフェースのパフォーマンス: 同時実行性などの正しいインターフェースのパフォーマンス。
7. インターフェースのセキュリティ: 支払い、リチャージインターフェースのデータ改ざんなど。
ps: 上記の範囲では、少なくとも期待どおりに、インターフェイスのユースケース カバレッジとコード カバレッジも考慮する必要があります。
3.6、バックエンドインターフェイスのテスト内容
いわゆるインターフェーステストですが、バックエンドインターフェースではどのような内容がテストされるのでしょうか?次の図は、いくつかのヒントになります (画像はインターネットからのものです)。
さて~以上がこの記事の内容ですが、理解できましたか?ご質問がある場合は、必ずメッセージを残して相談してください~