制定有效的測試計劃

通常,測試計劃制定的第一步就是將軟件分解成效小而且相對獨立的功能模塊,寫出測試需求.

 

測試需求有很多分類方法,最普通的一種就是按照功能分類.把軟件分解成功模塊有幾個好處.

1.測試需求是測試設計和開發測試用例的基礎,分解功能模塊可以更好地進行設計.

2.詳細的測試需求是用來衡量測試覆蓋率的重要指標.

3.測試需求包括各種測試實際和開發以及所需資源.

 

一個測試計劃應包括:產品基本情況,測試需求說明,測試策略和紀錄,測試資源配置,計劃表,問題跟蹤報告,測試計劃的評審和結果等.

 

1.產品基本情況調研

這部分應包括產品的一些基本情況介紹,例如:產品的運行平台和應用的領域,產品的特點和主要的功能模塊等.對於大的測試項目,還要包括測試的目的和側重點.具體的要點有:

 

目的.重點描述如何使測試建立在客觀的基礎上,定義測試的策略,測試的配置,粗略地估計測試大致需要的週期和最終測試報告遞交的時間.

變更.說明有可能會導致測試計劃變更的事件.包括測試工具改進了,測試的環境改變了,或者是添加了新的功能.

技術結構.可以藉助畫圖,將要測試的軟件劃分成幾個組成部分,規劃成一個適用於測試的完整系統,包括數據如何存儲,如何傳遞(數據流圖),每一部分的測試要達到什麼樣的目的,每一部分怎麼實現數據更新.還有就是常規性的技術要求,比如運行平台,需要什麼樣的數據庫等.

產品規格.製造商和產品版本號的說明.

測試範圍.簡單地描述如何搭建測試平台以及測試的潛在風險.

項目信息.說明要測試項目的相關資料,如用戶文檔,產品描述,主要功能的舉列說明.

 

2.測試需求說明

這一部分要列出所有要測試的功能項,凡是沒有出現在這個清單里的功能項都排除在測試的範圍之外.萬一有一天你在一個沒有測試的部分里發現了一個問題,你應該很高興你有這個紀錄在案的文檔,可以證明你測了什麼,沒測什麼.具體要點有:

功能的測試.理論上測試要覆蓋所有的功能項,例如:在數據庫中添加,編輯,刪除紀錄等,這會是一個浩大的工程,但是有利於測試的完整性.

設計的測試.對於一些用戶介面,菜單結構,還有窗體設計是否合理等的測試.

綜合考慮.這部分測試需求要考慮數據流從軟件中一個模塊流到另一個模塊過程中的正確性.

 

3.測試的策略和紀錄

這是整個測試計劃的重點所在,要描述如何公正,客觀地開展測試,要考慮模塊,功能,整體,系統,版本,壓力,性能,配置和安裝等各個因素的影響.要盡可能地考慮到細節,越詳細越好,並製作測試紀錄文檔的模塊,為即將開始的測試做準備.測試紀錄中要包括的部分具體說明如下.

 

聲明:要對測試公正性,遵照的標準做一個說明,證明測試是客觀的.整體上,軟件功能要滿足需求,實現正確,和用戶文檔的描述保持一致.

測試案例:描述測試案例是什麼樣的,採用了什麼工具,工具的來源是什麼,如何執行的,用了什麼樣的數據.測試的紀錄中要為將來的回歸測試留有餘地,當然,也要考慮同時安裝別的軟件對正在測試軟件會造成的影響.

特殊考慮:有的時候,針對一些外界環境的影響,要對軟件進行一些特殊方面的測試 .

經驗判斷:對以往的測試中經常出現的問題加以考慮.

設想:採取一些發散性的思維,往往能幫助你找到測試'的新途徑.

 

4.測試資源配置

制定一個項目資源計劃,包含每一個階段的任務,所需要的資源,當發生類似到了使用期限或者資源共享等事情的時候,要更新這個計劃.

 

5.計劃表

測試的計劃表可以做成多個項目通用的形成,根據大致的時閒估計來製作.操作流程要以軟件測試的常規週期作為參考,也可以根據什麼時候應該測試哪一個模塊來制定.

 

6.問題跟蹤報告

在測試的計劃階段,我們應該明確如何去做一個問題報告以及如何去界定一個問題的性質,問題報告要包括問題的發現者和修改者,問題發生的頻率,用了什麼樣的測試案例測出該問題的,以及明確問題產生時的測試環境.問題描述盡可能是定量的,分門別類地列舉.問題有幾種.

 

嚴重問題:嚴重問題意味著功能不可用,或者是權限限制方面的失誤等,也可能是某個地方的改變造成了別的地方出現問題.

一般問題:功能沒有按設計要求實現或者是一些介面交互的實現不正確.

建議問題:功能運行得不像要求的那麼塊,或者不符合某些約定俗成的習慣,但不影響系統的性能,如介面顯示錯誤,格式不對,含義模糊,混淆的提示信息等.

 

7.測試計劃的評審

又叫測試規範的評審,在測試真正實施之前必須要認真,負責地檢查一遍,獲得整個測試部門人員的認同,包括部門負責人的同意和簽字.

 

8.結果

計劃並不是到這裡就結束了,在最後測試結果的評審中,必須要嚴格驗證計劃和實際的執行是不是有偏差,體現在最終報告的內容是否和測試的計劃保持一致,然後,就可以開始著手製作下一個測試計劃了.