はじめに
私は以前、インターフェース自動化テストのためのユニットテストフレームワークの使用についての記事を共有しました-Python インターフェース自動化テストフレームワーク+データとコード分離に基づいて（高度な記事）、この記事では主に設計のアイデアと簡単な実践について説明します。しかし、編集者たちは実際の戦闘に努め、たまたまプロジェクトのニーズに応えました。格言のとおり：偽のトリックを実践しないと、多くの人々がブログを書いていくつかの小さな例を見つけ、彼らは一連のフレームワークを学んだと感じ、さらにはオープンであるとさえ感じます。実際、それ以外の場合は、プロセスを使用するときに多くの問題が見つかります。特に、会社の洗練されたインターフェースと複雑なビジネスロジックです。過去に構築されたフレームワークは不完全であり、すべてのシナリオに完全に適用できるわけではありません。現時点では、常に最適化し、実際に完璧にする必要がありますが、これも非常にまれです。能力を向上させるには、このプロセスを継続的に調査および学習する必要があります。
ユニットテストスキップテスト
初期バージョンでは、ほとんどのプロジェクトのインターフェース開発が完了した後、インターフェーステストを実行できます。プロジェクトの後半では、手入れの行き届いたインターフェーステストケースとスクリプトを回帰テストに使用して、手動テストとテストケーステストシナリオの設計に時間を費やすことができます。以前のデザインパターンDDTを考慮して、すべてのテストケースが完全に実行されます。テストケースの一部を実行したい場合はどうなりますか？unittestフレームワークに基づくスキップテストの使用：
通常の状況では、unittestは各テストケース（test_で始まるメソッド）を自動的にテストしますが、特定のテストケースを一時的にスキップする場合は、2つの実装方法があります。
方法1：skipXxxデコレーターを使用してテストケースをスキップするUnittestは、合計3つのデコレーターを提供します。
@ unittest.skip（理由）-----無条件スキップを表します。
@ unittest.skiplf（条件、理由）-----条件がTrueのときにスキップすることを意味します。
@ unittest.skipUnless（条件、理由）------条件がFalseの場合にスキップすることを意味します。
方法2：TestCaseのSkipTest（）メソッドを使用してテストケースをスキップする
ケースプレゼンテーション：
ユニットテストをインポートする
クラスTestHello（unittest.TestCase）：
＃say_hello（）関数をテストする
def test_001（self）：
self.assertEqual（1 + 2,3）
印刷（ "test_001：実行済み"）
＃add（）関数をテストする
@ unittest.skip（「一時的にtest_002をスキップ」）
def test_002（self）：
self.assertEqual（（3 + 4）、7）
self.assertEqual（（0 + 4）、4）
self.assertEqual（（-3 + 0）、-3）
印刷（ "test_002：実行済み"）
def test_003（self）：
self.skipTest（ "test_003を一時的にスキップします"）
印刷（ "test_003：実行済み"）
__name__ == '__main__'の場合：
unittest.main（）
結果は次のとおりです。
DDTスキップテスト
上記はunittestスキップテストで、ddt自体もunittestフレームワークを使用しており、この方法でも実装できます。ただし、ここでは紹介しません。別の方法を使用します。テストデータはExcelファイルに保存され、読み取り操作と書き込み操作は以前に実装されています。この場合、実行するテストケースを読み取るようにスイッチを設定できます。
例：
ユースケースの実行を制御するために使用されるフィールドをデータ駆動型テンプレートに追加します。
次に、コア実行プログラムに論理判断を追加します。
テスト結果とログの最適化
結果をカウントして、転送するときに、成功と失敗、および失敗の理由を追跡できるようにします。
演算結果：
ログを印刷：
すべてのユースケースが実行されるかどうかを確認していますか？
合計134-1が維持され、その後、すべてのユースケース実行スイッチがオンになったため、実行ログは、合計数が133、133の実行、132の成功、1つの失敗であることを示しました。詳細なログデータには守秘義務契約がございますので、ここに写真を掲載するのは不便です、ご了承ください。
動的グラフ：
テストレポート
レポートと印刷されたテスト結果データは一貫しており、問題がないことがわかります。
トラブルシューティング
上記は基本的に表示用に最適化されており、一部のインターフェイスでは、結果の['message']フィールドをパッケージ化しますが、テストするインターフェイスでは、すべてのインターフェイスから返されるjson文字列にメッセージフィールドがありません。各会社の開発には独自のスタイルがあり、ユニフォームがない場合、これは、私が遭遇したインターフェイス、結果が返された結果['msg']、一部が結果['message ']。作成するアサーションメソッドはassertEqualであり、そのうちの1つが使用されていますが、インターフェースが多数あり、一部にこのフィールドがない場合があります。この方法で作成すると、エラーが報告されます。コードロジックを変更してください。最も簡単な方法は、条件付き判断を直接使用して処理を回避することです。
インターフェース1のデータを返します。
インターフェース2のデータを返します。
別の例として、たとえば、私たちが書いたコードは、インターフェイス（json文字列）のシリアル化されたデータを取得しますが、一部のインターフェイスはjson形式を返さず、実際のプロジェクトでも他の形式である場合がありますインターフェイス、返されるデータは動的な値または定数値です。現時点では、データをフェッチする方法はres.json（）です。エラーである必要があります。また、変数値の場合、アサートすることはできません。期待される結果がわからないため、変化します。ただし、ルール、つまり生成されたロジックについては、ルールがないわけではありません。開発と通信する必要があると、このロジックを記述し、最後にアサートします。この種のインターフェースだけで作成するのは簡単ではありません。したがって、通常はインターフェイステストを行って、より多くのことを考えます。
まとめ
上記は、実際のプロジェクトで自動テストフレームワークが使用されている問題です。これらの問題は、以前に発生したことも、発生したこともないかもしれませんが、考えたことはありません。もちろん、これらの問題に対処するためのより良い方法があれば、テストに参加できます。 QQグループを開発して交換し、コミュニケーションと学習を行います：696400122。このグループは学習とコミュニケーションに焦点を当てており、すべての乾物は研究され、実際のプロジェクトでの実際の戦闘事例を背景として詳細に共有されています。