この記事では、APIを手動でテストする方法、自動化のどの段階を経たのか、信頼性が高く簡単にサポートされる自動テストを作成できるアプローチについて説明します。
SQA Days-12カンファレンスのレポートに基づきます。
nanoCADをテストするタスクは、2つの主要なグループに分けることができます。 1つ目は、設計者ツールとしてのnanoCADのテストです。主な質問は、「設計者は必要なものを描画できますか？」です。 2番目のグループはAPIテストです。ここでは、別の質問に対する答えを探しています。「これらのアプリケーションは動作するはずですか？」
ユーザーが作業するプログラムの手動テストにより、すべてが明確になります。 それでは、手動APIテストとは何ですか？ そして、通常の単体テストを使用してAPIをテストしてみませんか？
実際、ユニットテストはAPIの大部分をテストするのに適しています。 しかし、多くの関数があり、それらの呼び出しはユーザーアクションの要求につながります。 たとえば、アプリケーションは、GetPoint（）またはGetAngle（）関数を呼び出すことにより、ユーザーにポイントまたは角度の入力を求めることができます。 この機能がどのように機能するかを確認するには、すべてのメインオプションを使用してAPI関数を呼び出すテストアプリケーションを作成する必要がありますが、このようなテストを自動化するには、何らかの方法でユーザーのアクションを自動化する必要があります。
APIの手動テストスキームは次のとおりです。
各API関数をテストするための個別のコマンドが作成されました。 テスターはコマンドを手動で起動し、画面上のポイントを選択したり、座標を入力したりします。 テストケースに応じて。
: GetAngleTest UnitTest.dwg , : 0,0,0 : 100,100,0 . Esc: <Esc> 0. 0: 0 0. 0: 0 . 0. 0: 1 . Enter : <Enter> . Enter : <Space> . Enter : 1 . Enter : <Enter> . : #sqadays12 . Enter <135>: <Space> . [/-/]: . Enter <135> [/-/]: <Enter>
テストケースが完了すると、ログファイルが分析されます。
自動化を開始するには、「赤いボタン」を押してスクリプトを記録することから始めました。 奇跡は起こらず、予想通り、すべてのポイントがスクリーン座標で記録されました。
Window.MouseClick(100, 200); //
どうする 画面上の描画要素の位置は変化する可能性があるため、画面座標系は適切ではなく、信頼できる自動テストは次のものに依存するべきではありません。
- アプリケーションウィンドウとそのコントロールパネルのサイズと位置、
- OSのスタイルから、OSのさまざまなバージョンのコントロールを表示します。
- マルチモニター構成、
- そして、はるかに...
答えは明らかでした。点を図面の座標系に保存する必要があります。
しかし、テスト中に図面の座標を画面座標に変換する方法は？
この問題を解決する従来の方法は、nanoCADにロードされて座標変換を実行する自動テストシステム用のアダプターを作成することです。 ただし、このようなアダプターの作成は特定の自動テストシステムにバインドされるため、可能な限り回避し、代わりに既存のソフトウェアインターフェイスを使用することにしました。
COMモデルに、画面から図面への変換、およびその逆の変換を追加しました。
nanoCAD.Utility.CoordFromPixelToWorld() nanoCAD.Utility.CoordFromWorldToPixel()
テスト回路のテスターを自動テストシステムに置き換えました。
自動テストは次のようになります。
x_drawing = 3.14; // : y_drawing = 159265; // FromWorldToPixel(x_drawing, y_drawing, x_screen, y_screen); Window.MouseClick(x_screen, y_screen); // 100, 200, // .
このアプローチの欠点の1つは、そのようなスクリプトを自動的に作成できないことです。記録するとき、画面座標を図面の座標に動的に変換する必要があります。 完全なアダプターがあった場合、この問題は解決できます。
このアプローチの主な欠点は、テストロジックが2つの部分に分かれていることです。 テスト自体がnanoCADにロードされ、自動化スクリプトが自動化されたテストシステムにロードされます。 このようなテストは、保守とデバッグが困難です。テストロジックの変更には、2つの異なるモジュールの同期変更が必要です。
この欠点を取り除き、テストのロジック全体が1つのモジュールに収まるようにすることにしました。 次の2つのオプションが検討されました。
- テストのロジックは自動テストシステムにあり、ユニバーサルテストはnanoCADにロードされ、主要な自動テストから転送されたアクションを実行します。
- テストのロジックはnanoCADにあり、ユニバーサルテストは自動テストシステムにロードされ、ホストテストから転送されたアクションを実行します
最初のオプションは、手動でテストを実行する機会を奪うため、適切ではありません。 2番目のオプションである、すべてのユニバーサル自動テストが使用するライブラリを選択し、「ユニバーサルプレーヤー」と呼びました。
テスト設計は以前のものより複雑に見えるという事実にもかかわらず、テストの保守がはるかに簡単になりました。 現在、自動テストスクリプトには、テストの名前とユニバーサルプレーヤーの起動コードのみが含まれています。 ユニバーサルプレーヤーは、テストモジュールにアクションのリストを要求し、それらを順次実行します。
実際にはどのように見えますか？ 例に戻りましょう-記事の冒頭で述べたGetAngle（）関数のテスト。
: GetAngleTest ... , : 0,0,0 : 100,100,0 ...
nanoCADにロードされたGetAngleTestコマンドは、手動または自動で実行できます。
[CommandMethod("GetAngleTest")] public void GetAngleTest() { // UI testRunner.AddAction(new ActionClickDocument(0, 0, 0)); testRunner.AddAction(new ActionClickDocument(100, 100, 0)); testRunner.SendActions(); // EditorInput.Editor.GetAngle() PromptAngleOptions opts = new PromptAngleOptions(" "); PromptDoubleResult pr = this.ed.GetAngle(opts); // thisAssert.IsTrue((pr.Status == PromptStatus.OK) && (pr.Value > 0), " . " + pr.ToString()); }
RunGetAngleTest自動テストは、GetAngleTestコマンドから送信されたアクションのみを実行します。
[TestMethod] public void RunGetAngleTest() { // 'GETANGLETEST' Keyboard.SendKeys(uICommandLineEdit, "GETANGLETEST{Enter}", ModifierKeys.None); // UI this.ProcessUIActions(context); }
現在、ユニバーサルプレーヤーはVisual Studioのコード化されたUIテスト専用に作成されています。 ただし、理論的には、自動テストを別のシステムに転送するには、ユニバーサルプレーヤーを書き換えるだけで十分です。各自動テストシステムで利用可能な基本機能のみを使用しました。
ところで、当社にはテスター向けの空席があることに気づきましたか？
記事に関する議論は、フォーラム（ forum.nanocad.ru/index.php?showtopic=6513）でも利用できます。