アウトライン
私は子供の靴の多くをインタビューし、これらの年をテストしました。私は、テストへのインタフェースが何であるかを尋ねたほとんどの人は、について話します：私はJMeterを/郵便配達200が渡された場合でも、応答結果で、あなたのために見て、要求を送信します。あなたは200ダウンしていない場合は、開発を投げ問題があります。それをテストするためのインタフェースである最後のレポート！
それから私は、インタフェースのタイプ何を頼みますか？インターフェイスのデザインシーンどうやって？インターフェイスの設計方法を使用する場合？インタフェースの応答コードは何？フロントエンドとバックエンドのインターフェイスと対話する方法？学生は頭を悩ま始めたとき、3番目の質問は、脳がダウンタイム、しばしば聞かれます。
したがって：いくつかのインタフェーステスト理論的な知識が必要ですああ追加！
インターフェースは何ですか？
一般的に言えば、2つのインターフェイスがあり、一つは、一つは、システムの外部インターフェイスで、内部手続きインターフェースです。プラグイン・インターフェースとの間の通信;モジュール間のインターフェースと、次に小さなクラスがメソッドを提供し、広く、クライアントとバックグラウンドサービスの間のプロトコルを話すするインターフェースとして理解することができます。
システムの外部インタフェース：
当社のウェブサイト上またはサーバーや情報からリソースへのアクセスは、ウェブサイトは確かにあなたにデータベースを共有しない場合、それは我々はそれが提供するインタフェースを参照してデータを取得することができ、データを取得するために書かれた方法を提供します。
内部手続きインタフェース：
これは、インターフェイスをスローする方法及びその方法、モジュールとモジュールの間の相互作用だけでなく、内部の手順の間です。たとえば、Webプロジェクトは、これらのモジュールは、インタラクティブになるなど、削除、変更、追加、ログインを持っている、それが内部コール用インタフェース・システムがスローされます。
インターフェースの組成
完全なインタフェースは、次が含まれている必要があります。
1.インターフェース
2.コールURL
3.リクエストメソッド（GET \ポスト）
4.リクエストパラメータ、パラメータの種類、リクエストパラメータ
5.リターンパラメータ説明
インターフェースは、少なくともアドレス要求、リクエストメソッド、リクエストパラメータ（パラメータ及びパラメータ）、リクエストヘッダが存在するインターフェースの最初の部分であるべきです。ヘッダは、HTTPプロトコルのサーバは、文字列、一般の店舗クッキー、トークン及び他の情報を送信する前にデータのHTMLブラウザを通過させることです。
ヘッダおよびパラメータが異なっています。ヘッダ一般ストア要求をサーバに許可要求を持っていることを確認するようなクッキーのような確認情報の一部です。それは、サーバは、要求アドレスは一緒にパラメータとともにサーバーに送信されることを要求する権限を持っている場合、サーバは、アドレスとパラメータへの参照を返します。言い換えれば、サーバは、要求が許可要求を持っているかどうかを判断するためにヘッダー情報を受け入れるように裁判官が権限を持っていた後、要求およびアドレスパラメータを受け入れるです。
共通のインターフェイスタイプ
1、WebServiceのインタフェース
それは、石鹸とHTTPプロトコルの伝送を使用して、要求パケットとリターン・メッセージはXML形式は、我々は、テスト時のツールを使って呼び出すことができます。あなたはツールSOAPUI、JMeterのを使用することができます。
2、HTTP-APIインタフェース
これは、メソッド呼び出しを通るパスを区別するために、httpプロトコルを使用して要求パケットは、キーと値の形態であり、パケットは一般的にJSON文字列、または二つの最も一般的な方法の要求であるGETとPOST、とのように返します。あなたはツールの郵便配達、JMeterをなどを使用することができます。
3、ダボインタフェース
それが使用するRPC転送プロトコルは、一般にマイクロサービスで使用され
フロントエンドとバックエンド
フロント
のは、Webページを使用してみましょう、Webサイトを開き、フロントエンドです。Webページ、WebパフォーマンスとインタラクティブなWebレベルの実装の外観の構造を含みます。
バックエンド
私たちは、このような追加など、ページ、これらのビジネス・ロジック、機能、上で操作するときは、これらの機能は、バックエンドで実装されている、削除、変更します。その他のバックエンドデータベースのは、対応するビジネスロジックとの相互作用を処理します。考慮すべき機能、アクセス、安定性とパフォーマンスのデータプラットフォームを実装する方法です。
前端と後端は、インターフェイスを介して対話します。フロントページには、バックエンドのインターフェースを呼び出すことによって、データへのアクセスを機能を実現するために、データは、ユーザの目の前に表示されています。
インターフェイスのテスト定義
1、インターフェイステストは、システムコンポーネント間のインタフェースを試験する試験方法であって、
外部システムとの間のシステムおよびシステム内の様々なサブシステム間の相互作用を検出するために使用される2、
図3に示すように、フォーカスは、データをチェックするように切り替え、およびシステム間の論理的な相互依存関係れます
図4は、それぞれのインタフェース試験により、異なるテストが決定する場合に参加のパラメータ情報であるか否かを適切な機能、安全性の要件を満たすように適合インターフェース。
インタフェースのテスト意義
1は、システムの複雑さが上昇し続ける、従来の試験方法及び試験効率のコストの大幅な増加はそれほどインターフェーステストを行う、大幅に低下しました。
図2は、テストは、インターフェイスを実装することは比較的容易です。そして、インターフェースの自動化UIオートメーションも比較的安定。急速な反復をサポートし、手動回帰テストの時間と労力、コストを削減し、テスト・サイクルを短縮します。
図3に示すように、フロント及び多くのシステムの後端が分離され、セキュリティレベルので、フロントエンドにのみ依存するセキュリティ要件（先端が容易にバイパス）を満たすことができないシステムを限定することを有し、後端部はまた、検証される必要がありますケースからインターフェイスのレベルを確認することが必要です。フロントと送信を暗号化し、伝送、ログや印刷情報の後端部はまた、お金、識別情報として、特に利用者の個人情報に関連して、検証する必要があります。
バリュー・インタフェースのテスト
1、以前の問題を特定
早く発見のバグ、修理のコストを下げるためのテストは、プロジェクトの初期の開発に関与すべきです。しかし、機能テストは、テストシステムは、システムをテストするためのインタフェースを提供するまで待たなければなりません。関数インタフェースを開発する前に、インタフェースのテストは、システムをテストすることができます。システムインタフェースは、上部機能の基礎であり、インターフェイスは、問題を見つけて解決するために、以前より費用対効果をテストすることができます。しかし、実際の開発プロセスでは、開発者は、ライトユニットテストに十分な時間を持っていない、と彼らはしばしば、私はそれを書かれているコードの信頼を失っている、ユニットテストを書くことに時間を費やす必要はありません。この時間は、インタフェースのテストの役割がより重要になるだろう。
2、短縮、製品開発サイクル
製品開発サイクルのために、すべてのテスト作業は、機能テスト段階に焦点を当てている場合。質問のテストおよび修理サイクルが長くなります。テストは、以前の製品開発に介入することができるので、従って、有効に機能バグステージの数を制御することができ、効果的に製品開発サイクルを短縮します。
3、より根本的な問題を発見しました
システムの基本的なロジックの一部がトリガー簡単UI機能検査ではありません、ロジックは問題となる可能性があります。インターフェイスのテストは、それがより簡単に、より包括的なこれらの基本的なロジックをテストすることができます。
4、サーバーの例外処理機能をチェックします
機能テストのレベルに立って唯一のこの時間は、いくつかのセキュリティ問題を発見することは困難であるならば、それは簡単に、回避することができるので、通常、弱い検証フロントエンド検証と呼ばれます。機能への入口インターフェース・テストとしてこれらの異常いることを確認することは非常に容易になりません。
一般的な要求
GETとPOSTリクエスト
あなたが要求を取得した場合、ブラウザに直接入力するリクエストがポストに送られた場合、あなたは、長い要求はブラウザ内部で直接することができるようとして、すべてのGETリクエストは、その後、我々はツールを使用することができます。
GETとPOSTリクエストの違い
図1は、URLまたはクッキー質量参加を用いてGET。BODYでPOSTデータ。
2、POSTデータが非常に大きくなることが、GETのURLの長さに制限があるでしょう。
3、GETセキュリティよりもPOST、データがアドレスバーに表示されませんので。
図4に示すように、一般的に、データPOSTを送信するための要求データを取得するための要求を取得します
よくある質問：
（1）パラメータ誤用プログラム例外を通過します。
（2）オーバーフローのタイプ、一貫性のないデータの読み書きをもたらします。
被験者がアクセス許可を確認しなかったので、（3）、他のユーザーが機密情報にアクセスすることができます。
（4）状態誤用ロジックが混乱です。
（5）チェックロジック不完全、不適切な利益を得る悪用される可能性があります
インタフェースデザインのテストシナリオ
1.インタフェース仕様書をチェック
2.チェックコネクタフロント
3.インタフェースロジックチェック機能を実装
4.チェック要求パラメータの合法性
リクエストの確認パラメータの属性
例外処理要求のパラメータを確認してください6。
7.確認応答構造部材
応答データの正しさを確認するための8
9.異常応答
前記画像検査応答
11.の古いバージョンの互換性を確認してください
12.ビジネスロジックをチェックする権限の役割
ロジックをチェックし、依存関係13.動作パラメータ
インターフェイスのテストプロセス
-
実際には、プロセス・インターフェース・テストおよび機能テストのプロセスは、主目標は、要求仕様に依存し、従って、最初のニーズの評価プロセスに関与していると同様です。
-
ニーズを識別した後、インタフェース設計のニーズに応じて開発され、それはインタフェースの定義を与えます。開発・設計プロセスでは、テストは、設計のためのいくつかの提案を与えるテスト容易性を向上させ、デザインのニーズのために、テストプログラムを指定することができます。
-
現像後、完全なインターフェイス定義、要件文書とマップとインターフェイスの定義に基づいてテストケースを設計する必要があります。ビジネスシーン、機能、および異常なテスト側面からの主なテストケースの設計上の考慮事項。
-
テストケースの設計が完了した後、確認のためのテストケース。テスターは、インターフェースFBIの開発の初期段階に介入することができます。
-
プロジェクトの終わりに、各プロジェクトの概要の必要性。
インタフェースの応答ステータスコード
詳細HTTP要求のステータスコード
使用ASP.NET/PHP/JSPまたはJavaScriptがHTTPの異なる状態で使用される、いくつかの一般的なステータスコード：200 - サーバーが正常にページ404を返された - サービスは使用できません - 要求されたページは、503が存在しません。
1XX（暫定応答）が暫定応答状態を示し、コードの動作を継続するリクエスタが必要
-
100（続き）リクエスタは、要求を継続する必要があります。サーバーは、このコードは、要求の最初の部分が受信されたことを示し、残りを待って返します。
-
101（プロトコル切り替え）リクエスタプロトコルを切り替えたサーバは、ハンドオーバを承認され、サーバを必要とします。
（成功）の2xxが正常要求のステータスコードを処理して発現します
-
200（成功）サーバーは要求を正常に処理しました。一般的に、この手段サーバは要求されたページを提供すること。
-
201（作成された）要求が成功したとサーバが新しいリソースを作成しました。
-
202（受け入れ）サーバーは要求を受け入れたが、まだ処理されていません。
-
203（非信頼できる情報）サーバが正常に要求を処理したが、他のソースからのものであってもよい情報を返しています。
-
204（コンテンツなし）サーバが正常に要求を処理していないが、任意のコンテンツを返していません。
-
205（リセットコンテンツ）サーバーはリクエストを正しく処理しましたが、任意のコンテンツを返しません。
-
サーバ206（の一部）は正常部分GETリクエストを処理しました。
3XX（リダイレクション）さらなるアクションが必要とされる、要求を満たすために示しています。リダイレクションのための一般的に、これらのステータスコード
-
リクエスト300（選択）、サーバは、様々な動作を行うことができます。サーバは、に従って選択リクエスタ（ユーザエージェント）を操作する、または要求者が選択するためのアクションのリストを提供することができます。
-
301（永久移動）恒久的に要求されたページは新しい場所に移動されました。サーバはこの応答（GETまたはHEAD要求に対する応答）を返し、それが自動的に転送し、リクエスタ新しい場所へ。
-
Webサーバからの要求に302（一時移動）応答は、現在、別の場所であるが、要求者は、将来の要求のために元の場所を引き続き使用する必要があります。
-
303サーバがこのコードを返し、別の場所にGET要求を分離すべきである応答を取得するためにリクエスタ（他の場所を参照）。
-
304最後の要求以来（変更不可）、要求されたページが変更されていません。サーバはこのレスポンスを返すと、そのページのコンテンツには戻りません。
-
305（使用プロキシ）要求者にのみ、プロキシを使用して、要求されたページにアクセスすることができます。サーバはこの応答を返した場合、それは、リクエスタエージェントを使用すると述べました。
-
307現在位置から別のWebページからの要求に（一時的なリダイレクト）サーバの応答が、要求者は、将来の要求のために元の場所を引き続き使用する必要があります。
4XXこれらのステータスコードは、要求が間違っている可能性があることを示す（要求エラー）、処理サーバが妨げ
-
400（不正なリクエスト）、サーバは、要求の構文を理解していませんでした。
-
401（不正な）要求は認証を必要とします。ログインが必要なページの場合、サーバーは、この応答を返すことがあります。
-
403（禁止）サーバーは要求を拒否します。
-
404（見つからない）サーバーは要求を見つけることができません。
-
要求で指定された405（方法無効）メソッドが無効になっています。
-
406（受け入れられない）が要求されたページに応答して要求されたコンテンツの特性を使用することはできません。
-
407（プロキシ認証が必要）このステータスコード401（許可されていない）が、要求者がプロキシの使用を許可することを指定します。
-
タイムアウトは、要求408（リクエストタイムアウト）サーバーを待って発生した場合。
-
サーバは要求を完了する際に競合409（コンフリクト）が発生します。サーバが応答した紛争についての情報を含める必要があります。
-
410（削除済み）要求されたリソースが恒久的に削除された場合、サーバはこの応答を返します。
-
サーバ411（長さ）は、有効なContent-Lengthヘッダフィールドのない要求を受け付けません。
-
412サーバが要求に要求元の前提条件が満たされない場合（前提条件が失敗しました）。
-
サーバが処理するには大きすぎるため、413（リクエストエンティティが大きすぎる）サーバーは要求を処理できません。
-
414（リクエストURIが長すぎる）URI（通常はURL）の要求が長すぎると、サーバが処理することはできません。
-
要求されたページをサポートしていないフォーマットで415（サポートされていないメディアタイプ）要求。
-
416（リクエスト範囲ない充足）ページが要求された範囲を提供できない場合、サーバはこのステータスコードを返します。
-
満たすことができない417（期待値）サーバは、リクエストヘッダフィールドの要件を「所望しました」。
5xxの（サーバーエラー）これらのステータスコードは、要求を処理しようとしているときに内部サーバーエラーが発生したを示しています。これらのエラーは、誤ったサーバーそのものかもしれません
-
500（内部サーバーエラー）サーバーでエラーが発生し、要求を満たすことができません。
-
501（実装されていません）サーバーは要求を完了する必要はありません。たとえば、サーバーがこのコード要求識別方法を返さない場合があります。
-
502（不正なゲートウェイ）ゲートウェイまたはプロキシサーバは、上流のサーバーから無効な応答を受け取りました。
-
（それが過負荷またはメンテナンスのためにダウンしているため）、503（サービス利用不可）サーバーは現在使用できません。通常、これは一時的な状態です。
-
ゲートウェイまたはプロキシサーバが、要求として504（ゲートウェイタイムアウト）上流のサーバから受信されていません。
-
505（HTTPバージョンがサポートされていない）サーバは、要求に使用されるHTTPプロトコルのバージョンをサポートしていません。
-
511ネットワーク認証が必要（ネットワーク認証が必要）
インターフェイスケースの設計
通常、入力が上院に最も一般的な、時には出力なしでインターフェイス入力出力があります。関連するインターフェースを呼び出し、インターフェースは、関連する処理ロジックを実行します。
例えば試験とのインターフェースの設計、および2つの考慮事項を処理するメインインターフェイスからの入力：
1）入力のために、パラメータ・タイプに応じて設計することができます。
2）インタフェース処理のために、ロジックの実施形態に従って設計することができます。
3）出力、解析の結果と設計について
入力のためのデザイン
インタフェースは、入力が上院です。一般的なパラメータの種類は次のとおりです。
（1）数値（int型、長い、フロート、ダブル、など）
（2）タイプ文字列
（3）アレイまたはリンクされたリスト
（4）構造
可能性のある問題とリスク
-
プログラムの着信非特異的なタイプが予期せず終了しました
-
長い文字がストレージで、その結果、処理されていない、異常表示
-
他のユーザーに敏感な文字セットに見えます
-
配列またはリストタイプ
-
パラメータタイプは、アレイまたはリンクされたリストであり、ユースケースが考えられます
たとえば、バッチジョブ投入インターフェース、設計パラメータは、ユースケースを検討します：
-
正常値：1-5の外側の許可範囲：6権威;
-
境界値：1-35境界値、最大値及び最小許容要請。
-
特殊な値：0;
-
合法と違法なID。
-
重複IDなど。
-
可能性のある問題とリスク：
-
0アイテムプログラムが異常終了します。
-
重複は、処理中に大量のアイテムのような予期しない結果につながりません。
論理設計のための
インタフェースロジックは、論理設計は、以下の使用例観点から分析することができ、いくつかの処理が必要です。
（1）数値限定、制限点、などの制約のレベル。たとえば：Q為替活動は、参加する前に> 50統合が必要
たとえば、ログイン状況など：：（2）状態の制限アカウントでログインするために必要な同期ユーザー情報。
（3）制限付きアクセス：管理者のように。
多くの場合、機能テストをテストする際に遭遇制約は、インターフェースがより重要なテストです。その意義の嘘でユーザが行う操作は、操作の前端が制約を制限されている可能性があり、ユーザが直接トリガ要求インタフェースできない場合。しかし、実際には、他の手段が存在する場合：例えば、直接呼び出しインタフェースへの技術的手段を通じて、これらの条件のための制限は特に重要であるか否かのインターフェースが。
このような一般的な例として：交換がボタンをクリックすることはできませんので、グレーの状態であり、へ5Qの為替は200ポイントが必要ですが、統合の私の不足。しかし、私は、為替への直接呼び出しにフロントエンドインターフェースをバイパスすることができますか？もちろん、期待が転換ではありません。だから、この積分値の制限は、インタフェースのためにテストする必要があり、非常に重要であるだろう。
出力設計のための
実際には、出力は、結果の分析のために設計されているインタフェースを返しました：
出力
インタフェース処理は、唯一の正しい結果である可能性がありますが、エラー異常リターンの結果は、多くの場合、値がたくさんあります。あなたは多くのリターンが結果がある知っている場合は、異なる設計例の結果を使用することができます。我々は、完全にすべてのエラーコードをカバーすることができないかもしれないが、戻りコードに基づいて、返されたインターフェイスは、より多くの定義されたユースケースを設計することができます。
よくある質問とリスクを尋ねました
（1）エラー処理は、異常をもたらす遠位端、遠位端よりも小さいです。
（2）不適切なエラー処理、ユーザが不明瞭なエラーコードを表示させます。
（3）不適切なエラー、何が悪かったのか知らないユーザーを引き起こして、どのように解決します。
残業のためのインタフェースデザイン
インターフェースはそれを返していないので、もし通常の状況下では、インタフェースは、返されますか？そのプロセスは、考慮すべきインターフェースのニーズの試験部分の後も、タイムアウトです。タイムアウトが適切に処理されていない場合は、次のような問題を引き起こすことがあります。
（1）タイムアウト処理を行わない、障害物にプロセス全体の結果
混乱ロジックを発生（2）が得られ、インターフェースにタイムアウト復帰後に受信しました
廃棄物のためのインタフェースデザイン
廃止された契約は、前に定義を意味するが、理由の変化のためか、他の理由のための需要の、一時的に行います。これらのインタフェースは、もはや使用されませんが、それがコードすることが可能になると削除されませんでしたされていますが。あなたは、可能性のあるリスクを技術を使用して、これらのインタフェースを呼び出す場合。そのため、同じ時間の古いバージョンと互換性の新しいバージョンを考慮して、あなたはまた、リスクを回避するために、廃棄物関連のインターフェイスのチェックを行う必要があります。
：一般的な問題やリスク特別な手段を通じて利益を得ることができ、ユーザの原因制約、不足かどうか、。
合理性のためのインタフェースデザイン
インタフェースの合理的な定義は、以下の観点から分析することができるかどうか。
（1）インタフェースフィールドは冗長です。
（2）インタフェースは冗長です。
（3）インタフェースは、呼び出し元に返されるかどうかの情報を受け取ることを期待します。
インタフェースの定義は、すべてのコールのニーズを満たすか否かを判断する（4）。
（5）インタフェース定義コールは便利です。