提供数据也是测试的基本价值，测试提供的数据，理论上是研发团队进行各阶段决策的主要依据之一。
测试提供的数据，一方面包含
产品质量的结论；另一方面包含
研发过程的分析。
项目阶段点和结束时，测试提供的数据包括
研发过程、项目结束的
度量数据、
关键指标和主要风险等，本章将这些数据分为以来几个部分介绍：
测试结果；风险情况；测试过程数据。
4.1测试结果数据
4.1.1测试结果数据的范围和作用
测试结果是指在某项测试完成后，根据测试过程中获得的数据、现象等信息给出的，指示产品质量的
结论性信息。
测试结果典型的如：遗留缺陷数量和级别，主要业务流程的TPS，安装耗时，主要操作的平均延时等。
作用：这部分数据是测试所提供的数据中
最重要的一部分，通常在版本发布之
前提供出来，供产品团队的各个角色确定产品是否发布，在什么范围发布，上线时和上线后需要做什么安排。
4.1.2测试结果数据的内容
产品测试结果包含以下内容：
1、
遗留缺陷数据。包含遗留缺陷的个数、级别，每个缺陷的规避措施，计划修改时间等。
2、
性能指标。主要包含各个典型业务的性能性指标，指标通常包含容量、TPS、在线用户数、吞吐量、业务处理成功率、系统资源占用情况、平均操作耗时、平均响应延时、数据同步延时等。
3、
服务相关指标。如安装升级耗时、升级扩容影响业务的时长和比例、告警有效性、故障定位恢复有效性和对业务的影响、统计报表的性能和对业务的影响；按产品资料完成安装、升级、故障处理的时长、求助次数、试错次数等。
4、
可靠性相关指标。如故障自动恢复率、故障检测率、备份操作耗时和对业务成功率的影响、故障恢复的耗时和恢复期间业务的性能、系统过载时业务的性能等。
5、
安全性。安全性实际上没有定义出指标，只有安全漏洞防护要求的满足度，测试结果中需要按漏洞级别统计防护要求的满足度。
6、
兼容性。对产品所需要遵循的协议规范的遵从度，这关系到产品能否和客户网络的其他设备正确对接；对第三方产品的兼容性，这关系到产品能否广泛使用；对历史版本的前向兼容性，历史版本的全部特性、接口、指标是否都保持不变，这关系到老客户是否可以升级；平台产品对业务主流历史版本的兼容性，这关系到平台产品是可以单独发布使用，还是必须捆绑业务发布。
7、
体验相关指标。体验的设计和验证在我们的产品中是一个新课题，评估分主观和客观两部分。主观评估建议考虑外部资源进行评估。客观结果有任务完成率、单个任务跳转页面、音视频MOS值；完成任务的出错次数、求助次数；终端的能耗、流量、内存消耗等；
8、
风险闭环结果。项目早期，可能存在的技术风险，那么在测试结果中需要逐个说明这些风险的验证内容和验证结果。
性能测试大部分数据由性能测试执行工具完成，其它数据通过手工方式采集，数据通过配置管理工具进行管理。
4.1.3
用金字塔模型编排测试报告
测试报告模板，符合金字塔原理：
最重要的结论放在
最开始的位置，然后是得出结论所依据的各种
论据。研发团队的主要角色，都可以直接从几个固定的章节中获得需要的信息，确认测试结论。
在测试报告中，不能把所有的数据按照技术分类进行罗列，所有的数据结果一字排开；而是要根据每个读者的角色职责将数据
分类，并
突出重点。
在设计测试报内容编排时，首先需要知道报告的读者都有谁，每个读者需要根据什么信息做决策？然后再审视测试报告，是否让每个读者都能够根据章节索引，很快找到他们需要的数据。
4.2风险评估数据
4.2.1风险的含义及风险评估数据的作用
这里的风险指的是
技术风险。
作用：这部分数据是测试结果的一部分，作用也是供产品团队的各个角色确定产品是否发布等。
4.2.2RBT
测试进行风险管理最常用的方法是
RBT，即
基于风险的测试。
RBT的实施过程如下：
1、
确定测试范围。新、老特性；DFX；与版本、客户、产品相关的专项内容；
2、
风险等级评估。失效概率；失效影响；
3、
基于风险的测试。风险高的先测试；风险高的多测试；持续评估风险变化；
4、
风险闭环评估。根据风险点验证结果；重新评估失效概率；
测试报告中关于风险有两部分内容：一个是产品的
风险评估表，一个是
风险跟踪表。
RBT的初衷是把有限的测试资源用到
最重要的地方，同时严重的缺陷能够较早发现，因此风险评估结果首先会用于测试计划的人员和时间安排。
在产品研发项目中，更多的是把这个RBT方法与测试策略结合，作为一个
沟通工具使用。在项目中，通常是在测试策略中进行风险分析和评估，项目过程中除了对风险评分进行刷新，更关注风险点的
闭环。
4.2.3将风险作为测试的重要
输入
风险评估并非是编写测试策略时由测试自己完成的、顺带的动作，而应该是研发各个角色
共同实施的专项工作之一，特性的风险评级和具体风险点是测试的
最重要的输入之一。
风险评级和风险点
一方面是测试策略的输入，确定测试时需要覆盖哪些产品特性和DFX。
另一方面，风险和需求、设计一起作为测试设计的输入，明确特性和DFX的测试内容和重点。
4.2.4依托测试策略活动进行风险评估
想要风险信息真正发挥这些价值，首先要注意的是，基于风险管理整个过程的每个环节都
不能是测试
单方面的行动，至少在风险识别的环节，需要把产品团队的核心角色卷入进来，这样才能从客户使用、服务、设计等角度比较完整地识别技术风险。其次，风险的识别可以融入到
设计阶段的各个研发活动中。以经验来看，在所有的这些评审中，测试策略的
评审是暴露风险点
最有效的工具。最后，风险需要进行持续的
更新和跟踪。可以看出，风险管理在测试的落脚点是
测试策略，在测试策略的分析、评审、执行、调整等各个活动，都有风险信息贯穿其中。
测试策略是测试活动的
总纲领。测试策略的分析主要是根据项目的范围、目标和风险，确定测试的覆盖内容、优先级，提出环境、工具、输入信息的需求，并约定项目各个测试阶段的出入口准则等。
测试策略文档包括以下内容。
1、产品研发状况
分析。分析内容包括项目情况（项目概要情况，包含开发内容，也包括项目目标）和风险（主要的技术风险，含RBT风险评估表和风险记录表）；
2、测试策略
综述（测试策略的
总体安排，包含了测试覆盖、自动化、优先级等方面的内容）。主要包含
测试项目和策略（测试活动、开展时间、测试内容、测试方法、覆盖程度、测试重点、冲突处理等）、
继承部分的测试策略（老产品继承而来的特性）、
自动化测试策略（哪些内容实现自动化，什么阶段实现自动化）。
3、XX测试策略。分别说明
集成、
系统、
验收测试的测试策略，内容包括：
测试重点；环境和工具；入口准则、出口准则。
4、
其他信息和数据。对数据、研发和客户信息有哪些特殊需求，如何获取。
RBT虽然从名称上看是一项测试技术，但事实上是一种
研发模式。特性风险的高低，不仅影响测试的计划，也同样影响开发的计划。
4.3
测试过程数据
4.3.1测试过程数据的范围和作用
测试过程中记录的数据有两类：
测试项目过程数据和用例执行过程数据。
测试项目过程数据包含：
计划执行、缺陷、工作量、覆盖等相关的数据。有些是原始数据，有些是经过统计的、计算后的数据。
用例执行过程数据如：操作界面截图、操作日志、性能测试时记录的CPU、内存占用率等。
原始的测试过程数据通常不会出现在测试报告中，写入测试报告的是对测试过程数据的分析结论及其图表，一般还有：缺陷数和缺陷密度；工作量和工作量密度；覆盖率；系统在不同压力下的资源消耗、响应延时等。
测试过程数据有几方面的作用：
1、测试结论的
支撑性数据。主要是质量属性测试时的用例执行过程数据。
2、发现
改进点。通过分析与缺陷、进度、效率、覆盖有关的测试项目过程数据，发现当前项目的测试薄弱点，或者下一个项目的改进点。
3、建立
基准。测试项目过程数据和用例执行过程数据，可以分别形成与测试能力、产品质量相关指标的基准数据，基准数据经过积累可以用于估计新项目的工作量或进度，或评估项目质量。
4.3.2测试项目过程数据
测试项目的过程数据一般有：
1、
计划执行。
2、
工作量和效率。
3、
缺陷。
4、
覆盖。
对这些过程数据常规的分析有基准分析、分布分析、组合分析、趋势分析和覆盖率分析等。
基准分析：以上这些数据经过若干项目的积累后，都会形成一个区间，绝大部分项目的数据都是落在这个区间内，这个区间就是测试项目过程数据的基准。
分布分析：讲工作量、效率、缺陷等按特定的维度分类汇总绘制柏拉图，据此分析影响质量和效率的主要因素。分布分析是进行过程改进最主要的分析方法。缺陷引入的原因包括：初始化、配置管理、算法、功能实现、时间相关、界面相关、关联关系；功能测试手段包括：基本功能、出入、流程、交互；
组合分析：将两个或以上的数据组合进行分析，找到数据组合异常的部分进行风险分析和排查。组合分析常用
四象限分析法，最典型的是分析工作量密度-缺陷密度，用于发现可能测试不足的特性。
趋势分析：讲缺陷按时间绘制成增长曲线，如果在测试的最后一段时间新发现缺陷明显收敛，则表示测试能够发现的缺陷已经基本上都发现了，测试是正常结束的。缺陷的增长趋势分析，在较大型的、采用瀑布、V、W流程模型的研发项目中比较常用。迭代开发的项目中不再进行缺陷的增长趋势分析。
覆盖率分析：各种覆盖率衡量是测试的
强度，对于没有覆盖或者测试强度低于一般水平的需求，需要找出没有覆盖到的代码。如果是测试设计遗漏，则需要补充用例；如果是无需测试或通过其他手段保证质量，最好有其对应的风险分析结论和依据。
4.3.3测试项目过程数据的应用
在我们产品实践历程中，项目过程数据的采集，可以进行新项目的测试工作量估计。后来开始在项目中帮助及时
调整测试策略。
目前，对
未发现缺陷进行
预测仍是一个难题。
从经验来看，项目过程数据用于问题分析和识别通常是
有效的，也可以用于评价研发过程的问题是否解决。但
决不能用于对人或项目的考核，数据一旦用于考核，就无法再保证其客观性，无论为这个数据的采集再附加多少管理措施都没有用。因此，项目过程数据只考察其
统计意义，可以对应到测试策略的
调整、研发过程的
改进，
杜绝对应到某个个体的人的失误上。
我们的所有产品研发项目都使用统一的缺陷管理
电子流，通过一段时间的推行，基本上实现了全部缺陷通过电子流处理，因此缺陷相关的数据都可以从
工具中直接导出。
4.3.4用例执行过程数据
记录用例执行过程数据的主要目的是为了
发现隐藏的缺陷。用例执行的过程数据一般有：
1、
性能测试的过程数据。记录时间和资源相关的详细数据。
2、
可靠性测试的过程数据。记录故障发生时、恢复时、恢复后，在系统、产品、业务上发生了什么影响。
3、
可服务性测试的过程数据。记录服务操作的效率，以及操作系统、产品、业务产生的影响。
4、
体验测试的过程数据。记录影响用户体验的详细数据。
5、
功能测试的过程数据。根据特性的特点确定记录内容，含数据变化、界面操作、日志记录等。
对这些数据常规的分析有基准和例外分析、趋势分析。
基准和例外分析：以上这些数据经过若干项目的积累后，都会形成一个稳定的区间，这个区间就成为这个数据项约定俗成的基准。
趋势分析：有随容量或压力增加的变化趋势，以及随时间轴的变化趋势。
1、随容量或压力增加的变化趋势：资源、延时、耗时相关的数据，随着容量或压力增加的变化趋势。
2、随时间轴的变化趋势：在容量和压力维持稳定不变的情况下进行测试，同时记录业务处理成功率、延时、资源消耗随时间的变化趋势，通常这个测试至少要持续记录30-120分钟的数据。
4.3.5用例执行过程数据的应用
通过性能测试，
不仅能够获得产品的
处理能力和
容量的指标，还可以起到以下作用：
1、
获得性能拐点。产品维持稳定运行所能承受的压力上限。
2、
获得性能瓶颈。影响产品达到更好性能的主要因素。第一步就是采集每个业务流程；然后利用软件和数据的性能分析工具。有时候性能瓶颈并不在资源，通常是由于锁使用不当，业务流程不合理等程序设计和代码实现上的原因导致的。
3、
稳定性问题定位。常见做法是在实验室采用“空间换时间”的方法重现问题--给产品加上标称性能指标的压力，运行一段时间使问题重现，测试期间观察资源占用、业务处理耗时、延时，以及额外记录的业务处理过程的数据，通过数据与问题现象的相关关系，对问题进行初步判断和猜测。
4、
指导配置。可服务性、可靠性测试在执行用例时，需要加载正常的背景压力。除了观察和记录操作本身的数据，还需要观察和记录操作过程中的业务和系统性能数据变化。除了观察进行操作的这一段时间的数据，还需要观察操作完成后，直至业务性能完全恢复的这一段时间的数据。
最后，需要注意数据的存档。存档的数据不仅包含测试结果，也应该包含用例执行的过程数据。
4.4用数据讲好测试故事
想要让测试工作被研发团队其他成员了解并信任，
数据的作用不亚于缺陷。
缺陷比较
具体--产品存在什么样的问题；
数据比较
抽象--产品在哪个方面出问题的风险比较大。缺陷是离散的“
点”--缺陷之间没有逻辑关系；数据是系统的“
面”--多种数据综合起来形成对产品质量的完整评价。
缺陷是现象；数据导出结论。
| 典型数据 | 作用 | 技术 | |
| 测试结果 | 遗留缺陷数量和级别；主要业务流程的每秒事物数；安装耗时、主要操作的平均响应延时等 | 决策 |
缺陷分析；
性能及其他DFX的指标测试和数据记录
|
| 风险 | 技术风险 | 决策 | RBT |
| 测试过程数据 | 缺陷数和缺陷密度；工作量和工作量密度；代码覆盖率；系统在不同压力下的资源消耗、响应时延等 |
支撑测试结果；
发现改进点；
建立基准；
|
项目过程数据；
质量分析方法；
DFX用例执行过程数据；
|
这些数据支持测试讲好测试的3个故事：我的结论
是什么、我
依据什么做出的结论、
为什么我做的测试是足够的。
4.5小结
结果、风险、过程数据是测试活动的重要产出，构成了测试报告的主要内容。根据金字塔原理，测试报告最好采用以下结构：
首先给出版本测试的最终结论，用例执行结果、性能指标数据、遗留风险；
其次是详细的风险跟踪表、用例执行的关键过程数据及其图表；
最后是项目过程数据的分析，以及基于分析给出的改进建议。