軟件測試報(bào)告與測試評價(jià)PPT課件.ppt

第5章軟件測試報(bào)告與測試評價(jià) 5 1軟件缺陷的概念和種類5 2正確面對軟件缺陷5 3軟件缺陷的生命周期5 4軟件缺陷的嚴(yán)重性和優(yōu)先級5 5報(bào)告軟件缺陷5 6分離和再現(xiàn)軟件缺陷5 7測試總結(jié)報(bào)告5 8測試的評測 軟件測試是在軟件開發(fā)的過程中 對軟件產(chǎn)品進(jìn)行質(zhì)量控制 目的是保證軟件產(chǎn)品的最終質(zhì)量 一般來說軟件測試應(yīng)嚴(yán)格按照軟件測試流程 制定測試計(jì)劃 測試方案 測試規(guī)范 實(shí)施測試 對測試數(shù)據(jù)進(jìn)行記錄 并根據(jù)測試情況撰寫測試報(bào)告 測試報(bào)告主要是報(bào)告發(fā)現(xiàn)的軟件缺陷 測試評價(jià)主要包括覆蓋評價(jià)以及質(zhì)量和性能評價(jià) 覆蓋評價(jià)是對測試完全程度的評測 質(zhì)量和性能評價(jià)是對測試的軟件對象的性能 穩(wěn)定性以及可靠性的評測 5 1軟件缺陷的概念和種類 軟件缺陷簡單說就是存在于軟件 文檔 數(shù)據(jù) 程序 之中的那些不希望 或不可接受的偏差 而導(dǎo)致軟件產(chǎn)生的質(zhì)量問題 按照一般的定義 只要符合下面5個規(guī)則中的一個 就叫做軟件缺陷 軟件未達(dá)到軟件規(guī)格說明書中規(guī)定的功能 軟件超出軟件規(guī)格說明書中指明的范圍 軟件未達(dá)到軟件規(guī)格說明書中指出的應(yīng)達(dá)到的目標(biāo) 軟件運(yùn)行出現(xiàn)錯誤 軟件測試人員認(rèn)為軟件難于理解 不易使用 運(yùn)行速度慢 或者最終用戶認(rèn)為軟件使用效果不好 在軟件測試過程中如何判斷軟件缺陷 軟件缺陷都有哪些種類 1 功能不正常 2 軟件在使用上不方便 3 軟件的結(jié)構(gòu)未做良好規(guī)劃 4 功能不充分 5 與軟件操作者的互動不良 6 使用性能不佳 7 未做好錯誤處理 8 邊界錯誤 9 計(jì)算錯誤 10 使用一段時間所產(chǎn)生的錯誤 11 控制流程的錯誤 12 在大數(shù)據(jù)量壓力之下所產(chǎn)生的錯誤 13 在不同硬件環(huán)境下產(chǎn)生的錯誤 14 版本控制不良所產(chǎn)生的錯誤 15 軟件文檔的錯誤 5 2正確面對軟件缺陷 在軟件測試過程中 軟件測試人員必須確保測試過程發(fā)現(xiàn)的軟件缺陷得以關(guān)閉 測試是為了證明程序有錯 而不是證明程序沒錯 不管測試計(jì)劃多么完善和執(zhí)行測試多么努力 也不能保證所有軟件缺陷發(fā)現(xiàn)了就能修復(fù) 有些軟件缺陷可能會完全被忽略 還有一些可能推遲到軟件后續(xù)版本中修復(fù) 有些軟件缺陷不被修復(fù)的原因如下 1 沒有足夠的時間 2 不算真正的軟件缺陷 3 修復(fù)的風(fēng)險(xiǎn)太大 4 不值得修復(fù) 雖然軟件測試人員需要對自己找出的軟件缺陷保持一種平常心態(tài) 但同時又必須堅(jiān)持有始有終的原則 跟蹤每一個軟件缺陷的處理結(jié)果 確保軟件缺陷得以關(guān)閉 而缺陷是否需要修復(fù)的最終決定權(quán)在軟件的項(xiàng)目負(fù)責(zé)人 但使得缺陷得以關(guān)閉的責(zé)任在測試人員 5 3軟件缺陷的生命周期 軟件缺陷從被測試人員發(fā)現(xiàn)一直到被修復(fù) 也經(jīng)歷了一個特有的生命周期的階段 下面是一個最簡單的軟件缺陷生命周期的例子 系統(tǒng)地表示軟件缺陷從被發(fā)現(xiàn)起經(jīng)歷的各個階段 1 測試人員找到并登記軟件缺陷 軟件缺陷被移交到程序修復(fù)人員 2 程序修復(fù)人員修復(fù)軟件中的軟件缺陷 然后移交到測試人員 3 測試人員確認(rèn)軟件缺陷被修復(fù) 關(guān)閉軟件缺陷 當(dāng)軟件缺陷首先被軟件測試人員發(fā)現(xiàn)時 在許多情況下 軟件缺陷生命周期的復(fù)雜程度僅為軟件缺陷被打開 解決和關(guān)閉 然而 在有些情況下 生命周期變得更復(fù)雜一些 如圖5 1所示 圖5 1復(fù)雜的軟件缺陷生命周期 5 4軟件缺陷的嚴(yán)重性和優(yōu)先級 測試人員要對軟件缺陷分類 以簡明扼要的方式指出其影響 經(jīng)常使用的方法是給軟件缺陷劃分嚴(yán)重性和優(yōu)先級 嚴(yán)重性表示軟件缺陷的惡劣程度 反映其對產(chǎn)品和用戶的影響 優(yōu)先級表示修復(fù)缺陷的重要程度和應(yīng)該何時修復(fù) 下面給出嚴(yán)重性和優(yōu)先級的常用劃分方法 將有助于測試人員更好地理解兩者之間的差異 嚴(yán)重性級別 致命錯誤 例如 導(dǎo)致系統(tǒng)崩潰 數(shù)據(jù)丟失 數(shù)據(jù)毀壞等 一般性錯誤 例如 操作性錯誤 錯誤結(jié)果 遺漏功能等 次要錯誤 例如 錯別字 用戶接口布局 罕見故障等 缺陷優(yōu)先級 最高優(yōu)先級 指的是一些關(guān)鍵性錯誤 必須立即修復(fù) 高優(yōu)先級 在產(chǎn)品發(fā)布之前必須修復(fù) 中優(yōu)先級 如果時間允許應(yīng)該修復(fù) 低優(yōu)先級 可能會修復(fù) 但是也能發(fā)布軟件 5 5報(bào)告軟件缺陷 5 5 1報(bào)告軟件缺陷的基本原則在軟件測試過程中 對于發(fā)現(xiàn)的大多數(shù)軟件缺陷 要求測試人員簡捷 清晰地把發(fā)現(xiàn)的問題報(bào)告給判斷是否進(jìn)行修復(fù)的小組 使其得到所需要的全部信息 然后才能決定怎么做 報(bào)告軟件缺陷的基本原則如下 1 盡快報(bào)告軟件缺陷2 有效地描述軟件缺陷 有效的軟件缺陷描述要求如下 1 簡單與短小 2 明確指明錯誤類型 3 單一 4 使用IT業(yè)界慣用的表達(dá)術(shù)語和表達(dá)方法 3 在報(bào)告軟件缺陷時不做任何評價(jià)4 補(bǔ)充和完善軟件缺陷報(bào)告 以上概括了報(bào)告測試錯誤的規(guī)范要求 測試人員應(yīng)該牢記上面這些關(guān)于報(bào)告軟件缺陷的原則 這些原則幾乎可以運(yùn)用到任何交流活動中 盡管有時難以做到 然而 如果希望有效地報(bào)告軟件缺陷 并使其得以修復(fù) 這些是測試人員要遵循的基本原則 隨著軟件的測試要求不同 測試者積累了相應(yīng)的測試經(jīng)驗(yàn)會 將會逐漸養(yǎng)成良好的專業(yè)習(xí)慣 不斷補(bǔ)充新的規(guī)范書寫要求 此外 經(jīng)常閱讀 學(xué)習(xí)高級測試工程師的測試錯誤報(bào)告 結(jié)合自己以前的測試錯誤報(bào)告進(jìn)行對比和思考 可以不斷提高技巧 5 5 2IEEE軟件缺陷報(bào)告模板ANS IEEE829 1998標(biāo)準(zhǔn)定義了一個稱為軟件缺陷報(bào)告的文檔 用于報(bào)告 在測試期間發(fā)生的任何異常事件 簡言之 就是用于登記軟件缺陷 模板標(biāo)準(zhǔn)如圖5 3所示 圖5 3IEEE軟件缺陷報(bào)告模板 5 5 3軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng)至此 我們了解到軟件缺陷報(bào)告過程是很復(fù)雜的 需要大量信息 詳盡的細(xì)節(jié)和很好的組織工作 才能有所成效 在實(shí)際軟件測試工作中 為了更高效地記錄發(fā)現(xiàn)的軟件缺陷 并在軟件缺陷的整個生命周期中對其進(jìn)行監(jiān)控 常常運(yùn)用軟件缺陷跟蹤系統(tǒng) 圖5 4所示的是一個軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng) 圖5 4軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng) 軟件缺陷跟蹤數(shù)據(jù)庫最常用的功能 除了輸入軟件缺陷之外 就是通過執(zhí)行查詢來獲得需要的軟件缺陷清單 通過使用軟件缺陷跟蹤數(shù)據(jù)庫 不但可以進(jìn)行查詢 還可以找出發(fā)現(xiàn)的軟件缺陷類型 發(fā)現(xiàn)軟件缺陷的速度 以及多少軟件缺陷已經(jīng)得到了修復(fù) 能夠提取各種實(shí)用和關(guān)心的數(shù)據(jù) 可以顯示測試工作的成效和項(xiàng)目的進(jìn)展情況 測試人員或者項(xiàng)目管理員可以看出數(shù)據(jù)中是否有趨勢顯示需要增加測試的區(qū)域 或者測試工作是否符合預(yù)先所制定的測試計(jì)劃的進(jìn)程等 5 5 4手工報(bào)告和跟蹤軟件缺陷顯然 在軟件測試工作中 每個測試用例的結(jié)果都必須進(jìn)行記錄 如果使用軟件缺陷數(shù)據(jù)庫跟蹤系統(tǒng) 那么測試工具將自動記錄軟件缺陷的相關(guān)信息 如果測試是采用手工記錄和跟蹤軟件缺陷 那么有關(guān)軟件缺陷的信息可以直接記錄在相應(yīng)的文檔中 圖5 5所示的是根據(jù)ANS IEEE829 1998標(biāo)準(zhǔn)設(shè)計(jì)的軟件缺陷報(bào)告文檔 圖5 5軟件缺陷報(bào)告文檔 5 6分離和再現(xiàn)軟件缺陷 測試人員要想有效報(bào)告軟件缺陷 就要對軟件缺陷以明顯 通用和再現(xiàn)的形式進(jìn)行描述 分離和再現(xiàn)軟件缺陷是考驗(yàn)軟件測試人員專業(yè)技能的地方 測試人員應(yīng)該設(shè)法找出縮小問題范圍的具體步驟 對測試人員有利的情況是 若建立起絕對相同的輸入條件時 軟件缺陷就會再次出現(xiàn) 不存在隨機(jī)的軟件缺陷 如果找到的軟件缺陷要采取繁雜的步驟才能再現(xiàn) 或者根本無法再現(xiàn) 碰到這種情況 可采取如下的方法來分離和再現(xiàn)軟件缺陷 實(shí)踐證明這些方法對測試人員是有所幫助的 1 不要想當(dāng)然地接受任何假設(shè) 2 注意時間和運(yùn)行條件上的因素 3 注意軟件的邊界條件 內(nèi)存容量和數(shù)據(jù)溢出的問題 4 注意事件發(fā)生次序?qū)е碌能浖毕?5 考慮資源依賴性和內(nèi)存 網(wǎng)絡(luò) 硬件共享的相互作用 6 不要忽視硬件 5 7測試總結(jié)報(bào)告 測試總結(jié)報(bào)告的目的是總結(jié)測試活動的結(jié)果 并根據(jù)這些結(jié)果對測試進(jìn)行評價(jià) 這種報(bào)告是測試人員對測試工作進(jìn)行總結(jié) 并識別出軟件的局限性和發(fā)生失效的可能性 在測試執(zhí)行階段的末期 應(yīng)該為每個測試計(jì)劃準(zhǔn)備一份相應(yīng)的測試總結(jié)報(bào)告 本質(zhì)上講 測試總結(jié)報(bào)告是測試計(jì)劃的擴(kuò)展 起著對測試計(jì)劃 封閉回路 的作用 圖5 6所示的是符合IEEE標(biāo)準(zhǔn)829 1998軟件測試文檔編制標(biāo)準(zhǔn)的測試總結(jié)報(bào)告模板 圖5 6測試總結(jié)報(bào)告模板 5 8測試的評測 測試的評測主要方法包括覆蓋評測和質(zhì)量評測 測試覆蓋評測是對測試完全程度的評測 它建立在測試覆蓋基礎(chǔ)上 測試覆蓋是由測試需求和測試用例的覆蓋或已執(zhí)行代碼的覆蓋表示的 質(zhì)量評測是對測試對象的可靠性 穩(wěn)定性以及性能的評測 質(zhì)量建立在對測試結(jié)果的評估和對測試過程中確定的缺陷及缺陷修復(fù)的分析基礎(chǔ)上 5 8 1覆蓋評測覆蓋評測指標(biāo)是用來度量軟件測試的完全程度的 所以可以將覆蓋用做測試有效性的一個度量 最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋 它們分別是指針對需求 基于需求的 或代碼的設(shè)計(jì) 實(shí)施標(biāo)準(zhǔn) 基于代碼的 而言的完全程度評測 1 基于需求的測試覆蓋基于需求的測試覆蓋在測試過程中要評測多次 并在測試過程中 每一個測試階段結(jié)束時給出測試覆蓋的度量 例如 計(jì)劃的測試覆蓋 已實(shí)施的測試覆蓋 已執(zhí)行成功的測試覆蓋等 基于需求的測試覆蓋率通過以下公式計(jì)算 測試覆蓋率 T p i x s RfT 在制定測試計(jì)劃活動中 將計(jì)算計(jì)劃的測試覆蓋 其計(jì)算方法如下 計(jì)劃的測試覆蓋率 Tp RfT 其中 Tp是用測試過程或測試用例表示的計(jì)劃測試需求數(shù) RfT是測試需求的總數(shù) 在實(shí)施測試過程中 計(jì)算測試覆蓋時使用以下公式 已執(zhí)行的測試覆蓋率 Ti RfT 其中 Ti是用測試過程或測試用例表示的已執(zhí)行的測試需求數(shù) RfT是測試需求的總數(shù) 在執(zhí)行測試活動中 確定成功的測試覆蓋率 即執(zhí)行時未出現(xiàn)失敗的測試 如沒有出現(xiàn)缺陷或意外結(jié)果的測試 評測通過以下公式計(jì)算 成功的測試覆蓋率 Ts RfT 其中 Ts是用完全成功 沒有缺陷的測試過程或測試用例表示的已執(zhí)行測試需求數(shù) RfT是測試需求的總數(shù) 在執(zhí)行測試過程中 經(jīng)常使用兩個測試覆蓋度量指標(biāo) 一個是確定已執(zhí)行的測試覆蓋率 另一個是確定成功的測試覆蓋率 即執(zhí)行時未出現(xiàn)失敗的測試覆蓋率 2 基于代碼的測試覆蓋基于代碼的測試覆蓋評測是測試過程中已經(jīng)執(zhí)行的代碼的多少 與之相對應(yīng)的是將要執(zhí)行測試的剩余代碼的多少 許多測試專家認(rèn)為 一個測試小組在測試工作中所要做的最為重要的事情之一就是度量代碼的覆蓋情況 基于代碼的測試覆蓋率通過以下公式計(jì)算 基于代碼的測試覆蓋率 Ie TIic 其中 Ie是用代碼語句 代碼分支 代碼路徑 數(shù)據(jù)狀態(tài)判定點(diǎn)或數(shù)據(jù)元素名表示的已執(zhí)行代碼數(shù) TIic是代碼的總數(shù) 很明顯 在軟件測試工作中 進(jìn)行基于代碼的測試覆蓋評測這項(xiàng)工作極有意義 因?yàn)槿魏挝唇?jīng)測試的代碼都是一個潛在的不利因素 在一般情況下 代碼覆蓋運(yùn)用于較低的測試等級 例如單元和集成級 時最為有效 但是 僅僅憑借執(zhí)行了所有的代碼 并不能為軟件質(zhì)量提供保證 也就是說 即使所有的代碼都在測試中得到執(zhí)行 并不能擔(dān)保代碼是按照客戶需求和設(shè)計(jì)的要求去做了 5 8 2質(zhì)量評測測試覆蓋的評測提供了對測試完全程度的評價(jià) 而在測試過程中對已發(fā)現(xiàn)缺陷的評測提供了最佳的軟件質(zhì)量指標(biāo) 常用的測試有效性度量是圍繞缺陷分析來構(gòu)造的 缺陷分析就是分析缺陷在與缺陷相關(guān)聯(lián)的一個或者多個參數(shù)值上的分布 缺陷分析提供了一個軟件可靠性指標(biāo) 這些分析為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據(jù) 對于缺陷分析 常用的主要缺陷參數(shù)有以下4個 狀態(tài) 缺陷的當(dāng)前狀態(tài) 打開的 正在修復(fù)的或關(guān)閉的等 優(yōu)先級 表示修復(fù)缺陷的重要程度和應(yīng)該何時修復(fù) 嚴(yán)重性 表示軟件缺陷的惡劣程度 反映其對產(chǎn)品和用戶的影響等 起源 導(dǎo)致缺陷的原因及其位置 或排除該缺陷需要修復(fù)的構(gòu)件 缺陷分析通常用以下3類形式的度量提供缺陷評測 缺陷發(fā)現(xiàn)率 缺陷潛伏期 缺陷密度 1 缺陷發(fā)現(xiàn)率缺陷發(fā)現(xiàn)率是將發(fā)現(xiàn)的缺陷數(shù)量作為時間的函數(shù)來評測 即創(chuàng)建缺陷趨勢圖 如圖5 7所示 圖5 7缺陷發(fā)現(xiàn)率 2 缺陷潛伏期測試有效性的另外一個有用的度量是缺陷潛伏期 通常也稱為階段潛伏期 缺陷潛伏期是一種特殊類型的缺陷分布度量 在實(shí)際測試工作中 發(fā)現(xiàn)缺陷的時間越晚 這個缺陷所帶來的損害就越大 修復(fù)這個缺陷所耗費(fèi)的成本就越多 表5 1顯示了一個項(xiàng)目的缺陷潛伏期的度量 表5 2顯示了一個項(xiàng)目的缺陷分布情況 按缺陷造成階段和缺陷發(fā)現(xiàn)階段 按照缺陷產(chǎn)生階段和缺陷發(fā)現(xiàn)階段統(tǒng)計(jì)了一個項(xiàng)目的缺陷分布情況后 根據(jù)軟件開發(fā)生命周期的各個階段缺陷潛伏期度量的加權(quán)值 可以對缺陷的發(fā)現(xiàn)過程有效性和修復(fù)軟件缺陷所耗費(fèi)的成本等進(jìn)行評測 這里采用了一個缺陷損耗的概念 缺陷損耗是使用階段潛伏期和缺陷分布來度量缺陷消除活動的有效性的一種度量 缺陷消耗可使用下面公式計(jì)算 表5 3顯示了一個項(xiàng)目的各個缺陷損耗值 它們依據(jù)的是經(jīng)過缺陷潛伏期加權(quán)的已發(fā)現(xiàn)的缺陷數(shù) 這樣 在驗(yàn)收測試期間發(fā)現(xiàn)的需求缺陷的加權(quán)數(shù)值為42 即6 7 42 一般而言 缺陷損耗的數(shù)值越低 說明缺陷的發(fā)現(xiàn)過程越有效 最理想的數(shù)值應(yīng)該為1 作為一個絕對值 缺陷損耗幾乎沒有任何意義 但是當(dāng)用缺陷損耗來度量測試有效性的長期趨勢時 它就會顯示出自己的價(jià)值 3 缺陷密度軟件缺陷密度是一種以平均值估算法來計(jì)算出軟件缺陷分布的密度值 程序代碼通常是以千行為單位的 軟件缺陷密度是用下面公式計(jì)算的 圖5 8顯示了一個項(xiàng)目的各個模塊中每千行代碼的缺陷密度 圖5 8各個模塊中每千行代碼的缺陷密度 但是 在實(shí)際評測中 缺陷密度這種度量方法是極不完善的 度量本身是不充分的 這里邊存在的主要問題是 所有的缺陷并不都是均等構(gòu)造的 各個軟件缺陷的惡劣程度 及其對產(chǎn)品和用戶的影響的嚴(yán)重程度 以及修復(fù)缺陷的重要程度有很大差別 有必要對缺陷進(jìn)行 分級 加權(quán) 處理 給出軟件缺陷在各嚴(yán)重性級別或優(yōu)先級上的分布作為補(bǔ)充度量 這樣將使這種評測更加充分 更有實(shí)際應(yīng)用價(jià)值 因?yàn)樵跍y試工作中 大多數(shù)的缺陷都記錄了它的嚴(yán)重程度的等級和優(yōu)先級 所以這個問題通常都能夠很好解決 例如 圖5 9所示的缺陷分布圖表示軟件缺陷在各優(yōu)先級上所應(yīng)體現(xiàn)的分布方式 圖5 9各優(yōu)先級上軟件缺陷分布圖 5 8 3性能評測主要的性能評測包括以下幾點(diǎn) 動態(tài)監(jiān)測 在測試執(zhí)行過程中 實(shí)時獲取并顯示正在執(zhí)行的