リテラシーの内容:
1. インターフェースとは何ですか?
2. どのような種類のインターフェースがありますか?
3. インターフェースの本質は何ですか?
4. インターフェーステストとは何ですか?
5. インターフェーステストとは何ですか?
6. インターフェーステストはどのように行うのですか?
7. インターフェーステストポイントとは何ですか?
8. インターフェイステストではどのような知識を習得する必要がありますか?
9. その他の関連知識は?
インターフェイス テストの実践的なチュートリアルの完全なセット:ゼロ基礎から習熟まで、ステーション B の最初の推奨事項はコレクションする価値があります。
1. インターフェースとは何ですか?
インターフェイス テストは主に、外部システムと内部サブシステム間の対話ポイントに使用され、特定の対話ポイントを定義し、これらの対話ポイントを通じて、いくつかの特別なルール、つまりプロトコルを通じてデータ交換対話を実行します。
2. どのような種類のインターフェースがありますか?
インターフェースは一般に 2 つのタイプに分類されます。 1. プログラムの内部インターフェース 2. システムの外部インターフェース
システムの外部インターフェイス: たとえば、他の Web サイトやサーバーからリソースや情報を取得したい場合、他の人は絶対にあなたとデータベースを共有しません。彼らは、データを取得するために作成したメソッドを提供することしかできません。インターフェイスは、データ共有の目的を達成するために、彼が書いたメソッドを使用できます。
プログラム内のインターフェース: メソッド間、モジュールとモジュール間の対話、bbs システムなどのプログラム内でスローされるインターフェース、ログイン モジュール、投稿モジュールなどがあり、必要な場合は最初にログインする必要があります。 post, then this 2 つのモジュールは対話する必要があり、内部システムが呼び出すためのインターフェイスをスローします。
インターフェースの分類: 1. Webサービスインターフェース 2. http APIインターフェース
webService インターフェイスは、soap プロトコルを介して http 経由で送信されます。リクエスト メッセージと返信メッセージは両方とも XML 形式であり、テスト時に呼び出しとテストに渡すツールのみを使用します。
http API インターフェイスは、http プロトコルを使用してパスを介した呼び出しを区別します。リクエスト メッセージはキーと値の形式であり、返されるメッセージは通常 JSON 文字列です。get や post などのメソッドがあり、これらも最も一般的に使用されます2つのリクエスト方法。
JSON は、すべての言語で認識されるユニバーサル データ型です。(jsonの本質は文字列です。他の言語とは何の関係もありません。少し処理した後にのみ他の言語のデータ型に変換できます。例えば、Pythonでは辞書に変換できますが、 Key-Valueの形式はJavaScriptではネイティブに変換できます（オブジェクト、Javaではクラスオブジェクトに変換可能など）
3. インターフェースの性質とその仕組みは何ですか?
インターフェイスは URL であると簡単に理解できます。動作原理は、URL が get または post リクエストを通じてサーバーに何かを送信し、対応する戻り値を取得することです。本質はデータの送受信です。
4. インターフェーステストとは何ですか?
インターフェイス テストは、システム コンポーネント間のインターフェイスをテストするテストの一種です。インターフェイス テストは主に、外部システムと内部サブシステム間の相互作用ポイントを検出するために使用されます。テストの焦点は、データの交換、配信と制御管理のプロセス、およびシステム間の相互論理依存関係を確認することです。
簡単に言うと、送信したいデータをサーバーや他のモジュールなどの URL 経由で送信し、期待したものが返されるかどうかを確認することです。
5. インターフェーステストとは何ですか?
1. バグの発見が少ないほど、修理コストが低くなります。
2. フロントエンドは自由に変更可能、インターフェースはテスト済み、バックエンドは変更不要 フロントエンドとフロントエンドは 2 つのグループによって開発されます。
3. システムのセキュリティと安定性を確認します。フロントエンド パラメータは信頼できません。たとえば、京東ショッピングでは、フロントエンド価格を -1 元で渡すことはできませんが、インターフェイスを通じて -1 元を渡すことはできます。
4. 今日のシステムの複雑さは増大し続けており、従来のテスト方法のコストは急激に増加し、テスト効率は急激に低下しています。この場合、インターフェイス テストが解決策を提供します。
5\. インターフェイス テストは、自動化された継続的インテグレーション を実現するのが比較的容易であり、UI 自動化と比較して比較的安定しているため、手動回帰テストの人件費と時間を削減し、テスト サイクルを短縮し、バックグラウンド テストの迅速なリリースをサポートできます。終了要件。インターフェイスの継続的統合は、低コストと高収益の根本原因です。
6. 現在、多くのシステムのフロントエンド [アーキテクチャ] (http://lib.csdn.net/base/architecture) がセキュリティ レベルから分離されています。
(1) フロントエンドのみに依存して制限するとシステムのセキュリティ要件を満たすことができなくなり（フロントエンドをバイパスするのが非常に簡単になるため）、バックエンドも制御する必要があります。 、インターフェースレベルから検証する必要があります。
(2) また、特に ID カードや銀行カードなどのユーザーの個人情報に関わる場合、フロントエンドおよびバックエンドの送信やログの印刷などの情報が暗号化されて送信されているかどうかも検証する必要があります。
6. インターフェーステストはどのように行うのですか?
– 私たちのプロジェクトのフロントエンドとバックエンドの呼び出しは主に http プロトコルのインターフェイスに基づいているため、インターフェイスをテストするときは、主にツールまたはコードを使用して http リクエストの送受信をシミュレートします。postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary など、多くのツールがあります。
– インターフェイスの自動化、つまりコードによっても実現できます。フレームワークは UI の自動化に似ており、送信リクエストはアサーションによって判断されます。
7. インターフェーステストポイントとは何ですか?
目的: インターフェイスの正確さと安定性をテストする。
原理: クライアントがサーバーにリクエスト メッセージを送信し、サーバーがリクエスト メッセージを受信した後に対応するメッセージを処理してクライアントに応答を返し、クライアントが応答を受信するプロセスをシミュレートします。
ポイント: データ交換、転送、制御管理プロセス (プロセス数を含む) を検討する。
コア: 継続的インテグレーションはインターフェイス テストの中核です。
利点: 効率的な欠陥監視と品質監視機能を非常に複雑なプラットフォームにもたらします。プラットフォームが複雑になるほど、システムが大規模になり、インターフェイス テストの効果 (テスト効率の向上、ユーザー エクスペリエンスの向上、研究開発コストの削減) がより顕著になります。
ユースケース設計の重要なポイント: 通常、最も外側の 2 つのインターフェイスが主にテストされます。データ入力システム インターフェイス (システムで使用するために外部システムのパラメーターを呼び出す) とデータ アウトフロー システム インターフェイス (システムによって処理されたデータが適切であるかどうかを検証する) です。普通）;
PS: ユースケースを設計する際には、外部インターフェースがそのインターフェースを使用する外部ユーザーにどのような機能を提供するのか、また外部ユーザーが本当に必要とする機能は何なのかにも注意を払う必要があります。
質問 1. テストされたバックエンド インターフェイスは何ですか?
– この質問に答えるには、インターフェイス テスト アクティビティの内容の観点から始めることができます。下の図を見てください。これは基本的に、プロジェクトの現在のバックエンド インターフェイス テストの主な内容を反映しています。
質問 2. バックエンド インターフェイスは 1 回テストされ、フロントエンドも 1 回テストされますが、テストは繰り返されますか?
– この質問に答えるために、インターフェイス テストの内容とアプリ側のテスト アクティビティを直接比較できます。次の図は、アプリ テスト中にカバーまたは考慮する必要がある内容を示しています。
上の 2 つの図を比較すると、2 つのテスト活動の同じ部分には機能テスト、境界解析テスト、パフォーマンス テストが含まれており、他の部分は異なる特性や懸念事項により特別なテストが必要であることがわかります。ここで議論されます。次に、上記の 3 つの部分の同じ内容を分析します。
1. 基本機能テスト:
このテストは基本的なビジネス機能を対象としているため、この部分は 2 つのテスト間で最も重複する部分であり、開発者は通常この部分を参照します。
2. 境界分析テスト:
基本的な機能テストに基づいて入出力の境界条件を検討しますが、この部分には繰り返し部分（ビジネスルールの境界など）も含まれます。ただし、フロントエンドの入出力は、ユーザーが選択できる固定値 (ドロップダウン ボックスなど) を提供することが多く、この場合、テストの境界範囲は非常に制限されますが、テストにはそのような制限はありません。比較的広い範囲をカバーできるインターフェースのテストであるため、同様にインターフェースに問題が発生する可能性も高くなります。
3. 性能テスト:
どちらもパフォーマンス テストが必要ですが、焦点はまったく異なります。アプリ側のパフォーマンスは、携帯電話の CPU、メモリ、トラフィック、fps など、携帯電話に関連する機能に主に焦点を当てています。インターフェイスのパフォーマンスは、主にインターフェイスの応答時間、同時実行性、サーバー リソースの使用量に焦点を当てます。2 つのテストの戦略と方法は大きく異なるため、コンテンツのこの部分は個別にテストする必要がありますが、理論的には、これも異なる部分です。
まとめ：
1. インターフェイス テストとアプリ テストのアクティビティには、主にビジネス機能のテストに焦点を当てた、いくつかの繰り返しの内容が含まれています。また、それぞれの特性に応じた試験が異なるため、製品全体の品質を確保するためには、目的を絞った試験を個別に実施する必要があります。
2. インターフェイス テストではサーバー ロジックの検証に重点を置くことができ、UI テストではページ表示ロジックとインターフェイス フロントエンドおよびサーバー統合の検証に重点を置くことができます。
3. インターフェーステストの継続的統合:
インターフェイステストは継続的インテグレーションの自動化が中心的な内容であり、自動化によってのみ低コスト、高歩留まりを実現できます。現時点では主に回帰ステージで使用されるインターフェースの自動化を実現していますが、今後は以下のような自動化の度合いを強化する必要があります。
a) プロセスの観点: 回帰段階では、インターフェイス例外シナリオの対象範囲が強化され、徐々にシステム テストおよびスモーク テスト段階まで拡張され、最終的に完全なプロセス自動化が達成されます。
b) 結果表示: より豊富な結果表示、傾向分析、品質統計と分析など。
c) トラブルシューティング: エラー メッセージとログがより正確になり、問題の再現とトラブルシューティングが容易になります。
d) 結果検証：データベース情報検証などの自動検証機能を強化する。
e) コード カバレッジ: コード カバレッジを向上させるために、現在のブラック ボックスからホワイト ボックスへのドロップを常に試みます。
f) パフォーマンス要件: パフォーマンス テスト システムを改善し、自動化された手段を通じてインターフェイスのパフォーマンス インジケーターが正常であるかどうかを監視します。
4. インターフェーステストの品質評価基準：
a) ビジネス機能の範囲が完全かどうか
b) ビジネスルールが完全にカバーされているかどうか
c) パラメータの検証が要件（境界、ビジネスルール）を満たしているかどうか
d) インターフェース例外シナリオの網羅が完了しているかどうか
e) インターフェースのカバレッジが要件を満たしているかどうか
f) コードカバレッジが要件を満たしているかどうか
g) 性能指標が要件を満たしているかどうか
h) 安全指標が要件を満たしているかどうか
8. インターフェイステストではどのような知識を習得する必要がありますか?
① システムとさまざまな内部コンポーネント間のビジネス ロジックの相互作用を理解する。
②インターフェースのI/O（入出力：入力と出力）を理解する。
③ 通信原理、スリーウェイハンドシェイク、よく使われるプロトコルの種類、メッセージ構成、データ送信モード、共通ステータスコード、URL 構成など、プロトコルの基本的な内容を理解する。
④一般的なインターフェイス テスト ツール: jmeter、loadrunner、postman、soapUI など。
⑤基本的なデータベース操作コマンド（データ保存の確認、テストデータの抽出など）。
⑥ 一般的な文字タイプ: char、varchar、text、int、float、datatime、string など。
これらのスキルを学ぶにはどうすればよいでしょうか?
①システム間のビジネスインタラクションロジック：要件文書、フローチャート、マインドマップ、コミュニケーションなどの多くのチャネルと方法を通じて。
②プロトコル：内容が鮮やかで比較的入門書的な『図解 http』がオススメですが、他には『図解 tcp・IP』などもあります。
③インターフェイス テスト ツール: Baidu でこれらのツールを入手すると、多くの教育ブログ、関連する問題解決策、ツールベースの本が見つかります。もちろん、適切な本を選択することが非常に重要です。
④ データベース操作コマンド: 学習 Web サイト (W3C、新人チュートリアル)、教育ブログ、データベース関連の書籍、入門レベルの推奨事項: 「mysql は知っておくべき」、「oracle PL/SQL は知っておくべき」など。
⑤キャラクタータイプ：やはり百度、内政で迷ったら百度に聞け、外交で迷ったらグーグルに聞けという諺もあります。。。
インターフェイス関連の情報を取得するにはどうすればよいですか?
一般的な企業では、アドレス、パラメータの種類、メソッド、入力、出力などのインターフェースに関する情報を記載したインターフェースドキュメントを開発者や対応する技術者が作成しますが、そうでない場合は入手方法を工夫します。。。
インターフェース文書の 8 つの要素:
表紙:表紙は、ロゴ、コンテンツ タイトル、バージョン番号、会社名、文書作成日が記載された会社指定の表紙であることが望ましい。
改訂履歴:バージョン、改訂の説明、改訂日、改訂担当者、レビュー時期のレビュー担当者などが含まれる表形式の方が優れています。
インターフェイス情報:インターフェイス呼び出しメソッド、一般的に使用される GET/POST メソッド、インターフェイス アドレス。
機能の説明:インターフェイスの機能を簡潔かつ明確に説明します。たとえば、インターフェイスの取得にどのような情報が含まれないか。
インターフェイス パラメータの説明:各パラメータは、大文字と小文字を含め、実際の呼び出しと同じである必要があります。パラメータの意味は簡潔に説明されており、形式は文字列、整数、または長さなどです。
説明部分では、パラメータ値を指定する必要がある場所を説明し、タイムスタンプ、期間、パラメータが必須かどうか、一部のパラメータは必須であり、一部はオプションのパラメータなど、パラメータの生成方法を詳しく説明します。 、など。
戻り値の説明:
① テンプレートの戻り値を用意し、各戻りパラメータの意味を説明するのが最善です。
②実際の呼び出しインターフェイスと実際の戻り値を提供します。
通話制限、セキュリティ面:
暗号化方式、または自社の特別な暗号化プロセスを使用しても、双方が一貫した暗号化アルゴリズムを採用している限り、共通の md5 などのインターフェイス呼び出しのセキュリティを確保するためにインターフェイスを呼び出すことができます。
文書の保守: 文書を保守する際、変更があった場合は、変更日と変更者を記載し、大幅な変更の場合はバージョン番号を変更する必要があります。
9. その他の関連知識は?
取得リクエストとポストリクエストの違いは次のとおりです。
1. GET は URL または Cookie を使用してパラメータを渡します。一方、POST は BODY にデータを置きます。
2. GET の URL には長さ制限があり、POST のデータは非常に大きくなる可能性があります。
3. データがアドレス バーに表示されないため、POST は GET より安全です。
4. 一般に、get リクエストはデータの取得に使用され、post リクエストはデータの送信に使用されます。
実際、上記の点のうち、最後の点だけが信頼性が高くなります。最初の点は、post リクエストでも URL にデータを配置できるということです。get リクエストには実際には長さの制限はありません。post リクエストには暗黙的なパラメータがあるようです。 . 少し安全ですが、これは初心者向けです. リクエストを投稿しても、パケットをキャプチャすることでパラメータをキャプチャできます。(違いはこれだけで、上記3点は正確ではありません)
httpステータスコード:
先頭の 1、200、および 2 はすべて、リクエストが正常に送信されたことを示します。最も一般的なのは 200 で、リクエストが正常に完了し、サーバーが戻ったことを意味します。
2. 300 と 3 で始まるものはリダイレクトを表します。最も一般的なのは 302 で、リクエストを別の場所にリダイレクトします。
3. 400 400 は、クライアントから送信されたリクエストに文法エラーがあることを意味します。401 は、アクセスされたページが許可されていないことを意味します。403 は、このページへのアクセス許可がないことを意味します。404 は、そのようなページが存在しないことを意味します。
4. 5 の先頭の 500 はサーバーに例外があることを意味し、500 は内部サーバー例外を意味し、504 はサーバーがタイムアウトして結果が返されないことを意味します。
Webサービスインターフェイスをテストする方法:
メッセージのスペルを入力する必要はありません。Web サービスのアドレスまたは wsdl ファイルが提供され、soapui に直接インポートできます。この Web サービスのすべてのインターフェイスが表示され、メッセージが表示されます。パラメーターとメッセージを直接入力します。呼び出して、返された結果を確認するだけです。
天気予報 wsdl アドレス: http://www.webservicex.net/globalweather.asmx?wsdl
Cookie とセッションの違い:
1. Cookie データはクライアントのブラウザに保存され、セッション データはサーバーに保存されます。
2. Cookie はあまり安全ではないため、ローカルに保存されている Cookie を分析して不正行為を行う可能性があります。
セキュリティを考慮するとセッションを使用する必要があります。
3. セッションは一定期間内にサーバーに保存されます。アクセス数が増えるとサーバーのパフォーマンスが圧迫されます
サーバーパフォーマンスの低下を考慮して、Cookieを使用する必要があります。
4. 1 つの Cookie によって保存されるデータは 4K を超えることはできず、多くのブラウザでは、サイトで保存できる Cookie は 20 個までに制限されています。
5. そこで私の個人的な提案は次のとおりです。
ログイン情報などの重要な情報をセッションとして保存
他の情報を保持する必要がある場合は、Cookie に保存できます。
私の記事を注意深く読んでくださった皆さんに感謝します。あまり価値のあるものではありませんが、使用できる場合は持ち帰っても構いません。
これらの資料は、[ソフトウェア テスト] の友人にとって、最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。そして、あなたにも役立つことを願っています。
情報取得方法：
