BUG生命周期和管理

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

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

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

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

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

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

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

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

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

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

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

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

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

14、客戶從文檔上并沒(méi)有獵取關(guān)于該前置操作的相關(guān)信息，客戶便認(rèn)為軟件存在著B(niǎo)UG。 過(guò)期文檔本身就是錯(cuò)的并且無(wú)法彌補(bǔ)，這種現(xiàn)象經(jīng)常發(fā)生在后期對(duì)系統(tǒng)功能修改而沒(méi)有準(zhǔn)時(shí)更新對(duì)應(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驗(yàn)證狀態(tài)（Vertified&Fixed態(tài)） BUG重新打開(kāi)狀態(tài)（Reopen態(tài)） BUG關(guān)閉狀態(tài)（Closed&Fixed態(tài)）6、BUG生命歷程的5種典型過(guò)程（1）BUGStart- BU

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

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

17、Assigned狀態(tài)。實(shí)現(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重新打開(kāi)狀態(tài)測(cè)試人員發(fā)覺(jué)BUG并且將該BUG標(biāo)記為Unconfirmed&New狀態(tài)，下一步測(cè)試人員在排解BUG的登記錯(cuò)誤后，將該BUG置為Assigned狀態(tài)。實(shí)現(xiàn)人員接到該BUG通告進(jìn)行BUG確認(rèn)，確認(rèn)成功后該BUG狀態(tài)被置為Reassigned狀態(tài)，當(dāng)實(shí)現(xiàn)人員修復(fù)BUG后該BUG置為Resolved&Fixed狀態(tài)，但是實(shí)現(xiàn)人員發(fā)覺(jué)該BUG與其他

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

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

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

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