デスクトップアプリケーションの自動テスト：利便性とフレームワークの概要

はじめに

あなたは確かに回帰と受け入れテストについて聞いたことがあります。しかし、プロジェクトでの検収試験に実際にどれだけの費用がかかっているか知っていますか？
TMetricのような時間追跡システムの助けを借りて、これに対する答えをすばやく得ることができます。
私たちのプロジェクトでは、検収試験約100のアセンブリのデスクトップアプリケーションは、2人週以上かかりました。アプリケーションをよく知らなかった新しいQAスペシャリストは、最大の問題を抱えていました。経験豊富なQAスペシャリストと比較して、各テストケースに多くの時間を費やしました。
しかし、私の意見では、最も不快な部分はこれでした。リリース前に重大なエラーが見つかった場合は、受け入れテストを再度実行する必要があります。これらのエラーが修正された後。
書面による単体テストは少し役に立ちましたが、それでも回帰テストに費やす時間を大幅に削減しました。これにより、手動テストの量がクリティカルレベルに達したときに、自動化に移行し始めました。

ROI

自動UIテストを作成する前に、投資の収益性を評価する必要がありました。これは、ROI（Return On Investment https://en.wikipedia.org/wiki/Return_on_investment）の助けを借りて行いました。
UIテストのROIの計算も、複数の未知の変数を使用する興味深いタスクになりました。

ROI=利益/費用
または
ROI=（利益–費用）/費用

この段階で、必要なすべての費用を見積もるのに役立つ小さなプロトタイプが必要でした。非常に独特な結果が示されました。受け入れテストの実行には、このプロセスの自動化とほぼ同じ時間がかかります。最初、この情報は疑わしいように見えましたが、さらに調査すると、理由が明らかになりました。

新しいQAスペシャリストは、テストケースで説明されている手順についての理解が限られている可能性があります。これが発生した場合、状況をよりよく理解するために、数人の人々が検収試験に参加します。ここでは、環境設定と要件に関して私たちが持っている情報がどれほど関連性があるかという問題にも留意する必要があります。
検収試験に携わる人々は、技術文書の学習に時間を費やすことがあります。
アプリ自体が特定のサービスセットと相互作用します。それらの1つが利用できない場合、経験の浅いQAスペシャリストは、開発者が調査するバグの説明に時間を費やします。その結果、停電/ハードウェアの更新/コンピューターの再起動後に必要なサービスが適切に実行されなかったため、時間が無駄になります。
QAテスターのコンピューターはそれほど強力ではありません。 SSDがない場合は、インストール中にすでに気付くでしょう。また、アプリが高負荷で動作している場合は、低速のページングファイルが使用される可能性があります。
正直なところ、私たちは夢中になり、自動化に取り組んでいることを忘れていました。ちなみに、ブラウザの[YouTube]タブを閉じましたか？

それでは、ROIに戻りましょう。簡単にするために、計算は時間ごとに実行されました。手動テストの節約として利益を計算してみましょう。調査期間は1年です：

利益=（X – Y）* N =（60 – 1）* 8=472日

X –手動テストに費やされた時間（60日）
Y –自動テストの実行に費やされた時間（1日）
N –受け入れが実行された時間

次に、費用を見ていきます：

経費=A+ B + C + D + E + F =0 + 10 + 5 + 50 + 7 + 8 =80

A –自動化ツールライセンスのコスト。この例では、無料のツールを使用しました。
B – QAスペシャリストのトレーニング（10日）
C –インフラストラクチャの準備（5日）
D –テストの開発（50日）
E –テストの実行とプロセスで発見されたバグの説明（7日）
F –テストのメンテナンス（8日）

合計：

ROI=利益/費用=472/80=5,9

もちろん、ここでのいくつかの側面は推定されています。独自の計算を評価するために、有料ソリューションとさまざまなROI計算機が提供する機能の調査に時間を費やしました。これにより、平均ROI値2または3を計算しました。これは、すばらしい結果です。

既存のフレームワーク

組織的な質問を見てきたので、技術的な種類の質問に焦点を当てましょう。それらの中で最も重要なのは、デスクトップアプリケーションのテストを自動化するためのフレームワークを選択することでした。プロジェクトの機能に基づいて、次の要件がありました。

テストはWindowsマシンで開発および実行されます
フレームワークは、デスクトップアプリケーションのテストに適合させる必要があります
UIテストはCIプロセスに統合できます。すでにJenkinsを使用していたので、ここが望ましい
ユーザーフレンドリーなIDEでテストを作成する機能–構文の強調表示、テストスクリプトのナビゲーション、およびIntelliSenseスタイルのコード補完が必要です
QAトレーニングの最小限の費用。特定の理由で、QAスペシャリストはBrainfuckでテストを作成したくありませんでした
Stack Overflow、MSDNなどのコミュニティが望ましい

TestComplete

このプラットフォームは、その成熟度から当初は魅力的であり、技術的な側面に期待を寄せていました。
最初に遭遇したのは、不安定でかなり時代遅れのIDEでした。環境は構文の強調表示を多かれ少なかれ適切に処理しましたが、ナビゲーション（定義に移動）、検索、およびコードのオートコンプリートに重大な問題がありました。この機能は、約60％の時間でまったく機能しませんでした。内蔵レコーダーとInspectアナログは正常に機能しました。結局、IDEがアプリケーションに引数を渡し始めたとき、IDEは私たちに不快な驚きを与えました。これにより、予想どおり、アプリケーションのパフォーマンスにエラーが発生しました。

--no-sandbox
program files (x86)\smartbear\testcomplete12\x64\bin\Extensions\tcCrExtension\tcCEFHost.dll;application/x-testcomplete12-0-chrome-browser-agent

この段階では、ライセンスを購入する前に、時間を節約し、技術サポートの品質を評価するために、TestCompleteのサポートを状況に取り入れました。テクニカルサポートに数通の手紙が送られた後、私たちは答えを得ました–アプリケーションに渡された引数を無視する必要があります。変ですね。さらに調査したところ、CEFを使用するアプリケーションをテストするには、これらの引数が必要であることがわかりました。次の手紙では、CEFを使用していると述べ、サポートスペシャリストから議論を無視しないように言われました。それらを正確に使用する方法を尋ねたところ、答えは「引数を無視する」に戻りました。
テクニカルサポートとの会話を終えて、IDEのドキュメントに目を向けました（あまり期待せずに）。より多くの情報がありましたが、問題の事件に関連するものは何も見つかりませんでした。また、この同じドキュメントによると、IDEは最初とは異なる動作をするはずです。
TestCompleteのテストはVBScriptを使用して記述されると想定されています。

十分に長く見れば、これを聞くことができます。 Microsoftは、この「驚異」をPowerShellスクリプトに変換することをお勧めします。別の方法として、JavaScriptとPythonを使用することもできます。これは、状況を改善するのに役立ちます。

無料のツールとして、TestCompleteは耐えられるでしょうが、彼らのサイトには価格設定ページがあり、価格はユーザーごとです。結果として、これはツールを購入した後に得られるものです：

閉じたいIDE
1996年のスクリプトとの互換性
すべてを手動で記述しないようにするためのレコーダー
別の検査ですが、ベルとホイッスルが付いています
2種類のテクニカルサポートの回答
現実を表していないドキュメント

史上最悪の貿易協定、先に進みましょう。

コード化されたUI

戦術的な撤退、再編成、そして私たちは問題に直面します。一方では、VisualStudioをIDEとして使用する方法を学びました。一方、私たちのアプローチは、使用しているDevExpressUIコンポーネントに基づいていました。その結果、UIテストを自動化するためにDevExpressで公式に使用されているCodedUIフレームワークに関する興味深い情報が見つかりました。このフレームワークは内部テストプロセスに非常に統合されているため、Visual Studio拡張機能もあります。
広範なコミュニティがあり、MicrosoftはWebサイトでツールを宣伝し、この製品は「Microsoft VisualStudio」チャネル。簡単に言うと、すべてが有望に見え、フレームワークの準備を開始しました。
最初に遭遇した要件は、VisualStudioEnterpriseでした。さらに、このバージョンのVisual Studioは、テストを作成するだけでなく、テストを実行するためにも必要でした。これは、CIの場合に起動が実行されるmstestもEnterpriseエディションの一部である必要があることを意味します。
VSのインストールまたは変更時に対応するチェックボックスを有効にすることで、必要なすべてのコード化UIツールをインストールできます。

テストを作成するアプローチはかなり快適でした。シェルに統合されたコマンドにより、単体テストとUIを記述する「マップ」クラスを生成するレコーダーをすばやく起動できました。 VSに統合された追加のツールは、コードを呼び出さずに個別のテストクラスを作成する機能を提供しました。
私たちが気付いた唯一の特徴は、コントロールの説明があり、2つの部分に分割された部分クラスでした。他の多くのものとともに、それはドキュメントで説明されています。このドキュメントは、快適な作業プロセスに十分です。コード例とスクリーンショットにより、すべての技術情報に簡単にアクセスでき、理解しやすくなります。簡単に言うと、レコーダーがUIを記述すると、「Designer.cs」ファイルが生成されます。このファイルは、ユーザーインターフェイスを説明するコードを再利用する役割を果たします。レコーダが処理できなかったものはすべて手動で記述し、クラスの自動生成された部分以外の場所に保存する必要があります。これは、コントロールを作成するときにVS設計者によって記述された部分クラスと非常によく似ています。コントロールで実行される操作とその状態チェックの優先順位は、レコーダーが標準のTestMethod属性を追加するのに役立つメソッドで説明されます。
レコーダーが生成したものを調べ始めると、フレームワーク上に雲が集まり始めました。。まず第一に、それはアプリケーションの問題のいくつかを覆い隠しました：いくつかのコントロールのNameプロパティが指定されておらず、レコーダーはこのばかげたルール違反のインスタンスを受け入れ可能と見なし、テキストを通してコントロールを検索しました。また、複雑なコントロールを非常に非効率的に処理しました。たとえば、TreeViewノードはノードインデックスによって検索されたため、作成された「マップ」クラスはインターフェイス拡張の場合に使用できなくなりました。そして、レコーダーの価値は私たちの目には大幅に低下しました。後でチェックする必要がある場合、コードを自動生成する意味は何ですか？
これらすべてを和らげ、立派な解決策を見つけることができましたが、突然、雷が鳴りました：Microsoftこの技術は現在廃止されていると述べた。これにより、VS2019はコード化されたUIをサポートするVisualStudioの最後のバージョンになりました。現在および数年前にVS2019に依存する可能性はそれほど怖くはありませんでしたが、私たちのプロジェクトは非常に大きいため、どこかで困難が始まる可能性があります（たとえば、2025）。
要約しましょう。コード化されたUIを使用すると、次のことが可能になります。

強力な有料IDE
テスト用にすでに作成されているすべてのインフラストラクチャ：IDEとCIの両方の側
同じIDEのC＃でテストを作成しているため、プロジェクトの開発者にサポートを依頼する機能
大量の高品質のドキュメント
クラスの自動生成された部分にコードを配置し、自動生成プロセス中にコードを失った数人の悲しいQAスペシャリスト
生成されたコードの種類が多く、厳密なレビューを受ける必要がある
CIへの非常に透過的なアプローチ：目を閉じてmstestを介してテストを起動するためのコードを記述できます
ゆっくりと死んでいく赤色巨星の自動化は、新しいテストから絶えず成長し、不可逆的に時代遅れのソフトウェアを備えた完全に隔離されたマシンに代表される衰退する白色矮星、またはプロジェクトが新しいアップデートのプレッシャー。

最後の点を除いて、すべてが良さそうだった。これが、検索を続行する必要がある理由です。

TestStack.White

コード化されたUIの機能を調査するのと並行して、ホワイトの助けを借りてプロトタイピングテストに取り組んでいました。
ホワイト自体は非常に有望に見えた「Microsoft.Automation」ライブラリのラップアラウンドであり、ホワイトもコード化されたものに似ていますUI。しかし、詳しく調べてみると、それははるかに厳格であり、レコーダーがなかったという事実から実際のテスト構造まで、どこにでも気付くことができました。たとえば、アプリを実行し、ウィンドウを検索して、[実行]ボタンを押すと、次のようになります。

var appPath = @"C:\Program files\UiAutomatedTestApplication\TestApplication.exe";
var app = TestStack.White.Application.Launch(appPath);

var windowSearchCriteria = SearchCriteria.ByAutomationId("MainForm");
var window = app.GetWindow(windowSearchCriteria, InitializeOption.NoCache);

var execute = window.GetElement(SearchCriteria.ByText("Execute"));
var invokePattern = (InvokePattern)execute.GetCurrentPattern(InvokePattern.Pattern);
invokePattern.Invoke();

app.WaitWhileBusy();

アプリケーションの実行に関して不満がない場合でも、InvokePatternクラスを操作する必要性は非常に疑わしいものです。 InitializeOptionクラスも、WithCache静的メンバーにアクセスできるため奇妙に見えますが、厳密に内部的に使用されることになっています：

public class InitializeOption {
//
// Summary:
//     This option should not be used as this is only for internal white purposes
public static InitializeOption WithCache { get; }
public static InitializeOption NoCache { get; }
public virtual bool Cached { get; }
public virtual string Identifier { get; }
public virtual bool NoIdentification { get; }

//
// Summary:
//     Specify the unique identification for your window. White remembers the location
//     of UIItems inside a window as you find them. Next time when items inside the
//     same window is found they are located first based on position which is faster.
//
// Parameters:
//   identifier:
public virtual InitializeOption AndIdentifiedBy(string identifier);
public virtual void NonCached();
public override string ToString();
}

このような奇妙な決定はいたるところにあり、フレームワークはQAには抽象的すぎることがわかります。

ドキュメントはまともな品質であり、良い一般的な印象を残しています。プロジェクトのソースコードはgithubでホストされていましたが、最新のコミットは2016年1月8日までさかのぼります。
Whiteに関する情報をまとめると、次のようになります。

まともなドキュメント
ソースコードへのアクセス
小さなコミュニティ
コントロールの動作がPatternクラスを介して実装されていることをすべてのQAスペシャリストに説明する必要性
間違いなくフォークする必要がある古いリポジトリ

最も不快な部分は、私たちが避けたい独自のフレームワークを開発する必要性でした。だから私たちは先に進まなければなりませんでした。

Appium

以前に検索でAppiumに遭遇しましたが、MicrosoftがCoded UIの使用をやめた後、真剣に検討し始めました。
一見すると、Appiumを使用したテストは3リールのスロットマシンのように見えます。 1つ目は、ドライバーとの対話を可能にするAPIが存在する言語を示しています。これにより、Python、C＃、Javaなどの使い慣れた言語でテストを作成できます。2番目のリールは、テストとテスト対象の製品の中間層として機能するドライバーアプリを示しています。ドキュメントで説明されているように、テストとのやり取りはJSONワイヤープロトコルを使用して実行されます。これにより、実際に任意の言語でテストを作成できるようになります。そして3番目のリールは、テストしているオブジェクトを示しています。対応するドライバーが実行されている限り、それがWebサイト、モバイルアプリ、デスクトップアプリのいずれであるかは問題ではありません。ご覧のとおり、コンポーネントはエレガントに交換可能です。
パッケージの関連性の見積もりは満足のいくものでした。Githubページでは、リポジトリに新しいコミットがあったことがわかりました。 WinAppDriverリポジトリを調べていると、そこにレコーダーさえあることがわかりました。
プロトタイプを作成しているときに、いくつかの問題に気づき始めました。たとえば、フレームワークが多目的であるため、デスクトップコントロールを担当するWindowsElementには、実行時に次の例外をスローするFindElementByCssSelectorメソッドがあります。「予期しないエラー。実装されていないコマンド：cssセレクターロケーター戦略はサポートされていません。次の記事では、このフレームワークを使用しているときに発生した問題について詳しく説明しますが、今のところ、すべてを処理できたと言えます。

要約すると、Appiumを使用する際の内容は次のとおりです。

1つのインフラストラクチャと1つのテストの範囲で、ブラウザとの対話（フィードバックページを開く、オンラインアクティベーション、電子メール配信の確認）を必要とするアプリケーション機能をテストする機能
VisualStudioの任意のエディションで動作する機能
ブラウザを使用してUIをレンダリングするデスクトップアプリケーションをテストする機能。この良い例は、AzureDataStudioです
コード化されたUIで得られるすべての利点
Microsoftが推奨する無料のフレームワーク
Seleniumを使用したQAスペシャリストに馴染みのあるインフラストラクチャ
新しいコミットで更新されたリポジトリ
まともな大規模なコミュニティですが、CodedUIのコミュニティほど大きくはありません
機能が制限されたレコーダー
テスト用のドライバーアプリケーションを実行する必要性。あまり便利ではありませんが、独自のロギング機能があります
WindowsElementのAppiumWebElementからの不幸な継承により、足を撃ち抜くための多くの機会

フレームワークの要件に関するすべてのポイントを検討し、それらの各フレームワークで見つかったすべての問題を比較して、最終的にAppiumを選択しました。

結論

これらのフレームワークのそれぞれが自動テストにアプローチするという独自の哲学に基づいていたため、これらすべてのフレームワークを操作することは興味深いことでした。それらの一部は、他の人が日食に到達している間、またはすでに消えてしまったときにのみ、進路を開始しました。ツールの特定の要件のリストを作成し、メンバー間の相互作用が確立された責任あるチームを持つことで、利用可能な多くのソリューションで迷子になるのを防ぐことができます。また、将来のテストは、バックログ、ボード、CI、リファクタリング、その他すべてを備えた、通常のコードと同じくらい多くのプロジェクトであることを忘れないでください。