私たちが満足するツールを選択したと仮定します（そして、ここで私は前回の記事からのものだけでなく、TFSなどの健全なツールも意味します）、彼は私たちのために仕事の一部をしました。 製品のインストールを自動化することができましたが、すでに幸福のように思えました-ここで、手を貸してください...インストールの最後の段階で、システムの再起動を生き残る必要があることがわかります。 そして、おそらく後で、制限付きアカウント\ドメイン\その他のアカウントで起動します。 製品がmsgina.dllを変更するほど運が悪い場合、...はい、はい、winlogonに入り、アカウントのログインを自動化する必要があるということです。
それは思われる-何が私たちを止めることができますか？ 再起動後に開始されるサービスを作成します。これにより、必要な自動テストでプロセスが復活し、ファイルからすでに読み取られます。このユーザーの下で、起動してすべての作業を実行します。
既往歴
計画どおり、サービスを作成し、コマンドを実行できることを確認しました
ping localhost > c:\outping.txt
再起動直後、システムに入る前。 pingを自動テストに置き換えましたが、 何も機能しませんでした 。 最初のログインの前に開始できるサービスは、localsystemシステムアカウントに代わって開始され、 対話型にすることはできません。 これは、自動テストの実行時に、画面に表示されるウィンドウ、いわゆるデスクトップを記述するシステムオブジェクトを受信しなかったことを意味します。 一番下の行は、Windowsシステムには、ウィンドウを表示できる3つの領域があります-デフォルト（ログイン/パスワードの入力後に読み込まれる）、winlogon（使い慣れた認証要求を表示する）、および非対話型サービスの非表示領域です。
フレーズはとても合理化されています
これらの領域間の切り替えは、winapi 関数SetThreadDesktopを呼び出すことで実行できます。
エンコーダーは「OK」と考えました。「必要なのは、1つのwinapi関数を呼び出し、自動テストを開始し、静的リンクでコンパイルして、テスターが依存関係に悩まされないようにするだけです。
-OK、-テスターは考えました-全体として、今ではすべてのシステムでプログラムをチェックしてプログラムを実行する必要があります。
テストツールのテストに失敗することはできません。 しかし、私はこの道をたどりませんでした-最近、自転車の発明を脅かすWindowsの動作のあいまいなものに出会ったとき、姓Russinovichから始めて、Googleにクエリを作成することに頼り始めました。 今はうまくいった。 PSexecがお手伝いします。
レシピ
- srvAnyをダウンロードして、テスト環境にインストールします
- srvAnyプログラムのApplicationパラメーターで、
"\\\\_psexec\\PSexec.exe /x /s /d /accepteula cmd.exe"
という行を指定します。
/ xオプション自体は、winlogon環境での起動を提供します - 再起動し、認証の招待状を待ちます。すべてが正しく行われると、cmdコンソールがバックグラウンドで表示されます（Windows 7では表示されない場合がありますが、Alt + Tabキーを押して切り替えることができます）。 cmdを自動テストに置き換えます（tfsの場合、いくつかのパラメーターを指定してテストエージェントを実行する必要があります）。ログインパスワードを入力して、新しいmsginaの動作を確認します。 できた