一、非精准测试的五宗罪
精准测试这一理念之所以产生，主要是基于如下的6个方面的考虑：
-
测试过程和规范无法满足要求
-
项目验收缺少具备公信力的手段
-
传统的手工测试效率较低
-
测试与开发的断层
-
新技术架构的挑战
虽然测试流程很规范，但是软件质量还是不如意
随着测试行业的发展，软件测试做得越来越规范，但大部分的测试还是基于对业务的理解，与真实业务数据还有差距，准确性难以保证，测试结果无法精确的对软件质量进行定义和判断，系统上线后，问题开始暴露出来，使用体验差，更有甚者造成巨大的经济损失。归根结底，就是因为测试不充分，没有引入精准的测试分析，仅依靠测试经验是根本无法判断的。
软件项目验收缺少好的运行检测手段，检测结果缺少技术公信力
软件是拿来使用的。虽然软件项目验收过程中验收的内容比较多，包括合同约定内容、技术协议、开发文档、产品文档、用户文档、程序代码等，但客户最关心的是他们的业务能否真的在系统中落地运行，并且运行良好，单凭投入少量人力进行业务功能的验证，抽样的检测结果不代表软件全部，可信性不具备技术公信力。
传统的手工测试，测试执行无法精准量化控制，测试效率比较低
使用传统的手工测试，采用的是基于人工评定的黑盒测试方法，打造高可靠性的软件产品需要投入大量人工成本。由于测试执行无法精准量化控制，凭主观定性评价结果为主，对人力经验依赖大，人员变动情况大，质量抖动厉害，看不到明确测试差距和量化目标。虽然在不断的执行测试，但缺陷发现率并不高，无效的测试消耗了大量的测试成本。
测试人员不能精准把握缺陷现场，与开发人员协同工作困难
缺陷处理的一般流程是：测试人员执行用例，发现缺陷就提交缺陷系统，开发人员看到缺陷，进行重现或远程调试。如果测试给开发提供的测试结果都是比较模糊的功能逻辑描述，重现缺陷需要花费大量的时间。如果测试人员采用了精准测试技术，通过执行的用例就可以找到对应执行的程序代码块，这样解决问题就会快很多，开发人员和测试人员之间的协同工作就会轻松好多。
分布式、微服务架构，软件越来越复杂，测试挑战性越来越大
采用分布式/微服务架构，使软件系统越来越复杂，测试的挑战性越来越大，采用传统的测试方法执行测试，系统质量也难以保证。
在移动互联网大力发展时代，软件开发对质量要求越来越高，而迭代开发要求项目周期越来越短，快速的版本验证面临挑战。
二、精准测试：一种可
追溯的软件测试技术
从字面理解，精准就是非常准确。非常准确需要用数字说话。
在测试领域，精准测试是一套计算机测试辅助分析系统，对测试过程的活动进行监控，将采集到的监控数据进行分析，得到精准的量化数据，使用这些量化数据进行质量评价，利用这些分析数据可以促进测试过程的不断完善，形成度量及分析闭环。精准测试是一种可追溯的软件测试技术。
三、精准测试的核心：数据与追溯
精准测试的核心思想就是使用非常精确和智能的软件来解决软件测试的问题，从根本上引领从经验型方法向技术型方法的转型。质量的评估不再靠经验，而是通过精准的数据来判定。
精准测试没有改变传统的软件测试方法，区别只在于，由软件去采集测试过程执行的代码逻辑及测试数据的过程，自动建立测试用例与程序代码之间的逻辑关系。在测试过程加入软件的采集过程，可以形成正向和逆向的追溯。
通过正向追溯，开发人员可以看到测试人员执行用例的代码细节，以方便进行缺陷的修复，测试数据可以直接为开发调试提供依据，快速定位并修复缺陷。
通过逆向追溯，测试人员通过修改的源代码快速确定测试用例的范围，极大减少回归测试的盲目性和工作量，快速修订测试用例，达到测试覆盖率最大化。
四、精准测试的关键特性
软件测试示波器
在功能测试过程中自动分析程序运行的一些数据指标，以波形的形式进行实时输出。示波器是一种实时的监控，实时的计算测试过程数据并展现。
用例和代码双向追溯
执行一个测试用例以后，精准测试通过程序自动的记录和显示这个测试用例执行的代码。如果测试人员关注某一些代码行，它可以追溯出哪些用例在执行过程中运行过这段代码。
智能筛选回归用例集
根据代码的变动范围来直接精确的定位需要回归的用例，这样使回归测试所需的时间更短，回归的范围更准确。
测试覆盖率精确分析
精准测试覆盖率形式多样，最高支持标准MC/DC（修订的条件/判定覆盖）的100%覆盖率要求。
软件缺陷快速定位
根据缺陷与用例的对应关系，快速找到执行用例对应的代码行。
五、精准测试体系
方案的价值和实现
根据前文所讲到的需求、概念和关键特性，我们可以设计出如下的一种精准测试体系。这也是我们的技术团队一直在客户现场采用的测试方案。
组成部分
精准测试体系主要以持续集成平台、统一测试平台和测试监控分析平台为测试能力支撑。
通过持续集成完成代码的构建编译、静态代码扫描和测试环境部署；
使用统一测试平台实现自动化测试回归；
通过测试监控分析平台，精确、详尽的记录测试用例运行的情况，提供大量原生分析性数据，进行事后的缺陷分析、追踪，建立测试用例与程序代码的关联，实现测试用例和程序代码的双向追溯，真正实现数据化的测试管理。
测试过程
精准测试的整体过程如下图所示：
精准测试需要结合持续集成、持续部署和持续测试的过程，并结合白盒测试技术和黑盒测试技术，实现代码规范、质量和安全扫描，完成单元测试及覆盖率的评测，通过自动化测试的手段实现系统的功能测试。通过测试监控分析平台，从静态测试和动态测试两个维度实现软件质量的精准化评估。
双向追溯
精准测试的核心流程就是通过测试监控分析平台实现测试用例和程序代码的双向追溯。
在测试监控分析平台的帮助下，实现测试用例和海量的代码执行信息自动关联，精确到函数级别及代码块级别。测试人员可以知道测试用例到底测试了哪些功能，覆盖了哪些代码。
上图就是测试用例到被测代码的正向追溯，通过正向追溯可直接在代码级定位测试现场故障和缺陷逻辑，并提供最后运行的时序数据；通过正向追溯自动记录产生功能对应的详细设计实现，辅助软件解耦和架构分析；通过正向追溯，可以迅速定位缺陷对应的代码执行逻辑，帮助开发人员快速修复缺陷，可追踪难复现缺陷。
相反，在测试监控分析平台的帮助下，可以实现程序代码到测试用例的反向追溯。下图就是反射追溯的一个过程展示。
通过反向追溯，我们很容易就能确定代码块对应的测试集，获取到的增量代码，通过智能用例选取算法，可以准确的确定需要回归的测试用例。精准的确定回归测试范围，避免了全量回归造成测试资源的浪费，既保证了质量又缩短了版本的迭代周期。
代码覆盖
有了精准测试，覆盖率统计不再是白盒测试的技术专利。使用精准测试技术，系统测试也可以实现程序的覆盖率分析，而且可以不需要源代码，实现运行代码的指令覆盖、分支覆盖、圈复杂度、行覆盖和方法覆盖的统计分析。
程序代码的覆盖率统计可以是单次执行的数据，也可以是多次执行的累计数据，获得一段时间内或多人测试执行的累计效果，支持在软件研发周期内整体评估测试的覆盖程度。
传统的黑盒测试技术属于经验型模糊测试，质量、进度不可视，产生的无效劳动较多，系统与人员的管理成本极高，软件质量风险高。
传统的黑盒测试大约70%的缺陷很容易发现，但之后缺陷的发现效率会急剧的下降。而传统的白盒测试技术直接面对代码测试，难度大、效率低，仅关注覆盖率，无系统性。精准测试是采用传统黑盒测试与白盒测试相结合的模式，它可以在黑盒测试过程中，通过专用软件自动采集白盒级别的运行逻辑数据，根据可视化出来的不足点和漏洞点，引导开发和测试有针对性的补充测试用例，提高缺陷发现效率。
建设理念
精准测试体系的建立也是一个系统化的工程，需要长远规划，循序渐进，并逐步完善。需要以理论为基础，以实践为准绳，持续改进，让精准测试体系使测试更加智能化，对质量评估更精准。
并非是所有的项目类型，都适用精准测试，精准测试的核心需求是来自于对软件质量的较高要求，而不同的项目类型对质量的敏感程度是不同的。
移动互联网型的产品一般需求响应快，而且产品发布成本低，采用灰度发布，使用A/B测试方法替代传统的功能测试即使用小流量测试新功能，如有问题迅速下线，对发布质量并不太敏感。
项目型的产品一般以用户为中心，需要准确把握用户的需求，需要进行系统测试，通常采用用户测试的方式对项目进行验收，对项目的上线质量比较敏感。
产品型的产品需求由自己把握，产品的研发周期相对较长，通常都有独立的测试团队，需要按照一定的规程执行测试，由开发人员进行单元测试，由测试人员进行集成测试和系统测试，而且满足一定的质量目标才允许发布，对发布质量要求较高。
七、总结
精准测试的核心是以自动化的软件对软件测试过程数据进行记录，从而实现双向的追溯：从开发到测试的正向追溯以及从测试到开发的逆向追溯。
通过双向追溯，我们可以实现软件质量的实时监控，回归用例的智能筛选，测试覆盖率的精准分析以及软件缺陷的快速定位。
但精准测试并非适用于所有的软件项目类型，互联网应用、项目级应用和产品级应用，对软件质量的需求，也就是对精准测试的要求是逐渐递增的。
精准测试的诞生，核心动因是对于软件质量的要求。无论是项目验收公信力手段、测试效率管控、测试与开发人员的协同以及复杂的分布式架构带来的挑战，无不围绕着对软件质量的需求满足。而软件质量的最终价值，是用户体验的提升。在Gartner提出数字化转型的双模式理念后，各个领域都在寻找各自业务领域里应用和实践数字化转型的方案，对精准测试的实现过程，实际上也是软件测试过程数字化的一种体现。精准测试通过提升软件质量，改善了用户体验，从而赋予企业数字化转型更可靠的软件能力。
原文发布时间为：2018-06-19
本文作者：王俊其
