談到測試框架,很多人都趨之若鶩,本人也不例外。但最近發現自己對測試框架的理解一直存在誤解。很長時間對框架的理解,一直存在于如何組織腳本,如何寫出高質量的腳本這個層次,整個框架好像就是針對腳本這個層面。其實這個理解很局限也很片面。一個好的測試框架,應該包括整個測試活動的各個方面,以及對各個環節的規范、管理等等,所以腳本只是框架當中的一個環節,不應把腳本看的很重(當然不是說不重要)。腳本是用工具寫的,工具永遠是工具,整個測試過程起關鍵作用的還是人。
一個合理的框架應該包括流程、團隊、技術這三個基本要素,再用管理把這三個要素協調起來。
如圖,這三個要素是相輔相成互相依賴。
流程
首先談一下流程。這個要素,在整個測試活動周期中是用時最長的一個,大部分的測試活動都是在流程中進行。一個好的流程可以節約成本,縮短進度,提高測試質量。設計流程,不能為了自動化而自動化,要結合項目情況、目前測試部門發展情況來規劃功能自動化測試流程。
流程的規劃應該覆蓋自動化測試分析,業務流程的分析與組織,腳本的設計與開發。
拿到項目任務書后,首先要進行的就是自動化測試分析。這時要結合手上有的測試資源,如待測系統,測試需求,測試用例庫,功能說明等等,對系統來個綜合分析。這些作為分析階段的輸入。有輸入就要有輸出,也就是分析結果了。分析過程就是對業務的分析,對怎么規劃腳本的分析。對業務的分析最終要得出本次或本論測試需要測試范圍、內容,以及測試內容對需求的覆蓋情況等內容,最終形成業務跟蹤表,作為輸出。對于規劃腳本,就是要確定哪些功能可以做自動化,哪些不能做;哪些功能需要單獨作為一個腳本來寫,哪些功能適合合并成一個腳本來寫;參數的定義,主要是針對多個腳本都要用到的變量給出定義;其他可以定義一些腳本的相關信息。最終也要形成腳本分析跟蹤表,作為分析階段的輸出,納入測試資產統一管理。有了這些作為基礎,可以最大限度保證后續工作在可控范圍內進行。
做完分析工作,就可以繼續業務的組織和腳本的開發工作了,這兩個可以并行開展。把分析階段的輸出做為輸入,有序開展后續活動。
對于業務的分析組織,主要參與者是熟悉系統業務的人員?,F在的應用系統越來越復雜,如果沒有業務人員參與進來恐怕很難把測試做到位。這個過程就是由熟悉業務的人員來組織需要測試內容。包括測試功能點,業務邏輯,業務范圍等等。同時針對特殊業務規則,數據規則提出相應的需求,協調其他資源滿足特殊需求。這個過程也是組織測試案例、測試數據的過程,為測試執行做準備工作。這個過程的輸出就是測試內容的跟蹤表了。
與業務并行開展的就是腳本的設計與開發了。它不會受限與測試流程、測試邏輯的限制,完全可以按照分析過程的跟蹤表進行腳本的開發。這個過程腳本的設計和開發是兩個獨立的過程,設計是以文檔的方式展現腳本,包括腳本信息、輸入/輸出參數、調用說明、腳本流程圖等內容,這樣做可以讓團隊成員之間很好的協作,避免出現混亂、失控的狀態。而且腳本的設計人員不用考慮具體的業務邏輯,只要按照既定規則把劃分好的腳本設計好就完成了任務。然后腳本的開發人員嚴格按照設計文檔進行開發,最終形成腳本集,供其他環節調用。
以上各個活動都會有管理或是QA參與,進行活動的評審,確保各個環節都是按照規范進行的,保證自動化實施過程是在可控范圍內進行的活動,避免某個環節的隨意性。
技術
技術角度,主要是決定采用什么樣的工具,腳本開發工具,配置管理工具。還有就是要制定針對在工具的使用過程中要遵循的規范,如何讓工具之間配合,發揮最大的作用。
功能自動化測試用的最多的莫過于QTP了,由于它的簡單、易用,容易上手很是受大家的追捧。當然還有它能夠破解,這也為它廣泛推廣打下很好的基礎。
技術環節需要對腳本的開發做出明確的說明。底層函數的定義,功能函數的開發,函數庫的規劃,參數、腳本的開發規范等這些都要形成文檔。最后腳本的運行也是一個很關鍵的環節,包括運行的穩定性,效率,日志,失敗的處理這些都是需要處理的問題。如果條件允許可以自己開發工具來解決這些問題,但相應帶來的成本也是非常高的。這樣做的公司都是有單獨的團隊來維護測試工具這一塊的,所以在人力、技術資源很有限的情況下不要輕易嘗試這種方式。同行用的最多的好像就是用Excel來組織,然后通過讀取Excel來控制腳本的運行,這種方式簡單,易行,但對于過于復雜的系統不適用。還有一種方式就是用QTP+QC的方式,QC有單獨的模塊來管理,組織這些內容。并且會自動記錄執行日志,結果文件等。這種方式是最方便,成本最低的一種方式,維護起來也很容易,而且沒有不兼容的情況,很容易見到效果。如果公司不打算組建專門的測試開發團隊,用這個是最有效的一種方式。缺點是在組織數據時的靈活性欠佳。
原文轉自:http://www.uml.org.cn/Test/2009040910.asp