這種方式的好處在于，自動化工具和應用程序之間能夠做到完全的隔離。但是，由于使用了Windows消息，它也擁有了一個非常致命的缺點。那就是消息隊列的異步性與程序的順序性之間的矛盾。很多消息發送給了應用程序，但是應用程序的處理可能已經和消息隊列錯位了。有一些關于代碼的時間片等待，就是因為這個問題。
另外，就是由于完全的隔離，對于操縱控件數據的能力大大降低。畢竟，擁有大量數據的控件都不是標準控件。
第二、嵌入式。TestComplete就是這類工具。它有支持不同語言的版本。大概思路，就是在程序編譯的時候，注入自己的控件代理。腳本的回放，直接可以通過代理，操縱到應用程序。
可惜的是，這類軟件開發的時候，更多的是考慮平臺的兼容性。對于特有平臺上的支持不是十分完美。特別是對自定義控件（比如Delphi中，除了VCL的標準控件）支持也沒有做到最好。不過，我這里必須承認，TC的內部實現機制可能十分強大，我不能窺探所有。如果有人清晰，可以指點一二。
針對上面的兩種，我們想到的第三種方式：一體式。這種方式中，通過給程序在打包的過程中，添加額外的框架代碼，是的程序自動提供控件的訪問方式。自動化的模塊也會作為測試程序的一部分運行。
應用程序在執行腳本的時候，自動通過腳本，控制各控件界面的顯示和關閉。它應該是第二種方式的變種。但是由于是自己實現的，所以在對各類自定義控件支持的都非常好。
針對一開始提出的幾個自動化測試的難題，我們提出了，自動封裝窗體上所有控件的概念（這些概念后面會詳細介紹），對于測試人員，只要關心真正的業務操作流程。而業務流程中涉及到的控件，已經為他們自動提供好。這樣，腳本也自然只成了業務流程的腳本。其復雜度也就大大降下來了。
按照這個思路，最主要的是可以充分發揮“程序是我們自己的”的優勢，對于測試人員，開發人員是他們的最好的訪問控件的工具。有什么控件找不到，開發人員可以快速地給他們適配一個訪問方式。這也大大降低了測試人員對軟件系統內部的了解程度。
因此，自定義的測試框架，最大的優勢來源于其無限的擴充能力，以及簡潔的封裝界面。相信這個框架一定能給我們自動化測試方面帶來很多優勢。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
