本文件是測試團隊的日常工作規範，主要側重測試工作流程的控制，明確軟體工程的各階段測試團隊應完成的工作。測試技術和策略等問題不在本文件描述範圍內。
測試是軟體開發過程中的重要組成部分，肩負著如下責任：
在專案的前景、需求文件確立基線前對文件進行測試，從使用者體驗和測試的角度提出自己的看法。
編寫合理的測試計畫，並與專案整體計畫有機地整合在一起。
編寫覆蓋率高的測試用例。
針對測試需求進行相關測試技術的研究。
認真仔細地實施測試工作，並提交測試報告供專案組參考。
進行缺陷跟蹤與分析。
在人力資源有限的情況下，乙個團隊成員可能會同時承擔多個角色。
在專案組成立的同時，測試組也將同時成立。團隊成立的工作與責任如下：
圖表 1
在正式測試任務下達前，開發團隊應提前一周左右向測試團隊下達預通知，告之較為確切的測試日期，提供當前最新的相關資料。測試部門經理可視具體情況決定是否需要調整人力。測試人員可預先熟悉必要的背景資料，協助測試經理編寫《測試計畫書》初稿。
圖表 2
圖表 3
需求分析文件確立後，測試組需要編寫測試計畫文件，為後續的測試工作提供直接的指導
圖表 4
在需求分析文件確立基線以後，測試組需要針對專案的測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標準。在用例的編寫過程中，具體的任務和責任人如下：
圖表 5
實施測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計畫工作的基礎上。
圖表 6
在約定的測試週期完成之後，測試經理需要總結此測試的結果，編寫測試報告
圖表7在每輪測試結束之後，由測試組重新拷貝修改後的最新版本，進行回歸測試。
圖表 2
測試工作結束或即將結束時，測試組就要開始著手準備進行總結的工作。
在回歸測試結束之後，測試經理將要編寫測試總結報告，對測試進行總結，並且提交給全體專案組，為產品的後續工作提供重要的資訊支援。
測試總結工作是在以上的工作全部結束以後，它的目的是評估本次測試工作，總結經驗，使下一次的工作做得更好。
測試驗收工作是在以上工作全部結束後，對測試的過程，效果進行驗收，宣布測試結束。
測試歸檔是在測試驗收結束宣布測試有效，結束測試後，對測試過程中涉及到各種標準文件進行歸類，存檔。
測試驗收結束後，跟蹤產品在試執行階段暴露出來的新缺陷，以及已提交的缺陷是否再次發生。
本規範定義以下五類缺陷：
a類——嚴重錯誤，包括：
1. 由於程式所引起的宕機,非法退出
2. 死迴圈
3. 導致資料庫發生死鎖
4. 資料通訊錯誤
5 嚴重的數值計算錯誤
b類——較嚴重錯誤，包括：
1. 功能不符
2. 資料流錯誤
3. 程式介面錯誤
4. 輕微的數值計算錯誤
c類——一般性錯誤，包括：
1. 介面錯誤(詳細文件)
2. 列印內容、格式錯誤
3. 簡單的輸入限制未放在前台進行控制
4. 刪除操作未給出提示
d類——較小錯誤，包括：
1. 輔助說明描述不清楚
2. 顯示格式不規範
3. 長時間操作未給使用者進度提示
4. 提示視窗文字未採用行業術語
5. 可輸入區域和唯讀區域沒有明顯的區分標誌
6. 系統處理未優化
e類——測試建議（非缺陷）
軟體測試合格須符合以下標準。
以上比例為錯誤佔總測試模組的比例。
軟體產品未經測試合格，不允許投運。
如開發團隊對測試結論有爭議，由驗收組成員會議協調解決。測試團隊和開發團隊應無條件服從仲裁結果。
1. 《測試任務說明書》
2. 《測試計畫書》
3. 《測試用例說明書》
4. 《測試報告》
5. 《測試總結報告》
測試工作規範
版本記錄 目錄目錄.1 1.編寫目的.2 2.測試團隊構成.2 2.1職責.2 2.2角色劃分.2 3.1計畫與設計階段.2 3.1.1成立測試團隊.2 3.1.3召開測試啟動會議.3 3.1.4編寫測試計畫文件.3 3.1.5設計測試用例.4 3.2實施測試階段.4 3.2.1實施測試用例.43....
測試工作規範
v1.0 修改歷史 更改請求號 為文件正式發布後需要變更時的編號，編號方法待定，見配置管理kpa相關文件。正式批准 本文件是測試團隊的日常工作規範，主要側重測試工作流程的控制，明確軟體工程的各階段測試團隊應完成的工作。測試技術和策略等問題不在本文件描述範圍內。測試是軟體開發過程中的重要組成部分，肩負...
測試工作規範
1編寫目的 本文件是測試團隊的日常工作規範，主要側重測試工作流程的控制，明確軟體工程的各階段測試團隊應完成的工作。2測試職責 測試是軟體開發過程中的重要組成部分，肩負著如下責任 在專案的前景 需求文件確立基線前對文件進行測試，從使用者體驗和測試的角度提出自己的看法。編寫合理的測試計畫，並與專案整體計...