构建实用测试报告-CSDN博客

本文链接：https://blog.csdn.net/weixin_42007999/article/details/132451366

不要捉急于寻找测试报告的模板，别人的测试报告不一定适合你的组织
组织处于不同的阶段和成熟度，其测试报告的内容和重点也不尽相同
测试报告除了记录的性质，是否可以将管理思路、推动工作重点与之相结合

测试报告中可以引入很多内容：记录测试过程、人员分工、中间结果、重要事件追溯、质量评价、测试结果分析等等，按需添加。

一个项目结束后测试部门无论是否有硬性的要求，都应该出具一份标准的、完备的测试报告，即体现了测试的价值又呈现了合规性。

还应尽量避免项目结束后为了应付流程而草草的编写测试报告，建议可以在测试过程中通过节点式控制，由该项目的测试执行人员，渐进式记录并 “积累” 出一份测试报告。

1. 前言

从理论上讲，一个完整的测试活动主要产出包括《测试计划》、《测试方案》、《测试用例》、《缺陷报告》、《测试报告》等等，而对于一些中小型组织或团队而言，每个项目都完成这么多文档几乎是难以达成，或者即便有也质量不佳。

对于一般测试人员而言，只需要关注测试用例的编写、执行和缺陷报告的提交即可。

对于测试部门管理者而言，除了部门日常管理，还要争取获得组织对自己部门业绩的认可，这就需要一定数据、文档的支撑：

随时能看到各个项目的测试人员安排、当前工作内容和进度；
各项目在不同测试阶段的测试结果，是否产生了质量风险；
各个项目的最终质量评价如何，如何通过质量评价持续推进质量的改进；
重大问题部门间相互扯皮、推诿时，是否能及时拿出最有利的证据；
当前流程规范是否合理，是否有改进的地方，人员是否按照规范实施测试。

以上种种数据和分析加起来工作量着实不小，单靠某个人根本难以实现。所以我们希望尽可能通过团队协作的方式，在一份统一的模板中，由项目测试成员，平时按节点记录测试过程，项目结束后正好可以生成一份详尽的测试报告。这是一个积少成多的过程，其实分配到每个人身上的工作量不大，不会产生过多的抱怨，但最终的测试报告确是详尽可追溯的。

当然测试报告中的内容要尽量精简务实，避免过多的额外任务，而且这些需要通过一些平台来实现，并能在平台上进行公开和公示，减少推进的阻力。

2. 基本思路

1). 需要一个专门的平台用于存放各个时期生成的测试报告，还包括测试报告模板、填写说明等内容。可以使用企业知识管理类的平台，如Confluence、SharePoint 等来实现。

2). 要有部门制定的测试流程、规范等，测试报告在一定层面上就是记录这些规范实施的结果。

(1). 各测试阶段的测试目标，准入、准出规范。（在测试报告中要记录每个阶段何时进入的、何时完成的，是否达到既定要求等。）

(2). 用例选取规范。（在测试报告中记录每轮次的测试过程中，如何选取测试用例，选取数量是多少等。）

(2). 测试用例数量、测试需要时长等预估方法。（制定测试计划时不能随意拍脑袋决定，要有一套符合自己组织的的预估方法，进而计划工作量和实施节点。这些计划内容可以体现在测试报告中。）

(3). 质量评价模型。（按照统一的标准对项目进行质量评价打分，需要提前有一套各部门均认可的质量评价模型。）

3). 编制《测试报告模板》，报告主要结构可以但不限于包括以下内容：

(1). 摘要部分：项目背景介绍、项目属性（编号、紧急程度等）记录

(2). 测试计划：人员任务分配、各测试阶段计划时间节点

(3). 测试资源：① 项目需求、设计等文档位置链接；② 测试设计、用例位置链接； ③ 测试评审记录文件链接。 ......

(4). 测试跟踪：记录各测试阶段（冒烟、功能、集成等）起止时间、负责人、执行轮次、执行用例数量、发现缺陷数量、是否测试通过、是否延期、是否预计会产生质量风险等。

(5). 质量评价：测试结束后依据部门的质量评价模型，对被测项目进行质量评价。

(6). 缺陷分析：从多维度对本次测试过程中发现的缺陷进行分析和整理。

(7). 其它事项记录：包括风险记录、重要事件记录、对测试造成影响事件记录等。

4). 公示并征求团队成员意见。建议先分别与团队核心成员沟通，收集反馈、改进并获得认可，再公开在整个团队内公示，时间最少一周，减少推进的阻力。

5). 先试行并可根据情况进行微调，再逐步推进实施，最后纳入监管和定期核查。

3. 制定必要的测试规范

没有规矩不成方圆。没有规范的测试过程也就谈不上测试质量的提高，而输出的测试报告也不具太多的参考价值。如果各个项目的主要测试环节均能按照统一标准的规范去实施，那么除了本项目纵向的记录和评价，也具备项目间横向的参照价值，进而发现不足去改善和提升质量。

根据自己组织或部门的实际情况，结合当前阶段最迫切的管理要求，制定和调整测试规范。

规范需要进行公示，除了在测试内部公示，还要传递到相关部门，如开发、产品、运维等相关部门。避免后期不必要的扯皮。

3.1. 测试阶段划分

先有明确的阶段划分，如冒烟测试阶段、功能测试阶段（2轮）、集成测试阶段、预生产测试阶段、线上验证阶段等等。

再明确每个阶段的测试目的。如冒烟测试就是为了验证被提测项目的基本功能是否实现，而哪些属于基本功能的测试范畴，需要提前将冒烟测试用例在项目组内声明并得到相关人员的确认（如把冒烟测试单的说明和地址提交到项目群中）。

3.2. 制定各阶段的工作标准

1). 本阶段的用例选取标准。说明每个测试阶段用例选取的基本原则，如：

冒烟测试：选取被测功能的正向业务流程，且优先级为1和2级的测试用例
功能测试-1轮：选取全部测试用例
功能测试-2轮：选取1轮中执行失败的用例，加上优先级为1和2级的测试用例

2). 本阶段的准入、准出标准。设定相对于本阶段测试的进入和通过标准，如：

冒烟测试：
- 准入（开测标准）：开发前后端联调通过，提测演示通过。
- 准出（通过标准）：全部冒烟测试用例执行完成，没有阻塞类问题，没有严重程度2级及以上缺陷发现
- 如果未达到标准：该版本打回，修复后需重新提测，并以文字通告形式通知相应管理负责人。

3.3. 测试用例数量预估参考

预估测试用例的数量，明确测试规模，进而预估测试时长并进行测试计划排期。

接口测试用例的数量相对而言是好预估的，但是功能测试中用例的数量会麻烦一些。但测试用例的预估又会直接影响对测试时长的预估，毕竟用例数量知道了，那么测试中的绝大部分时间就可以预估了（如用例编写时间、各阶段的用例执行时间等）。

大家可以搜到很多测试用例规模预估的方法，无论哪种方法，都不要使之过于复杂，即便准确性会降低，只要相关人员认可就行了。而且随着项目经验的丰富，这个预估会愈加准确。

如：一个简单的用例规模预估方法：

1). 把用例分为两类：页面元素类（单元素验证用例）、业务逻辑类（流程类用例）

2). 预估页面元素类（单元素验证用例）数量：

2.1. 根据需求原型，大致数出各页面中元素的数量，就按每个元素对应一个测试用例。

2.2. 新增和编辑页面元素基本相同，可以编写1个用例，但为了防止执行时漏测，执行时每个页面都要执行1次用例，即该用例会被执行2次。

2.3. 尽量建立公共用例库。有些大量重复的测试用例不用单独再编写，如翻页、重置、样式检查等功能。

2.4. 根据需求的重要程度，页面中有些不重要的且非必填元素，如备注、说明等，可以合并为一个测试用例。

3). 预估业务逻辑类（流程类用例）数量：

3.1. 直接取元素类用例数量的10~20%作为流程类用例数量。具体比例可以根据自己公司以往用例数据来统计。

3.4. 测试时长预估参考

实际工作中，各部门经常为了计划排期的争夺而头疼，即想据理力争又受发布时间的制约。此时能做的就是尽量提供可信的数据以支撑自己的排期要求，即便拿不到希望的排期也可以在测试范围上进行“讨价还价”了。

熟悉需求、用例设计和编写，这些工作建议与开发同步并行开展，不再单独占用项目时长。

从 “接收提测” 到 “测试完毕” 这段测试时长的预估可以参考的一些方式：

1). 对标开发时长。对比参考 “产品人员” 或 “开发人员” 提出的时长，如依据以往项目统计，测试与开发时长为一比一，或占开发时长的一半；

2). 按用例数量预估测试时长，如：

▪ 冒烟测试：用例数量20个，平均每用例执行时长20分钟，考虑冗余掉提交缺陷和沟通时间，则约需要8人时，即1人日。

▪ 功能测试-1轮：全量测试用例数量100个，平均每用例执行时长5分钟，去除冗余约10人时。

3). 按用例规模预估时长的注意事项：部门对测试用例编写等有明确的规范和样例，如：用例中每个步骤完成一个独立角度的验证测试，而不能将打开某某页面、点击一下按钮这些中间操作过程当做一个步骤，而使时长的预估失效。最好有专门的标杆用例，用于均化每个用例的执行时长，并作为测试人员编写用例的参照。

3.5. 质量风险预警标准

根据每个阶段测试的执行结果，如果质量过差，影响后续进度的可能性较大，此时应对项目组进行风险预警。风险预警越早越好，如果等到测试的最后阶段，都快上线了再预警也就没有实际意义了。

1). 在不同的测试阶段设定阈值，达到阈值则进行质量风险预警。可以按测试阶段设定，也可以统一设定，如：

▪ 功能测试-1轮：(S1~S3级别)缺陷数 / 用例数 ≥ 2/3

2). 设定预警通知文本模板，发送到项目群或者指定人员，尽量避免口头形式。也可以做个小工具，在模板中填写数据后，通过钉钉机器人自动发送到相关项目群。如：

4. 报告模板说明

4.1. 摘要部分

项目背景介绍：简单介绍项目背景、主要内容

项目属性：最关注的项目属性

4.2. 测试计划部分

测试计划是对测试过程进行指导的纲领性的说明文档。在《计算机软件测试文档编制规范》（GBT9386-2008）中，测试计划被定义为 “描述预定测试活动的范围、方法、资源和进度的一种文档。它确定测试项、要测试的特征、测试任务、执行每一任务的人员以及需要应急对策的任何风险。” 其主要内容包括：

制定测试计划的目的为：“用来描述测试活动范围、方法、资源和进度。定义被测试的软件项、要测试的特征、要完成的测试任务、负责每项任务的人员以及与该计划相关的风险。”
一份测试计划的结构包括：测试计划标识符、引言、测试项、要测试的特征、不要测试的特征、方法、测试项通过准则、暂停准则和恢复要求、测试交付项、测试任务、环境要求、职责、人员配备和培训要求、进度、风险和应急、批准。

计划中包括的内容

各公司对测试计划中包含的属性都大同小异，需要注意的地方就是不要贪多贪全，结合自己公司情况，精炼够用就好。我们当时计划基本就只包含以下这些内容，事实证明够用了：

文档标题：统一格式即可，如《XXXX项目测试报告(5464)》，括号里面是项目ID号
项目整体时间：当前项目计划的开始时间、结束时间
项目人员相关：产品人员、开发人员、测试人员（公司没有其它文档记录项目整体情况，就在测试计划中加上这项以便备查）
项目类型：紧急还是正常项目，其测试要求和质量要求会不同
测试任务分配：
- 一般记录谁什么时间干什么事儿，消耗多少人日或者人时，一般表格形式即可，便于进行成本分析。
- 这块我在公司中也省去了。因为每个项目（或迭代）规模和周期都不大，指定一个负责人，再安排1到2个人测试即可，具体事项由小组内部讨论口头定下即可，否则在计划中安排这些细节费时且意义不大。
测试用例预估：根据需求规格说明、原型，预估测试用例的数量
测试时长预估：
- 测试开始时间、结束时间。主要是预估测试的结束时间，当然如果是根据项目进度要求固定了上线时间，这个就免了，干就是了。
- 根据需要可以再细化到各个测试子阶段，计划每个子阶段的开始和结束时间
- 我在公司中没有要求在计划阶段细化时间，只是在执行实施阶段要求按各个测试子阶段，记录实际测试时长
可能风险预估：表格形式，记录预估可能出现的风险，严重程度、出现的几率，影响范围，应对措施

4.3. 跟踪测试过程

进入测试执行阶段，需要记录整个测试的实施过程，包括期间发生的一些比较重要的事件。可以按各个测试阶段进行分别统计，如冒烟测试阶段、功能测试阶段、集成测试阶段等，每个阶段根据目的和各自的特点，分别设定需要记录的属性。

当前项目状态：正常、延期、提前、中断
当前测试进度：冒烟测试、功能测试第1轮、功能测试第2轮、集成测试、预生产环境测试、发布完成
实际时间属性：实际提测时间、实际上线时间
各阶段测试情况跟踪记录：
- 如：冒烟测试阶段跟踪记录
  - 开始时间、结束时间
  - 执行用例总数量、通过数量、失败数量、阻塞数量
  - 测试执行人员
  - 发现缺陷统计：按严重程度+优先级进行分类统计
  - 测试结论：通过、失败

4.4. 统计分析及质量评价

完成测试结果的统计分析，尤其是缺陷分析，如缺陷的增加趋势、缺陷类型分布、缺陷严重程度分布、缺陷产生原因分布等。需要结合本部门的目的选择生成相应的统计项。

进行测试质量评价。质量评价的范畴比较广，涉及到各项度量项和度量指标的设定，评价成本会较高，因此这里可以只针对测试部门的现有数据进行度量，需要部门提前选择度量的指标，并确定质量评价模型。在报告文档中，根据质量评价模型填入相关的数据，最终得出测试阶段的质量评价即可。

当然这种项目之间的横向比较也是一把双刃剑，尽量是同类型的项目，没有引入不稳定的技术或者有明显的难度和不确定性。再有就是根据组织的成熟度的和管理目标，注意调整度量的指标和评价模型。

4.5. 重要事项记录

测试过程中，还有些额外的内容，或者有些重要事件需要记录，可以统计记录到一个位置，如：需求变更记录、提测延期说明、质量风险预警等等。

事项名称	事项类型	事项说明	备注
XXX功能产品需求临时变更	需求变更	XXXXX
未按计划时间提测	延期	XXXXX

4.6. 资源列表

记录项目中的各类资源位置。一些组织或部门对这些资产没有统一的管理手段，各类资料散乱到不同的位置，导致后期难以找寻或追溯，因此在测试报告中可以将相关资源进行整理汇总并记录。

资源名称	所属部门	资料位置
RPD需求文档	产品部	http://..........
开发设计文档	开发部	http://..........
用例评审记录	测试部	http://..........

5. 其它补充

关于测试报告的填写和更新

可以由项目的测试负责人对测试报告进行填写和定期更新。从理想的角度看，都希望这个文档随着测试的进度能够实时更新，但实际这些零散的事项会打乱相关人员的工作节奏，或者很容易被遗漏。因此可以设定一个固定的时间截止点，如要求在每周五下午5点前，各个项目的测试负责人，务必将自己负责项目的测试报告更新到最新进度，部门负责人可以在部门群内提前@相关人进行提醒，到点后开始检查。

定期巡检规范的执行情况

对于规范的实施落地，必须要有相应的巡检机制，能够及时发现问题，不断改进并完善。巡检过程可以低频些，且简单透明，如：设定每两周开展一次巡检会议，抽查项目在测试过程中是否按照部门规范执行：