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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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