自動化測試框架之控制界面的關鍵

　　要做一體化自動化測試框架，那么，最重要的是要解決什么呢?相信了解windows編程的人員，都能發現這個問題所在。在窗體中，寫下代碼，控制每一個控件的輸入是非常簡單的事。但是，一旦顯示了一個模態窗體，原有的流程代碼會不再往下執行，而是停留在新窗體中，等待消息相應。這就是我們代碼控制界面的關鍵問題。

　　前面講到要做一體化自動化測試框架，那么，最重要的是要解決什么呢?

　　相信了解windows編程的人員，都能發現這個問題所在。在窗體中，寫下代碼，控制每一個控件的輸入是非常簡單的事。但是，一旦顯示了一個模態窗體，原有的流程代碼會不再往下執行，而是停留在新窗體中，等待消息相應。這就是我們代碼控制界面的關鍵問題。

　　這是什么道理呢?

　　我使用的是delphi系統，所以我可能使用vcl框架來解釋這個問題。但是其他語言同樣適用。

　　在windows程序中，winmain是入口。而winmain的處理，就是一個典型的死循環，先從消息隊列中取出消息，然后再給各窗體派發消息。

　　為了方便理解，我們將這個模型簡化，就是一個死循環a。中間在處理任意的代碼。

　　現在，由于調用了某一段處理，進入了另外一個死循環b。當代碼從a函數進入了b，那么當然，a循環下面的代碼當然只能停留下來，直到b循環結束。

　　而在windows界面中，模態窗體就是一個消息死循環。當windows彈出一個模態窗體的時候，其消息隊列獨立處理，不再走整個應用程序的消息循環。

　　現在比較明白了，不能方便控制界面的原因在于windows應用程序并不是流程化的，而是消息驅動的。

　　明白了這個道理，就有可能找到突破口。我想到了鉤子。在delphi中使用鉤子，推薦使用fastcode。

　　既然程序從a循環進入到b循環，我不能繼續執行a循環的代碼，那么，可不可以在進入b循環后，繼續執行a的代碼呢?

　　這應該是可行的。關鍵在于我必須做到b循環中，能夠調用到我的代碼。

原文轉自：http://www.anti-gravitydesign.com