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

機密 第11頁共11頁 DATE5/9/2017軟件測試工作流程規(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.1 BUG管理流程 87.2 BUG狀態(tài) 87.3 BUG解決方案 97.4 BUG優(yōu)先級 97.5 BUG嚴重等級 97.6 BUG書寫規(guī)范 107.6.1 測試人員BUG提交 107.6.2 開發(fā)人員BUG解決 118. 標準文檔 11

目的通過規(guī)范公司測試流程，確保測試工作的規(guī)范性和有效性，以驗證軟件產品的質量滿足用戶的需求。

測試作為質量控制的一種有效手段，運行測試用例找出軟件中潛在的各種缺陷，通過協助開發(fā)人員修正缺陷來提高軟件質量，回避軟件發(fā)布后由于潛在的軟件缺陷和錯誤造成的隱患和降低質量成本。通過測試管理為產品與過程改進提供可靠的數據分析，起到缺陷預防的作用。

本過程的方針：實施測試策劃活動

根據測試策劃所規(guī)定的要求編寫測試需求與用例，實施相關的測試活動

管理測試活動中發(fā)現的產品缺陷工作范圍測試人員在軟件開發(fā)過程中的任務：

參與評估軟件需求，編寫測試需求；根據用戶需求，編寫軟件測試用例；在開發(fā)人員完成單元測試后，進行模塊測試，以期盡早發(fā)現bug；根據軟件測試用例，執(zhí)行集成測試，尋找盡可能多的bug；

對bug進行追蹤與分析，保證bug及時得到修復；對軟件性能進行衡量，并進行測試總結，提交軟件測試報告書。工作職責工作內容輸出文檔提交每天工時申報OA工時登記提交每周工作周報工作周報每月5號前提交上月工作考核評價表月工作考核評價表若有加班/請假/調休，在OA上走相應流程加班/請假/調休登記測試組長，測試計劃階段提交測試計劃、測試用例測試計劃、測試用例測試執(zhí)行階段提交測試報告系統測試報告測試評估階段提交遺留問題分析報告測試遺留問題分析報告測試流程需求需求評審產品需求人員開發(fā)人員測試人員開發(fā)人員寫開發(fā)計劃（排期）測試人員寫測試計劃（排期）郵件通知部門所有人開發(fā)代碼及自測編寫測試用例運維人員部署測試環(huán)境測試用例評審產品需求人員開發(fā)人員測試人員測試人員執(zhí)行測試開發(fā)修復測試通過測試報告驗收方案軟件上線需求分析需求分析需求分析由產品人員制定，細化每一個功能的細節(jié)，每一個按鈕的位置，對于稍大或復雜一點的需求都進行建模。需求評審所有參與項目人員進行，開發(fā)人員、測試人員、項目責任人。測試人員提出需求，開發(fā)人員考慮功能實現的方案與可行性、當然開發(fā)負責也是要參與的。測試人員主要是對需求的理解提出疑問，以便才能根據需求寫用例。項目責任人是最終對軟件質量進行驗證的人，所以也需求了解需求。開發(fā)人員編寫排期開發(fā)人員需求根據需求功能點進行排期。然后將該計劃轉交給測試人員。測試計劃排期測試人員根據開發(fā)計劃，對測試擬定具體測試時間，也就是開發(fā)功能完成后的時間，進行幾輪測試等。然后，把項目的開發(fā)與測試計劃發(fā)送給各部門負責人及參與項目的所有人員。編寫測試用例根據詳細的需求分檔，開始進行用例的編寫。用例評審在用例進行評審之前，先以郵件形式將用例發(fā)送給相關人員，以便他們事先了解用例對哪些功能進行驗證以及驗證的細節(jié)。然后，測試人員組進行用例評審，開發(fā)人員對用例與實際功能不符合有哪些，產品人員對會通過用例對功能的具體實現進行把握等等。執(zhí)行測試測試人員第一輪測試，發(fā)現的問題通過缺陷管理工具進行反饋，開發(fā)人員對問題進行修復，完成第一輪測試后，需要寫測試結論，發(fā)到相關人員。然后進行第二輪測試，第二輪會對第一輪中發(fā)現的問題進行重點回歸。測試通過經過兩到三輪或四輪的測試后，直到沒發(fā)現新的問題，或暫時無法解決，或不緊急的問題。通過上級確認，可以通過。編寫測試報告與驗收方案。驗收方案是交由項目責任人進行驗證的。在現公司的流程中是將測試與項目責任人分開的，測試人員重點關注的是功能是否可以正常運行。項目責任人關注的是整個流程的質量以及最終用戶的質量。測試準備測試計劃根據需求文檔和項目計劃制定測試計劃。測試計劃旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規(guī)范等。測試計劃在策略和方法方面說明如何計劃、組織和管理測試項目。測試計劃完成后應該在項目組內進行評審。測試用例測試用例是為實施測試而向被測試系統提供的輸入數據、操作或各種環(huán)境設置以及期望結果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。

依據用戶需求分析說明書、概要設計文檔和開發(fā)詳細設計說明書來設計測試用例，發(fā)現需求與設計中的問題后，與需求者及時溝通確認。測試用例設計方法

測試用例的設計方法有等價類測試、邊界值分析、基于判定表的測試、基于因果圖的測試、基于狀態(tài)圖的測試、基于場景的測試。

在設計測試用例時常用的設計方法有等價類測試、邊界值分析兩種方法。測試用例操作步驟

在設計編寫測試用例時，首先要從測試用例庫中選擇相應功能的測試用例，在原有測試用例的基礎上依據系統需求文檔對測試用例的進行修改、更新，評審通過后將使用該測試用例測試被測系統。

在測試的執(zhí)行過程中和進行回歸測試后，對已設計的測試用例進行維護更新。測試用例選擇準則

測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數據、操作和環(huán)境設置等；

測試結果的可判定性：即測試執(zhí)行結果的正確性是可判定的或可評估的；

測試結果的可再現性：即對同樣的測試用例,系統的執(zhí)行結果應當是相同的。測試環(huán)境

根據需求文檔提供的內容，和開發(fā)部溝通確定測試項目所需的軟硬件環(huán)境，完成對測試項目所需軟硬件資源的準備工作，使軟硬件資源得到滿足。

測試數據準備

完成對測試項目基本數據的準備操作，包括數據庫連接、用戶信息、用戶角色權限、單位組織等信息和測試相關的測試數據。測試執(zhí)行測試準入條件

不接受無詳細需求文檔和開發(fā)說明的項目；需要測試的項目至少提前2個工作日提交測試進行需求分析

；開發(fā)人員經過自測通過，至少保證程序可以正常運行；對應的功能在正常流程下是可以正常使用。項目測試階段

測試人員依據測試計劃和測試用例進行測試活動。

測試一般分為兩個階段：

測試執(zhí)行階段：該階段測試人員測試出bug后將缺陷提交至缺陷管理庫。回歸階段：開發(fā)修改完bug之后，測試進行驗證回歸。

測試退出標準

全部的測試用例執(zhí)行完畢；按照系統測試計劃完成了系統測試，系統測試的功能覆蓋率達100％；系統的功能和性能滿足產品需求規(guī)格說明書的要求；在系統測試中發(fā)現的錯誤已經得到修改并且各級缺陷修復率達到標準；系統測試后不存在1、2類缺陷；3類缺陷允許存在，不超過總缺陷的10％。測試變更當需求變更，功能變化，測試人員根據變更情況，評估測試變更所需時間，提出變更風險。如變更情況被項目組通過，測試人員將按上述流程進行變更測試。缺陷管理BUG管理流程重新打開（Reopen）提交BUG（New重新打開（Reopen）提交BUG（New）確認BUG修復BUG關閉BUG（Closed）是否延期BUG驗證保留BUGYNYNNYBUG狀態(tài)激活

新創(chuàng)建的bug；

已解決但驗證未通過的bug；已關閉的bug重新出現需要再次激活

。

已解決

開發(fā)已經修改完成的bug。

關閉

已驗證通過的bug或系統工程師確認轉為需求的bug。BUG解決方案已解決

Bug已經被修改，待測試進行驗證。設計如此

測試人員理解錯誤，無需改動，即無效bug。重復bug

已經有同樣的bug，需標明重復bug號。

無法重現

根據測試寫的重現步驟，無法重現bug。

延期處理

確實是bug，但現在不解決，以后處理。

新增/變更需求

分析確實是存在問題，但需求沒有描述清晰，應指派給需求確認，進行需求的新增或變更。BUG優(yōu)先級高阻止與此密切相關功能的進一步測試，需要立即修復。中

必須修改，不一定馬上修改，必須修改，發(fā)版前必須修正。低

對系統的影響較小，如果時間允許應該修改。BUG嚴重等級嚴重（一類）不能執(zhí)行正常工作功能或重要功能，因軟件原因導致系統死機等，須馬上修正致命錯誤。通常有如下情況：系統停機（含軟件、硬件）或非法退出，且無法通過重啟恢復；系統死循環(huán)；與數據庫連接錯誤；數據庫發(fā)生死鎖或程序原因導致數據庫斷連；數據通訊錯誤或接口不通；重要功能無法正常使用、功能不符合用戶需求。一般（二類）影響系統功能或操作，應用模塊錯誤使業(yè)務中止無法進行后續(xù)操作，主要功能存在嚴重缺陷，影響到產品的使用，但不會影響到系統穩(wěn)定性。具體基本上可分為：業(yè)務流程錯誤或不完整；業(yè)務數據來源不正確、業(yè)務數據紊亂或丟失；業(yè)務數據保存不完整或無法保存到數據庫；部分功能使用存在問題，不影響業(yè)務繼續(xù)開展，但造成使用障礙；初始化未滿足客戶要求或初始化錯誤；功能點能實現，但結果錯誤；缺少數據有效性檢查或檢查不合理；刪除操作不給提示；日志記錄信息不正確或應記錄而未記錄；數據庫的表、業(yè)務規(guī)則、缺省值未加完整性等約束條件；在產品聲明支持的不同平臺下，出現部分一般交易無法使用或錯誤；系統某些查詢、打印等實時性要求不高的輔助功能無法正常使用。輕微（三類）使操作者不合理或者不方便或操作遇到麻煩，但它不影響執(zhí)行工作功能或重要功能，次要功能，對產品使用影響不大。例如：程序在一些顯示上不美觀，不符合用戶習慣，或是一些文字的錯誤。

具體基本上可分為：缺少產品使用、幫助文檔、系統安裝或配置方面需要信息；聯機幫助、脫機手冊與實際系統不匹配；系統版本說明不正確；提示說明未采用行業(yè)規(guī)范語言；顯示格式不規(guī)范；界面不整齊；軟件界面、菜單位置、工具條位置、相應提示不美觀，但不影響使用；輔助說明描述不清楚；提示窗口描述清楚；輸入輸出不規(guī)范；可輸入區(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志。建議（四類）BUG書寫規(guī)范測試人員BUG提交

主題用一個簡短的句子描述問題，不要寫成一大段以進入問題模塊路徑開頭，方便項目經理分派任務，以及開發(fā)人員定位問題描述問題時要詳細、簡練、抓住要點，直接切入正題，不要羅嗦不要夸大或縮小問題的嚴重程度步驟

用數字編號，一步步的描述重現問題的所有操作步驟提供明確的再現問題的步驟，避免問題被以“不能重現”關掉

設置區(qū)域需要詳細描述，如：各設置項值為默認、**值更改為“”，其他設置項值為默認

盡量用動詞作為開頭，描述每個步驟。如：打開、點擊、設置、選擇、插入、雙擊等不要在一個步驟中描述不相關的多個操作。如果是相關的一系列操作，可以使用“→”來連接描述按照你寫的步驟去執(zhí)行，看問題能否重現不要在步驟中使用含糊不清的縮寫詞描述

實際結果

實際只描述一個問題

同樣的操作步驟產生多種現象，要在一個缺陷報告中加以描述不同的操作步驟產生不同的問題，分別報bug如果有截圖，請列出所附的圖片信息預期結果

不要加入實際結果的描述信息描述要清晰，不要使用含糊不清的縮寫詞描述如果有截圖，請列出所附的圖片信息備注