扔掉模板——让你的测试报告有灵魂!

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

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

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

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

有结论的报告才有灵魂

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

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

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

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

软件测试报告如何编写?

张敬峰:测试报告装B指南

如何做一份精致的性能测试报告?

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

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

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

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

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

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

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

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

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

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

让你的结论有说服力

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

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

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

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

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

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

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

1.用户的关键业务

2.严重的事故

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

大家就看懂了。

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

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

上一页12下一页


留言