基于新信息技術(shù)的軟件測試技術(shù) 課件 第6章 測試報(bào)告和測試評測

第6章測試報(bào)告和測試評測6.1軟件缺陷6.2分離再現(xiàn)軟件缺陷6.3正確面對軟件缺陷6.4軟件缺陷生命周期及處理技巧6.5報(bào)告軟件缺陷6.6軟件缺陷的跟蹤管理6.7測試總結(jié)報(bào)告6.8測試的評測6.9質(zhì)量評測

6.1軟件缺陷

6.1.1軟件缺陷簡介軟件缺陷(Defect)常常又被叫做Bug。所謂軟件缺陷，簡單說就是存在于軟件(文檔、數(shù)據(jù)、程序)之中的那些不希望或不可接受的偏差，會導(dǎo)致軟件產(chǎn)生質(zhì)量問題。

只要符合下面5個規(guī)則中的一條，就叫做軟件缺陷：

(1)軟件沒有實(shí)現(xiàn)產(chǎn)品規(guī)格說明中所要求的功能；

(2)出現(xiàn)了產(chǎn)品規(guī)格說明中指明不應(yīng)該出現(xiàn)的錯誤；

(3)軟件實(shí)現(xiàn)了產(chǎn)品規(guī)格說明中沒有提到的功能模塊；

(4)軟件沒有實(shí)現(xiàn)產(chǎn)品規(guī)格說明中沒有明確提及但應(yīng)該實(shí)現(xiàn)的目標(biāo)；

(5)軟件難以理解，不容易使用，運(yùn)行緩慢，或從測試員的角度看，最終用戶會認(rèn)為不好。

例如，計(jì)算器(圖6.1)在測試中有如下問題，就認(rèn)為存在缺陷。圖6.1計(jì)算器

①計(jì)算器的產(chǎn)品規(guī)格說明應(yīng)能準(zhǔn)確無誤地進(jìn)行加、減、乘、除運(yùn)算。如果按下加法鍵，沒什么反應(yīng)，就是第一種類型的缺陷；若計(jì)算結(jié)果出錯，也是第(1)種類型的缺陷。

②產(chǎn)品規(guī)格說明書還可能規(guī)定計(jì)算器不會死機(jī)，或者停止反應(yīng)。如果隨意敲鍵盤，則計(jì)算器停止接受輸入，這就是第(2)種類型的缺陷。

③如果使用計(jì)算器進(jìn)行測試，發(fā)現(xiàn)除了加、減、乘、除之外還可以求平方根，但是產(chǎn)品規(guī)格說明中沒有提及這一功能模塊，這是第(3)種類型的缺陷。

④在測試計(jì)算器時若發(fā)現(xiàn)電池沒電會導(dǎo)致計(jì)算不正確，而產(chǎn)品說明書中是假定電池一直都有電的，則這就是第(4)種類型的錯誤。

⑤軟件測試員如果發(fā)現(xiàn)某些地方不對，比如測試員覺得按鍵太小、“=”鍵布置的位置不好按、在亮光下看不清顯示屏等，無論什么原因，都要認(rèn)定為缺陷。

6.1.2軟件缺陷產(chǎn)生的原因

從軟件本身、團(tuán)隊(duì)工作和技術(shù)問題等角度分析，造成軟件缺陷的主要因素有：

(1)需求不清晰，導(dǎo)致設(shè)計(jì)目標(biāo)偏離客戶的需求，從而引起功能或產(chǎn)品特征上的缺陷。

(2)系統(tǒng)結(jié)構(gòu)非常復(fù)雜，而又無法設(shè)計(jì)成一個很好的層次結(jié)構(gòu)或組件結(jié)構(gòu)，結(jié)果導(dǎo)致意想不到的問題或系統(tǒng)維護(hù)、擴(kuò)充上的困難；即使設(shè)計(jì)成良好的面向?qū)ο蟮南到y(tǒng)，由于對象、類太多，很難完成對各種對象、類相互作用的組合測試，而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。

(3)對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全，漏掉某些邊界條件，造成容量或邊界錯誤。

(4)對一些實(shí)時應(yīng)用，要進(jìn)行精心設(shè)計(jì)和技術(shù)處理，保證精確的時間同步，否則容易引起時間上不協(xié)調(diào)、不一致性帶來的問題。

(5)沒有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)的異地備份、災(zāi)難性恢復(fù)等問題，從而存在系統(tǒng)安全性、可靠性的隱患。

(6)系統(tǒng)運(yùn)行環(huán)境復(fù)雜，不僅用戶使用的計(jì)算機(jī)環(huán)境千變?nèi)f化，包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問題；在系統(tǒng)實(shí)際應(yīng)用中，數(shù)據(jù)量很大，從而會引起強(qiáng)度或負(fù)載問題。

(7)由于通信端口多、存取和加密手段的矛盾性等，會造成系統(tǒng)的安全性或適用性等問題。

(8)新技術(shù)的采用，可能涉及技術(shù)或系統(tǒng)兼容的問題，事先沒有考慮到。

6.1.3軟件的有效簡述規(guī)則

軟件缺陷簡述是軟件缺陷報(bào)告的基礎(chǔ)部分，也是測試人員就一個軟件問題與開發(fā)小組交流的最初且最好的機(jī)會。準(zhǔn)確報(bào)告軟件缺陷是非常重要的，因?yàn)椋?/p>

(1)清晰準(zhǔn)確的軟件缺陷簡述可以減少軟件缺陷從開發(fā)人員處返回的次數(shù)；

(2)可提高軟件缺陷修復(fù)的速度，使每一個小組能夠有效地工作；

(3)可提高測試人員的信任度，得到開發(fā)人員對清晰的軟件缺陷簡述的有效響應(yīng)；

(4)加強(qiáng)開發(fā)人員、測試人員和管理人員的協(xié)同工作，讓他們可以更好地工作。

在多年實(shí)踐的基礎(chǔ)上，我們積累了較多的軟件缺陷的有效簡述規(guī)則，主要有：

1．單一準(zhǔn)確

2．可以再現(xiàn)

3．完整統(tǒng)一

4．短小簡練

5．特定條件

6．補(bǔ)充完善

7．不做評價(jià)

6.1.4軟件缺陷的屬性

軟件缺陷的屬性包括缺陷標(biāo)識、缺陷類型、缺陷嚴(yán)重程度、缺陷優(yōu)先級、缺陷狀態(tài)、缺陷起源、缺陷來源、缺陷根源。

(1)缺陷標(biāo)識：標(biāo)記某個缺陷的唯一的標(biāo)識，可以使用數(shù)字序號表示。

(2)缺陷類型：根據(jù)缺陷的自然屬性劃分缺陷種類，具體類型見表6-1。

(3)缺陷嚴(yán)重程度：因缺陷引起的故障對軟件產(chǎn)品的影響程度，具體等級見表6-2。

(4)缺陷優(yōu)先級：缺陷必須被修復(fù)的緊急程度，見表6-3。

(5)缺陷狀態(tài)：缺陷通過一個跟蹤修復(fù)過程的進(jìn)展情況，具體狀態(tài)見表6-4。

(6)缺陷起源：缺陷引起的故障或事件第一次被檢測到的階段，具體起源見表6-5。

(7)缺陷來源：缺陷所在的地方，如文檔、代碼等，具體來源見表6-6。

(8)缺陷根源：造成上述錯誤的根本因素，以尋求軟件開發(fā)流程的改進(jìn)、管理水平的提高，具體根源見表6-7。

通常情況下，對于影響用戶使用或者影響產(chǎn)品美觀的軟件缺陷，附上圖片比較直觀，例如：

(1)當(dāng)產(chǎn)品中有一段文字沒有顯示完全，為了明確標(biāo)識這段文字的位置，測試人員必須貼上圖片。

(2)在測試外國語言版本的時候，當(dāng)發(fā)現(xiàn)產(chǎn)品中有一段文字沒有翻譯，測試人員需要貼上圖片標(biāo)識沒有翻譯的文字。

(3)在測試外國語言版本的時候，當(dāng)發(fā)現(xiàn)產(chǎn)品中有一段外國文字顯示亂字符，測試人員必須貼上圖片標(biāo)識亂字符的外國文字。

(4)對于產(chǎn)品中的語法錯誤、標(biāo)點(diǎn)符號使用不當(dāng)?shù)溶浖毕?，測試人員貼上圖片告訴開發(fā)人員缺陷在什么地方。

(5)在產(chǎn)品中運(yùn)用錯誤的公司標(biāo)志和沒有顯示圖片的重要等軟件缺陷，也需要附上圖片。

測試人員需要注意的是，有必要在圖片上用顏色標(biāo)注缺陷的位置，給開發(fā)人員一目了然的效果，使得軟件缺陷盡快修復(fù)。

軟件缺陷的分離和再現(xiàn)考驗(yàn)的是測試人員專業(yè)技能，測試人員要想有效報(bào)告軟件缺陷，就要對軟件缺陷以明顯、通用和再現(xiàn)的形式進(jìn)行簡述。測試人員應(yīng)該設(shè)法找出縮小問題范圍的具體步驟。對測試人員有利的情況是，若建立起絕對相同的輸入條件，軟件缺陷就會再次出現(xiàn)，不存在隨機(jī)的軟件缺陷。

6.2分離再現(xiàn)軟件缺陷

軟件缺陷分離和再現(xiàn)的方法主要有：

(1)確保所有的步驟都被記錄。

(2)特定條件和時間。

(3)壓力和負(fù)荷、內(nèi)存和數(shù)據(jù)溢出相關(guān)的邊界條件。

(4)考慮資源依賴性，包括內(nèi)存、網(wǎng)絡(luò)和硬件共享的相互作用等。

(5)不能忽視硬件。

6.3正確面對軟件缺陷

1．并不是測試人員發(fā)現(xiàn)的每個缺陷都是必須修復(fù)的測試是為了發(fā)現(xiàn)程序錯誤，而不能保證程序沒有錯誤。不管測試計(jì)劃和執(zhí)行多么努力，也不是所有缺陷發(fā)現(xiàn)了就能修復(fù)。有些軟件缺陷可能會完全被忽略，還有一些可能推遲到后續(xù)版本中修復(fù)。

有些軟件缺陷不被修復(fù)的原因如下：

1)沒有足夠的時間

2)不算真正的軟件缺陷

3)修復(fù)的風(fēng)險(xiǎn)太大

4)不值得修復(fù)

2．發(fā)現(xiàn)缺陷的數(shù)量說明不了軟件的質(zhì)量

軟件中不可能沒有缺陷，發(fā)現(xiàn)了很多缺陷對于測試工作來說，是很正常的事。缺陷的數(shù)量大，只能說明測試的方法很好，思路很全面，測試工作卓有成效。但以此來否認(rèn)軟件的質(zhì)量，還是不具客觀性的。

反過來，如果在測試過程中發(fā)現(xiàn)的缺陷較少，但這些缺陷都集中表現(xiàn)為功能沒有實(shí)現(xiàn)、性能未達(dá)標(biāo)、經(jīng)常引起死機(jī)或系統(tǒng)崩潰等現(xiàn)象，而且，大多數(shù)用戶在使用過程中都會發(fā)現(xiàn)這樣的問題，那么這樣的軟件就不能隨便發(fā)布。

6.4軟件缺陷生命周期及處理技巧6.4.1軟件缺陷生命周期概述生命周期是指一個物種從誕生到消亡所經(jīng)歷的不同的生命階段，軟件缺陷生命周期則指的是一個軟件缺陷被發(fā)現(xiàn)、報(bào)告到這個缺陷被修復(fù)、驗(yàn)證直至最后關(guān)閉的完整過程。在整個軟件缺陷生命周期中，通常是以改變軟件缺陷的狀態(tài)來體現(xiàn)不同的生命階段。因此，對于一個軟件測試人員來講，需要關(guān)注軟件缺陷在生命周期中的狀態(tài)變化，來跟蹤項(xiàng)目進(jìn)度和軟件質(zhì)量。一個簡單、優(yōu)化的軟件缺陷生命周期如圖6.2所示。圖6.2一個簡單、優(yōu)化的軟件缺陷生命周期

(1)發(fā)現(xiàn)—打開：測試人員找到軟件缺陷并將軟件缺陷提交給開發(fā)人員。

(2)打開—修復(fù)：開發(fā)人員再現(xiàn)、修復(fù)缺陷，然后提交給測試人員去驗(yàn)證。

(3)修復(fù)—關(guān)閉：測試人員驗(yàn)證修復(fù)過的軟件，關(guān)閉已不存在的缺陷。

在實(shí)際工作中，軟件缺陷的生命周期不可能像如上那么簡單，需要考慮其他各種情況，下面給出了一個復(fù)雜的軟件缺陷生命周期的例子，如圖6.3所示。

圖6.3一個復(fù)雜的軟件缺陷生命周期

綜上所述，軟件缺陷在生命周期中經(jīng)歷了數(shù)次的審閱和狀態(tài)變化，最終測試人員關(guān)閉軟件缺陷來結(jié)束軟件缺陷的生命周期。軟件缺陷生命周期中的不同階段是測試人員、開發(fā)人員和管理人員一起參與、協(xié)同測試的過程。軟件缺陷一旦發(fā)現(xiàn)，便進(jìn)入測試人員、開發(fā)人員、管理人員的嚴(yán)密監(jiān)控之中，直至軟件缺陷生命周期終結(jié)，這樣即可保證在較短的時間內(nèi)高效率地關(guān)閉所有的缺陷，縮短軟件測試的進(jìn)程，提高軟件質(zhì)量，同時減少開發(fā)、測試和維護(hù)成本。

6.4.2軟件缺陷處理技巧

以下列出處理軟件缺陷的基本技巧：

(1)審閱。

(2)拒絕。

(3)完善。

(4)分配。

(5)測試。

(6)重新打開。

(7)關(guān)閉。

(8)暫緩。

6.5報(bào)告軟件缺陷

一份軟件缺陷報(bào)告詳細(xì)信息見表6-8。

軟件缺陷的詳細(xì)簡述，如上所述，由三部分組成：操作/重現(xiàn)步驟、期望結(jié)果、實(shí)際結(jié)果，有必要再做進(jìn)一步的討論：

(1)“步驟”提供了如何重復(fù)當(dāng)前缺陷的準(zhǔn)確簡述，應(yīng)簡明而完備、清楚而準(zhǔn)確。這些信息對開發(fā)人員是關(guān)鍵的，視為修復(fù)缺陷的向?qū)?，開發(fā)人員有時抱怨糟糕的缺陷報(bào)告，往往集中在這里。

(2)“期望結(jié)果”與測試用例標(biāo)準(zhǔn)或設(shè)計(jì)規(guī)格說明書或用戶需求等一致，達(dá)到軟件預(yù)期的功能。測試人員站在用戶的角度要對它進(jìn)行簡述，它提供了驗(yàn)證缺陷的依據(jù)。

(3)“實(shí)際結(jié)果”是測試人員收集的結(jié)果和信息，以確認(rèn)缺陷確實(shí)是一個問題，并標(biāo)識那些影響到缺陷表現(xiàn)的要素。

6.5.1報(bào)告軟件缺陷的基本原則

報(bào)告軟件缺陷的基本原則如下：

1．盡快報(bào)告軟件缺陷

軟件缺陷發(fā)現(xiàn)得越早，留下的修復(fù)時間就越多。

2．有效地簡述軟件缺陷

軟件缺陷的基本簡述是軟件缺陷報(bào)告中測試人員對問題陳述的一部分，并且是軟件缺陷報(bào)告的基礎(chǔ)部分。

3．每一個報(bào)告只針對一個軟件缺陷

如果在一個報(bào)告中有多個軟件缺陷，最容易出現(xiàn)的結(jié)果是，只有第一個軟件缺陷受到注意和修復(fù)，而其他軟件缺陷往往被忘記或者忽視。軟件缺陷應(yīng)該分別報(bào)告，而不是堆在一起。這說起來容易，但是做起來不那么簡單。

4．在報(bào)告軟件缺陷時不做任何評價(jià)

在軟件測試過程中，測試人員是在尋找程序錯誤，所以測試人員和程序員之間容易形成對立關(guān)系。軟件缺陷報(bào)告可能以軟件測試人員工作“成績報(bào)告單”的形式由程序員或開發(fā)小組其他人審查，因此軟件缺陷報(bào)告中不應(yīng)該帶有傾向性以及個人的觀點(diǎn)。

5．補(bǔ)充和完善軟件缺陷報(bào)告

從發(fā)現(xiàn)Bug那一刻起，測試人員的責(zé)任就是保證它被正確地報(bào)告，并且得到應(yīng)有的重視，繼續(xù)監(jiān)視其修復(fù)的全過程。

以上概括了報(bào)告測試錯誤的規(guī)范要求，測試人員應(yīng)該牢記這些關(guān)于報(bào)告軟件缺陷的原則。這些原則幾乎可以運(yùn)用到任何交流活動中，盡管有時難以做到，然而，如果希望有效地報(bào)告軟件缺陷，并使其得以修復(fù)，這些是測試人員要遵循的基本原則。

6.5.2IEEE軟件缺陷報(bào)告模板

ANS/IEEE829—1998標(biāo)準(zhǔn)定義了一個稱為軟件缺陷報(bào)告的文檔，用于報(bào)告“在測試期間發(fā)生的任何異常事件”，簡言之，就是用于登記軟件缺陷，如圖6.4所示。

圖6.4軟件缺陷報(bào)告模板

一份優(yōu)秀的缺陷報(bào)告記錄下最少的重復(fù)步驟，不僅包括了期望結(jié)果，實(shí)際結(jié)果和必要的附件，還提供必要的數(shù)據(jù)、測試環(huán)境或條件，以及簡單的分析，如圖6.5所示。圖6.5優(yōu)秀的缺陷報(bào)告

而一份含糊而不完整的缺陷報(bào)告，缺少重建步驟，并且沒有期望結(jié)果、實(shí)際結(jié)果和必要的圖片，如圖6.6所示。圖6.6含糊而不完整的缺陷報(bào)告

一份散漫的缺陷報(bào)告(無關(guān)的重建步驟，以及對開發(fā)人員理解這個錯誤毫無幫助的結(jié)果信息)如圖6.7所示。圖6.7散漫的缺陷報(bào)告

6.6軟件缺陷的跟蹤管理

1．建立軟件缺陷跟蹤系統(tǒng)的優(yōu)點(diǎn)實(shí)踐中需要軟件缺陷跟蹤系統(tǒng)，以便簡述報(bào)告所發(fā)現(xiàn)的缺陷，處理軟件缺陷屬性，跟蹤軟件缺陷的整個生命周期和生成軟件缺陷跟蹤圖表等。建立一套軟件缺陷跟蹤系統(tǒng)的優(yōu)點(diǎn)概括起來有以下幾點(diǎn)：(1)軟件缺陷跟蹤系統(tǒng)擁有軟件缺陷跟蹤數(shù)據(jù)庫，它不僅可使軟件缺陷的簡述清楚，還提供統(tǒng)一的、標(biāo)準(zhǔn)化報(bào)告，使所有人的理解一致。

(2)缺陷跟蹤數(shù)據(jù)庫允許自動連續(xù)的軟件缺陷編號，還提供了大量供分析和統(tǒng)計(jì)的選項(xiàng)，這是手工方法無法實(shí)現(xiàn)的。

(3)基于缺陷跟蹤數(shù)據(jù)庫，可快速生成滿足各種查詢條件的、所必要的缺陷報(bào)表、曲線圖等，開發(fā)小組乃至公司的每一個人都可以隨時掌握軟件產(chǎn)品質(zhì)量的整體狀況或測試/開發(fā)的進(jìn)度。

(4)缺陷跟蹤數(shù)據(jù)庫提供了軟件缺陷屬性并允許開發(fā)小組根據(jù)項(xiàng)目的相對和絕對重要性來修復(fù)缺陷。

(5)可以在軟件缺陷的生命周期中管理缺陷，從最初的報(bào)告到最后的解決；確保了每一個缺陷不會被忽略，同時，它還可以使注意力保持在那些必須盡快修復(fù)的重要缺陷上。

(6)當(dāng)缺陷在它的生命周期中變化時，開發(fā)人員、測試人員以及管理人員將熟悉新的軟件缺陷信息。一個設(shè)計(jì)良好的軟件缺陷跟蹤系統(tǒng)可以獲取歷史記錄，并在檢查缺陷的狀態(tài)時參考?xì)v史記錄。

(7)在軟件缺陷跟蹤數(shù)據(jù)庫中關(guān)閉每一份缺陷報(bào)告，都可以被記錄下來。當(dāng)產(chǎn)品送出去時，每一份未關(guān)閉的缺陷報(bào)告都提供了預(yù)先警告的有效技術(shù)支持，并且證明測試人員找到特殊領(lǐng)域突然出現(xiàn)的事件中的軟件缺陷。

2．缺陷跟蹤系統(tǒng)的概述

一個缺陷跟蹤系統(tǒng)需要實(shí)現(xiàn)如下幾部分的功能：

(1)缺陷的上報(bào)，當(dāng)問題被發(fā)現(xiàn)后，可以通過系統(tǒng)進(jìn)行提交、保留，方便跟蹤。

(2)缺陷錄入系統(tǒng)后，項(xiàng)目經(jīng)理應(yīng)該可以通過缺陷跟蹤系統(tǒng)進(jìn)行瀏覽，定期獲得最新的缺陷問題報(bào)告。

(3)項(xiàng)目經(jīng)理將缺陷問題報(bào)告通過缺陷跟蹤系統(tǒng)轉(zhuǎn)交給程序員，程序員可以通過缺陷跟蹤系統(tǒng)知道自己負(fù)責(zé)修正的缺陷問題報(bào)告。

(4)缺陷問題的修正處理，當(dāng)程序員修復(fù)問題后，可以通過跟蹤系統(tǒng)，通知項(xiàng)目經(jīng)理問題已修復(fù)。

(5)對于無法根據(jù)缺陷報(bào)告重現(xiàn)的問題，也可以通過跟蹤系統(tǒng)，向項(xiàng)目經(jīng)理及測試人員要求更多更詳細(xì)的信息，并將缺陷問題返回至項(xiàng)目經(jīng)理重新處理。

(6)問題暫緩及申訴過程處理，對于缺陷報(bào)告提到的問題，如在當(dāng)前版本無法實(shí)現(xiàn)或者缺陷與需求有沖突的時候，可以將問題置為“暫緩處理”或“提出申訴”。

(7)對于優(yōu)先等級較低的缺陷問題，可能不能被及時處理掉，但必須可以被查詢。

(8)缺陷跟蹤系統(tǒng)可以提供跟蹤項(xiàng)目的狀態(tài)報(bào)告。

3．目前主流的缺陷跟蹤系統(tǒng)

1)?TestDirector

在工業(yè)級軟件項(xiàng)目領(lǐng)域，由于Mercury是測試軟件領(lǐng)域的老大(比較有名的如LoadRunner、WinRunner等)，因此它的TD也成了缺陷跟蹤系統(tǒng)的標(biāo)桿產(chǎn)品。其也是最早通過Web方式來進(jìn)行管理的缺陷跟蹤軟件。

2)?TestTrackPro

Seapine公司也是主要做項(xiàng)目管理軟件的，TestTrackPro同其同門配置管理產(chǎn)品SurroundSCM可以完美結(jié)合并實(shí)現(xiàn)完整的代碼級管理。其主要架構(gòu)為Client/Server，同時提供了CGI的Web訪問接口，不過其高昂的價(jià)格也會讓很多公司望而卻步。

3)?DevTrack

TechExcel可以說是CRM系統(tǒng)以及HelpDesk系統(tǒng)的老大，它的產(chǎn)品在很多大公司(如Oracle、IBM等)里都有應(yīng)用，最新發(fā)布的DevTrack功能也確實(shí)強(qiáng)大，在其項(xiàng)目配置的部分可以提供用戶對各級項(xiàng)目相關(guān)人員的UI進(jìn)行配置，同時也提供了最大的靈活度給客戶，可視化自定義跟蹤流程可以實(shí)現(xiàn)任何復(fù)雜的配置處理。

4)?JIRA

JIRA是目前比較流行的基于Java架構(gòu)的缺陷跟蹤系統(tǒng)，由于Atlassian公司對很多開源項(xiàng)目實(shí)行免費(fèi)，提供缺陷跟蹤服務(wù)，因此在開源領(lǐng)域，其認(rèn)知度比其他的產(chǎn)品要高得多，而且易用性也好一些。

5)?Mantis

Mantis是一個基于PHP技術(shù)的輕量級的缺陷跟蹤系統(tǒng)，其功能與前面提及的JIRA系統(tǒng)類似，都是以Web操作的形式提供項(xiàng)目管理及缺陷跟蹤服務(wù)。在功能上可能沒有JIRA那么專業(yè)，界面也沒有JIRA漂亮，但在實(shí)用性上足以滿足中小型項(xiàng)目的管理及跟蹤。更重要的是其開源，不需要負(fù)擔(dān)任何費(fèi)用。

6.7測試總結(jié)報(bào)告

測試總結(jié)報(bào)告的目的是總結(jié)測試活動的結(jié)果，并根據(jù)這些結(jié)果對測試進(jìn)行評價(jià)。這種報(bào)告是測試人員對測試工作進(jìn)行總結(jié)，并識別出軟件的局限性和發(fā)生失效的可能性。測試總結(jié)報(bào)告是測試計(jì)劃的擴(kuò)展，起著對測試計(jì)劃“封閉回路”的作用。在測試執(zhí)行階段的末期，應(yīng)該為每個測試計(jì)劃準(zhǔn)備一份相應(yīng)的測試總結(jié)報(bào)告，如圖6.8所示。

圖6.8測試總結(jié)報(bào)告

(1)測試總結(jié)報(bào)告標(biāo)識符。報(bào)告標(biāo)識符是標(biāo)識報(bào)告的唯一ID，用來方便測試總結(jié)報(bào)告的管理、定位和引用。

(2)概述。該部分內(nèi)容概要說明發(fā)生了哪些測試活動，包括軟件的版本發(fā)布及環(huán)境等。這部分內(nèi)容通常還包括測試計(jì)劃、測試設(shè)計(jì)規(guī)格說明、測試用例提供的參考信息等。

(3)差異。該部分內(nèi)容是報(bào)告與設(shè)計(jì)說明書，以及與測試計(jì)劃、測試設(shè)計(jì)或測試規(guī)程的差異，并指出每個差異的原因。

(4)綜合評估。該部分內(nèi)容是根據(jù)本報(bào)告中所展示的測試結(jié)果，提供對該軟件的總體評估；標(biāo)識在測試中檢測到的任何遺留的缺陷、限制或約束，可用問題/變更報(bào)告提供缺陷信息；對每一遺留缺陷、限制或約束，應(yīng)描述。

(5)結(jié)果總結(jié)。該部分內(nèi)容是列出所有問題及其解決情況，列出未解決的問題。

(6)評價(jià)。該部分內(nèi)容是提供每一個測試項(xiàng)目的評價(jià)，包含局限性評價(jià)，還要包含風(fēng)險(xiǎn)分析。

(7)建議。該部分內(nèi)容是對被測試軟件的設(shè)計(jì)、操作或測試提供改進(jìn)建議，應(yīng)討論每個建議及其對軟件的影響。如果沒有改進(jìn)建議，本條應(yīng)陳述為“無”。

(8)活動總結(jié)。該部分內(nèi)容是總結(jié)主要的測試活動和事件。

(9)審批。這一部分列出對這個報(bào)告享有審批權(quán)的所有人員的姓名和職務(wù)，應(yīng)留出用于署名和填寫日期的空間。

6.8測?試?的?評?測

測試的評測主要方法包括覆蓋評測和質(zhì)量評測。覆蓋評測是對測試完全程度的評測，它建立在測試覆蓋基礎(chǔ)上。測試覆蓋是由測試需求和測試用例的覆蓋或已執(zhí)行代碼的覆蓋表示的。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋，分別是指針對需求(基于需求的)或代碼的設(shè)計(jì)/實(shí)施標(biāo)準(zhǔn)(基于代碼的)而言的完全程度評測。

1．基于需求的測試覆蓋

基于需求的測試覆蓋在測試過程中要評測多次，并在測試過程中，每一個測試階段結(jié)束時給出測試覆蓋的度量。例如，計(jì)劃的測試覆蓋、已實(shí)施的測試覆蓋、已執(zhí)行成功的測試覆蓋等。

基于需求的測試覆蓋率通過以下公式計(jì)算：

其中：T是用測試過程或測試用例表示的已計(jì)劃(Plan)、已實(shí)施(Input)或已執(zhí)行成功(Success)的測試需求數(shù)；RfT是測試需求的總數(shù)。

在執(zhí)行測試過程中，經(jīng)常使用兩個測試覆蓋度量指標(biāo)，一個是確定已執(zhí)行(Ti)的測試覆蓋率，另一個是確定成功(Ts)的測試覆蓋率，即執(zhí)行時未出現(xiàn)失敗的測試覆蓋率。

可將Ts與已定義的成功標(biāo)準(zhǔn)對比