0

テスト自動化で設計上の問題が発生しています:-

要件 - 自動化フレームワークを介して (GUI ではなく UNIX コンソールを使用して) さまざまなサーバーをテストする必要があります。実行するテスト - ユニット、システム、統合

質問: テスト ケースを設計しているときに、Python の pyunit フレームワークと同じように、テスト ケースをテスト スイートの一部にする必要があると考えています (テスト スイートはクラスです)。しかし、テスト ケースをスケーラブルな自動化フレームワークの関数として保持する必要がありますか?それとも、テスト ケースを個別のクラス (それぞれ独自のセットアップ、実行、分解メソッドを持つ) として保持する必要がありますか? 自動化の観点から、テストケースをクラスとして持つという考えは、よりスケーラブルで保守しやすいものですか、それとも関数として持つものですか?

4

2 に答える 2

0

各テスト ケースには独自のセットアップ データと初期化メカニズムがあるため、通常、テスト ケースは関数ではなくクラスとして使用されます。テスト ケースを単一の関数として実装すると、テスト ケースを実行する前にテスト データをセットアップするのが難しくなるだけでなく、同じテスト シナリオを実行している場合、テスト ケース クラスに異なるテスト メソッドを含めることができます。

于 2012-10-13T08:38:58.047 に答える
0

以下は私の意見です。

関数としてテストを書くことの長所:

  • そのテスト ケースの前提条件が必要な場合は、前提条件を提供する別の関数を呼び出すだけです。ティアダウン手順についても同じことを行います
  • チームの新しい人にとってはシンプルに見えます。テストを関数として見ることで、何が起こっているのかを簡単に理解できます

テストを関数として書くことの短所:

  • 保守不可能 - 同じ種類の前提条件が必要なテストが多数ある場合、テスト ケースの作成者は、テスト ケース内の各前提条件関数の呼び出しを維持する必要があるためです。テストケース内の各ティアダウンで同じ

  • 多くのテスト ケース内でこのような前提条件関数の呼び出しが非常に多く、製品の機能などに何か変更があった場合は、多くの場所で手動で再度作業を行う必要があります。

テスト ケースをクラスとして記述する利点:

  • セットアップ、ラン、ティアダウンが明確に定義されています。テストの前提条件が簡単に理解できる
  • 何かを行うテスト 1 があり、テスト 1 の結果がテスト 2 および 3 のセットアップの前提条件として使用される場合、テスト 1 から継承し、そのセットアップを呼び出し、ティアダウン メソッドを最初に実行し、次に、テストを続行します。これにより、テストを互いに独立させることができます。ここでは、コードの実際の呼び出しを維持するために努力する必要はありません。継承のため、暗黙的に行われます。
  • 場合によっては、テスト 1 の setup メソッドとテスト 2 の run メソッドが別のテスト 3 の前提条件になる場合があります。その場合は、テスト 1 とテスト 2 の両方のクラスから継承し、テスト 3 のセットアップ メソッドで呼び出します。テスト 1 のセットアップとテスト 2 の実行。この場合も、実際のコードの呼び出しを維持する必要はありません。これは、フレームワークの観点から試行およびテストされるセットアップ メソッドと実行メソッドを呼び出すためです。

テストケースをクラスとして書くことの短所:

  • テストの数が増えると、特定のテストを調べて、それが何をするのかを言うことができなくなります。しかし、それを回避する解決策があります - 各テストケースのセットアップ、実行、ティアダウンメソッドごとにドキュメント文字列を記述します。そして、カスタム ラッパーを作成して、各テスト ケースのドキュメント文字列を生成します。継承中/継承後、特定の関数 (セットアップ、実行、ティアダウン) のドキュメント文字列を継承された関数に追加/削除するオプションを提供する必要があります。このようにして、そのラッパーを実行するだけで、ドキュメント文字列からテスト ケースに関する情報を取得できます。
于 2012-10-13T09:06:38.530 に答える