1、.軟件測試管理手冊文件狀態(tài)：文檔編號保 密 等 級內(nèi)控【】草稿作者最后完成日期【】修 改 稿【】正式發(fā)布審核人員最后審核日期批 準(zhǔn) 人最后批準(zhǔn)日期.修改記錄日期版本作者 / 修改者修訂類型描述2017-02-71.0修改根據(jù)原卡友智能的軟件測試過程進行修訂.目錄1導(dǎo)言.11.1概述 .11.2目標(biāo) .11.3適用范圍 .12測試職責(zé) .13測試需求分析 .24測試策略 .35測試計劃 .35.1測試進入條件 .35.2測試計劃 .36測試用例 .36.1測試用例操作步驟 .46.2測試用例選擇準(zhǔn)則 .46.3測試軟 / 硬件環(huán)境 .46.4測試數(shù)據(jù)準(zhǔn)備 .47測試執(zhí)行 .47.1項目測試周期

2、.47.2項目測試啟動 .47.3項目測試階段 .57.4項目測試結(jié)束 .57.5測試執(zhí)行過程績效考核 .58測試變更 .69缺陷管理 .79.1缺陷基本屬性 .79.2缺陷管理流程 .89.3缺陷分類 .99.4缺陷定義 .119.5缺陷完成度 .12.9.6處理機制 .1210測試結(jié)果分析 .1310.1測試完成的標(biāo)準(zhǔn) .1310.2保留的缺陷 .1310.3測試退出 .1411敏捷測試 .1512業(yè)務(wù)開發(fā)組測試與測試組測試的聯(lián)系與區(qū)別.1612.1職責(zé)上區(qū)別與聯(lián)系 .1612.2邊界的劃分 .16.1 導(dǎo)言1.1 概述制定本過程與規(guī)范的目的是為了規(guī)范軟件測試過程中的軟件測試活動，明確軟件

3、測試過程中業(yè)務(wù)單元開發(fā)小組的內(nèi)部測試與測試組之間的系統(tǒng)業(yè)務(wù)集成測試的關(guān)系與區(qū)別；明確軟件測試過程中的工作原則與方法。本規(guī)范作為軟件測試工作的標(biāo)準(zhǔn)與指南。1.2 目標(biāo)測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程”。為了更好地執(zhí)行好測試，我們明確以下目標(biāo)：1) 測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；2) 好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；3) 成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。1.3 適用范圍本規(guī)范是對項目軟件測試的一份指導(dǎo)性文件，對軟件測試過程中所涉及到的測試?yán)碚?、測試類型、測試方法、測試標(biāo)準(zhǔn)、測試流程以及軟件產(chǎn)品開發(fā)單位所承擔(dān)的職責(zé)進行總體

4、規(guī)范，以有效保證軟件產(chǎn)品的質(zhì)量。2 測試職責(zé)測試職責(zé)是指在項目開發(fā)過程中跟測試工作有關(guān)的角色分工，主要包含的角色以及工作職責(zé)如下：測試經(jīng)理：負責(zé)產(chǎn)品業(yè)務(wù)需求與測試任務(wù)的對接與安排；組織和指導(dǎo)測試組長完成項目的測試工作；負責(zé)測試組內(nèi)資源的協(xié)調(diào)和管理；定期組織測試的總結(jié)和分析；負責(zé)測試過程中與開發(fā)、產(chǎn)品的業(yè)務(wù)協(xié)調(diào)和業(yè)務(wù)確認(rèn)；測試組長（產(chǎn)品測試負責(zé)人）：分析需求并進行細化可用于執(zhí)行測試的需求制定測試計劃參與、跟蹤測試過程.統(tǒng)計測試數(shù)據(jù)對測試活動和結(jié)果進行分析，撰寫測試分析與總結(jié)報告測試工程師：根據(jù)測試計劃編寫測試用例搭建測試環(huán)境，準(zhǔn)備測試腳本執(zhí)行測試，記錄測試結(jié)果和缺陷，跟蹤缺陷的解決執(zhí)行回歸測試提

5、交測試數(shù)據(jù)技術(shù)支持工程師：環(huán)境支持版本發(fā)布支持3 測試需求分析首先了解產(chǎn)品或者客戶提出的業(yè)務(wù)需求功能、形成的產(chǎn)品需求， 以及本公司對需求的理解及說明，參加需求評審、 設(shè)計評審。 通過對文檔分析，分解各功能模塊和功能，為測試用例設(shè)計提供數(shù)據(jù)依據(jù)。反復(fù)檢查并理解各種信息，與產(chǎn)品或用戶交流，理解他們的要求?？梢园凑找韵虏襟E執(zhí)行：1）確定軟件提供的主要商業(yè)任務(wù)，即根據(jù)價值確定的需求。2）對每個商業(yè)任務(wù)，確定完成該任務(wù)所要進行的功能。3）確定從數(shù)據(jù)庫信息引出的計算結(jié)果。4）對于對時間有要求的交易，確定所要的時間和條件。這些條件包括數(shù)據(jù)庫大小、機器配置、交易量、以及網(wǎng)絡(luò)擁擠情況。5）確定會產(chǎn)生重大意外的壓

6、力測試，包括：內(nèi)存、硬盤空間、高頻度的交易。6）確定應(yīng)用需要處理的數(shù)據(jù)量。7）確定需要的軟件和硬件配置。通常情況下，不可能對所有可能的配置都測試到，因此要選擇最有可能產(chǎn)生問題的情況進行測試，包括：最低性能的硬件、幾個有兼容性問題的軟件并存、客戶端機器通過最慢的lan/wanf連接訪問服務(wù)器。8）確定其他與應(yīng)用軟件沒有直接關(guān)系的商業(yè)交易。包括：管理功能，如啟動和退出程序配置功能，如設(shè)置打印機操作員的愛好，如字體、顏色.應(yīng)用功能，如訪問email 或者顯示時間和日期。9）確定安裝與部署過程，包括定置從哪安裝、定制安裝、升級安裝。需要的部署物理結(jié)構(gòu)，機器配置等。10）確定沒有隱含在功能測試中的用戶界

7、面要求。大多界面都在功能測試時被測試到。還有些沒有測到，如：操作與顯示的一致性，如使用快捷鍵等；界面遵從合理標(biāo)準(zhǔn)，如按鈕大小，標(biāo)簽等。4 測試策略測試策略用于說明某項工作的測試方法與目標(biāo)。系統(tǒng)測試策略主要針對系統(tǒng)測試需求確定測試類型及實施的測試方法與技術(shù)。1. 采用的測試類型，對于測試案例的設(shè)計策略；2. 用于測試評估結(jié)果和測試是否完成的標(biāo)準(zhǔn)；3. 對測試策略所述的測試工作存在影響的特殊事項；4. 基于時間、進度、度量的軟件測試平衡策略的考慮；5 測試計劃5.1 測試進入條件項目啟動后，項目或者產(chǎn)品需求（ui 原型）完成并經(jīng)過評審；即可啟動測試工作；5.2 測試計劃根據(jù)測試的種類，測試計劃分為

8、功能測試和非功能測試計劃。測試計劃旨在說明各測試階段任務(wù)、人員分配、時間安排、測試要點、工作規(guī)范等。測試計劃在策略和方法方面說明如何計劃、組織和管理測試項目。測試計劃包含足夠的信息使測試工程師明白項目需要做什么是如何運作的。測試計劃不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。測試計劃應(yīng)附有測試功能點矩陣、測試性能點矩陣。測試計劃應(yīng)在項目組內(nèi)進行評審。參與測試計劃評審的人員包括：項目經(jīng)理、測試組長、開發(fā)組長、測試工程師。6 測試用例測試用例是為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設(shè)置以及期望結(jié)果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。從測試結(jié)構(gòu)上面劃分分為黑盒測試、

9、白盒測試2 種，他們各自有不同的測試方式，目前本公司只考慮黑盒測試，以下設(shè)計方法以黑盒方法為例。.6.1 測試用例操作步驟在設(shè)計編寫測試用例時，首先要從測試用例庫中選擇相應(yīng)功能的測試用例，在原有測試用例的基礎(chǔ)上依據(jù)系統(tǒng)需求文檔對測試用例的進行修改、更新，評審?fù)ㄟ^后將使用該測試用例測試被測系統(tǒng)。在測試項目結(jié)束后，統(tǒng)計分析所使用過的測試用例，進行分類放到相應(yīng)的測試用例庫中。為以后測試用例的設(shè)計編寫提供數(shù)據(jù)基礎(chǔ)。6.2 測試用例選擇準(zhǔn)則測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的, 以及極限的輸入數(shù)據(jù)、操作和環(huán)境設(shè)置等；測試結(jié)果的可判定性：即測試執(zhí)行結(jié)果的正確性是可判定

10、的或可評估的；測試結(jié)果的可再現(xiàn)性：即對同樣的測試用例, 系統(tǒng)的執(zhí)行結(jié)果應(yīng)當(dāng)是相同的。6.3 測試軟 / 硬件環(huán)境根據(jù)需求文檔提供的內(nèi)容，與研發(fā)溝通確定測試項目所需的軟硬件環(huán)境，完成對測試項目所需軟硬件資源的準(zhǔn)備工作，使軟硬件資源得到滿足。軟件硬件資源的確定需要在項目進入測試之前完成。完成對軟硬件資源的配置后，要進行對測試項目的軟硬件環(huán)境進行檢查，確認(rèn)對軟硬件資源配置的有效性。6.4 測試數(shù)據(jù)準(zhǔn)備完成對測試項目基本數(shù)據(jù)的準(zhǔn)備操作，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權(quán)限、單位組織等信息和測試相關(guān)的測試數(shù)據(jù)。7 測試執(zhí)行7.1 項目測試周期測試項目的測試周期可分為：單元測試、 接收測試、 集成測試、

11、 系統(tǒng)測試、 回歸測試、 性能測試、配置測試等等。根據(jù)不同項目或產(chǎn)品的特性，可以選型不同的測試周期，但集成測試、系統(tǒng)測試、回歸測試是必不可少的，性能測試根據(jù)具體產(chǎn)品與項目情況而定。7.2 項目測試啟動軟件項目測試活動的正式啟動，是在確認(rèn)軟件可測試性后展開的。軟件業(yè)務(wù)組內(nèi)的測試人員與開發(fā)人員需要一起完成代碼的單元測試并形成單元測試報告，單元測試效果通過接收測試驗證。.7.3 項目測試階段測試工程師依據(jù)測試計劃和測試用例進行測試活動。測試一般分為三個階段：1. 業(yè)務(wù)模塊組內(nèi)的單元測試與隨測，由業(yè)務(wù)模塊組內(nèi)的測試人員與開發(fā)人員共同一起完成；業(yè)務(wù)組的測試人員主要對業(yè)務(wù)模塊開發(fā)組的每天完成的功能進行隨測

12、，對已完成功能的核心代碼部分完成單元測試（白盒測試）；2. 集成測試、系統(tǒng)測試階段：該階段測試工程師實時提交缺陷，并跟蹤缺陷，驗證缺陷，直到提交的缺陷被關(guān)閉或被保留。 開發(fā)人員周期性提交修改過缺陷的新版本， 測試工程師在新版本上驗證缺陷。3. 回歸測試階段：在集成測試、系統(tǒng)測試階段完成后，產(chǎn)品將進入回歸測試階段。測試工程師對修改后的產(chǎn)品進行重新功能驗證， 確保修改的正確性， 驗證在修改缺陷的同時沒有引入新的問題。回歸缺陷是指開發(fā)人員標(biāo)示已修改的缺陷，經(jīng)測試后發(fā)現(xiàn)仍未修改正確，或引入其他缺陷，或在前一個版本中未發(fā)現(xiàn)的缺陷，在后一個版本中出現(xiàn)。4.在測試過程中，測試組長每天下班以前需要花15-30

13、 分鐘組織開發(fā)人員、測試工程師和項目經(jīng)理對 bug進行 review，由項目經(jīng)理給出bug相應(yīng)的解決時間。如產(chǎn)品進行性能測試，則需要在性能測試后，進行一輪回歸測試，確保功能的正確性。7.4 項目測試結(jié)束項目測試結(jié)束時應(yīng)達到測試質(zhì)量目標(biāo)所規(guī)定的標(biāo)準(zhǔn)。通過評審后結(jié)束該項目測試。7.5 測試執(zhí)行過程績效考核為促進開發(fā)人員積極主動做好質(zhì)量工作，對開發(fā)人員進行考核。序號開發(fā)人員考核內(nèi)容考核評分標(biāo)準(zhǔn)1開發(fā)人員提交的首個產(chǎn)品未通過單元測試標(biāo)準(zhǔn)。待定2開發(fā)人員無故將 【嚴(yán)重】、【非常嚴(yán)重】 級別無爭議的缺陷延期1 天修改。待定3開發(fā)人員未能正確修改缺陷，導(dǎo)致狀態(tài)為【已修改】的缺陷被【重新打待定開】，測試過程中

14、每天超過1 個。4開發(fā)人員千行缺陷代碼率在項目組中排名第一者待定5一個項目中【延遲修改】或【已知問題】的缺陷數(shù)超過總?cè)毕輸?shù)的10%待定.8 測試變更當(dāng)需求變更，功能變化時，產(chǎn)品經(jīng)理需要通知測試工程師，測試工程師根據(jù)變更情況，評估測試變更所需時間，提出變更風(fēng)險。測試組長要修改相應(yīng)的測試計劃，測試工程師要重新設(shè)計測試用例并組織完成評審或者經(jīng)過測試經(jīng)理的審查。.9 缺陷管理9.1 缺陷基本屬性缺陷是指在軟件開發(fā)過程中的針對軟件產(chǎn)品和開發(fā)過程中的問題，這些問題已經(jīng)影響或可能會影響軟件產(chǎn)品的質(zhì)量。缺陷應(yīng)該具備以下屬性，也就是往缺陷管理庫或者缺陷列表中提交的缺陷應(yīng)該具備以下屬性：屬 性 名 稱描 述缺陷標(biāo)

15、識標(biāo)記某個缺陷的一組符號，每個缺陷必須有一個唯一的標(biāo)識缺陷類型根據(jù)缺陷的自然屬性劃分的缺陷種類缺陷驗證程度因缺陷引起的故障對軟件產(chǎn)品的影響程度缺陷所處的模塊或子系缺陷分步的模塊或子系統(tǒng)統(tǒng)缺陷出現(xiàn)幾率指發(fā)現(xiàn)錯誤的幾率缺陷的重現(xiàn)步驟詳細的缺陷重現(xiàn)步驟附件與缺陷相關(guān)的附件（截圖、附件、用例等）備注對缺陷的其他描述.9.2 缺陷管理流程測試人員開發(fā)人員項目經(jīng)理提交 bug是否描述清晰是否需要修改否是是不正確是bug是否有爭議是是否需要延期修改是否修改正確否是修改 bug保留 bug正確關(guān)閉 bug否1) 提交缺陷測試工程師將缺陷填寫到管理工具中，選擇指派人為開發(fā)組長或相應(yīng)的開發(fā)人員。2) 分配缺陷開發(fā)

16、人員分別對自己收到的缺陷進行評審。評審后如果對提交的缺陷有疑問，可以與提交人協(xié)商。對未能達成一致的缺陷由項目經(jīng)理組織項目組成員評審。評審人員可以是項目組人員。如果缺陷初次分配的開發(fā)人員無法修改該缺陷，初次分配的開發(fā)人員可以將缺陷再次分配給其他開發(fā)人員。但為避免缺陷被多次分配，項目經(jīng)理應(yīng)跟蹤3 天以上未修改的缺陷。3) 修改缺陷開發(fā)人員對已確認(rèn)的缺陷進行修改，填寫修改記錄，修改缺陷狀態(tài)為“已修改”或其他狀態(tài)。4) 關(guān)閉缺陷測試工程師對已修改的缺陷進行驗證。如果已修改完成，測試工程師將缺陷狀態(tài)設(shè)置為關(guān)閉。如果沒有修改或引起回歸問題，將修改缺陷狀態(tài)為“重新開啟”或新增缺陷，由開發(fā)工程師繼續(xù)修改。5)

17、 保留缺陷對于有爭議的缺陷進行，將有項目經(jīng)理最終決定是否修改。如果缺陷是由于技術(shù)原因、版本原因不能修改，則保留該缺陷。.描 述文檔內(nèi)容缺失，或文檔應(yīng)該包括的范圍沒有涵蓋一致性問題有兩類：一是與源頭說明書不一致，比如需求和客戶業(yè)務(wù)需求不一致、設(shè)計與需求不一致等二是上下文或者與前提不一致文檔描述是錯誤的，不可實現(xiàn)或?qū)е洛e誤的輸出或結(jié)果該缺陷將會導(dǎo)致用戶功能的錯誤、不滿足、不可用內(nèi)容的描述不清楚、不能準(zhǔn)確表達、或表達的意思有歧義內(nèi)容組織邏輯不清楚、邏輯錯誤與最終用戶接口問題、與外部系統(tǒng)的接口問題、內(nèi)部子系統(tǒng)或模塊的接口問題輸入輸出不完整、不正確、不可測試或驗證內(nèi)容還需要進一步細化文檔的設(shè)計或?qū)崿F(xiàn)方式

18、存在性能問題文檔的設(shè)計或?qū)崿F(xiàn)方式存在安全性問題.9.3 缺陷分類1) 根據(jù)缺陷的定義，將缺陷分為如下列?文檔缺陷： 是指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、產(chǎn)品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定，被評審的對象包括最終出產(chǎn)物和中間過程產(chǎn)出物，比如需求文檔、設(shè)計文檔、計劃、報告、用例等缺 陷 分 類描述不完整不一致描述錯誤功能問題不清楚或有歧義邏輯錯誤接口問題輸入輸出問題不細化、描述不具體性能問題安全性問題? 代碼缺陷：是指對代碼進行同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷缺 陷 分 類描 述常量變量定義問題不滿足設(shè)計或需求編寫代碼不符合規(guī)范條件判斷處理.循環(huán)處理錯

19、誤異常處理算法邏輯問題注釋問題代碼冗余性能問題? 測試缺陷：是指由測試活動發(fā)現(xiàn)的測試對象（被測對象一般是指可運行的代碼、系統(tǒng)，不包括靜態(tài)測試發(fā)現(xiàn)的問題）的缺陷，測試活動包括單元測試、集成測試、系統(tǒng)測試、性能測試等? 過程缺陷：有稱為不符合項問題，是指通過過程審計、過程分析、管理評審、質(zhì)量評估、質(zhì)量審核等活動發(fā)現(xiàn)的關(guān)于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試工程師、項目經(jīng)理等缺 陷 類 型描 述功能錯誤影響了重要的特性、用戶界面、產(chǎn)品接口或全局?jǐn)?shù)據(jù)結(jié)構(gòu)，并且設(shè)計文檔需要爭取的變更。如邏輯、循環(huán)、遞歸、功能等缺陷結(jié)構(gòu)錯誤web應(yīng)用程序結(jié)構(gòu)化頁面無法顯示，或者顯示錯誤腳本錯誤web應(yīng)用程序當(dāng)中出

20、現(xiàn)腳本錯誤， 包括客戶端對數(shù)據(jù)進行校驗和運算的各種情況下產(chǎn)生的錯誤頁面鏈接錯誤web應(yīng)用程序頁面出現(xiàn)空鏈接、錯誤鏈接、死鏈接頁面文字錯誤web應(yīng)用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編碼錯誤頁面圖形錯誤web應(yīng)用程序頁面出現(xiàn)圖片內(nèi)容使用不當(dāng)，或者無法顯示alt 錯誤web應(yīng)用程序頁面當(dāng)中超文本標(biāo)識語言、文本標(biāo)簽解釋錯誤排版錯誤web應(yīng)用程序頁面排版不符合要求或者不符合使用習(xí)慣業(yè)務(wù)邏輯不合理應(yīng)用程序的實現(xiàn)流程和規(guī)定業(yè)務(wù)流程不一致，或者實現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的部分并行、爭用、同步等操作，引起的流程斷裂、死鎖、以及其他異常情況.業(yè)務(wù)邏輯不方便應(yīng)用程序?qū)崿F(xiàn)流程在實際情況下雖然

21、可以完成，但是存在不必要的反復(fù)、等待、冗余等影響使用效率的情況其他錯誤其他未分類錯誤建議系統(tǒng)改進建議9.4 缺陷定義1) 缺陷等級定義缺陷的嚴(yán)重程度對以上所述的缺陷類型都是適合的，缺陷的嚴(yán)重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。缺陷等級缺陷性質(zhì)系統(tǒng)中對應(yīng)的錯誤分類一級致命錯誤系統(tǒng)崩潰、死鎖閃退二級嚴(yán)重缺陷嚴(yán)重錯誤描述導(dǎo)致對被描述的主要對象的理解錯誤、不可行、不可運轉(zhuǎn)、對業(yè)務(wù)和整個系統(tǒng)造成重大損失或損害；對產(chǎn)品的基本功能有致命影響的缺陷。對被描述的部分對象的理解或?qū)崿F(xiàn)錯誤，部分的模塊或系統(tǒng)不可行或不能運轉(zhuǎn)或部分模塊和系統(tǒng)缺失，對整個系統(tǒng)有重大影響或可能造成部分的損失或損害；系

22、統(tǒng)實現(xiàn)功能與需求不符。三級一般缺陷次要錯誤布局不合理文字錯誤四級微小缺陷微不足道系統(tǒng)中部分單元模塊或單個功能描述和實現(xiàn)有錯誤、有偏差、不一致或有缺失，不影響模塊的正常運行，或有影響，但可以有替代的辦法或避免辦法基本不影響系統(tǒng)的運行和功能的實現(xiàn)。但是與標(biāo)準(zhǔn)、規(guī)范和定義不一致五級建議缺陷新特性不在定義、標(biāo)準(zhǔn)、范圍的定義和約束之內(nèi)，但是從提出者來看是需要完善的建議2) 缺陷優(yōu)先級定義缺 陷 優(yōu) 先 級描 述緊急需要立刻進行修改高在 1-2 天之內(nèi)必須修改完成.中缺陷需要正常排隊等待修復(fù)低留到組后解決，如果項目的進度緊張可以在產(chǎn)品發(fā)布以前不解決3) 缺陷狀態(tài)定義缺 陷 狀 態(tài)描 述初始狀態(tài)（ new）

23、測試或開發(fā)人員提交一個新的缺陷，等待開發(fā)人員或項目經(jīng)理分配修改負責(zé)人打回（ feedback）要求缺陷的報告者再次對缺陷進行說明已分配（ assigned ）是指已經(jīng)分配給屬主，等待修改。已解決（ resolved ）缺陷被屬主修改，等待測試工程師驗證關(guān)閉（ closed ）測試工程師驗證缺陷已經(jīng)修復(fù)重新打開（ reopen）測試工程師驗證，缺陷沒有修改正確遺留（ later ）經(jīng)項目經(jīng)理和技術(shù)經(jīng)理驗證此缺陷在本版本中不用修改9.5 缺陷完成度缺 陷 完 成 度描 述打開（ open）缺陷沒有被解決已解決（ fixed ）缺陷已經(jīng)修改遺留（ suspended）此缺陷步驟本階段解決重新打開（

24、reopen）重新打開某個缺陷不做修改（ won t fix）不對這個缺陷進行修改重復(fù)（ duplicate ）與某個缺陷重復(fù)需求如此技術(shù)經(jīng)理和開發(fā)人員經(jīng)過需求和設(shè)計的核實后決定不需要修改不可重現(xiàn)被指派的開發(fā)人員想要再現(xiàn)缺陷進行修改個時候，發(fā)現(xiàn)缺陷始終不能再現(xiàn)9.6 處理機制1) 退回機制若在測試過程中發(fā)生如下情況，將系統(tǒng)退回到業(yè)務(wù)開發(fā)組或相應(yīng)的版本提交人中員：.? 經(jīng)過測試后，發(fā)現(xiàn)與需求說明規(guī)格說明書中定義的功能項存較大的差異。? 單一模塊，測試過程中發(fā)現(xiàn)缺陷較多或者無法繼續(xù)進行系統(tǒng)其它功能模塊的測試，繼續(xù)測試無意義。?測試過程中，頻繁死機、系統(tǒng)崩潰或者應(yīng)用閃退（單次版本出現(xiàn)三次以上）。?

25、主業(yè)務(wù)流程出現(xiàn)斷點。2) 報告機制若出現(xiàn)以下情況，需要及時向部門領(lǐng)導(dǎo)匯報的情況：? 測試后期出現(xiàn)重大邏輯錯誤，修改測試影響上線時間? 測試過程中需求出現(xiàn)重大變更? 測試負責(zé)人定期匯報測試情況10 測試結(jié)果分析10.1 測試完成的標(biāo)準(zhǔn)被測試出的、在軟件錯誤級別分類中定義的：? 一級缺陷，致命錯誤， 100%得到修改并且復(fù)測通過? 二級缺陷，嚴(yán)重錯誤， 100%得到修改并且復(fù)測通過? 三級缺陷，較大錯誤， 100%得到修改并且復(fù)測通過? 四級缺陷，一般錯誤， 90%得到修改并且復(fù)測通過? 五級缺陷，輕微錯誤， 85%得到修改并且復(fù)測通過10.2 保留的缺陷測試超過了預(yù)定時間表，由項目經(jīng)理組織確定是

26、否停止測試，如果停止測試需要獲得質(zhì)量總監(jiān)的同意。測試結(jié)論及評價標(biāo)準(zhǔn)如下：測試結(jié)論評價標(biāo)準(zhǔn)測試未通過遺留了一級、二級缺陷測試通過版本不能遺留一、二類缺陷三類一般缺陷90%得到修改并且通過復(fù)測四類輕微缺陷85%得到修改并且通過復(fù)測推薦使用版本不能遺留一、二類缺陷三類一般缺陷90%得到修改并且通過復(fù)測四類輕微缺陷85%得到修改并且通過復(fù)測.可以證實發(fā)布版本不能遺留一、二類缺陷三類一般缺陷95%得到修改并且通過復(fù)測四類輕微缺陷90%得到修改并且通過復(fù)測測試結(jié)果分析是對測試結(jié)果的一個綜合評估，主要描述有測試中各個等級的缺陷數(shù)量，缺陷分布情況，缺陷修改情況、回歸測試提交缺陷數(shù)量，性能測試指標(biāo)情況。測試報告

27、由測試組長編寫并提交給項目經(jīng)理，且項目組內(nèi)評審確定、由質(zhì)量總監(jiān)進行審批。10.3 測試退出當(dāng)軟件測試總結(jié)完成，被測試的產(chǎn)品獲得相應(yīng)的測試評估的結(jié)果，即本輪次或者本產(chǎn)品的測試即完成。.11 敏捷測試.1、驗證需求和設(shè)計2、編寫計劃和用例2.1 編寫計劃2.2 編寫用例2.3 評審用例測試工程師的重點是審核和檢查文本對用戶需求定義的完整性、嚴(yán)密性和功能設(shè)計的可測性；在測試初期，測試工程師學(xué)會做靜態(tài)測試（針對于項目或者產(chǎn)品的 ui 原型、 prd 文檔），做好測試需求分析，設(shè)計邏輯的分析。測試工程師更多的是的思考需求的可實現(xiàn)性，將自身作為第一用戶積極參與項目和系統(tǒng)的需求分析，設(shè)計和開發(fā)。積極地參與前

28、期工作，并迅速反饋給設(shè)計和開發(fā)其靜態(tài)測試結(jié)果。要盡早的開始測試，不要等待到功能完全做好才開始。根據(jù)每次沖剌或迭代所確定的 features （特性與需求）的優(yōu)先級來制定測試計劃，需要包括測試的范圍、測試的工作量評估、測試的策略及時間任務(wù)安排，所需要的測試資源的計劃。測試案例的編寫顆粒度依據(jù)項目的具體情況而定，可以是簡要的測試大綱與要點的形式，也可以是涉及到具體的參數(shù)、步聚和數(shù)據(jù)的設(shè)計。為使開發(fā)人員能參與到測試案例的review 中來，以保證測試案例的質(zhì)量和可行性，確保測試工作的順利進行，讓開發(fā)人員迅速地了解測試的重點并給出相應(yīng)的意見和建議，測試人員在寫測試案例的同時，需要形成 test cas

29、e跟蹤矩陣，其中注明tc 已覆蓋了哪些features，具體每個features對應(yīng)的測試案例，這樣在測試經(jīng)理和 sm 對測試案例進行 review 的時候，能夠?qū)?tc 的覆蓋率一目了然，對覆蓋率不足的地方能夠及時給出意見3、測試執(zhí)行3.1 單元測試在日構(gòu)建版本給測試前，開發(fā)首先要做單元測試，提前告知軟件中的薄弱環(huán)節(jié)，幫助測試工程師調(diào)整測試重點。3.2 驗證測試這一階段的測試需要在計劃下進行。這種計劃性首先體現(xiàn)在開發(fā)和測試的相互協(xié)調(diào)配合，根據(jù)產(chǎn)品的架構(gòu)和功能模塊的依賴關(guān)系，按照項目的總體計劃共同推進。從測試的過程來看，測試執(zhí)行的一開始可以是針對部分功能的，之后可以逐步擴展。接著開始采用迭代的

30、過程完成測試任務(wù)，即將測試任務(wù)劃分為多個周期，一開始可以做些關(guān)鍵的功能性測試，可以對代碼中的可復(fù)用部分（組件，構(gòu)件）做完整的測試。接著的迭代周期可以做邊緣化的功能測試和其他測試，最后的幾個迭代應(yīng)該用于回歸測試，和關(guān)鍵的性能和穩(wěn)定性測試。3.3 每天提供為方便衡量項目的進度，測試可每天測試完畢后提供測試的bug 趨勢，即將每天新生成的bug 數(shù)和每天被bug 趨勢分析解決的 bug 數(shù)標(biāo)成一個趨勢圖表。一般在項目的開始階段新生bug 數(shù)曲線會呈上升趨勢，到項目中后期被解決 bug 數(shù)曲線會趨于上升，而新生bug 數(shù)曲線應(yīng)下降，到項目最后，兩條曲線都趨向于零。pm 會持續(xù)觀察這張圖表，確保項目健康發(fā)展，同時通過分析預(yù)測項目bug ，對于每個版本的bug ，開發(fā)都應(yīng)該想想為什么會出現(xiàn)這樣的問題，特別是很低級的bug ，對于同類的bug ，是否可以避免。3.4 測試用例維護3.5 控制中間版本在執(zhí)行測試過程中，測試工程師需要對已有的測試用例進行及時的維護。通常以下兩種情況下要新增一些測試用例：一是對于當(dāng)初測試設(shè)計不周全的領(lǐng)域，二是對于外部的 bug ，沒有被現(xiàn)有測試用例所覆蓋。當(dāng)產(chǎn)品的功能設(shè)計出現(xiàn)更改時（敏捷項目中功能設(shè)計的更改頻繁），所涉及的測試用例也要相應(yīng)地修改，使測試用例保持和現(xiàn)有的功能需求同步。為更好地保