1. インターフェーステストプロセス
1. 要望の協議
2. デマンドレビュー
3. シーンデザイン
4. データの準備
5. テストの実行
2. インターフェース文書要素を分析する
1. インターフェース名
2. インターフェースアドレス
3. サポート形式
4. リクエスト方法
5. リクエストパラメータ（パラメータ名、タイプ、必須、パラメータの説明など）
6. 戻りパラメータ（戻りコード、戻り値情報、戻りJSON文字列情報）
3. インターフェースのテストケースを設計する方法
3.1. テストケースを設計する理由
1. アイデアを明確にし、テスト漏れを避ける
2. テスト効率の向上
3. テストの進行状況を追跡する
4. タスクの負荷を反映する
5. 反復的なタスクをフォローアップする
3.2. インターフェースのテストケースを設計する際に考慮すべき点は何ですか
? 1. 機能
機能が正常かどうか
機能がインターフェースドキュメントに従って実装されているかどうか
通常のシーン
異常な光景
2. ロジカルビジネス
ログインが成功するかどうかなど業務に依存するか
3. 検査異常
(1) パラメータの異常
キーワード引数、空の引数、多数の引数、少数の引数、間違った引数
すべての必須パラメータをカバーする、オプションのパラメータを組み合わせる、パラメータがある、パラメータがない、または null である、パラメータの順序、数、タイプ
パラメータのタイプ値のサイズ、入力値の範囲、パラメータ文字列の長さ、パラメータに特殊文字が含まれている
(2) 異常データ
キーワードデータ、空のデータ、一貫性のない長さ、間違ったデータ
4. セキュリティ
クッキー
ヘッダ
一意の識別子
4. 一般的に使用されるインターフェイス テスト ケースのカバレッジ方法
1. 必要なパラメータの範囲
インターフェイスのパラメータについては、インターフェイスのドキュメントで通常、どれが必要でどれがそうでないかが説明されています。
必須パラメータについては、インターフェイスがパラメータを渡し、エラーを報告しないかどうかを必ずテストしてください。
2. パラメータはさまざまな状況に対応する必要があります
不正な文字、特殊文字、NULL 値、境界を越えたパラメータはエラーとして報告されますか? エラーメッセージは正しいですか?
3. 必須ではないパラメータの範囲
一般に、インターフェイスは必須でないパラメータが異常に渡されたかどうかを判断しないため、正当なパラメータ値とインターフェイスによって返された内容が正しいかどうかをテストする必要があります。
必須ではないパラメータが異常に検証されたことを示すインターフェース文書がある場合は、それらも検証する必要があります。
4. パラメータ組み合わせの適用範囲
ページをめくるには「オフセット」と「カウント」を組み合わせるなど、複数のパラメータを連携させる必要があるので、現時点ではテスト用に組み合わせる必要があります。
5. ビジネスロジック関連の範囲
一部のインターフェイスはビジネス ロジックと密接に関連しているため、インターフェイスのみの観点からテストすると、ビジネス ロジックによって引き起こされる一部のバグを見逃す可能性があります。
したがって、ビジネス ロジックに関連する場合は、ビジネス ロジックに関連するテスト ケースも考慮する必要があります。
5、インターフェイステストインターフェイスの優先順位
1. 優先順位 - すべてのインターフェースの場合
(1) インターフェースは外部に公開されます。通常、インターフェースは第三者によって呼び出されます。
(2) システムの内部呼び出しのためのコア関数インターフェース
(3) システムが内部で非コア関数インタフェースを呼び出す場合
2. 優先度 - 単一インターフェースの場合
(1) 順方向のユース ケースが最初にテストされ、次に逆方向のユース ケースがテストされます (通常、絶対的なものではありません)。
(2) 前提条件を満たしているか > デフォルトパラメータを保持するかどうか > パラメータが必須かどうか > パラメータ間に関連性があるかどうか > パラメータのデータ型の制限 > パラメータのデータ型自体のデータ範囲の制限
6. インターフェーステストの設計思想の分析
1. 前提条件が満たされているかどうか
一部の API では、データを正常に取得するには前提条件を満たす必要があります。いつものように、トークンにログインする必要があります。
逆の使用例:
前提条件が満たされるかどうかの 0 ～ n 個のユースケースを設計します (n 個の条件を想定)
2. デフォルト値パラメータを保持するかどうか
前向きのユースケース:
デフォルト値を持つパラメータは入力または渡されません。必須パラメータには正しい既存の「通常の」値が入力されます。その他は入力されず、ポジティブなユースケースが設計されます。
3. ビジネスルールと機能要件
実際の状況に応じて、インターフェースパラメータの記述と組み合わせて、n 個の順方向ユースケースと逆方向ユースケースを設計する必要がある場合があります。
4. パラメータは必須ですか?
逆の使用例:
必須パラメータごとに、空のパラメータ値を使用して逆のユースケースを設計します。
5. パラメータ間に関係があるかどうか
一部のパラメータは相互に制限的な関係にあります。
逆の使用例:
実際の状況に応じて、0~n 個のユースケースを設計する必要がある場合があります
6. パラメータのデータ型の制限
逆の使用例:
パラメータごとに、パラメータ値の型が一致しない逆のユースケースを設計します。
7. パラメータのデータ型自体のデータ範囲制限
前向きのユースケース:
すべてのパラメーターについて、各パラメーターのパラメーター値がデータ範囲内の最大値であるポジティブなユースケースを設計します。
逆の使用例:
各パラメーター (n と仮定) について、各パラメーターのパラメーター値がデータ範囲の最大値を超える n 個の逆ユース ケースを設計します。
各パラメーター (n と仮定) について、各パラメーターのパラメーター値がデータ範囲の最小値より小さい n 個の逆ユース ケースを設計します。
要約:
上記の側面を考慮すると、基本的には次の側面をカバーできます。
(1) メイン処理テストケース：通常のメイン処理機能検証
(2) 分岐フローテストケース：正常な分岐フロー機能検証
(3) 異常フローテストケース：異常耐障害性チェック
7. インターフェーステストで返された結果の比較
目的：
認証コードはOKです
確認コードは正しいです
1. リターンコードを比較する
2. 返された値の整合性を比較します。つまり、返されたキーは不完全です。
3. キーの値のデータ型を比較します。
4. キーに対応する値の比較（業務関連データの値の検証を含む）
最後に、私の記事を注意深く読んでくださった皆さんに感謝します。互恵性は常に必要です。それほど価値のあるものではありませんが、必要な場合はそれを取り上げることができます。
ソフトウェアテストインタビューアプレット
ソフトウェア テストの質問バンクには、何百万人もの人が参加しました。！！誰が知っているのか！！！ネットワーク全体で最も包括的なクイズ ミニ プログラムです。携帯電話を使用して、地下鉄やバスの中でもクイズに答えることができます。
次の面接の質問セクションが取り上げられます。
1. ソフトウェアテストの基礎理論、2. Web、アプリ、インターフェース機能テスト、3. ネットワーク、4. データベース、5. Linux
6. Web、アプリ、インターフェイスの自動化、7. パフォーマンス テスト、8. プログラミングの基本、9. 時間面接の質問、10. 公開テストの質問、11. セキュリティ テスト、12. コンピューターの基本
これらの資料は、[ソフトウェア テスト] の友人にとって、最も包括的かつ完全な準備倉庫となるはずです。この倉庫は、最も困難な旅を乗り越える何万人ものテスト エンジニアにも同行してきました。そして、あなたにも役立つことを願っています。