2023年09月10日 22:26:00
當自動化測試的指令碼編輯器完成之後，根據使用者反饋，這樣確實大大提高了工作效率。並且**的管理確實變得有效和可控。現在此專案已經開始向另乙個管理系統嘗試應用。可以預計，會有一些新的功能加入。
不過，我們回過頭來思考乙個問題--自動化的問題。這是我們最終的目的。雖然說自動化測試框架能夠解決軟體本身的執行問題，但是一次完整的測試，必然是要覆蓋全過程的。很顯然，我們的框架不能解決這個問題。
我做過很多專案的每日版本構造，所以對finalbuilder比較熟悉。我也同時意識到finalbuilder可以彌補我們框架在這方面的缺陷。很自然的，我將這個軟體引入到我們系統中來。
這個軟體在業界是非常有名的，很多人都很熟悉其用法。不過原來都是開發人員在做，測試人員不是很熟悉。所以我在最近對參與自動化測試的幾位測試人員，做了簡單的培訓。考慮到這篇文章的部分讀者也是測試人員，所以我在這裡也簡單的介紹一下finalbuilder。如果你使用過finalbuilder，可以跳過下面這段文字。
finalbuilder解決的是任務流的問題。就像我們以前的dos系統的大部分程式一樣，沒有介面互動部分，一次輸入，直接返回最終處理結果。這點和我們的自動化目標不謀而合。
在finalbuilder中，最本質的就是一次任務的執行。任務的執行包括兩部分：執行環境+執行資料。執行環境往往包括windows系統自帶的一些程式，包括copy，xcopy等等shell命令。也有系統中已經安裝的程式，如delphi、vc、svn等等。而執行資料，則是指我們的輸入了！由於我們要達到在執行中不存在介面互動，那麼就必然要求我們將所有需要互動的資訊一次性地輸入。於此同時，我們的環境程式，也必須同時支援此種模式（一般這種模式，稱之為命令列模式）。
對於使用finalbuilder的人來講，就有必要了解相關程式的命令列呼叫方式。這樣有助於我們使用和編寫任務。如果是我們自己研發乙個程式，那麼因為要使用到finalbuilder中來，也有必要支援命令列模式。
在finalbuilder中，最主要的還是順序流程，當然它也支援條件(if)、分支(case)、迴圈(loop)。最新的版本還有多執行緒協同。不過在使用初期，主要還是以順序流程為主了。
最關鍵最有用的就是run dos command和execute programe兩個action(任務)了。有了這兩個，你幾乎可以完成任何事情。當然了finalbuilder還提供了很多現成的控制項，使得你可以通過配置（而不是命令列）來編寫任務。這大大降低了使用難度。不過，不可避免的會有一些需求需要我們自己編寫命令列，因此著兩個action必須掌握。
finalbuilder的自動執行，是使用windows的計畫任務來完成的。在其選單中有生成計畫任務的功能。順便說一句，finalbuilder也一樣支援命令列模式，因此多個finalbuilder之間可以互相呼叫。這對我們的自動化非常有利。
好了，經過簡單介紹之後，我們可以發現，使用finalbuilder確實可以幫助我們解決問題。
那麼，我們需要解決哪些問題呢？下面是我列出的乙份清單，這份清單是按照順序列出的：
解除安裝已經安裝的目標軟體。
刪除所有目標軟體想過目錄，保障乾淨環境
獲取並複製目標軟體安裝程式
獲取自動化測試指令碼和框架程式
安裝目標軟體
安裝自動化測試框架
執行目標軟體
執行目標軟體的自動化測試指令碼，如：冒煙測試
生成自動化執行日誌，分析結果
傳送郵件通知自動化負責人
上面的這些事情，所有需要完成的功能，其實都已經做好了。因為我們通過手工確實可以走到最後。但是要做到覆蓋全過程的自動化的想法，還需要各個工具軟體互相協調。
首先是軟體的安裝和解除安裝，這需要程式保障命令列模式的安靜執行。（安裝和解除安裝都是需要人工互動的），剛好我們公司的安裝程式支援這個模式，省去了很多麻煩。不過，很多安裝軟體也都是支援的，只要多查查資料就可以了。
複製檔案就簡單多了，finalbuilder和windows都已經提供了很多命令。
關於自動化測試的執行，就對我們的自動化指令碼編輯器提出了需求。針對這個需求，我好幾天加班加點才加進去。主要是程式的協同性問題。必須等到目標軟體的主窗體完全啟動完畢。另外，需要對中途的意外退出，作出嚴格的防範，保障自動化測試能夠有始有終。這裡面增加了乙個超時的概念，可以保障最後程式的退出。
分析日誌更是重要，事實上，沒有日誌的自動化測試沒有人願意去做。目前還是先根據一些簡單的需求，做了一些統計，相信以後還會增加的功能是版本日誌對比。這樣可以看到系統的穩定性變化趨勢。
ok，在使用finalbuilder之後，我們已經初步將乙個完整的自動化測試過程構建起來。不過正如部落格上的一位讀者所說的，下面要重點關注指令碼的方案設計了。
自動化測試框架
可設計為五層 一 測試用例層 主要存放用例的指令碼，分為主指令碼和子指令碼。主指令碼用來控制各個子指令碼，實現指令碼間的資料傳遞。子指令碼是實現各個功能點的指令碼，同時也會提取出一些共用的方法，一般放在提取層中。主指令碼中可使用資料驅動來控制指令碼實現各種場景的流程，如silktest的test s...
自動化測試框架 與FinalBuilder結合
當自動化測試的指令碼編輯器完成之後，根據使用者反饋，這樣確實大大提高了工作效率。並且 的管理確實變得有效和可控。現在此專案已經開始向另乙個管理系統嘗試應用。可以預計，會有一些新的功能加入。不過，我們回過頭來思考乙個問題 自動化的問題。這是我們最終的目的。雖然說自動化測試框架能夠解決軟體本身的執行問題...
自動化測試框架 自動化測試呼喚開發
週末參加了testage 測試時代 組織的乙個專家討論會。主要討論測試自動化。說是專家討論會，我參加實在是慚愧，我對測試的理解實在是太淺薄了。只是因為在部落格上發表了一些謬論才收到邀請。想著可以幫助公司去接受一些新的思想，而自己也可以結識一些朋友，便去了。對於測試時代的會議組織，我以為定位和思路還是...