主题：如何书写测试报告 领导们通常是很关注测试的，因为通常只有测试团队才能够提供项目所处的真正位置。这种位置感来源于模块的成熟度、稳定度和主要问题列表。这种信息，我们叫它项目的可视性信息。可视性信息可以分为两类：
1）对内的信息汇总，以测试日志为典型，记录每个测试工程师一天的进度、发现和困难，上报给测试经理；
2）对外的信息发布，以测试报告为典型。测试经理汇总测试的数据和信息，作为项目进度和状态的重要标识上报给项目管理者。
一、测试日志（Test Log）
测试日志是帮助测试经理获取测试信息的重要途径，它的发布者是测试团队中的每一个成员，测试日志的读者是测试经理，而在规模大一些的测试团队中，可能是测试小组的组长。测试日志的使命是让测试经理了解自己团队的状况。
二、测试报告（Test Report）——言简意赅、图文并茂
测试报告写作的七大原则：
（1）字数要够少够精炼
用最少的篇幅和最简单的结构同时传达出所有的关键信息，这才是测试报告应该做的事。
1、首先要减少说废话套话，和测试无关的语言越少越好；
2、其次要避免过于细节，在报告后面可以尽情地添加附件来提供详细的信息，给求知欲强的人留有进一步专研的空间；
3、最后，信息要分层派送，比如封面上三句话说出你最想说的心里话，中间的内容把这三点展开来说，最后的封底处作出你作为测试人员对待测软件的评价和结论。
（2）图表要够多够通俗
1、饼图比大小（软件遗留问题模块分布）
2、柱图比高矮（各测试组发现问题个数）
3、曲线图上蹿下跳（软件稳定度的变化，问题解决率的变化，测试用例通过率的变化）
4、面积图比胖瘦（遗留问题的解决趋势）
5、图表要用的正确才有效
项目管理者关注的大部分东西都有合适的图表来表示：
1、总体成熟度和子模块的成熟度：成熟度的计算方式有很多，其中最简单的是统计测试用例的通过率，我们在上面讲曲线图的时候有例子。
2、缺陷分布：各种模块内遗留的问题数目及其比例，能帮助读者大略了解各个模块的稳定程度，饼图就是个很好的例子。
3、缺陷趋势：成熟度的变化趋势，从中可以看出软件质量的走向，也是那个曲线图的例子。
4、问题解决趋势，这是个很有用的关注点，从中可以看出问题解决的速度和趋势。当问题解决的速度下降的时候，能够及时向管理层报警提起重视，面积图的例子讲的就是这方面的东西。
图表能够标出各测试组或测试工程师的效率和进度，以便及时发现暗藏的问题，避免进度受影响；图表还能显示出各模块问题数和测试用例通过率的关系。
（3）颜色鲜艳，通俗易懂
绿色代表一切正常，红色代表糟糕，黄色代表不好说。在测试报告中用绿色表示稳定的模块，红色表示有问题的模块。
（4）既报喜又报忧，汇总出最严重的问题
在测试报告中列出未解决的TOP10严重故障。评审的对象之一就是剩余的严重问题都有哪些，以及产品带着这些问题上市的风险有多大，测试人员公正和客观的评价将是一个重要的参考。
（5）报告时间要及时
测试报告是为了让项目的管理者在第一时间了解项目的状态，因此报告的时间不能拖拖拉拉，新闻变成了旧闻就不值钱了。根据报告的重要程度和所做测试量的大小，测试报告准备的时间也应当不一样。
（6）罗列的数据准确有力
测试关注质量，但如果测试本身的质量无法保证，那测试还不如不做。测试内部需要建立抽查机制：
1、抽查应该成为一种持续的压力，不能搞献礼工程；
2、抽查的比例要事先约定，根据是抽查的工作量和可投入的人力等；
3、执行抽查的人必须有经验或者够权威，否则抽查出问题以后必将导致无休止的争论。
4、参考以往的趋势（比如：测试用例通过率变化明显部分抽查）
（7）逻辑要经得起推敲
测试报告中要做出很多结论，要注意结论的逻辑必须经得起推敲，做出的结论要有说服力。
版权声明：本文出自 hellorenwei 的51Testing软件测试博客：http://www.51testing.com/?578951
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
《笑傲测试》笔记（前言+第一式：庐山面目）
《笑傲测试》笔记（第二式：蓬门始开）
《笑傲测试》笔记（第四式：矫如龙翔）
《笑傲测试》笔记（第五式：浮云遮日）
《笑傲测试》笔记（第六式：伯仲伊吕）