、定義されました
インターフェイスのテストプログラムは、インターフェイスが実際にさまざまなデータベースを操作している、外部インターフェースを測定しています。
フロント：顧客のバックエンドを含むクライアント のバックエンド：サーバー側
注意：
通常、フロントエンド（言語開発HTML / CSS / JS、等）、後端が一般使用インタフェースを介して相互作用するので、なぜなら言語障壁の、（ジャワ/ PHP / Pythonのを）。
インタフェースは、データを返さ：一般的なデータ型のJSONタイプ（すべての言語を解決することができます）
インターフェイスのテストでは、ドキュメントをインタフェースしなければならない、インターフェイスのドキュメントは、次のパラメータを含める必要があります。
- URL
- リクエストモードポスト、取得
- パラメータ（パラメータ要求）
- リターン・パラメータ
あなたがうまく書けば、それは以下の2点を持っているでしょう
- リクエスト例、模範的なまたはリターン
- それは状態を示しています
あなたが要求を取得した場合は、ツールの助けを借りずに、直接ブラウザに送信することができます。インターフェイスのテストは、いくつかのバグ運転ページを見つけることができます見つけることができない、早く見つけるバグ解決コストが低くなっているバグを、機能テスト・プロセスとのインタフェースのテストは同じです。
展開 1：リクエストとPOSTリクエストの差分を取得
httpリクエスト
リクエストヘッダ
リクエストボディ（リクエストボディのライトパラメータ）
一般的に取得するための要求を取得し、リクエストヘッダを取得する唯一のリクエストURLパラメータに上やクッキーの内側に書き込むことができるデータ、データを送信するためのPOSTリクエストを。3xxの（同様の転送コールする：リダイレクトは別のページ、ステータスコードをページにあります）。4XXは存在しないパスを表します。
Requestパケットは、URLとパラメータを実行することができ、直接一緒にスプライス
ポストマンは、GETとPOSTリクエストのリクエストを追加します
、HTTPは、最も一般的に、PUTの（増加）4があります使用されているサーバーと対話するためのさまざまな方法、[削除（削除）、ポスト（変化する）、取得（チェック）、すなわち、CRUDを定義しています。
1）あなたは、彼はちょうどそれがこのような観点から、サーバー上のデータを変更しないことを意味し、クエリデータを取得し、気にし、情報を取得するために使用され、取得し、それはデータのセキュリティであり、後述します投稿には、データを変更することが可能であるので、これは両者の違いの一つです。
2）ポストは、それがサーバーを変更するには、サーバーを変更する要求を送信することができ、例えば、我々はポストを使用して、フォーラム、ブログのコメント、でHuitieたい、もちろん、それだけでデータを得ることも可能です。
3）データを削除するには削除します。これは、Get /ポストによって達成することができます。
4）入れて、増加したデータ配置、/ポストを取得することによって達成することができます。
展開 2：どのようにテストをインターフェイスしますか？
私たちのプロジェクトは主にフロントに基づいており、背面側が呼び出すためのインタフェースhttpプロトコルを、そのテストインタフェースは、httpリクエストをシミュレートするために主に使用さJMeterのツールです。
送信と受信。
インタフェースのテストを行う前に、私たちの最初のステップは、テスト要件を分析し、提供するために開発取得することです APIドキュメントを、
ステップ2：から APIドキュメント（主に上院と参照パラメータと明確な形式とチェックポイントの詳細含む）インタフェースのテストケースを選別
第三段階：インターフェースとテストケースレビューの開発と、
ステップ4：上院とパラメータデータに、準備のインターフェイスのテストケースの開発ライブラリを組み合わせ、およびに編成ファイルcsv形式。
ステップ5：インタフェースのテストケースのドキュメントと合わせ、インタフェースのテスト環境、準備のテストケースを作成し、データをCSVファイル形式を。
第二に、本実施形態インターフェイスデザイン
図1は、ログイン・モジュールのインターフェイスは、図に詳細なテスト：
デザインモデルは次のよう：
通常の検証：
確認によって（インターフェイス文書のアップロードパラメータに従って、結果を介して見ることができます）
認証パラメータの組み合わせ（追加製品、変性物、など）
異常検証：
ないインタフェースの文書に必要な入力パラメータに
2、ポートセキュリティ
1.バイパス認証（例えば、価格に任意の数で提出財受注を購入します）
身元確認をバイパスする2.許可（普通のユーザーがビジネス情報を変更するかどうか）
3。パラメータは、（ユーザー名はプレーンテキストで表示されている場合は、パスワードを、または暗いテキスト表示するかどうかをクラックするのは簡単です）、暗号化されています
4.パスワードの安全規制、パスワード検証の複雑さ
2 、ポストマンインタフェース試験例
（Firefoxブラウザのお気に入りを参照してください）
インターフェース・テストユースケースのデザイン 1：呼び出され得る黒の学生情報
API インタフェースのドキュメントを参照してください： http://doc.nnzhp.cn/index.php?s=/6&page_id=11
インターフェース文書仕上げニーズがある学生の情報を取得します
http://api.nnzhp.cn/api/user/stu_info?stu_name=黒
リクエストの方法は、stu_name =黒のパラメータを取得し、次のように郵便配達員の動作を参照してください。
インタフェースのテストケースの設計2：すべてを取得学生の情報を
（このインタフェースは、ヘッダ情報を追加する方法を示すことです）
インタフェース情報：
次のように郵便配達テスト結果のスクリーンショットである:(一時的に失敗し、それは、物品の供給源であってもよい間違っています）
インタフェースユースケースデザイン3：ログインインタフェースのテスト
スクリーンショット郵便配達次のように：
インターフェイスのテストケース4：追加学生情報の例
パラメータの型が何であるか、一般的なインタビューは引数はJSONデータ型を渡されたとき、これを言うことができます
在postman的截图如下：
需要说明的是 Headers(1) 原本没有(1)显示的，是在选择了传入的参数时json类型后： JSON(application/json) 后才自动显示的。
接口测试用例设计5：上传文件
上传的文件类型为 .txt文件，这个可以在测试用例的时候考虑进去，将文件的类型作为一个测试对象，如上传 .xls .docx 格式的文件是否能够上传
在postman的截图为:
接口测试用例设计6：学生金币充值
这个涉及到用户安全性，所以一般来说需要验证用户身份，使用cookie身份登录：
参照测试用例3，先获取cookie信息：
请求成功后可以从获得的body数据中取得用户的values值：也就是sign值：e31f748108a8f33231bc1b52e87c064e
接着再以cookie方式登录，然后添加金币即可：
所以第一步先在Header头部中添加cookie信息(cookie是在请求头部中添加，其它数据在body)：
然后第二步在请求体body中添加：
最后发送请求得到的数据如下：
这步由于来源cookie问题没试验成功，参考文章在：http://www.mamicode.com/info-detail-2220006.html