自動テストの生成：Excel、XML、XSLT、そしてどこでも

問題

アプリケーションには特定の機能領域があります。データの状態を分析して結果を生成する特定のエキスパートシステム-一連のルールに基づいた多くの推奨事項です。 システムコンポーネントは特定の単体テストのセットでカバーされますが、主な「魔法」はルールに従うことです。 ルールのセットはプロジェクト段階で顧客によって決定され、構成は完了します。

さらに、最初の受け入れ後（長くて難しい-「手動」で）エキスパートシステムのルールは、顧客の要求に応じて定期的に変更されるため、システムの回帰テストを実施して、ルールは引き続き正しく機能し、最後の変更によって副作用は発生していません。



主な難しさは、シナリオの準備でさえありません-それらはありますが、その実装です。 スクリプトを「手動で」実行する場合、時間と労力の約99％がアプリケーションでのテストデータの準備に費やされます。エキスパートシステムがルールを実行し、結果を分析するのにかかる時間は、準備部分に比べてわずかです。テストの複雑さは深刻なマイナス要因であることが知られています。顧客の側に不信を生じさせ、システムの開発に影響を与えます（「何かを変更したら、もう一度テストする必要があります...それで...」）。



明らかな技術的解決策は、すべてのスクリプトを自動化したスクリプトに変換し、リリーステストの一環として、または必要に応じて定期的に実行することです。 しかし、私たちは怠け者であり、テストシナリオのデータを非常に簡単に（理想的には顧客が）準備し、それに基づいて自動テストを自動的に生成する方法を見つけようとします。



ネコの下で、このアイデアを実装する1つのアプローチについて話します-MS Excel、XML、およびXSLT変換を使用します。

テストは主にデータです

そして、特に準備のできていないユーザーにとって、データを準備する最も簡単な方法はどこですか？ 表の中。 だから、まず第一に-MS Excelで。



個人的に、私はスプレッドシートが本当に好きではありません。 しかし、そうではありません（原則として、これは使いやすさの基準です）が、彼らはプロではないユーザーの心に「データとプレゼンテーションを混合する」という概念を浸透させ、育成しているためです（そして今ではプログラマーは無限のマルチレベルの「シート」からデータを選択しなければなりません。すべてがあります-セルの色とフォントの両方）。 しかし、この場合、問題について知っており、それを排除しようとします。

だから、問題の声明

• MS Excelでデータを準備します。 フォーマットは、データ準備の利便性の観点から合理的であり、さらなる処理のために単純であり、ビジネスユーザーへの転送のためにアクセス可能である必要があります（後者はオプションです。最初はツールを作成します）。
• 準備されたデータを受け入れ、テストコードに変換します。

解決策

いくつかの追加の紹介：

• Excelでのデータのプレゼンテーションの具体的な形式はまだ明確ではなく、最適なプレゼンテーションを求めてわずかに変更されるようです。
• テストスクリプトのコードは、時間の経過とともに変化する可能性があります（デバッグ、欠陥の修正、最適化）。

両方の点から、テストの初期データは、入力が実行される形式と、入力とテストが自動テストコードに変換されるプロセスの両方から極端に分割されるべきであるという考えに至ります。



データを任意のテキスト表現に変換するためのよく知られた技術はテンプレートエンジンであり、特にXSLT変換は、柔軟性、シンプル、便利、および拡張性があります。 追加のボーナスとして、変換を使用すると、テスト自体の生成（プログラミング言語に関係なく）とテストドキュメントの生成の両方が可能になります。



したがって、ソリューションアーキテクチャは次のとおりです。

1. データをExcelから特定の形式のXMLに変換する
2. XSLTを使用してXMLを任意のプログラミング言語のテストスクリプトの最終コードに変換する

両方の段階での特定の実装は、タスク固有である場合があります。 しかし、どのような場合でも役立つと思ういくつかの一般的な原則を以下に示します。

ステージ1. Excelでのデータメンテナンス

ここでは、率直に言って、データをテーブルブロックの形式で維持することに限定しました。 ファイルの断片が写真にあります。

1. ブロックは、ブロックの名前（セル「A5」）を含む行で始まります。これは、xml要素の名前として使用され、コンテンツが要件を満たす必要があります。オプションの「タイプ」（セル「B5」）属性値として使用されるため、制限もあります。
2. 表の各列には、ビジネス用語を表す「正式な」名前（行8）に加えて、「タイプ」（行6）および「技術名」（行7）の2つのフィールドが含まれます。 データを準備するプロセスでは、技術分野を非表示にすることができますが、コード生成中に使用されます。
3. テーブルの列は任意の数にすることができます。 スクリプトは、「タイプ」の空の値を持つ列（列D）を検出するとすぐに、列の処理を終了します。
4. アンダースコアで始まる「タイプ」の列はスキップされます。
5. テーブルは、最初の列に空の値を持つ行が見つかるまで処理されます（セル "A11"）
6. スクリプトは3つの空行の後に停止します。

ステージ2. Excel-> XML

データをExcelワークシートからXMLに変換するのは簡単な作業です。 変換はVBAコードを使用して行われます。 選択肢はあるかもしれませんが、私には最も簡単で最速の方法のように思えました。



以下では、いくつかの考慮事項のみを示します-最終ツールを保守および使用するのにより便利にする方法。

1. コードはExcelアドイン（.xlam）の形式で表示されます-テストデータを含むファイルの数が1つ以上で、これらのファイルが複数の人によって作成/サポートされている場合のコードサポートを簡素化します。 さらに、これはコードとデータを分離するアプローチと一致しています。
   
   
   
   
2. XSLTテンプレートは、アドインファイルと同じディレクトリに配置されます-サポートを簡素化するため。
   
   
   
   
3. 生成されたファイル：中間XMLおよびコード付きの結果ファイル。ソースデータを含むExcelファイルと同じディレクトリに配置することをお勧めします。 テストスクリプトを作成する人は、結果を処理するのにより便利で高速になります。
   
   
   
   
4. Excelファイルには、テスト用のデータを含む複数のシートが含まれている場合があります-テスト用のデータのばらつきを整理するために使用されます（たとえば、各ステップでシステムの反応を確認する必要があるプロセスがテストされている場合）：シートをコピーし、入力データの一部と予想される結果を変更しました-完了です。 1つのファイルにすべて;
   
   
   
   
5. Excelブック内のすべてのシートには一意の名前を付ける必要があるため、この一意性はテストスクリプトの名前の一部として使用できます。 このアプローチにより、スクリプト内のさまざまなサブシナリオの名前の一意性が保証されます。 また、テストスクリプトの名前にファイル名を含めると、スクリプト名の一意性がさらに簡単になります。これは、複数の人がテストデータを個別に準備する場合に特に重要です。 さらに、命名の標準的なアプローチは、テスト結果を分析する際に将来的に役立ちます-実行結果からソースデータへの取得は非常に簡単です。
   
   
   
   
6. ブックのすべてのシートのデータは、単一のXMLファイルに保存されます。 私たちにとって、これはテスト文書の生成の場合、そして場合によってはテストスクリプトの生成の場合に適切であると思われました。
   
   
   
   
7. テスト用のデータファイルを生成するとき、生成にソースデータを含む別のシートを含められないことが便利でした（たとえば、5つのシナリオのいずれかのデータがまだ準備できていません-テストを実行する時間です）。 これを行うには、契約を使用します。名前がアンダースコアで始まるシート-生成から除外されます。
   
   
   
   
8. ファイルにテストデータ（「ドキュメント」）を作成するためのシナリオの詳細が記載されたシートを保持しておくと便利です。そこから顧客の情報をコピーしたり、コメントを付けたり、他のデータシートが参照する基本データと定数を保持したりできます。 もちろん、このシートは生成に関与していません。
   
   
   
   
9. テストスクリプトの最終コードを生成するいくつかの側面に影響を与えることができるように、テストデータではなく、コードのセクションを含めるまたは除外するためにテンプレートで使用できる追加の情報「生成オプション」を最終XMLに含めると便利であることが判明しました（プラグマ、定義、など）これを行うには、非生成オプションシートにある名前付きセルを使用します。
   
   
   
   
10. テストデータの各行には、XMLレベルで一意の識別子が必要です。これは、コードを生成し、テストデータの行間のクロスリンクを処理する際に非常に役立ちます。

ステージ3. XML->コード

この部分は、解決されているタスクに非常に固有であるため、一般的な発言に限定します。

1. 最初の反復は、シート（さまざまなテストケース）を表す要素で始まります。 ここで、ユーティリティのセットアップ/分解ブロックを配置できます。
   
   
   
   
2. スクリプト要素内のデータ要素の反復は、期待される結果の要素から開始する必要があります。 したがって、「1つのテスト-1つのテスト」の原則に基づいて、生成されたテストを論理的に整理できます。
   
   
   
   
3. データが生成され、チェック対象のアクションが実行され、得られた結果が制御される領域をテンプレートレベルで明示的に分割することをお勧めします。 これは、モード付きのテンプレートを使用することで可能です。 このようなテンプレートの構造により、将来的に他の生成オプションを実行できるようになります。このテンプレートをインポートして、新しいテンプレートの必要な領域をオーバーラップするだけです。
   
   
   
   
4. コードとともに、同じファイルでテストを実行する際のヘルプを含めると便利です。
   
   
   
   
5. データ生成コードを個別に呼び出されるユニット（手順）に分離すると非常に便利です。テストの一部としても、独立して、デバッグやテストデータのセットの作成にも使用できます。

最終コメント

しばらくすると、テストデータを含むファイルが多くなり、テストスクリプトを生成するためのテンプレートのデバッグと「研磨」が続行されます。 したがって、一連のソースExcelファイルから自動テストを「大量」生成できるようにする必要があります。

おわりに

説明したアプローチを使用すると、テストデータまたは完全に機能する自動テストを準備するための非常に柔軟なツールを取得できます。



私たちのプロジェクトでは、複雑な機能領域の統合テスト用のテストスクリプトのセットをすばやく作成できました。現在、約180のtSQLtテストクラス（MS SQL Server側のロジックをテストするためのフレームワーク）で約60のファイルが生成されています。 計画では、このアプローチを使用して、このプロジェクトおよびプロジェクトの他の機能領域のテストを拡大する予定です。



ユーザー入力形式は以前のままであり、最終的な自動テストの生成は必要に応じて変更できます。



ExcelファイルをXMLに変換し、変換を開始するためのVBAコード（およびExcelとXMLの例）は、GitHub github.com/serhit/TestDataGeneratorで取得できます。



XSLT変換は、特定のタスク用のコードを生成するため、リポジトリには含まれていません-まだ独自のものがあります。 私はコメントとプルリクエストに喜んでいます。



幸せなテスト！