第8章-軟件BUG和管理

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

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

8.1.1BUG的影響

Bug會給用戶或使用者帶來相當大的麻煩，會給集體或者國家?guī)砗艽蟮慕?jīng)濟損失。如：千年蟲問題。8.1.2BUG的產(chǎn)生BUG的由來。對于軟件而言，BUG是程序編寫錯誤而導(dǎo)致軟件產(chǎn)生問題的缺陷。

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

Bug的難以避免性。

2．需求變更過于頻繁

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

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

4．交流不充分或者溝通出問題大部分項目人員在同客戶進行交流時常常存在著各種各樣的問題，究其原因，還是因為項目人員、參與人員和客戶之間沒有詳細、充分、謹慎地進行交流。

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

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

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

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

1、忽略設(shè)計；

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

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

8.2.3實現(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)為某種中斷機制，但是用戶認為這是一個BUG。如下圖：第二類型就是用戶界面錯誤，可歸納為GUI錯誤。可能是由于GUI制作不標準而導(dǎo)致用戶不能正確地工作。第三種類型為遺漏的功能BUG(以輸入框輸入信息錯誤，程序拋出未異常為典型)第四種類型為內(nèi)存溢出或者程序崩潰BUG，表現(xiàn)為程序掛起、系統(tǒng)崩潰，屬于一種比較嚴重的軟件BUG類型。（詳見教材的藥房藥品進存銷的軟件測試BUG）

8.2.4配置階段的BUG

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

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

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

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

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

圖8-3、8-4整合起來即為一張完整的報告單。圖8-3報告單(part1)圖8-4報告單(part2)8.3.2BUG報告的特點

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

1)書面的

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

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

4)可重現(xiàn)的

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

5)不做判斷的

對程序員的評價要三思而后行，本著合作的精神，作出合理的判斷。

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

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

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

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

1.錯誤信息；

2.處理延時；

3.屏幕閃爍；

4.光標跳躍；

5.文本錯誤；

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

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

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

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

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

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

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

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

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