软件测试记录，是一项比较考验逻辑思维和想象力的工作。它既不像软件开发那样有实实在在的代码作为工作成果的展示，也没有BA那样，将软件需求拆分为story，就能够决定项目的走向。测试工程师的测试成果则没有那么明显，没有很容易可度量的成果展示，那么为了保证软件质量，同时也要知会给项目相关方，那么测试日报和测试报告就是非常重要的途径了。
测试日报和测试报告，在一定程度上是可以避免冗长的会议汇报，以及反复和项目相关方的沟通，体现了数据一次性报备，同时在原有邮件上全部回复式的更新，可以清晰地体现出测试工作的推进和版本的迭代情况。有助于未能深入了解项目的相关方，从基础数据入手来了解整个项目的运行。同时也避免了项目后期，对于一些用户发现bug的回溯被归因为测试漏测的情况。
一、测试日报
这是一个理论上可以使用Jira或禅道等项目管理软件，生成每日项目情况来进行替代的东东，但碍于各种原因，项目组内的干系人不一定能够及时获得这样的信息，那么对于同步项目进度，特别是测试进度，测试日报就显得非常重要了。
一个合格的测试日报，需要起到以下几种作用：告知测试进度；明确风险因素；现存bug列表中的内容；以及相关信息。
1）相关信息：包括项目的日期、开发测试人员名单、软件版本等等。
项目日期用于表明该项目所属的时间周期和时限，用于确定项目进度的阶段是否在项目周期范围内。
人员名单这个用于告知项目相关方，尤其是项目组之外的干系人，开发和测试分别是谁，这样需要了解具体情况的时候，可以直接找到具体对应的人。
而软件版本，则是用来确定当前的测试对象的版本，是否是目标版本，以及明确当前测试的测试对象。
2）测试进度：就是告知测试进程，一般以百分比表示。这个度量可以是测试工程师针对自己工作总量的比较，也可以是测试用例执行数量和总数量的比较，也可以是日程的进度百分比。作用是直观地体现测试进度，对于很注重项目进展的干系人，会有直观反馈。但其实在敏捷流程下，这个指标的意义并不明显。
3）现存Bug列表：一般包括Bug在Jira上的编号及链接，严重程度。这个列表是测试日报的核心，用于显示在当前测试周期内未关闭的bug都有哪些。需要注意的是，该列表在周期末未能归零，则当前Sprint是无法进入下一周期的。
这样就可以直观地看出来当前bug中，各个等级的bug占比，用于进行数据统计。
测试日报没有固定的格式，需要注意的几点：
1）测试活动进行的时候，当天才会有测试日报。
2）测试日报发送范围仅包括项目组和项目干系人。
3）如果项目采用的是敏捷流程，那么日报中的数据要能够和Jira的信息相互印证。
4）测试日报不用来体现开发问题，也不用来作为评价开发水平的依据。
以下是测试日报可以参考的模板：
二、测试报告
测试报告是针对一个项目结束，或者一个release节点完成了，针对该项目或者该节点阶段，进行的软件质量总结性的评价。
测试报告的形式也比较多，比较简单的是测试用例表格的执行结果记录，可一直接作为测试报告的内容；稍微复杂一点的，可以进行一些图表的列举，用以呈现在该周期内，质量数据的变化，这里就是对之前日报中bug严重程度占比的引用。各种变化的折线图、饼状图等等，都可以在报告中展示质量指标的变动。
和测试日报一样，在测试报告中，需要标明项目参与人员，测试环境的各项条件，软件版本区间，以及测试对象的拓扑结构。
形式最复杂的，涵盖内容最多的，可以称之为质量分析报告。在这里需要说明的是，质量分析报告仍然是聚焦于分析软件质量本身，而并不用于质量追责或者责任回溯。
质量分析报告中，需要对发现的bug进行归类和分析，用以分析出引发失效的原因，从整体上反映出来问题较为集中的模块，或者失效集中发生的原因，例如需求不够明晰、模块分离度不够，聚合度低耦合度高等。
以下是测试报告可以参考的模板：
测试日报和测试报告，乃至最后的质量分析报告，是测试工程师在项目中，可被直接认定的、可量化的工作输出，需要认真对待，特别是Jira和禅道等项目管理/缺陷生命周期管理软件的报表功能还没有得到充分利用的时候。这些是能够最直观呈现软件质量波动的有力武器，也是软件测试工程师的基本功体现。
版权声明：本文出自51Testing会员投稿，51Testing软件测试网及相关内容提供者拥有内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
