Bug管理工具有很多,jira、禅道、git、mantis等等,有些公司,甚至会用Word、Excel等来记录Bug,不论是工具或者文档,只要能记录问题,都是可以的
那么如何报一个Bug才对呢,首先来看什么是漂亮的Bug:
一个好的Bug包括了简洁的标题,详细的步骤,明了的截图等
- 根据Bug步骤能重现bug
- 其他人看到你的Bug,心情没有变糟糕,要记住,你报的Bug,阅读对象可能是其他测试、开发、产品经理、甚至可能是你的领导
- 开发看到你的Bug后,基本上95%知道问题出在什么地方了
标题(摘要):
力求精简,表达清楚,避免出现写作文似的标题,一个好的标题应该尽量不超过50个字
优先级:
在时间不够的情况下,开发会根据优先级来修复Bug,标好优先级,方便开发处理问题,提高整个团队的效率,原则上,在上线之前所有提交的Bug都应该被修复,最次也要达到Major及以上级别的Bug都被修复
较通用标准:
- Blocker(P0):整个模块功能不能用、准入没有通过、测试无法继续工作;
- Critical(P1):崩溃、闪退等、主要功能无法实现、实现与需求严重不符、数据丢失;
- Major(P2):操作界面错误、次要功能无法实现或实现与需求不符、边界条件出现的错误、提示信息错误;
- Minor(P3):错别字、产品建议、不影响使用的易用性问题;
环境:
发生bug的环境是什么,比如浏览器是Chrome60.0.0.1、360 8.1、Android4.0 小米4、ios11 iPhone8等,标明了Bug发生的环境,更能帮助开发在特定的环境快速定位问题
账号:
Bug是否发生在特定的账号里,想复现Bug是否需要非常复杂的步骤,如果是,给出复现的账号吧,开发只要登录,找到对应的位置,就可以轻松复现解决
描述:
一个好的Bug描述,决定了其他人拿到这个Bug之后,是否能准确复现Bug,不要漏掉任何一个步骤
操作步骤:
步骤1:xxxxx
步骤2:xxxxx
实际结果:
比如:实际结果:删除文件失败。对于实际现象表现较复杂的,可以分子项来写,比如:实际结果:a.xxx;b.xxx
期望结果:
比如:期望结果:删除文件成功。期望信息较多的也可以分子项来写,力求信息全面,表达清楚。
附件:
贴上Bug的截图或者录屏、git动画等,开发就会很明了,不会在去重复询问,有的时候,一张图更能传达bug的意,问题不好用文字描述,使用录屏可以让开发很好的理解并重现Bug
log:
客户端崩溃了,客户端发生了一个不能重复的Bug,贴上崩溃的Crash,发生问题时候的log,开发一看就很明了
不要对一个程序员说:你的代码有Bug。
他的第一反应是:1,你的环境有问题吧;2,傻逼你会用吗。
如果你委婉地说:你这个程序和预期的有点不一致,你看看是不是我的操作方法有问题?
他本能地会想:操,是不是出Bug了!