Mantis系统使用培训及bug提交规范

我们按照上面ppt的方案实施了一年，能很好的适应各种情况，如果公司只有一个项目，这个方案游刃有余。但是随着公司的项目越来越多，测试的面越来越广，原先的方案设计在某些地方显的繁琐，出现的主要问题是，mantis里项目越来越多，按版本建的子项目也越来越多，举个例子，公司一个项目在mantis里一般分三个独立项目客户端，服务端，嵌入式，每个独立项目又按版本分子项目，随着版本迭代的增多，在项目选择里，会看到一个无法忍视的列表，每次测试人员报bug也很容易选错，且子项目之间名称不能重名，对以版本号命名的子项目来说很为难，当初按版本建子项目是为了方便处理每个项目的bug，这个通过其它方法也能解决，所以这个时候我们做了如下改进：

1. 所有的项目简化为一个主项目+一个子项目（遗留问题）

去掉所有子项目，用mantis的目标版本代替，如果当前迭代版本为1.2.0，则当前迭代版本的bug目标版本设置为1.2.0.

遗留问题子项目作为历史迭代未解决的问题汇总，在下次迭代的开始，项目经理可以从遗留问题里挑出本次迭代需要解决的问题，迭代完毕，会将没有解决的问题移到遗留问题里

2 启用发布版本属性

这个发布版本属性测试人员不用关心，由发布人员进行设置，主要是用来记录本次发布解决了哪些问题，对问题进行归档。

按照这个方案设计我们又使用了大半年，能达到我们的预期，子项目数骤降，列表也变的好看了，也变的易于管理了。

文末，也欢迎测试同行指点，提出更好的设计方案，一同进步。