全面的軟件BUG和管理介紹

1、軟件軟件BUGBUG和管理和管理 本章要點(diǎn)本章要點(diǎn) .軟件Bug對(duì)軟件質(zhì)量的影響；.常見的軟件Bug類型，重現(xiàn)軟件Bug的分析技術(shù)；.軟件Bug的描述和管理。 本章目標(biāo)本章目標(biāo) 了解軟件BUG的影響和產(chǎn)生；掌握軟件開發(fā)過(guò)程中產(chǎn)生的BUG種類；掌握使BUG重現(xiàn)的技術(shù)；了解軟件BUG報(bào)告單應(yīng)該包括的主要內(nèi)容以及軟件BUG的管理流程。 軟件BUG概述 在IEEE 1983 of IEEE Standard 729中對(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)的某種功能的失效或違背。 軟件

2、缺陷有很多種，其中主要軟件缺陷類型有： 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)、界面不美觀。BUG的影響的影響 Bug會(huì)給用戶或使用者帶來(lái)相當(dāng)大的麻煩，會(huì)給集體或者國(guó)家?guī)?lái)很大的經(jīng)濟(jì)損失。如：千年蟲問(wèn)題。BUG的產(chǎn)生的產(chǎn)生 BUG的由來(lái)。的由來(lái)。 對(duì)于軟件而言，對(duì)于軟件而言，BUG是程序編寫錯(cuò)誤而導(dǎo)致軟是程序編寫錯(cuò)誤而導(dǎo)致軟件產(chǎn)生問(wèn)題的缺陷。件產(chǎn)生問(wèn)題的缺陷。 軟件測(cè)試的目的就是找到軟件程序代碼內(nèi)的BUG

3、，糾正它，叫做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）、BS 結(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)

4、慎地進(jìn)行交流。 5測(cè)試人員的經(jīng)驗(yàn)與技巧不足 6時(shí)間過(guò)于緊迫 7缺乏文檔：貧乏或者差勁的文檔使得代碼維護(hù)和修改變得非常困難，結(jié)果會(huì)導(dǎo)致其他開發(fā)人員或客戶有許多錯(cuò)誤的理解。 8管理上的缺陷BUG的種類的種類 BUG是軟件“與生俱來(lái)”的特征，不同的軟件開發(fā)階段會(huì)產(chǎn)生不同的BUG，而不同的BUG又會(huì)產(chǎn)生不同的后果，因此BUG的屬性也并非相同。需求階段的需求階段的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ù)它要高1575倍。 主要的原因如下： 1、模糊、不清晰的需求； 2、被忽略的需求； 3、相互沖突的需

5、求； 分析設(shè)計(jì)階段的分析設(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ì)； 實(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ò)

6、誤，可歸納為GUI錯(cuò)誤。可能是由于GUI制作不標(biāo)準(zhǔn)而導(dǎo)致用戶不能正確地工作。 第三種類型為遺漏的功能BUG (以輸入框輸入信息錯(cuò)誤，程序拋出未異常為典型) 第四種類型為內(nèi)存溢出或者程序崩潰BUG，表現(xiàn)為程序掛起、系統(tǒng)崩潰，屬于一種比較嚴(yán)重的軟件BUG類型。（詳見教材的藥房藥品進(jìn)存銷的軟件測(cè)試BUG）配置階段的配置階段的BUG 配置階段的BUG出現(xiàn)的原因是復(fù)雜的，比較典型的是舊的代碼覆蓋了新的代碼，或者測(cè)試服務(wù)器上的代碼和實(shí)現(xiàn)人員本機(jī)最新代碼版本不一致。 可能是實(shí)現(xiàn)人員操作配置管理工具不正確引起的；還可能體現(xiàn)了測(cè)試人員或者最終用戶操作不正確。短視將來(lái)的短視將來(lái)的BUG “千年蟲”問(wèn)題就是當(dāng)初的設(shè)

7、計(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)是由Power Builder編寫，整型變量的最大值只有32767，因此程序經(jīng)常由于數(shù)據(jù)溢出而出現(xiàn)問(wèn)題，所以作者被迫用了近一個(gè)星期的時(shí)間來(lái)修改原來(lái)的程序。靜態(tài)文檔的靜態(tài)文檔的BUG 文檔BUG的定義很簡(jiǎn)單，即說(shuō)明模糊、描述不完整和過(guò)期的都屬于文檔BUG。說(shuō)明模糊特指無(wú)

8、充分的信息判斷如何正確地處理事情；描述不完整特指文檔信息不足以支持用戶完成某項(xiàng)工作；過(guò)期的文檔是沒有及時(shí)更新過(guò)的、錯(cuò)誤的文檔。BUG報(bào)告單的內(nèi)容報(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)分。 包含三

9、個(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ō)明為什么要推遲處理，

10、或說(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)： 未解決：初始化狀態(tài)或仍有沖突狀態(tài)。 已改正 不能重現(xiàn) 暫緩：對(duì)存在的問(wèn)題在下個(gè)版本改正。 符合設(shè)計(jì) 由報(bào)告人撤回 需要進(jìn)一步信息 不同意建議 重復(fù):關(guān)閉重復(fù)上報(bào)的缺陷。 （19）簽名:簽署以表明已經(jīng)對(duì)改動(dòng)進(jìn)行了測(cè)試，對(duì)結(jié)果表示滿意。（20）暫緩處理：對(duì)缺陷的推遲處理。 圖圖-3 -3 、圖、圖-4-4整合起來(lái)即為一張完整的報(bào)告單。整合起來(lái)即為一張完整的報(bào)告單。公司名稱 密級(jí) 問(wèn)題報(bào)告編號(hào):程序名 發(fā)布號(hào) 版本號(hào)報(bào)告類型(1-6) 嚴(yán)

11、重性（1-3） 附件（Y/N）1.編碼錯(cuò)誤 4.文檔 1.致命性2.設(shè)計(jì)問(wèn)題 5.硬件 2.嚴(yán)重性3.建議 6.質(zhì)疑 3.輕微性如果有,請(qǐng)描述:問(wèn)題概要問(wèn)題能否重現(xiàn)?(Y/N)問(wèn)題描述及如何重現(xiàn)建議的改正措施(可選)報(bào)告人日期下面各項(xiàng)僅供開發(fā)組填寫功能域 承辦人注釋狀態(tài)(1-2)優(yōu)先級(jí)(1-5)1.開放 2.關(guān)閉處理狀態(tài)(1-9)處理版本1.未解決 4.暫緩 7.由報(bào)告人撤回2.已改正 5.符合設(shè)計(jì) 8.需要進(jìn)一步信息3.不能重現(xiàn) 6.重復(fù) 9.不同意建議暫緩處理(yes/no)圖-3 報(bào)告單(part 1)公司名稱 密級(jí) 問(wèn)題報(bào)告編號(hào):程序名 發(fā)布號(hào) 版本號(hào)報(bào)告類型(1-6) 嚴(yán)重性（1-3

12、） 附件（Y/N）1.編碼錯(cuò)誤 4.文檔 1.致命性2.設(shè)計(jì)問(wèn)題 5.硬件 2.嚴(yán)重性3.建議 6.質(zhì)疑 3.輕微性如果有,請(qǐng)描述:問(wèn)題概要問(wèn)題能否重現(xiàn)?(Y/N)問(wèn)題描述及如何重現(xiàn)建議的改正措施(可選)報(bào)告人日期下面各項(xiàng)僅供開發(fā)組填寫功能域 承辦人注釋狀態(tài)(1-2)優(yōu)先級(jí)(1-5)1.開放 2.關(guān)閉處理狀態(tài)(1-9)處理版本1.未解決 4.暫緩 7.由報(bào)告人撤回2.已改正 5.符合設(shè)計(jì) 8.需要進(jìn)一步信息3.不能重現(xiàn) 6.重復(fù) 9.不同意建議暫緩處理(yes/no)圖-4 報(bào)告單(part 2)BUGBUG報(bào)告的特點(diǎn)報(bào)告的特點(diǎn) 一份好的問(wèn)題報(bào)告應(yīng)是書面的、已編號(hào)的、簡(jiǎn)單的、易于理解的、可重現(xiàn)

13、的、易讀的和不做判斷的。 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à)要三思而后行，本著合作的精神，作出合理的判斷。 重現(xiàn)重現(xiàn)BUGBUG的分析和方法的分析和方法 本節(jié)重點(diǎn)是報(bào)告編碼錯(cuò)誤報(bào)告編碼錯(cuò)誤，而非報(bào)告設(shè)計(jì)問(wèn)題。 一、重現(xiàn)BUG的分析 “可重現(xiàn)”隱含了下列定義：我們能夠描述如何讓程序進(jìn)入某個(gè)已知的狀態(tài)。任何熟悉程序的人都能夠依

14、照我們的描述使程序進(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)單、最直接和

15、最常見的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ù)積累的

16、經(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è)

17、堆棧中的遺留數(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)志之一

18、。 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)的BUG 6）因數(shù)據(jù)錯(cuò)誤導(dǎo)致的BUG 7）由于一些其他問(wèn)題附帶引起的BUG 8）間斷性硬件故障 9）BUG依賴于時(shí)間 10）BUG依賴與資源 11）BUG由長(zhǎng)期積累形成BUG管理流程管理流程 對(duì)BUG的跟蹤管理是測(cè)試工

19、作的一個(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ì)員）三方的交互，圖-4所示的BUG管理流轉(zhuǎn)圖詳細(xì)描述了三方關(guān)聯(lián)關(guān)系（同樣適合正式技術(shù)復(fù)審問(wèn)題處理流程）。 測(cè)試員（復(fù)審員）項(xiàng)目數(shù)據(jù)庫(kù)實(shí)施員（設(shè)計(jì)員）測(cè)試用例開始（用例規(guī)約）填寫測(cè)試結(jié)果（復(fù)審結(jié)果）的實(shí)際結(jié)果和備注輸入框根據(jù)反饋檢查修改后結(jié)果提交記錄至項(xiàng)目數(shù)據(jù)庫(kù) AutoMail Send自 動(dòng) 返 回 郵 件通 知 測(cè) 試 人 員（復(fù)審人員） 如果測(cè)試結(jié)果（復(fù)審結(jié)果）為已解決,項(xiàng)

20、目數(shù)據(jù)庫(kù)會(huì)自動(dòng)通知相關(guān)人員，告知問(wèn)題已經(jīng)關(guān)閉將反饋提交至項(xiàng)目數(shù)據(jù)庫(kù)針對(duì)測(cè)試結(jié)果（復(fù)審結(jié)果）填寫相應(yīng)修改意見已經(jīng)解決Message未解決回UpDataFindViewMessageSubmitFind數(shù)據(jù)庫(kù)圖-4 BUG管理流轉(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è)消息至“AutoMail Send”（可以是一個(gè)程序），由它向該B

21、UG的最終負(fù)責(zé)者實(shí)施員（設(shè)計(jì)員）發(fā)送一份“Error Report”。 實(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 不要在同一封郵件或者同一

22、個(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歷史記錄，并在檢查

23、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。

24、 郵件內(nèi)容第一行的格式為：Package:, 指要報(bào)告的包含錯(cuò)誤的Class包名稱。 郵件內(nèi)容的第二行格式為：Version:， 指該軟件包的版本。 其他內(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)容信息 如表-1所示。 5、 輕微的BUG報(bào)告 輕微的BUG報(bào)告應(yīng)該和重要的BUG報(bào)告分開發(fā)送。BUG描述信息BUG類別可追

25、蹤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

26、、Incomplete、NotaBUG、Invalid、WorksformeBUG提交人BUG提交人的名字(郵件地址)BUG提交時(shí)間BUG提交的時(shí)間，例如2003-1-23 14：00表-1 Bug詳細(xì)內(nèi)容描述(part 1)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)證

27、該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)力表-1 Bug詳細(xì)內(nèi)容描述(part 2) 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)鍵字“建議解決方案”。 新的描述