如何制定成功的測試計畫

「工欲善其事，必先利其器」。專業的測試必須以乙個好的測試計畫作為基礎。儘管測試的每乙個步驟都是獨立的，但是必定要有乙個起到框架結構作用的測試計畫。

測試的計畫應該作為測試的起始步驟和重要環節。乙個測試計畫應包括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計畫表、問題跟蹤報告、測試計畫的評審、結果等等。

產品基本情況調研：

這部分應包括產品的一些基本情況介紹，例如：產品的執行平台和應用的領域，產品的特點和主要的功能模組，產品的特點等。對於大的測試專案，還要包括測試的目的和側重點。

具體的要點有：

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

變更：說明有可能會導致測試計畫變更的事件。包括測試工具改進了，測試的環境改變了，或者是新增了新的功能。

技術結構：可以借助畫圖，將要測試的軟體劃分成幾個組成部分，規劃成乙個適用於測試的完整的系統，包括資料是如何儲存的，如何傳遞的（資料流圖），每乙個部分的測試是要達到什麼樣的目的。每乙個部分是怎麼實現資料更新的。

還有就是常規性的技術要求，比如執行平台、需要什麼樣的資料庫等等。

產品規格：就是製造商和產品版本號的說明。

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

專案資訊：說明要測試的專案的相關資料，如：使用者文件，產品描述，主要功能的舉例說明。

測試需求說明：

這一部分要列出所有要測試的功能項。凡是沒有出現在這個清單裡的功能項都排除在測試的範圍之外。萬一有一天你在乙個沒有測試的部分裡發現了乙個問題，你應該很高興你有這個記錄在案的文件，可以證明你測了什麼沒測什麼。

具體要點有：

功能的測試：理論上是測試是要覆蓋所有的功能項，例如：在資料庫中新增、編輯、刪除記錄等等，這會是乙個浩大的工程，但是有利於測試的完整性。

設計的測試：對於一些使用者介面、選單的結構還有窗體的設計是否合理等的測試。

整體考慮：這部分測試需求要考慮到資料流從軟體中的乙個模組流到另乙個模組的過程中的正確性。

測試的策略和記錄：

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

公正性宣告：要對測試的公正性、遵照的標準做乙個說明，證明測試是客觀的，整體上，軟體功能要滿足需求，實現正確，和使用者文件的描述保持一致。

測試案例：描述測試案例是什麼樣的，採用了什麼工具，工具的**是什麼，如何執行的，用了什麼樣的資料。測試的記錄中要為將來的回歸測試留有餘地，當然，也要考慮同時安裝的別的軟體對正在測試的軟體會造成的影響。

特殊考慮：有的時候，針對一些外界環境的影響，要對軟體進行一些特殊方面的測試。

經驗判斷：對以往的測試中，經常出現的問題加以考慮。

設想：採取一些發散性的思維，往往能幫助你找的測試的新途徑。

測試資源配置：

專案資源計畫：制定乙個專案資源計畫，包含的是每乙個階段的任務、所需要的資源，當發生類似到了使用期限或者資源共享的事情的時候，要更新這個計畫。

計畫表：

測試的計畫表可以做成乙個多個專案通用的形式，根據大致的時間估計來製作，操作流程要以軟體測試的常規週期作為參考，也可以是根據什麼時候應該測試哪乙個模組來制定。

問題跟蹤報告：

在測試的計畫階段，我們應該明確如何準備去做乙個問題報告以及如何去界定乙個問題的性質，問題報告要包括問題的發現者和修改者、問題發生的頻率、用了什麼樣的測試案例測出該問題的，以及明確問題產生時的測試環境。

問題描述盡可能是定量的，分門別類的列舉，問題有幾種：

1、嚴重問題：嚴重問題意味著功能不可用，或者是許可權限制方面的失誤等等，也可能是某個地方的改變造成了別的地方的問題。

2、一般問題：功能沒有按設計要求實現或者是一些介面互動的實現不正確。

3、建議問題：功能執行得不象要求的那麼快，或者不符合某些約定俗成的習慣，但不影響系統的效能，介面先是錯誤，格式不對，含義模糊混淆的提示資訊等等。

測試計畫的評審：

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