高速で安価なものが必要な場合のWindowsでのインストーラーのテスト

Webテスターの皆さん、セレンを飲んでも間違いはありません。 幸せなJavaテスター-彼らにとっては、特に厳しいケースではテストフレームワークがあります-siculi。 彼らはテストにコンソールアプリケーションをもたらしました-ここではpython、perlは快適です。 しかし、デスクトップはどうですか？ 特に、Windowsでのブラックボックスアプリケーションのテスト-インストーラー（msiパッケージなど）は、自動化が次のセクションで強調したのと同じレーキに遭遇するたびに、オートイットキャンプに導かれました。

自動テストインストーラーに必要なもの：

1. 必要に応じて、ロシア語版と英語版のインターフェイスで、ソースを編集せずにクリックします。 これを行うにはさまざまな方法がありますが、私はAutoitの方法がより好きでした-オブジェクトインスタンスの名前を知っていれば、クリックに関するメッセージを送信できます。唯一のマイナスは、ロシア語と英語の両方で、ボタンが配置されているウィンドウの名前を知ることです。
2. 同じコードの束の中に急上昇しないでください。たとえば、ウィンドウ1、2、3を押してボタン2またはボタン3を押す必要がある場合、ウィンドウ1、2、3のボタンを組み合わせて一種の抽象化「ボタン2へのパスと3」、必要に応じて呼び出します
3. 閉塞に関する報告、ドックは一般的に、彼がしたことを何とか食した。 ボタンを押す前にスクリーンショットを撮ることもありますか？
   非表示のテキスト

   どういうわけか実装します
4. すべてが完了したら結果を報告し、ボタンが押されたことではなく、すべてのアクションが実際に完了したことをテストします。 インストーラーの場合-ファイルが表示されたかどうか、サービスがアクティブかどうか、インターフェースが起動するかどうか。
5. 新しいexeを再コンパイルして分散させたくありません。 失敗したマシンで失敗した自動テストを直接編集したいのですが、自動テストの書き込み環境は環境に変更を加えるべきではありません-JAVA、.netなど 何百ものケース-私のテストは強打で合格しましたが、クライアントはそうではありません-ある種の.netを添付するのを忘れていました。 基本的に、この理由で、siculiを使用するオプションが落ちました。javaをロールバックして、それなしではすべてが機能しなかったことを確認することは非常に不利です。
6. 苦労と絶望に満ちた普通の世界のテスターは、tfsのマーケティングのスムーズなビデオに示されているものではなく、それが非常に幸運な場合-あなたとテスト計画に注意深く従う女の子（私は不運で、女の子は不在です）。 彼女はpython、cpanの何千もの機能を必要としません。 ルーチンを削除する必要があります。 腐敗しやすい現実の別のボーナスは、ハーフレートの学生のためのテスターです。クールですが、学生がperl、pythonを習得するとすぐに、彼はコーダーに逃げ出し、彼が与えられたテストタスクを完了することができれば非常に幸運です。 そこで、テスト中に最小限のプログラミングの機会を思いつきました。
7. 実行パスはすべてのオペレーティングシステムで同じではありません。どこかでuacウィンドウが表示されます。どこかで表示されないため、毎回実行する必要はありません。 テストパスを実行するときは、分岐する方法が必要です。

すべてをリストに減らして、私は次のアイデアに思いつきました-ini-filesとreportsの設定を持つウィンドウのために私自身のクリッカーが必要です。
わかりました、世代の経験を考慮しましょう、私たちはunix-wayを使用します：タスクを2つの部分-クリッカーとレポートジェネレーターに分割します。
クリッカーはオブジェクトをクリックします-最も単純な、できれば自己文書化されたテキストファイルで指定されたボタンは、キーボードからのキーストロークを模倣します。

レポートシェーパーは個別のエントリであり、特定のケースごとに記述され、必要に応じてサービスの確認、適切な場所でのファイルの作成、dirコマンドの出力と標準の比較などを行うことができます。 ほとんどの場合、新しい機能を常にチェックする必要があり、自分で監視する必要があることを経験が示しているため、それも必要ありません。

クリッカーの設定例：一意のテスト実行パスを含むway.iniファイル：

実際に、インストーラーで何ができるかを説明した後、別のiniファイルtestway1.iniに記述してテストパスを収集します。

Kanselボタンを確認する必要がある場合は、別のiniファイルtestway2.iniを作成します

countOps-way.iniから一度に読み取られる設定の数-現在、そのうちの7つがあります：LogMessage、WindowsNameEnglish、WindowsTextEnglish、Element、WindowsNameRussian、WindowsTextRussian、SendKeyText。 sLogPath-メッセージのファイル名、LogMessage。 残りはおそらく名前から明らかです。 要素プロパティは、プログラムAu3Info.exeを使用して決定する必要があります

そのようなiniファイル、clickAndType.au3で動作できるサンプルコード：

起動用のファームウェアにはパラメーターが必要です-設定を受け取るファイルの名前（たとえば、wayway.iniファイルから何を実行するかを示すtestway2.ini）。

では、このすべての経済でポイント7からの分岐を達成するにはどうすればよいでしょうか？ すべてが非常に簡単です。テストを実行すると、トレイでハングし、指定されたウィンドウが表示されるまで待機します。何も起こりませんでした。
おそらく、2回目の実行については説明しません。レポートコンパイラ、すべてが非常に個性的です。

OK、それは私のためにクリックできます、次は何ですか、ブレイン？ 自分の手で自動テストを起動するという悪質な慣行を取り除く必要があります。特別な仮想マシンを準備し、自動実行のrunme.bat形式のバッチファイルを含むBeforeInstallXXXのスナップショットを作成することをお勧めします。

テスト済みのインストーラーをファイルボールに配置し、仮想マシンを再起動するだけです。 運がよければ、ファイルボールに自動テストを配置することもできます。すべての変更が集中化され、testway.ini、ways.ini構成ファイルを各仮想マシンにコピーすることで時間を節約できます。

リクエストが増えるにつれて、おそらくrunme.bat機能を複雑にする必要があるという結論に達するでしょう。私の知る限り、3番目のプログラムがすぐに実装されます。runme.batを置き換えるランナーであり、明らかに、どちらに依存することができます開始オプションclickAndType.exeを選択する条件

上記のすべてがすでに1000人の人々によって1000回発明された自転車であるという事実に10点中9点を付けました。実際、すべては致命的な欠陥を持っているという事実に帰着します-多くの場合、モンスターは最大限の汎用性を発揮しましたが、私は主要な顧客およびユーザーとして、ツールのシンプルさに興味があり、そのように実装しました。 同時に、単純なグーグルでWindowsのインストーラーをテストすることに関する情報を見つけることができなかったと言うでしょう。 今彼女はここにいます。