質(zhì)量評價體系建設(shè)

軟件質(zhì)量評價體系（初稿）XXX修改歷史日期日期版本作者修改內(nèi)容2018/01/261.0xxx新建正式批準(zhǔn)角色角色簽名日期備注目錄1?目的 52?范圍 53?參考資料 54?測試過程描述 6測試流程圖 6活動說明 7需求評審 7測試計劃 9功能測試設(shè)計 10功能測試執(zhí)行 11集成/性能測試設(shè)計 14集成/性能測試執(zhí)行 15測試報告 17測試維護(hù) 18缺陷管理 205.1目的 20角色與職責(zé) 20缺陷管理流程 21新建缺陷 22修復(fù)缺陷 22驗(yàn)證缺陷 225.3缺陷管理系統(tǒng)部分字段詳解 225.4規(guī)范 25配置管理 256.1目的 25配置項(xiàng) 26測試環(huán)境配置 266.4規(guī)范 26目的本文是對項(xiàng)目軟件測試的指導(dǎo)性文件， 對軟件測試過程中所涉及到的測試?yán)碚摗?測試類型、測試方法、測試標(biāo)準(zhǔn)、測試流程及測試過程中涉及到的角色職責(zé)進(jìn)行總體規(guī)范，保證軟件質(zhì)量。2范圍本文適用于軟件測試人員。參考資料《文檔評審指南》《項(xiàng)目測試計劃模版》《測試用例模版》《測試執(zhí)行規(guī)范》《項(xiàng)目測試報告模版》《測試用例配置管理》《缺陷模板》《SVN 提交規(guī)范》《軟件測試環(huán)境發(fā)布流程》

以有效測試過程描述測試流程圖測試維護(hù)活動說明目的確保產(chǎn)品需求文檔可以全面、理解達(dá)到一致。

清晰地描述產(chǎn)品的功能和性能； 確保項(xiàng)目組成員對需求的角色與職責(zé)需求人員：《需求規(guī)格說明書》的編寫，以及軟件開發(fā)過程中《需求規(guī)格說明書》的修正。評審人員：評審《需求規(guī)格說明書》，從全面性、完整性、正確性、一致性、可靠性方面檢查《需求規(guī)格應(yīng)由開發(fā)人員與測試人員共同組成。啟動標(biāo)準(zhǔn)《需求規(guī)格說明書》編寫完成工作流程圖輸入/輸出輸入：《需求規(guī)格說明書》輸出：需求缺陷規(guī)范參見《文檔評審指南》測試計劃目的明確測試內(nèi)容、測試任務(wù)安排、測試進(jìn)度、測試策略、測試資源、風(fēng)險控制；保持測試過程的順暢，有效控制和跟蹤測試進(jìn)度，應(yīng)對測試過程中的各種變更。422.2角色與職責(zé)測試負(fù)責(zé)人：根據(jù)《項(xiàng)目整體計劃》 、《需求規(guī)格說明書》編制《測試計劃》 ，明確測試內(nèi)容、測試任務(wù)安排、測試進(jìn)度、測試策略、測試資源、風(fēng)險控制，以便測試工作正常開展。測試計劃實(shí)際編寫內(nèi)容參見《項(xiàng)目測試計劃模版》 啟動標(biāo)準(zhǔn)需求評審?fù)瓿?，《?xiàng)目整體計劃》編制完成工作流程圖測試計劃測試負(fù)責(zé)人輸入/輸出輸入：《需求規(guī)格說明書》、《項(xiàng)目整體計劃》輸出：《測試計劃》422.6規(guī)范測試計劃編寫內(nèi)容參見《測試計劃模版》功能測試設(shè)計目的通過多種測試方法編寫測試用例， 以使最少的測試用例件功能的正確性，從而提升軟件質(zhì)量。角色和職責(zé)測試人員：采用多種測試方法編寫有效的測試用例，并對遺漏正。評審人員：對測試人員編寫的測試用例進(jìn)行評審，提出遺漏直至用例缺陷的驗(yàn)證關(guān)閉。啟動標(biāo)準(zhǔn)需求文檔評審?fù)瓿?，且測試計劃制定完成。

實(shí)現(xiàn)最大的測試覆蓋，保證軟/錯誤的測試用例進(jìn)行修/錯誤的用例缺陷，并跟蹤工作流程圖測試設(shè)計測試人員輸入輸出輸入：《需求規(guī)格說明書》輸出：《測試用例》、測試用例評審缺陷規(guī)范測試用例實(shí)際內(nèi)容參見《測試用例模版》功能測試執(zhí)行目的依據(jù)測試計劃，按照測試用例對軟件進(jìn)行測試，驗(yàn)證軟件功能與需求的實(shí)際匹配程度。424.2角色與職責(zé)測試人員：依據(jù)測試計劃，按照測試用例對軟件進(jìn)行測試。對于發(fā)現(xiàn)的缺陷必須記錄，并且跟蹤缺陷的狀態(tài)， 直至缺陷的驗(yàn)證關(guān)閉。在測試執(zhí)行過程中發(fā)現(xiàn)遺漏測試用例必須補(bǔ)充至測試用例，保證測試用例與實(shí)際測試的一致性。開發(fā)人員：對于測試人員提交的缺陷進(jìn)行確認(rèn)、修復(fù)。評審人員：對測試人員與開發(fā)人員意見不一的問題進(jìn)行裁決。 當(dāng)測試人員與開發(fā)人員對缺陷有效性的意見不統(tǒng)一時，評審人員應(yīng)總合各方面意見，對缺陷有效性作出最終判定。評審人員應(yīng)由測試負(fù)責(zé)人、開發(fā)負(fù)責(zé)人和需求人員共同組成。4.2.4.3啟動標(biāo)準(zhǔn)測試用例編寫完成，且用例評審?fù)瓿伞?24.4工作流程圖測試執(zhí)行測試人員測試執(zhí)行開始按照測試用例進(jìn)行軟件測試No 是否發(fā)現(xiàn)缺陷 發(fā)現(xiàn)缺陷測試順利通過是否全部測試用例執(zhí)行完成■■■<Yes測試執(zhí)行完成4.245輸入輸出輸入：功能測試用例輸出：功能測試缺陷4.2.4.6規(guī)范測試執(zhí)行過程需按照《測試執(zhí)行規(guī)范》進(jìn)行，缺陷管理需按照本文 5缺陷管理進(jìn)行。集成/性能測試設(shè)計目的為集成測試提供測試依據(jù)，記錄并保證集成測試覆蓋度；依據(jù)《測試計劃》及性能指標(biāo)進(jìn)行性能測試用例設(shè)計、性能測試腳本開發(fā)，試有序進(jìn)行。

保證性能測角色和職責(zé)測試人員：以整個軟件為對象，確保新功能、老功能、新老功能接口正確進(jìn)行用例設(shè)計；依據(jù)性能指標(biāo)及測試計劃編寫性能測試用例、開發(fā)性能測試腳本。啟動標(biāo)準(zhǔn)功能測試完成且軟件功能無中斷工作流程圖集成集成/性能測試設(shè)計測試人員測試人員注：此處兩文檔編寫無先后關(guān)系注：此處兩文檔編寫無先后關(guān)系輸入輸出輸入：功能測試用例、功能測試缺陷、 《測試計劃》、性能指輸出：集成測試用例、性能測試用例、性能測試腳本規(guī)范集成測試用例實(shí)際內(nèi)容參見《測試用例模版》集成性能測試執(zhí)行目的以整個軟件為對象，以測試計劃為指導(dǎo)，按照集成測試用例對新功能、老功能、新老功能接口進(jìn)行測試和性能測試，以保證測試的全面性和完整性。426.2角色和職責(zé)測試人員：以整個軟件為對象，以測試計劃為指導(dǎo)，按照集成測試用例對新功能、老功能、新老功能接口進(jìn)行測試，并依據(jù)性能測試計劃對軟件性能進(jìn)行測試。4.2.6.3啟動標(biāo)準(zhǔn)集成/性能測試設(shè)計完成工作流程圖輸入輸出輸入：《集成測試用例》、《測試計劃》、《性能測試計劃》、《性能測試用例》輸出：集成測試缺陷4.2.6.6規(guī)范測試執(zhí)行過程需按照《測試行為規(guī)范》進(jìn)行，缺陷管理需按照本文 5缺陷管理進(jìn)行。測試報告目的真實(shí)、客觀反映測試過程中各測試階段、測試項(xiàng)的情況，并將結(jié)果進(jìn)行數(shù)字化進(jìn)行分析，真實(shí)反映/圖像化軟件質(zhì)量實(shí)際情況。角色與職責(zé)測試負(fù)責(zé)人：真實(shí)、客觀地對測試過程中各測試階段、測試項(xiàng)的情況，并以數(shù)字的形式對實(shí)際情況進(jìn)行分析，真實(shí)反映軟件實(shí)際測試狀況。啟動標(biāo)準(zhǔn)測試執(zhí)行完成。工作流程圖測試報告測試負(fù)責(zé)人收集整理各測試階段、測試項(xiàng)實(shí)際測試情況編寫測試報告輸入輸出輸入：各測試階段、測試項(xiàng)實(shí)際測試情況輸出：《項(xiàng)目測試報告》

/圖像427.6規(guī)范項(xiàng)目測試報告實(shí)際內(nèi)容參見《項(xiàng)目測試報告模版》測試維護(hù)目的軟件產(chǎn)品的版本是隨著軟件的升級而不斷變化的， 而每一次版本的變化都會對測試用庫產(chǎn)生影響，所以測試用例庫也需要不斷地變更和維護(hù)，使之與產(chǎn)品的變化保持一致。428.2角色與職責(zé)測試負(fù)責(zé)人：真實(shí)、客觀地對測試過程中各測試階段、測試項(xiàng)的情況，并以數(shù)字4.2.8.3啟動標(biāo)準(zhǔn)測試執(zhí)行完成。

/圖像工作流程圖測試維護(hù)測試維護(hù)測試人員測試人員注：此處三個維護(hù)行為無先后關(guān)系注：此處三個維護(hù)行為無先后關(guān)系輸入輸出輸入：測試用例、測試用例庫輸出：更新后的測試用例庫規(guī)范測試用例的管理參見《測試用例配置管理》缺陷管理目的對各階段測試發(fā)現(xiàn)的缺陷進(jìn)行跟蹤管理，以保證各級缺陷的修復(fù)率達(dá)到標(biāo)準(zhǔn)角色與職責(zé)參與缺陷流轉(zhuǎn)的角色有三個：測試人員、開發(fā)人員和評審人員。測試人員：依據(jù)測試計劃，按照測試用例對軟件進(jìn)行測試。對于發(fā)現(xiàn)的缺陷必須記錄，并且跟蹤缺陷的狀態(tài)，直至缺陷的驗(yàn)證關(guān)閉。在測試執(zhí)行過程中發(fā)現(xiàn)的遺漏測試用例必須補(bǔ)充至測試用例，保證測試用例與實(shí)際測試的一致性。開發(fā)人員：對于測試人員提交的缺陷進(jìn)行確認(rèn)、修復(fù)。評審人員：對測試人員與開發(fā)人員意見不一的問題進(jìn)行裁決。 當(dāng)測試人員與開發(fā)人員對缺陷有效性的意見不統(tǒng)一時，評審人員應(yīng)總合各方面意見，對缺陷有效性作出最終判定。評審人員應(yīng)由測試負(fù)責(zé)人、開發(fā)負(fù)責(zé)人和需求人員共同組成。缺陷管理流程缺陷管理流程測試人員 開發(fā)人員 評審人員提出Bug認(rèn)BugNo是否有效意見是否統(tǒng)一一Yes

NoYesNo

判定Bug是否有效Yes驗(yàn)證Bug No是否修復(fù)Yes關(guān)閉Bug段階缺陷的處理步驟如下:新建缺陷缺陷的提出人負(fù)責(zé)在缺陷管理系統(tǒng)中新建缺陷，并對缺陷的基本情況進(jìn)行描述。缺陷的基本信息主要包括：缺陷描述、緊急程度、嚴(yán)重程度、處理人員等。提出人在登記缺陷時，必須確定所輸入的缺陷內(nèi)容要描述清楚，產(chǎn)生缺陷的步驟描述要完整，使缺陷能夠被重現(xiàn)出來。在描述缺陷產(chǎn)生的步驟上， 務(wù)必簡易清楚。提出人可以用錯誤抓圖等方式進(jìn)行補(bǔ)充描述。修復(fù)缺陷當(dāng)有多個缺陷同時打開時，開發(fā)人員應(yīng)首先修復(fù)緊急程度更高的缺陷。 開發(fā)人員首先析缺陷，并將缺陷狀態(tài)更改為“處理中” 。當(dāng)開發(fā)人員確定該缺陷不是有效的缺陷時，則將缺陷狀態(tài)更改為“拒絕”詳細(xì)填寫拒絕的原因。最終由測試人員將該缺陷記錄為“無效”測試人員對缺陷有效性的意見不統(tǒng)一，應(yīng)進(jìn)行缺陷評審，由評審人員判定。

，并添加注釋。若在此過程中開發(fā)人員與當(dāng)確認(rèn)該缺陷有效時，開發(fā)人員應(yīng)按照要求修復(fù)缺陷。 缺陷修復(fù)后，開發(fā)人員需添加注釋詳細(xì)填寫修復(fù)的內(nèi)容、缺陷根源、修復(fù)版本，更改缺陷狀態(tài)為“待驗(yàn)證”當(dāng)確認(rèn)該缺陷不是本系統(tǒng)引起， 需要其它項(xiàng)目組協(xié)同進(jìn)行分析解決

。開發(fā)人員應(yīng)保持缺陷狀態(tài)為“處理”，并將該缺陷的“處理人員”改為相應(yīng)的項(xiàng)目組人員，以便缺陷能及時流轉(zhuǎn)。驗(yàn)證缺陷測試人員負(fù)責(zé)驗(yàn)證缺陷是否已解決。如已解決則關(guān)閉缺陷，否則將“缺陷狀態(tài)”更改為“重開”，以便開發(fā)人員重新對此缺陷進(jìn)行處理。缺陷管理系統(tǒng)部分字段詳解缺陷狀態(tài)：指缺陷通過一個跟蹤修復(fù)過程的進(jìn)展情況。包括：新建、處理中、拒絕、無效、待驗(yàn)證、重開、關(guān)閉缺陷嚴(yán)重程度：是指因缺陷引起的故障對系統(tǒng)的影響程度。員負(fù)責(zé)確認(rèn)。由提出人初步指定，開發(fā)缺陷級別 定義 幫助和示例1、死機(jī)、重啟、內(nèi)存泄漏、自動關(guān)機(jī)； 軟件在待機(jī)或者使用時岀現(xiàn)死機(jī)、報錯、系統(tǒng)重啟、自動關(guān)機(jī)、癱瘓等造成無法使用的問題；無法開機(jī)；操作應(yīng)用時內(nèi)存不足，造成大量軟件應(yīng)用不能使用的情況；2、花屏、白屏等屏幕異?，F(xiàn)象； 喚醒后屏幕、鍵盤失效；屏幕岀現(xiàn)花屏、白屏現(xiàn)象；一級問題（致命問題）A

3、系統(tǒng)無響應(yīng)； 待機(jī)或者使用中系統(tǒng)沒有響應(yīng)；電話不能呼岀、撥入或呼通率低于95%以下，單通（1%以上）;通話不能斷，短信不能收發(fā)，延遲（非網(wǎng)絡(luò)問題）；屏幕無法點(diǎn)亮，屏幕半亮無法使用，屏幕灰屏無法使用等；4、岀現(xiàn)數(shù)據(jù)丟失、數(shù)據(jù)庫被破壞或者損壞用戶器件；

系統(tǒng)數(shù)據(jù)丟失或?qū)绗F(xiàn)數(shù)據(jù)庫破壞現(xiàn)象給用戶帶來損失；任意應(yīng)用一直報錯無法正常使用機(jī)器；5、手機(jī)卡不能被識別；掉網(wǎng)，脫網(wǎng)； 在使用時出現(xiàn)不能識別SIM卡/T卡；燒壞手機(jī)卡，損T卡，給用戶帶來損失的情況；SIM絡(luò)；掉網(wǎng)或脫網(wǎng)；6、危機(jī)用戶安全的； 手機(jī)發(fā)燙，異常嘯叫；可能造成用戶聽力、視覺或其他人身損傷的。1、基本業(yè)務(wù)功能未實(shí)現(xiàn)； 基本業(yè)務(wù)功能處理不符合協(xié)議；產(chǎn)品定義中需求的本功能沒有實(shí)現(xiàn)；二級問題（嚴(yán)重問題）

2、應(yīng)用程序自動退出或失效； 通信方面岀現(xiàn)單通（小于等于 1%）、通話回音、通話嘯叫、電流音、信號漂移、重新搜網(wǎng)、掉卡、通話自動掛斷、三方通話岀現(xiàn)問題、短信業(yè)務(wù)岀現(xiàn)接收延遲（小于等于1小時）、丟短信（丟失率大于3%）、經(jīng)常發(fā)送失敗等現(xiàn)象；網(wǎng)絡(luò)自動斷網(wǎng)、連接失敗及無數(shù)據(jù)交換的基本功能；應(yīng)用程序自動退出，或提示強(qiáng)制關(guān)閉/無響應(yīng)關(guān)閉；B 3、自動亮屏； 軟件在使用過程中應(yīng)用軟件自動退岀，或者某些功失效；4、軟件使用造成系統(tǒng)反應(yīng)慢； 在使用過程中整個系統(tǒng)運(yùn)行速度逐漸變慢，造成系統(tǒng)性能下降；5、客戶反饋問題； 客戶反饋問題根據(jù)客戶定義級別來報（沒有定義的應(yīng)標(biāo)識為二級嚴(yán)重問題）?？蛻舭ǖ谌胶献骰锇?；6、不符合國家法律法規(guī)的，或會引起民族或文化爭議的問題；7、參數(shù)設(shè)置異常；

不能岀現(xiàn)違反國家法律法規(guī)信息，不能岀現(xiàn)引起民族或矛盾的信息；參數(shù)設(shè)置不能保存或失效；8用戶界面信息異常； 提示信息與實(shí)際不符，顯示不全、漏顯示、重疊、錯誤、亂碼或者不美觀等現(xiàn)象；大范圍的UI、文字、音、圖案、燈光提示錯誤、不準(zhǔn)確；三級問題（一1、主要功能已實(shí)現(xiàn)，存在影響用戶正常使用軟件應(yīng)用的部分功能的失效，或者操作某功能響應(yīng)般問題）C

的問題；

慢，界面刷新不及時；1、輕微、提示性問題，不影響系統(tǒng)功能 幫助文件、提示信息缺少或可讀性差、用詞不當(dāng)、錯別字及不易于理解的描述；2、操作復(fù)雜或用戶不常操作到的路徑； 操作3級以上菜單功能岀現(xiàn)的問題；操作多個模塊（3個）交互后岀現(xiàn)的問題四級問題（輕微問題）D

3、需要提示信息的地方?jīng)]有相應(yīng)提醒； 收費(fèi)業(yè)務(wù)在用戶訂閱前沒有提示信息；4、用戶使用不便或者容易出現(xiàn)誤操作； 操作功能使用不方便，并且不方便的程度很輕微；5、建議性問題以使軟件可用性更強(qiáng)； 外觀色彩、字體大小顯示更適合長時間使用；提示音不應(yīng)有特別刺耳或者容易讓人疲勞的情況；增加一些簡單功能使軟件更人性化；刪除多余的功能；缺陷緊急程度：指缺陷必須被修復(fù)的緊急程度。具體協(xié)商約定緊急程度的具體含義。

由提出人指定。各測試小組可以項(xiàng)目組包括：高、中、低缺陷起源：指引起缺陷的起因。由開發(fā)人員初步指定，測試人員負(fù)責(zé)確認(rèn)。包括：需求、架構(gòu)、設(shè)計、編碼、測試、環(huán)境、數(shù)據(jù)、無效缺陷根/r