测试报告怎么写？这是一个从新手开始问，一直到老手还在困惑的问题。
对于新手来说，虽然随手就能拿到模板，但是模板里到底在说什么，到底要填写哪些信息？
对于老手来说，测试报告堆砌了一大堆数据，到底有什么用？
所以这篇文章，我们一起聊聊这个话题。
有结论的报告才有灵魂
我读过很多测试报告，也写过很多测试报告，这些测试报告中的绝大部分，都是没有灵魂的。
什么叫有灵魂？我们讨论用例设计的时候说过，只有进行了设计，测试人员的工作才有意义。类似的，一个测试报告只有经过了深入的思考之后取舍，对读者产生了价值，才是有灵魂的。
但是这些报告，则是套用一个模板，按部就班的在模板中填充了内容。至于这些内容对读者到底意味着什么，编写者并不关心。
到底什么样的报告是有灵魂的？知乎上对测试报告有几个回答挺好玩儿的，我给大家摘录一下：
软件测试报告如何编写？
张敬峰：测试报告装B指南
如何做一份精致的性能测试报告？
第一篇是中规中矩的在介绍一个相对古老的测试报告模板，第二篇则是对一些测试报告的调侃，第三篇则是一个在线图表工具的软文。
假如你是一名项目经理，看到上面的报告是什么感觉？
至少我的感受是，看起来B格很高，但是我好像没看懂，我需要很费力的自己总结我想要的信息。
这就是因为报告编写的目的是展示自己的苦劳，甚至是炫耀自己的专业性，而不是满足报告的读者，所以读者看到的是眼花缭乱的炫技，大量数据的堆砌，有些还会有很多图表。然而这些到底意味着什么，没人知道，也没人信服。
一篇有灵魂的测试报告，一定是满足它最主要客户的期望的。
测试报告一般是给项目经理和项目的其他同事参考的，大家对测试人员最主要的期望就是保证产品质量。那么作为测试人员，你的使命就是回答这个问题：“你认为，这个产品的质量是行，还是不行”。如果你的测试报告简单到只有一句话，也应该是这个结论。
测试过程应当以得出这个结论为目的进行组织，测试团队投入了大量的资源，最终的成果就是这个结论。这也就是说，凡是对得出这个结论没有价值的活动都应当吝啬资源的投入，凡是对这个结论有价值的活动都应当充分保证资源。
但是哪怕作为高级测试工程师，有时候都不敢做出这个结论。这是因为往往测试所获得的资源不充分，测试人员对结论没有信心。但是，哪怕一个不充分的结论也比没有结论要好得多。一个不充分的结论是什么样呢？我们可以告诉项目经理，“我认为质量可以，但是我这个结论只有7成把握”。只有你能够给出这个结论，项目经理才能得出他的结论“这个产品，上还是不上”。
这可以说是测试人员的终极使命，你完成了这个，你才是项目经理信得过的守门员。
所以，对于测试报告来说，我建议第一个段落就应该开篇明义，“我们现在的产品是啥，我们的结论是啥”，然后才是解释和说明这个结论的内容。
让你的结论有说服力
明确了结论之后，读者要么认同这个结论，要么不认同这个结论。无论是否认同，大家都想知道，你凭什么做出这个结论的。或者说，你的这个结论到底是否有说服力。因此，下面的内容应当是解释我们这个结论的说服力的。
那么，我们以专业的测试人员的身份想一想，一个结论要能说服我们，我们需要它有什么样的证据？
软件测试是一个评估过程，评估的手段是
1.分析测试对象特点
2.确认测试策略
3.选择测试方法
4.设计测试用例
5.执行测试用例
6.记录缺陷。
这个过程的每一个环节都有可能出问题，导致最终的结论失效。
但是如果你按照这个思路写下去，除非专业的测试人员，否则大家不仅看不懂，也没兴趣。这一大堆东西与那个结论对读者来说意义差不多，就是自说自话。
那一般人能理解的逻辑过程是啥呢？就是我之前说的那两点：
1.用户的关键业务
2.严重的事故
你只需要从这两个角度对系统进行分析（测试分析），然后告诉大家我们是怎么设计的测试，重点是啥（测试设计），实际执行的过程中难点是啥，最终搞定了哪些没搞定哪些（测试执行），系统里还有啥坑（风险预估）。
大家就看懂了。
例如，针对我之前的那个迁移，你可以这么说：
本次变更的特点有三个，优先级依次降低：