认识达内从这里开始

今天分享一下以前在带领团队过程中，测试人员编写软件测试报告常见的疏漏，以便大家避免，更好让测试成果呈现给客户（可能是自己的领导，也可能是用户，后文统称为客户）。

文档模板的使用

往往公司模板更新换代了，但测试人员仍然在沿用原来的模板。轻则说明你粗心，重则说明你不关心公司的变化、磨洋工。曾经笔者下面遇到过真实的例子，有一同事使用旧文档模板，但实际公司的名字和Logo都发生了变化，发送到产品经理，后果肯定是测试报告被打回，并通报批评。如果极端点，测试报告放到更高层，如公司主要领导，那后果和影响不言而喻。

修订记录应该在首页后标示清楚

修订记录，是自己劳动成果的过程记录，这点也是测试人员容易忽视的地方。有的测试人员，每次提交的测试报告，修订记录都只有一条。实际测试报告应该是有审查和修订过程的，比如你在发出测试报告之前，通常都应给测试经理审查过目，往往过后还会有些问题修订。如果不标识清楚，那么可能提出的一些特别要求，会让报告显得用了较长时间。这可能让公司高层客户认为你的能力不行，也不能让外部（如ISO审查组织）了解你们的工作合规性。修订记录主要包括：修改时间、版本号、修订人、修订内容及审查人。

内容应该清晰易懂，简明扼要

不要把测试报告的内容写成一篇中篇小说。各种修饰词，流水话一大堆，导致看的人雾里看花，似是而非。我看过有把测试报告写成文章的，通篇报告都是文字，我认为、我想、他们应该等一大堆称谓词，然后草草下个结论，让人不明所以。

测试报告应该尽量避免主观看法，加入一堆的主观认识。而应该客观的、简明扼要的把过程表述清楚。并且尽可能结合图文和表格辅以说明。这样的测试报告才令人赏心悦目，也让人一目了然，从而把测试结果很好的呈现给客户。

绝不放过一个错字

软件测试人员应该是一群吹毛求疵的人，如果自己的报告中有一堆错别字，哪怕是一个错别字，可能都会尴尬难堪。原来就有同事非常粗心，导致测试报告出现多个错别字。而开发人员一句"平时找bug时，连一个错别字都被你单独列为一个bug，XX，你看你文档有好多bug"，这个测试人员闹得非常尴尬。很好的做法就是，写完测试报告后，自己一定要通篇检查一到两遍，这样严格要求自己，才能去高要求别人。

没有闭环的bug，哪怕是往期版本遗留的bug，都应该罗列出来

往往测试人员在一些外部压力下，容易把承诺修改但还来不及验证的bug在测试报告中抹去，或者有意疏漏。但这样不呈现出来，一发出去，可能高层不知道具体情况而做出错误的决策，导致后期出现人为的事故。如以前碰到过软件系统的一小工具，因为使用频率不高，所以bug经测试经理、开发经理和项目经理达成一致意见延期修复，但测试人员没有在测试报告中把这些bug呈现出来，导致市场人员在给用户演示时为了说明系统的强大，从而错误的展示了该有bug的工具，以至在用户面前出现冷场。更极端的结果可能是，用户拒绝采用该系统。所以我们在测试报告中，应该把没有闭环的bug，哪怕是往期版本遗留的bug，都应该详细罗列出来。这样才能让高层或推广部门的同事进行规避或作出应对措施。

产出成果恰当呈现

这一环常常是大家极容易忽视的一环。往往测试人员的做法是，报告写好了直接发送一封带附件的邮件给客户，好点的可能会加几行文字。但是，我想说，除了你的直接领导、平级同事外，其他客户往往是没有太多时间和耐心下载附件并仔细查看你的报告的，他们关心的是"现在的软件质量到底如何，是否能放给用户使用"。很好的做法是在邮件内容页开头，写上测试结论、问题建议，并可以把主要的测试结果统计放在后面，然后才是附上完整测试报告的附件。

写一份测试报告不难，要写好一份合格高质量的报告需要我们花费更多的心思。

更多内容请关注【广州IT培训学校】