基本概述

《ANSI/IEEE軟體測試文檔標準829-1983》將測試計畫定義為:“一個敘述了預定的測試活動的範圍、途徑、資源及進度安排的文檔。它確認了測試項、被測特徵、測試任務、人員安排,以及任何偶發事件的風險。”軟體測試計畫是指導測試過程的綱領性檔案,包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。藉助軟體測試計畫,參與測試的項目成員,尤其是測試管理人員,可以明確測試任務和測試方法,保持測試實施過程的順暢溝通,跟蹤和控制測試進度,應對測試過程中的各種變更。
測試目標

編寫軟體測試計畫得重要目的就是使測試過程能夠發現更多的軟體缺陷,因此軟體測試計畫的價值取決於它對幫助管理測試項目,並且找出軟體潛在的缺陷。因此,軟體測試計畫中的測試範圍必須高度覆蓋功能需求,測試方法必須切實可行,測試工具並且具有較高的實用性,便於使用,生成的測試結果直觀、準確。
一個好的測試計畫可以起到如下作用:
1、避免測試的“事件驅動”;
2、使測試工作和整個開發工作融合起來;
3、資源和變更事先作為一個可控制的風險。
“5W”規則
“5W”規則指的是“What(做什麼)”、“Why(為什麼做)”、“When(何時做)”、“Where(在哪裡)”、

“How(如何做)”。利用“5W”規則創建軟體測試計畫,可以幫助測試團隊理解測試的目的(Why),明確測試的範圍和內容(What),確定測試的開始和結束日期(When),指出測試的方法和工具(How),給出測試文檔和軟體的存放位置(Where)。為了使“5W”規則更具體化,需要準確理解被測軟體的功能特徵、套用行業的知識和軟體測試技術,在需要測試的內容裡面突出關鍵部分,可以列出關鍵及風險內容、屬性、場景或者測試技術。對測試過程的階段劃分、文檔管理、缺陷管理、進度管理給出切實可行的方法。
就通常軟體項目而言,基本上採用“瀑布型”開發方式,這種開發方式下,各個項目主要活動比較清晰,易於操作。整個項目生命周期為“需求-設計-編碼-測試-發布-實施-維護”。然而,在制定測試計畫時候,有些測試經理對測試的階段劃分還不是十分明晰,經常性遇到的問題是把測試單純理解成系統測試,或者把把各類型測試設計(測試用例的編寫和測試數據準備)全部放入生命周期的“測試階段”,這樣造成的問題是浪費了開發階段可以並行的項目日程,另一方面造成測試不足。合理的測試階段應遵循下面劃分方法:

照上圖所述,相應階段可以同步進行相應的測試計畫編制,而測試設計也可以結合在開發過程中實現並行,測試的實施即執行測試的活動即可連貫在開發之後。值得注意的是:單元測試和集成測試往往由開發人員承擔,因此這部分的階段劃分可能會安排在開發計畫而不是測試計畫中。
評審更新機制

測試計畫改變了已往根據任務進行測試的方式,因此,為使測試計畫得到貫徹和落實,測試組人員必須及時跟蹤軟體開發的過程,對產品提交測試做準備,測試計畫的目的,本身就是強調按規劃的測試戰略進行測試,淘汰以往以任務為主的臨時性。在這種情況下,測試計畫中強調對變更的控制顯得尤為重要。
變更來源於以下幾個方面:
1、項目計畫的變更;
2、需求的變更;
3、測試產品版本的變更;
4、測試資源的變更。
測試階段的風險主要是對上述變更所造成的不確定性,有效的應對這些變更就能降低風險發生的幾率。要想計畫本身不成為空談和空白無用的紙質文檔,對不確定因素的預見和事先防範必須做到心中有數。對於項目計畫的變更,除了測試人員及時跟進項目以外,項目經理必須認識到測試組也是項目成員,因此必須把這些變更信息及時通知到項目組,使得整個項目得到順延。項目計畫變更一般涉及都是日程變更,令人遺憾的是,往往為了進度的原因,交付期限是既定的,項目經理不得不減少測試的時間,這樣,執行測試的時間就被壓縮了。在這種情況下,測試經理常常固執的認為進度縮減的唯一的方法就是向上級通報並主觀認為產品質量一定會下降,這種做法和想法不一定是正確的。
詳細規格

測試資源的變更是源自測試組內部的風險而非開發組風險,當測試資源不足或者衝突,測試部門不可能安排如此多的人手和足夠時間參與測試時,在測試計畫中的控制方法與測試時間不足相類似。沒有測試經理願意承擔資源不足的測試工作,只能說公司本身是否具備以質量為主的體系或者項目經理對產品質量的重視程度如何決定了對測試資源投入的大小,最終產品質量取決因素不僅僅在於測試經理。為了排除這種風險,除了象時間不足、測試計畫變更時那樣縮減測試規模等等方法以外,測試經理必須在人力資源和測試環境一欄標出明確需要保證的資源,否則,必須將這個問題作為風險記錄。規避風險的辦法可能有:

二、抽調不同模組開發者進行交叉系統測試或借用其他項目開發人員;
儘管上面儘可能的描述了測試計畫如何制定才能“完美”,但是還存在的問題是對測試計畫的管理和監控。一份計畫投入再多的時間去做也不能保證按照這份計畫進行實施。好的測試計畫是成功的一半,另一半是對測試計畫的執行。對小項目而言,一份更易於操作的測試計畫更為實用,對中型乃至大型項目來看,測試經理的測試管理能力就顯得格外重要,要確保計畫不折不扣的執行下去,測試經理的人際諧調能力,項目測試的操作經驗、公司的質量現狀都能夠對項目測試產生足夠的影響。另外,計畫也是“動態的”。不必要把所有的因素都可能囊括進去,也不必要針對這種變化額外製定“計畫的計畫”,測試計畫制定不能在項目開始後束之高閣,而是緊追項目的變化,實時進行思考和貫徹,根據現實修改,然後成功實施,這才能實現測試計畫的最終目標――保證項目最終產品的質量。
模板要求
軟體項目的測試計畫是描述測試目的、範圍、方法和軟體測試的重點等的文檔。對於驗證軟體產品的可接受程度編寫測試計畫文檔是一種有用的方式。詳細地測試計畫可以幫助測試項目組之外的人了解為什麼和怎樣驗證產品。它非常有用但是測試項目組之外的人卻很少去讀它。

1、標題;
2、軟體標識,包括版本/發布版本號;
3、目錄;
4、文檔的目的和閱讀人群;
5、測試的對象;
6、軟體產品概述;
7、相關文檔列表,例如需求規格、設計文檔和其它測試計畫等;
8、有關的標準和法規;
9、可追溯的需求;
10、有關的命名約定和標識約定;
11、軟體項目的相關的所有部門和成員/聯繫信息/職責;
12、測試項目組和人員/聯繫信息/職責;
13、假設和依賴;
14、項目風險分析;
15、測試優先權和重點;
16、範圍和測試限制;
17、測試描述-根據測試類型、特徵、功能、過程、系統、模組等分類;
18、輸入等價類分類描述、邊界值分析、錯誤分類;
19、測試環境-軟、硬體、作業系統、其它需要的軟體、數據配置、與其它系統的接口;
20、測試環境有效性分析-測試環境的不同和產品系統對測試有效性的影響;
21、測試環境建立和配置問題;
22、軟體移植性考慮;
23、軟體配置管理過程;
24、測試數據建立需求;
25、系統日誌描述/錯誤日誌/其它的能力和工具,例如螢幕捕獲工具、這對於描述bug和報告bug
是很有用的;
26、討論任何測試人員用來發現bug或跟蹤bug的硬體、軟體工具;
27、測試自動化-採用的理由和描述;

29、測試腳本/測試代碼維護過程和版本控制;
30、跟蹤和解決-工具和步驟
31、用於項目的測試度量標準;
32、報告需求和測試交付產品;
33、軟體入口和出口標準;
34、初期確定的測試周期和標準;
35、測試暫停和重啟標準;
36、人員分配;
37、人員崗前培訓;
38、測試地點/場所;
39、測試項目組之外可用的資源和他們的作用、職責、交付、聯繫人和協調等問題;
40、與所有權相關的級別、分類、安全和許可問題;
41、公開的一些問題。
軟體測試
軟體測試定義是:為了發現程式中的錯誤而執行程式的過程.它是幫助識別開發完成(中間或最終的版本)的計算機軟體(整體或部分)的正確度(correctness) 、完全度(completeness)和質量(quality)的軟體過程;是SQA(software quality assurance)的重要子域。希望在完成這個詞條的同時,與大家共同學習。 |