第8章-軟件BUG和管理

第八章軟件BUG和管理[本章要點(diǎn)]１.軟件Bug對(duì)軟件質(zhì)量的影響；２.常見的軟件Bug類型，重現(xiàn)軟件Bug的分析技術(shù)；３.軟件Bug的描述和管理。[本章目標(biāo)]了解軟件BUG的影響和產(chǎn)生；掌握軟件開發(fā)過(guò)程中產(chǎn)生的BUG種類；掌握使BUG重現(xiàn)的技術(shù)；了解軟件BUG報(bào)告單應(yīng)該包括的主要內(nèi)容以及軟件BUG的管理流程。8.1軟件BUG概述在IEEE1983ofIEEEStandard729中對(duì)軟件缺陷下了一個(gè)標(biāo)準(zhǔn)的定義：（1）從產(chǎn)品內(nèi)部看，軟件缺陷是軟件產(chǎn)品開發(fā)或維護(hù)過(guò)程中所存在的錯(cuò)誤、毛病等各種問(wèn)題；（2）從外部看，軟件缺陷是系統(tǒng)所需要實(shí)現(xiàn)的某種功能的失效或違背。軟件缺陷有很多種，其中主要軟件缺陷類型有：

1.一些功能、特性沒有實(shí)現(xiàn)或只實(shí)現(xiàn)了一部分；2.軟件設(shè)計(jì)不合理，存在缺陷。實(shí)際運(yùn)行結(jié)果和預(yù)期結(jié)果不一致；3.運(yùn)行出錯(cuò)，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂4.數(shù)據(jù)結(jié)果不正確、精度不夠；5.用戶不能接受的其他問(wèn)題，如存取時(shí)間過(guò)長(zhǎng)、界面不美觀。

8.1.1BUG的影響

Bug會(huì)給用戶或使用者帶來(lái)相當(dāng)大的麻煩，會(huì)給集體或者國(guó)家?guī)?lái)很大的經(jīng)濟(jì)損失。如：千年蟲問(wèn)題。8.1.2BUG的產(chǎn)生BUG的由來(lái)。對(duì)于軟件而言，BUG是程序編寫錯(cuò)誤而導(dǎo)致軟件產(chǎn)生問(wèn)題的缺陷。

軟件測(cè)試的目的就是找到軟件程序代碼內(nèi)的BUG，糾正它，叫做DEBUG。BUG產(chǎn)生的原因很多，具體有以下幾點(diǎn)。1．程序編寫錯(cuò)誤

Bug的難以避免性。

2．需求變更過(guò)于頻繁

需求變更所造成的結(jié)果就是變更程序代碼，程序代碼只要稍做變更就必須經(jīng)過(guò)測(cè)試來(lái)確保運(yùn)行正常，所以這個(gè)影響是一個(gè)連鎖反應(yīng)或稱為依存問(wèn)題。

3．軟件的復(fù)雜度圖形用戶界面（GUI）、B\S結(jié)構(gòu)、面向?qū)ο笤O(shè)計(jì)、分布式運(yùn)算、底層通信協(xié)議、超大型關(guān)系型數(shù)據(jù)庫(kù)以及龐大的系統(tǒng)規(guī)模，都體現(xiàn)了軟件復(fù)雜度大大高于以前，Bug出現(xiàn)可能性就更高。

4．交流不充分或者溝通出問(wèn)題大部分項(xiàng)目人員在同客戶進(jìn)行交流時(shí)常常存在著各種各樣的問(wèn)題，究其原因，還是因?yàn)轫?xiàng)目人員、參與人員和客戶之間沒有詳細(xì)、充分、謹(jǐn)慎地進(jìn)行交流。

5．測(cè)試人員的經(jīng)驗(yàn)與技巧不足6．時(shí)間過(guò)于緊迫7．缺乏文檔：貧乏或者差勁的文檔使得代碼維護(hù)和修改變得非常困難，結(jié)果會(huì)導(dǎo)致其他開發(fā)人員或客戶有許多錯(cuò)誤的理解。8．管理上的缺陷8.2BUG的種類BUG是軟件“與生俱來(lái)”的特征，不同的軟件開發(fā)階段會(huì)產(chǎn)生不同的BUG，而不同的BUG又會(huì)產(chǎn)生不同的后果，因此BUG的屬性也并非相同。8.2.1需求階段的BUG

這個(gè)階段的BUG是最難發(fā)現(xiàn)、最難修復(fù)的，而且值得注意的是需求階段的BUG如果沒有及時(shí)發(fā)現(xiàn)等到實(shí)現(xiàn)階段發(fā)現(xiàn)時(shí)，那么修復(fù)它的費(fèi)用要比當(dāng)初修復(fù)它要高15~75倍。主要的原因如下：1、模糊、不清晰的需求；2、被忽略的需求；3、相互沖突的需求；

8.2.2分析設(shè)計(jì)階段的BUG

設(shè)計(jì)中的BUG比需求階段產(chǎn)生的BUG特征明顯易于捕獲，但是其維修代價(jià)很高，原因是設(shè)計(jì)BUG已經(jīng)作為一個(gè)整體影響著整個(gè)系統(tǒng)的實(shí)現(xiàn)。原因主要有3種途徑。

1、忽略設(shè)計(jì)；

2、混亂的設(shè)計(jì)；

3、模糊的設(shè)計(jì)；

8.2.3實(shí)現(xiàn)階段的BUG就是軟件系統(tǒng)中最普通、最一般的“常規(guī)BUG”?？梢詫?shí)現(xiàn)階段出現(xiàn)的BUG分為下面幾類：

1、消息錯(cuò)誤

2、用戶界面錯(cuò)誤

3、遺漏的功能

4、內(nèi)存溢出或者程序崩潰

5、其他實(shí)現(xiàn)錯(cuò)誤第一類型說(shuō)明了軟件系統(tǒng)向用戶發(fā)送了出錯(cuò)的消息，可能消息是合理的或者表現(xiàn)為某種中斷機(jī)制，但是用戶認(rèn)為這是一個(gè)BUG。如下圖：第二類型就是用戶界面錯(cuò)誤，可歸納為GUI錯(cuò)誤?？赡苁怯捎贕UI制作不標(biāo)準(zhǔn)而導(dǎo)致用戶不能正確地工作。第三種類型為遺漏的功能BUG(以輸入框輸入信息錯(cuò)誤，程序拋出未異常為典型)第四種類型為內(nèi)存溢出或者程序崩潰BUG，表現(xiàn)為程序掛起、系統(tǒng)崩潰，屬于一種比較嚴(yán)重的軟件BUG類型。（詳見教材的藥房藥品進(jìn)存銷的軟件測(cè)試BUG）

8.2.4配置階段的BUG

配置階段的BUG出現(xiàn)的原因是復(fù)雜的，比較典型的是舊的代碼覆蓋了新的代碼，或者測(cè)試服務(wù)器上的代碼和實(shí)現(xiàn)人員本機(jī)最新代碼版本不一致?？赡苁菍?shí)現(xiàn)人員操作配置管理工具不正確引起的；還可能體現(xiàn)了測(cè)試人員或者最終用戶操作不正確。8.2.5短視將來(lái)的BUG

“千年蟲”問(wèn)題就是當(dāng)初的設(shè)計(jì)人員為了節(jié)省一點(diǎn)硬件成本給全球造成了難以估量的損失。作者曾經(jīng)為一家大藥房開發(fā)了一套藥品管理的進(jìn)銷存軟件，由于最初的時(shí)候?qū)I(yè)務(wù)流程并不是很熟悉，所以在定義藥品編碼的時(shí)候把許多藥品的ID號(hào)定義為了整型變量（INT），開始作者認(rèn)為這些足以定義所有的藥品名稱了，沒想到一年以后，由于藥房的業(yè)務(wù)量急增，藥品的ID也就不夠了，由于整套系統(tǒng)是由PowerBuilder編寫，整型變量的最大值只有32767，因此程序經(jīng)常由于數(shù)據(jù)溢出而出現(xiàn)問(wèn)題，所以作者被迫用了近一個(gè)星期的時(shí)間來(lái)修改原來(lái)的程序。

8.2.6靜態(tài)文檔的BUG

文檔BUG的定義很簡(jiǎn)單，即說(shuō)明模糊、描述不完整和過(guò)期的都屬于文檔BUG。說(shuō)明模糊特指無(wú)充分的信息判斷如何正確地處理事情；描述不完整特指文檔信息不足以支持用戶完成某項(xiàng)工作；過(guò)期的文檔是沒有及時(shí)更新過(guò)的、錯(cuò)誤的文檔。8.3.1BUG報(bào)告單的內(nèi)容

BUG報(bào)告單也叫缺陷報(bào)告單或者問(wèn)題報(bào)告單。問(wèn)題報(bào)告單所需的基本信息類型是大同小異的，不同的只是組織和標(biāo)志。介紹一下字段：（1）問(wèn)題報(bào)告編號(hào)（2）程序名（3）版本標(biāo)識(shí)：發(fā)布號(hào)和版本號(hào)。是用來(lái)識(shí)別被測(cè)的代碼。例如：某個(gè)版本號(hào)可能是1.01m，發(fā)布號(hào)是1.01，“m”指1.01版本的第13稿。（4）報(bào)告類型：描述了發(fā)現(xiàn)的問(wèn)題類型。包括：編碼錯(cuò)誤、設(shè)計(jì)問(wèn)題、建議、文檔、硬件、質(zhì)疑。（5）嚴(yán)重性：為問(wèn)題嚴(yán)重程度評(píng)分。包含三個(gè)等級(jí)：三個(gè)等級(jí)：輕微的、嚴(yán)重的和致命的。（6）附件存有測(cè)試數(shù)據(jù)的軟盤、鍵盤捕獲記錄或一組可產(chǎn)生測(cè)試用例的宏、程序的打印輸出、內(nèi)存dump或一份注釋，里面詳細(xì)描述了你所做的操作，以及你認(rèn)為該問(wèn)題很重要的原因。（7）問(wèn)題概要：對(duì)問(wèn)題進(jìn)行描述，有助于評(píng)審?fù)怀龅膯?wèn)題，并找到相應(yīng)的問(wèn)題報(bào)告。（8）問(wèn)題能否重現(xiàn)。要多次測(cè)試看能否再次出現(xiàn)。（9）問(wèn)題描述及如何重現(xiàn)。描述所有的步驟和現(xiàn)象，包括錯(cuò)誤信息。一定要提交報(bào)告。（10）建議的改正措施（11）報(bào)告人（12）日期：指的是報(bào)告人員發(fā)現(xiàn)問(wèn)題的日期。（13）功能域：對(duì)問(wèn)題進(jìn)行大體分類。（14）承辦人（15）注釋：程序員在這里簡(jiǎn)短地說(shuō)明為什么要推遲處理，或說(shuō)明是如何改正問(wèn)題的。（16）狀態(tài)。三個(gè)狀態(tài)碼：開放、關(guān)閉和已解決。（17）優(yōu)先級(jí)。只由項(xiàng)目經(jīng)理設(shè)置。（18）處理狀態(tài)與處理版本處理狀態(tài)定義了問(wèn)題的當(dāng)前狀態(tài)：<1>未解決：初始化狀態(tài)或仍有沖突狀態(tài)。<2>已改正<3>不能重現(xiàn)<4>暫緩：對(duì)存在的問(wèn)題在下個(gè)版本改正。<5>符合設(shè)計(jì)<6>由報(bào)告人撤回<7>需要進(jìn)一步信息<8>不同意建議<9>重復(fù):關(guān)閉重復(fù)上報(bào)的缺陷。（19）簽名:簽署以表明已經(jīng)對(duì)改動(dòng)進(jìn)行了測(cè)試，對(duì)結(jié)果表示滿意。（20）暫緩處理：對(duì)缺陷的推遲處理。

圖8-3、8-4整合起來(lái)即為一張完整的報(bào)告單。圖8-3報(bào)告單(part1)圖8-4報(bào)告單(part2)8.3.2BUG報(bào)告的特點(diǎn)

一份好的問(wèn)題報(bào)告應(yīng)是書面的、已編號(hào)的、簡(jiǎn)單的、易于理解的、可重現(xiàn)的、易讀的和不做判斷的。

1)書面的

一份書面的報(bào)告是必要的，供日后對(duì)修改后的程序進(jìn)行測(cè)試時(shí)使用；讓管理層、銷售人員和產(chǎn)品支持人員檢查。

2)已編號(hào)的依據(jù)惟一的編號(hào)跟蹤問(wèn)題報(bào)告。3)簡(jiǎn)單的一份報(bào)告應(yīng)只描述一個(gè)問(wèn)題，不要在一份報(bào)告中記錄多個(gè)缺陷。

4)可重現(xiàn)的

一定要強(qiáng)調(diào)BUG的可重現(xiàn)性。

5)不做判斷的

對(duì)程序員的評(píng)價(jià)要三思而后行，本著合作的精神，作出合理的判斷。

8.3.3重現(xiàn)BUG的分析和方法

本節(jié)重點(diǎn)是報(bào)告編碼錯(cuò)誤，而非報(bào)告設(shè)計(jì)問(wèn)題。一、重現(xiàn)BUG的分析“可重現(xiàn)”隱含了下列定義：我們能夠描述如何讓程序進(jìn)入某個(gè)已知的狀態(tài)。任何熟悉程序的人都能夠依照我們的描述使程序進(jìn)入該狀態(tài)。從那個(gè)狀態(tài)出發(fā)，我們確定出精確的一組步驟來(lái)暴露出問(wèn)題。為使報(bào)告更有效，我們應(yīng)該對(duì)問(wèn)題進(jìn)一步分析，目的在于：1）找出問(wèn)題最嚴(yán)重的后果。找出某個(gè)BUG導(dǎo)致的最嚴(yán)重的后果，這樣可以激發(fā)人們改正它的興趣。一個(gè)看來(lái)很輕微的問(wèn)題往往更有可能被暫緩處理。例如：假設(shè)有個(gè)BUG在屏幕角落顯示了一個(gè)無(wú)用的字符，這個(gè)問(wèn)題很輕微，但是是可以報(bào)告的。有些時(shí)候，屏幕上顯示出無(wú)用信息只是一個(gè)孤立的問(wèn)題（因此對(duì)它置之不理的決定可能是明智的，尤其是程序快要交付的時(shí)候）。但是如果繼續(xù)運(yùn)行這個(gè)程序，可能會(huì)出現(xiàn)一旦顯示無(wú)用

信息之后，程序幾乎會(huì)馬上崩潰----最嚴(yán)重的后果。2）找出最簡(jiǎn)單、最直接和最常見的BUG觸發(fā)條件。如果理解和改正問(wèn)題僅需要很小的工作量，那么就會(huì)修復(fù)它。如果問(wèn)題的解決需要（或看起來(lái)需要）很長(zhǎng)的時(shí)間和精力，程序員會(huì)不太情愿改正它。如果問(wèn)題會(huì)在程序日常使用的過(guò)程中發(fā)生，管理層對(duì)問(wèn)題的關(guān)注會(huì)增加。如果問(wèn)題的出現(xiàn)幾乎無(wú)人知曉，關(guān)注程度會(huì)很低。3）找出產(chǎn)生相同問(wèn)題的其他路徑。有時(shí)不止一種方法可以觸發(fā)一個(gè)錯(cuò)誤，若有兩條不同的路徑通往同一個(gè)BUG，比起僅有一條路徑來(lái)勢(shì)更有力的危險(xiǎn)信號(hào)。即使每條路徑都包含著很復(fù)雜的步驟序列，存在兩條路徑也意味著代碼中含有嚴(yán)重的錯(cuò)誤。要充分展示各條路徑的差異，不能讓程序員把多條路徑視為對(duì)同一個(gè)BUG的相似描述。4）找出相關(guān)的問(wèn)題。根據(jù)積累的經(jīng)驗(yàn)，仿照以前發(fā)現(xiàn)BUG的方法，查找程序中其他可能的位置，能有相當(dāng)?shù)臋C(jī)會(huì)在新的代碼中找出類似的問(wèn)題。二、可重現(xiàn)BUG的分析技術(shù)

1）尋找最關(guān)鍵的步驟根據(jù)BUG查找代碼中的錯(cuò)誤，不要忽略任何細(xì)微的有關(guān)錯(cuò)誤的線索。應(yīng)該查找下列的問(wèn)題：

1.錯(cuò)誤信息；

2.處理延時(shí)；

3.屏幕閃爍；

4.光標(biāo)跳躍；

5.文本錯(cuò)誤；

6.工作指示燈在設(shè)備未使用時(shí)亮起。

2）最大程度地提高程序運(yùn)行的可見性將程序運(yùn)行的越多方面變的可見，就越能看到更多的出錯(cuò)情況，也就越有可能明確關(guān)鍵的步驟。用調(diào)試工具可以報(bào)告出當(dāng)前活動(dòng)的進(jìn)程、程序占用的內(nèi)存或其他資源的數(shù)量、正在使用的堆棧的數(shù)量以及其他的內(nèi)部信息。

1.監(jiān)測(cè)堆棧中的遺留數(shù)據(jù)的多少

2.監(jiān)側(cè)進(jìn)程的收發(fā)消息，內(nèi)存的占用情況。另一條途徑是將屏幕顯示的所有內(nèi)容和磁盤文件的所有變更統(tǒng)統(tǒng)都打印出來(lái)，然后進(jìn)行分析。3）多嘗試一些結(jié)果將程序的事件進(jìn)行組合的執(zhí)行。4）查找后續(xù)錯(cuò)誤一旦發(fā)現(xiàn)了某個(gè)錯(cuò)誤，也應(yīng)該再堅(jiān)持運(yùn)行程序一段時(shí)間，看看是否會(huì)有其他的錯(cuò)誤出現(xiàn)。我們要認(rèn)真細(xì)致地做這件事，最初出現(xiàn)的問(wèn)題可能會(huì)誘發(fā)一系列后續(xù)問(wèn)題。5）漸進(jìn)地省略或改變步驟問(wèn)題復(fù)雜的時(shí)候可以跳過(guò)一些步驟，但對(duì)每個(gè)要省略的步驟進(jìn)行測(cè)試，看看它是否是重現(xiàn)BUG的必要環(huán)節(jié)。

至于改變步驟，可以在每個(gè)步驟中查找是否存在邊界條件，對(duì)邊界條件的敏感程度，是一個(gè)測(cè)試人員技術(shù)成熟與否的標(biāo)志之一。

6）在程序以前的版本中查找錯(cuò)誤7）查找配置依賴三、讓BUG可重現(xiàn)如何觸發(fā)BUG?將我們記得的有關(guān)第一次操作的所有事情都記下來(lái)，進(jìn)行一步一步的問(wèn)題回溯。倘若沒有效果，可能是沒有滿足確切的條件，BUG沒有顯現(xiàn)出來(lái)。下面列舉了幾種應(yīng)該考慮到的情況:1）競(jìng)爭(zhēng)條件2）被遺忘的細(xì)節(jié)3）BUG造成的影響會(huì)導(dǎo)致其無(wú)法重現(xiàn)4）BUG是依賴于內(nèi)存的5）僅會(huì)在初次運(yùn)行時(shí)出現(xiàn)的BUG6）因數(shù)據(jù)錯(cuò)誤導(dǎo)致的BUG7）由于一些其他問(wèn)題附帶引起的BUG8）間斷性硬件故障9）BUG依賴于時(shí)間

10）BUG依賴與資源11）BUG由長(zhǎng)期積累形成8.3.4BUG管理流程

對(duì)BUG的跟蹤管理是測(cè)試工作的一個(gè)重要部分，測(cè)試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，因此，對(duì)BUG進(jìn)行跟蹤管理，確保每個(gè)被發(fā)現(xiàn)的缺陷都能及時(shí)得到處理。BUG管理流程是一套復(fù)雜的處理過(guò)程，涉及到測(cè)試員（復(fù)審員）、項(xiàng)目數(shù)據(jù)庫(kù)管理員、實(shí)施員（設(shè)計(jì)員）三方的交互，圖8-4所示的BUG管理流轉(zhuǎn)圖詳細(xì)描述了三方關(guān)聯(lián)關(guān)系（同樣適合正式技術(shù)復(fù)審問(wèn)題處理流程）。圖8-4BUG管理流轉(zhuǎn)圖BUG跟蹤管理的起始動(dòng)作是測(cè)試員（復(fù)審員）選擇一個(gè)測(cè)試用例開始測(cè)試，當(dāng)測(cè)試員（復(fù)審員）發(fā)現(xiàn)程序?qū)嶋H輸出值和程序期望值不符的時(shí)候，他就發(fā)現(xiàn)了一個(gè)BUG，并執(zhí)行流程第二個(gè)動(dòng)作“填寫測(cè)試的實(shí)際結(jié)果”。當(dāng)測(cè)試員（復(fù)審員）向BUG跟蹤管理系統(tǒng)遞交該BUG時(shí)，系統(tǒng)將該BUG保存至“項(xiàng)目數(shù)據(jù)庫(kù)”中，并且同步發(fā)送一個(gè)消息至“AutoMailSend”（可以是一個(gè)程序），由它向該BUG的最終負(fù)責(zé)者實(shí)施員（設(shè)計(jì)員）發(fā)送一份“ErrorReport”。實(shí)施員（設(shè)計(jì)員）會(huì)及時(shí)接受到這樣的BUG報(bào)告，并且根據(jù)報(bào)告中包含的BUG唯一序號(hào)向“項(xiàng)目數(shù)據(jù)庫(kù)”查詢?cè)揃UG的詳細(xì)信息。當(dāng)實(shí)施員（設(shè)計(jì)員）對(duì)BUG跟蹤的修復(fù)動(dòng)作完成后，就會(huì)在“項(xiàng)目數(shù)據(jù)庫(kù)”中將該BUG的狀態(tài)轉(zhuǎn)換為“Fixed”，BUG跟蹤管理系統(tǒng)接收到這樣的“UpData”動(dòng)作，就會(huì)自動(dòng)向BUG的測(cè)試員（復(fù)審員）發(fā)送BUG已經(jīng)修復(fù)的消息，測(cè)試員（復(fù)審員）對(duì)BUG進(jìn)行確認(rèn)測(cè)試，如果該BUG正確修復(fù)則關(guān)閉它，如果該BUG依然存在問(wèn)題，整個(gè)動(dòng)作回復(fù)到BUG跟蹤管理的起始處。1、如何提交系統(tǒng)中的BUG不要在同一封郵件或者同一個(gè)錯(cuò)誤輸入框中報(bào)告多個(gè)（尤其在不同軟件包之中的）錯(cuò)誤。2、使用自動(dòng)BUG報(bào)告工具使用成熟的BUG管理工具實(shí)現(xiàn)BUG全程管理，可以有效避免被大量的測(cè)試數(shù)據(jù)所淹沒而引發(fā)一系列問(wèn)題。有如下一些優(yōu)點(diǎn)：①BUG管理工具安裝簡(jiǎn)單、運(yùn)行方便、管理安全。②BUG管理工具有利于BUG的清楚傳遞，由于使用了后臺(tái)數(shù)據(jù)庫(kù)進(jìn)行管理，提供全面詳盡的報(bào)告輸入項(xiàng)，可產(chǎn)生標(biāo)準(zhǔn)化的BUG報(bào)告。

③BUG管理工具提供大量的分析選項(xiàng)和強(qiáng)大的查詢匹配能力，能根據(jù)各種條件組合進(jìn)行BUG統(tǒng)計(jì)。當(dāng)BUG在它的生命周期中變化時(shí)，開發(fā)人員、測(cè)試人員、及項(xiàng)目管理人員將及時(shí)獲得動(dòng)態(tài)的變化信息。④BUG管理人員允許你獲取BUG歷史記錄，并在檢查BUG的狀態(tài)時(shí)參考這一記錄。⑤BUG管理工具可針對(duì)軟件產(chǎn)品設(shè)定不同的模塊，并針對(duì)不同的模塊設(shè)定相關(guān)的責(zé)任人員，這樣可以實(shí)現(xiàn)提交報(bào)告時(shí)自動(dòng)發(fā)給指定的責(zé)任人。⑥BUG管理工具支持權(quán)限，設(shè)定不同的用戶對(duì)BUG記錄的操作權(quán)限不同，可有效控制進(jìn)程管理。⑦BUG管理工具設(shè)定不同的BUG嚴(yán)重程度和優(yōu)先級(jí)，從最初的報(bào)告到最后的解決，確保了錯(cuò)誤不會(huì)被忽略，同時(shí)可以使注意力集中在優(yōu)先級(jí)和嚴(yán)重程度高的錯(cuò)誤上。⑧BUG管理工具自動(dòng)發(fā)送郵件通知相關(guān)責(zé)任人員，并且根據(jù)設(shè)定的不同責(zé)任人，自動(dòng)發(fā)送最新的BUG動(dòng)態(tài)信息，有效地幫助測(cè)試人員和開發(fā)人員進(jìn)行溝通。3、通過(guò)電子郵件發(fā)送BUG報(bào)告描述主題是要清楚而簡(jiǎn)潔地描述BUG。郵件內(nèi)容第一行的格式為：Package:<something>,<something>指要報(bào)告的包含錯(cuò)誤的Class包名稱。郵件內(nèi)容的第二行格式為：Version:<something>，<something>指該軟件包的版本。其他內(nèi)容應(yīng)該注意以下幾點(diǎn)：①確切而完整的錯(cuò)誤信息（這非常重要）。②您做了或輸入了些什么，以便重現(xiàn)該問(wèn)題。③錯(cuò)誤行為的描述：您預(yù)期應(yīng)該有什么樣的行為，而您看到的是如何。④您建議如何改正，或甚至您自己做的修補(bǔ)程序。⑤詳細(xì)解釋您如何設(shè)置該程序，包含完整的設(shè)置文件屬性。⑥任何其他依賴于這個(gè)問(wèn)題軟件包的軟件包版本。4、BUG詳細(xì)內(nèi)容信息如表8-1所示。5、輕微的BUG報(bào)告輕微的BUG報(bào)告應(yīng)該和重要的BUG報(bào)告分開發(fā)送。BUG描述信息BUG類別可追蹤BUG標(biāo)志BUG基本描述BUG所屬項(xiàng)目\子系統(tǒng)\模塊所屬的項(xiàng)目\子系統(tǒng)\模塊，最好能較精確的定位至模塊BUG標(biāo)題BUG簡(jiǎn)明描述BUG流轉(zhuǎn)狀態(tài)BUG流轉(zhuǎn)狀態(tài)，可分為Unconfirmed、New、Assigned、Reassigned、Needinfo、Reopened、Resolved、Reopen、Verified、ClosedBUG嚴(yán)重等級(jí)BUG嚴(yán)重等級(jí),可分為Critical、Grave、Serious、Blocker、Important、Normal、Minor、TrivialBUG解決關(guān)鍵字BUG解決關(guān)鍵字,可分為Fixed、Wontfix、Later、Remind、Duplicate、Incomplete、NotaBUG、Invalid、WorksformeBUG提交人BUG提交人的名字(郵件地址)BUG提交時(shí)間BUG提交的時(shí)間，例如2003-1-2314：00表8-1Bug詳細(xì)內(nèi)容描述(part1)BUG過(guò)程描述BUG指定解決人由測(cè)試人員確定，如果該BUG的流轉(zhuǎn)狀態(tài)從Unconfirmed&New變?yōu)锳ssignedBUG指定解決時(shí)間由測(cè)試人員確定，如果該BUG超過(guò)指定修復(fù)時(shí)間而未修復(fù)，則系統(tǒng)自動(dòng)發(fā)送報(bào)警郵件。BUG處理描述如果實(shí)現(xiàn)人員對(duì)代碼進(jìn)行了修改，要求在此處體現(xiàn)出修改內(nèi)容，如果代碼行數(shù)很多則縮略書寫B(tài)UG處理時(shí)間記錄BUG處理時(shí)間BUG確認(rèn)測(cè)試人員驗(yàn)證該BUG被正確的修復(fù)了BUG確認(rèn)描述BUG確認(rèn)修復(fù)內(nèi)容BUG確認(rèn)時(shí)間BUG確認(rèn)修復(fù)時(shí)間BUG詳細(xì)描述對(duì)BUG的詳細(xì)描述，對(duì)BUG描述的詳細(xì)程度直接影響實(shí)現(xiàn)人員對(duì)該BUG的修復(fù)效果，描述應(yīng)該盡可能詳細(xì)BUG環(huán)境說(shuō)明對(duì)測(cè)試環(huán)境的描述，避免實(shí)現(xiàn)人員和測(cè)試人員環(huán)境的不同造成BUG異議BUG附帶附件附件包括對(duì)BUG現(xiàn)場(chǎng)出錯(cuò)快照(圖片)，錯(cuò)誤輸出文件信息等，加強(qiáng)該BUG的表現(xiàn)力表8-1Bug詳細(xì)內(nèi)容描述(part2)6、不知道歸屬的BUG設(shè)置默認(rèn)的BUG修復(fù)人員，防止意外的丟失了BUG負(fù)責(zé)人的信息。7、關(guān)閉BUG報(bào)告提出的BUG被修正后，通過(guò)測(cè)試人員確認(rèn)、測(cè)試通過(guò)才可以關(guān)閉。BUG的提出和關(guān)閉都是只能由測(cè)試人員執(zhí)行。將所有不能被修復(fù)的BUG收集起來(lái)標(biāo)記為“Wontfix”，統(tǒng)一遞交給代碼評(píng)審委員會(huì)。

8、接續(xù)的討論信息BUG的管理系統(tǒng)的流轉(zhuǎn)過(guò)程中，會(huì)有針對(duì)該BUG的新的描述信息加入，例如實(shí)現(xiàn)人員或者測(cè)試人員加上的對(duì)處理BUG自己的理解和曾經(jīng)使用過(guò)的解決方案等。對(duì)于新的描述信息，請(qǐng)遵循以下規(guī)則：①新的描述信息和舊的描述信息之間應(yīng)該增加醒目的隔離條。②新的信息描述應(yīng)該包括提供者的名稱和電子郵件地址。③新的描述信息應(yīng)該包括信息的新增時(shí)間。

④新的描述信息如果是建議修改意見，應(yīng)該在該信息的開頭加上關(guān)鍵字“建議解決方案”。⑤新的描述信息如果是某些疑問(wèn)，應(yīng)該在該信息的