這段時間一直在為公司內部開發自動化測試框架，簡稱GTF。這些程式碼都是公司的財產，不方便共享。當然了，如果公司願意，我倒願意開源了。

不說這些了，因為這個框架現在還屬於開發階段，很多事都是言之過早。最近幾個博文中，我會持續將我在架構過程中的想法寫下來。供自己和大家一起分享。

這些想法，並不屬於我一個人，我工作中的同事們給了我很大的幫助。

這一篇主要說明架構方面的考慮。

在現有的提供自動化測試解決方案的產品很多，包括：Robot，TestComplete，WinRunner等等。我只接觸過這些，公司裡也進行過很大的嘗試，但是結果往往總是不竟如人意。

這中間，排除那些人員方面的原因，也總結這些自動化工具，在使用過程中的不方便的地方：

1. 定位控制元件不方便。標準控制元件還好，非標準控制元件就只能靠很多非正常方法去獲取。而且，控制元件的識別往往和介面佈局相關。
2. 驗證資料不方便。這點更是針對非標準控制元件（什麼？你不用非標準控制元件？），資料的檢測，甚至誇張到使用圖片檢測。
3. 程式碼維護不方便。由於在編寫過程中，大量的和介面相關的程式碼，導致最後在需求變更的時候，程式碼的維護，成為測試人員的負擔。

針對這些情況，我們經過討論，何不自己做一個測試框架。當然了，這是基於我們的豐富的知識積累的決策。大家不需要關心這個決策的情況。不過，可以多關注一些我們在做的過程中的分析結果。

通過分析流行的測試框架，有多種方式：

第一、最典型的就是訊息驅動，自動化工具通過指令碼錄製和編寫，儲存為測試指令碼。在回放的過程中，將這些指令碼轉換成為Windows訊息，傳送給我們應用程式的窗體和各種控制元件。

這種方式的好處在於，自動化工具和應用程式之間能夠做到完全的隔離。但是，由於使用了Windows訊息，它也擁有了一個非常致命的缺點。那就是訊息佇列的非同步性與程式的順序性之間的矛盾。很多訊息傳送給了應用程式，但是應用程式的處理可能已經和訊息佇列錯位了。有一些關於程式碼的時間片等待，就是因為這個問題。

另外，就是由於完全的隔離，對於操縱控制元件資料的能力大大降低。畢竟，擁有大量資料的控制元件都不是標準控制元件。

第二、嵌入式。TestComplete就是這類工具。它有支援不同語言的版本。大概思路，就是在程式編譯的時候，注入自己的控制元件代理。指令碼的回放，直接可以通過代理，操縱到應用程式。

可惜的是，這類軟體開發的時候，更多的是考慮平臺的相容性。對於特有平臺上的支援不是十分完美。特別是對自定義控制元件（比如Delphi中，除了VCL的標準控制元件）支援也沒有做到最好。不過，我這裡必須承認，TC的內部實現機制可能十分強大，我不能窺探所有。如果有人清晰，可以指點一二。

針對上面的兩種，我們想到的第三種方式：一體式。這種方式中，通過給程式在打包的過程中，新增額外的框架程式碼，是的程式自動提供控制元件的訪問方式。自動化的模組也會作為測試程式的一部分執行。

應用程式在執行指令碼的時候，自動通過指令碼，控制各控制元件介面的顯示和關閉。它應該是第二種方式的變種。但是由於是自己實現的，所以在對各類自定義控制元件支援的都非常好。

針對一開始提出的幾個自動化測試的難題，我們提出了，自動封裝窗體上所有控制元件的概念（這些概念後面會詳細介紹），對於測試人員，只要關心真正的業務操作流程。而業務流程中涉及到的控制元件，已經為他們自動提供好。這樣，指令碼也自然只成了業務流程的指令碼。其複雜度也就大大降下來了。

按照這個思路，最主要的是可以充分發揮“程式是我們自己的”的優勢，對於測試人員，開發人員是他們的最好的訪問控制元件的工具。有什麼控制元件找不到，開發人員可以快速地給他們適配一個訪問方式。這也大大降低了測試人員對軟體系統內部的瞭解程度。

因此，自定義的測試框架，最大的優勢來源於其無限的擴充能力，以及簡潔的封裝介面。相信這個框架一定能給我們自動化測試方面帶來很多優勢。