前面に書かれています_テストフィールドでインターフェイスのステータスについて必ず話してください。
現在、企業における実践的なテスト スキルの適用では、機能テストとインターフェイス テストが最も広く使用されています。ただし、機能テストと比較すると、インターフェイス テストの差は非常に大きくなります。
また、インターフェイス テストはテスト分野で非常に高い地位を占めており、ソフトウェア テスト エンジニアの初級者と中級者の間の境界線となっています。したがって、テスターがインターフェイス テストを理解している限り、非常に良い給与の仕事を見つけることができます。
したがって、テスト担当者 (質問者から見れば QA) は、インターフェイスのテスト能力を向上させるために最善を尽くす必要があります。
インターフェイステストのコードカバレッジを改善したい場合。まず、コード カバレッジを向上させるための適切な措置を講じるために、コード カバレッジが低い理由を知る必要があります。主題によって補足されたアプリケーション シナリオを注意深く分析した後、主題の質問を 4 つの部分に分けて説明します。
1. 従来のインターフェイステストではコードカバレッジ率が低いのはなぜですか?
2. コードカバレッジを改善するにはどうすればよいですか?
3. インターフェースのテストケースメソッドの理解を容易にするために、例が示されています。
4. インターフェイスのテスト範囲を確保する際に発生する可能性のある問題を分析します。
1. 従来のインターフェーステストではコードカバレッジ率が低いのはなぜですか?
インターフェース QA はまだブラックボックスです。QA はインターフェイスの内部ロジックには注意を払いません。ユースケースとしての独自の理解に従って、さまざまなパラメーターの組み合わせを設計するだけです。
実際、この主題により、コード カバレッジが低い根本原因が明らかになりました。インターフェイスのテストでは、この種のブラックボックス テスト ケースの設計思考が非常に一般的です。
ブラックボックス テスターのテスト ケース設計を確認するために、単純なインターフェイス シナリオを例に挙げてみましょう。
httpプロトコルを例に挙げます
単一インターフェース:
URL の検証
* URL パスには検証が必要な特別なパスがいくつかあります
クエリパラメータ、リクエストヘッダ、リクエストボディパラメータの検証
* パラメータの場合: 通常のクラスパラメータの検証 (正常データと異常データ)
* ビジネスの場合: 単一インターフェイス関数のカバレッジ (順方向および逆方向の要件)
応答データの検証
※正常インタフェース応答範囲
※異常インタフェース応答範囲（エラー情報）
ビジネス シナリオを検証します。
* アプリケーションのビジネス シナリオをカバーします。
* インターフェイスを介してユーザーの可能な操作プロセスをシミュレートします。
この種のブラックボックス設計はインターフェイスのテストを扱いますが、次の 4 つのカテゴリが欠けていることがよくあります。
省略分類 1. 不明確または不規則なテストによるシーンの省略
インターフェイス テスト ケースの設計アイデアが明確でない、または標準化されていない場合、現場を見逃してしまいがちです。つまり、ブラックボックスのテストケース設計思考ではカバーすべきシナリオに漏れがあり、コードのカバー率は確実に低下してしまいます。
分類 2 が欠落しており、カバーするのが難しいブランチが含まれています
インターフェースの実装ロジックは多岐にわたり、多くの分岐が含まれますが、いくつかの共通点を以下に示します。さらに追加していただければ幸いです。
1. インターフェイスには非同期タスクが含まれます
インターフェイスに非同期タスクが含まれる場合。従来のインターフェイス テスト ケースの設計アイデアは、通常、非同期タスクの通常の実行をトリガーするだけです。ただし、非同期タスクの失敗、リトライ、引き上げのタイミングなどの非同期処理は逃す可能性があります。したがって、コードカバレッジが減少します。
2. インターフェースにはトランザクションが含まれます
インターフェイスにトランザクションが含まれる場合、従来のインターフェイス テスト ケース設計では通常、通常のトランザクション プロセスのみがトリガーされます。実際の開発者は、ロールバックの特定のステップとロールバック後に必要な処理のために、いくつかの特別なビジネス実装を行っています。これらのシナリオは見落とされやすく、コード カバレッジにも影響します。
3. インターフェイスにはロックが含まれています
インターフェイスにロックが含まれる場合、一部のテスト シナリオが見逃されやすくなります。読み取り-書き込みロックを例に挙げます (読み取り-読み取りの共存、読み取り-書き込みの非共存、書き込み-書き込みの非共存)。従来のインターフェイス テスト ケースの設計では、読み取りと読み取りの共存、読み取りと書き込みの非共存、および書き込みと書き込みの非共存シナリオの一部が見逃される可能性があります。これらのシナリオはカバーできても、ロックの有効期限が切れた後に待機し、ロックの取得に失敗するシナリオをカバーすることは困難です。明らかに、これによりコード カバレッジが減少します。
4. インターフェイスにはキャッシュが含まれます
インターフェイス、特にクエリ インターフェイスでキャッシュ テクノロジを使用するのが一般的です。バッチクエリなど。インターフェイスにキャッシュが含まれる場合、従来のインターフェイス テスト ケースの設計ではキャッシュの影響を簡単に無視でき、インターフェイス キャッシュに関連する対象を絞った検証はありません。これにより、コード カバレッジも減少します。
省略分類 3. 異常シーンの無視
理論的に言えば、すべてのインターフェイスに異常なシナリオが存在する可能性があります
インターフェイスに何らかの異常なシナリオがある場合、フレームワークのエラーがスローされますが、これは通常は許可されません。言い換えれば、プログラマは通常、インターフェイス上で発生する可能性のある例外シナリオに対処する必要があります。いくつかの過酷なシナリオが出現しにくく、テスターは無視されやすいです。カバレッジがなくなると、コードのカバレッジが確実に減少します。例えば：
シナリオ 1: ダウンストリーム インターフェイスがタイムアウトを返す
上流サービスがこのサービスが提供するインターフェースを呼び出す場合、このサービスはこのインターフェース業務を処理する際に他のサービスにアクセスする必要があり、他のサービスの戻りがタイムアウトになる可能性があり、このサービスは通常は永遠に待機しません。
シナリオ 2: データベース接続のタイムアウト
特定のインターフェイスでデータを操作する必要がある場合、データベース サーバーのパフォーマンスは一定であり、いくつかのデータベース例外シナリオが存在する必要があります。これらのシナリオでは、通常、開発は何らかのコード処理を実行します。
シナリオ 3: キャッシュ サーバーの例外
ユーザーのログイン ステータス (キャッシュ サービスに保存されている場合)。キャッシュ サービスが異常または再起動された場合、多くのインターフェイスが影響を受けます。これらのシナリオもカバーする必要があります。
省略分類 4. その他の関連プロジェクトの構成
多くのプロジェクトのビジネス ロジックは、構成を通じて制御できますが、これも非常に一般的です。一部の機能の有効有無や起動モード、特定の業務内容の制御などを設定項目で行うことができます。
例えば：
機能イネーブルスイッチの設定
スイッチがオフの場合、この機能の業務コードはカバーされません。このタイプのコードがカバーできるようにするには、担当営業マンがスイッチをオンにしてテストする必要があります。
タイミングタスクの設定
設定に従ってスケジュールされたタスクの実行ポリシーを設定します。一部のスケジュールされたタスクは、さまざまな状態でデータを処理します。特定のタスク モードがテストされていない場合、または特定のモードのデータ ステータスが完全にカバーされていない場合、シーンは見逃されます。コードカバレッジを減らします。
次に、コード カバレッジを改善するにはどうすればよいでしょうか?
全体的なアイデア: 最初の部分で分析した理由により、コードを理解していないテスターがインターフェイスをより適切にテストし、これらのシナリオをカバーできるように最善を尽くすためにいくつかの対策を講じます。最終的にコードカバレッジを向上させます。
解決策 1. ブラックボックス テスト シナリオの省略
この種のシーン省略は比較的簡単に解決できます。具体的な対策: ユースケースの設計方法とプロセスを標準化し、基本的なテスターを有能にします。
解決策 2. インターフェイス内の特別な分岐点、例外シナリオ、およびプロジェクト構成関連のシナリオをカバーする
インターフェイス設計のユースケースからこれらのシナリオをカバーしたい場合は、これらのビジネス ロジックを知り、理解する必要があります。この目標を達成するには、次の 4 つのステップから確実に達成できます。
1. 開発はインターフェイスドキュメントを提供するだけでなく、インターフェイス実装ドキュメントも提供し、ドキュメントにはインターフェイスの実装プロセスが明確に記述されている必要があります。たとえば、インターフェースに関係する構成項目、非同期タスク、トランザクション、ロック、キャッシュなどを明確に記述する必要があります。フローチャートやシーケンス図を出力できるとベストです。この点は非常に重要であり、コード基盤を持たないテスターがインターフェイスのビジネスと実装の詳細を理解するのに非常に役立ちます。
2. テスターは要件レビューに参加するだけでなく、プロジェクト要件を習得します。インターフェースの具体的な業務理解を深めていくために、開発要件設計レビュー会議に参加することも必要です。テスターが一人で読んで勉強するのは難しいため、テスターはビジネスの実装を理解するために、より多くの対応する開発者を見つけることができます。
3. 要件が変更された場合、またはビジネスの実装が変更された場合は、関連する文書をタイムリーに伝達および更新します。
4. テスターは、ビジネス実装の熟練度に基づいてテスト ケースを設計し、インターフェイスの実装ビジネス シナリオをカバーします。
3. コードカバレッジを向上させる方法を理解しやすくするために、例を挙げます。
例 1. 非同期タスク - バッチ削除を例にします
プロジェクトでユーザーに優れたエクスペリエンスを提供するために、一部の削除インターフェイスには非同期削除タスクが含まれるのが一般的です。
例: 注文のバッチ削除 (電子商取引会社)、ファイルのバッチ削除 (特定のディスク) など。これらのデータのバッチ削除サービスの多くは、非同期タスクを通じて実装されます。
データ削除の仮説ロジックを大まかに書いてみましょう
分析します:
従来のインターフェイス テスト ケースの範囲では、これらの非同期タスクの他のブランチを無視するのが簡単です。理由も非常に単純で、QA はこれらのロジックを知りません。これらのシナリオは、インターフェイスを呼び出すときにトリガーするのも簡単ではありません。
開発者がこのフローチャートを提供すると、テスターはフローチャートに基づいてすべての分岐をカバーするテスト ケースを設計できます。
シナリオの例:
非同期タスクの書き込みに失敗しました
固定ユーザーの固定データを事前に書き込むことでデータ書き込みを防止可能（主キー競合等の対応）
データベース接続数の変更とインターフェースの一括削除
非同期タスクの実行に失敗しました
間違ったデータが事前に設定されていて、実行が失敗する可能性があります（一部のフィールドが欠落している、一部のフィールド値が間違ったデータである）
例 2. トランザクション
プロジェクトには、いくつかのトランザクションを伴うインターフェイス実装がいくつかありますが、これも非常に一般的です。
分析します:
インターフェースのテストケース設計では、ビジネスプロセス全体を考慮し、各ステップの例外を可能な限りカバーするように努め、ビジネスプロセス全体をカバーするためにさまざまなテストシナリオを設計します。
シナリオの例:
トランザクションで例外が発生し、ロールバックは成功しました。
例 3. ロック
プロジェクトでは、Web 側、アプリ側、小さなプログラムなど、複数端末での操作も比較的一般的です。次に、インターフェイスがデータの同じ部分で動作するシナリオがいくつかあります。
分析:
インターフェイスのテスト ケースを設計するときは、コード カバレッジを向上させるためにロック関連のシナリオを考慮する必要があります。
シナリオ例:
ロックを取得する
ロックなし
書き込みロックを取得する
読み取りロックを取得する
書き込みロックが存在します
読み取りロックを取得する
書き込みロックを取得する
読み取りロックが存在します
読み取りロックを取得する
書き込みロックを取得する
ロックを解除する
読み取りロック
ロックが正常に解除されました
ロックの解除に失敗しました
書き込みロック
ロックが正常に解除されました
ロックの解除に失敗しました
例 4. タスクのタイミングを計る
プロジェクトでデータをバッチで処理する必要がある場合、通常はオフピーク期間にスケジュールされたタスクを通じて実装することを選択します。
例: データ バージョンの移行、期限切れデータのクリーンアップなど。
分析します:
サーバー インターフェイスをテストするときは、これらのスケジュールされたタスクも検証する必要があります。コードカバレッジを効果的に改善できます。
ここでは主にタスク実行のデータステータスに重点を置きますが、データの包括性を確保するには、タスクの処理ロジックをカバーできるように、ライフサイクル全体を代表するデータが存在し、ある程度の大きさを持っている必要があります。
シナリオの例:
時限タスクがアクティブ化されているかどうか
スケジュールされたタスクが実行されるかどうか
タスクが実行される前に、データは包括的ですか (ライフサイクル全体のすべてのタイプをカバーしています)
4. インターフェイステストのカバレッジを確保する際に遭遇する可能性のある困難の分析
難点1. 開発側が提供するインターフェース実装ドキュメントが標準化されていない
開発および実装ドキュメントには特定のテンプレートと記述仕様が必要であり、開発者はドキュメントを出力することが厳密に要求されます。管理措置が必要です。
難しさ 2. テスターの理解の難しさ
ドキュメントでは、コードを減らしてプロセスの説明に重点を置く必要があります。
これは育成可能であり、難易度は特に高くありません。このテスターが進歩を望まない場合を除きます。
難しさ 3. 設計されたユースケースをテストできない
いくつかの異常なシナリオがあり、テストを実装するのは非常に難しいため、助けを求めることができます。
今、テスターとして、ユースケースを設計する際に、そのテストが実現できるかどうかを考える必要はない、とますます感じています。主にスキル不足のため、テストできません。したがって、ユースケースは正常に設計され、ユースケースの実行は大きなボスによって支援されることができます。
5. 最終的なまとめ
特定の実装要件
開発者は、インターフェイス実装ロジックをコード思考からドキュメント記述に変換します。これは、ノーコード基盤がプロジェクトのビジネスを理解するための前提条件です。ドキュメントは標準化され、レビューは明確であり、変更はタイムリーに同期される必要があります。
テスターは学習を強化し、ドキュメントを読み、レビューから学び、開発に相談し、ビジネス実装を理解する必要があります。
テスターはビジネスを深く理解しており、より包括的なテスト シナリオを設計し、テストを実装します。
意義
コード カバレッジ率が向上し、プロジェクトのテストがより完全に行われるようになります。より多くの隠れた問題を見つけることができます。
これにより、コーディング能力のないテスターでも急速に成長し、優れたテストを行うことができます。
開発・実装プロセスを標準化し、プロジェクトの開発・管理を促進する上でも一定の役割を果たします。
欠点がある
特に部門をまたがる業務の場合、最初は導入するのが難しいでしょう。
テストや開発には通信コストがかかります。
[以下は、私が編集した 2023 年の最も完全なソフトウェア テスト エンジニア学習ナレッジ アーキテクチャ システム図です]
1. Pythonプログラミングの入門から習得まで
2.インターフェース自動化プロジェクトの実戦
3. Web自動化プロジェクトの実戦
4. アプリ自動化プロジェクトの実戦
5. 一流メーカーの再開
6. DevOps システムのテストと開発
7. 一般的に使用される自動テストツール
8、JMeterのパフォーマンステスト
9. まとめ（最後にちょっとしたサプライズ）
寿命が長いのでオイルを追加してください。すべての努力は決して裏切られることはなく、粘り強く続ける限り、最後には必ずご褒美が得られます。自分の時間を大切にして夢を追いかけてください。初心を忘れず、前に進んでください。あなたの未来はあなたの手の中にあります！
人生は短く、時間は貴重です。将来何が起こるかを予測することはできませんが、現在の瞬間を把握することはできます。一日一日を大切にし、自分自身をより強く、より良くするために努力してください。確固たる信念、粘り強い追求、成功はやがてあなたのものになります。
常に自分自身に挑戦することによってのみ、常に自分を超えることができます。夢を追い続け、勇敢に前進すれば、その葛藤の過程がとても美しく、やりがいのあるものであることに気づくでしょう。自分を信じてください、あなたならできるよ！
