ここでは白、黒ホワイトペーパーのレコードをテストするインタフェースである、を取得
1.インターフェイス？大きく二つに分け
（1）内部システム・インタフェースの言葉が最初にログインする必要性に注意を払うに（私はハハ理解します）
得るためにインターフェイスを介してサーバから情報を取得する（2）外部システムインタフェース
HTTP APIウェブサービスインターフェースとの差にインタフェース（HTTP Webサービスとインタフェースの記事を参照）
テストの観点から外部へのWebサービス・インターフェースは、HTTP要求パケットとリターンメッセージを介して、SOAPプロトコル伝送を取るxml形式は、我々はテストを通じて呼び出しを行うためのツールを持って、テスト
HTTPプロトコルはメソッド呼び出しを区別するためにパスを通過することで、要求パケットが戻りメッセージ通常、JSON文字列の形式でキーと値があり、他の取得するための方法およびポストは、最も一般的に使用される2つの方法が要求されている、あります
（3）前端と後端
メインページのフロントエンドと達成するために簡単なチェック、論理機能の後端を実現するために、
（4）インタフェース試験手順
ビジネス需要に精通まず、ニーズ調査、
第二に、インタフェース文書を提供するために開発
第三に、書き込みテストケースインタフェース
第四に、例の評価
第五に、ティモシーテスト開始テスト
第六に、テスト報告書を提出
（5）インターフェースは、従属インターフェースドキュメントをテスト
界面少なくとも含む文書：1、2インターフェース仕様、コールのURL 3、要求メソッド（\ポストを得る）4、要求パラメータ、パラメータ・タイプ、要求パラメータの説明5、リターンパラメータ記述（役割同様の要件文書）
（6）試験HTTPインターフェイス
直接パラメータをスプライスされることができ、要求インターフェイスを取得
URL？PARAM =疑問符の前で値＆PARAM2 =値これは最も単純なものですが、パラメータ＆複数のを接続するためにリクエストのパラメータ名と値が続き、要求URLです
参照にJSON文字列は、郵便配達要求インタフェースなどのツールを使用する必要性は、この時点でもありです
（7）HTTPステータスコード
各問題httpリクエストした後、応答があるでしょう、HTTP自体は、要求が成功したかどうかを示すステータスコードを持っていますが、一般的なステータスコードは次のとおりです。
この要求を表明している1200の先頭に2は、最も一般的にはOK、サーバも返される要求に代わって、200で、成功しています。
2300図3は、この要求が別の場所にリダイレクトされ、リダイレクトの始まりは、最も一般的には302で表し、
400は403ではない、このページ404に代わって、このページにアクセスする権限を持っていなかった、認証なしで訪問したページ401人の代表、構文エラーがあり、クライアントから送信された3400個の要求を表し、
4,500初めにサーバ5の代わりに異常がある、異常な内部サーバ500のデリゲート、504には、結果を返さない、サーバ側のタイムアウトを表します
SOAPUI〜（8）テストツールWebサービスインタフェース
それをテストする方法Webサービス・インターフェース、彼はメッセージに行くためにあなたを必要とせず、Webサービスに取り組む、WSDLファイルまたは直接SOAPUIに、あなたはWebサービス内のすべてのインターフェイスを見ることができ、メッセージがあり、直接塗りつぶし引数、それを見るために結果を返します
（9）インタフェーステストケース設計
あなたが正しい結果を返すことができる場合、検証することで、そのインタフェースの文書のパラメータは、通常の着信します
インタフェースの安全：1は、検証バイパス、例えば、商品を購入する、その価格は$ 300、その後、私は私が3元には、この商品の価格を入れ、オーダーを提出、何のバックエンドの検証はありませんGenghen。ポイントは、私は、私のバランスではなく、また、増加-3にお金を入れますか？2は、そのようなインタフェースの変更などの許可された製品情報の身元をバイパスし、それは売り手が変更するために取得する必要があり、その後、私は普通のユーザーが成功を変更することはできません渡し、私は合格し、他の売り手の1が正常に3変更することはできません、パラメータは、暗号化されています例えば、私は、ユーザー名とパスワードが暗号化されていない場合は、あなたの要求を傍受そして誰かが、あなたは情報を得ることができるようになりますし、暗号化ルールは亀裂に簡単で、暗号化されていない、インタフェースを上陸させました。小切手4の複雑さ、パスワードのセキュリティルール、パスワード
異常な検証：異常な、私は異常な状況のインターフェイスチェックを検証するために、あなたのインターフェイスのドキュメントの要件に従ってパラメータを入力しない、です。例えば、入ってくる文字列型の整数タイプを入力し、必要なパラメータを記入しない、長さは10、11パスで、要するに、あなたは私が、実際には、さらに3、通過しますしません来るか、と言う来る方法です非必須は、パラメータの型を渡された、パラメータ長
各企業のビジネスは同じではないこと、ビジネスロジックの設計によると、その後、ユースケースを設計するために、独自のビジネスシステムに基づいており、あなたは、特に自社のビジネスを見ているが、実際にこれは、機能テスト設計のユースケースで同じです。例えば、これで、需要の掲示板を掲示板を取る：1、ログインが5回失敗した後、2を記録するために、別の15分を待たなければならない、新たに登録されたユーザーは、インターンシップ3を介してメッセージを投稿することができます必要があり、削除ポストはポイントを控除しました等
