自動化測試框架：自己的框架

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

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

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

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

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

        定位控件不方便。標準控件還好，非標準控件就只能靠很多非正常方法去獲取。而且，控件的識別往往和界面布局相關。
        驗證數據不方便。這點更是針對非標準控件（什么？你不用非標準控件？），數據的檢測，甚至夸張到使用圖片檢測。
        代碼維護不方便。由于在編寫過程中，大量的和界面相關的代碼，導致最后在需求變更的時候，代碼的維護，成為測試人員的負擔。
        針對這些情況，我們經過討論，何不自己做一個測試框架。當然了，這是基于我們的豐富的知識積累的決策。大家不需要關心這個決策的情況。不過，可以多關注一些我們在做的過程中的分析結果。

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

        第一、最典型的就是消息驅動，自動化工具通過腳本錄制和編寫，保存為測試腳本。在回放的過程中，將這些腳本轉換成為Windows消息，發送給我們應用程序的窗體和各種控件。

原文轉自：http://www.kjueaiud.com