Mantis基本特性：
- 个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件；
- 支持多项目、多语言；
- 权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动；
- 主页可发布项目相关新闻，方便信息传播；
- 方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷；
- 缺陷报告可打印或输出为CSV格式，0.18.0版：支持可定制的报表输出，可定制用户输入域；
- 有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析；
- 流程定制不方便，但该流程可满足一般的缺陷跟踪。
 |
四、项目实施经验教训
测试作为项目开发的最后一环，错误、延时、疏忽等都可能在测试阶段表现出来，如何有序管理和分析各种问题对质量控制和过程改进非常重要，使用web based系统就是一个好的实践。
在项目组内，对Bug采用数据库系统进行跟踪并不困难，因为主要是测试人员提交Bug报告，测试人员使用最多，相信测试人员对使用中心数据库的好处是很了解的了，只要项目经理支持就很好办了。如果要对其他缺陷，如需求变更，也这样管理就不是那么容易了，在技术上当然没有问题，难在工作方式的改变，虽然用Email和文档管理无法实现工作流的自动化，也不如数据库系统提供那么多的分析和报告选项，但在小规模的项目中依靠人工管理也可以做得井井有条。我们在多个项目的实施中就遇到这样的情况，有的项目随时都有需求变更，而且变更的数量不少，项目组主动提出想用数据库系统来管理；有的项目刚起步，第一个阶段的开发业务功能不多，推行的时候阻力就很大。我的初级目标是有序地管理错误和变更，在实施手段上有冲突时，不要操之过急，融洽的关系对项目的成功是很重要的。往往是有了成功的案例后，回头推广又变得容易了。实施新过程时最好先局部试点，采用PDCA循环，不断总结经验，再推广。
使用缺陷数据库，可以制作得到各种缺陷分析图表，从而预测项目风险或解释测试结果。下面两张图都是Mantis生成的缺陷图，从累积错误打开图，分析错误生成趋势，在发现错误报告未收敛时发布软件，显然风险很大，当然使用图表时还应结合实际，在曲线平坦时，是否开展了测试工作，曲线上升时，错误的严重性等级如何等。从严重性等级的柱状图可分析被测系统的总体状况。在发布管理不规范的组织中，当产品质量问题突出时，测试组可以通过解释这些图来阐述测试结果，从而规范发布过程。
第一部分提到的根本原因（Root Cause）域，他有助于使开发人员的注意力集中到引起最严重、最频繁问题的领域，从而消耗最少的资源改进过程取得最显著的成果，这是我在过程改进时最常用到的 80/20法则。在项目实施时，实际情况并不理想，因为开发人员忙于改Bug，少有主动写错误发生的根本原因的，这需要开发人员的配合和管理者的支持。
缺陷数据的使用应谨慎，不要将错误个人化，应保证数据的真实性，否则数据对过程改进没有意义。
文章来源于领测软件测试网 https://www.ltesting.net/
