一

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 时，我们可以加上录屏；

四

好了，事情已经很明朗了，主要原因就是我没有提供技术问题的实锤，同样的错误不能犯两次，希望我这次的教训也能给你带来启发。

以上，希望对你有所帮助，有任何问题欢迎留言和我沟通。