最近看到一篇关于测试报告的不错的文章，是有英文的，这个难不倒我们吧~
编写高质量 bug 报告，是和开发人员高效和愉快的协作、共同提高代码的质量的一个前提~
「原创声明：保留所有权利，禁止转载」
标题写错了 不是测试报告 是 BUG 报告
看了下原文，感觉有点啰嗦。。。
一、如何重现 （操作步骤、预期结果、实际结果）
二、环境说明（机型、账号、网络）
三、现象截图或视频
四、请上传日志附件
内容上，我觉得基本有这几个就差不多了。至于优先级、分配人、bug 状态这些，基本上大部分缺陷管理系统都有，不大需要特别强调。
我觉得最基本的，是提供足够让开发本地自行重现此问题所需的信息；进一步的可以通过日志甚至具体代码逻辑等，提供有助于开发定位及解决问题的信息；终极的话，直接附上修复 MR 给开发 review 。
最痛恨那些啥也不写，一图流的。除非有另外沟通过开发知道怎么回事，否则真的是一脸懵逼，别人想协助回归验证下，都看不懂是啥 bug 。
通篇读下来感觉应该是如何提出一个好的 bug 给开发
测试真是太难了
这说的是如何提 BUG。。。并不是测试报告。
进来前：拷贝忍者又可以 copy 一份模版了
进来后：？？？
接口的测试报告呢
没看懂 有没有中文版的？
讲的是如果提 bug