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