インターフェーステストツールの詳しい説明

そもそもインターフェースとは何でしょうか?

一般に、インターフェースには 2 種類あり、1 つはプログラムの内部インターフェース、もう 1 つはシステムの外部インターフェースです。
システムの外部インターフェイス: たとえば、他の Web サイトやサーバーからリソースや情報を取得したい場合、他の人はデータベースをあなたと共有することは絶対にありません。彼らは、データを取得するために作成したメソッドを提供することしかできません。提供されているものを引用することができます。彼が書いたインターフェイスは、データ共有の目的を達成するために彼が書いたメソッドを使用できます。たとえば、私たちが使用するアプリや URL は、データを処理するときにすべてインターフェイスを通じて呼び出されます。
プログラム内のインターフェイス: メソッド間の対話、モジュールとモジュール、ログイン モジュールや投稿モジュールなどを備えた bbs システムなどのプログラム内でスローされるインターフェイス。投稿したい場合は、最初にログインする必要があります。ログインすると、これら 2 つのモジュールが対話する必要があり、内部システムが呼び出すためのインターフェイスがスローされます。

【CTI教育ソフトウェア検定】Jmeter暗号化インターフェース検定 ~2023年の転職・昇給に必須の知識~ インタビュー

1. 共通インターフェース:
1. WebService インターフェース: http を介した SOAP プロトコルで送信され、リクエストメッセージとリターンメッセージはいずれも XML 形式であり、テストの際にはツールを使用して呼び出してテストします。使用できるツールには、SoapUI、jmeter、loadrunner などが含まれます。

2. http api インターフェース: http プロトコルを採用し、呼び出しメソッドをパスで区別します。リクエストメッセージはキーバリューの形式です。戻りメッセージは一般に json 文字列です。get や post などのメソッドがあります。これも最も一般的に使用される 2 つのリクエスト メソッドです。使用できるツールには、postman、RESTClient、jmeter、loadrunner などが含まれます。

2. フロントエンドとバックエンド:
 インターフェイスのテストについて話す前に、まずフロントエンドとバックエンドという 2 つの概念を明確にしましょう。
      フロントエンドとは何ですか? Web 側では、使用する Web ページと開く Web サイトはすべてフロントエンドであり、HTML と CSS で記述されます。アプリ側では、使用するアプリ (Android またはobject-C (iOS 上のアプリ開発) によって開発され、その機能は、ページを表示し、美しいページを表示し、ページ上で操作するときに空でない検証などの簡単な検証を行うことです。これらのビジネス ロジックは、 Weibo でのショッピングや投稿などの機能はバックエンドによって実装されます。バックエンドは、ショッピング時の残高の差し引き方法と Weibo の送信先アカウントを制御します。次に、フロントエンドとバックエンドのやり取りはインターフェイスを通じて行われます。 。
      私が前に言ったことを理解できないかもしれませんが、覚えておいてほしいのは、フロントエンドは見た目を美しくする責任があり、バックエンドは家族を養うためにお金を稼ぐ責任があるということです。

3. インターフェイス テストとは:
インターフェイス テストは、システム コンポーネント間のインターフェイスをテストするテストです。インターフェイス テストは主に、外部システムとシステム間、および内部サブシステム間の相互作用ポイントを検出するために使用されます。テストの焦点は、データの交換、伝送および制御の管理プロセス、システム間の相互論理依存関係などを確認することです。

OK、上記は百度百科事典の言うことであり、以下は私が言うことです。

実際、インターフェイステストは非常に単純で、通常の機能テストよりも簡単だと思います(最初に言っておきますが、将来削除する可能性がありますO(∩_∩)O!)。私も、インターフェーステストとは何なのかと多くの人に(たったの2、3人ですが)聞かれましたが、理解できなくてもわかったふりをする態度で、こう言いたいと思います。さまざまな状況下での対応する入力および出力情報インターフェイスが対応する機能要件およびセキュリティ要件を満たしているかどうかを判断するため。

インターフェイス テストは機能テストよりも簡単だとなぜ言えるのでしょうか? 機能テストでは、ページから値を入力し、ボタンやリンクをクリックしてその値をバックエンドに転送します。さらに、機能テストでは、UI、フロントエンドの対話、およびインターフェイスのテストもテストされます。他の機能、ただしインターフェイスのテスト ページはありません。インターフェイス仕様文書の呼び出し元アドレスとリクエスト パラメータを使用してメッセージを結合し、リクエストを送信して戻り結果をチェックするため、受信パラメータと送信パラメータを測定するだけで済みます。 , これは比較的簡単です。

4. インターフェースの構成
インターフェースのコンポーネントは何ですか?

まず、インターフェイス ドキュメントには次のコンテンツが含まれている必要があります。

1. インターフェースの説明
2. 呼び出し URL
3. リクエストメソッド (get\pos​​t)
4. リクエストパラメータ、パラメータタイプ、リクエストパラメータの説明
5. リターンパラメータの説明

インターフェイスのドキュメントから、インターフェイスは少なくともリクエスト アドレス、リクエスト メソッド、およびリクエスト パラメーター (入力パラメーターと送信パラメーター) で構成されている必要があることがわかります。一部のインターフェイスにはリクエスト ヘッダーがあります。

ヘッダー: HTTP プロトコルを使用して HTML データをブラウザーに送信する前にサーバーによって送信される文字列です。ヘッダーと HTML ファイルの間には空行が必要です。通常、Cookie やトークンなどの情報が格納されます。

何人かの学生が、ヘッダーと入力の関係は何ですかと私に尋ねました。すべてのパラメータがサーバーに送信されるわけではありませんか?

OK、まず第一に、これらは確かにサーバーに送信されるパラメーターですが、異なります。ヘッダーに保存されるパラメーターには通常、リクエストにアクセス許可リクエストがあるかどうかを確認するために使用される Cookie などの検証情報が保存されます。がサーバーである場合、サーバーにリクエストを送信し、リクエストアドレスと入力パラメータをサーバーに送信すると、サーバーはアドレスと入力パラメータに基づいて出力パラメータを返します。つまり、サーバーはまずヘッダー情報を受け入れてリクエストに権限があるかどうかを判断し、権限があると判断した後、リクエストのアドレスと入力パラメータを受け入れます。

5. インターフェイス テストを行う必要がある理由:
インターフェイスがバックエンドと対話するためにフロントエンド ページまたは APP によって実際に使用されることは誰もが知っています。そのため、多くの人が「機能テストはすでにテスト済みですが、なぜ?」と尋ねるでしょう。インターフェイスをテストする必要がありますか? OK、この質問に答える前に、例を挙げてみましょう。

例えば、ユーザー登録機能をテストする場合、ユーザー名は英字(大文字と小文字を区別)、数字、アンダースコアを含む6~18文字と規定されています。まず、機能テスト中に、20 文字の入力や特殊文字の入力などのユーザー名ルールが確実にテストされますが、これらはフロントエンドでのみ検証され、バックエンドでは検証されない可能性があります。パケットをキャプチャすることで回避します。フロントエンドの検証に合格し、バックエンドに直接送信された場合はどうすればよいですか? 想像してみてください。ユーザー名とパスワードがバックエンドで検証されず、誰かがフロントエンドの検証をバイパスした場合、ユーザー名とパスワードを何気なく入力することはできないでしょうか? ログインしている場合、SQLインジェクションなどで任意にログインでき、管理者権限も取得できる可能性がありますが、怖くないですか?

したがって、インターフェイス テストの必要性が次のように反映されます。

①. ページ上での操作では発見できないバグが多数見つかります。

② システムの例外処理能力を確認する

③. システムのセキュリティと安定性を確認する

④. フロントエンドは自由に変更可能一度インターフェースをテストすれば、バックエンドを変更する必要はありません。

6. インターフェイス テストのテスト方法:
インターフェイス テストを実施する前に、次のことも理解する必要があります。

1) GET リクエストと POST リクエスト:
    get リクエストの場合はブラウザに直接入力します。ブラウザで直接リクエストできる限りは get リクエストです。post リクエストの場合はリクエストされません。送信するにはツールを使用する必要があります。
GET リクエストと POST リクエストの違い:
    1. GET は URL または Cookie を使用してパラメータを渡します。そしてPOSTでBODYにデータを入れます。
    2. GET URL には長さ制限があるため、POST データが非常に大きくなる可能性があります。
    3. データがアドレス バーに表示されないため、POST は GET より安全です。
    4. 一般に、get リクエストはデータの取得に使用され、post リクエストはデータの送信に使用されます。
実際、上記の点のうち、最後の点だけがより信頼できます。最初の点は、post リクエストでも URL にデータを入れることができるということです。実際、get リクエストには長さの制限はありません。Post リクエストには暗黙的なパラメータがあるようです。若干安全ですが、初心者向けです 投稿リクエストを行ってもパケットをキャプチャすることでパラメータを取得できます。したがって、面接中に上記のことを言ってください。

2)、httpステータスコード

各 HTTP リクエストが発行されると、応答が返されます。HTTP 自体には、リクエストが成功したかどうかを示すステータス コードがあります。一般的なステータス コードは次のとおりです: 1. 200 と 2 で始まるものは、リクエストが正常に送信されたことを示します
一般的なのは 200 で、これはリクエストに問題がなく、サーバーがリクエストを返したことを意味します。
2. 300 3 はリダイレクトを意味し、最も一般的なのは 302 で、リクエストを別の場所にリダイレクトします。 3.
400 400 はクライアントによって送信されたリクエストに構文エラーがあることを意味し、401 はアクセスされたページが承認されていないことを意味します。このページにアクセスする権限がないことを示します。404 はそのようなページがないことを意味します
。4. 500 はサーバーに例外があることを意味します。500 はサーバーに内部例外があることを意味します。504 はサーバーがタイムアウトしたことを意味し、結果は返されていません。

次に、インターフェイス テストのテスト方法について説明します。

1). 一般的なインターフェースの使用例の設計

①. 通過性検証: まず、インターフェイス関数が使いやすいかどうか、つまり通常の通過性テストを行う必要があります. インターフェイス文書のパラメータに従って、パラメータが正常に渡されていれば、正しい結果が得られます。返される。
② パラメータの組み合わせ: 製品を操作するためのインターフェースが存在します。フィールドのタイプがあります。1 を渡すと、製品の変更を意味します。プロダクト ID、製品名、価格のいずれかが必須です。タイプが 2 を渡す場合、商品の削除を意味します 商品 ID を渡す必要があります この場合、パラメーターの組み合わせをテストする必要があります type が 1 を渡した場合、商品名のみが正常に変更できるかどうか ID、名前、価格の場合すべて合格したかどうか、変更が成功するかどうか。

③. インターフェースのセキュリティ:
     1. 認証をバイパスします。たとえば、商品を購入し、その価格が 300 元である場合、注文を送信するときに商品の価格を 3 元に変更します。バックエンドでの認証はありますか? ?さらに残酷な話ですが、お金を-3にしても残高は増えますか?
     2. ID 認証をバイパスします。たとえば、製品情報インターフェイスを変更するには、販売者が変更する必要があります。したがって、一般ユーザーにそれを渡しても、変更は成功しますか? 別の販売者に渡したら、変更は成功しますか? 3. パラメータが暗号化されているかどうか
     ? たとえば、ログインするインターフェイス、ユーザー名とパスワードが暗号化されている場合、暗号化されていない場合、他の人が傍受した場合にあなたの情報を取得できます。暗号化ルールは簡単に破られますか?
     4. パスワードセキュリティルール、パスワードの複雑さの検証

④. 例外検証:
いわゆる例外検証とは、インターフェースの例外検証を検証するために、インターフェース文書の要件に従ってパラメーターを入力しないことを意味します。たとえば、必要なパラメータを入力しない場合は、整数型を入力し、文字列型を渡し、長さが 10 である場合は 11 を渡します。つまり、その方法を教えていただければ、私はそうします。実際には、渡さなければならないタイプは、パラメータのタイプ、入力パラメータの長さの 3 つだけです (オプションで渡されます)。

2) ビジネスロジックに基づいてユースケースを設計する
ビジネスロジックに基づいてユースケースを設計するということは、自社のシステムの業務に基づいてユースケースを設計することです。各社のビジネスは異なるため、自社のビジネスに特化して検討する必要があります。 、これも機能テスト設計のケースと同じです。
    例えばbbsを例に挙げると、bbsの要件は以下の通りです 1.
    5回ログインに失敗した場合、再ログインまで15分待つ必要がある
    2. 新規登録ユーザーはインターンシップ期間を過ぎていること3.投稿を
   削除すると減点されます
   4. ...
   このように、これらのテスト ポイントをリストし、データ テストに対応するテスト ポイントを作成する必要があります。


7. インターフェイスのテストにはどのようなツールを使用すればよいですか? インターフェイスのテストには、postman、RESTClient、jmeter、loadrunner、SoapUI など、さまざまなツールがありますが、最もお勧めするテスト ツールは postman と jmeter です 。インターフェイスのテストにはこれら 2 つのツールを使用しますが、その他のツールは今回は紹介しません。

1) Postman は Google のインターフェイス テスト プラグインで、使い方が簡単で、ユース ケース管理、取得、投稿、ファイル アップロード、応答検証、変数管理、環境パラメータ管理などの機能をサポートしています。バッチを作成し、ユースケースのエクスポートをサポートします。

jmeter は、100% 純粋な Java で書かれた無料のオープン ソース ツールです。主にパフォーマンス テストに使用されます。loadrunner と比較して、使用するメモリが少なく、無料でオープン ソースで、軽量で便利で、インストールは必要ありません。大衆の間でますます人気が高まっています。

注: 以下の使用例で使用されるアドレスはすべて私のローカル環境に基づいており、外部ネットワークからアクセスすることはできません。

①. ユーザー情報の取得: このインターフェースは、userid を通じてユーザー情報を取得するために使用されます。

リクエストアドレス: http://192.168.1.102:8081/getuser

リクエストメソッド:POST/GET

       入参:

出力:

  postmanでのリクエストは以下の通りです

 jmeter でのリクエストは次のとおりです。

 

 ②. ユーザー情報の取得: ヘッダー、Content-Type application/json を追加する必要があります

1.1 リクエストアドレス

http://192.168.1.102:8081/getuser2

1.2 リクエスト方法

取得/投稿

1.3     入参

 1.4 送信パラメータ

 postman テストは以下の通りです。今回の入力パラメータは json 型です。もちろんドキュメントには json を使用しなければならないとは書かれていません。他の方法も可能です。

 

  jmeterテストは次のとおりです

 ③.ユーザーバランス変更2

1.1 機能説明

機能の説明: Cookie を追加する必要があります。トークントークンはハードコードされた token12345 です。

1.2 リクエストアドレス

http://192.168.1.102:8081/setmoney2

1.3 リクエスト方法

役職

1.4    入参

 1.5 送信パラメータ

   郵便配達員の試験は次のとおりです。

 jmeter テストは次のとおりです。

 

 

 ④ファイルアップロード

郵便屋さん:

jメーター:

 

 ⑤. リクエストWebServiceインターフェース

以下に示すように、webService インターフェイスをリクエストするために必要なツールは SoapUI です。

 

 jmeter でのリクエストは次のとおりです。 

最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。

 

おすすめ

転載: blog.csdn.net/2301_76643199/article/details/132902104