制定成功的測試計劃

制定成功的測試計劃

《世界商業評論》ICXO.COM ( 日期：2004-07-28 11:04)

工欲善其事，必先利其器”。專業的測試必須以一個好的測試計劃作為基礎。儘管測試的每一個步驟都是獨立的，但是必定要有一個起到架構結構作用的測試計劃。測試的計劃應該作為測試的起始步驟和重要環節。一個測試計劃應包括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果等等。 產品基本情況調研： 這部分應包括產品的一些基本情況介紹，例如：產品的運行平台和應用的領域，產品的特點和主要的功能模組，產品的特點等。對於大的測試專案，還要包括測試的目的和側重點。 具體的要點有： 目的：重點描述如何使測試建立在客觀的基礎上，定義測試的策略，測試的配置， 粗略的估計測試大致需要的周期和最終測試報告遞交的時間。 變更：說明有可能會導致測試計劃變更的事件。包括測試載入器改進了，測試的環境改變了，或者是添加了新的功能。 技術結構：可以藉助畫圖，將要測試的軟體劃分成幾個組成部分，規劃成一個適用於測試的完整的系統，包括資料是如何儲存的，如何傳遞的（資料流圖），每一個部分的測試是要達到什麼樣的目的。每一個部分是怎麼實現資料更新的。還有就是常規性的技術要求，比如運行平台、需要什麼樣的資料庫等等。 產品規格：就是製造商和產品版本號碼的說明。 測試範圍：簡單的描述如何搭建測試平台以及測試的潛在的風險。 項目資訊：說明要測試的項目的相關資料，如：使用者文檔，產品描述，主要功能的舉例說明。 測試需求說明： 這一部分要列出所有要測試的功能項。凡是沒有出現在這個清單裡的功能項都排除在測試 的範圍之外。萬一有一天你在一個沒有測試的部分裡發現了一個問題，你應該很高興你有這個記錄在案的文檔，可以證明你測了什麼沒測什麼。具體要點有： 功能的測試：理論上是測試是要覆蓋所有的功能項，例如：在資料庫中添加、編輯、刪除記錄等等，這會是一個浩大的工程，但是有利於測試的完整性。 設計的測試：對於一些使用者介面、菜單的結構還有表單的設計是否合理等的測試。 整體考慮：這部分測試需求要考慮到資料流從軟體中的一個模組流到另一個模組的 過程中的正確性。 測試的策略和記錄： 這是整個測試計劃的重點所在，要描述如何公正客觀地開展測試，要考慮：模組、功能、 整體、系統、版本、壓力、效能、配置和安裝等各個因素的影響。要儘可能的考慮到細節，越詳細越好，並製作測試記錄文檔的模板，為即將開始的測試做準備，測試記錄重要包括的部分 具體說明如下： 公正性聲明：要對測試的公正性、遵照的標準做一個說明，證明測試是客觀的，整體上，軟體功能要滿足需求，實現正確，和使用者文檔的描述保持一致。 測試案例：描述測試案例是什麼樣的，採用了什麼工具，工具的來源是什麼，如何執行的，用了什麼樣的資料。測試的記錄中要為將來的迴歸測試留有餘地，當然，也要考慮同時安裝的別的軟體對正在測試的軟體會造成的影響。 特殊考慮：有的時候，針對一些外界環境的影響，要對軟體進行一些特殊方面的測試。 經驗判斷：對以往的測試中，經常出現的問題加以考慮。 設想：採取一些發散性的思維，往往能協助你找的測試的新途徑。 測試資源配置： 項目資源計劃：制定一個項目資源計劃，包含的是每一個階段的任務、所需要的資源，當發生類似到了使用到期日或者資源共用的事情的時候，要更新這個計劃。 計劃表： 測試的計劃表可以做成一個多重專案通用的形式，根據大致的時間估計來製作，操作流程 要以軟體測試的常規周期作為參考，也可以是根據什麼時候應該測試哪一個模組來制定。 問題跟蹤報告： 在測試的計劃階段，我們應該明確如何準備去做一個問題報告以及如何去界定一個問題的 性質，問題報告要包括問題的發現者和修改者、問題發生的頻率、用了什麼樣的測試案例測出該問題的，以及明確問題產生時的測試環境。 問題描述儘可能是定量的，分門別類的列舉，問題有幾種： 1、嚴重問題：嚴重問題意味著功能不可用，或者是許可權限制方面的失誤等等，也可能是某個地方的改變造成了別的地方的問題。 2、一般問題：功能沒有按設計要求實現或者是一些介面互動的實現不正確。 3、建議問題：功能運行得不象要求的那麼快，或者不符合某些約定俗成的習慣，但不影響系統的效能，介面先是錯誤，格式不對，含義模糊混淆的提示資訊等等。 測試計劃的評審： 又叫測試規範的評審，在測試真正實施開展之前必須要認真負責的檢查一遍，獲得整個測 試部門人員的認同，包括部門的負責人的同意和簽字。 結果： 計劃並不是到這裡就結束了，在最後測試結果的評審中，必須要嚴格驗證計劃和實際的執 行是不是有偏差，體現在最終報告的內容是否和測試的計劃保持一致，然後，就可以開始著手製作下一個測試計劃了。