1 Mantis工具应用技巧
在我的项目中，使用的是Mantis工具来管理缺陷。
用过Mantis系统的伙伴应该都知道，Mantis是一个开源缺陷跟踪系统，以Web可视化UI界面进行操作，进行项目管理及缺陷跟踪。
虽然Mantis系统有如下的功能特性：
1、可定制Email通知功能；
2、支持多项目、多语言；
3、权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动；
4、具有方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷；
5、缺陷报告可打印或输出为CSV格式；
6、有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析；
但是，Mantis系统有一个重要信息是需要自己定制的，那就是功能模块。
如果不去定制，采用初始的配置，那么你提交的缺陷属于什么功能的都没有办法清晰的标识，非常不方便缺陷管理。
所以，你必须自行增加一些字段来满足缺陷所属功能模块的管理。
下面就以我参与的项目为例，介绍一下，如何通过自定义字段来管理缺陷类别和功能模块，供各位网友参考。
1.1 管理缺陷类别
在项目中，一般会是整个项目使用同一个Mantis系统来管理缺陷，不管是开发人员还是测试人员。
但是，项目中需要跟踪的问题可能是缺陷类的问题，也可能是需求类的问题。缺陷类问题，有的是开发提测之前发现的，有的是提测之后测试人员发现的。
所以，我们用“分类”字段来区分问题大类，并且是提单必填字段，分为三大类：产品需求问题、开发阶段问题、测试阶段问题。
如图所示：
该自定义字段的添加步骤如下：
1）使用管理员账号，进入Mantis“管理”栏
2）进入“项目管理”页面，如图：
3）在“全域分类”板块，输入想添加的“分类”字段，如“测试阶段问题”，然后点击“添加分类”按钮，如图：
这样就可以添加字段成功了。
1.2 管理功能模块
“分类”字段用于对缺陷进行总体类别划分，但是这个字段不适合划分功能模块，因为功能模块通常划分比较细致，并且通常数量较多。
所以，我们需要用其他的自定义字段来实现功能模块的管理。下面就是我们项目中使用的管理方法。
1.2.1 新建字段
首先，进入使用管理员账号，进入Mantis“管理”栏。然后，进入“自定义字段管理”页面。
下一步，手动输入自定义字段的名称，如图例中的“XX特性功能模块”。最后，点击“新建自定义字段”按钮。
1.2.2 编辑字段属性
自定义字段新建成功后，进入修改自定义字段页面，对字段进行属性编辑。
1. 类型可以根据需要和喜好进行选择，一般一个缺陷属于单个模块，所以，最好选用列表或者单选框，此例中以单选框为例，如下图：
2. 可能取值
此例中为 基本功能|功能交互|容量|稳定性|易用性|兼容性，中间用“|”隔开。
3. 然后勾选什么场景下显示以及什么场景下必需
一般“在创建问题时显示”和“报告问题时必需”要勾选，如图所示：
4. 点击“修改自定义字段”按钮，就成功修改了字段属性。
1.2.3 自定义字段关联到项目
自定义字段属性配置成功后，接下来就是关联到项目：
进入修改自定义字段页面，选择需要关联的项目，Ctrl+A可全选所有项目进行关联，然后点击关联自定义字段，这样就关联成功了。
1.2.4 功能模块字段的使用
根据上面的配置，“功能模块”在提交问题单时会显示出来，并且为必填项，如下所示：
前面主要是介绍如何通过缺陷管理工具的应用，有条理的管理缺陷，可以方便进行缺陷度量和测试相关的度量。
但是，管理好缺陷不意味着可以管理好测试，测试工作做得好不好，一个重要度量参考数据就是是否存在漏测。
正如ISTQB高级大纲中提到的：测试过程的附加值只能通过整个项目或程序的成功（或通过防止更严重的失效发生）来体现，因此，测试经理必须相应地计划和控制测试过程。
所以，避免漏测是测试工作的重要目标。下面我就结合项目实战来说一下避免漏测的方法。
2 如何尽量避免漏测
2.1 漏测是测试从业者心中永远的痛
对于测试组长、测试经理、测试总监等测试管理者来说，最担心的问题之一就是漏测。所以，如何避免漏测是测试管理过程中一个很重要的课题。
漏测从狭义上讲，是指有bug没有测试出来，遗漏给了下游（运维、技术支持、客户、用户等）。从广义上讲，测试出来的bug，但是由于误判或过失导致私自关闭bug单，最终bug遗漏给下游，也属于漏测。
2.2 如何减少漏测？
避免漏测的途径有很多，增加测试覆盖、测试前移、采用基于风险或基于需求的策略、实时调整测试计划，这些途径都可以不同程度的避免漏测。
本文要重点说的是，通过有序、规范的缺陷管理间接避免漏测（绝对的避免是不可能的，可以尽量减少漏测）。
2.3 案例分析
如下是我之前的一个项目遵循的缺陷处理规范：
1、提交问题单不能跨天
2、冒烟测试阶段及最后一轮测试提交问题要在发现问题后一个小时内
3、修改问题单级别、非正常关闭问题单必须经过直接主管评审
4、回归关闭问题单，必须备注好回归通过的版本信息
5、非正常关闭问题必须备注好关闭过程，如什么时间，经过哪些人评估过
6、开发无权关闭问题单，开发也无权单方面提出关单的建议
7、不重现的问题，或者低概率的问题，原则上要持续观察两个版本以上才能关闭
8、提交问题单需包含重现步骤、实际结果、预期结果、问题影响、日志、截图
9、问题级别要准确评估，影响上线发布的，问题级别一定要在4以上（假如级别从低到高分别是1-2-3-4-5），级别拿不准的，找组长评估
我们来分析和总结一下上面这个规范。
2.3.1 时效性
第1、2条主要是强调提交问题单的时效性的，符合测试基本原则中的“尽早发现问题”原则。其中第2条主要是强调在测试周期的前期和后期需要缩短发现bug到提交bug的时间间隔，给开发解决问题及管理团队评估问题预留更多的时间。
2.3.2 慎重关单，宽进严出
第3、4、5、6、7主要是针对关闭问题要慎重，只能由提单人关闭问题单，问题未解决情况下的关闭要经过严格的评审过程进行质量把控，概率性的问题要经过多个版本的反复测试。这样就不会发生问题单没有经过处理随意关闭的情况了，从而可以减少漏测。
2.3.3 问题单信息要全
第8条强调的是问题单提交时信息要全面，这样做的目的是可以让处理问题单的开发人员能更清楚的了解问题的详情，能更快、更容易的分析出问题的原因，从而更好的推动问题解决，避免问题和风险遗留。
2.3.4 问题单级别要合情合理
第9条主要说的是，较严重的问题，提交缺陷单的时候，问题级别信息要匹配合理，否则会影响测试经理或者项目经理的判断，造成问题遗漏出去。
3 说在最后的话
当然，上面的这个缺陷管理规范，主要是围绕针对问题单处理的。实际上在项目开展的过程中，沟通和汇报也是非常重要的环节。对于一些关键问题，测试工程师一定要在提单的基础上，第一时间知会测试经理，甚至是先汇报再提单。关键问题举例：阻塞性问题、关键特性问题、重大修改引入问题、较严重的二次故障问题等。
希望上面的这些经验可以帮助相关人员（主要是测试管理者、测试工程师）更好的避免漏测，进一步提升软件产品的质量信心。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
