1、 軟件測試工作流程規(guī)范V1.0xxxxx有限公司2017年4月20日修訂歷史記錄版本日期修訂模塊修訂者說明V1.02017.5.10文檔新建技術部目錄1.目的42.工作范圍43.工作職責44.測試流程45.測試準備65.1測試計劃65.2測試用例65.2.1測試用例設計方法75.2.2測試用例操作步驟75.2.3測試用例選擇準則75.3測試環(huán)境75.4測試數據準備76.測試執(zhí)行76.1測試準入條件76.2項目測試階段76.3測試退出標準76.4測試變更87.缺陷管理87.1BUG管理流程87.2BUG狀態(tài)87.3BUG解決方案97.4BUG優(yōu)先級97.5BUG嚴重等級97.6BUG書寫規(guī)范10

2、7.6.1測試人員BUG提交107.6.2開發(fā)人員BUG解決118.標準文檔111. 目的通過規(guī)范公司測試流程，確保測試工作的規(guī)范性和有效性，以驗證軟件產品的質量滿足用戶的需求。測試作為質量控制的一種有效手段，運行測試用例找出軟件中潛在的各種缺陷，通過協(xié)助開發(fā)人員修正缺陷來提高軟件質量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患和降低質量成本。通過測試管理為產品與過程改進提供可靠的數據分析，起到缺陷預防的作用。本過程的方針： 實施測試策劃活動 根據測試策劃所規(guī)定的要求編寫測試需求與用例，實施相關的測試活動 管理測試活動中發(fā)現的產品缺陷2. 工作范圍測試人員在軟件開發(fā)過程中的任務：1) 參

3、與評估軟件需求，編寫測試需求；2) 根據用戶需求，編寫軟件測試用例；3) 在開發(fā)人員完成單元測試后，進行模塊測試，以期盡早發(fā)現bug；4) 根據軟件測試用例，執(zhí)行集成測試，尋找盡可能多的bug；5) 對bug進行追蹤與分析，保證bug及時得到修復；6) 對軟件性能進行衡量，并進行測試總結，提交軟件測試報告書。3. 工作職責工作內容輸出文檔提交每天工時申報OA工時登記提交每周工作周報工作周報每月5號前提交上月工作考核評價表月工作考核評價表若有加班/請假/調休，在OA上走相應流程加班/請假/調休登記測試組長，測試計劃階段提交測試計劃、測試用例測試計劃、測試用例測試執(zhí)行階段提交測試報告系統(tǒng)測試報告測

4、試評估階段提交遺留問題分析報告測試遺留問題分析報告4. 測試流程需求評審產品需求人員開發(fā)人員測試人員開發(fā)人員寫開發(fā)計劃（排期）測試人員寫測試計劃（排期）郵件通知部門所有人開發(fā)代碼及自測編寫測試用例運維人員部署測試環(huán)境測試用例評審產品需求人員開發(fā)人員測試人員測試人員執(zhí)行測試開發(fā)修復測試通過測試報告驗收方案軟件上線需求分析l 需求分析需求分析由產品人員制定，細化每一個功能的細節(jié)，每一個按鈕的位置，對于稍大或復雜一點的需求都進行建模。l 需求評審所有參與項目人員進行，開發(fā)人員、測試人員、項目責任人。測試人員提出需求，開發(fā)人員考慮功能實現的方案與可行性、當然開發(fā)負責也是要參與的。測試人員主要是對需求的

5、理解提出疑問，以便才能根據需求寫用例。項目責任人是最終對軟件質量進行驗證的人，所以也需求了解需求。l 開發(fā)人員編寫排期開發(fā)人員需求根據需求功能點進行排期。然后將該計劃轉交給測試人員。l 測試計劃排期測試人員根據開發(fā)計劃，對測試擬定具體測試時間，也就是開發(fā)功能完成后的時間，進行幾輪測試等。然后，把項目的開發(fā)與測試計劃發(fā)送給各部門負責人及參與項目的所有人員。l 編寫測試用例根據詳細的需求分檔，開始進行用例的編寫。l 用例評審在用例進行評審之前，先以郵件形式將用例發(fā)送給相關人員，以便他們事先了解用例對哪些功能進行驗證以及驗證的細節(jié)。然后，測試人員組進行用例評審，開發(fā)人員對用例與實際功能不符合有哪些，

6、產品人員對會通過用例對功能的具體實現進行把握等等。l 執(zhí)行測試測試人員第一輪測試，發(fā)現的問題通過缺陷管理工具進行反饋，開發(fā)人員對問題進行修復，完成第一輪測試后，需要寫測試結論，發(fā)到相關人員。然后進行第二輪測試，第二輪會對第一輪中發(fā)現的問題進行重點回歸。l 測試通過經過兩到三輪或四輪的測試后，直到沒發(fā)現新的問題，或暫時無法解決，或不緊急的問題。通過上級確認，可以通過。編寫測試報告與驗收方案。驗收方案是交由項目責任人進行驗證的。在現公司的流程中是將測試與項目責任人分開的，測試人員重點關注的是功能是否可以正常運行。項目責任人關注的是整個流程的質量以及最終用戶的質量。5. 測試準備5.1 測試計劃根據

7、需求文檔和項目計劃制定測試計劃。測試計劃旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規(guī)范等。測試計劃在策略和方法方面說明如何計劃、組織和管理測試項目。測試計劃完成后應該在項目組內進行評審。5.2 測試用例測試用例是為實施測試而向被測試系統(tǒng)提供的輸入數據、操作或各種環(huán)境設置以及期望結果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。依據用戶需求分析說明書、概要設計文檔和開發(fā)詳細設計說明書來設計測試用例，發(fā)現需求與設計中的問題后，與需求者及時溝通確認。5.2.1 測試用例設計方法測試用例的設計方法有等價類測試、邊界值分析、基于判定表的測試、基于因果圖的測試、基于狀態(tài)圖的測試、

8、基于場景的測試。在設計測試用例時常用的設計方法有等價類測試、邊界值分析兩種方法。5.2.2 測試用例操作步驟1) 在設計編寫測試用例時，首先要從測試用例庫中選擇相應功能的測試用例，在原有測試用例的基礎上依據系統(tǒng)需求文檔對測試用例的進行修改、更新，評審通過后將使用該測試用例測試被測系統(tǒng)。2) 在測試的執(zhí)行過程中和進行回歸測試后，對已設計的測試用例進行維護更新。5.2.3 測試用例選擇準則 測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數據、操作和環(huán)境設置等； 測試結果的可判定性：即測試執(zhí)行結果的正確性是可判定的或可評估的； 測試結果的可再現性：即對同樣

9、的測試用例,系統(tǒng)的執(zhí)行結果應當是相同的。5.3 測試環(huán)境根據需求文檔提供的內容，和開發(fā)部溝通確定測試項目所需的軟硬件環(huán)境，完成對測試項目所需軟硬件資源的準備工作，使軟硬件資源得到滿足。5.4 測試數據準備完成對測試項目基本數據的準備操作，包括數據庫連接、用戶信息、用戶角色權限、單位組織等信息和測試相關的測試數據。6. 測試執(zhí)行6.1 測試準入條件1) 不接受無詳細需求文檔和開發(fā)說明的項目；2) 需要測試的項目至少提前2個工作日提交測試進行需求分析；3) 開發(fā)人員經過自測通過，至少保證程序可以正常運行；對應的功能在正常流程下是可以正常使用。6.2 項目測試階段測試人員依據測試計劃和測試用例進行測

10、試活動。測試一般分為兩個階段：1) 測試執(zhí)行階段：該階段測試人員測試出bug后將缺陷提交至缺陷管理庫。2) 回歸階段：開發(fā)修改完bug之后，測試進行驗證回歸。6.3 測試退出標準1) 全部的測試用例執(zhí)行完畢；2) 按照系統(tǒng)測試計劃完成了系統(tǒng)測試，系統(tǒng)測試的功能覆蓋率達100；3) 系統(tǒng)的功能和性能滿足產品需求規(guī)格說明書的要求；4) 在系統(tǒng)測試中發(fā)現的錯誤已經得到修改并且各級缺陷修復率達到標準；5) 系統(tǒng)測試后不存在1、2類缺陷；6) 3類缺陷允許存在，不超過總缺陷的10。6.4 測試變更當需求變更，功能變化，測試人員根據變更情況，評估測試變更所需時間，提出變更風險。如變更情況被項目組通過，測試

11、人員將按上述流程進行變更測試。7. 缺陷管理7.1 BUG管理流程重新打開（Reopen）提交BUG（New）確認BUG修復BUG關閉BUG（Closed）是否延期BUG驗證保留BUGYNYNNY7.2 BUG狀態(tài)l 激活1) 新創(chuàng)建的bug；2) 已解決但驗證未通過的bug；3) 已關閉的bug重新出現需要再次激活。l 已解決開發(fā)已經修改完成的bug。l 關閉已驗證通過的bug或系統(tǒng)工程師確認轉為需求的bug。7.3 BUG解決方案l 已解決Bug已經被修改，待測試進行驗證。l 設計如此測試人員理解錯誤，無需改動，即無效bug。l 重復bug已經有同樣的bug，需標明重復bug號。l 無法重

12、現根據測試寫的重現步驟，無法重現bug。l 延期處理確實是bug，但現在不解決，以后處理。l 新增/變更需求分析確實是存在問題，但需求沒有描述清晰，應指派給需求確認，進行需求的新增或變更。7.4 BUG優(yōu)先級l 高阻止與此密切相關功能的進一步測試，需要立即修復。l 中必須修改，不一定馬上修改，必須修改，發(fā)版前必須修正。l 低對系統(tǒng)的影響較小，如果時間允許應該修改。7.5 BUG嚴重等級l 嚴重（一類）不能執(zhí)行正常工作功能或重要功能，因軟件原因導致系統(tǒng)死機等，須馬上修正致命錯誤。通常有如下情況：1) 系統(tǒng)停機（含軟件、硬件）或非法退出，且無法通過重啟恢復；2) 系統(tǒng)死循環(huán)；3) 與數據庫連接錯誤

13、；4) 數據庫發(fā)生死鎖或程序原因導致數據庫斷連；5) 數據通訊錯誤或接口不通；6) 重要功能無法正常使用、功能不符合用戶需求。l 一般（二類）影響系統(tǒng)功能或操作，應用模塊錯誤使業(yè)務中止無法進行后續(xù)操作，主要功能存在嚴重缺陷，影響到產品的使用，但不會影響到系統(tǒng)穩(wěn)定性。具體基本上可分為：1) 業(yè)務流程錯誤或不完整；2) 業(yè)務數據來源不正確、業(yè)務數據紊亂或丟失；3) 業(yè)務數據保存不完整或無法保存到數據庫；4) 部分功能使用存在問題，不影響業(yè)務繼續(xù)開展，但造成使用障礙；5) 初始化未滿足客戶要求或初始化錯誤；6) 功能點能實現，但結果錯誤；7) 缺少數據有效性檢查或檢查不合理；8) 刪除操作不給提示；

14、 9) 日志記錄信息不正確或應記錄而未記錄；10) 數據庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件；11) 在產品聲明支持的不同平臺下，出現部分一般交易無法使用或錯誤；12) 系統(tǒng)某些查詢、打印等實時性要求不高的輔助功能無法正常使用。l 輕微（三類）使操作者不合理或者不方便或操作遇到麻煩，但它不影響執(zhí)行工作功能或重要功能，次要功能，對產品使用影響不大。例如：程序在一些顯示上不美觀，不符合用戶習慣，或是一些文字的錯誤。具體基本上可分為：1) 缺少產品使用、幫助文檔、系統(tǒng)安裝或配置方面需要信息；2) 聯(lián)機幫助、脫機手冊與實際系統(tǒng)不匹配；3) 系統(tǒng)版本說明不正確；4) 提示說明未采用行業(yè)規(guī)范語言；

15、5) 顯示格式不規(guī)范；6) 界面不整齊；7) 軟件界面、菜單位置、工具條位置、相應提示不美觀，但不影響使用；8) 輔助說明描述不清楚；9) 提示窗口描述清楚；10) 輸入輸出不規(guī)范；11) 可輸入區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志。l 建議（四類）7.6 BUG書寫規(guī)范7.6.1 測試人員BUG提交1) 主題 用一個簡短的句子描述問題，不要寫成一大段 以進入問題模塊路徑開頭，方便項目經理分派任務，以及開發(fā)人員定位問題 描述問題時要詳細、簡練、抓住要點，直接切入正題，不要羅嗦 不要夸大或縮小問題的嚴重程度2) 步驟 用數字編號，一步步的描述重現問題的所有操作步驟 提供明確的再現問題的步驟，避免問題

16、被以“不能重現”關掉 設置區(qū)域需要詳細描述，如：各設置項值為默認、*值更改為“”，其他設置項值為默認 盡量用動詞作為開頭，描述每個步驟。如：打開、點擊、設置、選擇、插入、雙擊等 不要在一個步驟中描述不相關的多個操作。如果是相關的一系列操作，可以使用“”來連接描述 按照你寫的步驟去執(zhí)行，看問題能否重現 不要在步驟中使用含糊不清的縮寫詞描述3) 實際結果 實際只描述一個問題 同樣的操作步驟產生多種現象，要在一個缺陷報告中加以描述 不同的操作步驟產生不同的問題，分別報bug 如果有截圖，請列出所附的圖片信息4) 預期結果 不要加入實際結果的描述信息 描述要清晰，不要使用含糊不清的縮寫詞描述 如果有截圖，請列出所附的圖片信息5) 備注 避免寫成大段落，要寫得簡單、易讀 問題的特征 出現問題后的解決方法 對終