自動化測試框架:與FinaIBUIder

　當自動化測試的腳本編輯器完成之后，根據使用者反饋，編輯器確實大大提高了工作效率，并且代碼的管理確實變得有效而可控。而且現在此項目已經開始向另一個管理類軟件系統嘗試應用?？梢灶A計，會有一些新的功能加入。 
　　不過，我們回過頭來思考最開始的一個問題——自動化的問題。這是我們最終的目的。雖然說自動化測試框架能夠解決軟件本身的執行問題，但是一次完整的測試，必然是要覆蓋全過程的。很顯然，我們的框架不能解決這個問題。 
　　因為我做過很多項目的每日版本構造，對FinalBuilder比較熟悉，同時也意識到FinalBuilder可以彌補我們框架在這方面的缺陷。很自然地，我將這個軟件引入到我們整個系統中來。 
　　這個軟件在業界是非常有名的，很多人都很熟悉其用法。不過原來都是開發人員在使用，測試人員不是很熟悉。所以有必要對參與自動化測試的測試人員進行簡單的培訓。 
　　考慮到這篇文章的部分讀者也是測試人員，所以我在這里也簡單的介紹一下FinalBuilder。 
　　FinalBuilder解決的是任務流的問題。就像我們以前的D0s系統的大部分程序一樣，沒有界面交互部分，一次輸入，直接返回最終處理結果。這點和我們的自動化目標不謀而合。 
　　在FinalBuilder中，最本質的就是一個任務的執行。任務的執行包括兩部分：執行環境加上執行數據。 
　　執行環境往往包括Windows系統自帶的一些程序，包括Copy、XCopy等Shell命令，也有系統中已經安裝的程序，如Delphi、VC、SVN等。而執行數據，則是指我們的輸入。由于我們要實現在執行中不存在界面交互，那么就必然要求我們將所有需要交互的信息一次性地輸入。與此同時，我們的環境程序，也必須同時支持此種模式(一般情況下，這種模式稱為命令行模式)。 
　　對于使用FinalBuilder人來講，就有必要了解相關程序的命令行調用方式。這樣有助于我們使用和編寫任務。如果是我們自己研發一個程序，那么因為要使用到FinalBuilder中來，也有必要支持命令行模式。 
　　在FinalBuilder中，最主要的還是順序流程，當然它也支持條件、分支、循環。最新的版本還有多線程協同，不過在使用初期，主要還是以順序流程為主。 
　　最關鍵、最基礎的就是Run DoSCommand和Execute Programe兩個任務了。有了這兩個，幾乎可以完成任何事情。當然，FinalBuilder還提供了很多現成的控件，使得你可以通過配置(而不是命令行)來編寫任務，這大大降低了使用難度。不過，不可避免的會有一些需求需要我們自己編寫命令行，因此這兩個任務必須掌握。 
　　FinalBuilder的自動執行，是使用Windows的計劃任務來完成的。在其菜單中有生成計劃任務的功能。順便說一句，FinalBuilder本身也一樣支持命令行模式，因此多個FinalBuilder之間，可以互相調用。這對我們的自動化非常有利。 
　　在經過簡單的介紹后，我們發現，使用FinalBuilder確實可以幫助我們解決問題。 
　　那么，我們需要解決哪些問題呢？下面是我按照順序列出的一份清單： 
　　◆卸載已經安裝的目標軟件； 
　　◆刪除所有目標軟件的相關目錄，保障干凈環境； 
　　◆從服務器獲取并復制目標軟件的安裝程序； 
　　◆從源代碼服務器獲取自動化測試腳本和框架程序； 
　　◆安裝目標軟件； 
　　◆安裝自動化測試框架， 
　　◆執行目標軟件； 
　　◆執行與目標軟件配套的自動化測試腳本，如：冒煙測試； 
　　◆生成自動化執行日志，分析結果； 
　　◆發送郵件通知自動化負責人。 
　　所有需要完成的功能，其實上面這些都已經做好了。因為我們通過手工確實可以走到最后。但是要做到覆蓋全過程的自動化的想法，還需要各個工具軟件互相協調。 
　　首先是軟件的安裝和卸載，這需要軟件能提供命令行模式的安裝運行(安裝和卸載都是需要人工交互的)，由于我們自身的安裝程序支持這個模式，自然省去了很多麻煩。對于網絡上流行的免費的和收費的安裝軟件，也都是支持安全模式的，這些只要多查查資料就可以了。 
　　復制文件就簡單多了，FinalBuilder和Windows都已經提供了很多命令。 
　　關于工作流程的自動化執行，那就是我們的自動化測試框架。針對這個需求，我花費了很多工夫才加進去。主要是程序的協同性問題。必須等到目標軟件的主窗體完全啟動完畢。另外，需要對中途的意外退出做出嚴格的防范，保障自動化測試能夠有始有終。這里面增加了一個超時的概念，可以保障最后程序的退出。 
　　分析日志更是重要。事實上，沒有日志的自動化測試沒有人愿意去做。目前還是先根據一些簡單的需求，做了一些統計，相信以后還會增加的功能是版本日志對比，這樣可以看到系統的穩定性變化趨勢。 
　　而自動化最重要的就是完成從電腦到人的連接。將報表按照分類發送到相關人員信箱中，他們就可以繼續根據測試結果進行處理。 
　　說到底，FinalBuilder就是幫助我們解決了工作流的問題。將自動化測試的流程固化在腳本中。最關鍵的是，這個流程的管理，我們可以使用現成的方案，而不需要再去自己造一個新的輪子。這樣符合我們系統架構的基本原則。 
　　當然，FinalBuilder不是唯一的選擇。事實上有很多開源軟件也都可以完成這樣的功能，最簡單的就是直接使用批處理BAT文件。同時，專業的軟件，可以提供更多的調試和輔助功能。
　　OK!我們的自動化測試框架，在使用FinalBuilder之后，已經初步將一個完整的自動化測試過程構建起來。正如博文的一位讀者所說的，下面要重點關注腳本的方案設計了。 
　　當自動化測試的腳本編輯器完成之后，根據使用者反饋，編輯器確實大大提高了工作效率，并且代碼的管理確實變得有效而可控。而且現在此項目已經開始向另一個管理類軟件系統嘗試應用?？梢灶A計，會有一些新的功能加入。

不過，我們回過頭來思考最開始的一個問題——自動化的問題。這是我們最終的目的。雖然說自動化測試框架能夠解決軟件本身的執行問題，但是一次完整的測試，必然是要覆蓋全過程的。很顯然，我們的框架不能解決這個問題。 
　　因為我做過很多項目的每日版本構造，對FinalBuilder比較熟悉，同時也意識到FinalBuilder可以彌補我們框架在這方面的缺陷。很自然地，我將這個軟件引入到我們整個系統中來。 
　　這個軟件在業界是非常有名的，很多人都很熟悉其用法。不過原來都是開發人員在使用，測試人員不是很熟悉。所以有必要對參與自動化測試的測試人員進行簡單的培訓。 
　　考慮到這篇文章的部分讀者也是測試人員，所以我在這里也簡單的介紹一下FinalBuilder。 
　　FinalBuilder解決的是任務流的問題。就像我們以前的D0s系統的大部分程序一樣，沒有界面交互部分，一次輸入，直接返回最終處理結果。這點和我們的自動化目標不謀而合。 
　　在FinalBuilder中，最本質的就是一個任務的執行。任務的執行包括兩部分：執行環境加上執行數據。 
　　執行環境往往包括Windows系統自帶的一些程序，包括Copy、XCopy等Shell命令，也有系統中已經安裝的程序，如Delphi、VC、SVN等。而執行數據，則是指我們的輸入。由于我們要實現在執行中不存在界面交互，那么就必然要求我們將所有需要交互的信息一次性地輸入。與此同時，我們的環境程序，也必須同時支持此種模式(一般情況下，這種模式稱為命令行模式)。 
　　對于使用FinalBuilder人來講，就有必要了解相關程序的命令行調用方式。這樣有助于我們使用和編寫任務。如果是我們自己研發一個程序，那么因為要使用到FinalBuilder中來，也有必要支持命令行模式。 
　　在FinalBuilder中，最主要的還是順序流程，當然它也支持條件、分支、循環。最新的版本還有多線程協同，不過在使用初期，主要還是以順序流程為主。 
　　最關鍵、最基礎的就是Run DoSCommand和Execute Programe兩個任務了。有了這兩個，幾乎可以完成任何事情。當然，FinalBuilder還提供了很多現成的控件，使得你可以通過配置(而不是命令行)來編寫任務，這大大降低了使用難度。不過，不可避免的會有一些需求需要我們自己編寫命令行，因此這兩個任務必須掌握。 
　　FinalBuilder的自動執行，是使用Windows的計劃任務來完成的。在其菜單中有生成計劃任務的功能。順便說一句，FinalBuilder本身也一樣支持命令行模式，因此多個FinalBuilder之間，可以互相調用。這對我們的自動化非常有利。 
　　在經過簡單的介紹后，我們發現，使用FinalBuilder確實可以幫助我們解決問題。 

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