|
級別: 初級 蔡琰 (cindy_cai@sina.com), QA 主管, 外企 2003 年 12 月 01 日 缺陷管理貫穿于整個軟件開發(fā)生命周期中, 是不可缺少的環(huán)節(jié)，但在國內(nèi)一些中小型開發(fā)商中沒有得到足夠得重視。本文結(jié)合實際應(yīng)用，系統(tǒng)地介紹了缺陷跟蹤開源軟件 Buggit 和 Mantis, 以期拋磚引玉，引起重視。 在您的項目中,是否有遇到過 這樣的問題：測試人員報的缺陷被遺忘掉；延期項目終于發(fā)布，卻遭遇用戶頻頻抱怨，管理人員將矛頭指向測試人員；書寫不規(guī)范的錯誤報告，使得開發(fā)人員不得不 一次次找到測試人員來重現(xiàn)；地域分散的開發(fā)團隊，通過email和文檔交流，缺陷狀態(tài)混亂，相關(guān)人員無法及時獲得有關(guān)的變更信息…… 那 么，讓測試組織使用數(shù)據(jù)庫來部署產(chǎn)品缺陷的記錄和跟蹤吧！對于中小軟件開發(fā)組織，或許不太可能使用動則幾千美金一個許可證的商業(yè)軟件，但免費而又易于維護 的軟件完全可以滿足您80%以上的需要。如果您的組織還陷于無窮無盡的混亂不堪的缺陷之中，不要猶豫，馬上行動，免費軟件可以很好地管理這個過程，但在實 施中對管理上提出的要求則是您應(yīng)該自我提高的。下面我們看看一個中小型開發(fā)組織兩年多的實施過程，或許對您有些啟發(fā)。 某 公司在全球航運業(yè)信息化領(lǐng)先，在全球設(shè)有四個研發(fā)中心，主要為公司開發(fā)航運和物流軟件，大多給公司內(nèi)部和業(yè)務(wù)有關(guān)的客戶使用，有些成熟的軟件銷售給同行或 作為中立的平臺提供給同行使用。該公司的上海的研發(fā)中心使用的是免費或開源的軟件跟蹤缺陷，有獨立的測試小組，工作包括功能測試、壓力測試、質(zhì)量保證和過 程改進，使用的是免費軟件Buggit。 后來為了解決異地開發(fā)過程中的缺陷跟蹤問題, 開始使用Mantis 0.17.5版本（開源軟件，PHP/MySQL/Web Based），開始用一個實際的項目作試點，并根據(jù)項目組不同角色成員的反饋，測試組對系統(tǒng)進行配置和代碼的修改加以提高；由于效果很不錯，幾個月后就推 廣到其他多個項目。
缺 陷包括產(chǎn)品錯誤，需求和設(shè)計變更，新特性或擴展功能（New Feature, Enhancement）等，它存在于整個軟件開發(fā)生命周期之中。使用中心數(shù)據(jù)庫便于項目組和管理人員獲取正確、足夠的信息，簡化了地域分散的組織的信息 共享流程，它還可以實現(xiàn)工作流程的自動化，最大限度減少重復(fù)工作。 不同的組織，缺陷跟蹤流程會有所不同，下圖是一個典型的缺陷生命周期圖。  在alpha/beta測試期間，測試人員將發(fā)現(xiàn)的Bug 提交到缺陷跟蹤系統(tǒng)，該系統(tǒng)至少應(yīng)包含：
一個好的系統(tǒng)還需要：
提交之后，Bug為"Submitted"狀態(tài)，變更控制委員會（Change Control Board，視項目規(guī)模組織，可以是不同角色的幾個人組成或一個人擔當）評審決定：
開發(fā)人員將Bug修復(fù)后，其狀態(tài)改為"Resolved"，他們應(yīng)發(fā)布到下一個測試版本（Test Build）中，測試人員測試所有"Resolved" Bug，沒有問題應(yīng)關(guān)閉（"Closed"狀態(tài)），未修復(fù)則要重新打開（"Opened"狀態(tài)）。 對于用戶提交的Bug，有些系統(tǒng)會增加"Confirmed"的狀態(tài)，表示經(jīng)測試Bug確實存在。 對其他變更（如需求改變或新增），以上流程同樣適用，但可能需要多次分配（assign），如需求變更，業(yè)務(wù)分析員要更新需求文檔，系統(tǒng)分析員要更新設(shè)計文檔，然后程序員改代碼。 系統(tǒng)最好還有以下功能：
流程制定并評審?fù)ㄟ^后，就應(yīng)該選擇合適的工具，對一個新組建的組織，也可以先選擇工具，再結(jié)合特定的工具制定流程。正式實施前應(yīng)對項目組所有成員進行培訓(xùn)，以提高工具使用效率和成員間的溝通效率。 最初我們選擇了一個十分簡單而又易于維護的工具Buggit，用于項目組內(nèi)部的Bug跟蹤；隨著跨地域開發(fā)項目的出現(xiàn)，溝通交流復(fù)雜性凸現(xiàn)，我們適時選擇了Web Based系統(tǒng)。下面看看兩個系統(tǒng)的具體實施。
測試作為項目開發(fā)的最后一環(huán)，錯誤、延時、疏忽等都可能在測試階段表現(xiàn)出來，如何有序管理和分析各種問題對質(zhì)量控制和過程改進非常重要，使用web based系統(tǒng)就是一個好的實踐。 在 項目組內(nèi)，對Bug采用數(shù)據(jù)庫系統(tǒng)進行跟蹤并不困難，因為主要是測試人員提交Bug報告，測試人員使用最多，相信測試人員對使用中心數(shù)據(jù)庫的好處是很了解 的了，只要項目經(jīng)理支持就很好辦了。如果要對其他缺陷，如需求變更，也這樣管理就不是那么容易了，在技術(shù)上當然沒有問題，難在工作方式的改變，雖然用 Email和文檔管理無法實現(xiàn)工作流的自動化，也不如數(shù)據(jù)庫系統(tǒng)提供那么多的分析和報告選項，但在小規(guī)模的項目中依靠人工管理也可以做得井井有條。我們在 多個項目的實施中就遇到這樣的情況，有的項目隨時都有需求變更，而且變更的數(shù)量不少，項目組主動提出想用數(shù)據(jù)庫系統(tǒng)來管理；有的項目剛起步，第一個階段的 開發(fā)業(yè)務(wù)功能不多，推行的時候阻力就很大。我的初級目標是有序地管理錯誤和變更，在實施手段上有沖突時，不要操之過急，融洽的關(guān)系對項目的成功是很重要 的。往往是有了成功的案例后，回頭推廣又變得容易了。實施新過程時最好先局部試點，采用PDCA循環(huán)，不斷總結(jié)經(jīng)驗，再推廣。 使 用缺陷數(shù)據(jù)庫，可以制作得到各種缺陷分析圖表，從而預(yù)測項目風險或解釋測試結(jié)果。下面兩張圖都是Mantis生成的缺陷圖，從累積錯誤打開圖，分析錯誤生 成趨勢，在發(fā)現(xiàn)錯誤報告未收斂時發(fā)布軟件，顯然風險很大，當然使用圖表時還應(yīng)結(jié)合實際，在曲線平坦時，是否開展了測試工作，曲線上升時，錯誤的嚴重性等級 如何等。從嚴重性等級的柱狀圖可分析被測系統(tǒng)的總體狀況。在發(fā)布管理不規(guī)范的組織中，當產(chǎn)品質(zhì)量問題突出時，測試組可以通過解釋這些圖來闡述測試結(jié)果，從 而規(guī)范發(fā)布過程。 第一部分提到的根本原因（Root Cause）域，他有助于使開發(fā)人員的注意力集中到引起最嚴重、最頻繁問題的領(lǐng)域，從而消耗最少的資源改進過程取得最顯著的成果，這是我在過程改進時最常用到的 80/20法則。在項目實施時，實際情況并不理想，因為開發(fā)人員忙于改Bug，少有主動寫錯誤發(fā)生的根本原因的，這需要開發(fā)人員的配合和管理者的支持。 缺陷數(shù)據(jù)的使用應(yīng)謹慎，不要將錯誤個人化，應(yīng)保證數(shù)據(jù)的真實性，否則數(shù)據(jù)對過程改進沒有意義。 實施過程中，大家會對工具提出很多需求，應(yīng)評估哪些是共同需求、核心需求，系統(tǒng)修改復(fù)雜程度，對當前系統(tǒng)和系統(tǒng)升級的影響。測試組在實施過程中，對不同角色人員的工作流程有了深入而準確的了解，同時可以進行工作流程的改進。 使用開源系統(tǒng)的利弊 由 于開源系統(tǒng)的代碼是公開的，用戶可自行維護和定制，大家也可以提交新特性和功能擴展要求，而不必受制于商業(yè)系統(tǒng)的制造商。開源系統(tǒng)的用戶遍布世界各地， Bug反而容易發(fā)現(xiàn)，同時公開源代碼中低效率的程序也容易被發(fā)現(xiàn)和修改。當然越是流行的軟件，生命力越強，Bug清除和新特性增加越快。 開 源系統(tǒng)與其他工具的集成比較差，不如商業(yè)系統(tǒng)提供整個軟件開發(fā)生命周期的工具的集成，如項目管理、需求管理、建模、自動化測試、缺陷跟蹤、配置管理等有機 集成，實現(xiàn)整個開發(fā)流程的自動化。但一般的中小企業(yè)，大多沒有實力配置全所有系統(tǒng)，另外，不同廠商優(yōu)勢不同，主導(dǎo)系統(tǒng)也不同，有的企業(yè)需要根據(jù)自身的特點 選擇不同廠商的工具，所以即使購買商業(yè)工具也未必能將所有系統(tǒng)很好地集成。 開源系統(tǒng)是免費的，但有人提供收費的系統(tǒng)維護和定制服務(wù)。
本 文主要探討缺陷跟蹤管理的流程、工具和實施問題，缺陷跟蹤在技術(shù)上并不難，而是難在管理上，好的工具有利于管理和交流，優(yōu)秀的項目組應(yīng)意識到有效的交流方 式是多種多樣的，不應(yīng)該單依賴系統(tǒng)，這樣才有利于提高團隊的戰(zhàn)斗力，而不是把重點放在追求系統(tǒng)功能的十全十美。有些缺陷跟蹤系統(tǒng)有Knowledge Base 功能，這對公司知識庫的累積也很有效；有的系統(tǒng)對不同用戶生成相關(guān)的To-Do-List，方便日常工作；有的對每個發(fā)布版本都有詳細的缺陷報告?？傊?花費時間和精力完善錯誤管理系統(tǒng)是值得的，這是質(zhì)量管理和提高的基礎(chǔ)。
| |||||||||||||||||||||||||
