１０.１過程模型軟件測試和軟件開發(fā)一樣.都遵循軟件工程原理和管理學(xué)原理.第二章著重從軟件生命周期的角度介紹了瀑布模型、漸增模型、快速原型模型、螺旋模型、噴泉模型等軟件開發(fā)過程模型.這些模型對軟件開發(fā)過程具有很好的指導(dǎo)作用.但利用這些模型無法更好地指導(dǎo)測試實踐.軟件測試的地位和價值并沒有體現(xiàn)出來.測試專家通過實踐總結(jié)出了許多測試模型.這些模型對測試活動進行了抽象.明確了測試與開發(fā)之間的關(guān)系.是測試管理的重要參考依據(jù).本章基于軟件測試模型演變的過程對目前常用的一些模型作簡單介紹.下一頁返回１０.１過程模型10.1.1Ｖ模型在軟件測試方面.Ｖ模型是最廣為人知的模型.如圖１０－１所示.Ｖ模型已存在了很長時間.和瀑布模型有一些共同的特性.因此它也像瀑布模型一樣受到了批評和質(zhì)疑.Ｖ模型中的過程從左到右.描述了基本的開發(fā)過程和測試行為.Ｖ模型的價值在于它非常明確地標明了測試過程中存在的不同級別.并且清楚地描述了這些測試階段和開發(fā)過程中各階段的對應(yīng)關(guān)系.Ｖ模型也有一定的局限性.如把測試作為編碼之后的最后一個活動、需求分析等前期產(chǎn)生的錯誤直到后期的驗收測試才能發(fā)現(xiàn).上一頁下一頁返回１０.１過程模型為了解決Ｖ模型的局限性.在實際中一些企業(yè)會結(jié)合自己的實踐開發(fā)公司測試工作的Ｖ模型.圖１０－２所示是某公司的Ｖ模型.從圖中可以看出紅色背景為開發(fā)團隊關(guān)注的階段.深藍色背景為軟件測試團隊關(guān)注的區(qū)域.作為專業(yè)的質(zhì)量人員.測試工作在項目初始化啟動階段就介入項目中.并伴隨在項目的全部生命周期中.開發(fā)人員進行需求分析以及概要設(shè)計、詳細設(shè)計等階段.可以對應(yīng)到測試人員的驗收測試、系統(tǒng)測試和集成測試等階段.測試人員可以由后向前提前準備和規(guī)劃.待產(chǎn)品單元測試以后.再進行集成測試等各階段測試的執(zhí)行.測試人員作為質(zhì)量的跟蹤和把控人員.對整個測試版本的迭代和交付也會跟進到底.直到項目結(jié)束.上一頁下一頁返回１０.１過程模型10.1.2Ｗ模型Ｖ模型的局限性在于沒有明確地說明早期的測試.無法體現(xiàn)“盡早地和不斷地進行軟件測”的原則.在Ｖ模型中增加軟件各開發(fā)階段應(yīng)同步進行的測試.則演化為Ｗ模型.在模型中不難看出.開發(fā)是“Ｖ”.測試是與此并行的“Ｖ”.基于“盡早地和不斷地進行軟件測試”的原則.在軟件的需求和設(shè)計階段的測試活動應(yīng)遵循ＩＥＥＥ１０１２－１９９８?軟件驗證與確認(Ｖ＆Ｖ)?的原則.上一頁下一頁返回１０.１過程模型Ｗ模型由Ｅｖｏｌｕｔｉｆ公司提出.相對于Ｖ模型.Ｗ模型更科學(xué).如圖１０－３所示.Ｗ模型是Ｖ模型的發(fā)展.強調(diào)測試伴隨著整個軟件開發(fā)周期.而且測試的對象不僅是程序.對需求、功能和設(shè)計同樣要進行測試.測試與開發(fā)是同步進行的.這有利于盡早地發(fā)現(xiàn)問題.Ｗ模型也有局限性.Ｗ模型和Ｖ模型都把軟件的開發(fā)視為需求、設(shè)計、編碼等一系列串行的活動.無法支持迭代、自發(fā)性以及變更調(diào)整.10.1.3Ｘ模型上一頁下一頁返回１０.１過程模型Ｘ模型也是對Ｖ模型的改進.如圖１０－４所示.Ｘ模型提出針對單獨的程序片段進行相互分離的編碼和測試.此后通過頻繁的交接.通過集成最終合成為可執(zhí)行的程序.Ｘ模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試.此后將進行頻繁的交接.通過集成最終成為可執(zhí)行的程序.然后再對這些可執(zhí)行程序進行測試.已通過集成測試的成品可以進行封裝并提交給用戶.也可以作為更大規(guī)模和范圍內(nèi)集成的一部分.多根并行的曲線表示變更可以在各個部分發(fā)生.由圖可見.Ｘ模型還定位了探索性測試.這是不進行事先計劃的特殊類型的測試.這一方式往往能幫助有經(jīng)驗的測試人員在測試計劃之外發(fā)現(xiàn)更多的軟件錯誤.但這樣可能對測試造成人力、物力和財力的浪費.對測試員的熟練程度要求比較高.上一頁下一頁返回１０.１過程模型10.1.4Ｈ模型Ｈ模型如圖１０－５所示.軟件測試過程活動完全獨立.貫穿于整個產(chǎn)品的周期.與其他流程并發(fā)地進行.某個測試點準備就緒時.就可以從測試準備階段進行到測試執(zhí)行階段.軟件測試可以盡早地進行.并且可以根據(jù)被測物的不同分層次進行.圖１０－５演示了在整個生產(chǎn)周期中某個層次上的一次測試“微循環(huán)”.圖１０－５中標注的“其他流程”可以是任意的開發(fā)流程.例如設(shè)計流程或者編碼流程.也就是說.只要測試條件成熟.測試準備活動完成.測試執(zhí)行活動就可以進行.上一頁下一頁返回１０.１過程模型Ｈ模型揭示了一個原理:軟件測試是一個獨立的流程.貫穿于產(chǎn)品的整個生命周期.與其他流程并發(fā)地進行.Ｈ模型指出軟件測試要盡早準備、盡早執(zhí)行.不同的測試活動可以是按照某個次序進行的.但也可能是反復(fù)的.只要某個測試達到準備就緒點.測試執(zhí)行活動就可以開展.上一頁返回１０.２軟件測試過程的關(guān)鍵活動本書前幾章詳細介紹了軟件測試的常用方法.只掌握方法的讀者也許想知道該怎么使用這些方法.以及在什么情況下使用這些方法.本節(jié)將詳細介紹在具體的軟件測試活動中如何使用測試方法.軟件測試是貫穿于整個軟件開發(fā)生命周期的一個完整的過程.為了有效地實現(xiàn)軟件測試各個層面的測試目標.需要和軟件開發(fā)過程一樣.定義一個完整的軟件測試過程.該過程應(yīng)該涉及各個軟件測試活動、技術(shù)、文檔等內(nèi)容.來指導(dǎo)和管理軟件測試活動.以提高軟件測試效率和軟件質(zhì)量.并告警軟件開發(fā)過程和測試工程.下一頁返回１０.２軟件測試過程的關(guān)鍵活動軟件測試過程的關(guān)鍵活動主要包括提取測試需求、確定測試策略、制訂測試計劃、開展測試設(shè)計、執(zhí)行測試用例、分析測試結(jié)果等.在實際項目中主要按照測試階段將以上關(guān)鍵活動融入進去.軟件測試由５個階段組成.如圖１０－６所示.(１)測試計劃和控制:在該階段通過了解需求確定測試范圍、制定測試策略(測試方法)、編寫測試計劃(安排資源及時間進度)并控制測試過程.(２)測試分析和設(shè)計:在該階段對測試需求進行設(shè)計.設(shè)計出用于測試的測試用例等細節(jié).上一頁下一頁返回１０.２軟件測試過程的關(guān)鍵活動(３)測試實現(xiàn)和執(zhí)行:在該階段明確測試輸入、預(yù)期結(jié)果和執(zhí)行條件因素.按照設(shè)計的測試用例執(zhí)行測試.如果有ｂｕｇ產(chǎn)生還要分析并定位問題.提交和跟進ｂｕｇ修復(fù).(４)評估出口準則和報告:在該階段通過測試過程問題記錄.判斷是否符合準出測試.整理和分析測試數(shù)據(jù)和結(jié)果.提交測試報告.(５)測試結(jié)束活動:測試結(jié)束.如圖１０－６所示.軟件測試的各個階段是按順序進行的.而測試計劃和控制貫穿整測試過程.測試分析和設(shè)計、測試實現(xiàn)和執(zhí)行在時間上可能是重疊的或者并行進行的.上一頁返回１０.３軟件測試計劃軟件測試計劃是指導(dǎo)測試過程的綱領(lǐng)性文件.包含產(chǎn)品概述、測試策略、測試方法、測試范圍、測試資源、風(fēng)險分析等內(nèi)容.在需求活動一開始就要著手編寫測試計劃.隨著開發(fā)過程的逐步展開添加內(nèi)容.通過軟件測試計劃明確測試對象范圍和測試方法.通過對時間、資源、風(fēng)險、測試范圍和預(yù)算等方面的綜合分析和規(guī)劃.保證實施軟件測試過程的順暢溝通.制定軟件測試計劃的目的就是把知識和經(jīng)驗直接轉(zhuǎn)化成執(zhí)行任務(wù)的具體方法.為組織、安排和管理測試項目提供一個整體框架.同時促進團隊間關(guān)于測試任務(wù)和過程的交流.此外還可以對項目執(zhí)行過程中的風(fēng)險進行分析.并制定相關(guān)的應(yīng)對策略.下一頁返回１０.３軟件測試計劃

一般建議在需求說明書確定之后或者在開發(fā)計劃確定之后制定軟件測試計劃.以便盡早識別相關(guān)風(fēng)險.軟件測試計劃在測試活動中處于中心位置.在整個軟件測試過程中.需要不斷監(jiān)控測試過程.同時對測試計劃進行維護與更新.一般在維護中需要對測試計劃中規(guī)定的資源、進度等進行監(jiān)督.關(guān)注測試項目是否按計劃執(zhí)行.根據(jù)實際項目情況對測試計劃進行調(diào)整或修改.測試計劃更新后還需經(jīng)過相關(guān)人員的評審與確認.上一頁下一頁返回１０.３軟件測試計劃

測試計劃有很多模板.可以是Ｅｘｃｅｌ、ＸＭｉｎｄ、Ｗｏｒｄ格式的.但是測試計劃的基本結(jié)構(gòu)不變.主要包括:測試計劃的簡介.測試項目說明.測試范圍.測試手段和策略.項目通過或失敗的標準.暫停和重新啟動測試的標準/原則.測試的可交付性.測試任務(wù)分配.測試環(huán)境的需求.測試的職責(zé)、人員和培訓(xùn)需求.進度表.風(fēng)險及偶然試過的預(yù)測等.在實際項目中可以使用微軟的項目管理文件記錄測試計劃中的測試時間、測試進度、測試人員、測試內(nèi)容.項目管理文檔根據(jù)具體的測試執(zhí)行情況每天更新.也可以使用ＸＭｉｎｄ記錄測試策略.即對應(yīng)版本使用哪些具體的測試方法、是否需要專項測試、人員如何分配等.上一頁下一頁返回１０.３軟件測試計劃

圖１０－７所示是某互聯(lián)網(wǎng)公司內(nèi)部研發(fā)的測試管理軟件“快測２.０”平臺.通過該平臺可以創(chuàng)建測試項目、版本號、測試時間、發(fā)布時間.關(guān)聯(lián)測試用例.安排項目相關(guān)人員資源.實現(xiàn)測試計劃電子化.同時該平臺還集功能測試、快測適配測試、Ａｎ￣ｄｒｏｉｄ安全測試、自定義測試等三十多項專項測試于一體.可以對測試過程中涉及的各專項領(lǐng)域進行統(tǒng)一管理.并進行相關(guān)數(shù)據(jù)和報告的集成.通過測試報告將測試發(fā)布流程實時記錄.以方便作出正式上線決策.使用“快測２.０”可以優(yōu)化測試管理流程.提高工作效率.上一頁返回１０.４測試用例設(shè)計測試用例是為了某特定目標而編制的一組測試輸入、執(zhí)行條件以及預(yù)期結(jié)果的程序.以便測試某個程序路徑或核實程序是否滿足某特定需求.測試用例設(shè)計是軟件測試活動中最重要的活動之一.也是測試人員必須掌握的基本技能之一.由本書前面章節(jié)所介紹的軟件測試的具體方法可以知道.軟件測試用例設(shè)計的方法有白盒測試和黑盒測試兩種.黑盒測試的用例設(shè)計.一般采用等價類劃分、邊界值分析等.主要適用于功能測試和驗收測試.白盒測試用例可以采用邏輯覆蓋等方法.下一頁返回１０.４測試用例設(shè)計每個公司有各自的測試用例模板.包括模塊、子模塊、優(yōu)先級、前置條件、操作步驟、操作數(shù)據(jù)、預(yù)期結(jié)果、用例狀態(tài)、缺陷嚴重級、概率、實際測試結(jié)果、備注、字體格式以及字體大小.測試用例按照之前約定的流程或按模塊設(shè)計.測試用例模板還應(yīng)說明測試用例放置的位置以及執(zhí)行的先后順序.前面執(zhí)行過的測試用例是否可以作為下面測試用例執(zhí)行的輸入數(shù)據(jù).也就是說測試數(shù)據(jù)是否具有連貫性等.這是判斷測試用例有效性的首要條件.測試用例可以分為基本事件、備選事件和異常事件.設(shè)計基本事件的用例.應(yīng)該參照用例規(guī)約和相關(guān)的功能設(shè)計要求.設(shè)計備選事件和異常事件的用例則困難得多.往往在設(shè)計文檔中分析描述得不夠詳細.需要測試用例設(shè)計人員通過高度的測試敏感度和業(yè)務(wù)熟悉度設(shè)計.上一頁下一頁返回１０.４測試用例設(shè)計可以采用軟件黑盒測試的基本方法(等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等)設(shè)計測試用例.測試用例管理最好借助測試用例管理軟件.有了管理軟件.無論是編寫每日的測試工作日志還是編寫軟件測試報告.都會變得輕而易舉.圖１０－８所示是某互聯(lián)網(wǎng)公司內(nèi)部研發(fā)的測試管理軟件“快測２.０”平臺中對用例編寫進行管理和維護的用例管理平臺.用例平臺基于Ｂ/Ｓ結(jié)構(gòu).通過Ｗｅｂ界面仿照傳統(tǒng)Ｅｘｃｅｌ模式進行用例編寫的管理、修改、刪除.同時加入了用例分配、用例執(zhí)行、執(zhí)行結(jié)果查看、思維導(dǎo)圖、數(shù)據(jù)統(tǒng)計、ＩＭ通知等功能.用例平臺靈活、易用、易于擴展.可以快捷、有效地管理項目用例.查看項目進度.提高工作效率.上一頁返回１０.５軟件測試執(zhí)行在測試用例的設(shè)計和測試腳本的開發(fā)完成之后.就開始執(zhí)行測試.測試的執(zhí)行有手工測試執(zhí)行和自動化測試.手工測試執(zhí)行是根據(jù)已有的測試用例或者分配的測試模塊.按照用例的步驟或者模塊的功能一步一步執(zhí)行.查看預(yù)期結(jié)果與實際結(jié)果是否一致.自動化測試是通過測試工具.運行測試腳本.得到測試結(jié)果.自動化測試管理比較容易.執(zhí)行不會打折扣.并能自動記錄結(jié)果.因此這里著重以手工測試執(zhí)行為主介紹測試執(zhí)行.在測試執(zhí)行階段.每個測試人員都要認真閱讀相關(guān)項目說明書.熟悉業(yè)務(wù)系統(tǒng).手工測試執(zhí)行過程中.應(yīng)該注意的事項如下:(１)搭建測試環(huán)境事項.(２)注意前提條件和特殊說明.下一頁返回１０.５軟件測試執(zhí)行

(３)測試用例要全部執(zhí)行.(４)不要忽視任何偶然現(xiàn)象.(５)加強測試過程記錄.(６)詳細預(yù)期與實際的不一致.(７)提交缺陷時與開發(fā)的關(guān)系處理.(８)提交一份優(yōu)秀的問題報告單.(９)及時更新測試用例.上一頁下一頁返回１０.５軟件測試執(zhí)行

在測試執(zhí)行階段.測試人員需要詳細記錄測試過程.目前一般業(yè)界都有一些測試管理軟件.可以自動記錄執(zhí)行過程.如上述某互聯(lián)網(wǎng)公司的用例平臺.不僅可以用于用例設(shè)計.還可以很清晰地記錄測試執(zhí)行的數(shù)據(jù).如什么時間哪位同學(xué)執(zhí)行了哪些測試用例.這些數(shù)據(jù)將非常有利于測試負責(zé)人進行測試工作量和進度的評估.實時記錄也非常有利于后續(xù)缺陷的重現(xiàn).上一頁返回１０.６缺陷管理測試過程中一般都會發(fā)現(xiàn)軟件的錯誤和缺陷.可提交或納入軟件缺陷管理過程.在一個良好的組織中.缺陷數(shù)據(jù)的收集和分析是很重要的.從缺陷數(shù)據(jù)中也可以得到很多與軟件質(zhì)量相關(guān)的數(shù)據(jù).前面章節(jié)已經(jīng)介紹了不同的故障分類.本節(jié)主要從缺陷管理的角度簡單介紹實際項目中的缺陷管理.１.缺陷的基本信息為了讓開發(fā)人員或其他人員清晰地了解缺陷的信息.要盡可能多地提供缺陷信息.一般缺陷的基本信息有以下幾部分內(nèi)容:(１)缺陷標題(描述缺陷的標題).(２)缺陷的提交人.下一頁返回１０.６缺陷管理

(３)缺陷提交時間.(４)缺陷所屬項目/模塊.(５)缺陷的類型.(６)缺陷的嚴重程度.(７)缺陷的緊急程度.(８)缺陷的指定解決人.(９)缺陷的指定解決時間.(１０)缺陷的實際處理人.(１１)缺陷的實際處理時間.上一頁下一頁返回１０.６缺陷管理

(１２)缺陷的驗證人.(１３)缺陷的驗證結(jié)果描述.(１４)缺陷的驗證時間.(１５)缺陷的詳細描述.(１６)缺陷產(chǎn)生的測試環(huán)境.(１７)必要的附件和截圖.上一頁下一頁返回１０.６缺陷管理

軟件的缺陷描述是后續(xù)論述的軟件缺陷報告的重要組成部分.也是測試人員就一個測試問題與開發(fā)人員交流的最初且最好的機會.好的描述.需要使用簡單、準確、專業(yè)的語言來捉住缺陷的本質(zhì).否則不清晰的描述可能誤導(dǎo)開發(fā)人員.延誤修復(fù).圖１０－９所示是某互聯(lián)網(wǎng)公司ｂｕｇ管理系統(tǒng)中提交ｂｕｇ后的界面截圖.讀者可以清晰地看到其對相關(guān)字段都進行了詳細描述.２.缺陷的類型軟件缺陷的分類方法很多.一般分為需求缺陷、設(shè)計缺陷、文檔缺陷、算法缺陷、界面缺陷和性能缺陷等.不同公司也會有自己的一些定義.通過缺陷的分類.分析產(chǎn)生各類缺陷的原因.下面是某互聯(lián)網(wǎng)公司的缺陷類型.讀者可以進一步了解:上一頁下一頁返回１０.６缺陷管理

(１)代碼錯誤:因程序代碼錯誤而引發(fā)的ｂｕｇ的統(tǒng)稱.(２)代碼設(shè)計缺陷:通常是代碼底層架構(gòu)設(shè)計引起的深層次問題.修復(fù)難度大.涉及程序?qū)崿F(xiàn)方案(該類ｂｕｇ從“代碼錯誤”類ｂｕｇ中獨立出來.用于深度ｂｕｇ分析定位).(３)頁面問題:主要表現(xiàn)為頁面布局錯誤.通常與產(chǎn)品運行的平臺無關(guān).(４)適配問題:由平臺兼容性引發(fā)的問題.(５)配置相關(guān):資源提供錯誤、缺失或發(fā)布時屬性設(shè)置錯誤導(dǎo)致的ｂｕｇ.上一頁下一頁返回１０.６缺陷管理

(６)打包升級安裝部署:主要用于應(yīng)用工廠打包異常.(７)實現(xiàn)誤差:產(chǎn)品實現(xiàn)雖無功能性問題.但與需求不符.(８)標準規(guī)范:流程缺失、不按流程實施所引發(fā)的質(zhì)量事故.例如未經(jīng)測試就發(fā)布而產(chǎn)生的生產(chǎn)ｂｕｇ等.(９)數(shù)據(jù)庫相關(guān):數(shù)據(jù)庫設(shè)計錯誤、刷庫腳本錯誤所引發(fā)的ｂｕｇ.(１０)易用性問題:影響用戶體驗的ｂｕｇ.通常不需要改動需求.(１１)需求問題:需求設(shè)計不合理.ｂｕｇ修復(fù)通常需要變動原始需求.(１２)客戶端性能:性能缺陷的一種.通常表現(xiàn)為響應(yīng)慢、內(nèi)存泄漏等.上一頁下一頁返回１０.６缺陷管理

(１３)代碼安全:安全類ｂｕｇ.如注入問題等漏洞.(１４)運維問題:服務(wù)器故障引發(fā)的宕機或網(wǎng)關(guān)異常等引發(fā)的網(wǎng)絡(luò)中斷.(１５)未知:暫無法定位到原因的ｂｕｇ.(１６)其他:目前暫未歸類的ｂｕｇ.例如證書問題、簽名問題等.３.缺陷的嚴重級嚴重級是按照軟件缺陷對軟件質(zhì)量的影響程度作出的劃分.在提交ｂｕｇ的過程中.需要注意對ｂｕｇ的嚴重等級進行區(qū)分和說明.實際工作中不同公司對不同的項目/產(chǎn)品有不同的要求.上一頁下一頁返回１０.６缺陷管理

有可能一個ｂｕｇ在不同項目中會有不同的嚴重等級.表１０－１所示就是某互聯(lián)網(wǎng)公司從用戶、主業(yè)務(wù)和ｂｕｇ出現(xiàn)概率幾個方面對ｂｕｇ級別作出的定義.讀者可以參考了解.４.缺陷的優(yōu)先級優(yōu)先級是用于處理和修正軟件缺陷的先后順序的指標.它指明哪些缺陷需要有限修正.哪些缺陷可以稍后修正.一般優(yōu)先級從高到低分為３個等級:高、中、低.其中高優(yōu)先級的缺陷是應(yīng)該被立即解決的.中優(yōu)先級的缺陷是需要正常排隊等待修復(fù)或列入軟件發(fā)布清單后修復(fù).低優(yōu)先級別的缺陷可以在方便的時候被糾正.與缺陷的嚴重程度一樣.優(yōu)先級的劃分也不是絕對的.可以根據(jù)具體的情況靈活劃分.上一頁下一頁返回１０.６缺陷管理

嚴重級別高的缺陷不一定優(yōu)先級別最高.需要根據(jù)實際項目業(yè)務(wù)情況確定.圖１０－１０所示是某互聯(lián)網(wǎng)公司ｂｕｇ管理系統(tǒng)中解決優(yōu)先級設(shè)定.可以看出其設(shè)定了４個定級:不急、一般、盡快和緊急.５.缺陷的管理流程從測試人員發(fā)現(xiàn)到提交缺陷.再到后面的修復(fù)驗證等會經(jīng)過一系列的過程.在這一系列過程中每個階段的缺陷狀態(tài)組成了缺陷的生命周期.缺陷不同.由于評審人員或測試人員或開發(fā)人員的立場和角度不同.上一頁下一頁返回１０.６缺陷管理

對缺陷的認識程度也不同.因此需要對缺陷的生命周期及對應(yīng)階段的人員職責(zé)等根據(jù)自己項目的實踐經(jīng)驗作統(tǒng)一認知的定義.一般缺陷可以劃分為ｎｅｗ、ｃｏｎｆｉｒｍｅｄ、ｆｉｘｅｄ、ｃｌｏｓｅｄ、ｒｅｏｐｅｎ等.圖１０－１１所示是某公司對缺陷生命周期的劃分的定義.從圖中可以看到測試人員發(fā)現(xiàn)了缺陷ＤｅｆｅｃｔＤｅｆｅｃｔｅｄ.這個狀態(tài)標注為ｎｅｗ(新建)Ｄｅｆｅｃｔ.同時會對缺陷進行判斷.如果是新發(fā)現(xiàn)的缺陷.則標注為ＯｐｅｎＤｅｆｅｃｔ.如果是已有的Ｄｅｆｅｃｔ再次出現(xiàn).則為ＲｅｏｐｅｎＤｅｆｅｃｔ.缺陷提交給開發(fā)人員后.開發(fā)人員會Ａｎａｌｙｚｅ(分析)Ｄｅｆｅｃｔ.開發(fā)團隊會對缺陷進行反饋.如果需要Ｃｌａｒｉｆｉｃａｔｉｏｎ(澄清).會返回給測試人員澄清.上一頁下一頁返回１０.６缺陷管理

如果不需要澄清.則開發(fā)人清晰地了解缺陷的信息后.會判斷是否接受這個缺陷.如果認為不是開發(fā)范圍內(nèi)的.可以Ｒｅｊｅｃｔ(拒絕)Ｄｅｆｅｃｔ.是自己范圍內(nèi)的會接受.然后開始Ｆｉｘ(修復(fù))Ｄｅｆｅｃｔ.在修復(fù)以后會提交給測試人員Ｒｅｔｅｓｔ(重測)Ｄｅｆｅｃｔ.測試人員進行測試.如果通過.則可以Ｃｌｏｓｅｄ(關(guān)閉)Ｄｅｆｅｃｔ.否則再次提交給開發(fā)人員.如此循環(huán).以確保缺陷的跟蹤.推進缺陷的修復(fù).上一頁返回１０.７測試報告10.7.1測試報告的定義測試報告是指把測試的過程和結(jié)果寫成文檔.對發(fā)現(xiàn)的問題和缺陷進行分析.為糾正軟件所存在的質(zhì)量問題提供依據(jù).同時為軟件驗收和交付打下基礎(chǔ).測試報告是測試階段最后的文檔產(chǎn)出物.優(yōu)秀的測試經(jīng)理或測試人員應(yīng)該具備良好的文檔編寫能力.一份詳細的測試報告包含足夠的信息.包括產(chǎn)品質(zhì)量和測試過程的評價.測試報告基于測試中的數(shù)據(jù)采集以及最終的測試結(jié)果分析.下一頁返回１０.７測試報告10.7.2測試報告的內(nèi)容不論以何種格式編寫測試報告.測試報告都應(yīng)該包括如下內(nèi)容:(１)測試目的:本測試報告的具體編寫目的.指出相關(guān)干系人.(２)項目背景:對項目目標和目的進行簡要說明.(３)測試環(huán)境:測試應(yīng)該具備的軟/硬件環(huán)境.(４)相關(guān)人員:參與的測試執(zhí)行人員、測試管理人員、開發(fā)人員、策劃人員、產(chǎn)品人員等相關(guān)干系人.(５)測試時間:測試計劃時間、實際測試時間.(６)測試方法:功能測試、專項測試等具體測試策略.上一頁下一頁返回１０.７測試報告(７)測試范圍:測試的主要范圍或者測試的對象.(８)測試結(jié)構(gòu)與缺陷分析:整個測試報告最核心的部分.主要匯總各種數(shù)據(jù)并進行度量.度量包括對測試過程的度量和能力評估、對軟件產(chǎn)品的質(zhì)量度量和產(chǎn)品評估、軟件的風(fēng)險評估以及最后的測試結(jié)論.測試報告可以是版本測試報告.也可以是產(chǎn)品測試報告.版本測試報告是指對同一個產(chǎn)品的不同迭代周期的測試報告.產(chǎn)品測試報告是指對一個產(chǎn)品全功能測試的執(zhí)行結(jié)果報告.上一頁下一頁返回１０.７測試報告10.7.3測試報告實踐每個公司都有自己的測試報告模板.測試報告填寫的難點在于測試結(jié)果和缺陷分析.測試結(jié)果關(guān)乎軟件質(zhì)量是否過關(guān)且相關(guān)人員是否要承擔(dān)一定的質(zhì)量責(zé)任.例如.當版本測試的結(jié)果是不通過.原因是軟件出現(xiàn)嚴重影響使用的缺陷時.這個版本則需要重新開發(fā)并測試.這時就會追究造成該嚴重缺陷的原因.若該缺陷是人為因素導(dǎo)致.則需要以降低ＫＰＩ等方式進行懲罰.缺陷分析可以為產(chǎn)品以后的迭代版本服務(wù).避免一些現(xiàn)版本測試“踩過的坑”.比如.這次版本測試中的缺陷類型多源于兼容性問題.那就應(yīng)該將測試報告中的數(shù)據(jù)提交給開發(fā)人員.讓他們總結(jié)該類問題.減少以后版本中的兼容性問題.上一頁下一頁返回１０.７測試報告在初級階段可以以Ｗｏｒｄ、Ｅｘｃｅｌ文檔為主手寫測試報告.圖１０－１２所示是一個功能測試報告模板(Ｅｘｃｅｌ格式).可以看到其主要包括測試結(jié)論、風(fēng)險評估、版本信息、ｂｕｇ數(shù)據(jù)信息等.讀者可以參考了解.除了功能測試需要測試報告.其他專項測試也有各自的測試報告格式.比如性能測試、安全測試、自動化測試.圖１０－１３所示就是自動化測試的測試報告格式.10.7.4創(chuàng)建報告實例隨著自動化程度的提高.可以用專業(yè)的報告系統(tǒng)來提取數(shù)據(jù).形成數(shù)據(jù)更齊全、更嚴謹?shù)臏y試報告.圖１０－１４所示是某互聯(lián)網(wǎng)公司所形成的一套自己的測試報告系統(tǒng).上一頁下一頁返回１０.７測試報