|
|
| Mantis使用规范V1 |
|
|
|
|
缺陷跟踪管理系统
使用规范
XXXXXXXXXX
XXXX年XX月
1MantisBT简介
缺陷管理平台Mantis，也做MantisBT，全称MantisBugTracker。
Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。
Mantis是一个缺陷跟踪系统具有多特性包括：易于安装，易于操作，基于Web，支持任何可运行PHP的平台，已经被翻译成68种语言，支持多个项目，为每一个项目设置不同的用户访问级别，跟踪缺陷变更历史，定制我的视图页面，提供全文搜索功能，内置报表生成功能(包括图形报表)，通过Email报告缺陷，用户可以监视特殊的Bug，附件可以保存在web服务器上或数据库中，自定义缺陷处理工作流，支持输出格包括、MicrosoftExcel、MicrosoftWord，集成源代码控制(SVN与CVS)，集成wiki知识库与聊天工具(可选/可不选)，支持多种数据库(MySQL、MSSQL、PostgreSQL、Oracle、DB2)，提供WebService(SOAP)接口，提供Wap访问。
Mantis基本特性：
个人可定制的Email通知功能，每个用户可根据自身的工作特点只订阅相关缺陷状态邮件；
支持多项目、多语言；
权限设置灵活，不同角色有不同权限，每个项目可设为公开或私有状态，每个缺陷可设为公开或私有状态，每个缺陷可以在不同项目间移动；
主页可发布项目相关新闻，方便信息传播；
具有方便的缺陷关联功能，除重复缺陷外，每个缺陷都可以链接到其他相关缺陷；
缺陷报告可打印或输出为CSV格式，1.1.7版：支持可定制的报表输出，可定制用户输入域；
有各种缺陷趋势图和柱状图，为项目状态分析提供依据，如果不能满足要求，可以把数据输出到Excel中进一步分析；
流程定制方便且符合标准，满足一般的缺陷跟踪。
2.1状态
新建
反馈
确认
分派
解决
关闭
未处理
已修正
重新打开
修改为改完成度状态。
无法重现
无法修复
重复问题
不是问题
暂停
不做修改
2.3问题优先级
低：事件不重要,可以在时间和资源允许的情况下再解决。
中：事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决。
高：事件是重要的,并且应该在紧急的事件处理之后尽快得到解决。
加急：事件非常重要,并且需要马上给予关注。
特急：导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等。
2.4角色
决策组：一般指项目管理者，包括产品经理、开发经理、项目经理等
测试人员：测试人员
开发人员：具体的开发人员
3缺陷处理流程规范
缺陷处理流程规范如下：
由测试人员提交bug
由决策组人查看bug，判断是否重复，处理的及时性，需要修复的bug分配给相应的开发人员，其余bug反馈给测试人员
由开发人员负责修改bug
由测试人员验证，关闭bug
3.1测试人员提交BUG
测试人员提交bug时，必须填写【分类】【出现频率】【严重性】【平台配置】【产品版本】【摘要】【描述】；当重现bug的步骤复杂时，需填写【问题重现步骤】；同时可以添加截图辅助说明bug。
【严重性】：严重性的评定标准参照《软件测试BUG等级评定规范》。
【出现频率】：每次必现的为经常，做相同操作不是每次都存在的为随机，没有时间重复做试验的为没有试验，无法再现的为无法重复，一定要写。
【摘要】：对发现问题的原因及结果的简单描述，包括发现问题的模块及界面名称，出现的结果。
【描述】：Bug的描述遵照5C标准，5C标准具体如下：
Correct（准确）：每个组成部分的描述准确，不会引起误解；?Clear（清晰）：每个组成部分的描述清晰，易于理解；?Concise（简洁）：只包含必不可少的信息，不包括任何多余的内容；?Complete（完整）：包含复现该缺陷的完整步骤和其他本质信息；?Consistent（一致）：按照一致的格式书写全部缺陷报告。jpg、png、doc、xls、xml、zip、rar文件，大小不要超过5MB。
3.2测试人员处理反馈的BUG
对于重复问题，查看系统确认，若为重复问题，则将问题状态置为【关闭】，若不是重复问题，反馈给开发负责人，问题完成度置为【未处理】；
对于无法重现问题，重新验证，若无法重现，将问题状态置为【关闭】，若可以重现，将问题状态置为【反馈】，反馈给相应开发，问题完成度置为【未修改】，
对于不是bug的问题，确认后将问题状态置为【关闭】；
3.3决策组处理BUG
决策组按照bug描述，项目需求，项目资源情况调整bug优先级，确定目标版本，并按照缺陷处理流程规范调整bug状态及完成度，需要修复则分派给相应开发人员。具体规范如下：
对于提交重复的bug，将状态置为反馈，反馈给相应测试人员，完成度置为重复问题；
对于不是bug的问题，将状态置为反馈，反馈给相应的测试人员，完成度置为不是问题；
对于未分配的bug，将状态置为确认，完成度保持未修复；
对于因技术问题无法修改的bug，将状态置为认可，完成度置为无法修复；
对于是问题，但是允许存在，或者暂时允许存在的bug，将状态置为认可，完成度为不做修改；
对于由于版本或其他原因而允许暂时停止修复的bug，将状态置为认可，完成度为暂停；
对于需要在本版本修改的bug，将状态置为分派，分派给响应开发人员，完成度保持未处理不变；
对于开发人员反馈的bug，需重新审查处理，处理方式同上。
3.4开发人员处理BUG
查看分派给自身的bug
若无法重现，将状态置为反馈，反馈给测试人员，完成度改为无法重现；
对于提交重复的bug，将状态置为反馈，反馈给开发负责人，完成度置为重复问题；
对于因技术问题无法修改的bug，将状态置为反馈，反馈给决策组代表（如项目经理、产品经理、开发负责人等），完成度置为无法修复；
对于因分派错误无法修改的bug，将状态置为反馈，反馈给决策组代表（如项目经理、产品经理、开发负责人等），完成度置为未修复；
修改完成，将状态置为解决，同时分派给相应测试人员，完成度置为已修正；
开发人员修复bug后，修改完成度，选择修正版本:Bug产生的原因，修改方法
文件：修改涉及的文件
函数:修改涉及的函数
4补充说明
Mantis不管理需求，如出现需求不明确的问题，由决策组处理。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
