标签：检查 处理 是否 开发人员 复现 测试 bug 测试环境

1.设计如此

1. 找相关证据证明这是bug : 检查测试用例是否明确写出这种情况是bug,检查需求文档是否明确写出这种情况是bug
2. 如果没有直接证据，想一下自己为什么认为这是bug？有哪些地方不合理,对用户有什么样的影响,竞争产品，行业龙头是怎么做的？
3. 3.拿着自己的理由跟测试经理讲，争取测试经理的认可,再跟产品经理讲,拿着产品经理的聊天记录，跟开发讲

2.无法重现

1. 按照bug的描述自己重新操作一遍， 检查这个bug是否还复现
2. 如果还复现，那么检查bug描述是否足够清晰

   1.影响版本
   2.测试环境
       1)在哪些测试环境上复现
       2)在哪些测试环境上不复现
       3)你测过哪些环境都写出来
   3.如果不复现了，是手机app的话，那么在当时测试的版本，当时测试的环境，重新操作
   4.如果不复现，是web的话，可能没办法回到之前的版本上测试
       1)提bug是要截图证明
       2)用charles抓包，上传到缺陷附件中　
   

3. 重复bug

   1.检查主bug和你的bug是不是描述同一个问题
   2.检查主bug和你的bug是谁先提交 : 先提交的bug是主bug
   3.等主bug关闭以后，再校验一次，检查自己的bug是否已经修好了
   

3.最后确认不是bug的话，要记录bug，并分享给整个测试组

4.避免以后别人测试，仍然认为这是一个bug，重复提交

5.现在认为不是bug，上线以后，用户可能会反馈这个问题， 可能又会认为这是bug，项目经理可以调查为什么漏掉这个bug

标签：检查,处理,是否,开发人员,复现,测试,bug,测试环境
来源： https://www.cnblogs.com/shuheng/p/16516150.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。