提BUG的正确姿势

在软件项目中经常会有各种或大或小的Bug，更甚一点出现Error。

首先针对该bug我们需要尝试如何定位相关的问题，具体可参看：。

当我们定位出来后，又如何清晰无异议的提出Bug呢？是不是经常遇到别人给你说某某地方有个Bug，然后就没有然后了...你是什么反应？或者一个功能表面上看起来都是正常的，但他说结果错了，然后呢，然后也没然后了，你去看了一下，好像都正常，没有报错什么的，这时候你是什么反应？以上可能是我们在工作中经常出现的一些场景；

再说说我们作为QA人员，在提bug的时候经常犯的错误：

• 第一种，只说错误现象。在没有明显的错误情况下，报告错误而不说正确的结果应该是什么，没有应该正确的结果（预期结果）对比，光说错误相当于污蔑。

• 第二种，描述笼统。

• 第三种，Bug point缺乏上下文。比如说，某个页面里的一个功能按钮有bug，如果直接报告这个功能按钮，你是一下子反应不过来的，你的系统分为很多大模块，然后下面有小模块，然后下面有很多页面，这个页面里有很多功能按钮，甚至很多页面都有相同的按钮，那么到底是说哪个页面的功能按钮有Bug呢

以上几种情况会造成一个直接的结果就是：沟通成本太大！

 

目前我们一般会分为2种方式处理在测试过程中的问题：

1.针对复杂/特殊数据才能显示的bug，可以先把数据造出来跟开发直接沟通后再提相关的bug，这样是为了方便防止造数据所造成的时间浪费；也方便开发在测试协助的基础上快速定位bug；

2.针对一般bug跟踪，我们可以直接将问题记录到jira上，由开发根据我们的描述自己去复现和定位问题；

 

那言归正传，我们如何提一个有效的JIRA bug呢？我们主要归结关注为以下重要字段：

 BUG标题：

 要能简要说明问题

BUG重要性：https://blog.csdn.net/sunshine_mei/article/details/49230199

重要性分类参考如下：

BUG分类：

功能，需求，安全，性能，环境……

 

影响版本/解决版本：方便关联看板

影响版本：该bug是由哪个版本引起的

解决版本：该bug是在哪个版本中解决的

 

报告人/经办人/验证人

报告人：提出该bug的人

经办人：该bug由谁经办

验证人：该bug由谁验证

 

BUG描述包含如下：

【环境】：尽可能一句话描述让开发知道你的复现场景
xx测试环境/xx系统/xx浏览器等

 
【重现步骤】：尽可能根据描述用户可复现（举例如下）
1）进入测试环境社招后台
2）进入COE-招聘费用。
3）针对费用状态为“已确认”的候选人，点击【退回】。
4）输入退回理由后，点击确定
实际结果：该候选人状态未更新
预期结果：该候选人状态变更为【已退回】

【附件】：可贴上日志或者可复现文件或者其他的有效信