bug管理系统都应该考虑什么因素

1、一般Bug管理大致流程是：1. 测试人员提交新的Bug入库，错误状态为New。2. 高级测试人员验证错误，如果确认是错误，器皆阄诟分配给相应的开发人员，设置状态为Open。如果不是错误，则拒绝，设置为Declined(拒绝)状态。3. 开发人员查询状态为Open的Bug，如果不是错误，则置状态为Declined；如果是Bug则修复并置状态为Fixed。不能解决的Bug，要留下文字说明及保持Bug为Open状态。对于不能解决和延期解决的Bug，不能由开发人员自己决定，一般要通过某种会议（评审会）通过才能认可。4. 测试人员查询状态为Fixed的Bug，然后验证Bug是否已解决，如解决置Bug的状态为Closed，如没有解决置状态为Reopen。

2、之前负责BUG管理工作时，从BUG管理系统收到的bug表述很多都是含糊不清，只是说出现了错误，但是错误的现象是什么，提示信息是什么，怎么操作才出现的，都不清楚，这样的bug交给开发人员，只会给开发人员增加负担，因为还要再作测试，以发现更多的信息，去排除bug，或者他会到测试那边其讨论，询问详情，有时要多次反馈才能确定到底是什么问题。这冗长的环节和时间等待，非常浪费时间和经理，等到后来同事遇到bug往往直接找我们技术反馈、处理而绕过bug管理系统。这样做肯定会影响到技术人员的开发效率，打断其思路，是非常不好的工作习惯。

3、虽然有自己的管理系统，但是bug管理系统并不是团队每个成员经常登录的系统，这就导致遇到bug时，需要经过“找出收藏的网址→登陆→依照指标输入详情→阶段性查看最新进展”，如果遇到这个bug是用户向你反馈而后你输入到bug系统时，你还需要等几天后给出反馈。所以同事的反馈不好用、不爱用、企业花了大价钱购买的系统无疑没有起到应有的作用。