不說這些了，因為這個框架現在還屬于開發階段，很多事都是言之過早。最近幾個博文中，我會持續將我在架構過程中的想法寫下來。供自己和大家一起分享。
這些想法，并不屬于我一個人，我工作中的同事們給了我很大的幫助。
這一篇主要說明架構方面的考慮。
在現有的提供自動化測試解決方案的產品很多，包括:Robot，TestComplete，WinRunner等等。我只接觸過這些，公司里也進行過很大的嘗試，但是結果往往總是不竟如人意。
這中間，排除那些人員方面的原因，也總結這些自動化工具，在使用過程中的不方便的地方:
1. 定位控件不方便。標準控件還好，非標準控件就只能靠很多非正常方法去獲取。而且，控件的識別往往和界面布局相關。
2. 驗證數據不方便。這點更是針對非標準控件(什么?你不用非標準控件?)，數據的檢測，甚至夸張到使用圖片檢測。
3. 代碼維護不方便。由于在編寫過程中，大量的和界面相關的代碼，導致最后在需求變更的時候，代碼的維護，成為軟件測試人員的負擔。
針對這些情況，我們經過討論，何不自己做一個軟件測試框架。當然了，這是基于我們的豐富的知識積累的決策。大家不需要關心這個決策的情況。不過，可以多關注一些我們在做的過程中的分析結果。
通過分析流行的軟件測試框架，有多種方式:
第一、最典型的就是消息驅動，自動化工具通過腳本錄制和編寫，保存為測試腳本。在回放的過程中，將這些腳本轉換成為Windows消息，發送給我們應用程序的窗體和各種控件。
這種方式的好處在于，自動化工具和應用程序之間能夠做到完全的隔離。但是，由于使用了Windows消息，它也擁有了一個非常致命的缺點。那就是消息隊列的異步性與程序的順序性之間的矛盾。很多消息發送給了應用程序，但是應用程序的處理可能已經和消息隊列錯位了。有一些關于代碼的時間片等待，就是因為這個問題。
另外，就是由于完全的隔離，對于操縱控件數據的能力大大降低。畢竟，擁有大量數據的控件都不是標準控件。
第二、嵌入式。TestComplete就是這類工具。它有支持不同語言的版本。大概思路，就是在程序編譯的時候，注入自己的控件代理。腳本的回放，直接可以通過代理，操縱到應用程序。
可惜的是，這類軟件開發的時候，更多的是考慮平臺的兼容性。對于特有平臺上的支持不是十分完美。特別是對自定義控件(比如Delphi中，除了VCL的標準控件)支持也沒有做到最好。不過，我這里必須承認，TC的內部實現機制可能十分強大，我不能窺探所有。如果有人清晰，可以指點一二。
針對上面的兩種，我們想到的第三種方式:一體式。這種方式中，通過給程序在打包的過程中，添加額外的框架代碼，使得程序自動提供控件的訪問方式。自動化的模塊也會作為軟件測試程序的一部分運行。
應用程序在執行腳本的時候，自動通過腳本，控制各控件界面的顯示和關閉。它應該是第二種方式的變種。但是由于是自己實現的，所以在對各類自定義控件支持的都非常好。
針對一開始提出的幾個自動化測試的難題，我們提出了，自動封裝窗體上所有控件的概念(這些概念后面會詳細介紹)，對于軟件測試人員，只要關心真正的業務操作流程。而業務流程中涉及到的控件，已經為他們自動提供好。這樣，腳本也自然只成了業務流程的腳本。其復雜度也就大大降下來了。
按照這個思路，最主要的是可以充分發揮“程序是我們自己的”的優勢，對于測試人員，開發人員是他們的最好的訪問控件的工具。有什么控件找不到，開發人員可以快速地給他們適配一個訪問方式。這也大大降低了軟件測試人員對軟件系統內部的了解程度。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
