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

1、軟件測試工作流程規(guī)V1.0xxxxx2021 年 4 月 20 日修訂歷史記錄版本日期修訂模塊修訂者說明V1.02021.5.10文檔新建技術(shù)部目錄1目的32工作圍33工作職責(zé)34測試流程35測試準備55.1測試方案55.2測試用例5521測試用例設(shè)計方法 6522測試用例操作步驟 6523測試用例選擇準那么65.3測試環(huán)境65.4測試數(shù)據(jù)準備66. 測試執(zhí)行66.1測試準入條件66.2工程測試階段66.3測試退出標準66.4測試變更77. 缺陷管理77.1BUG管理流程77.2BUG 狀態(tài) 77.3BUG解決方案77.4BUG優(yōu)先級87.5BUG嚴重等級87.6BUG書寫規(guī)9測試人員BUG提

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

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

4、報告4. 測試流程需求分析需求分析由產(chǎn)品人員制定，細化每一個功能的細節(jié)，每一個按鈕的位置，對于稍大或復(fù)雜一點的需求都進展建模。需求評審所有參與工程人員進展，開發(fā)人員、測試人員、工程責(zé)任人。測試人員提出需求，開發(fā)人員考慮功能實 現(xiàn)的方案與可行性、當(dāng)然開發(fā)負責(zé)也是要參與的。測試人員主要是對需求的理解提出疑問，以便才能根據(jù)需 求寫用例。工程責(zé)任人是最終對軟件質(zhì)量進展驗證的人，所以也需求了解需求。開發(fā)人員編寫排期開發(fā)人員需求根據(jù)需求功能點進展排期。然后將該方案轉(zhuǎn)交給測試人員。測試方案排期測試人員根據(jù)開發(fā)方案，對測試擬定具體測試時間，也就是開發(fā)功能完成后的時間，進展幾輪測試等。 然后，把工程的開發(fā)與測試

5、方案發(fā)送給各部門負責(zé)人與參與工程的所有人員。編寫測試用例根據(jù)詳細的需求分檔，開始進展用例的編寫。用例評審在用例進展評審之前，先以形式將用例發(fā)送給相關(guān)人員，以便他們事先了解用例對哪些功能進展驗證以 與驗證的細節(jié)。然后，測試人員組進展用例評審，開發(fā)人員對用例與實際功能不符合有哪些，產(chǎn)品人員對會通過用例對 功能的具體實現(xiàn)進展把握等等。執(zhí)行測試測試人員第一輪測試，發(fā)現(xiàn)的問題通過缺陷管理工具進展反響，開發(fā)人員對問題進展修復(fù)，完成第一輪 測試后，需要寫測試結(jié)論，發(fā)到相關(guān)人員。然后進展第二輪測試，第二輪會對第一輪中發(fā)現(xiàn)的問題進展重點 回歸。測試通過經(jīng)過兩到三輪或四輪的測試后，直到?jīng)]發(fā)現(xiàn)新的問題，或暫時無法解

6、決，或不緊急的問題。通過上級確 認，可以通過。編寫測試報告與驗收方案。驗收方案是交由工程責(zé)任人進展驗證的。在現(xiàn)公司的流程中是將測試與工程責(zé)任人分開的，測試人員重 點關(guān)注的是功能是否可以正常運行。工程責(zé)任人關(guān)注的是整個流程的質(zhì)量以與最終用戶的質(zhì)量。5. 測試準備5.1測試方案根據(jù)需求文檔和工程方案制定測試方案。測試方案旨在說明各測試階段任務(wù)、人員分配、時間安排、測 試要點、工作規(guī)等。測試方案在策略和方法方面說明如何方案、組織和管理測試工程。測試方案完成后應(yīng)該 在工程組進展評審。5.2測試用例測試用例是為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以與期望結(jié)果的一個特定 的集合。解決要

7、測什么、怎么測和如何衡量的問題。依據(jù)用戶需求分析說明書、概要設(shè)計文檔和開發(fā)詳細設(shè)計說明書來設(shè)計測試用例，發(fā)現(xiàn)需求與設(shè)計中的 問題后，與需求者與時溝通確認。5.2.1 測試用例設(shè)計方法 測試用例的設(shè)計方法有等價類測試、邊界值分析、基于判定表的測試、基于因果圖的測試、基于狀態(tài)圖 的測試、基于場景的測試。在設(shè)計測試用例時常用的設(shè)計方法有等價類測試、邊界值分析兩種方法。5.2.2 測試用例操作步驟1) 在設(shè)計編寫測試用例時，首先要從測試用例庫中選擇相應(yīng)功能的測試用例，在原有測試用例的根底 上依據(jù)系統(tǒng)需求文檔對測試用例的進展修改、更新，評審?fù)ㄟ^后將使用該測試用例測試被測系統(tǒng)。2) 在測試的執(zhí)行過程中和進

8、展回歸測試后，對已設(shè)計的測試用例進展維護更新。5.2.3 測試用例選擇準那么? 測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以與極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等；? 測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定的或可評估的；? 測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例, 系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是一樣的。5.3 測試環(huán)境 根據(jù)需求文檔提供的容，和開發(fā)部溝通確定測試工程所需的軟硬件環(huán)境，完成對測試工程所需軟硬件資 源的準備工作，使軟硬件資源得到滿足。5.4 測試數(shù)據(jù)準備 完成對測試工程根本數(shù)據(jù)的準備操作，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權(quán)限、單位組織等信息和 測試

9、相關(guān)的測試數(shù)據(jù)。6. 測試執(zhí)行6.1 測試準入條件1) 不承受無詳細需求文檔和開發(fā)說明的工程；2) 需要測試的工程至少提前 2 個工作日提交測試進展需求分析 ；3) 開發(fā)人員經(jīng)過自測通過，至少保證程序可以正常運行；對應(yīng)的功能在正常流程下是可以正常使用。6.2 工程測試階段測試人員依據(jù)測試方案和測試用例進展測試活動。 測試一般分為兩個階段：1) 測試執(zhí)行階段：該階段測試人員測試出bug 后將缺陷提交至缺陷管理庫。2) 回歸階段：開發(fā)修改完 bug 之后，測試進展驗證回歸。6.3 測試退出標準1) 全部的測試用例執(zhí)行完畢；2) 按照系統(tǒng)測試方案完成了系統(tǒng)測試，系統(tǒng)測試的功能覆蓋率達100；3) 系

10、統(tǒng)的功能和性能滿足產(chǎn)品需求規(guī)格說明書的要求；4) 在系統(tǒng)測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改并且各級缺陷修復(fù)率到達標準；5) 系統(tǒng)測試后不存在 1、 2 類缺陷；6) 3 類缺陷允許存在，不超過總?cè)毕莸?10。6.4測試變更當(dāng)需求變更，功能變化，測試人員根據(jù)變更情況，評估測試變更所需時間，提出變更風(fēng)險。如變更情況 被工程組通過，測試人員將按上述流程進展變更測試。7. 缺陷管理7.1 BUG管理流程7.2 BUG狀態(tài)激活1) 新創(chuàng)立的bug;2) 已解決但驗證未通過的bug；3) 已關(guān)閉的bug重新出現(xiàn)需要再次激活 。已解決開發(fā)已經(jīng)修改完成的 bug。關(guān)閉已驗證通過的bug或系統(tǒng)工程師確認轉(zhuǎn)為需求的bu

11、g。7.3 BUG解決方案已解決Bug 已經(jīng)被修改，待測試進展驗證。設(shè)計如此 測試人員理解錯誤，無需改動，即無效bug。重復(fù) bug已經(jīng)有同樣的 bug ，需標明重復(fù) bug 號。無法重現(xiàn) 根據(jù)測試寫的重現(xiàn)步驟，無法重現(xiàn)bug。延期處理確實是bug，但現(xiàn)在不解決，以后處理。新增 /變更需求分析確實是存在問題，但需求沒有描述清晰，應(yīng)指派給需求確認，進展需求的新增或變更。7.4 BUG 優(yōu)先級高 阻止與此密切相關(guān)功能的進一步測試，需要立即修復(fù)。中 必須修改，不一定馬上修改，必須修改，發(fā)版前必須修正。低對系統(tǒng)的影響較小，如果時間允許應(yīng)該修改。7.5 BUG 嚴重等級嚴重一類 不能執(zhí)行正常工作功能或重

12、要功能，因軟件原因?qū)е孪到y(tǒng)死機等，須馬上修正致命錯誤。 通常有如下情況：1) 系統(tǒng)停機含軟件、硬件或非法退出，且無法通過重啟恢復(fù)；2) 系統(tǒng)死循環(huán)；3) 與數(shù)據(jù)庫連接錯誤；4) 數(shù)據(jù)庫發(fā)生死鎖或程序原因?qū)е聰?shù)據(jù)庫斷連；5) 數(shù)據(jù)通訊錯誤或接口不通；6) 重要功能無常使用、功能不符合用戶需求。一般二類影響系統(tǒng)功能或操作，應(yīng)用模塊錯誤使業(yè)務(wù)中止無法進展后續(xù)操作，主要功能存在嚴重缺陷，影響到產(chǎn) 品的使用，但不會影響到系統(tǒng)穩(wěn)定性。具體根本上可分為：1) 業(yè)務(wù)流程錯誤或不完整；2) 業(yè)務(wù)數(shù)據(jù)來源不正確、業(yè)務(wù)數(shù)據(jù)紊亂或喪失；3) 業(yè)務(wù)數(shù)據(jù)保存不完整或無法保存到數(shù)據(jù)庫；4) 局部功能使用存在問題，不影響業(yè)務(wù)

13、繼續(xù)開展，但造成使用障礙；5) 初始化未滿足客戶要求或初始化錯誤；6) 功能點能實現(xiàn)，但結(jié)果錯誤；7) 缺少數(shù)據(jù)有效性檢查或檢查不合理；8) 刪除操作不給提示；9) 日志記錄信息不正確或應(yīng)記錄而未記錄；10) 數(shù)據(jù)庫的表、業(yè)務(wù)規(guī)那么、缺省值未加完整性等約束條件；11) 在產(chǎn)品聲明支持的不同平臺下，出現(xiàn)局部一般交易無法使用或錯誤；12) 系統(tǒng)某些查詢、打印等實時性要求不高的輔助功能無常使用。輕微三類 使操作者不合理或者不方便或操作遇到麻煩，但它不影響執(zhí)行工作功能或重要功能，次要功能，對產(chǎn)品 使用影響不大。例如：程序在一些顯示上不美觀，不符合用戶習(xí)慣，或是一些文字的錯誤。具體根本上可分為：1) 缺

14、少產(chǎn)品使用、幫助文檔、系統(tǒng)安裝或配置方面需要信息；2) 聯(lián)機幫助、脫機手冊與實際系統(tǒng)不匹配；3) 系統(tǒng)版本說明不正確；4) 提示說明未采用行業(yè)規(guī)語言；5) 顯示格式不規(guī)；6) 界面不整齊；7) 軟件界面、菜單位置、工具條位置、相應(yīng)提示不美觀，但不影響使用；8) 輔助說明描述不清楚；9) 提示窗口描述清楚；10) 輸入輸出不規(guī)；11) 可輸入?yún)^(qū)域和只讀區(qū)域沒有明顯的區(qū)分標志。建議四類7.6 BUG 書寫規(guī)7.6.1 測試人員 BUG 提交1) 主題? 用一個簡短的句子描述問題，不要寫成一大段? 以進入問題模塊路徑開頭，方便工程經(jīng)理分派任務(wù)，以與開發(fā)人員定位問題? 描述問題時要詳細、簡練、抓住要點

15、，直接切入正題，不要羅嗦? 不要夸大或縮小問題的嚴重程度2) 步驟? 用數(shù)字編號，一步步的描述重現(xiàn)問題的所有操作步驟? 提供明確的再現(xiàn)問題的步驟，防止問題被以“不能重現(xiàn)關(guān)掉? 設(shè)置區(qū)域需要詳細描述，如：各設(shè)置項值為默認、 * 值更改為“，其他設(shè)置項值為默認? 盡量用動詞作為開頭，描述每個步驟。如：翻開、點擊、設(shè)置、選擇、插入、雙擊等不要在一個步驟中描述不相關(guān)的多個操作。如果是相關(guān)的一系列操作，可以使用“T來連接描述 按照你寫的步驟去執(zhí)行，看問題能否重現(xiàn)不要在步驟中使用模糊不清的縮寫詞描述3) 實際結(jié)果? 實際只描述一個問題? 同樣的操作步驟產(chǎn)生多種現(xiàn)象，要在一個缺陷報告中加以描述? 不同的操作步驟產(chǎn)生不同的問題，分別報 bug? 如果有截圖，請列出所附的圖片信息4) 預(yù)期結(jié)果? 不要參加實際結(jié)果的描述信息? 描述要清晰，不要使用模糊不清的縮寫詞描述? 如果有截圖，請列出所附的圖片信息5) 備注? 防止寫成大段落，要寫得簡單、易讀? 問題的特征? 出現(xiàn)問題后的解決方法? 對終端客戶的影響情