第8章_軟件BUG和管理

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

2、實(shí)現(xiàn)的某 種功能的失效或違背。 軟件缺陷有很多種，其中主要軟件缺陷類(lèi) 型有： 1.一些功能、特性沒(méi)有實(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.用戶(hù)不能接受的其他問(wèn)題，如存取時(shí)間過(guò)長(zhǎng)、界面 不美觀。 8.1.1 8.1.1 BUG的影響的影響 Bug會(huì)給用戶(hù)或使用者帶來(lái)相當(dāng)大的麻煩，會(huì) 給集體或者國(guó)家?guī)?lái)很大的經(jīng)濟(jì)損失。如：千年蟲(chóng) 問(wèn)題。 8.1.2 BUG的產(chǎn)生的產(chǎn)生 BUG的由來(lái)。的由來(lái)。 對(duì)于軟件而言，對(duì)于軟件而言，BUG是程序編寫(xiě)錯(cuò)誤而導(dǎo)致軟是程序編寫(xiě)錯(cuò)誤而導(dǎo)

3、致軟 件產(chǎn)生問(wèn)題的缺陷。件產(chǎn)生問(wèn)題的缺陷。 軟件測(cè)試的目的就是找到軟件程序代碼內(nèi)的BU G，糾正它，叫做DEBUG。 BUG產(chǎn)生的原因很多，具體有以下幾點(diǎn)。 1程序編寫(xiě)錯(cuò)誤 Bug的難以避免性。 2需求變更過(guò)于頻繁 需求變更所造成的結(jié)果就是變更程序代碼，程序 代碼只要稍做變更就必須經(jīng)過(guò)測(cè)試來(lái)確保運(yùn)行正常， 所以這個(gè)影響是一個(gè)連鎖反應(yīng)或稱(chēng)為依存問(wèn)題。 3軟件的復(fù)雜度 圖形用戶(hù)界面（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)目人員在同客戶(hù)進(jìn)行

4、交流時(shí)常常存在著各 種各樣的問(wèn)題，究其原因，還是因?yàn)轫?xiàng)目人員、參 與人員和客戶(hù)之間沒(méi)有詳細(xì)、充分、謹(jǐn)慎地進(jìn)行交 流。 5測(cè)試人員的經(jīng)驗(yàn)與技巧不足 6時(shí)間過(guò)于緊迫 7缺乏文檔：貧乏或者差勁的文檔使得代碼維護(hù) 和修改變得非常困難，結(jié)果會(huì)導(dǎo)致其他開(kāi)發(fā)人員 或客戶(hù)有許多錯(cuò)誤的理解。 8管理上的缺陷 8.2 BUG的種類(lèi)的種類(lèi) BUG是軟件“與生俱來(lái)”的特征，不同的軟 件開(kāi)發(fā)階段會(huì)產(chǎn)生不同的BUG，而不同的BUG又 會(huì)產(chǎn)生不同的后果，因此BUG的屬性也并非相同。 8.2.1需求階段的需求階段的BUG 這個(gè)階段的BUG是最難發(fā)現(xiàn)、最難修復(fù)的，而 且值得注意的是需求階段的BUG如果沒(méi)有及時(shí)發(fā)現(xiàn) 等到實(shí)現(xiàn)階段

5、發(fā)現(xiàn)時(shí)，那么修復(fù)它的費(fèi)用要比當(dāng)初 修復(fù)它要高1575倍。 主要的原因如下： 1、模糊、不清晰的需求； 2、被忽略的需求； 3、相互沖突的需求； 8.2.2分析設(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ì)； 8.2.3實(shí)現(xiàn)階段的BUG 就是軟件系統(tǒng)中最普通、最一般的“常規(guī)BUG”。 可以將實(shí)現(xiàn)階段出現(xiàn)的BUG分為下面幾類(lèi)： 1、消息錯(cuò)誤 2、用戶(hù)界面錯(cuò)誤 3、遺漏的功能 4、內(nèi)存溢出或者程序崩潰 5、其他

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

7、器上 的代碼和實(shí)現(xiàn)人員本機(jī)最新代碼版本不一致。 可能是實(shí)現(xiàn)人員操作配置管理工具不正確引起 的；還可能體現(xiàn)了測(cè)試人員或者最終用戶(hù)操作不 正確。 8.2.5短視將來(lái)的短視將來(lái)的BUG “千年蟲(chóng)”問(wèn)題就是當(dāng)初的設(shè)計(jì)人員為了節(jié)省 一點(diǎn)硬件成本給全球造成了難以估量的損失。 作者曾經(jīng)為一家大藥房開(kāi)發(fā)了一套藥品管理 的進(jìn)銷(xiāo)存軟件，由于最初的時(shí)候?qū)I(yè)務(wù)流程并不 是很熟悉，所以在定義藥品編碼的時(shí)候把許多藥 品的ID號(hào)定義為了整型變量（INT），開(kāi)始作者認(rèn) 為這些足以定義所有的藥品名稱(chēng)了，沒(méi)想到 一年以后，由于藥房的業(yè)務(wù)量急增，藥品的ID也 就不夠了，由于整套系統(tǒng)是由Power Builder編寫(xiě)， 整型變量的最

8、大值只有32767，因此程序經(jīng)常由于 數(shù)據(jù)溢出而出現(xiàn)問(wèn)題，所以作者被迫用了近一個(gè) 星期的時(shí)間來(lái)修改原來(lái)的程序。 8.2.6靜態(tài)文檔的靜態(tài)文檔的BUG 文檔BUG的定義很簡(jiǎn)單，即說(shuō)明模糊、描述 不完整和過(guò)期的都屬于文檔BUG。說(shuō)明模糊特指 無(wú)充分的信息判斷如何正確地處理事情；描述不 完整特指文檔信息不足以支持用戶(hù)完成某項(xiàng)工作； 過(guò)期的文檔是沒(méi)有及時(shí)更新過(guò)的、錯(cuò)誤的文檔。 8.3.1 BUG報(bào)告單的內(nèi)容報(bào)告單的內(nèi)容 BUG報(bào)告單也叫缺陷報(bào)告單或者問(wèn)題報(bào)告單。 問(wèn)題報(bào)告單所需的基本信息類(lèi)型是大同小異的， 不同的只是組織和標(biāo)志。 介紹一下字段： （1）問(wèn)題報(bào)告編號(hào) （2）程序名 （3）版本標(biāo)識(shí)：發(fā)布號(hào)

9、和版本號(hào)。是用來(lái)識(shí)別被 測(cè)的代碼。 例如：某個(gè)版本號(hào)可能是1.01m，發(fā) 布號(hào)是1.01，“m”指1.01版本的第13稿。 （4）報(bào)告類(lèi)型：描述了發(fā)現(xiàn)的問(wèn)題類(lèi)型。包括：編 碼錯(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ù)的軟盤(pán)、鍵盤(pán)捕獲記錄或一組可產(chǎn) 生測(cè)試用例的宏、程序的打印輸出、內(nèi)存dump或 一份注釋?zhuān)锩嬖敿?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è)試看

10、能否再次出現(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)行大體分類(lèi)。 （14）承辦人 （15）注釋?zhuān)撼绦騿T在這里簡(jiǎn)短地說(shuō)明為什么要推 遲處理，或說(shuō)明是如何改正問(wèn)題的。 （16）狀態(tài)。三個(gè)狀態(tài)碼：開(kā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)一步信息 不同意

11、建議 重復(fù):關(guān)閉重復(fù)上報(bào)的缺陷。 （19）簽名:簽署以表明已經(jīng)對(duì)改動(dòng)進(jìn)行了測(cè)試，對(duì) 結(jié)果表示滿(mǎn)意。 （20）暫緩處理：對(duì)缺陷的推遲處理。 圖圖8-3 8-3 、8-48-4整合起來(lái)即為一張完整的報(bào)告單。整合起來(lái)即為一張完整的報(bào)告單。 公司名稱(chēng) 密級(jí) 問(wèn)題報(bào)告編號(hào): 程序名 發(fā)布號(hào) 版本號(hào) 報(bào)告類(lèi)型(1-6) 嚴(yán)重性（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)僅供開(kāi)發(fā)組填寫(xiě) 功能域 承辦人 注

12、釋 狀態(tài)(1-2)優(yōu)先級(jí)(1-5) 1.開(kāi)放 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) 圖8-3 報(bào)告單(part 1) 公司名稱(chēng) 密級(jí) 問(wèn)題報(bào)告編號(hào): 程序名 發(fā)布號(hào) 版本號(hào) 報(bào)告類(lèi)型(1-6) 嚴(yán)重性（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)告人日期 下面各

13、項(xiàng)僅供開(kāi)發(fā)組填寫(xiě) 功能域 承辦人 注釋 狀態(tài)(1-2)優(yōu)先級(jí)(1-5) 1.開(kāi)放 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) 圖8-4 報(bào)告單(part 2) 8.3.2 BUG 8.3.2 BUG報(bào)告的特點(diǎn)報(bào)告的特點(diǎn) 一份好的問(wèn)題報(bào)告應(yīng)是書(shū)面的、已編號(hào)的、 簡(jiǎn)單的、易于理解的、可重現(xiàn)的、易讀的和不做 判斷的。 1) 書(shū)面的 一份書(shū)面的報(bào)告是必要的，供日后對(duì)修改后 的程序進(jìn)行測(cè)試時(shí)使用；讓管理層、銷(xiāo)售人員和 產(chǎn)品支持人員檢查。 2) 已編號(hào)的 依據(jù)惟

14、一的編號(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.38.3.3重現(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)。 任何熟悉程序的人都能夠依照我們的描述使程 序進(jìn)入該狀態(tài)。 從那個(gè)狀態(tài)出發(fā)，我們確定出精確的一組步驟 來(lái)暴露出問(wèn)題。 為使報(bào)告更有效，我們應(yīng)該對(duì)問(wèn)題進(jìn)一步分析，

15、 目的在于： 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)單、最直接和最常見(jiàn)的BUG觸發(fā)條件。 如果理解和改正問(wèn)題僅需要很小的工作量，那 么就會(huì)修復(fù)它。 如果問(wèn)題的解決需要（或看起來(lái)

16、需要）很長(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ì)在 新的代碼

17、中找出類(lèi)似的問(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)行的可見(jiàn)性 將程序運(yùn)行的越多方面變的可見(jià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)存的占用情況。 另一條

18、途徑是將屏幕顯示的所有內(nèi)容和磁盤(pán)文件 的所有變更統(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)B UG的必要環(huán)節(jié)。 至于改變步驟，可以在每個(gè)步驟中查找是否 存在邊界條件，對(duì)邊界條件的敏感程度，是一 個(gè)測(cè)試人員技術(shù)成熟與否的標(biāo)志之一。 6）在程序以前的版本中查找錯(cuò)誤 7）查找配置依賴(lài) 三、

19、讓BUG可重現(xiàn) 如何觸發(fā)BUG? 將我們記得的有關(guān)第一次操作的所有事情都記 下來(lái)，進(jìn)行一步一步的問(wèn)題回溯。 倘若沒(méi)有效果，可能是沒(méi)有滿(mǎn)足確切的條件， BUG沒(méi)有顯現(xiàn)出來(lái)。 下面列舉了幾種應(yīng)該考慮到的情況: 1）競(jìng)爭(zhēng)條件 2）被遺忘的細(xì)節(jié) 3）BUG造成的影響會(huì)導(dǎo)致其無(wú)法重現(xiàn) 4）BUG是依賴(lài)于內(nèi)存的 5）僅會(huì)在初次運(yùn)行時(shí)出現(xiàn)的BUG 6）因數(shù)據(jù)錯(cuò)誤導(dǎo)致的BUG 7）由于一些其他問(wèn)題附帶引起的BUG 8）間斷性硬件故障 9）BUG依賴(lài)于時(shí)間 10）BUG依賴(lài)與資源 11）BUG由長(zhǎng)期積累形成 8.3.4 BUG管理流程管理流程 對(duì)BUG的跟蹤管理是測(cè)試工作的一個(gè)重要部 分，測(cè)試的目的是為了盡早發(fā)

20、現(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)題處理流程）。 測(cè) 試 員 （ 復(fù) 審 員 ）項(xiàng) 目 數(shù) 據(jù) 庫(kù)實(shí) 施 員 （ 設(shè) 計(jì) 員 ） 測(cè) 試 用 例 開(kāi) 始 （ 用 例 規(guī) 約 ） 填 寫(xiě) 測(cè) 試 結(jié) 果 （ 復(fù) 審 結(jié) 果 ） 的 實(shí) 際 結(jié) 果 和 備 注 輸 入 框 根 據(jù) 反 饋 檢 查 修 改 后 結(jié) 果 提 交 記 錄 至 項(xiàng) 目 數(shù) 據(jù) 庫(kù)

21、 A u to M a il S e n d 自 動(dòng) 返 回 郵 件 通 知 測(cè) 試 人 員 （ 復(fù) 審 人 員 ） 如 果 測(cè) 試 結(jié) 果 （ 復(fù) 審 結(jié) 果 ） 為 已 解 決 ,項(xiàng) 目 數(shù) 據(jù) 庫(kù) 會(huì) 自 動(dòng) 通 知 相 關(guān) 人 員 ， 告 知 問(wèn) 題 已 經(jīng) 關(guān) 閉 將 反 饋 提 交 至 項(xiàng) 目 數(shù) 據(jù) 庫(kù) 針 對(duì) 測(cè) 試 結(jié) 果 （ 復(fù) 審 結(jié) 果 ） 填 寫(xiě) 相 應(yīng) 修 改 意 見(jiàn) 已 經(jīng) 解 決 M e s s a g e 未 解 決 回 U p D a ta F in d V ie wM e s s a g e S u b m it F in d 數(shù) 據(jù) 庫(kù) 圖8-4 BUG

22、管理流轉(zhuǎn)圖 BUG跟蹤管理的起始動(dòng)作是測(cè)試員（復(fù)審員） 選擇一個(gè)測(cè)試用例開(kāi)始測(cè)試，當(dāng)測(cè)試員（復(fù)審 員）發(fā)現(xiàn)程序?qū)嶋H輸出值和程序期望值不符的 時(shí)候，他就發(fā)現(xiàn)了一個(gè)BUG，并執(zhí)行流程第二 個(gè)動(dòng)作“填寫(xiě)測(cè)試的實(shí)際結(jié)果”。 當(dāng)測(cè)試員（復(fù)審員）向BUG跟蹤管理系統(tǒng)遞 交該BUG時(shí)，系統(tǒng)將該BUG保存至“項(xiàng)目數(shù)據(jù) 庫(kù)”中，并且同步發(fā)送一個(gè)消息至“AutoMail S end”（可以是一個(gè)程序），由它向該BUG的最 終負(fù)責(zé)者實(shí)施員（設(shè)計(jì)員）發(fā)送一份“Error Re port”。 實(shí)施員（設(shè)計(jì)員）會(huì)及時(shí)接受到這樣的BUG 報(bào)告，并且根據(jù)報(bào)告中包含的BUG唯一序號(hào)向 “項(xiàng)目數(shù)據(jù)庫(kù)”查詢(xún)?cè)揃UG的詳細(xì)信息。 當(dāng)

23、實(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è)試，如果該B UG正確修復(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ù)所淹沒(méi)而引發(fā)一 系列問(wèn)

24、題。 有如下一些優(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)大的 查詢(xún)匹配能力，能根據(jù)各種條件組合進(jìn)行BUG 統(tǒng)計(jì)。當(dāng)BUG在它的生命周期中變化時(shí)，開(kāi)發(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é)任 人。

25、BUG管理工具支持權(quán)限，設(shè)定不同的用戶(hù)對(duì)B UG記錄的操作權(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è)試人員和開(kāi) 發(fā)人員進(jìn)行溝通。 3、通過(guò)電子郵件發(fā)送BUG報(bào)告 描述主題是要清楚而簡(jiǎn)潔地描述BUG。 郵件內(nèi)容第一行的格式為：Package:, 指要報(bào)告的包含錯(cuò)誤的Class包名稱(chēng)。 郵件內(nèi)容的第二行格式為：Version:， 指該軟件包的

26、版本。 其他內(nèi)容應(yīng)該注意以下幾點(diǎn)： 確切而完整的錯(cuò)誤信息（這非常重要）。 您做了或輸入了些什么，以便重現(xiàn)該問(wèn)題。 錯(cuò)誤行為的描述：您預(yù)期應(yīng)該有什么樣的行為， 而您看到的是如何。 您建議如何改正，或甚至您自己做的修補(bǔ)程序。 詳細(xì)解釋您如何設(shè)置該程序，包含完整的設(shè)置文 件屬性。 任何其他依賴(lài)于這個(gè)問(wèn)題軟件包的軟件包版本。 4、 BUG詳細(xì)內(nèi)容信息 如表8-1所示。 5、 輕微的BUG報(bào)告 輕微的BUG報(bào)告應(yīng)該和重要的BUG報(bào)告分開(kāi)發(fā) 送。 BUG描 述信息 BUG類(lèi)別可追蹤BUG標(biāo)志 BUG 基本 描述 BUG所屬項(xiàng)目 子系統(tǒng)模塊 所屬的項(xiàng)目子系統(tǒng)模塊，最好能較精確的定位 至模塊 BUG標(biāo)題BUG

27、簡(jiǎn)明描述 BUG流轉(zhuǎn)狀態(tài)BUG流轉(zhuǎn)狀態(tài)，可分為Unconfirmed、New、Assi gned、Reassigned、Needinfo、Reopened、Res olved、Reopen、Verified、Closed BUG嚴(yán)重等級(jí)BUG嚴(yán)重等級(jí),可分為Critical、Grave、Serious、 Blocker、Important、Normal、Minor、Trivial BUG解決關(guān)鍵字 BUG解決關(guān)鍵字,可分為Fixed、Wontfix、Later、 Remind、Duplicate、Incomplete、NotaBUG、I nvalid、Worksforme BUG提交人BUG提

28、交人的名字(郵件地址) BUG提交時(shí)間BUG提交的時(shí)間，例如2003-1-23 14：00 表8-1 Bug詳細(xì)內(nèi)容描述(part 1) BUG 過(guò)程描 述 BUG指定 解決人 由測(cè)試人員確定，如果該BUG的流轉(zhuǎn)狀態(tài)從Unconfir med&New變?yōu)锳ssigned BUG指定解 決時(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ù)很多則縮略書(shū)寫(xiě) BUG處理時(shí)間記錄BUG處理時(shí)間 BUG確認(rèn)測(cè)試 人員 驗(yàn)證該BUG被正確的修復(fù)了 BUG確認(rèn)描述BUG確認(rèn)修復(fù)內(nèi)容 B

29、UG確認(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-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)該包括提供者的名稱(chēng)和電子 郵件地址。 新的描述信息應(yīng)該包括信息的新增時(shí)間。 新的描述信息如果是建議修改意見(jiàn)，應(yīng)該在該 信息