测试报告踩坑的点

多测师12

　　测试报告作为测试人员的核心输出项，是体现自己工作价值的重要承载工具，需要我们认真对待，所以我们要重视测试报告的输出，那么在编写测试报告的时候，我们有哪些点需要注意的呢?
　　01 不要乱用模板
　　很多测试新人在编写测试报告时，都会去找别人要一份所谓的测试报告模板，总感觉别人的报告是好的，而没有考虑到自己团队的实际情况，不是说不能套用模块，这里有两个小坑需要注意下：
　　页眉页脚：在正规的公司里，对于文档的页眉页脚都有会明确的要求。但我们的阅读习惯又是会把这块内容隐藏起来。这就会导致你在套用模板的时候，忽略了这部分内容的修改，笔者曾经阅读过一份测试报告，页眉页脚上的说明和Logo竟然是别的公司，这就很尴尬了。
　　空白标题：模板一般会讲究大而全，所以会有很多标题项，给到有需要的人去填写，比如项目背景、术语解释等，但是这些内容是需要根据实际情况去做裁剪的。但新手们可能不知道怎么写，就放在那里，也不删除。笔者见过一份测试报告，里面有2~3项只有标题而没有内容，你是想让读者给你补上么?
　　02 没有明确测试范围
　　在测试报告中，我们需要明确的给出测试范围是哪些，如果版本的内容较多，可以适当的简写，但不能不写。产品给的版本内容好比是预售出去的火车票。而测试报告中的测试范围，就是上车前的检票环节，要对齐，不能有缺失，也尽量不能有夹带，否则火车可能会失控。
　　变更的点要明确出来：如果版本周期比较长，或者在研发过程中需求发生了变化，需要在测试范围中明确的标注出来，让阅读报告的人能够清楚的知道哪些点是做过变更的，有助于他们评估影响范围。
　　裁剪的要特别明确出来：由于各种原因，原来计划的功能或者需求没有得到实现，被裁剪的功能要特别的明确标注出来，让大家清楚的知道最终上线的是哪些内容。避免因为信息不对称引发误解。


　　​
　　03 内容描述不清晰
　　不要把测试报告的内容写成一篇中篇小说。各种修饰词，流水话一大堆，导致看的人雾里看花，似是而非。我看过有把测试报告写成文章的，通篇报告都是文字，我认为、我想、他们应该等一大堆称谓词，最后草草下个结论，让人不明所以。
　　测试报告应该尽量避免主观看法，加入一堆的主观认识。而应该客观的、简明扼要的把过程表述清楚。并且尽可能结合图文和表格辅以说明。这样的测试报告才令人赏心悦目，也让人一目了然，从而把测试结果很好的呈现给客户。
　　04 没有风险说明
　　这点是在测试报告经常被忽略但又非常重要的一个点。在一些核心版本、变更较大的版本中，我们需要明确给出一些风险项，最好能给出必要的解决方案或者应对方法。常见的风险一般会有以下几类：
　　缺陷遗留风险：有些版本缺陷并会被完全修复，那么遗留缺陷的风险是什么，如何应对，是否需要对外统一话述等。
　　测试策略风险：在测试时间紧张、业务功能特别复杂的场景中，我们使用了特定的测试策略，可能引发或者遗留的风险项是什么，是否做好了预案。
　　发布升级风险：重要的变更、涉及历史数据迁移、中间件版本升级等内容时，除了做好全面的验证外，还需要给出必要的回退方案。
　　业务风险：是否依赖其它子系统的同步升级配合，是否有第三方系统参与升级，新业务带来的用户操作变更是否做好了对应的培训或者有对应的操作文档(特别是To B的产品)，是否预留了用户意见反馈通道等等。
　　05 没有测试结论
　　你见过没有测试结论的测试报告么?嗯，我见过。给某个版本的测试工作下结论是需要非常谨慎的，因为你需要对测试结论负责(很多人忽略了这一点，然后就被甩锅了)。在结合测试过程和测试风险后，我们需要给出明确的测试结论：通过、不通过、有条件通过(某些功能被裁剪了，或者某些场景是通过Mock等方式能过的，可能存在风险)。谁说测试结论一定要是通过呢?
　　在编写测试报告时，还有些小坑需要特别注意的，比如： 不能有错别字、排版要规范、图表要清晰等，不要让这些小细节让别人对整个测试报告留下不好映象。
　　06 小结
　　一份好的测试报告至少应当包含以下几点内容：
　　测试范围：你最终的测试范围是什么，覆盖了哪些功能点。哪些是原来迭代规划的，哪些是临时增加的，又有哪些转动了下个迭代中。这些都是需要明确出来的，看报告的人并不一定会全程参与到研发过程中，所以需要你的测试报告来体现真实的迭代内容是什么。
　　测试结论：从测试人员专业的角度，给出迭代的质量评估，是否达到了发布标准，是否可以发布，如果不能，说清楚原因。
　　测试风险：在测试过程中遇的考虑到的风险，上线后可能发生的风险，如果你知道，请明确出来，让团队各角色(研发、产品、部门负责人等)根据你的风险分析，一起来决定是否发布版本。
　　当然，测试报告不仅仅只包含以上内容，但是以上内容是看报告的人最注的内容，除此以外，还应该包含但不限于测试策略、人员投入、BUG分析(对研发团队很重要)、测试改进意见等等。