オリジナル転送します。https：//blog.csdn.net/jinganglong123/article/details/51122713
テストタスクのテストヘッドを受信した後、試験は、以下のプロセス仕様に従って行われるべきです。
2.1テスト要件分析
、製品の機能インターフェイスのドキュメントの準備が完了した後、製品開発のリーダー、検証後の電荷の対応人で問題になっているテスト・インタフェース。インターフェイスのドキュメントを取得するためのテストリーダーは、次の二つの側面での作業を行う必要があります。一方で、テスターがインターフェース機能の意味と用法を理解し、各インターフェイスのインターフェイスに関わる様々な分野を文書化します。一方で、テスターは完全に開発者と通信しなければならない明確各フィールドのプロトコル仕様および範囲に各インターフェイスを理解し、値。
各試験の後に提出するために必要なテストケースの準備を完了するための担当者は、テストケースのレビューの場合は、試験に合格した場合後のフォローアップ作業の開始前に、テスト・リードの監査を取るか、または組織のリーダーを検討します。
敏捷性のテスト時間の緊急性を考慮して、開発からニーズの分析はキックオフ（T-7）が開催されますときに介入し始めました。
2.2テスト計画
、テスト計画を通信するために、テストのリーダーやプロジェクトマネージャーとの契約を担当するインターフェーステスト人。単一のインターフェースは、相関テスト時間及び毎日のテスト作業をテストし、開発するために、異なるテスタに分配分割インターフェースインターフェース機能の複雑さに応じて、テストのヘッドによって、あまりにも関与するドキュメントをインタフェースするとき。
2.3デザインのテストケース
タスクインターフェース・テストの分割後、テスト・インタフェースのための担当者は例が、自動化することができるインタフェースのドキュメント、インタフェース書かれたテストケース、クリアをベースとするその場合、手動テストの必要性をインチ 包括的なテストを確実にするために自動化されたテストスクリプトのその後の準備のためのガイダンスを提供します。ケース設計インターフェースのテストポイントが上昇、このガイドの次のセクションを参照する必要があります。ケースは、すべてのテストポイントをカバーするために行う必要があり、かつ一定の特別なインタフェースのために、考慮インタフェースの特別な性質を取って、テストケースの準備が目標。
ケース評価を行うためのテストケースの準備の完了後、評価は、試験を通して行うべきです。
テスト環境の準備2.4
必要なインタフェーステスト自動化ツールのJMeterのインストール、Java環境の設定とテストを完了するために、自分の責任他の職員。背景環境に必要なインターフェイスのテストは、状況は、テスト担当者の担当者に必要保守および開発を担当し、対応する開発者が環境に配慮し、開発環境でテストする必要がある環境の安定とベータ版を確実にするために、別のテスト環境が存在しないことです正しいです。独立したテスト環境、テスト環境場合は、保守担当者は、その開発マネージャーからテスト環境に配備最新のベータ版を取得し、初期設定パラメータと初期テストデータを保護する必要があります。
試験の2.5実装
計画に従って準備作業の完了後には、試験を実施することができます。1は、テスターがインターフェースのすべての詳細を理解強化することができるように優先順位手動テスト、手動テストのすべてのケースに関する勧告のテスト実装インタフェース再び、一方であなたはすぐにバグを見つけることができるインターフェイスがあり、開発者へのタイムリーなフィードバックを変更するには。主要なバグの開発が解決されたように、各フィールドの構成の場合を遂行するためのインターフェイスは、安定した仕事の自動化スクリプトの記録となって書き込みなど、ケースには、テストスクリプトの作成にテストを自動化し、スクリプト記述された仕様、良いスクリプトの組織構造をたどることができ、便利ましたポストスクリプトの保守管理。スクリプティングスクリプティングの仕様は、以下の仕様のセクションを参照してください。
テスト段階でのテストによると、欠陥のテストケースとインタフェースの理解を深め、テストケースを補完または修正される可能性があります、テスターはそれぞれのケースが正確、簡単後半回帰テストであることを保証するために、良いテストケースのタイムリーなメンテナンスが必要です。
テストは各インターフェイスを完了すると、テストレポートを提出します。そして、要約を照合する関連文書をテストします。
評価の2.6テスト結果
テストの最終段階のためのステージの、検討会のテスト結果を整理するための責任がテストチームのリーダー。各テストの結果を確認するために満たすこと（ケース、テストスクリプト、バグリスト、試験報告書及びその他の出力試験物質を含む）職員でした。問題や不備速やかに修正し、標準化されたテストを識別します。保存された要約ノートによる評価のテスト結果は、会社の資産テストの一部を形成します。
2.7テストプロセスを最適化するために続行
一定の期間のためのインターフェースの自動化テストの後、定期的にまとめるためにテストされます。特定された問題を改善するために、テストガイドラインは、継続的な最適化テストのプロセスを改善します。
インタフェース仕様テスト関連の文書管理
3.1ドキュメントのスコープテスト
：文書のインタフェーステスト自動化の主な種類は、次のように管理する必要がある
インターフェイスのドキュメント、テストドキュメント、テストレポート（結果）のドキュメント、テストスクリプト（JMXタイプ）、会議の議事録を、文書やその他のテスト関連文書の見直し。
作成するための3.2 Testのドキュメントの指示
文書化要件クラス（例：インターフェイスのドキュメント）をテストする開発者が提供するテストの冒頭では、テスターは、ユースケースを書く、ドキュメントは、開発者ベースのインターフェイスのドキュメントへのタイムリーなフィードバックのために地元の必要性を規制しない、標準化を提供するように変更付勢インタフェースのドキュメント。
文書は、テストケースのテスターは、インターフェイスのドキュメントを持って、より良い文書の作成のニーズを理解し始めた後に、後者は評価の対象にテストケースドキュメントを最適化していきます。試験資料の準備が完了すると、試験の準備には、スクリプト、テストケースドキュメントからユースケースに基づいて作成したスクリプトを開始します。
テストスクリプトは、出力テストテストテスト担当者の形式、ポストスクリプトの保守・管理を容易にするため、スクリプトを記述するために、次の書類の規制要件を満たすために必要なスクリプトで実行されています。
テストレポート文書は、試験終了後に試験機で、同社が提供する、監査のテストヘッドに提出要求仕様のテンプレートに基づいて作成テストフェーズの結果の要約レポートには、対応する製品やプロジェクトを発行し、修正開発、ビジネス、リーダーシップやその他の関係者。
会議の議事録は、審査書類およびその他の文書は、プロジェクトのニーズに基づいて、テストプロセス全体で生産され、これらの文書は、ガイドとして使用し、テストのテスターを標準化し、要件文書に分類することができます。
3.3テスト文書ファイリング要件は
、テストタスクの終了後、テスターはSVNサーバの下の適切なディレクトリにアップロードし、関連するテストドキュメントのさまざまな、整理する必要があります。テストグループ全体でのテスト資産の形成。これは、テストドキュメントのすべてのタイプをアーカイブする必要があり、試験終了後のリンクに、各テスターの注意を払う必要があります。
それを、SVNのディレクトリ管理の独自のセットを持って、テスターのテストが完了したプロジェクトや製品で強力それぞれの領域をテストすることをお勧めである製品やプロジェクトが独自のディレクトリSVN、テストを持っているので、開発マネージャは、テストケースとして必要とされます、テストレポート、SVN対応する項目にアップロードテストドキュメント。しかし、試験後、テスターは型アーカイブにより、最終的なテスト関連のドキュメント（インタフェースのドキュメント、テストドキュメント、テストレポート（結果）のドキュメント、テストスクリプト（JMXタイプ）、議事録、審査書類など）を完了する必要がありますSVNは、テスト文書管理は、自分の資産を形成するために、テストグループ、テストグループによって制御され、テストグループの下に、独自のディレクトリを管理することができます。
次の例では、テストドキュメント北京のアーカイブ要件のテストグループを説明し、テストグループ参照の残りはアーカイブのために用意し、独自のプロジェクトのテスト文書の状況に応じて、行うことができます。
インターフェイスのテストポイント
4.1インターフェースユーザビリティ
メインインタフェースをテストインタフェースのユーザビリティが利用可能であるか否か、インタフェースの存在は、プロトコルタイプインタフェースは、テストケースを含める必要があります
指定されたアドレスおよびプロトコルインターフェースに基づい〖〗R1インタフェースドキュメントインターフェイスにメソッドにアクセスします。
〗〖R2は、間違った方法は、プロトコルインターフェイスアドレスに従ってアクセスすることができない使用します。
R3〖は正しい方法が間違ったプロトコルインタフェースアドレスに従ってアクセスすることができない使用します〗。
4.2入力および出力パラメータと命名の数
の入力および出力パラメータとインタフェースの主要なテストという名前の入力および出力パラメータの数は、数が含まれており、各パラメータの名前が正しいか、テストケースを含むべきである：
〖〗R1インターフェースドキュメントチェック入力パラメータに基づいを番号と名前、および文書一貫するかどうか。
出力パラメータならびに名およびドキュメント一致するかどうかを確認する文書の数に基づいて〗〖R2インターフェース（正常および異常パラメータの出力パラメータを確認するように注意してください）。
R3〗〖間違ったパラメータ名、インターフェイスエラー、およびエラー・メッセージが返されますを入力してください。
4.3入力パラメータは、アイテムを失う
失うオプションの入力パラメータ要件主入力パラメータ検査項目インタフェースを失い、テストケースを含むべきである：
〖〗R1を失うためのすべてのエントリに応じて、入力インタフェース文書を順次されていませんインタフェースは、エラー・メッセージが返されるかどうかを確認できます。
順次入力パラメータのすべてのエントリ選択された出力を確認に従ってR2〗〖インターフェース文書は、エラーメッセージを表示せず、返すために適切なデータインタフェースを有していなくてもよい場合。
4.4入力の正当性パラメータ
の入力パラメータは、仕様を確認するために、メインの入力パラメータの正当性の正当性を、テストケースが含まれなければならない：
数字のみによって：明確な要件（例えばとともに〗〗R1ベースのインタフェースのマニュアルを参照して、値は、以下でのみアルファベットを選択可能な選択、時間形式のフォーマット）の入力パラメータの最大数の長さは、チェックがこれらの要件を満たしています。
全幅半値幅の場合のように、特殊文字を含むR2〗〖インターフェイス文書単位ではなく、明示的に必要な入力パラメータ、長いテストシーケンス長、。エラーメッセージが返され与え、インターフェイスエラーかどうかを確認してください。
4.5出力の内容の正しさのパラメータ
背景の出力パラメータの主な内容の出力パラメータの内容の正確さと実際のデータの整合性をチェックするかどうか、テストケースが含まれるべきである：
〖〗R1は、これらをテストするために、入力パラメータの組み合わせの多様性を考えます返されたインターフェース構成データが正しいフィールドの内容は、各フィールドの具体的な内容を確認します。一般的にはより多くのバックエンドデータベースとのデータによって確認すること。
R2は〗〖入力パラメータの様々な組み合わせを考える、戻された項目で、これらのインタフェースの組み合わせでテストデータを順次入力パラメータに関するものであり、初期値は、同じ入力です。
4.6インターフェイス機能検証
検査の正常動作の特定のインタフェース動作の主な機能は、テストケースを含むべきであることを確認するためのインターフェイス機能：
〖〗R1が正しいパラメータを入力し、バックオフィス機能の正しい動作を達成するために、対応するインターフェースを確認。たとえば、次のブートのためのコマンドインタフェースが送信され、バックグラウンド・システムに対応するインターフェイスが適切に起動し、正しいパラメータを返します。
R2〗〖パラメータ入力エラー、達成されるべきバックオフィス機能に対応するインターフェースが実行されていないかどうかを確認。
4.7インターフェースドキュメント規範
インタフェースドキュメント規範主に提供されるインタフェースのドキュメントの開発に関する正確な仕様の確認、テストケースを含むべきである：
〖〗R1インタフェース文書を正確に入力および出力パラメータ、曖昧不在のために名付けられました。
各パラメータの〗〖R2インタフェース文書は、デフォルト値があるかどうか、どうか任意又は失う、タイプの明確な記述を有します。
〗各入力パラメータエントリの〗R3インタフェースのドキュメントでは、このような最長のどのくらいの長さとして明確に良い基本的な条件は、唯一の特殊文字を含めることはできません、数値または文字ができなければなりません。
〗〖R4は、インターフェイスの出力パラメータまたはパラメータの数の組み合わせの複数のタイプが存在する場合と異なる名前、この場合、インターフェイス文書で明確に設定し、クリア条件の出力パラメータのこのタイプのように見えました。