-1

Windows システムをシャットダウンするコードの簡単なテスト スイートを開発しようとしています。要件は、システムが電源をオフにする前にシャットダウン コールを実際に受信したかどうか (この結果をさらにテスト スイートに渡すため) と、正確なシャットダウン開始時間をプログラムで判断することです。

これまでのところ、いくつかの異なるアプローチを試しましたが、どれも満足のいくものではないようです:

1) WM_QueryEndSession 呼び出しの監視とキャッチ

欠点: 基本的に、この呼び出しは、実行中のアプリや対話型のユーザーにシステムのシャットダウンを通知するためによく使用されます。ただし、この呼び出しは、応答しないアプリまたはサービスでは機能しない可能性があります。または、呼び出しが正しいステータスで終了した場合でも、応答しないサービスが終了し、アプリがシステムによって閉じられるまで、実際のシャットダウンが遅れる場合があります。

2) Windows イベント ログ Windows イベント ログを読み取るプログラムを開発できます。プログラムがイベント ログをスキャンし、関連するメッセージがログに記録されているかどうかを確認するには、しばらく時間がかかります。しかし、それには時間がかかるようで、システムがイベント ログ サービスの閉鎖とさらなるシャットダウンを開始する前に完了しない可能性があります。さらに、システムのシャットダウン中にプログラムを実行することは信頼できないようです。

3) 単純にコンピューターに ping を実行して、ネットワーク アダプターがネットワークから切断されていることを確認します。これは、シャットダウン プロセスで実行される最初のアクションではなく、応答しないプロセスやその他の理由によって大幅に遅れる可能性があります。

システムの電源がオフになる前に、システムへのシャットダウン コールをキャッチする信頼できる方法はありますか?

4

1 に答える 1

0

正直なところ、私の脳はNOと叫んでいます。全体のアイデアに欠陥があるようです。まったく別の問題の症状に対処しようとする必死の試みのように思えます。さらに、特定の境界を超えてテストすることは、一般的には賢明ではありません。それには正当な理由があります。それは、努力する価値がないほど物事を複雑にしすぎるからです。たとえば、シャットダウンをテストしているこの状況では:

  • 本当にテストでシャットダウンしますか?
  • 今すぐシャットダウンしたくない他のアプリケーションはどうですか?
  • 実際にシャットダウンすると、シャットダウンをテストしているアプリは、システムの残りの部分と共にダウンします。
  • シャットダウン後、自動的に再起動しますか?
  • シャットダウン オプションを使用して自動的に再起動する場合、これは運用シナリオと同じになりますか?
  • より現実的なテストのためにリモート再起動を実行するには、適切な電源オフと Wake-on-LAN が必要ではないでしょうか?
  • あるいは、実際にシャットダウンせずにシャットダウン コマンドをテストしたいですか?
    • 問題は、シャットダウン コマンドを (正常に) 送信するとすぐに、Windows がシャットダウンを開始することです。
    • シャットダウンを中止することもできますが、その時点までに他のアプリケーションが要求に応じて閉じられている可能性があります (あまりフレンドリーな動作ではありません)。

これは、通常、問題のある境界へのインターフェイスをモックする方が適切な状況です。次に、モックとの相互作用が正しいことをテストするだけです。

そうは言っても、あなたが別の問題の症状に対処しようとしているのではないかと心配しています.

あなたは言った:「一部のWindows展開に矛盾がありました(ただし、すべてではありません)」。
不一致の根本原因を特定しましたか? シャットダウン コマンドを自動的に発行することになっているアプリケーションがある場合、失敗する可能性があるいくつかの理由があります。

  • アプリケーションが実行されていない可能性があります。
  • 必要な呼び出しを行うことができないバグがある可能性があります。
  • 呼び出しを行った可能性がありますが、Windows が拒否した可能性があります ( API 呼び出しの戻り値を確認していることを願っていますか? ) 何らかの理由 (許可、リモート セッション、OS が他の何かの最中 - 誰が知っていますか?)。
  • これで、呼び出しが成功の結果を返した場合でも、シャットダウンを停止できます。(ところで、あなたは開始時刻を知る必要があると言いました。これがそれです!これはシャットダウンが開始されたときです。レジストリ内のファイルに現在の時刻を書き込みます。好きなようにします。
  • 上記のすべてを考慮しても、どのアプリケーションでもシャットダウン プロセスを中止できます。そのため、システムをシャットダウンするコードが徹底的にテストされ、完全に動作したとしても、まったく無関係な別のアプリが向きを変えて、「シャットダウンしなくていいぞ!」と言うことがあります。- そして、システムは実行を続けます....

「別の問題の症状」に戻ります...あなたが言ったことのいくつか(イベントログの確認、時間の心配、「シャットダウンコールがシステムに発行されたかどうかをキャッチする」など)は、あなたがしようとしていることを示唆しています「シャットダウンコマンドが発行された」ことを事後的に調べますか?

これはテストの問題ではなく、ロギングの問題のようです。

おそらく、この非常に重要なロギングが正しく行われていることをテストしたいですか?
そして、これは私を真っ直ぐに戻します:むしろ Windows API 呼び出しをモックし、文書化された API とのやり取りが正しいことをテストします

狂気の神々を罵倒するのを思いとどまらせなければ...

応答していないアプリ/サービスのWM_QueryEndSessionを監視することの欠点について言及しました。ただし、他のアプリはあまり気にしません。必要なアプリは 1 つだけです。必要に応じて、小さなシンプルなスタンドアロンの監視ユーティリティ。メッセージを受け取ったら、理由とともにログに記録します。(もちろん、シャットダウンが完了するという保証はまだありません。)

さらに一歩進んで、監視アプリはSetProcessShutdownParameters関数を使用して、シャットダウンを通知される最初のプロセスの 1 つにすることができます。もちろん、シャットダウンが中止された場合、監視ユーティリティは実行されなくなり、再起動する必要があります。(私は狂気と狂気について言及しましたか?
または、最後のシャットダウンの1つに設定して、実際のシャットダウンに近い時間に何らかのアクションを実行できるようにします(実際にシャットダウンする場合)。

イベント ログの読み取りに関する懸念は、システムのシャットダウン中に終了するには遅すぎる可能性があるためです。シャットダウン中にそれを読みたいと思うのはなぜですか?(または、狂気はすでに定着していますか? ) ディスクが何もせずに停止している間、データが流出することはほとんどありません。必要に応じて再起動時に読んでください。ただし、最初にShutdown Event Trackerについて読んでください。

最後に、 WM_QueryEndSession をリッスンする代わりに (またはそれに加えて)、WM_EndSessionをリッスンします。前者が送信されない状況がいくつかあります。しかし、私が知る限り、後者は常に送信する必要があります。

私は狂気に言及しましたか?……狂気だったのかも。...ルーニービンについて言及したことは知っています。... 何 誰 なぜ いつ どのように?…頭の中にいる!
狂気は終わります。

于 2013-09-08T23:39:14.680 に答える