摘要
本文首先介紹了Bug管理的常規(guī)過(guò)程，接著分析了應(yīng)用于開源軟件開發(fā)過(guò)程的Bug跟蹤與管理系統(tǒng)的特點(diǎn)，描述了一個(gè)典型的Bug生命周期過(guò)程，并對(duì)完成一個(gè)合格的Bug報(bào)告做出了解釋。文章還簡(jiǎn)單介紹了比較流行的缺陷跟蹤與管理系統(tǒng)bugglgj/bugzilla/' target='_blank'>Bugzilla等，并給出了個(gè)人的想法。
關(guān)鍵詞：Bug管理，生命周期，缺陷跟蹤與管理系統(tǒng)
Abstract-This paper introduces a normal bug management process， analyzes characteristics of bug tracking and management in development of open source software， describes a classic bug life cycle， and explains how to accomplish an eligible bug report. Also， some popular bug tracking and management systems such as Bugzilla are introduced， following with some personal thoughts.
Key Words: Bug management， life cycle， bug tracking and management system
1問題介紹
在軟件開發(fā)與維護(hù)過(guò)程中，有效地進(jìn)行質(zhì)量控制與保證工作尤為重要。正因如此，軟件缺陷跟蹤與管理在現(xiàn)代軟件過(guò)程中成為實(shí)施質(zhì)量控制與保證的重要方面。軟件中的缺陷(Defect或Bug)是軟件開發(fā)過(guò)程中的"副產(chǎn)品"。通常，缺陷會(huì)導(dǎo)致軟件產(chǎn)品在某種程度上不能滿足用戶的需要[[1]]。開源軟件組織宣稱，開源的目的是獲得更好的質(zhì)量、更高的可靠性、更強(qiáng)的靈活性、低成本和對(duì)掠奪式賣主禁閉行為的終結(jié)[[2]]。如其所言，開源軟件自由和開放的精神迎來(lái)了一些擁護(hù)者。雖然如此，軟件缺陷始終存在，如何實(shí)施對(duì)開源軟件Bug的跟蹤與管理呢?它與商業(yè)軟件缺陷管理又有什么區(qū)別呢?開源的人們又在使用哪些他們的Bug跟蹤系統(tǒng)呢?帶著疑問與不解，我開始了對(duì)開源軟件Bug跟蹤與管理的探討。
2 Bug跟蹤與開源軟件Bug管理
2.1缺陷管理一般過(guò)程
軟件不是完美無(wú)缺的，正常情況下，出現(xiàn)惹人厭煩的Bug不可能成為軟件工程師們的期待。缺陷跟蹤管理是測(cè)試工作的一個(gè)重要部分，測(cè)試的目的是為了盡早發(fā)現(xiàn)軟件系統(tǒng)中的缺陷，因此，對(duì)缺陷進(jìn)行跟蹤管理，確保每個(gè)被發(fā)現(xiàn)的缺陷都能夠及時(shí)得到處理是測(cè)試工作的一項(xiàng)重要內(nèi)容[[3]]。沒有人希望自己的產(chǎn)品存在太多的缺陷，但既然存在缺陷，應(yīng)該跟蹤和管理它。在介紹開源軟件缺陷跟蹤與管理之前，我們有必要對(duì)一般的缺陷管理過(guò)程有一個(gè)系統(tǒng)的認(rèn)識(shí)。
軟件存在的錯(cuò)誤(Bug)一般是在測(cè)試過(guò)程中發(fā)現(xiàn)出來(lái)的，對(duì)于如何處理測(cè)試中發(fā)現(xiàn)的錯(cuò)誤，將直接影響到測(cè)試的效果。對(duì)于測(cè)試中發(fā)現(xiàn)的Bug，需要有一個(gè)明確的管理流程。首先，測(cè)試人員提交新的Bug入庫(kù)，錯(cuò)誤狀態(tài)為New;然后，高級(jí)測(cè)試人員驗(yàn)證錯(cuò)誤，如果確認(rèn)是錯(cuò)誤，分配給相應(yīng)的開發(fā)人員，設(shè)置狀態(tài)為Open;如果不是錯(cuò)誤，則拒絕，設(shè)置為Declined狀態(tài);之后，開發(fā)人員查詢狀態(tài)為Open的Bug，如果不是錯(cuò)誤，則置狀態(tài)為Declined;如果是Bug則修復(fù)并置狀態(tài)為Fixed。對(duì)于不能解決的Bug，要留下文字說(shuō)明及保持Bug為Open狀態(tài)，但對(duì)于不能解決和延期解決的Bug，不能由開發(fā)人員自己決定，一般要通過(guò)某種會(huì)議(評(píng)審會(huì))通過(guò)才能認(rèn)可。后，測(cè)試人員查詢狀態(tài)為Fixed的Bug，然后驗(yàn)證Bug是否已解決，如解決置Bug的狀態(tài)為Closed，如沒有解決置狀態(tài)為Reopen[[4]]。這個(gè)過(guò)程中，我們可以發(fā)現(xiàn)它對(duì)測(cè)試人員的要求較高，如對(duì)于那些可能不是錯(cuò)誤的問題不應(yīng)該被當(dāng)作Bug處理。
2.2開源軟件Bug管理
相對(duì)于常規(guī)的Bug管理流程，開源軟件的缺陷跟蹤與管理理所當(dāng)然不能超越它。但是，正如我們所提到的，開源軟件的開發(fā)模式的特殊性對(duì)其Bug跟蹤與管理過(guò)程也提出了新的更嚴(yán)格的過(guò)程要求。在此，首先有必要對(duì)缺陷跟蹤系統(tǒng)(Bug Tracker)有一個(gè)比較正確的認(rèn)識(shí)。缺陷包括產(chǎn)品錯(cuò)誤，需求和設(shè)計(jì)變更，新特性或擴(kuò)展功能(New Feature， Enhancement)等，它存在于整個(gè)軟件開發(fā)生命周期之中[[5]]。那么，一個(gè)Bug Tracker 究竟要保存哪些信息呢?Bug跟蹤系統(tǒng)在軟件開發(fā)過(guò)程中也常常用來(lái)記載新的功能需求、任務(wù)日志、補(bǔ)丁包等，只要是具有明確的開始和結(jié)束狀態(tài)的東西，它們以及在這個(gè)過(guò)程中的轉(zhuǎn)變以及產(chǎn)生的信息都應(yīng)當(dāng)存儲(chǔ)到系統(tǒng)中。相比于商業(yè)軟件開發(fā)過(guò)程，在開源軟件開發(fā)過(guò)程中，一個(gè)Bug的典型生命周期是這樣的：?jiǎn)栴}報(bào)告者(可能對(duì)項(xiàng)目一無(wú)所知)總結(jié)出現(xiàn)的問題，給出恰當(dāng)?shù)某跏济枋�，將這些信息加以歸檔，然后提交到系統(tǒng);其他用戶或測(cè)試者讀到Bug信息，可能給出進(jìn)一步的注釋，在此過(guò)程中可能會(huì)通過(guò)適當(dāng)?shù)姆绞揭髿w檔者澄清一些問題;問題在其他用戶體驗(yàn)過(guò)程中再次出現(xiàn)，多次的重現(xiàn)表明這個(gè)問題確實(shí)存在，這個(gè)過(guò)程其實(shí)是一個(gè)Bug生命期的重要階段，因?yàn)橐粋�(gè)不真實(shí)的Bug可能在這個(gè)階段被關(guān)閉或刪除;問題或缺陷得到診斷，并且解決它需要付出的代價(jià)也有了估計(jì)，這個(gè)過(guò)程可能由開發(fā)成員完成，但也可能是熱情的用戶;問題解決時(shí)間有了初步規(guī)劃，可能在某一個(gè)但不一定是下一個(gè)版本中，問題會(huì)被解決;后，問題得到解決，相關(guān)的更改應(yīng)該被記錄下來(lái)后，應(yīng)該關(guān)閉這個(gè)問題。
但是，上面的過(guò)程可能會(huì)中途停止。那么，為什么一個(gè)Bug會(huì)中途夭折呢?其實(shí)可以想到，Bug報(bào)告者可能對(duì)項(xiàng)目或軟件產(chǎn)品不熟悉，這樣他可能提交一個(gè)錯(cuò)誤的問題報(bào)告。這樣，這個(gè)Bug可能很快被關(guān)掉。另一個(gè)變化因素是，同樣的問題在系統(tǒng)中已經(jīng)有了記載，甚至可能被解決了。在這種情況下，這個(gè)冗余的Bug會(huì)被刪除。當(dāng)然，開發(fā)者也許自以為是地認(rèn)為，某個(gè)Bug根本不存在，或者開發(fā)者簡(jiǎn)單地改動(dòng)一些地方后認(rèn)為Bug不再存在，于是他可能把實(shí)際上沒有解決的問題給關(guān)掉了[[6]]。
2.3Bug報(bào)告
技術(shù)支持被認(rèn)為是一件可怕的工作，因?yàn)橛凶玖拥腷ug報(bào)告需要處理[[7]]。我們可以看到，當(dāng)出現(xiàn)問題或缺陷后，系統(tǒng)可能得到許多用戶和測(cè)試者的報(bào)告，那么，如何有效地實(shí)施Bug Tracker呢?
一個(gè)開源項(xiàng)目啟動(dòng)后，Bug跟蹤系統(tǒng)也開始運(yùn)行，它一般運(yùn)行于C/S或B/S架構(gòu)的服務(wù)器上。在客戶端，它提供一種或多種用戶接口，如Web表單、郵件等，有些缺陷跟蹤系統(tǒng)還提供一些提交工具，簡(jiǎn)化了用戶操作。我們先關(guān)注針對(duì)客戶端的接口，比如，一個(gè)測(cè)試者想要報(bào)告一個(gè)Bug，他首先進(jìn)入Bug報(bào)告界面，但更多的時(shí)候，系統(tǒng)總是提示測(cè)試者要注意的事項(xiàng)。實(shí)際上，在報(bào)告Bug前重要的當(dāng)然是發(fā)現(xiàn)Bug并試圖找出它的原因了。正如linux新手可能會(huì)被告知：盡量關(guān)注當(dāng)前出現(xiàn)的問題并且試圖找出原因[[8]]。一個(gè)友好的Bug報(bào)告者不能是只知道抱怨，在報(bào)告中胡亂地描述著：彈出討厭的窗口。這樣的報(bào)告會(huì)產(chǎn)生歧義，那么，如何提交一個(gè)合格的Bug報(bào)告呢?Elisabeth Hendrickson在他的一本著作中寫道：當(dāng)你編寫bug報(bào)告時(shí)，記住你的聽眾，選擇一個(gè)好的標(biāo)題，清楚的記錄步驟并解釋錯(cuò)誤的影響;你的bug report將會(huì)因?yàn)槟慊ㄔ谒厦娴母裢馀Χ�，并且有更多的錯(cuò)誤被修復(fù);終將達(dá)到我們期望的結(jié)果-使錯(cuò)誤在傷害用戶之前得到修復(fù)[[9]]。的開源軟件質(zhì)量控制與保證平臺(tái)Mozilla規(guī)定了一個(gè)良好的Bug報(bào)告應(yīng)該包含以下信息：軟件版本序列號(hào)、運(yùn)行環(huán)境、錯(cuò)誤現(xiàn)場(chǎng)信息、調(diào)試與警告信息等[[10]]。實(shí)際中，缺陷跟蹤系統(tǒng)有必要提供適當(dāng)?shù)慕涌诮o用戶。
