全面的軟件BUG和管理介紹

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

2、缺陷有很多種，其中主要軟件缺陷類型有： 1.一些功能、特性沒有實現(xiàn)或只實現(xiàn)了一部分； 2.軟件設(shè)計不合理，存在缺陷。實際運(yùn)行結(jié)果和預(yù)期結(jié)果不一致； 3.運(yùn)行出錯，包括運(yùn)行中斷、系統(tǒng)崩潰、界面混亂 4.數(shù)據(jù)結(jié)果不正確、精度不夠； 5.用戶不能接受的其他問題，如存取時間過長、界面不美觀。BUG的影響的影響 Bug會給用戶或使用者帶來相當(dāng)大的麻煩，會給集體或者國家?guī)砗艽蟮慕?jīng)濟(jì)損失。如：千年蟲問題。BUG的產(chǎn)生的產(chǎn)生 BUG的由來。的由來。 對于軟件而言，對于軟件而言，BUG是程序編寫錯誤而導(dǎo)致軟是程序編寫錯誤而導(dǎo)致軟件產(chǎn)生問題的缺陷。件產(chǎn)生問題的缺陷。 軟件測試的目的就是找到軟件程序代碼內(nèi)的BUG

3、，糾正它，叫做DEBUG。 BUG產(chǎn)生的原因很多，具體有以下幾點。 1程序編寫錯誤 Bug的難以避免性。 2需求變更過于頻繁 需求變更所造成的結(jié)果就是變更程序代碼，程序 代碼只要稍做變更就必須經(jīng)過測試來確保運(yùn)行正常， 所以這個影響是一個連鎖反應(yīng)或稱為依存問題。 3軟件的復(fù)雜度 圖形用戶界面（GUI）、BS 結(jié)構(gòu)、面向?qū)ο笤O(shè)計、分布式運(yùn)算、底層通信協(xié)議、超大型關(guān)系型數(shù)據(jù)庫以及龐大的系統(tǒng)規(guī)模，都體現(xiàn)了軟件復(fù)雜度大大高于以前，Bug出現(xiàn)可能性就更高。 4交流不充分或者溝通出問題 大部分項目人員在同客戶進(jìn)行交流時常常存在著各種各樣的問題，究其原因，還是因為項目人員、參與人員和客戶之間沒有詳細(xì)、充分、謹(jǐn)

4、慎地進(jìn)行交流。 5測試人員的經(jīng)驗與技巧不足 6時間過于緊迫 7缺乏文檔：貧乏或者差勁的文檔使得代碼維護(hù)和修改變得非常困難，結(jié)果會導(dǎo)致其他開發(fā)人員或客戶有許多錯誤的理解。 8管理上的缺陷BUG的種類的種類 BUG是軟件“與生俱來”的特征，不同的軟件開發(fā)階段會產(chǎn)生不同的BUG，而不同的BUG又會產(chǎn)生不同的后果，因此BUG的屬性也并非相同。需求階段的需求階段的BUG 這個階段的BUG是最難發(fā)現(xiàn)、最難修復(fù)的，而且值得注意的是需求階段的BUG如果沒有及時發(fā)現(xiàn)等到實現(xiàn)階段發(fā)現(xiàn)時，那么修復(fù)它的費(fèi)用要比當(dāng)初修復(fù)它要高1575倍。 主要的原因如下： 1、模糊、不清晰的需求； 2、被忽略的需求； 3、相互沖突的需

5、求； 分析設(shè)計階段的分析設(shè)計階段的BUG 設(shè)計中的BUG比需求階段產(chǎn)生的BUG特征明顯 易于捕獲，但是其維修代價很高，原因是設(shè)計BUG 已經(jīng)作為一個整體影響著整個系統(tǒng)的實現(xiàn)。 原因主要有3種途徑。 1 、忽略設(shè)計； 2、混亂的設(shè)計； 3、模糊的設(shè)計； 實現(xiàn)階段的BUG 就是軟件系統(tǒng)中最普通、最一般的“常規(guī)BUG”。 可以將實現(xiàn)階段出現(xiàn)的BUG分為下面幾類： 1、消息錯誤 2、用戶界面錯誤 3、遺漏的功能 4、內(nèi)存溢出或者程序崩潰 5、其他實現(xiàn)錯誤 第一類型說明了軟件系統(tǒng)向用戶發(fā)送了出錯的 消息，可能消息是合理的或者表現(xiàn)為某種中斷機(jī)制，但是用戶認(rèn)為這是一個BUG。 如下圖：第二類型就是用戶界面錯

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

7、計人員為了節(jié)省一點硬件成本給全球造成了難以估量的損失。 作者曾經(jīng)為一家大藥房開發(fā)了一套藥品管理的進(jìn)銷存軟件，由于最初的時候?qū)I(yè)務(wù)流程并不是很熟悉，所以在定義藥品編碼的時候把許多藥品的ID號定義為了整型變量（INT），開始作者認(rèn)為這些足以定義所有的藥品名稱了，沒想到 一年以后，由于藥房的業(yè)務(wù)量急增，藥品的ID也就不夠了，由于整套系統(tǒng)是由Power Builder編寫，整型變量的最大值只有32767，因此程序經(jīng)常由于數(shù)據(jù)溢出而出現(xiàn)問題，所以作者被迫用了近一個星期的時間來修改原來的程序。靜態(tài)文檔的靜態(tài)文檔的BUG 文檔BUG的定義很簡單，即說明模糊、描述不完整和過期的都屬于文檔BUG。說明模糊特指無

8、充分的信息判斷如何正確地處理事情；描述不完整特指文檔信息不足以支持用戶完成某項工作；過期的文檔是沒有及時更新過的、錯誤的文檔。BUG報告單的內(nèi)容報告單的內(nèi)容 BUG報告單也叫缺陷報告單或者問題報告單。 問題報告單所需的基本信息類型是大同小異的，不同的只是組織和標(biāo)志。 介紹一下字段： （1）問題報告編號 （2）程序名 （3）版本標(biāo)識：發(fā)布號和版本號。是用來識別被測的代碼。 例如：某個版本號可能是1.01m，發(fā)布號是1.01，“m”指1.01版本的第13稿。 （4）報告類型：描述了發(fā)現(xiàn)的問題類型。包括：編碼錯誤 、設(shè)計問題 、建議 、文檔 、硬件、質(zhì)疑。 （5）嚴(yán)重性：為問題嚴(yán)重程度評分。 包含三

9、個等級：三個等級：輕微的、嚴(yán)重的和致命的。 （6）附件 存有測試數(shù)據(jù)的軟盤、鍵盤捕獲記錄或一組可產(chǎn)生測試用例的宏、程序的打印輸出、內(nèi)存dump或一份注釋，里面詳細(xì)描述了你所做的操作，以及你認(rèn)為該問題很重要的原因。 （7）問題概要：對問題進(jìn)行描述，有助于評審?fù)怀龅膯栴}，并找到相應(yīng)的問題報告。 （8）問題能否重現(xiàn)。要多次測試看能否再次出現(xiàn)。（9）問題描述及如何重現(xiàn)。描述所有的步驟和現(xiàn)象，包括錯誤信息。一定要提交報告。（10）建議的改正措施（11）報告人（12）日期：指的是報告人員發(fā)現(xiàn)問題的日期。（13）功能域：對問題進(jìn)行大體分類。（14）承辦人（15）注釋：程序員在這里簡短地說明為什么要推遲處理，

10、或說明是如何改正問題的。（16）狀態(tài)。三個狀態(tài)碼：開放、關(guān)閉和已解決。（17）優(yōu)先級。只由項目經(jīng)理設(shè)置。（18）處理狀態(tài)與處理版本 處理狀態(tài)定義了問題的當(dāng)前狀態(tài)： 未解決：初始化狀態(tài)或仍有沖突狀態(tài)。 已改正 不能重現(xiàn) 暫緩：對存在的問題在下個版本改正。 符合設(shè)計 由報告人撤回 需要進(jìn)一步信息 不同意建議 重復(fù):關(guān)閉重復(fù)上報的缺陷。 （19）簽名:簽署以表明已經(jīng)對改動進(jìn)行了測試，對結(jié)果表示滿意。（20）暫緩處理：對缺陷的推遲處理。 圖圖-3 -3 、圖、圖-4-4整合起來即為一張完整的報告單。整合起來即為一張完整的報告單。公司名稱 密級 問題報告編號:程序名 發(fā)布號 版本號報告類型(1-6) 嚴(yán)

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

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

13、的、易讀的和不做判斷的。 1) 書面的 一份書面的報告是必要的，供日后對修改后的程序進(jìn)行測試時使用；讓管理層、銷售人員和產(chǎn)品支持人員檢查。 2) 已編號的 依據(jù)惟一的編號跟蹤問題報告。 3) 簡單的 一份報告應(yīng)只描述一個問題，不要在一份報告中記錄多個缺陷。 4) 可重現(xiàn)的 一定要強(qiáng)調(diào)BUG的可重現(xiàn)性。 5) 不做判斷的 對程序員的評價要三思而后行，本著合作的精神，作出合理的判斷。 重現(xiàn)重現(xiàn)BUGBUG的分析和方法的分析和方法 本節(jié)重點是報告編碼錯誤報告編碼錯誤，而非報告設(shè)計問題。 一、重現(xiàn)BUG的分析 “可重現(xiàn)”隱含了下列定義：我們能夠描述如何讓程序進(jìn)入某個已知的狀態(tài)。任何熟悉程序的人都能夠依

14、照我們的描述使程序進(jìn)入該狀態(tài)。從那個狀態(tài)出發(fā)，我們確定出精確的一組步驟來暴露出問題。 為使報告更有效，我們應(yīng)該對問題進(jìn)一步分析， 目的在于： 1）找出問題最嚴(yán)重的后果。 找出某個BUG導(dǎo)致的最嚴(yán)重的后果，這樣可以激發(fā)人們改正它的興趣。一個看來很輕微的問題往往更有可能被暫緩處理。 例如：假設(shè)有個BUG在屏幕角落顯示了一個無用的字符，這個問題很輕微，但是是可以報告的。有些時候，屏幕上顯示出無用信息只是一個孤立的問題（因此對它置之不理的決定可能是明智的，尤其是程序快要交付的時候）。但是如果繼續(xù)運(yùn)行這個程序，可能會出現(xiàn)一旦顯示無用 信息之后，程序幾乎會馬上崩潰-最嚴(yán)重的后果。 2）找出最簡單、最直接和

15、最常見的BUG觸發(fā)條件。如果理解和改正問題僅需要很小的工作量，那么就會修復(fù)它。如果問題的解決需要（或看起來需要）很長的時間和精力，程序員會不太情愿改正它。如果問題會在程序日常使用的過程中發(fā)生，管理層對問題的關(guān)注會增加。如果問題的出現(xiàn)幾乎無人知曉，關(guān)注程度會很低。 3）找出產(chǎn)生相同問題的其他路徑。 有時不止一種方法可以觸發(fā)一個錯誤，若有兩條不同的路徑通往同一個BUG，比起僅有一條路徑來勢更有力的危險信號。即使每條路徑都包含著很復(fù)雜的步驟序列，存在兩條路徑也意味著代碼中含有嚴(yán)重的錯誤。 要充分展示各條路徑的差異，不能讓程序員把多條路徑視為對同一個BUG的相似描述。 4）找出相關(guān)的問題。 根據(jù)積累的

16、經(jīng)驗，仿照以前發(fā)現(xiàn)BUG的方法，查找程序中其他可能的位置，能有相當(dāng)?shù)臋C(jī)會在新的代碼中找出類似的問題。 二、可重現(xiàn)BUG的分析技術(shù) 1）尋找最關(guān)鍵的步驟 根據(jù)BUG查找代碼中的錯誤，不要忽略任何細(xì)微的有關(guān)錯誤的線索。 應(yīng)該查找下列的問題： 1. 錯誤信息； 2.處理延時； 3.屏幕閃爍； 4. 光標(biāo)跳躍； 5.文本錯誤； 6. 工作指示燈在設(shè)備未使用時亮起。 2）最大程度地提高程序運(yùn)行的可見性 將程序運(yùn)行的越多方面變的可見，就越能看到更多的出錯情況，也就越有可能明確關(guān)鍵的步驟。 用調(diào)試工具可以報告出當(dāng)前活動的進(jìn)程、程序占用的內(nèi)存或其他資源的數(shù)量、正在使用的堆棧的數(shù)量以及其他的內(nèi)部信息。 1.監(jiān)測

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

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

19、作的一個重要部分，測試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，因此，對BUG進(jìn)行跟蹤管理，確保每個被發(fā)現(xiàn)的缺陷都能及時得到處理。 BUG管理流程是一套復(fù)雜的處理過程，涉及到測試員（復(fù)審員）、項目數(shù)據(jù)庫管理員、實施員（設(shè)計員）三方的交互，圖-4所示的BUG管理流轉(zhuǎn)圖詳細(xì)描述了三方關(guān)聯(lián)關(guān)系（同樣適合正式技術(shù)復(fù)審問題處理流程）。 測試員（復(fù)審員）項目數(shù)據(jù)庫實施員（設(shè)計員）測試用例開始（用例規(guī)約）填寫測試結(jié)果（復(fù)審結(jié)果）的實際結(jié)果和備注輸入框根據(jù)反饋檢查修改后結(jié)果提交記錄至項目數(shù)據(jù)庫 AutoMail Send自 動 返 回 郵 件通 知 測 試 人 員（復(fù)審人員） 如果測試結(jié)果（復(fù)審結(jié)果）為已解決,項

20、目數(shù)據(jù)庫會自動通知相關(guān)人員，告知問題已經(jīng)關(guān)閉將反饋提交至項目數(shù)據(jù)庫針對測試結(jié)果（復(fù)審結(jié)果）填寫相應(yīng)修改意見已經(jīng)解決Message未解決回UpDataFindViewMessageSubmitFind數(shù)據(jù)庫圖-4 BUG管理流轉(zhuǎn)圖 BUG跟蹤管理的起始動作是測試員（復(fù)審員）選擇一個測試用例開始測試，當(dāng)測試員（復(fù)審員）發(fā)現(xiàn)程序?qū)嶋H輸出值和程序期望值不符的時候，他就發(fā)現(xiàn)了一個BUG，并執(zhí)行流程第二個動作“填寫測試的實際結(jié)果”。 當(dāng)測試員（復(fù)審員）向BUG跟蹤管理系統(tǒng)遞交該BUG時，系統(tǒng)將該BUG保存至“項目數(shù)據(jù)庫”中，并且同步發(fā)送一個消息至“AutoMail Send”（可以是一個程序），由它向該B

21、UG的最終負(fù)責(zé)者實施員（設(shè)計員）發(fā)送一份“Error Report”。 實施員（設(shè)計員）會及時接受到這樣的BUG報告，并且根據(jù)報告中包含的BUG唯一序號向“項目數(shù)據(jù)庫”查詢該BUG的詳細(xì)信息。 當(dāng)實施員（設(shè)計員）對BUG跟蹤的修復(fù)動作完成后，就會在“項目數(shù)據(jù)庫”中將該BUG的狀態(tài)轉(zhuǎn)換為“Fixed”，BUG跟蹤管理系統(tǒng)接收到這樣的“UpData”動作，就會自動向BUG的測試員（復(fù)審員）發(fā)送BUG已經(jīng)修復(fù)的消息，測試員（復(fù)審員）對BUG進(jìn)行確認(rèn)測試，如果該BUG正確修復(fù)則關(guān)閉它，如果該BUG依然存在問題，整個動作回復(fù)到BUG跟蹤管理的起始處。 1、如何提交系統(tǒng)中的BUG 不要在同一封郵件或者同一

22、個錯誤輸入框中報告多個（尤其在不同軟件包之中的）錯誤。 2、使用自動BUG報告工具 使用成熟的BUG管理工具實現(xiàn)BUG全程管理，可以有效避免被大量的測試數(shù)據(jù)所淹沒而引發(fā)一系列問題。 有如下一些優(yōu)點： BUG管理工具安裝簡單、運(yùn)行方便、管理安全。 BUG管理工具有利于BUG的清楚傳遞，由于 使用了后臺數(shù)據(jù)庫進(jìn)行管理，提供全面詳盡的報告輸入項，可產(chǎn)生標(biāo)準(zhǔn)化的BUG報告。 BUG管理工具提供大量的分析選項和強(qiáng)大的查詢匹配能力，能根據(jù)各種條件組合進(jìn)行BUG統(tǒng)計。當(dāng)BUG在它的生命周期中變化時，開發(fā)人員、測試人員、及項目管理人員將及時獲得動態(tài)的變化信息。 BUG管理人員允許你獲取BUG歷史記錄，并在檢查

23、BUG的狀態(tài)時參考這一記錄。 BUG管理工具可針對軟件產(chǎn)品設(shè)定不同的模塊，并針對不同的模塊設(shè)定相關(guān)的責(zé)任人員，這樣可以實現(xiàn)提交報告時自動發(fā)給指定的責(zé)任人。 BUG管理工具支持權(quán)限，設(shè)定不同的用戶對BUG記錄的操作權(quán)限不同，可有效控制進(jìn)程管理。 BUG管理工具設(shè)定不同的BUG嚴(yán)重程度和優(yōu)先級，從最初的報告到最后的解決，確保了錯誤不會被忽略，同時可以使注意力集中在優(yōu)先級和嚴(yán)重程度高的錯誤上。 BUG管理工具自動發(fā)送郵件通知相關(guān)責(zé)任人員，并且根據(jù)設(shè)定的不同責(zé)任人，自動發(fā)送最新的BUG動態(tài)信息，有效地幫助測試人員和開發(fā)人員進(jìn)行溝通。 3、通過電子郵件發(fā)送BUG報告 描述主題是要清楚而簡潔地描述BUG。

24、 郵件內(nèi)容第一行的格式為：Package:, 指要報告的包含錯誤的Class包名稱。 郵件內(nèi)容的第二行格式為：Version:， 指該軟件包的版本。 其他內(nèi)容應(yīng)該注意以下幾點： 確切而完整的錯誤信息（這非常重要）。 您做了或輸入了些什么，以便重現(xiàn)該問題。 錯誤行為的描述：您預(yù)期應(yīng)該有什么樣的行為，而您看到的是如何。 您建議如何改正，或甚至您自己做的修補(bǔ)程序。 詳細(xì)解釋您如何設(shè)置該程序，包含完整的設(shè)置文件屬性。 任何其他依賴于這個問題軟件包的軟件包版本。 4、 BUG詳細(xì)內(nèi)容信息 如表-1所示。 5、 輕微的BUG報告 輕微的BUG報告應(yīng)該和重要的BUG報告分開發(fā)送。BUG描述信息BUG類別可追

25、蹤BUG標(biāo)志BUG基本描述BUG所屬項目 子系統(tǒng)模塊所屬的項目子系統(tǒng)模塊，最好能較精確的定位至模塊BUG標(biāo)題BUG簡明描述BUG流轉(zhuǎn)狀態(tài)BUG流轉(zhuǎn)狀態(tài)，可分為Unconfirmed、New、Assigned、Reassigned、Needinfo、Reopened、Resolved、Reopen、Verified、ClosedBUG嚴(yán)重等級BUG嚴(yán)重等級,可分為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提交時間BUG提交的時間，例如2003-1-23 14：00表-1 Bug詳細(xì)內(nèi)容描述(part 1)BUG過程描述BUG指定解決人由測試人員確定，如果該BUG的流轉(zhuǎn)狀態(tài)從Unconfirmed&New變?yōu)锳ssignedBUG指定解決時間由測試人員確定，如果該BUG超過指定修復(fù)時間而未修復(fù)，則系統(tǒng)自動發(fā)送報警郵件。BUG處理描述如果實現(xiàn)人員對代碼進(jìn)行了修改，要求在此處體現(xiàn)出修改內(nèi)容，如果代碼行數(shù)很多則縮略書寫B(tài)UG處理時間記錄BUG處理時間BUG確認(rèn)測試人員驗證

27、該BUG被正確的修復(fù)了BUG確認(rèn)描述BUG確認(rèn)修復(fù)內(nèi)容BUG確認(rèn)時間BUG確認(rèn)修復(fù)時間BUG詳細(xì)描述對BUG的詳細(xì)描述，對BUG描述的詳細(xì)程度直接影響實現(xiàn)人員對該BUG的修復(fù)效果，描述應(yīng)該盡可能詳細(xì)BUG環(huán)境說明對測試環(huán)境的描述，避免實現(xiàn)人員和測試人員環(huán)境的不同造成BUG異議BUG附帶附件附件包括對BUG現(xiàn)場出錯快照(圖片)，錯誤輸出文件信息等，加強(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報告 提出的BUG被修正后，通過測試人員確認(rèn)、測 試通過才可以關(guān)閉。 BUG的提出和關(guān)閉都是只能由測試人員執(zhí)行。 將所有不能被修復(fù)的BUG收集起來標(biāo)記為“Wontfix”，統(tǒng)一遞交給代碼評審委員會。 8、接續(xù)的討論信息 BUG的管理系統(tǒng)的流轉(zhuǎn)過程中，會有針對該BUG的新的描述信息加入，例如實現(xiàn)人員或者測試人員加上的對處理BUG自己的理解和曾經(jīng)使用過的解決方案等。 對于新的描述信息，請遵循以下規(guī)則： 新的描述信息和舊的描述信息之間應(yīng)該增加醒目的隔離條。 新的信息描述應(yīng)該包括提供者的名稱和電子郵件地址。 新的描述信息應(yīng)該包括信息的新增時間。 新的描述信息如果是建議修改意見，應(yīng)該在該信息的開頭加上關(guān)鍵字“建議解決方案”。 新的描述