自動化測試框架: 與FinalBuilder結合
當自動化測試的指令碼編輯器完成之後,根據使用者反饋,這樣確實大大提高了工作效率。並且程式碼的管理確實變得有效和可控。現在此專案已經開始向另一個管理系統嘗試應用。可以預計,會有一些新的功能加入。
不過,我們回過頭來思考一個問題--自動化的問題。這是我們最終的目的。雖然說自動化測試框架能夠解決軟體本身的執行問題,但是一次完整的測試,必然是要覆蓋全過程的。很顯然,我們的框架不能解決這個問題。
我做過很多專案的每日版本構造,所以對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之後,我們已經初步將一個完整的自動化測試過程構建起來。不過正如部落格上的一位讀者所說的,下面要重點關注指令碼的方案設計了。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1779887
相關文章
- 軟體自動化測試與AI結合 - modernanalystAINaN
- 自動化測試框架框架
- 介面自動化測試框架搭建總結框架
- 軟體測試框架——自動化測試框架框架
- 自動化測試框架思路框架
- 自動化測試框架指南框架
- 自己動手寫Web自動化測試框架(6):自動化測試框架的規劃Web框架
- 測試開發之自動化篇-自動化測試框架設計框架
- 手工測試與APPSCAN自動化測試結合的提高效率測試策略APP
- 自動化測試框架比較框架
- 自動化測試框架介紹框架
- Selenium自動化測試框架框架
- 軟體測試自動化框架框架
- 介面自動化測試框架 HttpFPT框架HTTP
- 利用tox打造自動自動化測試框架框架
- T框架介紹(自動化測試框架)框架
- Airtest結合tidevice實現IOS自動化測試AIIDEdeviOS
- 自動化裝置測試與自動化測試的區別
- UI自動化測試框架Cypress初探UI框架
- Python 自動化測試框架unittestPython框架
- 自動化測試QTP知識框架QT框架
- 自動化測試框架:擁抱Ruby框架
- 自動化測試框架的AW模式框架模式
- 自動化測試總結(二)
- 自動化測試系列 —— UI自動化測試UI
- 《軟體自動化測試成功之道》節選8 - 與每日構建結合
- 軟體自動化測試有什麼優勢?自動化測試框架有哪些?框架
- 自己動手寫Web自動化測試框架Web框架
- Robot Framework自動化測試框架核心指南-如何做好自動化測試平臺框架的設計Framework框架
- 淺談自動化測試框架開發框架
- HamronyOS 自動化測試框架使用指南框架
- Python自動化測試框架介紹Python框架
- 常用網路介面自動化測試框架框架
- 自動化測試框架Selenium入門框架
- 四種常用的自動化測試框架框架
- 自動化測試框架:日誌的分析框架
- Python自動化測試框架-pytestPython框架
- 介面自動化測試框架搭建的思路框架