BUG生命周期和管理

1、BUG生命周期和管理發(fā)布時間: 2012-2-15 10:58 作者: igoone 來源: 51Testing軟件測試網(wǎng)采編字體: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 推舉標(biāo)簽： Bug 軟件測試管理 缺陷管理 1、BUG的影響精神的摧殘 誰會情愿得到垃圾團(tuán)隊的稱號？ BUG有著無窮的生命力，你會很悲觀，認(rèn)為自己已經(jīng)無能為力了，這種心情會在長時間的工作后加重。 大家都厭倦重復(fù)處理相同的問題，測試人員也已經(jīng)煩透了長長的BUG列表，精神壓力與日俱增。 低生產(chǎn)率和低等產(chǎn)品質(zhì)量，耗費(fèi)了大量的資源。有時管理層并沒有意識到發(fā)生了什么問題，為了保證項目的最終交付，他們?yōu)轫椖枯斔土嗽?/p>

2、源不斷的新人，由于培訓(xùn)無法跟進(jìn)，最終導(dǎo)致了整個產(chǎn)品開發(fā)的崩潰。形象的損失 假如某些公司的某些產(chǎn)品毀滅了重大BUG，勢必會牽連降低公司的形象，至少我們有理由信任該公司的產(chǎn)品質(zhì)量不穩(wěn)定。 電子商務(wù)更能體現(xiàn)形象，假如網(wǎng)站很長時間才能響應(yīng)客戶服務(wù)，或者毀滅了丟失訂單、混亂訂單的現(xiàn)象，這樣的網(wǎng)站會很快被客戶拋棄，客戶一旦離開就很難回頭。 形象的損失帶來的后果是巨大的，產(chǎn)品不被市場所認(rèn)可，甚至公司也不再被市場所認(rèn)可。財寶的流失 產(chǎn)品的開發(fā)需要資金，公司的運(yùn)轉(zhuǎn)需要資金，壞的市場形象需要公司花費(fèi)更多的資金來挽回聲譽(yù)。 有BUG的軟件產(chǎn)品后期維護(hù)也是一個大問題2、BUG的產(chǎn)生溝通的誤會 羞怯。跟客戶溝通的時候總

3、是用很小的聲音說明自己的觀點，表現(xiàn)力度不夠；或者靜靜地坐在會議室的角落，沒有任何思想地觀看別人的激烈爭辯。 可怕。項目參與人員缺乏對客戶的了解，造成盲目跟從心理。溝通的時候只是去聽，從不敢反對或者提出相反的看法。 依靠。部分項目參與人員認(rèn)為溝通的時候，只要有一個人做會議筆記就可以了，總是找一種感情上的依托。 輕視。擁有專業(yè)學(xué)問的項目人員不重視客戶所說的，或者認(rèn)為客戶所說的簡直就是天方夜譚，毫無科學(xué)依據(jù)。 健忘。自信能記住會議上全部爭辯內(nèi)容而不作筆記，結(jié)果在實際的設(shè)計或者開發(fā)過程中遺忘了部分要點和留意事項。 誤會。這是人類相互之間普遍存在的一種現(xiàn)象。大家的認(rèn)知層面、各自擁有的學(xué)問、處事原則各不相

4、同，難免會產(chǎn)生這種狀況，可以通過相互培訓(xùn)及有效的溝通來避開這種狀況的發(fā)生。軟件的簡潔性程序員的錯誤 過于疲乏。讓程序員持續(xù)地開發(fā)，疲于奔命地完成某項任務(wù)，這時候的他認(rèn)為休息比編碼質(zhì)量有更重要的意義。 不守法規(guī)。程序員依據(jù)自己心中的藍(lán)圖去描繪一個秀麗的烏托邦，或者隨心所欲地用法自我編碼格式，完全不遵守項目的開發(fā)準(zhǔn)則。 過于熱心。程序員經(jīng)常犯這樣的錯誤，沒有經(jīng)過嚴(yán)格的驗證和全局的考慮，任意修改設(shè)計并且認(rèn)為這會產(chǎn)生更好的效果。 心不在焉。需求轉(zhuǎn)變 客戶并不了解需求轉(zhuǎn)變所帶來的后果，就算知道了他們還是會堅持這么做。并且在客戶的眼里，他們只需要看到轉(zhuǎn)變，卻從不考慮轉(zhuǎn)變所需的額外工作時間。 需求轉(zhuǎn)變的后果

5、可能會造成重新設(shè)計或者日程調(diào)整，已完成工作、重做或者被完全拋棄，整個項目環(huán)境可能要因此轉(zhuǎn)變等。 頻繁小的轉(zhuǎn)變或者幾次重大的轉(zhuǎn)變，項目各部分之間已知或者未知的依靠關(guān)系就會相互影響，從而導(dǎo)致更多問題的毀滅。 需求轉(zhuǎn)變增加了項目操作的簡潔性，產(chǎn)生了大量不確定因素，并且還可能打擊參與人員的工作主動性。一個需求轉(zhuǎn)變頻繁的項目或者產(chǎn)品是沒有任何測試價值的。時間壓力 時間是一種貴重的資源。 全部軟件項目時間都需要被精確估算。可是夾雜著估量、猜想這些不穩(wěn)定的因素，當(dāng)最終期限迫近和關(guān)鍵時刻到來之際，錯誤也就跟著毀滅了。文檔貧乏 貧乏或者差勁的文檔使得代碼維護(hù)和修轉(zhuǎn)變得異樣艱辛，其結(jié)果是帶來很多錯誤。 區(qū)分職業(yè)實

6、現(xiàn)人員的方法并不是看他有幾年的編碼閱歷，而在于其是否有良好的先文檔后實現(xiàn)的習(xí)慣。 文檔代表著一種特殊的記憶，沒有它的存在對人對己都不利。軟件開發(fā)工具 總是期望通過更加先進(jìn)的工具來避開BUG的毀滅，這就患上了典型的銀彈綜合癥。 開發(fā)工具可能使我們擺脫某些問題的毀滅，并且提高工作效率。實際上，現(xiàn)代的開發(fā)工具對整個軟件質(zhì)量尤其是牢靠性并沒有什么重大的影響。3、Bug如何穿透測試代價太大 正規(guī)的軟件公司會引入QA，對項目整個過程進(jìn)行全方位的質(zhì)量保證工作。但是執(zhí)行QA需要調(diào)用很多的資源，比如要檢查和復(fù)審需求階段輸出的標(biāo)準(zhǔn)工件，就需要高水平的分析員加入，但是通常他們時間很少很貴重，并且不會有太多的精力顧及

7、此事。 在設(shè)計和實現(xiàn)階段，隨著大量審查工作的介入，全部該階段的參與人員都要付出更多的時間和精力來參與。 這些形式的檢查、審查和測試延長了整個項目的開發(fā)過程，這些附加的工作時間都會挺直變成附加費(fèi)用，大大增加了整個項目的造價。市場決策 即使測試人員發(fā)覺了產(chǎn)品中的BUG，但是公司會覺得修復(fù)BUG將延長整個產(chǎn)品的發(fā)布時間，有可能錯過銷售的旺季（可能是每年的5-10月份），并且會打亂整個公司針對該產(chǎn)品的銷售方案，在確認(rèn)產(chǎn)品中的BUG不是格外嚴(yán)峻的狀況下，軟件被銷售了。但是，假如這是航天、醫(yī)療、股票交易的管控軟件系統(tǒng)，如帶有BUG，則發(fā)布后果是格外嚴(yán)峻的，但是對于某些行業(yè)這樣的做法是可行的。時間緊迫 測試

8、要花費(fèi)大量的時間，至今尚未有一種自動化的測試工具能夠全面和高效率地測試一套軟件產(chǎn)品。 測試項目經(jīng)理接到測試任務(wù)后表現(xiàn)得過于樂觀，沒有考慮任務(wù)的風(fēng)險。 開發(fā)人員過高估量自己的力氣，認(rèn)為全部的BUG都是微不足道、便于修復(fù)的。他讓測試工作和編碼工作同時進(jìn)行，這樣根本沒方法保證測試的正確性。并且在時間緊迫的時候，大多數(shù)測試員只是選擇明顯的幾條程序路徑測試或者輸入不完整的測試數(shù)據(jù)，這些都造成了大量的BUG紕漏?，F(xiàn)場證據(jù) 有時會遇到這種問題，發(fā)覺了BUG但是不知道怎么把它明顯地表示出來。不能向開發(fā)人員供應(yīng)足夠的證據(jù)報告，是測試人員的恥辱，開發(fā)人員同樣會依據(jù)這樣的報告譏笑測試人員的所作所為。 BUG的可重現(xiàn)

9、性，與導(dǎo)致BUG毀滅的緣由有著親熱的聯(lián)系。 BUG的可重現(xiàn)性也體現(xiàn)了測試人員對軟件系統(tǒng)的生疏程度。 BUG的可重現(xiàn)性，也體現(xiàn)在操作的挨次上。過于自信 開發(fā)人員是格外不懇切的測試人員，他們總是說“我做的確定沒問題”或者“不行能呀，它在我的機(jī)器上跑得好好的”。有的時候項目管理者也很自負(fù)，過于信任團(tuán)隊成員的表現(xiàn)，而不去理睬測試人員或者客戶的埋怨。 Titanic災(zāi)難就充分體現(xiàn)了人類的自信，我們有足夠的水密艙就算破了5個船也不會沉。 沒有具體的測試方案，沒有嚴(yán)謹(jǐn)?shù)臏y試行為，不再關(guān)注每個細(xì)小的環(huán)節(jié)，這樣BUG就從旁邊靜靜溜走了。模糊提交測試環(huán)境 缺少必要的測試工具和設(shè)備。在一個比較大型的網(wǎng)站中，系統(tǒng)在正

10、常負(fù)載狀況下的性能格外重要，假如測試人員沒有一種有效的測試工具或者必要的硬件設(shè)備，那么就很難去模擬、再現(xiàn)系統(tǒng)負(fù)載的環(huán)境。 缺少必要的系統(tǒng)配置。假如是Java開發(fā)的程序，我們可能會在多種操作系統(tǒng)上去驗證它的正確性和穩(wěn)定性。 缺少必要的測試用例。好的測試模型可以削減更多的BUG，也可以發(fā)覺更多潛在的BUG。好的測試用例不僅僅是一系列測試方法的組合，它更大的用處在于和歷史積累BUG記錄的對比分析。4、Bug的種類需求階段的BUG來源： 模糊不清的需求 忽視的需求 沖突的需求分析、設(shè)計階段的BUG來源： 忽視設(shè)計 混亂的設(shè)計 ：這樣的狀況發(fā)生在兩種設(shè)計性質(zhì)完全相反的狀況中，假如在實際的系統(tǒng)中，某塊地址

11、規(guī)定不允許被多線程訪問，而方案卻被設(shè)計成以多線程方式進(jìn)行，則會在此層面上產(chǎn)生BUG，嚴(yán)峻的會造成整個系統(tǒng)的崩潰。 模糊的設(shè)計：模糊BUG產(chǎn)生的緣由在于設(shè)計人員對需求沒有清楚的生疏，或者需求本身就是模糊不清的。實現(xiàn)階段的BUG來源： 遺漏的功能 內(nèi)存溢出：屬于一種比較嚴(yán)峻的軟件BUG類型。例如，軟件執(zhí)行了某些強(qiáng)行向操作系統(tǒng)疼惜地址寫入數(shù)據(jù)的指令，導(dǎo)致整個環(huán)境的徹底崩潰；再如：數(shù)值除零導(dǎo)致堆棧溢出 其他實現(xiàn)：表現(xiàn)為毀滅的錯誤難以定位其類型，比如在產(chǎn)品化階段，測試人員或者最終用戶提出的部分提高程序運(yùn)行效率的建議，當(dāng)然開發(fā)人員并不完全處理這些問題，但是這些建議將成為一種特殊的BUG類型，被保留在項目數(shù)

12、據(jù)庫中。配置階段的BUG 配置階段的BUG是最危急的，往往體現(xiàn)在軟件交付或者最終的系統(tǒng)測試中。 配置階段的BUG毀滅的緣由是簡潔的，比較典型的是舊的代碼掩蓋了新的代碼；或者測試服務(wù)器上的代碼和實現(xiàn)人員本機(jī)最新代碼版本不全都。這些狀況造成了錯誤代碼被修改后，經(jīng)過一個時間段再次回來測試時又會毀滅同樣的問題。 配置階段的BUG解決方案也很簡潔，項目組可以指定專人（集成員）進(jìn)行配置和集成管理，集成員保證正確集成整個系統(tǒng)，并將最新的代碼發(fā)布到測試服務(wù)器或者客戶服務(wù)器上。這個階段由QA（質(zhì)量保證）部門負(fù)責(zé)監(jiān)管和把握，規(guī)定集成的時間間隔和最佳集成時間，統(tǒng)一維護(hù)一份項目組集成人員和集成時間列表。短視將來的BU

13、G 很多軟件BUG都是設(shè)計人員或者實現(xiàn)人員的眼光短淺造成的，出名的例子就是“千年蟲”問題。 其他短視的BUG例子還有我們以前的身份證號碼，原來的15位的編號根本不符合一人一號的設(shè)計要求，重碼的現(xiàn)象相當(dāng)嚴(yán)峻。所以毀滅了18位號碼。 再如：中國移動開發(fā)了134號段的號碼?，F(xiàn)在又有了159號段。靜態(tài)文檔的BUG 文檔BUG的定義很簡潔，即說明模糊、描述不完整和過期的都屬于文檔BUG。 說明模糊特指無充分的信息推斷如何正確地處理事情。例如設(shè)計文檔中說明白對類實例方法的調(diào)用，卻沒說明邊界條件和特殊的調(diào)用挨次。 描述不完整特指文檔信息不足以支持用戶完成某項工作。例如某套軟件的某一項操作有具體的前置條件，而

14、客戶從文檔上并沒有獵取關(guān)于該前置操作的相關(guān)信息，客戶便認(rèn)為軟件存在著BUG。 過期文檔本身就是錯的并且無法彌補(bǔ)，這種現(xiàn)象經(jīng)常發(fā)生在后期對系統(tǒng)功能修改而沒有準(zhǔn)時更新對應(yīng)的文檔，造成了文檔的不全都性。5、BUG的生命周期 BUG初始狀態(tài)（Unconfirmed&New態(tài)） BUG支配狀態(tài)（Assigned態(tài)） BUG重新支配狀態(tài)（Reassigned態(tài)） BUG修復(fù)狀態(tài)（Resolved&Fixed態(tài)） BUG驗證狀態(tài)（Vertified&Fixed態(tài)） BUG重新打開狀態(tài)（Reopen態(tài)） BUG關(guān)閉狀態(tài)（Closed&Fixed態(tài)）6、BUG生命歷程的5種典型過程（1）BUGStart- BU

15、G初始狀態(tài) -BUG支配狀態(tài)-BUG重新支配狀態(tài) - BUG修復(fù)狀態(tài) -BUG驗證狀態(tài) - BUG關(guān)閉狀態(tài)測試人員發(fā)覺BUG并且將該BUG標(biāo)記為Unconfirmed&New狀態(tài)，下一步測試人員在排解BUG的登記錯誤后，將該BUG置為Assigned狀態(tài)。實現(xiàn)人員接到該BUG通告進(jìn)行BUG確認(rèn)，確認(rèn)成功后該BUG狀態(tài)被置為Reassigned狀態(tài)，當(dāng)實現(xiàn)人員修復(fù)BUG后該BUG置為Resolved&Fixed狀態(tài)。測試人員對實現(xiàn)人員修復(fù)后的BUG進(jìn)行確認(rèn)測試，假如該BUG被正確修復(fù)了，那么其狀態(tài)被置為Closed&Fixed狀態(tài)，同時意味著該BUG的整個生命周期終結(jié)了（2）BUGStart-

16、BUG修復(fù)狀態(tài) - BUG驗證狀態(tài) -BUG關(guān)閉狀態(tài)回來測試后，假如部分登記BUG再次毀滅，測試人員可挺直將已登記的Closed&Fixed狀態(tài)的BUG轉(zhuǎn)入修復(fù)流程，等實現(xiàn)人員修復(fù)BUG后將該BUG置為Resolved&Fixed狀態(tài)。測試人員對實現(xiàn)人員修復(fù)后的BUG進(jìn)行確認(rèn)測試，假如該BUG被正確修復(fù)了，那么其狀態(tài)被置為Closed&Fixed狀態(tài)，同時意味著該BUG的整個生命周期終結(jié)了（3）BUGStart- BUG初始狀態(tài) - BUG支配狀態(tài)-BUG重新支配狀態(tài)測試人員發(fā)覺BUG并且將該BUG標(biāo)記為Unconfirmed&New狀態(tài)，下一步測試人員在排解BUG的登記錯誤后，將該BUG置為

17、Assigned狀態(tài)。實現(xiàn)人員接到該BUG通告進(jìn)行BUG確認(rèn)，確認(rèn)失敗后該BUG狀態(tài)被置為Reassigned狀態(tài)并發(fā)送回BUG起始階段（4）BUGStart- BUG初始狀態(tài) - BUG支配狀態(tài)-BUG重新支配狀態(tài) - BUG修復(fù)狀態(tài) -BUG重新打開狀態(tài)測試人員發(fā)覺BUG并且將該BUG標(biāo)記為Unconfirmed&New狀態(tài)，下一步測試人員在排解BUG的登記錯誤后，將該BUG置為Assigned狀態(tài)。實現(xiàn)人員接到該BUG通告進(jìn)行BUG確認(rèn)，確認(rèn)成功后該BUG狀態(tài)被置為Reassigned狀態(tài)，當(dāng)實現(xiàn)人員修復(fù)BUG后該BUG置為Resolved&Fixed狀態(tài)，但是實現(xiàn)人員發(fā)覺該BUG與其他

18、實現(xiàn)人員的BUG有關(guān)聯(lián)關(guān)系，可能導(dǎo)致本次修復(fù)無效，所以實現(xiàn)人員將該BUG置為Reopen狀態(tài)發(fā)送回BUG起始階段（5）BUGStart- BUG初始狀態(tài) - BUG支配狀態(tài)-BUG重新支配狀態(tài) - BUG修復(fù)狀態(tài) -BUG驗證狀態(tài) - BUG重新打開狀態(tài)人員接到該BUG通告進(jìn)行BUG確認(rèn)，確認(rèn)成功后該BUG狀態(tài)被置為Reassigned狀態(tài)，當(dāng)實現(xiàn)人員修復(fù)BUG后該BUG置為Resolved&Fixed狀態(tài)。測試人員對實現(xiàn)人員修復(fù)后的BUG進(jìn)行確認(rèn)測試，驗證成功后測試人員懷疑該BUG并非真正修復(fù)，將該BUG置為Reopen狀態(tài)發(fā)送回BUG起始階段7、BUG的流轉(zhuǎn)狀態(tài)關(guān)鍵字 未確定的（Uncon

19、firmed）。這個BUG最近才被發(fā)覺，還沒有人確認(rèn)它是否真的存在，假如有別的測試人員遇到了同樣的問題，就可以將這個Bug標(biāo)記為New，或者將這個Bug刪除，或者做上closed標(biāo)記。 新加入的（New）。這個BUG最近被測試人員添加到Bug列表中，已經(jīng)被證明存在且必需修改的。即將被支配，假如支配了可以標(biāo)記為Assigned，未支配則將保留New標(biāo)記，或者做上Resolved標(biāo)記。 確認(rèn)支配的（Assigned）。測試人員將BUG的修復(fù)任務(wù)支配給具體的實現(xiàn)人員，假如BUG不屬于被支配實現(xiàn)人員的范圍，可置為Reassigned，等待被重新指定相關(guān)修改人員。 重新支配的（Reassigned）。該

20、BUG不屬于被支配實現(xiàn)人員的范圍，可置為 Reassigned等待被重新指定相關(guān)修改人員。 需要憂慮的（Needinfo）。測試人員或?qū)崿F(xiàn)人員無法對發(fā)覺的BUG進(jìn)行精確定位或描述，需要相關(guān)實現(xiàn)人員幫忙，以更深刻地生疏和修復(fù)這個Bug。 重復(fù)毀滅的（Reopened）。該BUG已經(jīng)不是第一次被發(fā)覺，它可以被標(biāo)記為Assigned或者Resolved。 已解決的（Resolved）。實現(xiàn)人員對被支配給自己的BUG進(jìn)行修改，修改完以后，修改狀態(tài)。 重新啟用的（Reopen）。當(dāng)實現(xiàn)人員發(fā)覺某些BUG具有關(guān)聯(lián)性，即使該BUG被正確修復(fù)了，也會被發(fā)送到起始狀態(tài)等待回來再次確認(rèn)。或測試人員發(fā)覺該BUG沒有

21、被真正修改后，重置狀態(tài)。 正在驗證的（Verified）。測試人員對標(biāo)記為Resolved狀態(tài)的BUG進(jìn)行驗證。 平安關(guān)閉的（Closed）。該BUG已經(jīng)被完全解決。8、BUG的解決關(guān)鍵字 已經(jīng)修復(fù)（Fixed），該BUG被正確修復(fù)了，并且得到了測試人員的確認(rèn)。 無法修復(fù)（Wontfix），發(fā)覺的BUG永久不會被修復(fù)，或者該BUG牽涉面太廣需要委員會打算。 下版本解決（Later），發(fā)覺的BUG不會在產(chǎn)品的這個版本中解決，將在下一個版本中被修復(fù)。 無法確定（Remind），發(fā)覺的BUG可能不會在產(chǎn)品的這個版本中解決，也可能會。 重復(fù)的（Duplicate），發(fā)覺的BUG是一個已存在BUG的復(fù)件。 無法證明（Incomplete），用了全部的方法都不能再現(xiàn)這個BUG，沒有更多的線索來證明這BUG的存在，即使看程序源代碼也無法確認(rèn)這個Bug的毀滅。 測試錯誤（NotaBUG），BUG報告毀滅了錯誤，將正確的軟件過程報告成BUG了。 無效的（Invalid），描述