一
1 月 27 号，我在编辑公众号文章时，发现了微信公众号的一个前端显示 bug，就顺手给贴到一个测试论坛上，因为不是自己产品的 bug，所以就想着有腾讯的人看到可以自己去跟进来着。
结果等了几天都没动静，直到第三天，也就是 1 月 30 号，终于有一个坛友肉身帮忙重现，竟然发现问题不重现了，我勒个去。
其实她一开始给我说没有这个问题时，我还是不相信的，毕竟我在提 bug 前反复验证过，并且给出了必现步骤，以及其他关联场景的验证结果，但是，我再次去验证时，竟然真的不重现了。
这真是哑巴吃黄连，有苦说不出，搞的我是个坑逼一样，做测试嘛，最不爽的就是被开发质疑，现在好了，被同行质疑了。
其实对于提交 bug 的标准，我一直都有在团队进行强调，并且以身作则，但是大部分都是针对可以联系到开发的情况，至少说是有一个可以沟通的环境的（可以当面沟通，或者拿代码说话），不像是这次，就算怀疑是被偷偷修复了，我也找不到人去确认。
所以我顺手把之前的标准做了下改进，把本次问题的情况也可以涵盖进去，自己踩过的坑，就算给其他人垫背了。
二
我细化的标准如下（以 Bug 描述为主）：
1.Bug 标题清晰易懂，标准是一眼就明白需要反馈的问题；
2.提供必现的操作步骤（如果有的话），记得按第三方的角度去进行描述，最好自己可以按描述无脑操作一遍试试；
3.进行关联场景的验证，尽可能确定出现问题的关键要素，可以把验证过的场景都补充到 bug 说明中；
4.确定关键要素后，尽可能的去定位问题出现的技术原因，避免只是简单的现象描述；
5.就算问题很明显，也需要截图为证，必要的时候进行录屏；
三
下面继续用我本次提交的 bug 做个实例讲解：
1.我的 Bug 标题是「微信公众号文章内超链接没有对标题中的空格进行转义」。
这个标题还算言简意赅，懂技术的应该能一眼就看出来问题所在，毕竟我都说了转义的问题了，扒一下代码就可以确认了，所以我觉得标题是达标的；
2.我提供的必现步骤也是自己实际确认过的，特别是第三步，如果是我自己操作的话，我其实是点击「从本公众号已群发的消息中进行选择」链接来获取我的公众号文章列表的，但是为了方便第三方重现，我特意改成用公众号名称搜索的方式，因为我确认过，两个路径操作的结果相同，当然，也可能因此被怀疑是做宣传用的，那就只能加个括号备注了，很无奈；
3.公众号文章内添加链接一共有三个路径，一个是直接贴链接，一个是搜索公众号再搜文章，还有一个是从自己公众号文章列表选取，后面两个方式就是出问题的情况，我在重现步骤中已经描述了，为了缩小范围，所以我在 PS 里补充了第一种情况的操作结果；
4.这个是本次要说的重点，如果是我们自己的业务，说到 html 字符转义，开发肯定就能明白了，所以我也就没有去进一步确认，现在想起来，如果自己有这个能力的话，不管是不是自己的业务，都可以去把问题定位到根本的技术实现细节上，开发只需要秒改就行了；
5.截图为证这个我也是有的，一般无图无真相，这个道理大家都是懂的，但是有图还不承认，这个就涉及到人品问题了，如果有测试故意伪造环境谎报 bug，我觉得可以直接开除，反正我还没碰到过，如果有开发偷偷修复问题后不承认问题的存在，我绝对会找他当面拿代码对质，并且不再相信他的代码质量，真的，这不是技术问题，这是人品问题，比技术问题要严重的多，当然，为了避免扯皮，在提交一些不能被及时处理的 bug 时，我们可以加上录屏；
四
好了，事情已经很明朗了，主要原因就是我没有提供技术问题的实锤，同样的错误不能犯两次，希望我这次的教训也能给你带来启发，如果觉得我把这件事说明白了，请点「好看」让我知道。
以上，希望对你有所帮助，有任何问题欢迎留言和我沟通。
标签：正确,公众,bug,问题,有效,重现,文章,Bug 来源： https://blog.51cto.com/sylan215/2919789
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。