測試工作流程規(guī)范

測試工作流程規(guī)范Flex組測試組人員構成角色姓名職責備注測試組長監(jiān)管整個測試流程，做測試計劃，安排測試人員測試，保證相關文檔入庫，定期對測試工作進行總結測試人員測試項目、產品，進行問題跟蹤，及

時反饋與匯報測試結果；編寫項目/產品bug匯總表、項目/產品

測試報告；編寫或者輔助需求設計人員編寫項目

測試用例。測試人員測試人員測試人員測試人員學科負責人測試組長測試人員項目負責人提出測試申請測試任務計劃接收測試任務提前提交送測單、項目相關文檔對項目進行測試填寫bug匯總表、測試報告反饋測試結果審核測試結果安排人員修改并申請復測時間修改問題完善項目回歸測試存在問題測試任務計劃與安排測試任務完成相關文檔入庫總結測試工作是否計劃與啟動階段（1）測試原有項目學科負責人與項目負責人確定項目完善時間；學科負責人向測試組長提出測試申請，在《測試組任務計劃表》里追加新的測試任務，填寫學科、送測項目名稱、提出申請日期、期望測試日期、項目負責人、是否提交送測單；測試組長根據當前測試組的資源情況與提出申請的項目檢測任務的緊急情況，做測試計劃，填寫《測試組任務計劃表》里測試人、計劃測試時間，并通知測試人員；根據項目規(guī)模測試人員在計劃測試時間之前主動找項目負責人要項目相關文檔；項目負責人對項目進行送測前檢查，檢查通過后填寫送測單，寫明需要測試內容與目前功能實現情況；項目負責人將送測單提交給學科負責人，審核通過后提交給測試人員，啟動測試。計劃與啟動階段（2）測試新項目項目立項通過后，學科負責人通知測試組長，確定需求分析完成時間；測試組長根據項目需求分析完成時間安排測試人員跟蹤項目；測試人員適當參與項目的需求討論會，了解整個項目的需求設計；需求明確無異議，且項目負責人將《需求規(guī)格說明書》完成后，測試人員熟讀《需求規(guī)格說明書》；測試人員與項目負責人共同完成項目測試用例的設計；項目負責人對項目進行詳細設計，完成項目的開發(fā)；接著(1)測試原有項目的流程執(zhí)行。實施測試階段測試人員與項目負責人確認送測單、送測項目最新模塊、送測項目最新代碼、配套的項目相關文檔與資源均已提交；項目負責人不提交送測單或者送測單填寫不符合規(guī)范，測試人員可以拒絕檢測該項目；送測項目最新模塊、送測項目最新代碼未提交，或者提供的項目相關文檔不完整影響測試，測試人員也可以拒絕檢測該項目；測試人員根據送測單需要測試的內容，按照測試計劃時間對項目進行測試；對于原有項目，沒有對應的測試用例，測試人員按照送測單需要測試的內容進行集成測試；對于有測試用例的新項目，執(zhí)行測試用例進行測試；測試過程中，將缺陷記錄在《項目bug匯總表》中，測試完畢填寫測試概況，填寫bug總數、嚴重bug數量、一般bug數量、較小bug數量；實施測試階段測試人員將《項目bug匯總表》提交給學科負責人，學科負責人審核后填寫有效bug數量、無效bug數量，簽字確認后提交給項目經理，項目經理了解情況后簽字；測試人員根據《項目bug匯總表》的實際情況，將有效bug統(tǒng)一提交到wiki上，并填寫《項目測試報告》，對測試情況進行總結，對缺陷進行客觀的分析；《項目測試報告》提交給測試組長進行書寫規(guī)范審核，確定符合規(guī)范后將報告提交給項目經理審核簽字；根據《項目bug匯總表》記錄的缺陷，學科負責人與項目負責人確定項目完善時間，做修改計劃；學科負責人根據項目完善時間向測試組長提出項目復測申請，測試組長根據實際情況安排測試任務，盡量安排原測試人對項目進行復測；實施測試階段測試人員與項目負責人確認復測項目最新模塊、最新代碼、最新的項目相關文檔與資源均已提交；測試人員對項目進行回歸測試，對《項目bug匯總表》原有缺陷狀態(tài)進行修改，將回歸測試中發(fā)現的新缺陷追加到《項目bug匯總表》中，并且填寫復測的概況；回歸測試完畢后，《項目bug匯總表》提交給學科負責人填寫新增的有效bug數量，簽字確認，項目經理簽字確認；測試人員將復測情況追加到《項目測試報告》中，重新提交給測試組長檢查，提交給項目經理審核簽字；如果項目復測還存在缺陷則進入下一輪的復測流程中，直到測試發(fā)現的項目缺陷已經修改完畢或者確定剩余缺陷不影響產品質量，測試工作完成?？偨Y階段測試組長最終驗收確認《項目bug匯總表》、《項目測試報告》，與項目相關的需要備份的文檔資料全部提交到svn入庫；測試組長根據測試計劃與實際執(zhí)行情況，與測試人員進行溝通，并做測試工作的總結；項目測試情況與測試工作進行情況匯報給項目經理，項目通過驗收，測試工作全部完成；測試組長召開測試工作總結會，對測試工作進行評估與建議，對過程不斷進行改進。缺陷管理bug狀態(tài)分為5種狀態(tài)：新建；進行中；已解決；已拒絕；已關閉。缺陷管理流程由測試人員發(fā)現bug后，新建bug，bug的狀態(tài)設置為“新建”；測試人員直接把bug指派到相應的管理者（一般是由測試組長、學科負責人等人參與bug分配），確定bug為非有效缺陷，管理者那里就直接將bug的狀態(tài)設置為“已拒絕”；bug經過相應的管理者分配，該bug轉移給相應的開發(fā)人員，bug狀態(tài)的狀態(tài)設置為“進行中；開發(fā)人員對bug進行修復，對已經修復完的bug，其狀態(tài)為“已解決”；測試人員在做bug復測時，對已經修復完的bug，其狀態(tài)設置為“已關閉”；如果bug仍然存在，則將開發(fā)人員設置的bug狀態(tài)“已解決”修改為“新建”；如果bug修復導致了新的bug，那么就創(chuàng)建新的bug，將其狀態(tài)設置為“新建”；經過復測，確認bug修復驗證完畢，bug狀態(tài)設置為“已關閉”。程度等級Bug等級說明分類說明修改優(yōu)先級嚴重問題7導致整個產品無法進行測試。該級別需要程序員立即修改模塊無法加載或者啟動立刻系統(tǒng)無法啟動或者異常退出其它導致無法測試的錯誤6死機，數據丟失，主要功能完全喪失，性能差等錯誤。該級別需要程序員立即修改運行過程中系統(tǒng)崩潰/死機/重啟立刻數據無法存儲與讀取，保存、打開文件，導出exe、打開exe存在序列化問題功能設計與需求嚴重不符內存泄露數據丟失或者不正確，無法連接服務器嚴重的數值計算錯誤5主要功能喪失，導致嚴重的問題，或致命的錯誤聲明。該級別需要程序員盡快修改功能未實現或者存在錯誤緊急較小的數值計算錯誤系統(tǒng)所提供的功能或服務受明顯的影響用戶數據丟失或破壞一般問題4次要功能喪失，不太嚴重，如提示信息不太準確。該級別需要程序員修改操作界面錯誤（包括數據窗口內列名定義、含義是否一致）高邊界條件下錯誤（如輸入邊界值導致的錯誤）功能存在錯誤，但出現概率很低提示信息錯誤（包括未給出信息、信息提示錯誤等）長時間操作讓用戶等待確無進度提示系統(tǒng)未優(yōu)化（性能問題）3較小的問題，對功能幾乎沒有影響，產品及屬性仍可使用。修改優(yōu)先級為低，該級別需要程序員修改界面格式等不規(guī)范中操作時未給用戶提示文字排列不整齊等一些小問題光標跳轉設置不好，鼠標（光標）定位錯誤輕微問題2違背正常習慣，界面不美觀，控件排列、格式不統(tǒng)一，該級別需要程序員修改或不修改輔助說明描述不清楚普通個別不影響產品理解的錯別字可輸入區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志提示信息格式不符合要求建議1功能性建議，功能使用性、方便性、易用性不夠建議低測試用例設計設計依據：需求規(guī)格說明書項目測試需求功能點所屬行業(yè)的業(yè)務知識掌握程度測試工程師本人的理解程度（個人經驗）測試用例設計編號規(guī)則：以“項目標識”+“模塊標識”+“子功能模塊序號”來定義用例ID；項目標識為項目源碼包的名稱（英文），模塊標識為功能模塊的主要類名，子功能模塊序號為需求規(guī)格說明書里該子功能在功能模塊的子節(jié)點序號；各項目源碼包、模塊類名均遵循編碼規(guī)范命名；舉例：初中物理光學項目用例ID：Optics_OpticsCalculate_01。理想畫板_鏡面反射_01測試用例內容用例ID

模塊標識

開發(fā)人員

用例作者

設計日期

測試人員

測試日期

預置條件

步驟操作描述（輸入數據說明）預期結果實際結果1.

2.

3.

4.

5.

測試結果

用例設計步驟測試需求分析：從軟件需求分析文檔中，找出待測軟件/模塊的需求，通過自己的分析、理解，整理成為測試需求，要清楚被測對象具體包含哪些功能點；

業(yè)務流程分析：對項目相關的業(yè)務知識、學科知識要熟悉，然后對被測軟件/模塊的業(yè)務流程要進行全盤的整理出來（可畫簡單的流程圖作為參考），主要包含該業(yè)務流程的主流程、備選流程、數據流向、關鍵判斷條件以及完成該操作的非必要條件；

測試用例設計：測試用例設計的類型主要包括功能測試、邊界測試、異常測試、性能測試、壓力測試等，在設計用例時要盡量考慮邊界、異常等情況；

用例設計步驟測試用例評審：由測試用例設計者發(fā)起，參加的人員需包括測試負責人、學科負責人、開發(fā)人員及其他相關的測試人員；測試用例完善：測試用例編寫完成之后需不斷完善，軟件產品新增功能或更新需求后，測試用例必須配套修改更新；在測試過程中發(fā)現設計測試用例時考慮不周，需要對測試用例進行修改完善；在軟件交付使用后客戶反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成，也需要對測試用例進行完善。用例評審用例設計的結構安排是否清晰合理，是否高效的需求進行覆蓋；用例的優(yōu)先級別是否安排合理；是否覆蓋了測試需求的所有功能點，包括需求中的業(yè)務規(guī)則、所有用戶可能使用的流程或等；用例是否有很好的可執(zhí)行性。例如用例的預置條件、執(zhí)行步驟、輸入數據和期待結果是否清晰、正確；是否已經刪除了冗余的測試用例；是否簡潔、復用性強；是否易于管理。用例編寫標準制訂統(tǒng)一的模板進行，并約定模板的使用方法；根據項目實際情況，編寫測試用例編寫規(guī)則，包括用例編號規(guī)則、用例編寫步驟、用例編寫內容、用例維護等內容；根據規(guī)則中約定的編寫方法、內容等進行編寫；用例編寫要步驟明確，輸入輸出要素清晰，并且與需求和缺陷相對應；應嚴格根據需求規(guī)格說明書及測試需求功能分析點進行，要求覆蓋全部需求功能點；注重用例的可復用性，即在以后相似系統(tǒng)的測試過程中