測試工作規(guī)范

文件編號：生效日期：受控編號：當(dāng)前版本：當(dāng)前狀態(tài)：發(fā)布日期：編制人：審核人：批準(zhǔn)人：修訂記錄日期修訂版本描述作者2023-05-11V0.1新建 目錄一、概述 41.1目的 41.2內(nèi)容 4二、職責(zé) 52.1工作職責(zé) 52.2崗位職責(zé) 52.2.1軟件測試工程師 52.2.2硬件測試工程師 62.2.3臨床測試工程師 6三、工作目標(biāo) 83.1測試的重要維度 83.2測試活動 83.3非測試活動 93.4測試目標(biāo) 103.4.1核心目標(biāo) 103.4.2其他目標(biāo) 103.4.3階段目標(biāo) 103.5非測試目標(biāo) 11四、工作流程 124.1測試階段 124.2測試工作流程 134.2.1測試申請 134.2.2測試準(zhǔn)備 144.2.3測試設(shè)計 144.2.4測試實施 154.2.5缺陷管理 184.2.6回歸驗證 204.2.7測試驗收 204.2.8測試總結(jié) 214.3測試依據(jù) 224.4通過標(biāo)準(zhǔn) 224.5停止標(biāo)準(zhǔn) 224.6例外放行 24五、測試相關(guān)文檔 255.1 測試計劃 255.2 測試方案 255.3 測試用例 265.4 缺陷列表 275.5 測試報告 29六、日常工作規(guī)范 306.1工作任務(wù) 306.2輸入輸出 306.3協(xié)作要求 31七、測試過程管理 337.1測試文檔 337.1.1測試文檔管理 337.1.2編號規(guī)則 337.2缺陷處理 357.3過程控制 357.4測試版本管理 357.5測試報告 35八、文檔管理規(guī)范 378.1文檔模板 378.2文檔管理 378.3文檔維護(hù) 37九、責(zé)任追溯 38十、工作匯報 39十一、附件 40十二、其他 41

一、概述1.1目的該文檔作為測試組各項工作的指導(dǎo)與部門成員工作的參照執(zhí)行標(biāo)準(zhǔn)，針對測試團(tuán)隊的日常工作規(guī)范，主要包括測試流程、測試結(jié)果、測試文檔的輸出。確保測試工作流程的控制，明確項目的各階段測試團(tuán)隊?wèi)?yīng)完成的工作。工作實踐過程中，由部門成員不斷改進(jìn)優(yōu)化，使工作明確、有序、高效進(jìn)行，使與其他各部門更好的協(xié)作，做好產(chǎn)品的質(zhì)量控制與質(zhì)量保證。1.2內(nèi)容該文檔明確規(guī)定了測試組的工作職責(zé)、工作目標(biāo)、工作流程、文檔管理規(guī)范、日常工作規(guī)范、責(zé)任追溯與工作匯報等內(nèi)容。

二、職責(zé)2.1工作職責(zé)測試組同時承擔(dān)有以下工作職責(zé)：1、協(xié)助研發(fā)與項目團(tuán)隊高質(zhì)量完成產(chǎn)品研發(fā)，以節(jié)省開發(fā)成本；2、參與各階段工作，對階段成果進(jìn)行測試，以保證階段目標(biāo)的達(dá)成；3、發(fā)布前進(jìn)行缺陷查找和定位，發(fā)現(xiàn)盡可能多的缺陷，以節(jié)省維護(hù)成本，保證用戶信心；4、編寫測試計劃、測試方案、測試用例，在盡量真實的環(huán)境下保證高覆蓋度的測試，以節(jié)省運維成本；5、進(jìn)行缺陷跟蹤與分析，查找和監(jiān)控存在的問題，推進(jìn)項目質(zhì)量和管理質(zhì)量的提升；6、正確評價測試對象的質(zhì)量現(xiàn)狀，確定實際與預(yù)期目標(biāo)的差距；7、對工作資源與成果進(jìn)行管理、維護(hù)（輸入、輸出、交互文檔、測試版本、缺陷記錄等資源）。2.2崗位職責(zé)2.2.1軟件測試工程師按照測試計劃負(fù)責(zé)產(chǎn)品軟件部分的測試工作及相關(guān)文檔的撰寫。1、編寫測試用例，利用測試工具進(jìn)行軟件測試及管理，對測試結(jié)果進(jìn)行分析；2、負(fù)責(zé)軟件測試報告的撰寫和測試問題的跟蹤；3、協(xié)同軟件工程師，完成軟件設(shè)計部分的不良分析和版本故障跟蹤；4、參與軟件早期設(shè)計檢視，保證軟件可測試性需求；5、按時按質(zhì)完成上級交辦的其他工作。2.2.2硬件測試工程師按照測試計劃負(fù)責(zé)產(chǎn)品硬件部分的測試工作及相關(guān)文檔的撰寫。1、編寫測試用例并執(zhí)行，對測試結(jié)果進(jìn)行分析；2、負(fù)責(zé)硬件測試報告的撰寫和測試問題的跟蹤；3、協(xié)同硬件工程師，完成硬件設(shè)計部分的不良分析和版本故障跟蹤；4、參與硬件早期設(shè)計檢視，保證硬件可測試性需求；5、負(fù)責(zé)新元器件測試及承擔(dān)EMC（電磁兼容性）、可靠性測試等工作；6、負(fù)責(zé)測試工裝、測試儀器、測試儀表及測試設(shè)備的維護(hù)工作；7、按時按質(zhì)完成上級交辦的其他工作。2.2.3臨床測試工程師按照測試計劃負(fù)責(zé)產(chǎn)品臨床性能參數(shù)部分的測試工作及相關(guān)文檔的撰寫。1、編寫測試用例并執(zhí)行，對測試結(jié)果進(jìn)行分析；2、負(fù)責(zé)臨床測試報告的撰寫和測試問題的跟蹤；3、協(xié)同開發(fā)工程師，完成設(shè)計部分的不良分析和版本故障跟蹤；4、參與設(shè)備早期設(shè)計檢視，保證設(shè)備可測試性需求；5、負(fù)責(zé)設(shè)備臨床性能指標(biāo)驗證工作；6、負(fù)責(zé)產(chǎn)品臨床評價咨詢、產(chǎn)品注冊、產(chǎn)品技術(shù)要求和說明書的編寫；7、按時按質(zhì)完成上級交辦的其他工作。

三、工作目標(biāo)3.1測試的重要維度測試時間、測試成本和測試質(zhì)量構(gòu)成測試過程中需要關(guān)注的三個重要維度，三個維度相互制約、相互影響。在測試中，永遠(yuǎn)無法實現(xiàn)時間、成本和質(zhì)量的三贏，為其中任何2個目標(biāo)所做的努力，都必須以付出第三個目標(biāo)的損失為代價，此外我們永遠(yuǎn)都不可能窮盡所有的測試內(nèi)容，因此必須綜合權(quán)衡作出取舍。3.2測試活動測試組的測試活動如下：1、計劃和控制；2、提取測試需求、選擇測試環(huán)境和條件；3、設(shè)計測試用例；4、實施和執(zhí)行各階段的測試；5、檢查測試結(jié)果；6、評估出口準(zhǔn)則；7、報告測試過程及被測系統(tǒng)；8、總結(jié)各階段的測試工作；9、為進(jìn)入下一開發(fā)過程，或?qū)⑾到y(tǒng)交付給用戶，測試組提供質(zhì)量評估等足夠的信息，幫助利益相關(guān)者決定是否發(fā)布。3.3非測試活動測試組的非測試活動如下：1、部門日常工作；2、部門工作文檔管理；3、部門團(tuán)隊管理工作；4、部門工作成果管理；5、部門工作結(jié)果匯報；6、部門團(tuán)隊成員技能提升；7、協(xié)助其他部門完成非測試工作任務(wù)。根據(jù)公司領(lǐng)導(dǎo)、部門經(jīng)理的管理要求和工作目標(biāo)，有效、規(guī)范、高效的非測試活動將有助于推動測試活動高質(zhì)量的完成，達(dá)成工作目標(biāo)，實現(xiàn)團(tuán)隊效益。3.4測試目標(biāo)3.4.1核心目標(biāo)總體來說，測試組的核心目標(biāo)是：通過對被測對象的源代碼、程序、文檔，進(jìn)行靜態(tài)分析、評審和執(zhí)行動態(tài)測試，以提供信息來改進(jìn)被測對象的質(zhì)量，以及改善開發(fā)和測試的過程質(zhì)量。3.4.2其他目標(biāo)1、發(fā)現(xiàn)缺陷；2、增加對質(zhì)量的信心；3、為決策者提供信息；4、預(yù)防缺陷。3.4.3階段目標(biāo)1、需求分析的過程中對需求文檔測試，主要目標(biāo)是識別和解決問題，避免將缺陷引入設(shè)計和代碼；2、早期進(jìn)行測試設(shè)計的過程中，主要目標(biāo)是檢測測試依據(jù)，避免將缺陷引入代碼；3、開發(fā)和測試中（如單元測試），主要目標(biāo)是盡可能的發(fā)現(xiàn)bug，從而識別和修正盡可能多的缺陷；4、系統(tǒng)測試中，主要目標(biāo)是為了評估系統(tǒng)的特征，比如可靠性、可用性、安全性等；5、驗收測試中，主要目標(biāo)是確認(rèn)系統(tǒng)是否按照預(yù)期工作，是建立滿足需求的信心；6、發(fā)布測試中，主要目標(biāo)是對軟件質(zhì)量進(jìn)行評估，從而為利益相關(guān)者提供信息：在給定時間點發(fā)布或可能存在的風(fēng)險；7、維護(hù)測試中，主要目標(biāo)是驗證在開發(fā)過程中的軟件變更是否引入新的缺陷。3.5非測試目標(biāo)1、規(guī)范工作流程，采用合理的工作方式，有序的推進(jìn)工作；2、高質(zhì)量完成工作任務(wù)，達(dá)成工作目標(biāo)；3、建設(shè)高效能的團(tuán)隊組織；4、實現(xiàn)團(tuán)隊價值，提升各成員素質(zhì)；5、營造良好的工作氛圍。

四、工作流程4.1測試階段產(chǎn)品或項目的實現(xiàn)，在公司內(nèi)分為多個階段進(jìn)行：立項、需求、計劃、設(shè)計、實施、測試、確認(rèn)、發(fā)布。其中，測試階段的工作主要由測試組的測試活動完成。其他各階段，主要由研發(fā)中心完成，測試組會參與各個階段，根據(jù)各項目的實際情況參與度不同。需要明確的是，非測試活動測試部門至少參與評審，且評審意見應(yīng)得到重視。在產(chǎn)品或項目的各階段，測試組的測試活動與研發(fā)中心的工作并行開展。4.2測試工作流程4.2.1測試申請開發(fā)組向測試負(fù)責(zé)人提交《測試申請表》，該文檔主要說明：申請測試人員數(shù)量、進(jìn)行哪些階段的測試、需要提交哪些測試文檔、測試周期及測試環(huán)境要求。（1）研發(fā)應(yīng)當(dāng)提交詳盡可用的文檔，包括但不限于歷史版本、當(dāng)前版本、功能修改詳細(xì)信息、需求變更詳細(xì)信息以及期望任務(wù)完成時間等；（2）所交付的測試任務(wù)需具備可測試性。若配套的客戶端程序、終端機(jī)固件、服務(wù)器程序等均進(jìn)行了改動，交付測試任務(wù)時需配套交付；（3）由測試經(jīng)理對所有交付的測試任務(wù)進(jìn)行過濾，對不符合測試交付條件的測試任務(wù)進(jìn)行拒絕、協(xié)調(diào)和反饋。4.2.2測試準(zhǔn)備在技術(shù)實現(xiàn)編碼階段的工作結(jié)束時，進(jìn)入產(chǎn)品的測試準(zhǔn)備階段，為真正開展產(chǎn)品測試做好前期準(zhǔn)備工作。（1）制定測試計劃和測試方案；（2）組織協(xié)調(diào)測試人員；根據(jù)測試計劃和測試方案，組織協(xié)調(diào)相關(guān)測試人員，形成測試工作組。（3）測試人員的培訓(xùn)；正式開展測試工作之前，對所有測試人員進(jìn)行測試工作的集中培訓(xùn)。通過測試培訓(xùn)，使測試人員明確測試目標(biāo)和要求、了解待測系統(tǒng)、統(tǒng)一測試方法和流程，保質(zhì)保量的開展和進(jìn)行測試工作。（4）測試所需硬件設(shè)施和其他準(zhǔn)備工作；與相關(guān)部門聯(lián)系協(xié)調(diào)對接測試工作所需的設(shè)施：服務(wù)器、測試機(jī)等在測試準(zhǔn)備階段全部到位。4.2.3測試設(shè)計測試組負(fù)責(zé)人可以要求研發(fā)中心為測試預(yù)留足夠的時間。在整體計劃定稿后，測試人員開始編寫合理的計劃方案、搭建符合用戶的測試環(huán)境、撰寫和設(shè)計測試用例、準(zhǔn)備測試資源。測試計劃、測試方案、測試用例設(shè)計均需進(jìn)行評審。測試組內(nèi)部評審后，交于研發(fā)中心評審。產(chǎn)品線經(jīng)理負(fù)責(zé)明確重要功能、邏輯復(fù)雜度高的功能，并基于架構(gòu)設(shè)計和代碼層面指出計劃、用例、環(huán)境的不足之處，測試組采納合理意見。測試設(shè)計應(yīng)兼顧階段性成果測試的規(guī)劃。提倡盡早測試，階段交付，以便分散壓力、工作量和風(fēng)險。4.2.4測試實施測試實施是軟件測試工作的核心階段，測試實施階段嚴(yán)格按照測試計劃和測試方案展開。（1）搭建測試環(huán)境根據(jù)產(chǎn)品的實際需要搭建運行環(huán)境及準(zhǔn)備相關(guān)測試所需初始數(shù)據(jù)，包括：測試人員、測試工具等。搭建測試環(huán)境，需要盡可能與客戶使用環(huán)境一致，如果實難滿足，差距較大，應(yīng)對不同環(huán)境下，存在的各種隱患及風(fēng)險進(jìn)行分析并備案，在質(zhì)量評估報告中注明。（2）冒煙測試滿足以下條件，測試人員進(jìn)行冒煙測試：必須提供資料：任務(wù)單、測試版本、測試標(biāo)準(zhǔn)、修改說明；測試標(biāo)準(zhǔn)必須是需求規(guī)格說明書或其他文檔形式的標(biāo)準(zhǔn)；修改說明必須包含5個信息：歷史版本號、當(dāng)前版本號、修改功能、修改原因、影響點；必須說明期望測試任務(wù)完成的時間、測試要求、環(huán)境配置、重點關(guān)注內(nèi)容；本次測試任務(wù)相關(guān)的最近一次測試中提交了bug，bug需被全部修改；測試版本必須保證功能是可測的；當(dāng)安裝卸載正常、可測試的功能達(dá)到80%以上時，才認(rèn)為該版本的功能是可測的。除非有特殊理由，否則，不滿足以上條件測試組將拒絕該測試任務(wù)，并由測試組負(fù)責(zé)人回復(fù)郵件說明原因。待研發(fā)中心修改后，再提交。（3）測試執(zhí)行冒煙測試通過，正式執(zhí)行測試。測試執(zhí)行過程中，測試人員要注意以下幾點：測試人員對測試版本進(jìn)行確認(rèn)并記錄；測試人員要及時記錄發(fā)現(xiàn)的缺陷，并在每日下班前對缺陷進(jìn)行整理；研發(fā)人員要即時對測試人員提交的缺陷進(jìn)行查閱，并且最遲在次日修改缺陷狀態(tài)并給出詳盡說明；測試完結(jié)后，測試組需要提交對應(yīng)的書面文檔，上交測試記錄、測試結(jié)果或測試報告；測試人員應(yīng)盡力定位bug產(chǎn)生的原因。如遇到重要、可復(fù)現(xiàn)性低的問題，應(yīng)及時與研發(fā)人員聯(lián)系，進(jìn)行聯(lián)調(diào)，現(xiàn)場定位原因。此類問題，應(yīng)使測試組負(fù)責(zé)人知曉，且如有需要，由測試組負(fù)責(zé)人出面協(xié)調(diào)。若是正式測試，每一輪測試，測試人員應(yīng)將計劃的測試用例完整執(zhí)行一遍。測試發(fā)現(xiàn)的bug提交至缺陷管理工具上，研發(fā)人員進(jìn)行查閱并修改。原則上，研發(fā)需修改完所有bug，才可提供完整包進(jìn)行下一輪的測試。在下一輪測試開啟前，允許研發(fā)提交新版本進(jìn)行bug驗證，bug驗證通過后，需重新打包提交進(jìn)行下一輪測試。每一輪測試結(jié)束后，測試組需提交階段性的測試報告。（4）用例維護(hù)用例維護(hù)是指測試過程中根據(jù)每項測試結(jié)果，發(fā)現(xiàn)先前的測試用例不合理之處并對其進(jìn)行相應(yīng)的調(diào)整和改正。先前的測試用例設(shè)計不全面或者不夠準(zhǔn)確，隨著測試過程的深入和對產(chǎn)品功能特性的更好理解，發(fā)現(xiàn)測試用例存在一些邏輯錯誤需要及時更新；所發(fā)現(xiàn)的、嚴(yán)重的軟件缺陷沒有被目前的測試用例所覆蓋，需要及時更新；新的版本中添加新功能或者原有功能的修改，要求測試用例做相應(yīng)改動；測試用例不規(guī)范或者描述語句的錯誤；舊的測試用例已經(jīng)不再使用，需要刪除。（5）需求維護(hù)需求維護(hù)是指測試過程中根據(jù)每項測試結(jié)果，發(fā)現(xiàn)前期需求不合理之處并對其進(jìn)行相應(yīng)的調(diào)整和改正。需求維護(hù)工作貫穿整個測試過程。4.2.5缺陷管理提交缺陷的測試人員，需對缺陷進(jìn)行跟蹤直至缺陷被修復(fù)。測試人員有責(zé)任協(xié)助研發(fā)人員解決問題，并在問題修改后進(jìn)行驗證。為了保證缺陷的有效性：（1）測試一旦開啟，在未結(jié)束前，不得更新測試版本；（2）原則上，現(xiàn)有缺陷全部修改后方可提交驗證；（3）定期清理缺陷，關(guān)閉過期未處理和無效缺陷。由測試組負(fù)責(zé)人決定，哪些階段需要對缺陷進(jìn)行分析，以此評判工作中暴露的問題，以便及時更正。被拒絕修改的缺陷，由測試組負(fù)責(zé)人決定是否可以不作修改。如同意不改則責(zé)任追溯時，測試組負(fù)責(zé)人需承擔(dān)責(zé)任。缺陷按其嚴(yán)重程度分為4個等級，如下：等級程度具體描述1致命阻礙開發(fā)、測試工作；造成系統(tǒng)崩潰、死機(jī)、數(shù)據(jù)丟失；主要功能、基本模塊丟失、一級菜單不能使用2嚴(yán)重功能設(shè)計與需求嚴(yán)重不符；數(shù)據(jù)數(shù)值計算出錯；程序接口調(diào)用出錯；錯誤的波及面廣，影響到其他重要功能正常實現(xiàn)；非常規(guī)操作導(dǎo)致的程序崩潰、死機(jī)、死循環(huán)；外觀難以接受的缺陷3一般功能未實現(xiàn)但不影響使用；操作時間較長；數(shù)據(jù)錯誤顯示；操作界面錯誤；輸入限制4建議頁面建議性問題不影響正常使用；用戶體驗感不好；界面顯示不美觀；輔助說明描述不清楚；界面存在文字錯誤4.2.6回歸驗證待回歸的bug：（1）說清楚bug產(chǎn)生的原因；（2）必須要有詳細(xì)的定位信息、在哪個版本中修改、測試建議、影響范圍；（3）定位修改信息包括：修改了哪里，會影響到哪里；（4）不予解決、設(shè)計如此、延期處理的bug一定要有詳細(xì)且合理的原因，此類bug需經(jīng)評審再決定是否關(guān)閉?；貧wbug：（1）注明bug回歸時間；（2）注明bug回歸版本；（3）注明bug回歸步驟，若引發(fā)了新的bug并提交新的bug單后，在此處注明單號；（4）若開發(fā)在定位修改中寫得不詳細(xì)，經(jīng)過溝通之后才了解，在此處寫上對開發(fā)定位信息的詳細(xì)補(bǔ)充；（5）對回歸通過的bug進(jìn)行關(guān)閉，否則重新打開，并備注重新打開的理由。4.2.7測試驗收測試驗收階段的主要工作是：以客戶使用的角度，再次確認(rèn)系統(tǒng)的可操作性、正確性、全面性和完整性，為產(chǎn)品的上線應(yīng)用、推廣營銷最后把關(guān)。測試驗收階段依舊沿襲測試實施階段使用到的各種測試形式和方法，依據(jù)測試實施階段產(chǎn)生的測試問題報告單、測試用例單、階段性測試總結(jié)等各種文檔和資料展開。4.2.8測試總結(jié)測試總結(jié)階段是測試工作的最后一個階段，要進(jìn)行以下四項工作：（1）總結(jié)對測試階段工作完成情況、工作方法進(jìn)行總結(jié)。一方面總結(jié)好的方法和經(jīng)驗用于指導(dǎo)將來的測試工作；另一方面發(fā)現(xiàn)不足需改進(jìn)之處引起借鑒，并在今后的工作中加以避免。（2）匯總分析對測試驗收階段的遺留問題進(jìn)行匯總、統(tǒng)計和分析，并提出解決和修改建議。（3）整理文檔包括：產(chǎn)品設(shè)計說明書、產(chǎn)品培訓(xùn)教材、產(chǎn)品操作手冊、用戶使用說明書以及測試階段生成的各種文檔資料。（4）編寫測試報告把測試的過程和結(jié)果寫成文檔，包括產(chǎn)品質(zhì)量和測試過程的評價，測試報告基于測試中的數(shù)據(jù)采集以及對最終的測試結(jié)果分析。4.3測試依據(jù)1、需求規(guī)格說明書或需求變更說明；；如有例外的要求，需要列入需求變更或變更后的需求規(guī)格說明書，一同作為測試的標(biāo)準(zhǔn)。如果是臨時任務(wù)，需要將標(biāo)準(zhǔn)列入任務(wù)單，作為測試的標(biāo)準(zhǔn)；2、詳細(xì)設(shè)計文檔；一定要認(rèn)真閱讀開發(fā)詳細(xì)設(shè)計文檔，真正弄懂系統(tǒng)需求及設(shè)計思路；3、開發(fā)交付的修改說明文檔；測試范圍為修改或變更的點及與其相關(guān)聯(lián)的功能；4、各項工作規(guī)范及工作流程圖；參照工作流程圖，有序開展工作。5、行業(yè)標(biāo)準(zhǔn)和慣例；引用行業(yè)標(biāo)準(zhǔn)和慣例的時候，需要測試人員有足夠的經(jīng)驗。大部分情況沒有需求支持，則會用現(xiàn)存的成熟標(biāo)準(zhǔn)來實現(xiàn)測試。4.4通過標(biāo)準(zhǔn)1、被測版本滿足需求原型；

2、評審?fù)ㄟ^的用例覆蓋率達(dá)到100%，所有測試用例均執(zhí)行通過；

3、所有遺留問題都已有解決方案（延期解決/暫不解決/需求優(yōu)化/掛起）；4、性能指標(biāo)達(dá)到要求，驗收測試滿足預(yù)期。4.5停止標(biāo)準(zhǔn)停止標(biāo)準(zhǔn)規(guī)定了測試工作在滿足何種條件時停止測試。停止測試分為正常停止和非正常停止兩種情況。正常停止的情形：1、按照測試計劃，完成了規(guī)定的所有工作，達(dá)到準(zhǔn)出標(biāo)準(zhǔn)，可以停止測試；2、系統(tǒng)的功能和性能滿足需求規(guī)格說明書的要求；3、測試中發(fā)現(xiàn)的缺陷，各級缺陷的修復(fù)率達(dá)到標(biāo)準(zhǔn)；現(xiàn)存bug中，不存在致命級別、嚴(yán)重級別的缺陷；現(xiàn)存bug中，存在的一般級別缺陷的個數(shù)，不超過總?cè)毕莸?%；現(xiàn)存bug中，存在的建議級別缺陷的個數(shù)，不超過總?cè)毕莸?0%；4、功能測試的覆蓋率達(dá)到100%;5、執(zhí)行完全部用例發(fā)現(xiàn)的缺陷，不低于總?cè)毕莸?6%；6、平均每100行代碼，遺留的缺陷不多于2個；7、最近3輪測試，新缺陷數(shù)量的走勢趨于平緩下降；8、遺留缺陷的風(fēng)險在安全范圍內(nèi)。非正常停止的情形：1、現(xiàn)有測試環(huán)境不再支持繼續(xù)測試，則停止測試，測試執(zhí)行掛起；2、系統(tǒng)有大量或嚴(yán)重的錯誤，可測性極差，則停止測試，等待修改；3、項目計劃變更或人員變動，導(dǎo)致測試執(zhí)行無法繼續(xù)，則停止測試，測試執(zhí)行掛起；4、需求變更，導(dǎo)致測試標(biāo)準(zhǔn)較大范圍的變動，則停止測試，測試執(zhí)行掛起；5、出現(xiàn)風(fēng)險事故，導(dǎo)致測試執(zhí)行無法繼續(xù)，則停止測試，測試執(zhí)行掛起；6、有緊急任務(wù)和高優(yōu)先級任務(wù)，將導(dǎo)致較長時間，則停止測試，測試執(zhí)行掛起；7、提交測試結(jié)果的時間到，無可計劃的時間繼續(xù)測試，則停止測試。4.6例外放行測試組會在測試報告中給出合格或者不合格的評價，研發(fā)中心自己決定是否修改，如果不修改，則需要開會討論確認(rèn)是否例外放行。而測試組依據(jù)質(zhì)量評估報告或測試報告，提出發(fā)布建議。以下情形，測試組將不同意例外放行：1、硬器件質(zhì)量存在安全隱患；2、硬器件質(zhì)量存在性能缺陷；3、固件程序遺留有重大性能缺陷；4、軟件質(zhì)量存在重大性能缺陷；5、軟件質(zhì)量存在重大功能缺陷；6、設(shè)備臨床性能指標(biāo)不達(dá)標(biāo)。

五、測試相關(guān)文檔測試計劃1、確定測試內(nèi)容簡要的說明本系統(tǒng)的功能，詳細(xì)描述工作的范圍，估計測試設(shè)計和實施測試所需工作量。2、確定測試方法及標(biāo)準(zhǔn)說明本次測試采用的方法和測試標(biāo)準(zhǔn)，針對可能的測試結(jié)果，說明將采取的處理方法。3、確定資源列出測試任務(wù)的負(fù)責(zé)人及所有參與人員，說明本次測試的時間安排，要求與開發(fā)計劃中的實施計劃對應(yīng)，確定所需所有資源（人力、硬件、軟件和工具）。4、風(fēng)險評估填寫測試風(fēng)險列表，分析本設(shè)備測試過程中可能出現(xiàn)的風(fēng)險并采取相應(yīng)的措施。測試方案1、測試范圍針對項目進(jìn)行的功能測試，列出項目所包含的主要功能模塊。2、測試策略確定測試范圍、測試人員、測試時間、測試方法及測試工具。3、測試準(zhǔn)備測試環(huán)境、硬件要求、數(shù)據(jù)庫的數(shù)據(jù)量、測試工具等是否準(zhǔn)備齊全。4、測試用例嚴(yán)格按照《測試用例規(guī)范》編寫，評審?fù)ㄟ^后使用用例管理工具進(jìn)行維護(hù)。5、測試通過標(biāo)準(zhǔn)定義測試通過及產(chǎn)品發(fā)布標(biāo)準(zhǔn)。6、測試輸出輸出測試報告、測試用例執(zhí)行記錄及缺陷分析列表。7、測試風(fēng)險定義測試風(fēng)險（如測試范圍風(fēng)險、測試進(jìn)度風(fēng)險及測試環(huán)境風(fēng)險），提供規(guī)避方案。測試用例1、用例編號由字母、字符、數(shù)字組合而成的字符串，有唯一性、易識別性。2、用例標(biāo)題對測試用例的簡單描述，用概括的語言描述該測試用例的測試點，測試用例標(biāo)題不能重復(fù)。3、前置條件執(zhí)行當(dāng)前測試用例需要的前提條件，如果這些前提條件不滿足，則后面測試步驟無法進(jìn)行或無法得到預(yù)期結(jié)果。4、用例級別從基本功能、核心業(yè)務(wù)、重要特性、實際使用頻率等方面將用例級別分為高、中、低三個級別。5、操作步驟執(zhí)行當(dāng)前測試用例需要的操作步驟，需要明確的給出每一個操作的詳細(xì)描述，測試人員可以根據(jù)對應(yīng)操作步驟完成測試用例執(zhí)行。6、測試數(shù)據(jù)測試用例執(zhí)行時，需要輸入的外部信息，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權(quán)限等和測試相關(guān)的數(shù)據(jù)。7、實際結(jié)果按照步驟執(zhí)行當(dāng)前測試用例，被測設(shè)備的實際輸出結(jié)果，包括返回值內(nèi)容，界面的響應(yīng)結(jié)果，輸出結(jié)果的規(guī)則符合度等，一個測試步驟對應(yīng)一個測試結(jié)果。8、預(yù)期結(jié)果當(dāng)前測試用例的預(yù)期輸出結(jié)果，用來與實際結(jié)果比較，如果相同則該測試用例通過，否則該測試用例失敗。缺陷列表1、bug編號缺陷的唯一標(biāo)識，根據(jù)該標(biāo)識能追蹤到具體的某個缺陷。2、所屬模塊bug出現(xiàn)的模塊，能更快找到bug且為后續(xù)bug統(tǒng)計提供依據(jù)。3、bug標(biāo)題描述bug的標(biāo)題，用一句非常簡潔的話語將問題的核心描述出來，不要有歧義，字?jǐn)?shù)最好不要超過20個。4、嚴(yán)重程度bug出現(xiàn)后造成的影響，根據(jù)影響大小對bug進(jìn)行了分級，一般可以分為四級：致命、嚴(yán)重、一般、建議。5、優(yōu)先級定義bug被修復(fù)的先后順序，優(yōu)先級高的先被修復(fù)，一般可以分為四級：緊急、高、中、低，可與bug嚴(yán)重程度結(jié)合使用。6、bug狀態(tài)是缺陷跟蹤過程的進(jìn)展情況，狀態(tài)分為：激活、已解決、已關(guān)閉。7、bug類型根據(jù)缺陷產(chǎn)生的來源和根源劃分出的缺陷種類，如代碼錯誤、設(shè)計缺陷、界面優(yōu)化、性能問題、配置相關(guān)、安裝部署、安全相關(guān)等。8、所屬版本發(fā)現(xiàn)bug所在的軟件版本，有助于問題更快復(fù)現(xiàn)及解決。9、復(fù)現(xiàn)步驟按照此步驟能復(fù)現(xiàn)該bug，復(fù)現(xiàn)步驟是bug提交的一個非常重要的要素，包括：前置條件、發(fā)生時間、操作步驟、預(yù)期結(jié)果、實際結(jié)果和相關(guān)附件。10、附件出現(xiàn)bug時所產(chǎn)生的文件均需上傳，如截圖、視頻、數(shù)據(jù)庫、日志等。注意：不要把幾個bug錄入到同一個ID，即使這些bug的表面現(xiàn)象類似，或者是在同一個區(qū)域出現(xiàn)，或者是同一類問題，也應(yīng)該一個缺陷對應(yīng)記錄一個bug，因為這樣才能清晰地跟蹤所有bug的狀態(tài)，并且有利于缺陷的統(tǒng)計和質(zhì)量的衡量。測試報告測試報告分為4類：1、正式測試報告；2、臨時測試報告；3、器件確認(rèn)測試報告；4、質(zhì)量評估報告；對質(zhì)量現(xiàn)狀進(jìn)行評定，判斷是否滿足預(yù)期結(jié)果，分析實際與預(yù)期之間的差距。各類測試報告中，需要對測試結(jié)果進(jìn)行總結(jié)，得出結(jié)論性的問題說明和質(zhì)量評價，以提供給管理者直觀清晰的匯報。遺留的問題一定要討論評審，確定可遺留到下個版本，而且要在測試報告中，注明已知問題&風(fēng)險。測試組負(fù)責(zé)人應(yīng)即時上報測試報告，一般在測試完成后的當(dāng)天進(jìn)行匯報。

六、日常工作規(guī)范6.1工作任務(wù)測試組的工作任務(wù)由測試組負(fù)責(zé)人統(tǒng)一分派。任務(wù)分派和流轉(zhuǎn)應(yīng)通過郵件形式轉(zhuǎn)發(fā)，附帶任務(wù)來源提供的所有資料和信息。任務(wù)執(zhí)行人在完成任務(wù)后，需將任務(wù)記錄在文檔中。任務(wù)單在公司全范圍內(nèi)流轉(zhuǎn)，從任務(wù)請求開始，直到任務(wù)完成結(jié)束。包含：任務(wù)每個環(huán)節(jié)的負(fù)責(zé)人、輸入或輸出文檔路徑、結(jié)果概述等信息。6.2輸入輸出測試組的測試工作分為3類：正式測試、臨時測試、其他測試。各類任務(wù)的輸入信息和輸出成果如下：1、正式測試工作的輸入：任務(wù)單、符合接受標(biāo)準(zhǔn)的測試對象、測試計劃；2、正式測試工作的輸出：任務(wù)單更新后提交、測試版本入庫管理、缺陷入庫跟蹤、測試用例、測試報告；3、臨時測試任務(wù)的輸入：任務(wù)單、符合接受標(biāo)準(zhǔn)的測試對象、任務(wù)安排；4、臨時測試任務(wù)的輸出：任務(wù)單更新后提交、測試版本入庫管理、缺陷入庫跟蹤、測試用例、測試結(jié)果上報；5、其他測試任務(wù)的輸入：任務(wù)單、測試所需的資料和文檔、測試對象、任務(wù)安排；6、其他測試任務(wù)的輸出：任務(wù)單更新后提交、測試版本入庫管理、問題上報跟蹤、測試結(jié)果上報；完成任務(wù)后，任務(wù)執(zhí)行人負(fù)責(zé)上報任務(wù)結(jié)果，然后將任務(wù)記錄更新至任務(wù)清單列表中。同時，將輸出成果提交至文檔庫統(tǒng)一管理、使用。6.3協(xié)作要求測試組外部協(xié)助要求：1、研發(fā)中心提交測試組請求協(xié)助的工作任務(wù)均需通過郵件形式，附帶書面材料，發(fā)送至測試組負(fù)責(zé)人郵箱；2、研發(fā)中心應(yīng)保證測試組從產(chǎn)品或項目立項開始介入，并遵照達(dá)成一致的工作流程和規(guī)則進(jìn)行操作。如有特殊情況，應(yīng)事先知會測試組負(fù)責(zé)人，協(xié)商一致；3、如研發(fā)中心未按照規(guī)定的流程行事，測試組負(fù)責(zé)人有權(quán)拒絕接受研發(fā)中心的任務(wù)，并給出說明；測試組內(nèi)部成員協(xié)作要求：1、工作事務(wù)的溝通，采用郵件方式；2、工作流轉(zhuǎn)需按照規(guī)定的工作流程操作；3、工作過程中，完成規(guī)定的工作記錄，以備查驗追蹤；4、不得擅自從其他各處接受工作任務(wù)；5、工作過程中，與其他部門溝通時，重要問題需測試組負(fù)責(zé)人知悉；6、工作過程中，主動上報任務(wù)進(jìn)度，遇到問題應(yīng)主動尋求幫助；7、接受任務(wù)時，首先檢查任務(wù)資料、工作資源、技術(shù)難度等，如存在工作困難，應(yīng)第一時間與測試組負(fù)責(zé)人溝通；8、完成工作時，需按工作規(guī)則提交完整的工作成果，提交符合要求的文檔記錄和規(guī)范的工作文檔；9、對自身崗位職責(zé)內(nèi)的事情，盡責(zé)完成。對團(tuán)隊發(fā)展和自身提升有益的事情，可主動提出并實施。

七、測試過程管理7.1測試文檔7.1.1測試文檔管理本項目對測試文檔進(jìn)行集中管理，文檔集中存放在項目經(jīng)理處。測試文檔由不同角色分別創(chuàng)建，各角色創(chuàng)建的文檔如下：文檔名稱編制者其他說明《測試計劃》項目經(jīng)理《測試需求表》測試需求制定人員《測試用例說明書》測試設(shè)計人員《測試執(zhí)行記錄表》測試執(zhí)行人員《缺陷記錄》缺陷報告人員《缺陷跟蹤匯總表》缺陷報告人員《測試總結(jié)分析報告》項目經(jīng)理7.1.2編號規(guī)則子系統(tǒng)編號規(guī)則目的是定義要測試的各子系統(tǒng)的編號，以唯一標(biāo)識各子系統(tǒng)。本項目需要測試的各子系統(tǒng)的編號如下：階段子系統(tǒng)名稱編號XXXX子系統(tǒng)01XX子系統(tǒng)02XXXX子系統(tǒng)11XX子系統(tǒng)12XXXX子系統(tǒng)21XX子系統(tǒng)22測試項編號規(guī)則這里的測試項，是指測試需求和測試用例等。為了便于區(qū)分和管理測試項，并且唯一地標(biāo)識測試項，需要對測試項規(guī)定一種編號規(guī)則。我們制定編號規(guī)則如下：編號名稱說明定義系統(tǒng)識別碼測試項目/系統(tǒng)的標(biāo)識，在項目開始時自行定義，要求不與其他項目的標(biāo)識沖突。測試項識別碼用于標(biāo)識是何種測試項（測試用例、測試需求）測試需求R測試用例C缺陷記錄D子系統(tǒng)編號各子系統(tǒng)的編號與子系統(tǒng)編號中定義的一樣模塊編號唯一標(biāo)識同一子系統(tǒng)中的各模塊7.2缺陷處理本項目特定義缺陷處理過程如下：1、測試人員每天記錄當(dāng)天發(fā)現(xiàn)的缺陷；2、測試人員每天下班前將記錄的缺陷發(fā)送給項目經(jīng)理；3、測試結(jié)束時測試人員將所有缺陷整合成一個完整的缺陷文檔；4、測試結(jié)束時項目經(jīng)理組織對本次不修改的缺陷進(jìn)行評審。7.3過程控制1、各階段開發(fā)組或測試組需提供的文檔必須完備，負(fù)責(zé)人或測試者必須具體化；2、各階段的時間節(jié)點及周期控制需具體化；3、如有任何一環(huán)節(jié)出現(xiàn)延期或意外需提前告知。7.4測試版本管理測試人員對開發(fā)每次提交的版本和程序代碼都要做好記錄與備份工作，盡量保證交付