-.z.測試體系建立與軟件測試流程〔初稿〕**物合智聯(lián)科技**修改歷史日期版本修改內(nèi)容作者2016/7/111.0新建沙莎正式批準角色簽名日期備注目錄237221.目的4165472.范圍5153923.測試過程描述6128333.1測試流程圖6150123.2活動說明7137503.2.1需求評審7189783.2.2測試方案8290963.2.3測試設計9111733.2.4功能測試執(zhí)行1138883.2.5集成/性能測試設計1216563.2.6集成測試/性能測試14306183.2.7文檔測試16105493.2.8測試報告17101264.缺陷管理18195794.1概述18126654.1.1編寫目的18112974.1.2適用范圍1942084.1.3角色和職責19130824.1.4名詞解釋19140894.2缺陷狀態(tài)關系示意圖1959924.3缺陷流轉(zhuǎn)的過程及處理20250724.4缺陷頁面局部字段詳解21283775.配置管理 22133896.人員培養(yǎng) 221.目的本文是對工程軟件測試的指導性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準、測試流程及測試過程中涉及到的角色職責進展總體標準，以有效保證軟件質(zhì)量。2.范圍本文適用于所有軟件測試人員。3.測試過程描述3.1測試流程圖3.2活動說明3.2.1需求評審3.2.1.1目的從源頭把握軟件質(zhì)量，并確保開發(fā)結(jié)果與實際需求相一致3.2.1.2角色與職責需求人員："需求規(guī)格說明書"的編寫，以及軟件開發(fā)過程中"需求規(guī)格說明書"的修正；評審人員：評審"需求規(guī)格說明書"，從全面性、完整性、正確性、一致性、可靠性方面檢、查"需求規(guī)格說明書"，將需求缺陷提交給需求人員，并跟蹤需求缺陷直至需求缺陷驗證關閉。3.2.1.3啟動標準 "軟件需求規(guī)格說明書SRS"編寫完成3.2.1.4工作流程圖3.2.1.5輸入/輸出輸入："需求規(guī)格說明書"輸出：需求缺陷3.2.2測試方案3.2.2.1目的明確測試內(nèi)容、測試任務安排、測試進度、測試策略、測試資源、風險控制；保持測試過程的順暢，有效控制和跟蹤測試進度，應對測試過程中的各種變更。3.2.2.2角色與職責測試負責人：根據(jù)"軟件開發(fā)方案"、"需求規(guī)格說明書"編制"測試方案"，明確測試內(nèi)容、測試任務安排、測試進度、測試策略、測試資源、風險控制，以便測試工作正常開展，測試方案實際編寫內(nèi)容參見"工程測試方案模版"。3.2.2.3啟動標準需求評審完成，"工程整體方案"編制完成。3.2.2.4工作流程圖3.2.2.5輸入/輸出輸入："軟件需求規(guī)格說明書"、"軟件開發(fā)方案"輸出："測試方案"、"測試方案"3.2.3測試設計3.2.3.1目的通過多種測試方法編寫測試用例，以使最少的測試用例，實現(xiàn)最大的測試覆蓋，保證軟件功能的正確性，從而提升軟件質(zhì)量。3.2.3.2角色和職責測試人員：采用多種測試方法編寫有效的測試用例，并對遺漏/錯誤的測試用例進展修正。評審人員：對測試人員編寫的測試用例進展評審，提出遺漏/錯誤的用例缺陷，并跟蹤直至用例缺陷的驗證關閉。3.2.3.3啟動標準需求文檔評審完成且測試方案制定完成3.2.3.4工作流程圖3.2.3.5輸入輸出輸入："軟件需求規(guī)格說明書"、"測試方案"、"測試方案"輸出："測試用例"、測試用例評審缺陷3.2.4功能測試執(zhí)行3.2.4.1目的依據(jù)測試方案，按照測試用例對軟件進展測試，驗證軟件功能與需求的實際匹配程度。3.2.4.2角色與職責測試人員：依據(jù)測試方案，按照測試用例對軟件功能進展測試。對于發(fā)現(xiàn)的缺陷必須記錄，并且跟蹤缺陷的狀態(tài)，直至缺陷的驗證關閉。在測試執(zhí)行過程中發(fā)現(xiàn)的遺漏測試用例必須補充至測試用例，保證測試用例與實際測試的一致性。開發(fā)人員：對于測試人員提交的缺陷進展確認、修復。開發(fā)經(jīng)理：對測試人員與實際開發(fā)人員意見不一的問題進展裁決。3.2.4.3啟動標準測試用例編寫完成且用例評審完成3.2.4.4工作流程圖3.2.4.5輸入輸出輸入：功能測試用例輸出：功能測試報告，缺陷報告單3.2.5集成/性能測試設計3.2.5.1目的 為集成測試提供測試依據(jù)，記錄并保證集成測試覆蓋度；依據(jù)"測試方案"及性能指標制定性能測試方案、性能測試用例設計、性能測試腳本開發(fā)，保證性能測試有序進展。3.2.5.2角色和職責測試人員：以整個軟件為對象，確保新功能、老功能、新老功能接口正確進展用例設計；依據(jù)性能指標及測試方案對性能測試進展方案、以及性能測試用例/腳本的開發(fā)。3.2.5.3啟動標準功能測試完成且軟件功能無中斷3.2.5.4工作流程圖3.2.5.5輸入輸出輸入："功能測試用例"、功能測試缺陷、"測試方案"、性能指標輸出："集成測試用例"、"性能測試方案"、"性能測試用例"、性能測試腳本3.2.6集成測試/性能測試3.2.6.1目的 以整個軟件為對象，以測試方案為指導，按照集成測試測試用例對新功能、老功能、新老功能接口進展測試和性能測試，保證測試的全面性和完整性。3.2.6.2角色和職責測試人員：以整個軟件為對象，以測試方案為指導，按照集成測試測試用例對新功能、老功能、新老功能接口進展測試，并依據(jù)性能測試方案對軟件性能進展測試。3.2.6.3啟動標準集成/性能測試設計完成3.2.6.4工作流程圖3.2.6.5輸入輸出輸入："集成測試用例"、"測試方案"之集成測試事項、"性能測試方案"、"性能測試用例"輸出：集成測試缺陷3.2.7文檔測試3.2.7.1目的 保證對客戶的指導與實際系統(tǒng)的使用狀況相一致。3.2.7.2角色和職責測試人員：對"用戶操作手冊"及在線幫助進展測試，記錄文檔描述缺陷，并跟蹤直至缺陷的驗證關閉。需求人員：對測試人員提出的文檔描述缺陷進展修正。3.2.7.3啟動標準"用戶操作手冊"或在線幫助編寫完成3.2.7.4工作流程圖3.2.7.5輸入輸出輸入："用戶操作手冊"、在線幫助輸出：文檔缺陷3.2.8測試報告3.2.8.1目的真實、客觀反映測試過程中各測試階段、測試項的情況，并將結(jié)果進展數(shù)字化/圖像化進展分析，真實反映軟件質(zhì)量實際情況。3.2.8.2角色與職責測試負責人：真實、客觀地對測試過程中各測試階段、測試項的情況，并以數(shù)字/圖像的形式對實際情況進展分析，真實反映軟件實際測試狀況。3.2.8.3啟動標準集成測試完成3.2.8.4工作流程圖3.2.8.5輸入輸出輸入：各測試階段、測試項實際測試情況輸出："工程測試報告"

4.缺陷管理4.1概述4.1.1編寫目的為標準QC的合理使用，方便各工程組管理測試過程，測試管理人員正確使用QC而編寫。4.1.2適用范圍適用于功能測試有關工作，功能測試中的缺陷要求全部采用QC進展管理。4.1.3角色和職責角色名稱職責描述測試經(jīng)理申請QC工程建立，分配有關人員權(quán)限測試人員登記測試缺陷，跟蹤和修改缺陷狀態(tài)，并進展復測開發(fā)人員從QC中獲取缺陷信息，修復缺陷，并修改QC缺陷狀態(tài)及分析記錄缺陷相關內(nèi)容4.1.4名詞解釋QC：QC〔QualityCenter〕，也被稱為MQC〔MercuryQualityCenter〕。不僅可以在一個工程組內(nèi)進展質(zhì)量控制和管理，也可以在跨地域的不同工程組內(nèi)部進展質(zhì)量控制和管理，從而可以保證應用系統(tǒng)的質(zhì)量。通過在整個應用系統(tǒng)中提供并集成了測試的需求管理、案例管理、缺陷管理等，QC可以地加速測試過程執(zhí)行。4.2缺陷狀態(tài)關系示意圖4.3缺陷流轉(zhuǎn)的過程及處理參與缺陷流轉(zhuǎn)的角色有三個：測試經(jīng)理、測試人員和開發(fā)人員。缺陷的處理步驟如下：4.3.1新建缺陷測試人員負責在QC中新建缺陷，并對缺陷的根本情況進展描述。缺陷的根本信息主要包括：缺陷描述、緊急程度、嚴重程度、處理子系統(tǒng)等。測試人員在登記缺陷時，必須確定所輸入的缺陷內(nèi)容要描述清楚，產(chǎn)生缺陷的步驟描述要完整，使缺陷能夠被重現(xiàn)出來。在描述缺陷產(chǎn)生的步驟上，務必簡易清楚。測試人員可以利用錯誤抓圖等方式進展補充描述。4.3.2修復缺陷當有多個缺陷同時翻開時，開發(fā)人員應首先修復緊急程度更高的缺陷。開發(fā)人員首先分析缺陷，并將缺陷狀態(tài)更改為"處理〞中。當該缺陷不是有效的缺陷時，則將"缺陷狀態(tài)〞更改為"拒絕〞，并在"缺陷詳細信息〞模塊中的"分析和修改內(nèi)容〞中使用"添加注釋〞按鈕詳細填寫拒絕的原因。當確認該缺陷有效時，開發(fā)人員應按照要求修復缺陷。缺陷修復后，開發(fā)人員需在"缺陷詳細信息〞模塊中的"分析和修改內(nèi)容〞中使用"添加注釋〞按鈕詳細填寫修復的內(nèi)容，并填寫缺陷起源、缺陷歸屬子系統(tǒng)，更改"缺陷狀態(tài)〞為"待驗證〞。當確認該缺陷不是本系統(tǒng)引起，需要其它工程組協(xié)同進展分析解決，開發(fā)人員應保持缺陷狀態(tài)為"處理〞，并將該缺陷的"處理子系統(tǒng)〞改為相應的工程組或系統(tǒng)，以便缺陷能及時流轉(zhuǎn)。4.3.3驗證缺陷測試人員負責驗證缺陷是否已解決，如已解決則由缺陷原提出人關閉缺陷，否則將"缺陷狀態(tài)〞更改為"重現(xiàn)〞，以便開發(fā)人員重新對此缺陷進展處理。4.4缺陷頁面局部字段詳解缺陷狀態(tài)：指缺陷通過一個跟蹤修復過程的進展情況。包括：新建、翻開、已修改、重新翻開、關閉、拒絕、延遲缺陷嚴重程度：是指因缺陷引起的故障對系統(tǒng)的影響程度。由提出人初步指定，開發(fā)人員負責確認。包括：致命、嚴重、一般、輕微缺陷緊急程度：指缺陷必須被修復的緊急程度。由提出人指定。各測試小組可以工程組具體協(xié)商約定緊急程度的具體含義。包括：高、中、低提出、處理、拒絕、待驗證、重現(xiàn)、關閉缺陷起源：指引起缺陷的起因。包括：需求、架構(gòu)、設計、編碼、測試、環(huán)境、數(shù)據(jù)、拒絕缺陷起源類型含義需求由于需求定義或需求分析引起的缺陷架構(gòu)由于企業(yè)架構(gòu)設計的問題引起的缺陷設計由于本系統(tǒng)設計原因引起的缺陷編碼由于編碼的問題引起的缺陷測試由于測試人員在測試設計、測試操作或理解有誤等原因引起的缺陷環(huán)境由于測試環(huán)境的問題引起的缺陷數(shù)據(jù)由于測試數(shù)據(jù)的問題引起的缺陷拒絕重復。表示該缺陷已經(jīng)被其它提交人找出來了〔‘純粹’重復〕，或者開發(fā)認為原因是一樣的〔但從測試來看，認為出現(xiàn)的地方有所不同、表現(xiàn)有所不同等〕不可復現(xiàn)。不能重現(xiàn)〔如因缺陷出現(xiàn)的環(huán)境重現(xiàn)不了〕，或以前出現(xiàn)的*個缺陷自動消失了〔可能是在處理其他缺陷的時候把這個缺陷一并修復掉了〕是按照需求和設計實現(xiàn)的，不屬于缺陷延后解決。由于時間、進度、重要程度或者技術/需求等方面的原因，認為目前不能解決或由于時間關系，須延期解決或者本版暫不解決留待到后續(xù)版本解決的缺陷這個缺陷是一個錯誤，但非常輕微，對系統(tǒng)幾乎無影響，可以忽略不計

5.配置管理軟件測試過程是一個復雜性的勞動，測試過程中會產(chǎn)生大量測試文檔，主要通過相關管理工具的方式實行對文檔的管理。在文檔的管理方面，按照公共類、工程類、軟件缺陷類、開發(fā)人員類、測試工具類等：1〕公共類主要放置測試模板及測試規(guī)程