接口测试报告模板_扔掉模板——让你的测试报告有灵魂！

测试报告怎么写？这是一个从新手开始问，一直到老手还在困惑的问题。

对于新手来说，虽然随手就能拿到模板，但是模板里到底在说什么，到底要填写哪些信息？

对于老手来说，测试报告堆砌了一大堆数据，到底有什么用？

所以这篇文章，我们一起聊聊这个话题。

---

有结论的报告才有灵魂

我读过很多测试报告，也写过很多测试报告，这些测试报告中的绝大部分，都是没有灵魂的。

什么叫有灵魂？昨天我们讨论用例设计的时候说过，只有进行了设计，测试人员的工作才有意义。类似的，一个测试报告只有经过了深入的思考之后取舍，对读者产生了价值，才是有灵魂的。

但是这些报告，则是套用一个模板，按部就班的在模板中填充了内容。至于这些内容对读者到底意味着什么，编写者并不关心。

到底什么样的报告是有灵魂的？知乎上对测试报告有几个回答挺好玩儿的，我给大家摘录一下：

软件测试报告如何编写？​www.zhihu.com

张敬峰：测试报告装B指南​zhuanlan.zhihu.com

如何做一份精致的性能测试报告？​www.zhihu.com

第一篇是中规中矩的在介绍一个相对古老的测试报告模板，第二篇则是对一些测试报告的调侃，第三篇则是一个在线图表工具的软文。

假如你是一名项目经理，看到上面的报告是什么感觉？

至少我的感受是，看起来B格很高，但是我好像没看懂，我需要很费力的自己总结我想要的信息。

这就是因为报告编写的目的是展示自己的苦劳，甚至是炫耀自己的专业性，而不是满足报告的读者，所以读者看到的是眼花缭乱的炫技，大量数据的堆砌，有些还会有很多图表。然而这些到底意味着什么，没人知道，也没人信服。

一篇有灵魂的测试报告，一定是满足它最主要客户的期望的。

测试报告一般是给项目经理和项目的其他同事参考的，大家对测试人员最主要的期望就是保证产品质量。那么作为测试人员，你的使命就是回答这个问题：“你认为，这个产品的质量是行，还是不行”。如果你的测试报告简单到只有一句话，也应该是这个结论。

测试过程应当以得出这个结论为目的进行组织，测试团队投入了大量的资源，最终的成果就是这个结论。这也就是说，凡是对得出这个结论没有价值的活动都应当吝啬资源的投入，凡是对这个结论有价值的活动都应当充分保证资源。

但是哪怕作为高级测试工程师，有时候都不敢做出这个结论。这是因为往往测试所获得的资源不充分，测试人员对结论没有信心。但是，哪怕一个不充分的结论也比没有结论要好得多。一个不充分的结论是什么样呢？我们可以告诉项目经理，“我认为质量可以，但是我这个结论只有7成把握”。只有你能够给出这个结论，项目经理才能得出他的结论“这个产品，上还是不上”。

这可以说是测试人员的终极使命，你完成了这个，你才是项目经理信得过的守门员。

所以，对于测试报告来说，我建议第一个段落就应该开篇明义，“我们现在的产品是啥，我们的结论是啥”，然后才是解释和说明这个结论的内容。

---

让你的结论有说服力

明确了结论之后，读者要么认同这个结论，要么不认同这个结论。无论是否认同，大家都想知道，你凭什么做出这个结论的。或者说，你的这个结论到底是否有说服力。因此，下面的内容应当是解释我们这个结论的说服力的。

那么，我们以专业的测试人员的身份想一想，一个结论要能说服我们，我们需要它有什么样的证据？

软件测试是一个评估过程，评估的手段是

1. 分析测试对象特点
2. 确认测试策略
3. 选择测试方法
4. 设计测试用例
5. 执行测试用例
6. 记录缺陷。

这个过程的每一个环节都有可能出问题，导致最终的结论失效。

但是如果你按照这个思路写下去，除非专业的测试人员，否则大家不仅看不懂，也没兴趣。这一大堆东西与那个结论对读者来说意义差不多，就是自说自话。

那一般人能理解的逻辑过程是啥呢？就是我之前说的那两点：

1. 用户的关键业务
2. 严重的事故

你只需要从这两个角度对系统进行分析（测试分析），然后告诉大家我们是怎么设计的测试，重点是啥（测试设计），实际执行的过程中难点是啥，最终搞定了哪些没搞定哪些（测试执行），系统里还有啥坑（风险预估）。

大家就看懂了。

例如，针对我之前的那个迁移，你可以这么说：

本次变更的特点有三个，优先级依次降低：

1. 本次迁移的是一次系统接口的迁移，迁移前后用户的感受是不变的，因此主流程的回归是一个重点；
2. 由于注册流程比较长，没走完的那些工单就可能出问题，因此我们要注意这类未完成工单；
3. 由于这个接口比较老，客户接入的情况也未必标准，可能有很多坑，所以需要对重点客户的历史数据进行分析，避免他们无法使用。

我们针对这三个部分有针对性的设计了测试用例。第一部分的设计思路是XXX，方法是XXX，覆盖非常全面，第二部分相对全面，第三部分只选取了TOP3的商户进行研究。

最终执行的情况是，第一部分100%执行，发现问题XXX，基本上不会有什么问题；第二部分XXX。第三部分XXX。

综上所述，我认为本次迁移的质量足以满足要求，不会影响用户的关键业务或者产生严重生产事故。

---

好的报告是窗口

一篇好的测试报告，能够让团队认识你，了解你的工作，信任你的结论。

写好一篇测试报告，与测试人员对团队期望、自己的使命和定位的理解是分不开的。昨天的文章里有个朋友问，“自己提的bug没人理怎么办？”这是一个测试人员经常会遇到的困境，这往往意味着测试人员并没有获得团队的信任——他自己认为的问题并不是团队认为的问题，换句话说，凡是遇到这样困境的人，都没有在团队中寻找到自己的位置。

我在上面只是以测试过程收尾后的报告作为例子。事实上，一个测试人员要写的报告有很多种，测试需求分析报告、用例设计报告、缺陷报告；日、周、月报、团队季、月、年度总结报告；分享报告、技术文章、评审报告等等。

所有的这些报告都是你向外展示自己的窗口，通过这些报告，可以看出来你的信念、思维、格局。往往这些字面之下的内容决定了你在团队里到底混得怎么样，大家是否信任你重视你。

每个人都会受限于自己的岗位、知识而过分关注自己的一亩三分地，忘记了团队的目标，测试人员相对于开发人员，天然的拥有用户视角，天然的贴近客户，就更应该时刻记得团队目标，用团队总体的格局来影响和感召团队的成员。

所以，测试人员应当拥有自己的骄傲，你在团队的定位与别人不一样，你不是来混日子的，你是来帮助团队和团队一起成功的。希望我的读者都能够发挥自己的优势，寻找到自己的价值所在，为你的团队注入灵魂。