|
測試工作規(guī)范
版本記錄：
|
文件狀態(tài)：
[√] 草稿
[ ] 正式發(fā)布
[ ] 正在修改
|
當前版本：
|
1.1
|
|
作 者：
|
|
|
完成日期：
|
|
|
簽 收 人：
|
|
|
簽收日期：
|
|
1編寫目的
本文檔是測試團隊的日常工作規(guī)范，主要側重測試工作流程的控制，明確軟件工程的各階段測試團隊應完成的工作。測試技術和策略等問題不在本文檔描述范圍內。
2測試團隊構成
2.1職責
測試是軟件開發(fā)過程中的重要組成部分，肩負著如下責任：
Ø 在項目的前景、需求文檔確立基線前對文檔進行測試，從用戶體驗和測試的角度提出自己的看法。
Ø 編寫合理的測試計劃，并與項目整體計劃有機地整合在一起。
Ø 編寫覆蓋率高的測試用例。
Ø 針對測試需求進行相關測試技術的研究。
Ø 認真仔細地實施測試工作，并提交測試報告供項目組參考。
Ø 進行缺陷跟蹤與分析。
在人力資源有限的情況下，一個團隊成員可能會同時承擔多個角色。
|
角色名稱
|
相關主要責任
|
|
測試經(jīng)理
|
l 組建測試組
|
|
l 協(xié)調測試組內部的溝通
l 代表測試組與其他角色組進行溝通
l 編寫測試計劃
l 測試報告分析
|
|
測試用例設計工程師
|
l 編寫測試用例{可以由測試經(jīng)理兼任}
|
|
測試實施工程師
|
l 實施測試用例，執(zhí)行測試
|
|
技術支持工程師
|
l 為測試工作提供技術支持
|
3工作流程及規(guī)范
3.1計劃與設計階段
在項目組成立的同時，測試組也將同時成立。團隊成立的工作與責任如下：
|
過程要點
|
詳細說明
|
|
輸入條件
|
項目組成立（參與《項目計劃書》的評審）
|
|
工作內容
|
為測試組任命一名測試經(jīng)理，同時確定測試組的構成人選。
|
|
退出標準
|
測試組成立
|
|
責任人
|
測試經(jīng)理
|
圖表 1
3.1.2測試預通知
在正式測試任務下達前，開發(fā)團隊應提前一周左右向測試團隊下達預通知，告之較為確切的測試日期，提供當前最新的相關資料。測試部門經(jīng)理可視具體情況決定是否需要調整人力。測試人員可預先熟悉必要的背景資料，協(xié)助測試經(jīng)理編寫《測試計劃書》初稿。
|
過程要點
|
詳細說明
|
|
輸入條件
|
項目進入軟件實現(xiàn)階段（編碼）
|
|
工作內容
|
項目/產(chǎn)品經(jīng)理郵件通知測試經(jīng)理正式測試交接時間，測試規(guī)模預估等
|
|
退出標準
|
預通知得到測試經(jīng)理確認，并提交《測試計劃書》初稿
|
|
責任人
|
產(chǎn)品經(jīng)理，測試經(jīng)理
|
圖表 2
3.1.3召開測試啟動會議
|
過程要點
|
詳細說明
|
|
輸入條件
|
測試經(jīng)理完成測試計劃書初稿
|
|
工作內容
|
開發(fā)團隊與測試團隊交接測試內容，對測試目標達成一致，商討測試計劃初稿的可行性，統(tǒng)一項目組的目標和測試的工作重點。
|
|
退出標準
|
明確測試內容與重點，項目方提交《測試任務書》，測試方提交《測試計劃書》正稿。
|
|
責任人
|
產(chǎn)品經(jīng)理，測試經(jīng)理
|
圖表 3
3.1.4編寫測試計劃文檔
需求分析文檔確立后，測試組需要編寫測試計劃文檔，為后續(xù)的測試工作提供直接的指導
|
過程要點
|
詳細說明
|
|
輸入條件
|
項目需求文檔建立
|
|
工作內容
|
根據(jù)項目的需求文檔，按照測試計劃文檔模板編寫測試計劃。測試計劃中應該至少包括以下關鍵內容：
l 測試需求——需要測試組測試的范圍，估算出測試所花費的人力資源和各個測試需求的測試優(yōu)先級
l 測試方案——整體測試的測試方法和每個測試需求的測試方法
l 測試資源——本次測試所需要用到的人力、硬件、軟件、技術的資源
l 測試組角色——明確測試組內各個成員的角色和相關責任
l 里程碑——明確標準項目過程中測試組應該關注的里程碑
l 可交付工件——在測試組的工作中必須向項目組提交的產(chǎn)物，包括測試計劃、測試報告等等
l 風險管理——列舉出測試工作所可能出現(xiàn)的風險
測試計劃編寫完畢后，必須提交給項目組全體成員，并由項目組組中各個角色組聯(lián)合評審。
|
|
退出標準
|
l 測試計劃由項目組評審通過.
l 在項目開發(fā)過程中，要適時的對測試計劃進行跟蹤，以評估此計劃的完整性、可行性，在項目結束時還要最后評估一下測試計劃的質量
|
|
責任人
|
測試經(jīng)理
|
圖表 4
在需求分析文檔確立基線以后，測試組需要針對項目的測試需求編寫測試用例，在實際的測試中，測試用例將是唯一實施標準。在用例的編寫過程中，具體的任務和責任人如下：
|
過程要點
|
詳細說明
|
|
輸入條件
|
測試需求明確，測試計劃明確
|
|
工作內容
|
根據(jù)每一步測試計劃編寫全部的測試用例
|
|
退出標準
|
測試用例需要覆蓋所有的測試需求
|
|
責任人
|
測試用例設計工程師（可由測試實施工程師或測試經(jīng)理兼做）
|
圖表 5
實施測試用例將花費測試組絕大部分時間，這些工作都是建立在前期很多計劃工作的基礎上。
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試經(jīng)理制前一工作日定出當日的測試計劃，確定可用的測試用例。
|
|
工作內容
|
測試實施工程師根據(jù)測試計劃中分配給自己的測試任務和提供的測試用例，實施相應的測試用例，并將記錄實施用例的結果
|
|
退出標準
|
測試用例中的所有任務被執(zhí)行，結果被記錄。
|
|
責任人
|
測試實施工程師
|
圖表 6
在約定的測試周期完成之后，測試經(jīng)理需要總結此測試的結果，編寫測試報告
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試組完成了預定周期的測試任務
|
|
工作內容
|
測試經(jīng)理根據(jù)此輪測試的結果，編寫測試報告，主要應包含以下內容：
l 測試報告的版本
l 測試的人員和時間
l 測試所覆蓋的缺陷——測試組在這輪測試中所有處理的缺陷，報告了測試經(jīng)理處理的缺陷和實施工程師驗證的缺陷。不僅要寫出覆蓋缺陷的總數(shù)，還要寫明這些缺陷的去向
l 測試新發(fā)現(xiàn)的缺陷數(shù)量
l 上一版本活動缺陷的數(shù)量
l 經(jīng)過此輪測試，所有活動缺陷的數(shù)量及其狀態(tài)分類
l 測試評估——寫明在這一版本中，那些功能被實現(xiàn)了，那些還沒有實現(xiàn)，這里只需寫明和上一版本不同之處即可
l 急待解決的問題——寫明當前項目組中面臨的最優(yōu)先的問題，可以重復提出
|
|
退出標準
|
在每輪測試結束之后應盡快將符合標準的測試報告發(fā)給全項目組
|
|
責任人
|
測試經(jīng)理
|
圖表7
在每輪測試結束之后，由測試組重新拷貝修改后的最新版本，進行回歸測試。
|
過程要點
|
詳細描述
|
|
輸入條件
|
在每輪測試中，按照現(xiàn)有的測試用例沒有新的缺陷被發(fā)現(xiàn)，測試報告中全部的活動缺陷都被解決。
|
|
工作內容
|
測試組將按照測試計劃中對于回歸測試的策略對產(chǎn)品進行回歸測試，回歸測試的用例屬于測試用例的一部分或者是全部測試用例，但不能超出原先預定的測試用例的范圍。
|
|
退出標準
|
回歸測試所運行的用例全部通過。
|
|
責任人
|
測試實施工程師 （可由測試實施工程師或測試經(jīng)理兼做）
|
圖表 2
測試工作結束或即將結束時，測試組就要開始著手準備進行總結的工作。
在回歸測試結束之后，測試經(jīng)理將要編寫測試總結報告，對測試進行總結，并且提交給全體項目組，為產(chǎn)品的后續(xù)工作提供重要的信息支持。
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試組完成了所有的測試實施工作
|
|
工作內容
|
測試經(jīng)理根據(jù)測試的結果，按照測試報告的文檔模板編寫測試報告，測試報告必須包含以下重要內容：
l 測試資源概述——多少人、多長時間
l 測試結果摘要——分別描述各個測試需求的測試結果，產(chǎn)品實現(xiàn)了哪些功能點，哪些還沒有實現(xiàn)
l 缺陷分析——按照缺陷的屬性分類進行分析
l 測試需求覆蓋率——原先列舉的測試需求的測試覆蓋率，可能一部分測試需求因為資源和優(yōu)先級的因素沒有進行測試，那么在這里要進行說明
l 測試評估——從總體對項目質量進行評估
l 測試組建議——從測試組的角度為項目組提出工作建議
|
|
退出標準
|
測試經(jīng)理完成了符合標準的測試報告，發(fā)送給全項目組。
|
|
責任人
|
測試經(jīng)理
|
測試總結工作是在以上的工作全部結束以后，它的目的是評估本次測試工作，總結經(jīng)驗，使下一次的工作做得更好。
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試經(jīng)理完成了符合標準的測試報告，發(fā)送給全項目組
|
|
工作內容
|
測試經(jīng)理根據(jù)測試的結果，按照測試總結的文檔模板編寫測試總結，
|
|
退出標準
|
測試經(jīng)理完成了符合標準的測試總結，發(fā)送給全測試組。
|
|
責任人
|
測試經(jīng)理
|
3.3.3測試驗收
測試驗收工作是在以上工作全部結束后，對測試的過程，效果進行驗收，宣布測試結束。
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試組完成了所有的測試實施工作，測試經(jīng)理完成符合標準的測試總結文檔
|
|
工作內容
|
由測啟會上約定的驗收組成員，對本測試收進行驗收，驗收內容包括：
l 測試效果驗收——測試是否達到預期目的
l 測試文檔驗收——測試過程文檔是否齊全，可信，符合標準
l 測試評估——從總體對測試的質量進行評估
l 測試建議——對本次測試工作指出不足，需要在以后工作中改進的地方
l 宣布測試結束——測試驗收組成員簽字宣布本次測試結束
|
|
退出標準
|
簽發(fā)測試驗收報告
|
|
責任人
|
產(chǎn)品經(jīng)理
|
3.3.4測試歸檔
測試歸檔是在測試驗收結束宣布測試有效，結束測試后，對測試過程中涉及到各種標準文檔進行歸類，存檔。
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試驗收通過
|
|
工作內容
|
歸類，存檔測試過程涉及到的文檔，主要包括以下文檔（必須）
l 測試任務書
l 測試計劃書
l 測試用例書
l 測試報告書
l 測試總結書
l 測試驗收書
|
|
退出標準
|
全部文檔歸類完畢，版本號封存
|
|
責任人
|
測試經(jīng)理
|
3.4缺陷跟蹤
測試驗收結束后，跟蹤產(chǎn)品在試運行階段暴露出來的新缺陷，以及已提交的缺陷是否再次發(fā)生。
|
過程要點
|
詳細描述
|
|
輸入條件
|
測試組完成了所有的測試實施工作，測試驗收通過，產(chǎn)品試運行、運行。
|
|
工作內容
|
l 已發(fā)現(xiàn)缺陷是否再次發(fā)生
l 是否有新發(fā)現(xiàn)的在測試中未發(fā)現(xiàn)的缺陷
l 是否有新發(fā)現(xiàn)的在測試中已發(fā)現(xiàn)但未修改的缺陷
定義：
A類：新發(fā)現(xiàn)的缺陷
B類：已發(fā)現(xiàn)的缺陷
C類：已發(fā)現(xiàn)未修改的缺陷
|
|
退出標準
|
缺陷跟蹤報告
|
|
責任人
|
產(chǎn)品經(jīng)理、項目實施經(jīng)理
|
4缺陷類型定義
本規(guī)范定義以下五類缺陷：
Ø A類——嚴重錯誤，包括：
1. 由于程序所引起的死機,非法退出
2. 死循環(huán)
3. 導致數(shù)據(jù)庫發(fā)生死鎖
4. 數(shù)據(jù)通訊錯誤
5 嚴重的數(shù)值計算錯誤
Ø B類——較嚴重錯誤，包括：
1. 功能不符
2. 數(shù)據(jù)流錯誤
3. 程序接口錯誤
4. 輕微的數(shù)值計算錯誤
Ø C類——一般性錯誤，包括：
1. 界面錯誤(詳細文檔)
2. 打印內容、格式錯誤
3. 簡單的輸入限制未放在前臺進行控制
4. 刪除操作未給出提示
Ø D類——較小錯誤，包括：
1. 輔助說明描述不清楚
2. 顯示格式不規(guī)范
3. 長時間操作未給用戶進度提示
4. 提示窗口文字未采用行業(yè)術語
5. 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志
6. 系統(tǒng)處理未優(yōu)化
Ø E類——測試建議（非缺陷）
5測試標準
軟件測試合格須符合以下標準。
|
A類錯誤
|
B類錯誤
|
C類錯誤
|
D類錯誤
|
E類建議
|
|
無
|
無
|
≤2%
|
≤4%
|
暫不作要求
|
以上比例為錯誤占總測試模塊的比例。
軟件產(chǎn)品未經(jīng)測試合格，不允許投運。
6爭議處理
如開發(fā)團隊對測試結論有爭議，由驗收組成員會議協(xié)調解決。測試團隊和開發(fā)團隊應無條件服從仲裁結果。
7標準文檔
1. 《測試任務說明書》
2. 《測試計劃書》
3. 《測試用例說明書》
4. 《測試報告》
5. 《測試總結報告》
6. 《測試驗收報告》
7. 《缺陷跟蹤報告》
|
