缺陷管理贯穿于整个软件开发生命周期中, 是不可缺少的环节，但在国内一些中小型开发商中没有得到足够得重视。本文结合实际应用，系统地介绍了缺陷跟踪开源软件 Buggit 和 Mantis, 以期抛砖引玉，引起重视。
在您的项目中,是否有遇到过这样的问题：测试人员报的缺陷被遗忘掉；延期项目终于发布，却遭遇用户频频抱怨，管理人员将矛头指向测试人员；书写不规范的错误报告，使得开发人员不得不一次次找到测试人员来重现；地域分散的开发团队，通过email和文档交流，缺陷状态混乱，相关人员无法及时获得有关的变更信息……
那么，让测试组织使用数据库来部署产品缺陷的记录和跟踪吧！对于中小软件开发组织，或许不太可能使用动则几千美金一个许可证的商业软件，但免费而又易于维护的软件完全可以满足您80%以上的需要。如果您的组织还陷于无穷无尽的混乱不堪的缺陷之中，不要犹豫，马上行动，免费软件可以很好地管理这个过程，但在实施中对管理上提出的要求则是您应该自我提高的。下面我们看看一个中小型开发组织两年多的实施过程，或许对您有些启发。
一、项目背景、组织架构
某公司在全球航运业信息化领先，在全球设有四个研发中心，主要为公司开发航运和物流软件，大多给公司内部和业务有关的客户使用，有些成熟的软件销售给同行或作为中立的平台提供给同行使用。该公司的上海的研发中心使用的是免费或开源的软件跟踪缺陷，有独立的测试小组，工作包括功能测试、压力测试、质量保证和过程改进，使用的是免费软件Buggit。
后来为了解决异地开发过程中的缺陷跟踪问题, 开始使用Mantis 0.17.5版本（开源软件，PHP/MySQL/Web Based），开始用一个实际的项目作试点，并根据项目组不同角色成员的反馈，测试组对系统进行配置和代码的修改加以提高；由于效果很不错，几个月后就推广到其他多个项目。
二、缺陷跟踪流程
缺陷包括产品错误，需求和设计变更，新特性或扩展功能（New Feature, Enhancement）等，它存在于整个软件开发生命周期之中。使用中心数据库便于项目组和管理人员获取正确、足够的信息，简化了地域分散的组织的信息共享流程，它还可以实现工作流程的自动化，最大限度减少重复工作。
不同的组织，缺陷跟踪流程会有所不同，下图是一个典型的缺陷生命周期图。
在alpha/beta测试期间，测试人员将发现的Bug 提交到缺陷跟踪系统，该系统至少应包含：
失败描述：摘要、重建步骤、隔离信息；
识别信息：顺序的ID号、报告作者、报告归档日期。
一个好的系统还需要：
严重性等级，以评估在测试条件下，错误在系统中的绝对影响；
优先级，评估顾客实际使用中发生事件的可能性，或对目标顾客的后续影响；
环境：系统软、硬件配置，测试版本号；
附件，错误信息或屏幕截图。
提交之后，Bug为"Submitted"状态，变更控制委员会（Change Control Board，视项目规模组织，可以是不同角色的几个人组成或一个人担当）评审决定：
是Bug，分配给相关开发人员修复，状态为"Assigned"；
不是Bug或其他原因，关闭，状态为"Closed"，解决方式（Resolution）根据实际情况选择；
是Bug，但延迟到下一个版本修复，状态为"Postponed"。
开发人员将Bug修复后，其状态改为"Resolved"，他们应发布到下一个测试版本（Test Build）中，测试人员测试所有"Resolved" Bug，没有问题应关闭（"Closed"状态），未修复则要重新打开（"Opened"状态）。
对于用户提交的Bug，有些系统会增加"Confirmed"的状态，表示经测试Bug确实存在。
对其他变更（如需求改变或新增），以上流程同样适用，但可能需要多次分配（assign），如需求变更，业务分析员要更新需求文档，系统分析员要更新设计文档，然后程序员改代码。
系统最好还有以下功能：
Root Cause：根本原因分析，这需开发人员的帮助；
Close Date和Resolution：系统生成关闭日期，可选择或输入问题是如何解决的；
系统自动跟踪记录缺陷历史，可输入注释；
方便的查询功能；
可定制的报表，缺陷趋势图表；
Email提醒。
文章来源于领测软件测试网 https://www.ltesting.net/
