测试基本功——日报和报告的编写

lsekfe

软件测试记录，是一项比较考验逻辑思维和想象力的工作。它既不像软件开发那样有实实在在的代码作为工作成果的展示，也没有BA那样，将软件需求拆分为story，就能够决定项目的走向。测试工程师的测试成果则没有那么明显，没有很容易可度量的成果展示，那么为了保证软件质量，同时也要知会给项目相关方，那么测试日报和测试报告就是非常重要的途径了。

测试日报和测试报告，在一定程度上是可以避免冗长的会议汇报，以及反复和项目相关方的沟通，体现了数据一次性报备，同时在原有邮件上全部回复式的更新，可以清晰地体现出测试工作的推进和版本的迭代情况。有助于未能深入了解项目的相关方，从基础数据入手来了解整个项目的运行。同时也避免了项目后期，对于一些用户发现bug的回溯被归因为测试漏测的情况。

一、测试日报

这是一个理论上可以使用Jira或禅道等项目管理软件，生成每日项目情况来进行替代的东东，但碍于各种原因，项目组内的干系人不一定能够及时获得这样的信息，那么对于同步项目进度，特别是测试进度，测试日报就显得非常重要了。

一个合格的测试日报，需要起到以下几种作用：告知测试进度；明确风险因素；现存bug列表中的内容；以及相关信息。

1） 相关信息：包括项目的日期、开发测试人员名单、软件版本等等。

项目日期用于表明该项目所属的时间周期和时限，用于确定项目进度的阶段是否在项目周期范围内。

人员名单这个用于告知项目相关方，尤其是项目组之外的干系人，开发和测试分别是谁，这样需要了解具体情况的时候，可以直接找到具体对应的人。

而软件版本，则是用来确定当前的测试对象的版本，是否是目标版本，以及明确当前测试的测试对象。

2） 测试进度：就是告知测试进程，一般以百分比表示。这个度量可以是测试工程师针对自己工作总量的比较，也可以是测试用例执行数量和总数量的比较，也可以是日程的进度百分比。作用是直观地体现测试进度，对于很注重项目进展的干系人，会有直观反馈。但其实在敏捷流程下，这个指标的意义并不明显。

3） 现存Bug列表：一般包括Bug在Jira上的编号及链接，严重程度。这个列表是测试日报的核心，用于显示在当前测试周期内未关闭的bug都有哪些。需要注意的是，该列表在周期末未能归零，则当前Sprint是无法进入下一周期的。

这样就可以直观地看出来当前bug中，各个等级的bug占比，用于进行数据统计。

测试日报没有固定的格式，需要注意的几点：

1） 测试活动进行的时候，当天才会有测试日报

2） 测试日报发送范围仅包括项目组和项目干系人

3） 如果项目采用的是敏捷流程，那么日报中的数据要能够和Jira的信息相互印证

4） 测试日报不用来体现开发问题，也不用来作为评价开发水平的依据

以下是测试日报可以参考的模板：

202X年XX月XX日ABCDEF项目日报
软件版本（如果有嵌入式或涉及多软件，需要列出每个软件模块的版本）:
测试工程师：
风险：（未能按时转测，转测版本被多次打回，测试周境对测试工作的影响等等）
今天发现了X个bug，其中严重及以上为X个，占比XX% 或 现存bug XX个，其中严重及以上为X个，占比XX%，列表如下:
序号	Bug编号（Jira编号）	严重级别	Bug链接
1
2

二、测试报告

测试报告是针对一个项目结束，或者一个release节点完成了，针对该项目或者该节点阶段，进行的软件质量总结性的评价。

测试报告的形式也比较多，比较简单的是测试用例表格的执行结果记录，可一直接作为测试报告的内容；稍微复杂一点的，可以进行一些图表的列举，用以呈现在该周期内，质量数据的变化，这里就是对之前日报中bug严重程度占比的引用。各种变化的折线图、饼状图等等，都可以在报告中展示质量指标的变动。

和测试日报一样，在测试报告中，需要标明项目参与人员，测试环境的各项条件，软件版本区间，以及测试对象的拓扑结构。

形式最复杂的，涵盖内容最多的，可以称之为质量分析报告。在这里需要说明的是，质量分析报告仍然是聚焦于分析软件质量本身，而并不用于质量追责或者责任回溯。

质量分析报告中，需要对发现的bug进行归类和分析，用以分析出引发失效的原因，从整体上反映出来问题较为集中的模块，或者失效集中发生的原因，例如需求不够明晰、模块分离度不够，聚合度低耦合度高等。

以下是测试报告可以参考的模板：

XXXX项目节点发布/最终发布测试报告

项目周期： 20XX年X月X日-20XX年X月X日

项目测试工程师：

说明：本报告主要作为情况分析和问题定位，不用做责任回溯

一、Bug分析    （本节内容主要分析以下几个点：    1. 各个Sprint的bug数量变动折线图，同时还要有严重及以上bug的占比折线图    2. 按照一定模块顺序进行逐个分析，列出各个模块bug集中的柱状图，例如前端、后端、中台，或者软件的模块A、B、C等)

二、风险分析：    （本节内容主要包括在本次或本轮release中，所有容易产生风险和质量问题的缺陷，例如未能按时提测，需求细节未能澄清，临时的需求变更，测试范围的变动，人员的变动等等）

二、项目建议    （本节内容说明项目组在两个milestone间或者整个研发过程中，可以延续的工作措施和内容，可以提高的方面或者领域）

测试日报和测试报告，乃至最后的质量分析报告，是测试工程师在项目中，可被直接认定的、可量化的工作输出，需要认真对待，特别是Jira和禅道等项目管理/缺陷生命周期管理软件的报表功能还没有得到充分利用的时候。这些是能够最直观呈现软件质量波动的有力武器，也是软件测试工程师的基本功体现。

岳妙慧