ビジュアル テストやスクリプトなどの Silk Test Workbench 資産を作成してアプリケーションのテスト ソリューションを構築する前に、テスト戦略を立てることをお勧めします。
1 つのビジュアル テストまたはスクリプトに特定のテスト ソリューションのすべての部分を含める必要はありません。また、通常、そうすることは有益ではありません。
通常、最も効率のよいテスト方法は、モジュール式アプローチを採用したものです。 アプリケーション テストを一連のトランザクション単位として考えます。
たとえば、オンライン発注システムのテストには、以下のようなトランザクション単位が含まれるかもしれません。
オンライン システムへのログオン
顧客プロファイルの作成
注文の発注
オンライン システムのログオフ
1つのテストでこれらの単位をすべて処理し、このテストを使用するシナリオが10通りある場合、それらのシナリオを処理するために10個の別々のテストを記録する必要があります。 アプリケーションに何らかの変更があった場合、たとえば、ログオン ウィンドウにフィールドが1つ追加された場合、新しいフィールドへのデータ入力を処理するために10個の別々のテストに変更が必要になります。
これらのトランザクション単位をすべてテストするビジュアル テストまたはスクリプトを 1 つ作成して、それをシナリオごとに 10 個作成するよりも、これらのトランザクション単位を 1 つずつ処理する別個のテストをテスト「モジュール」として作成する方が有益です。 トランザクション単位ごとに別々のテストを作成し、それをテスト シナリオごとに再利用すれば、ログオン トランザクション単位を処理するテストだけを変更すればよいことになります。
ドライバ スクリプトを実行すると、各テストが連続して呼び出されて実行されます。
モジュール式アプローチでは、在庫確認のテストを行う追加のテストを 1 つ作成し、それが適切な順序で呼び出されるようにドライバ スクリプトを更新できます。 以下の例は、別々のスクリプトを呼び出してオンライン発注システムをテストするドライバ スクリプトを示しています。
Workbench.RunScript ("OnlineLogOn_Script")
Workbench.RunScript ("CreateProfile_Script")
Workbench.RunScript ("ValidateStock_Script")
Workbench.RunScript ("PlaceOrders_Script")
Workbench.RunScript ("OnlineLogOff_Script") このようなモジュール式のテスト戦略を実施すると、テスト フローの変更も容易です。
たとえば、注文発注前の在庫確認など、オンライン発注システムのテストに追加のトランザクション単位が必要になった場合、10個の異なるテスト シナリオがあれば、在庫確認を処理する10個のスクリプトを変更しなければなりません。
このようなモジュール式アプローチは、再利用性は向上しますが、毎回異なるデータを使用して一連のトランザクション単位を複数回繰り返すようなテスト戦略を要する、異なるテスト「シナリオ」に対応するには十分とは言えません。 アクティブ データを使用すると、外部データ ソースを使用して、アプリケーション テストでのモジュール式テスト スクリプトの再利用を促進できます。
また、ソリューションをテストするためにドライバ スクリプトから関数を呼び出すこともできます。関数は、他のアプリケーション テストで再利用することができます。