入門
「インターフェイスのテストは、」非常にハイエンドの人々は、特に学生はまだ始まったばかりのテストの目的を得るために、用語を考えます。検査技術を深化し続けでは、「インターフェース・テストは、」増加する周波数のビジョン私たちのフィールドに表示されます。そして、最終的には、インタフェースのテストは行う方法ですか？インターフェース・テストの利点は、どのような分野にも反映されていますか？
インターフェースは何ですか
外部と内部のサブシステム間のシステムとシステム間の相互作用のポイント：インターフェイス - Baiduの百科事典は、文を引用しました
内部プログラム・インターフェース、システムの外部インターフェイス：インターフェイスは、一般的に二つのタイプに分けられます。
1.システムの外部インタフェースは：例えば、最も一般的なシステムの外部インターフェース- Alipayの支払インターフェースは、多くのアプリの決済機能が支払いを行うためにAlipayの支払インターフェースを起動され、このインターフェイスは、外部システムアリペイシステムへの呼び出しを提供することです
。2.プログラム内部インターフェース：な淘宝網のモールなどのモジュールとモジュール間の相互作用、購入品に、あなたが最初の注文を配置する前にログインする必要があり、ログイン間の受注が対話的で、この相互作用は、プログラム内の他のモジュールを許可するためのインタフェースでありますコール。また内部手続きで直接インタフェースメソッド呼び出し。例えば、前景と背景の電子ビジネスプラットフォームのフロントデスク、HTMLやCSSやJSの技術と他の開発者の間で、インターフェース呼び出し、JAVA、Pythonや他の言語と背景開発スタッフ、フロントデスクからユーザーの入力データであれば、どのようにデータが戻ってそれを送信しますか？データ転送は、主インタフェース試験の一部でGETまたはPOST HTTPプロトコル要求、の前後端部によって達成されます。
一般的なタイプ
1.webServiceインタフェース：石鹸を通過するHTTP伝送プロトコル、要求パケットと復帰のメッセージはXML形式です。あなたは、テスト、テストのツールを介して起動する必要があります。いくつかの企業はまだ、病院や他の産業として、インタフェースのこの種を使用しています。
2.http APIインタフェース：HTTPメソッド呼び出しパスで区別離れプロトコル、および要求パケットは、キーと値の形態である、パケットは、一般的のようなGETとPOSTとJSON文字列を返します。今のところ、最も一般的に使用されます。例えば、HTTPプロトコルとしてRESTfulなベースのインターフェイス。
3.dubboインタフェース：直接ソケット通信を使用してリモート呼び出しのためのRPCプロトコルを使用して、外出先RPCプロトコル、。高い伝送効率、およびシステムの統計との関係、コール数を呼び出すことができます。Java言語の開発を使用して、唯一のJava言語のプロジェクトの開発との間の通信に使用することができ、それは、クロスランゲージ、クロスプラットフォームの機能を持っていません！
4.ハードウェアインターフェース：USB、充電ポート（ここでは説明しません）
インターフェイスのタイプ、あなたは私の他の記事を参照することができます：DjangoのWebインターフェイスの開発
前方及び後方端部との間の差
インターフェイスは、2つの概念、フロントとリア理解する必要があり、前にやってテストし
、私たちが見るような、通常のWebアプリ、データの役割の先端の先端のためのコンテンツを表示するためには、簡単なデータ検証を行うには：1.前面を淘宝網のモール、など、これらの商品情報、フォトギャラリー。
2.リア：フロントとリアの両端に相互作用インタフェースを介してその一方、複雑なビジネスロジックの計算、達成するための機能は、例えば、私たちは商品の購入価格を計算し、プロモーションの使用は、最終的な支払いは、バックエンドの実装を介して行われA。
インタフェースのコール図
説明：すなわち、入力条件は、インタフェースプログラムを処理した後、出力結果が得られたパケットの基準、即ち基準パケット。
インタフェースのテストとは何ですか
システム・コンポーネント間のインタフェースのテストを：Baiduの百科事典は言って引用されています。主に他のシステムにサービスを提供するように適合され、検出システムと外部システム、および様々なサブシステム、検査データ交換、伝送、管理及び制御プロセスの内部点の間の相互作用、およびシステム間の相互の論理的依存性との間基礎となるフレームワークおよびシステムサービスセンタシステムは、外部システムへの主試験システムのインタフェースを提供例えば、その正確性と安定性を検証します。
言うようにインターフェイスのテスト：
1.インターフェイステストすなわち機能テストは、テスト入力条件によって、インターフェースは、結果が予想される結果と一致している返します。
2.インターフェースは、クライアントとサーバーを接続するために使用され、返されたデータは、一般的なインターフェイスJSON形式です。
3.テストインタフェーステストデータは、実質的な、様々なデータベース操作（追加、削除、変更、検索）です。
4.インターフェースのテストは、実際にブラックボックステストブラックボックスとしてのインターフェースを処理するビジネスロジックは非常に単純なプロセスである、我々は何が適切な結果を生む、入力条件の多様性を考慮する必要があります。
試験インタフェースそのブラックボックス
インターフェイステストはブラックボックステスト、ブラックボックステスト、必ずしもそうではないだけのインタフェースのテストです。
そして、我々はまた、機能テスト、インタフェースのテストと機能テストとして知られているブラックボックステストは、それがすべてではないことを知っていますか？答えはノーです、なぜですか？機能テストはまた、UI層手順、を含む、ボタン、インタラクティブUI機能、及びテスト動作のインターフェースを、インターフェースを呼び出すことによって試験することができるページでないと、インターフェースは単に対応する入力条件を与えて送信され、その後、インターフェースを確認しています結果は、出力が期待を満たしていることができます。ある程度までは、インターフェイスは機能テストのいくつかよりも、単純にテストします。
インターフェースの組成
1.インタフェースのドキュメント。
2.インタフェースのURL。
3.リクエスト方法：郵便またはGET
4.要求パラメータ、パラメータ・タイプ、記述パラメータ要求。
5.リターンパラメータ。
文書から見たインターフェース、インターフェースは、インターフェースの最初の部分を有する少なくともアドレス要求、リクエストメソッド、リクエストパラメータ（パラメータ及び参照）、リクエスト・ヘッダーがあり、クッキーであるべきです。
ヘッダ（ヘッダ）：HTTPプロトコル・サーバーは、文字列を送信する前に、ブラウザのHTMLにデータを渡すために、依然としてヘッダ及びHTMLファイル、一般的な店舗クッキー、トークンとその他の情報との間の空白行の分離を必要とします
だから、ヘッダおよび上院には行うには何がありますか？彼らは、サーバーに送信されたすべてのパラメータんでありませんか？
まず、彼らが実際にパラメータでサーバーに送信されますが、それらが異なるされ、ヘッダに格納されているパラメータは、クッキーなどの一般的な店舗パリティ情報の一部は、ある、それは要求をサーバに許可要求を持っていることを確認することです、存在する場合、それは、次に、要求アドレスが一緒パラメータと共にサーバに送信され、サーバは、サーバは、アドレスおよびパラメータへの参照を返すことを要求することができます。言い換えれば、サーバは、要求が許可要求を持っているかどうかを判断するためにヘッダー情報を受け入れるように裁判官が権限を持っていた後、要求とアドレス上院を受け入れるです。
なぜインタフェーステストを行います
私たちは、描画することにより、プログラム（UI層）のフロントエンドは、表示データと単純なデータの検証が、バックエンドのビジネス・ロジックの本当のコアに使用されていることを知っています。
伝統的な機能テストではなく、フロントエンドフロントエンドエンジニアが行って作業する場合、我々はテストを展開することはできませんテスト作業は、他の一方で、フロントエンドチェック機能ので、機能のバックエンドデータを欠場する可能性が高いですチェックすると発生する可能性のある主要な問題について、直接私たちのプログラムは、フロントエンド、バックエンドの操作をバイパスすることにより、ユーザのキャプチャ。
だから、テストインタフェースは、主な理由は以下のとおりです。
- テストはできるだけ早くコストがかかる、早く介入をテストし、問題が最も低い解決することが判明。何度もの開発者は、テストが仕事は、待機状態での時間のほとんどがあるだろうとせず、インタフェースのテストは、フロントエンドインターフェースなしでテストすることができ、完全な製品テストを提出する必要はありません
- フロントは、事前チェックの制御を持っているので、インタフェースのテストは、問題の多くは、フロントで見つけることができない見つけることができるので、バックエンド機能の検証が前にテストすることは困難です
- テスト効率を高め、人件費やマニュアル回帰テストの時間コストを削減し、短縮テストサイクル
メリットテストのUIインターフェーステストと比較
- インタフェース早く介入をテストし、以前の介入より高い値。
- より安定したインターフェースのテスト、変化が少ないです。インスタントフロントエンドの問題を通してテストインタフェース、それらを解決することは非常に高速になります
- 試験後インターフェイス、低コストの溶液中の欠陥を発見しました。より根本的な欠陥、より広範な表面の影響、底欠陥が、それらを解決するため、Nの表面上の欠陥を引き起こす可能性が非常に面倒になり、必ずしも欠陥の源を見つけることができません
- より正確かつ迅速に問題を見つけます。我々は機能試験を通じてインタフェースをテストしたときに問題に表示され、それは界面層のうちの干渉を除外されているように、我々はより迅速かつ正確に、問題を見つけることができます。
インターフェイスのテストプロセス
機能テストとのインタフェース試験の原理は同じであり、それは実際に機能テストプロセスとフローの基本的に同じです。
インターフェイステストは等しくないインタフェーステストツールであります
多くの人々は、インタフェース・テスト・ツールを使用してテストをインタフェースすると思うだろう。実際には、はるかに多くのテストツール、SOAPUIイェジンハオ、JMeterのイェジンハオインタフェースの使用よりも、これらのツールは、テストにそれが容易になり、当社のインターフェーステストプロセスですが、ツールが唯一のツール、実際のテストケースのコアまたはインタフェースであります思考の設計およびテスト。我々は最終的には、インタフェースのテストを行うときに何の仕事、その後に行われる必要がありますか？
テストプロセスをインタフェース：
- 取得要件文書およびインターフェースのドキュメント
- 要件の分析を通じて、ビジネス要件とビジネス・ロジック・インターフェースの境界を文書化
- インターフェイス文書インタフェース仕様（インターフェースアドレス、要求のモード、パラメータ、パラメータ）の分析によって
- （インターフェースのテストデータの準備に焦点を当てた）インタフェースのテストケースの設計
- インターフェース・テスト・ツール・インターフェース・テストを使用して
- 界面欠陥管理と追跡
- 自動化された継続的な統合インタフェース
共通のインタフェース・テスト・ツール
こうした郵便配達、JMeterは、LoadRunnerのように、多くのためのツールをテストするインターフェース、SOAPUI他、より一般的には郵便配達してJMeterのです。はじめに以下の郵便配達とJMeterの。
1.Postmanは、ユースケース管理、サポートのget /ポスト、ファイルのアップロード、レスポンス認証、変数管理、環境パラメータ管理やその他の機能をサポートし、インタフェースのテストプラグインで、シンプルを使用してGoogleのであるあなたは、バッチ実行をすることができ、およびユースケースのエクスポートをサポートし、インポート。
2.jmeterは100％純粋なJavaで書かれた無料のオープンソースのツールですが、それは主に、インストールすることなく、軽量で便利な、その小さなメモリフットプリント、フリーでオープンソース、より多くの公共圏のLoadRunnerのに比べて、性能試験のために使用されています好きな。
インターフェイスのテストはどのように行います
1）汎用インタフェーステストケース設計
①、検証を通じて：まず第一に、それはあなたが正しい結果を返すことができる場合は、通常のテスト、そのインタフェースの文書のパラメータを、入ってくる通常のことで、あること、このインタフェース機能が不自由されていることを確認する必要があります。
②、パラメータの組み合わせ：インタフェース動作品があり、フィールドタイプがあり、時間のパス1が商品を削除するとき、価格一つは、型パス2を通過しなければならない、修飾された商品、ID、製品名を表しますidは、そう、私たちは、パラメータの組み合わせを測定する時間タイプ1を通過し、唯一正常に変更することはできません商号を渡し、ID必要があり、合格しなければならない名前で転送が成功したとき、価格を変更することはできません。
③、インターフェイスのセキュリティ：
1、検証バイパスは、例えば、商品を購入する、その価格は$ 300、そして私が注文を提出、私はバックエンドの検証はありません、$ 3へこの製品の価格を置きます。 Genghenポイントは、私は-3にお金を入れて、私のバランスではないですが、また増えますか？
2は、そのようなインタフェースの変更などの許可された製品情報の身元をバイパスし、それは売り手が変更するために取得する必要があり、その後、私は普通のユーザーが成功を変更することはできません渡し、私は合格し、他の売り手の1が正常に変更することはできません
3、パラメータは、暗号化されています例えば、私は、ユーザー名とパスワードが暗号化されていない場合は、あなたの要求を傍受そして誰かが、あなたは情報を得ることができるようになりますし、暗号化ルールは亀裂に簡単で、暗号化されていない、インタフェースを上陸させました。
小切手4の複雑さ、パスワードのセキュリティルール、パスワード
④、異常な検証：
いわゆる異常の確認、私は異常な状況のインターフェイスチェックを検証するために、あなたのインターフェイスのドキュメントの要件に従ってパラメータを入力しませんさ。例えば、入ってくる文字列型の整数タイプを入力し、必要なパラメータを記入しない、長さは10、11パスで、要するに、あなたは私が、実際には、さらに3、通過しますしません来るか、と言う来る方法です非本質的には、パラメータの型、パラメータ長を通過しました。
2）、デザインのユースケースにビジネスロジックに従って
ビジネスロジックに従って設計された、そして、各企業のビジネスは、あなたが特に自社のビジネスを見ているが、実際には、これはまた、ある同じではないことのユースケースを設計するために、独自のビジネスシステムに基づいています機能テスト設計のユースケースと同じです。
例えば、これで、需要の掲示板を掲示板を取る：
1、ログインが5回失敗した後、ログインするために、別の15分を待たなければなら
2を、新たに登録されたユーザーは、インターンシップを通じてメッセージを投稿することができます必要が
3、削除ポストはポイントを控除しました
4、......
あなたは次のように記載されているこれらのテストポイントを取り、その後、テスト・ポイントに対応するテストデータを作成して行きます。
リクエストステータスコード説明
この要求を表明している1200年の初めに2は、最も一般的にはOK、サーバも返される要求に代わって、200で、成功しています。
2300図3は、この要求が別の場所にリダイレクトされ、リダイレクトの始まりは、最も一般的には302で表し、
クライアント3400 400の代わりに要求が403、に代わって不正にアクセス構文エラー、401ページを送りましたこのページへのアクセスがないということではなく、404ページの代わりに、
結果が返されませんでした、5は4500のサーバの異常、異常な内部サーバ500人の代表、サーバ側のタイムアウトの504人の代表者を代表するで始まります
このインタフェースのテストチュートリアルでは、私は、インターフェイスをテストするテストプロセスの詳細な分析に基づいて行われます、我々はこのシリーズに注力し続けることができ、私はあなたが収穫されると信じています。
