c)哪些部分不需要測試,為什么?
d)哪些部分需要推遲測試,為什么?
e)是否要驗證每個模塊的穩定性?
f)測試的優先級和先后順序。(例如,先測試均勻派發程序,后測試數據查詢程序,因為均勻派發程序必須今天內發布,非常緊急!)
2.測試目標
系統目標對測試人員了解自己需要做什么是非常重要的。測試項目負責人應積極與系統設計人員或開發人員溝通,以取得相關資料。測試人員必須知道系統是做什么并且幫助項目實現這種目標。在計劃中包括系統視圖和目標后,要確保所有的測試人員都知道項目和系統的目標。通常情況下項目計劃都是模糊的。模糊的目標必須通過成員的努力轉換成可衡量和實現的東西。沒有固定的視圖和目標,你將無法完成部分任務。而且,你會發現很難將對產品的認識向別人轉述。
(例如,邏輯測試系統是一個能夠選擇數據庫,執行腳本以及顯示測試用例上提到的所有參數。邏輯測試系統的目標:為了方便測試人員在測試邏輯腳本,提高測試人員測試促銷邏輯的速度和效率,更好地保證發布的促銷邏輯參數的準確性。)
3.聯系方式
列出項目參與人員的職務、姓名、E-mail 和電話。
表格 1 聯系方式
職務 | 姓名 | 電話 | |
開發人員 | - | - | - |
開發經理 | - | - | - |
測試負責人 | - | - | - |
測試人員 | - | - | - |
4.風險及約束
列出測試過程中可能存在的一些風險和制約因素,并給出規避方案。如:
a)由于客觀存在的設備、網絡等資源原因,使得測試不全面。明確說明哪些資源欠缺,產生什么約束;(例如,客戶端程序---由于網絡資源有限,不能做到十幾臺機器同時下載的情況,無法進行大型的壓力測試)
b)由于研發模式為現場定制,且上線時間壓力大,使得測試不充分。明確說明在此種約束下,測試如何應對;
c)只針對專門的客戶群需求的測試。明確說明此約束下的客戶群和業務范圍。(例如,測試系統只針對測試人員的需求進行測試)
5.測試文檔
列出測試過程中可能用到的參考文檔、相關的設計文檔以及保存位置,測試完成后應產生的文檔。
(例如,測試工具CMITest----參考文檔:《邏輯測試系統測試計劃-V2.0.doc》,《邏輯測試系統測試用例-V2.0.doc》;
保存位置:\\195.1.1.1\ AfterService\upgrade目錄下,測試完成后應該產生《邏輯測試報告手冊V1 0.doc》)
6.測試參考文檔
表格 2 測試參考文檔
文檔說明 | 作者 | 文檔位置 |
需求文檔(需求規格說明書、Readme.txt或者郵件) | - | - |
測試計劃 | - | - |
測試用例 | - | - |
7.測試提交文檔
表格 3 測試提交文檔
文檔說明 | 作者 | 文檔位置 |
《測試計劃》 | - | - |
《測試用例》 | - | - |
《測試報告》 | - | - |
《Readme.txt》 | - | - |
《操作說明手冊》 | - | - |
原文轉自:http://www.uml.org.cn/Test/200906256.asp