この記事は以下から複製されます：
https://www.cnblogs.com/simple1025/p/11149838.html
質問：インターフェーステストを要約するアイデアは、昨年の採用から来ています。すべてのインタビューは、インターフェーステストについていくつかの質問をします。「1,000人の読者の目には1000のハムレットがある」と言うことができ、すべてのテスターがそれらを持っています昨年のその段階での採用プロセスのために、インターフェーステストのさまざまな理解、サーバーインターフェーステストとユースケース分析の主要なポイントを逐次整理し、補足してアーカイブしました。このドキュメントを歓迎します。読んだ友達が提案をします。
サーバー側インターフェースのテストでは、通常、要求と応答のパラメーターの検証、ビジネスロジックまたはビジネスルールの検証、データベース操作の検証などの機能からテストを開始します。機能が正常になった後、必要に応じて、履歴関連バージョンとの互換性テスト、インターフェースタイムアウト検証、設計合理性検証など、安全関連の検査、パフォーマンステスト、および一連の拡張テストが実行されます。ユースケース設計も、これらの側面から分析および設計されます、次のマインドマップは、テストのフォーカス方向の要約です。
詳細は次のとおりです。
入力用
入力は主にインターフェースの入力パラメーターを参照します。通常のテストでは、最初に正常な入力パラメーターと異常な入力パラメーターを検討します。異常な状態には、パラメーターの異常とデータの異常が含まれます。ユースケースの設計は同等です。クラス分割と境界値分析
A.通常のエントリ
通常の入力パラメーターはよく理解されています。つまり、インターフェース設計文書の入力標準に従って、通常のパラメーターを入力します。応答は、インターフェース設計文書の合意された条件に従って正常に返されます。
B.異常なパラメータ
パラメータの例外は次のとおりです。パラメータが空、多かれ少なかれパラメータ、間違ったパラメータ
C.異常なデータ
データ異常：データ型エラー、null以外のパラメーターが空、長さが設計を満たしていない、データが辞書の範囲にない、不正なメンバー、特殊文字または機密文字、相関のある異常パラメーターデータなど
処理ロジック用
インターフェーステストの前に、R＆Dは通常、インターフェース設計ドキュメントまたはビジネス関連の設計図面とフローチャートを提供します。ビジネスプロセスの処理ロジックでは、入力パラメーターの制限条件、イベントの操作オブジェクト、およびビジネスの状態から切り替えることができます
A.制約条件の分析
数値制限：辞書、レベル、業界関連の制限、金額制限、スコア制限など。
ステータスの制限：有効|無効、オンライン|オフライン、黒塗り|白塗りなど
関係の制限：存在または非存在、拘束または拘束解除など
権限の制限：管理者、一般ユーザーなど
B.オブジェクト分析
オブジェクト分析は、主に合法的および違法なオブジェクトを操作するためのものです。たとえば、銀行カードユーザーがカードを再チャージする場合、それは存在する可能性があります。ユーザーAはユーザーA以外のカードを使用して再チャージします。 ;ユーザーAは自分のカードを使用して充電したり、カードをブラックリストに登録したり、紛失したりしています。
C.状態遷移の分析
たとえば、決済サービスの場合、最初の決済は成功し、注文がキャンセルされた後に注文は返金されます。決済が失敗した場合、決済は失敗しました。ステータスの切り替えは正常ですか？通常の業務がスムーズに行われない場合、ステータスはどのように表示されますか？制御可能、異常状態の有無、空状態のビジネスへの対応など
D.タイミング分析
一部の複雑なアクティビティでは、アクティビティは一連のアクションによって指定された順序で実行されます。これらのアクションはアクションフローを形成します。これらのアクションは、期待される結果を待つためにこの順序で実行され、次に実行中に発生する他の分岐アクションが実行されますプログラムは何をしますか
例えば、ゼブラの駐車リスク管理事業では、駅に進入して車両が方向転換して高速事業に進入しない場合はどうすればよいでしょうか。
出力用
例外を検討する場合、通常は通常の状況と無効な状況を考えますが、すべてのエラーコードを網羅しているとは限りません。インターフェース定義によって返されるエラーコードは、ネットワーク例外、無効なルール、無効などのユースケースのこの部分を補足するのに役立ちます。パラメータ、無効なビジネスID、無効なタスク、サーバーの例外など、エラーコードの値を追加して、より多くのユースケースを設計します
出力に基づくこの種の設計ユースケースは、フロントエンドとバックエンドが正常に出力結果であるかどうか、プロンプトがわかりやすいかどうか、機密情報が表示されるかどうかなどを見つけることができます。
データベース操作
A.データベース操作が頻繁であるかどうか、データベースの書き込み中にCPUを大量に消費するかどうか、およびデータベースの書き込みが完了した後にプロセスが解放されるかどうか
B.ビジネスデータストレージが正常かどうか、重複したデータストレージがあるかどうか、文字化けがあるかどうか、ログデータストレージが正常かどうか
C.データの更新が正常かどうか、特に時刻フィールドかどうか、および時刻が24時間形式かどうか
D.データの削除とバックアップが正常かどうか
安全性
機密情報を暗号化するかどうか（銀行口座番号、パスワード、送金金額など）
パフォーマンス関連
A.インターフェースが並行性になる状況、並行性シナリオ、および並行性が問題を引き起こす状況
B.最大同時実行性、応答時間、スループット、リソース消費
インターフェースタイムアウト
インターフェースは通常戻りますが、インターフェースが戻らない場合はどうなりますか？そのため、インターフェースタイムアウト後の処理もテストの一部として考慮する必要があります。タイムアウトが適切に処理されない場合、プロセスがブロックされるか、タイムアウト後にインターフェースの戻りを受信するため、論理的に混乱する可能性があります。
過去のバージョンとの互換性分析
廃止されたプロトコルまたはインターフェース、およびコードはコメント化されていません。特定の状況下では、古いバージョンの廃止されたプロトコルまたはインターフェースがトリガーされ、ユーザーが関数を使用または呼び出した後に予期しない問題や損失が発生する可能性があります。
同じシステム内の異なるサービス間のインターフェースが相互に呼び出しを行う場合、特に新しいインターフェースと古いインターフェースの両方が特定の機能を処理する場合、新しいインターフェースは履歴インターフェースの影響を受けますか？ビジネスの非互換性の問題はありますか？
これにはテスターが長い間システムをテストする必要があるため、この種のシナリオを考えると、いつどのバージョンのリファクタリングが行われたか、それらのインターフェースが破棄され、それらのインターフェースが追加され、どのシナリオが履歴をトリガーするかが明確になります。インターフェースのあるルール
合理的なインターフェース設計
インターフェイスフィールドが冗長であるかどうか、インターフェイスが呼び出し元が期待する情報を返すかどうか、インターフェイス定義がすべての呼び出し元のニーズを満たすかどうか、インターフェイスが呼び出しに便利かどうか、インターフェイスが拡張可能かどうか、インターフェイスパラメータが便利かどうか、インターフェイスのビジネスルールが正しいかどうか、インターフェースはサービス全体の使用であり、これらの効果があります
著者：simplesally出典：https：//www.cnblogs.com/simple1025/：この記事は著者とブログParkの合計に属します。転載および推奨を歓迎しますが、このセクションで宣言された著者の同意なしに、記事ページに保持する必要があります。場所は元のリンクを提供します。それ以外の場合は、法的責任を追う権利が留保されます。