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