軟件測試管理手冊文件狀態(tài)：【】草稿【】修改稿【√】正式發(fā)布文檔編號保密等級內控作者最后完成日期審核人員最后審核日期批準人最后批準日期修改記錄日期版本作者/修改者修訂類型描述2017-02-71.0修改根據(jù)原卡友智能的軟件測試過程進展修訂目錄TOC\o\h\z\u1導言11.1概述11.2目標11.3適用*圍12測試職責13測試需求分析24測試策略35測試方案35.1測試進入條件35.2測試方案36測試用例36.1測試用例操作步驟46.2測試用例選擇準則46.3測試軟/硬件環(huán)境46.4測試數(shù)據(jù)準備47測試執(zhí)行47.1工程測試周期47.2工程測試啟動47.3工程測試階段57.4工程測試完畢57.5測試執(zhí)行過程績效考核58測試變更69缺陷管理79.1缺陷根本屬性79.2缺陷管理流程89.3缺陷分類99.4缺陷定義119.5缺陷完成度129.6處理機制1210測試結果分析1310.1測試完成的標準1310.2保存的缺陷1310.3測試退出1411敏捷測試1512業(yè)務開發(fā)組測試與測試組測試的聯(lián)系與區(qū)別1612.1職責上區(qū)別與聯(lián)系1612.2邊界的劃分16導言概述制定本過程與規(guī)*的目的是為了規(guī)*軟件測試過程中的軟件測試活動，明確軟件測試過程中業(yè)務單元開發(fā)小組的內部測試與測試組之間的系統(tǒng)業(yè)務集成測試的關系與區(qū)別；明確軟件測試過程中的工作原則與方法。本規(guī)*作為軟件測試工作的標準與指南。目標測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程〞。為了更好地執(zhí)行好測試，我們明確以下目標：測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。適用*圍本規(guī)*是對工程軟件測試的一份指導性文件，對軟件測試過程中所涉及到的測試理論、測試類型、測試方法、測試標準、測試流程以及軟件產品開發(fā)單位所承當?shù)穆氊熯M展總體規(guī)*，以有效保證軟件產品的質量。測試職責測試職責是指在工程開發(fā)過程中跟測試工作有關的角色分工，主要包含的角色以及工作職責如下：測試經(jīng)理：負責產品業(yè)務需求與測試任務的對接與安排；組織和指導測試組長完成工程的測試工作；負責測試組內資源的協(xié)調和管理；定期組織測試的總結和分析；負責測試過程中與開發(fā)、產品的業(yè)務協(xié)調和業(yè)務確認；測試組長〔產品測試負責人〕：分析需求并進展細化可用于執(zhí)行測試的需求制定測試方案參與、跟蹤測試過程統(tǒng)計測試數(shù)據(jù)對測試活動和結果進展分析，撰寫測試分析與總結報告測試工程師：根據(jù)測試方案編寫測試用例搭建測試環(huán)境，準備測試腳本執(zhí)行測試，記錄測試結果和缺陷，跟蹤缺陷的解決執(zhí)行回歸測試提交測試數(shù)據(jù)技術支持工程師：環(huán)境支持版本發(fā)布支持測試需求分析首先了解產品或者客戶提出的業(yè)務需求功能、形成的產品需求，以及本公司對需求的理解及說明，參加需求評審、設計評審。通過對文檔分析，分解各功能模塊和功能，為測試用例設計提供數(shù)據(jù)依據(jù)。反復檢查并理解各種信息，與產品或用戶交流，理解他們的要求。可以按照以下步驟執(zhí)行：1〕確定軟件提供的主要商業(yè)任務，即根據(jù)價值確定的需求。2〕對每個商業(yè)任務，確定完成該任務所要進展的功能。3〕確定從數(shù)據(jù)庫信息引出的計算結果。4〕對于對時間有要求的交易，確定所要的時間和條件。這些條件包括數(shù)據(jù)庫大小、機器配置、交易量、以及網(wǎng)絡擁擠情況。5〕確定會產生重大意外的壓力測試，包括：內存、硬盤空間、高頻度的交易。6〕確定應用需要處理的數(shù)據(jù)量。7〕確定需要的軟件和硬件配置。通常情況下，不可能對所有可能的配置都測試到，因此要選擇最有可能產生問題的情況進展測試，包括：最低性能的硬件、幾個有兼容性問題的軟件并存、客戶端機器通過最慢的LAN/WANF連接訪問效勞器。8〕確定其他與應用軟件沒有直接關系的商業(yè)交易。包括：管理功能，如啟動和退出程序配置功能，如設置打印機操作員的愛好，如字體、顏色應用功能，如訪問email或者顯示時間和日期。9〕確定安裝與部署過程，包括定置從哪安裝、定制安裝、升級安裝。需要的部署物理構造，機器配置等。10〕確定沒有隱含在功能測試中的用戶界面要求。大多界面都在功能測試時被測試到。還有些沒有測到，如：操作與顯示的一致性，如使用快捷鍵等；界面遵從合理標準，如按鈕大小，標簽等。測試策略測試策略用于說明*項工作的測試方法與目標。系統(tǒng)測試策略主要針對系統(tǒng)測試需求確定測試類型及實施的測試方法與技術。采用的測試類型，對于測試案例的設計謀略；用于測試評估結果和測試是否完成的標準；對測試策略所述的測試工作存在影響的特殊事項；基于時間、進度、度量的軟件測試平衡策略的考慮；測試方案測試進入條件工程啟動后，工程或者產品需求〔UI原型〕完成并經(jīng)過評審；即可啟動測試工作；測試方案根據(jù)測試的種類，測試方案分為功能測試和非功能測試方案。測試方案旨在說明各測試階段任務、人員分配、時間安排、測試要點、工作規(guī)*等。測試方案在策略和方法方面說明如何方案、組織和管理測試工程。測試方案包含足夠的信息使測試工程師明白工程需要做什么是如何運作的。測試方案不包括測試用例的細節(jié)和系統(tǒng)功能的詳細信息。測試方案應附有測試功能點矩陣、測試性能點矩陣。測試方案應在工程組內進展評審。參與測試方案評審的人員包括：工程經(jīng)理、測試組長、開發(fā)組長、測試工程師。測試用例測試用例是為實施測試而向被測試系統(tǒng)提供的輸入數(shù)據(jù)、操作或各種環(huán)境設置以及期望結果的一個特定的集合。解決要測什么、怎么測和如何衡量的問題。從測試構造上面劃分分為黑盒測試、白盒測試2種，他們各自有不同的測試方式，目前本公司只考慮黑盒測試，以下設計方法以黑盒方法為例。測試用例操作步驟在設計編寫測試用例時，首先要從測試用例庫中選擇相應功能的測試用例，在原有測試用例的根底上依據(jù)系統(tǒng)需求文檔對測試用例的進展修改、更新，評審通過后將使用該測試用例測試被測系統(tǒng)。在測試工程完畢后，統(tǒng)計分析所使用過的測試用例，進展分類放到相應的測試用例庫中。為以后測試用例的設計編寫提供數(shù)據(jù)根底。測試用例選擇準則測試用例的代表性：能夠代表各種合理和不合理的、合法的和非法的、邊界和越界的,以及極限的輸入數(shù)據(jù)、操作和環(huán)境設置等；測試結果的可判定性：即測試執(zhí)行結果的正確性是可判定的或可評估的；測試結果的可再現(xiàn)性：即對同樣的測試用例,系統(tǒng)的執(zhí)行結果應當是一樣的。測試軟/硬件環(huán)境根據(jù)需求文檔提供的內容，與研發(fā)溝通確定測試工程所需的軟硬件環(huán)境，完成對測試工程所需軟硬件資源的準備工作，使軟硬件資源得到滿足。軟件硬件資源確實定需要在工程進入測試之前完成。完成對軟硬件資源的配置后，要進展對測試工程的軟硬件環(huán)境進展檢查，確認對軟硬件資源配置的有效性。測試數(shù)據(jù)準備完成對測試工程根本數(shù)據(jù)的準備操作，包括數(shù)據(jù)庫連接、用戶信息、用戶角色權限、單位組織等信息和測試相關的測試數(shù)據(jù)。測試執(zhí)行工程測試周期測試工程的測試周期可分為：單元測試、接收測試、集成測試、系統(tǒng)測試、回歸測試、性能測試、配置測試等等。根據(jù)不同工程或產品的特性，可以選型不同的測試周期，但集成測試、系統(tǒng)測試、回歸測試是必不可少的，性能測試根據(jù)具體產品與工程情況而定。工程測試啟動軟件工程測試活動的正式啟動，是在確認軟件可測試性后展開的。軟件業(yè)務組內的測試人員與開發(fā)人員需要一起完成代碼的單元測試并形成"單元測試報告"，單元測試效果通過接收測試驗證。工程測試階段測試工程師依據(jù)測試方案和測試用例進展測試活動。測試一般分為三個階段：業(yè)務模塊組內的單元測試與隨測，由業(yè)務模塊組內的測試人員與開發(fā)人員共同一起完成；業(yè)務組的測試人員主要對業(yè)務模塊開發(fā)組的每天完成的功能進展隨測，對已完成功能的核心代碼局部完成單元測試〔白盒測試〕；集成測試、系統(tǒng)測試階段：該階段測試工程師實時提交缺陷，并跟蹤缺陷，驗證缺陷，直到提交的缺陷被關閉或被保存。開發(fā)人員周期性提交修改正缺陷的新版本，測試工程師在新版本上驗證缺陷。回歸測試階段：在集成測試、系統(tǒng)測試階段完成后，產品將進入回歸測試階段。測試工程師對修改后的產品進展重新功能驗證，確保修改的正確性，驗證在修改缺陷的同時沒有引入新的問題。回歸缺陷是指開發(fā)人員標示已修改的缺陷，經(jīng)測試后發(fā)現(xiàn)仍未修改正確，或引入其他缺陷，或在前一個版本中未發(fā)現(xiàn)的缺陷，在后一個版本中出現(xiàn)。在測試過程中，測試組長每天下班以前需要花15-30分鐘組織開發(fā)人員、測試工程師和工程經(jīng)理對BUG進展REVIEW，由工程經(jīng)理給出BUG相應的解決時間。如產品進展性能測試，則需要在性能測試后，進展一輪回歸測試，確保功能的正確性。工程測試完畢工程測試完畢時應到達測試質量目標所規(guī)定的標準。通過評審后完畢該工程測試。測試執(zhí)行過程績效考核為促進開發(fā)人員積極主動做好質量工作，對開發(fā)人員進展考核。序號開發(fā)人員考核內容考核評分標準1開發(fā)人員提交的首個產品未通過單元測試標準。待定2開發(fā)人員無故將【嚴重】、【非常嚴重】級別無爭議的缺陷延期1天修改。待定3開發(fā)人員未能正確修改缺陷，導致狀態(tài)為【已修改】的缺陷被【重新翻開】，測試過程中每天超過1個。待定4開發(fā)人員千行缺陷代碼率在工程組中排名第一者待定5一個工程中【延遲修改】或【問題】的缺陷數(shù)超過總缺陷數(shù)的10%待定測試變更當需求變更，功能變化時，產品經(jīng)理需要通知測試工程師，測試工程師根據(jù)變更情況，評估測試變更所需時間，提出變更風險。測試組長要修改相應的測試方案，測試工程師要重新設計測試用例并組織完成評審或者經(jīng)過測試經(jīng)理的審查。缺陷管理缺陷根本屬性缺陷是指在軟件開發(fā)過程中的針對軟件產品和開發(fā)過程中的問題，這些問題已經(jīng)影響或可能會影響軟件產品的質量。缺陷應該具備以下屬性，也就是往缺陷管理庫或者缺陷列表中提交的缺陷應該具備以下屬性：屬性名稱描述缺陷標識標記*個缺陷的一組符號，每個缺陷必須有一個唯一的標識缺陷類型根據(jù)缺陷的自然屬性劃分的缺陷種類缺陷驗證程度因缺陷引起的故障對軟件產品的影響程度缺陷所處的模塊或子系統(tǒng)缺陷分步的模塊或子系統(tǒng)缺陷出現(xiàn)幾率指發(fā)現(xiàn)錯誤的幾率缺陷的重現(xiàn)步驟詳細的缺陷重現(xiàn)步驟與缺陷相關的〔截圖、、用例等〕備注對缺陷的其他描述缺陷管理流程提交缺陷測試工程師將缺陷填寫到管理工具中，選擇指派人為開發(fā)組長或相應的開發(fā)人員。分配缺陷開發(fā)人員分別對自己收到的缺陷進展評審。評審后如果對提交的缺陷有疑問，可以與提交人協(xié)商。對未能達成一致的缺陷由工程經(jīng)理組織工程組成員評審。評審人員可以是工程組人員。如果缺陷初次分配的開發(fā)人員無法修改該缺陷，初次分配的開發(fā)人員可以將缺陷再次分配給其他開發(fā)人員。但為防止缺陷被屢次分配，工程經(jīng)理應跟蹤3天以上未修改的缺陷。修改缺陷開發(fā)人員對已確認的缺陷進展修改，填寫修改記錄，修改缺陷狀態(tài)為“已修改〞或其他狀態(tài)。關閉缺陷測試工程師對已修改的缺陷進展驗證。如果已修改完成，測試工程師將缺陷狀態(tài)設置為關閉。如果沒有修改或引起回歸問題，將修改缺陷狀態(tài)為“重新開啟〞或新增缺陷，由開發(fā)工程師繼續(xù)修改。保存缺陷對于有爭議的缺陷進展，將有工程經(jīng)理最終決定是否修改。如果缺陷是由于技術原因、版本原因不能修改，則保存該缺陷。缺陷分類根據(jù)缺陷的定義，將缺陷分為如以下文檔缺陷：是指對文檔的靜態(tài)檢查過程中發(fā)現(xiàn)的缺陷。檢查活動包括同行評審、產品審計等。評審的缺陷要根據(jù)被評審對象的類型來確定，被評審的對象包括最終出產物和中間過程產出物，比方需求文檔、設計文檔、方案、報告、用例等缺陷分類描述描述不完整文檔內容缺失，或文檔應該包括的*圍沒有涵蓋不一致一致性問題有兩類：一是與源頭說明書不一致，比方需求和客戶業(yè)務需求不一致、設計與需求不一致等二是上下文或者與前提不一致描述錯誤文檔描述是錯誤的，不可實現(xiàn)或導致錯誤的輸出或結果功能問題該缺陷將會導致用戶功能的錯誤、不滿足、不可用不清楚或有歧義內容的描述不清楚、不能準確表達、或表達的意思有歧義邏輯錯誤內容組織邏輯不清楚、邏輯錯誤接口問題與最終用戶接口問題、與外部系統(tǒng)的接口問題、內部子系統(tǒng)或模塊的接口問題輸入輸出問題輸入輸出不完整、不正確、不可測試或驗證不細化、描述不具體內容還需要進一步細化性能問題文檔的設計或實現(xiàn)方式存在性能問題平安性問題文檔的設計或實現(xiàn)方式存在平安性問題代碼缺陷：是指對代碼進展同行評審、審計或代碼走查過程中發(fā)現(xiàn)的缺陷缺陷分類描述常量變量定義問題不滿足設計或需求編寫代碼不符合規(guī)*條件判斷處理循環(huán)處理錯誤異常處理算法邏輯問題注釋問題代碼冗余性能問題測試缺陷：是指由測試活動發(fā)現(xiàn)的測試對象〔被測對象一般是指可運行的代碼、系統(tǒng)，不包括靜態(tài)測試發(fā)現(xiàn)的問題〕的缺陷，測試活動包括單元測試、集成測試、系統(tǒng)測試、性能測試等過程缺陷：有稱為不符合項問題，是指通過過程審計、過程分析、管理評審、質量評估、質量審核等活動發(fā)現(xiàn)的關于過程的缺陷和問題。過程缺陷的發(fā)現(xiàn)者一般是測試工程師、工程經(jīng)理等缺陷類型描述功能錯誤影響了重要的特性、用戶界面、產品接口或全局數(shù)據(jù)構造，并且設計文檔需要爭取的變更。如邏輯、循環(huán)、遞歸、功能等缺陷構造錯誤Web應用程序構造化頁面無法顯示，或者顯示錯誤腳本錯誤Web應用程序當中出現(xiàn)腳本錯誤，包括客戶端對數(shù)據(jù)進展校驗和運算的各種情況下產生的錯誤頁面錯誤Web應用程序頁面出現(xiàn)空、錯誤、死頁面文字錯誤Web應用程序頁面出現(xiàn)的中外文拼寫、使用、以及不同語種頁面的編碼錯誤頁面圖形錯誤Web應用程序頁面出現(xiàn)圖片內容使用不當，或者無法顯示ALT錯誤Web應用程序頁面當中超文本標識語言、文本標簽解釋錯誤排版錯誤Web應用程序頁面排版不符合要求或者不符合使用習慣業(yè)務邏輯不合理應用程序的實現(xiàn)流程和規(guī)定業(yè)務流程不一致，或者實現(xiàn)流程無法正確完成。包括流程數(shù)據(jù)的局部并行、爭用、同步等操作，引起的流程斷裂、死鎖、以及其他異常情況業(yè)務邏輯不方便應用程序實現(xiàn)流程在實際情況下雖然可以完成，但是存在不必要的反復、等待、冗余等影響使用效率的情況其他錯誤其他未分類錯誤建議系統(tǒng)改良建議缺陷定義缺陷等級定義缺陷的嚴重程度對以上所述的缺陷類型都是適合的，缺陷的嚴重程度反映的是對缺陷的發(fā)現(xiàn)對象可能造成的影響或后果來定義的。缺陷等級缺陷性質系統(tǒng)中對應的錯誤分類描述一級致命錯誤系統(tǒng)崩潰、死鎖閃退導致對被描述的主要對象的理解錯誤、不可行、不可運轉、對業(yè)務和整個系統(tǒng)造成重大損失或損害；對產品的根本功能有致命影響的缺陷。二級嚴重缺陷嚴重錯誤對被描述的局部對象的理解或實現(xiàn)錯誤，局部的模塊或系統(tǒng)不可行或不能運轉或局部模塊和系統(tǒng)缺失，對整個系統(tǒng)有重大影響或可能造成局部的損失或損害；系統(tǒng)實現(xiàn)功能與需求不符。三級一般缺陷次要錯誤布局不合理文字錯誤系統(tǒng)中局部單元模塊或單個功能描述和實現(xiàn)有錯誤、有偏差、不一致或有缺失，不影響模塊的正常運行，或有影響，但可以有替代的方法或防止方法四級微小缺陷微缺乏道根本不影響系統(tǒng)的運行和功能的實現(xiàn)。但是與標準、規(guī)*和定義不一致五級建議缺陷新特性不在定義、標準、*圍的定義和約束之內，但是從提出者來看是需要完善的建議缺陷優(yōu)先級定義缺陷優(yōu)先級描述緊急需要立刻進展修改高在1-2天之內必須修改完成中缺陷需要正常排隊等待修復低留到組后解決，如果工程的進度緊*可以在產品發(fā)布以前不解決缺陷狀態(tài)定義缺陷狀態(tài)描述初始狀態(tài)〔New〕測試或開發(fā)人員提交一個新的缺陷，等待開發(fā)人員或工程經(jīng)理分配修改負責人打回〔FeedBack〕要求缺陷的報告者再次對缺陷進展說明已分配〔Assigned〕是指已經(jīng)分配給屬主，等待修改。已解決〔Resolved〕缺陷被屬主修改，等待測試工程師驗證關閉〔Closed〕測試工程師驗證缺陷已經(jīng)修復重新翻開〔Reopen〕測試工程師驗證，缺陷沒有修改正確遺留〔Later〕經(jīng)工程經(jīng)理和技術經(jīng)理驗證此缺陷在本版本中不用修改缺陷完成度缺陷完成度描述翻開〔Open〕缺陷沒有被解決已解決〔Fi*ed〕缺陷已經(jīng)修改遺留〔Suspended〕此缺陷步驟本階段解決重新翻開〔Reopen〕重新翻開*個缺陷不做修改〔Won’tfi*〕不對這個缺陷進展修改重復〔Duplicate〕與*個缺陷重復需求如此技術經(jīng)理和開發(fā)人員經(jīng)過需求和設計的核實后決定不需要修改不可重現(xiàn)被指派的開發(fā)人員想要再現(xiàn)缺陷進展修改個時候，發(fā)現(xiàn)缺陷始終不能再現(xiàn)處理機制退回機制假設在測試過程中發(fā)生如下情況，將系統(tǒng)退回到業(yè)務開發(fā)組或相應的版本提交人中員：經(jīng)過測試后，發(fā)現(xiàn)與需求說明規(guī)格說明書中定義的功能項存較大的差異。單一模塊，測試過程中發(fā)現(xiàn)缺陷較多或者無法繼續(xù)進展系統(tǒng)其它功能模塊的測試，繼續(xù)測試無意義。測試過程中，頻繁死機、系統(tǒng)崩潰或者應用閃退〔單次版本出現(xiàn)三次以上〕。主業(yè)務流程出現(xiàn)斷點。報告機制假設出現(xiàn)以下情況，需要及時向部門領導匯報的情況：測試后期出現(xiàn)重大邏輯錯誤，修改測試影響上線時間測試過程中需求出現(xiàn)重大變更測試負責人定期匯報測試情況測試結果分析測試完成的標準被測試出的、在軟件錯誤級別分類中定義的：一級缺陷，致命錯誤，100%得到修改并且復測通過二級缺陷，嚴重錯誤，100%得到修改并且復測通過三級缺陷，較大錯誤，100%得到修改并且復測通過四級缺陷，一般錯誤，90%得到修改并且復測通過五級缺陷，輕微錯誤，85%得到修改并且復測通過保存的缺陷測試超過了預定時間表，由工