そもそもインターフェースとは何でしょうか？
一般に、インターフェースには 2 種類あり、1 つはプログラムの内部インターフェース、もう 1 つはシステムの外部インターフェースです。
システムの外部インターフェイス: たとえば、他の Web サイトやサーバーからリソースや情報を取得したい場合、他の人がデータベースをあなたと共有することは絶対にありません。他の人が提供できるのは、その人が作成したメソッドのみです。データを取得するには、データ共有の目的を達成するために、彼が提供するインターフェイスを引用して彼が書いたメソッドを使用できます。たとえば、私たちが使用するアプリや URL は、データを処理するときにすべてインターフェイスを通じて呼び出されます。
プログラム内のインターフェース: メソッド間の対話、モジュール間の対話、bbs システムなどのプログラム内でスローされるインターフェース、ログイン モジュール、投稿モジュールなどがあります。投稿したい場合は、まずログインする必要があり、投稿したい場合は、ログインする必要があります。その後、これら 2 つのモジュールが対話する必要があり、内部システムが呼び出すためのインターフェイスがスローされます。
1. 共通インターフェース:
1. WebServiceインターフェース: http経由のsoapプロトコルで送信され、リクエストメッセージとリターンメッセージはともにxml形式であり、テストする際にはツールを使用して呼び出してテストします。使用できるツールには、SoapUI、jmeter、loadrunner などが含まれます。
2. http api インターフェース: http プロトコルを採用し、呼び出しメソッドをパスで区別します。リクエストメッセージはキーバリューの形式です。戻りメッセージは一般に json 文字列です。get や post などのメソッドがあります。これも最も一般的に使用される 2 つのリクエスト メソッドです。使用できるツールには、postman、RESTClient、jmeter、loadrunner などが含まれます。
2. フロントエンドとバックエンド:
インターフェイス テストについて説明する前に、まずフロントエンドとバックエンドという 2 つの概念を理解しましょう。
フロントエンドとは何ですか? Web 側では、使用する Web ページと開く Web サイトはすべてフロントエンドです。これらは HTML と CSS で記述されます。アプリ側では、それがフロントエンドです。 Android または object-C (iOS でアプリを開発) で開発されたアプリを使用します。その機能は、ページを表示し、美しいページを見て、空ではない検証などの簡単な検証を行うことです。ページでは、これらのビジネス ロジックと、Weibo でのショッピングや投稿などの機能がバックエンドによって実装され、バックエンドは、ショッピング時の残高の差し引きと、Weibo への投稿先のアカウントを制御します。エンドとバックエンドは対話しますか? それはインターフェースを介して行われます。
前に述べたことは、あなたには理解しにくいかもしれません。覚えておいてほしいのは、フロントエンドは見た目を美しくする責任があり、バックエンドは家族を養うためにお金を稼ぐ責任があるということです。 。
上の 2 つの図を比較すると、2 つのテスト アクティビティの同じ部分には機能テスト、境界分析テスト、パフォーマンス テストが含まれていることがわかります。< a i= 2>、その他の部品は、異なる特性や懸念事項により特別なテストが必要となるため、ここでは説明しません。次に、上記の 3 つの部分で同じ内容を分析します。
1. 基本機能テスト:
基本的なビジネス機能をテストするため、この部分は 2 つのテストの重複度が最も高く、開発学生は通常主にこの部分の内容を参照します。
2. 境界分析テスト:
基本的な機能テストをベースに、入出力の境界条件を検討しますが、この部分には繰り返し部分（ビジネスルールの境界など）も含まれます。ただし、フロントエンドの入力と出力は、ユーザーが選択できる固定値 (ドロップダウン ボックスなど) を提供することが多く、この場合、テストの境界範囲は非常に制限されますが、このような制限はありません。比較的広い範囲をカバーできるインターフェースであるため、同様にインターフェースに問題が発生する可能性も高くなります。
3. 性能テスト:
どちらもパフォーマンス テストが必要ですが、焦点は確かに大きく異なります。アプリ側のパフォーマンスは、携帯電話の CPU、メモリ、トラフィック、fps などの携帯電話関連の機能に主に焦点を当てています。インターフェイスのパフォーマンスは、主にインターフェイスの応答時間、同時実行性、サーバー リソースの使用量などに焦点を当てます。 2 つのテストの戦略と方法は大きく異なるため、この部分は個別にテストする必要がありますが、理論的には、これも異なる部分です。
まとめ：
1. インターフェイス テストとアプリ テストのアクティビティには、主にビジネス機能のテストに焦点を当てた、いくつかの繰り返しの内容が含まれています。また、特性ごとに試験が異なり、製品全体の品質を確保するには対象となる試験を個別に実施する必要があります。
2. インターフェイス テストではサーバー ロジックの検証に重点を置くことができ、UI テストではページ表示ロジックとインターフェイス フロントエンドおよびサーバー統合の検証に重点を置くことができます。
3. インターフェーステストとは:
インターフェイス テストは、システム コンポーネント間のインターフェイスをテストするテストの一種です。インターフェイス テストは主に、外部システムとシステム間、および内部サブシステム間の相互作用ポイントを検出するために使用されます。テストの焦点は、データの交換、伝送および制御の管理プロセス、システム間の相互論理依存関係などを確認することです。
OK、上記は百度百科事典の言うことであり、以下は私が言うことです。
実際、インターフェイステストは非常に単純で、通常の機能テストよりも簡単だと思います（最初に言っておきますが、将来削除する可能性がありますO(∩_∩)O!）。私も、インターフェーステストとは何なのかと多くの人に（たったの2、3人ですが）聞かれましたが、理解できなくてもわかったふりをする態度で、こう言いたいと思います。さまざまな状況下での対応する入力および出力情報インターフェイスが対応する機能要件およびセキュリティ要件を満たしているかどうかを判断するため。
インターフェイス テストは機能テストよりも簡単だとなぜ言えるのでしょうか? 機能テストでは、ページから値を入力し、ボタンやリンクをクリックしてその値をバックエンドに転送します。さらに、機能テストでは、UI、フロントエンドの対話、およびインターフェイスのテストもテストされます。他の機能、ただしインターフェイスのテスト ページはありません。インターフェイス仕様文書の呼び出し元アドレスとリクエスト パラメータを使用してメッセージを結合し、リクエストを送信して戻り結果をチェックするため、受信パラメータと送信パラメータを測定するだけで済みます。 , これは比較的簡単です。
4. インターフェース構成
インターフェースはどのような部分で構成されていますか?
まず、インターフェイス ドキュメントには次のコンテンツが含まれている必要があります。
1. インターフェイスの説明
2. 呼び出し元 URL
3. リクエスト メソッド (get\post)
4 、リクエスト パラメータ、パラメータ タイプ、リクエスト パラメータの説明
5. リターン パラメータの説明
インターフェイスのドキュメントから、インターフェイスは少なくともリクエスト アドレス、リクエスト メソッド、およびリクエスト パラメーター (入力パラメーターと送信パラメーター) で構成されている必要があることがわかります。一部のインターフェイスにはリクエスト ヘッダーがあります。
ヘッダー: HTTP プロトコルを使用して HTML データをブラウザーに送信する前にサーバーによって送信される文字列です。ヘッダーと HTML ファイルの間には空行が必要です。通常、Cookie やトークンなどの情報が格納されます。
何人かの学生が、ヘッダーと入力の関係は何ですかと私に尋ねました。すべてのパラメータがサーバーに送信されるわけではありませんか?
OK、まず第一に、これらは確かにサーバーに送信されるパラメーターですが、異なります。ヘッダーに保存されるパラメーターには通常、リクエストにアクセス許可リクエストがあるかどうかを確認するために使用される Cookie などの検証情報が保存されます。存在する場合は、サーバーにリクエストできます
5. インターフェーステストが必要な理由:
誰もが知っているように、インターフェイスはバックエンドと対話するためにフロントエンド ページまたは APP によって実際に使用されるため、機能テストはすでにテストしたのに、なぜインターフェイスをテストする必要があるのかと多くの人が疑問に思うでしょう。 OK、この質問に答える前に、例を挙げてみましょう。
例えば、ユーザー登録機能をテストする場合、ユーザー名は英字（大文字と小文字を区別）、数字、アンダースコアを含む6～18文字と規定されています。まず、機能テスト中に、20 文字の入力や特殊文字の入力などのユーザー名ルールが確実にテストされますが、これらはフロントエンドでのみ検証され、バックエンドでは検証されない可能性があります。パケットをキャプチャすることで回避します。フロントエンドの検証に合格し、バックエンドに直接送信された場合はどうすればよいですか?想像してみてください。ユーザー名とパスワードがバックエンドで検証されず、誰かがフロントエンドの検証をバイパスした場合、ユーザー名とパスワードを何気なく入力することはできないでしょうか?ログインしている場合、SQLインジェクションなどで任意にログインでき、管理者権限も取得できる可能性がありますが、怖くないですか？
したがって、インターフェイス テストの必要性が次のように反映されます。
①. ページ上での操作では発見できないバグが多数見つかります。
② システムの例外処理能力を確認する
③. システムのセキュリティと安定性を確認する
④. フロントエンドは自由に変更可能一度インターフェースをテストすれば、バックエンドを変更する必要はありません。
6. インターフェーステストのテスト方法:
インターフェイスのテストを実施する前に、次のことも理解する必要があります。
1)、GET リクエストと POST リクエスト:
get リクエストの場合は、ブラウザに直接入力するだけです。ブラウザで直接リクエストできる限り、 Get リクエストです。post リクエストの場合は機能しません。送信するにはツールを使用する必要があります。
GET リクエストと POST リクエストの違い:
1. GET は URL または Cookie を使用してパラメータを渡します。そしてPOSTでBODYにデータを入れます。
2. GET URL には長さ制限があるため、POST データが非常に大きくなる可能性があります。
3. データがアドレス バーに表示されないため、POST は GET より安全です。
4. 一般に、get リクエストはデータの取得に使用され、post リクエストはデータの送信に使用されます。
実際、上記の点のうち、より信頼できるのは最後の点だけです。最初の点は、投稿リクエストでも URL にデータを入れることができるということです。実際、get には長さの制限はありません。リクエストを投稿する パラメーターは暗黙的であるため、少し安全であるようですが、それは初心者向けであり、リクエストを投稿した場合でも、パケットをキャプチャすることでパラメーターを取得できます。したがって、面接中に上記のことを言ってください。
2)、httpステータスコード
各 http リクエストが発行されると、応答が返されます。HTTP 自体には、リクエストが成功したかどうかを示すステータス コードがあります。一般的なステータス コードは次のとおりです。
1 200 または 2 で始まるものは、リクエストが正常に送信されたことを意味します。最も一般的なのは 200 で、リクエストが正常でサーバーから返されたことを意味します。
2. 300 3 はリダイレクトを意味します。最も一般的なのは 302 で、リクエストを別の場所にリダイレクトします。
3. 400 400 はリダイレクトを意味します。送信されたリクエストクライアントによる構文エラーがあります。401 はアクセスされたページが承認されていないことを意味し、403 はこのページにアクセスする権限がないことを意味し、404 はそのようなページが存在しないことを意味します。
4. 500 5 は、サーバーに例外があることを意味します。500 は内部サーバー例外を表し、504 はサーバーのタイムアウトを表し、結果が返されなかった
次に、インターフェイス テストのテスト方法について説明します。
1). 一般的なインターフェースの使用例の設計
①. 通過性検証: まず第一に、インターフェース関数が使いやすいこと、つまり通常の通過性テストを行う必要があります. インターフェース文書上のパラメーターに従って、パラメーターが正常に渡されていれば、正しい結果を返すことができます。
②. パラメータの組み合わせ: プロダクトを操作するためのインターフェースが存在します フィールドタイプがあります 1 を渡すとプロダクトを変更することを意味します プロダクト ID、プロダクト名、プロダクト ID のいずれか価格、タイプを渡す必要があります。2 を渡すと、製品は削除され、製品 ID が必要になります。この場合、パラメータの組み合わせをテストする必要があります。タイプ 1 を渡すと、製品名だけがあれば変更は成功しますか?渡されましたか? ID、名前、価格がすべて渡された場合、正常に変更できますか? 正常に変更できません。
③. インターフェースのセキュリティ:
1. 検証をバイパスします。たとえば、製品を購入し、その価格が 300 元の場合、注文を送信するときに、価格を 3 元に変更しましたが、バックエンドでの検証はありますか? さらに無慈悲な言い方をすると、価格を -3 に変更しても残高は増えますか?
2. ID 認証をバイパスします。たとえば、製品情報インターフェースを変更する場合、変更するには販売者である必要があります。したがって、一般ユーザーにアップロードした場合、変更は成功しますか? ? 別の販売者にアップロードした場合、成功しますか? 正常に変更できません
3. ログインするインターフェイス、ユーザー名とパスワードなどのパラメータが暗号化されているかどうか暗号化されていない場合、暗号化ルールが簡単に解読されるかどうかに関係なく、他人があなたのリクエストを傍受し、あなたの情報を取得する可能性があります。
4. パスワード セキュリティ ルール、パスワードの複雑さの検証
④. 例外検証:
いわゆる例外検証とは、インターフェイスの異常状況の検証を検証するために、インターフェイス文書の要件に従ってパラメータを入力しないことを意味します。たとえば、必要なパラメータを入力しない場合は、整数型を入力し、文字列型を渡し、長さが 10 である場合は 11 を渡します。つまり、その方法を教えていただければ、私はそうします。実際には、渡さなければならないタイプは、パラメータのタイプ、入力パラメータの長さの 3 つだけです (オプションで渡されます)。
2) ビジネス ロジックに基づいてユース ケースを設計する
ビジネス ロジックに基づいて設計する場合、自社システムのビジネスに基づいてユース ケースを設計することになります。各企業のビジネスは異なります。 . 実際、これは機能テスト設計のユースケースと同じです。
たとえば、bbs の場合、bbs の要件は次のとおりです。
1. 5 回ログインに失敗した場合は、15 分間待つ必要があります。再度ログインします。
2. 新規登録ユーザーは、投稿する前にインターンシップ期間を過ぎている必要があります
3. 投稿を削除するとポイントが差し引かれます< a i=6> 4.... ... このように、これらのテスト ポイントをリストし、データ テストに対応するテスト ポイントを作成する必要があります。
7. 測定に使用するツール
postman、RESTClient、jmeter、loadrunner、SoapUIなど、インターフェーステスト用のツールはたくさんありますが、私が最もお勧めするテストツールはpostmanとjmeterです。次に、これら2つのツールを使ったインターフェーステストの方法を簡単に紹介します。ツールについては今回は説明しません。紹介はありません。
1) Postman は Google のインターフェイス テスト プラグインで、使い方が簡単で、ユース ケース管理、取得、投稿、ファイル アップロード、応答検証、変数管理、環境パラメータ管理などの機能をサポートしています。バッチを作成し、ユースケースのエクスポートをサポートします。
jmeter は、100% 純粋な Java で書かれた無料のオープン ソース ツールです。主にパフォーマンス テストに使用されます。loadrunner と比較して、使用するメモリが少なく、無料でオープン ソースで、軽量で便利で、インストールは必要ありません。大衆の間でますます人気が高まっています。
8. インターフェースのテストと継続的統合
インターフェイステストは継続的インテグレーションの自動化が中心的な内容となっており、自動化を維持することで初めて低コスト、高利益を実現することができます。現在、主に回帰フェーズで使用されるインターフェースの自動化を実装していますが、将来的には以下の自動化の程度を強化する必要があります。
a) プロセスの観点: 回帰フェーズでのインターフェイス異常シナリオのカバー範囲を強化し、徐々にシステム テストおよびスモーク テスト フェーズまで拡張し、最終的には完全なプロセスの自動化を達成します。
b) 結果表示: より豊富な結果表示、傾向分析、品質統計と分析など。
c) 問題の場所: エラー メッセージとログがより正確になり、問題の再現と場所の特定が容易になります。
d) 結果検証：データベース情報検証などの自動検証機能を強化します。
e) コード カバレッジ: コード カバレッジを向上させるために、現在のブラック ボックスからホワイト ボックスへの移行を常に試みます。
f) パフォーマンス要件: パフォーマンス テスト システムを改善し、自動化された手段を通じてインターフェイスのパフォーマンス インジケーターが正常であるかどうかを監視します。
9. インターフェーステストの品質評価基準
a) ビジネス機能の範囲が完全かどうか
b) ビジネスルールの網羅性が充実しているか
c) パラメータ検証が要件（境界、ビジネスルール）を満たしているかどうか
d) インターフェース例外シナリオの網羅が完了しているかどうか
e) インターフェースのカバレッジが要件を満たしているか?
f) コードカバレッジは要件を満たしていますか?
g) 性能指標が要件を満たしているかどうか
h) 安全指標が要件を満たしているかどうか
私の記事をよく読んでくださった皆様、ありがとうございます。礼儀には常に礼儀があります。それほど価値のあるものではありませんが、使用できる場合は、直接受け取ることができます。
これらの資料は、[ソフトウェア テスト] の友人にとって最も包括的かつ完全な準備倉庫となるはずです。また、この倉庫には数千人のテスト エンジニアも同行します。最も困難な旅を経験しました。この情報があなたのお役に立てれば幸いです。困っている友達は、下の小さなカードをクリックして受け取ってください。
