160 lines
11 KiB
Markdown
160 lines
11 KiB
Markdown
---
|
||
title: 精准测试相关概念
|
||
date: 2022-01-28 15:48:48:53
|
||
categories: [精准测试]
|
||
author: Anges黎梦
|
||
tags:
|
||
- 精准测试
|
||
- 覆盖率
|
||
---
|
||
## 背景
|
||
|
||
### 范围评估
|
||
|
||
对于分布式系统中的绝大部分应用，随着业务发展，自身应用的代码复杂度会不断增加。
|
||
|
||
一些业务架构设计不太合理的系统，当任何一个接口产生变动，则会使多个其他应用也受到影响。在测试过程中会发现只是自身应用代码的修改，会导致对外暴露的接口逻辑发生很大变动，此时开发人员和测试人员需要判定出这个对外暴露的接口对哪些上层应用有影响。
|
||
|
||
随着软件的频繁更迭，需要大量的时间和人力去测试， 而业务快速迭代交付导致测试时间不断压缩，全回归是一件很困难的事情。加上回归测试完全依赖于测试人员的能力、经验和业务熟悉度，受主观因素影响太大，并且测试对代码覆盖程度，质量高低，没有客观数据可衡量，完全靠人为主观介定，不确定性太多，这是产生漏测的根本原因。
|
||
|
||
> 显然，如何基于代码变更准确、全面地判定影响范围会越来越重要！
|
||
|
||
当前测试行业的范围评估情况，如下图：
|
||
|
||
|
||
|
||
往往上图中的这些内容是没有数据支撑的。当应用的代码有变更，无法获知变更影响了哪些功能，也无法精准地选取测试用例，因此不得不进行全量回归。
|
||
|
||
### 代码质量分析
|
||
|
||
在软件团队不断发展的今天，团队内各个人员的代码水平就显得尤为重要。
|
||
在编写代码时，研发人员也会编写代码进行测试，但这样一来，导致代码质量下降的因素除了一些代码写法上不规范的代码、出漏洞的代码，同时还会有一些冗余的代码。由此引发出的代码质量问题，也需要可度量。
|
||
|
||
### 传统软件测试的主要短板
|
||
|
||
现如今，软件产品的规模以及复杂度的扩展速度，可谓超乎想象，而传统的软件测试方法，在面临这些挑战时已经表现出了些许力不从心。这些力不从心，也就是传统软件测试的短板，简单可以分为下面这五大类:
|
||
|
||
**第一大短板：测试的维护成本日益升高。**
|
||
|
||
传统测试用例数量的增长会导致测试用例的代码覆盖率增长，但当覆盖率到达一定的数值时（75%左右），则出现了增长瓶颈，这时为了维护一个庞大的测试用例集，以保证产品新特性和老功能的正确性与稳定性，使覆盖率继续增长，需要花费越来越多的时间和人力成本，如下图：
|
||
|
||
|
||
|
||
而在这成千上万的测试用例中，有很多陈旧的用例已经失效了(不再能满足现有产品的测试需求了)，但是整个团队还是要花费很多精力去维护这个庞大的测试用例集。
|
||
|
||
**第二大短板：测试过程的低效。**
|
||
|
||
随着软件功能的不断丰富，相应测试用例集也愈加庞大，这时难免会出现“杀虫剂”效应，即：测试用例越来越多，而产品的“免疫力”也越来越强，测试效果却不明显。
|
||
造成这种问题的原因是，我们在测试早期已经发现了80%的软件缺陷，除非再花费巨大的人力和时间成本分析并增加大批量的测试用例，否则后期新增的测试用例已经很难再发现新的缺陷。
|
||
|
||
|
||
**第三大短板：缺乏有效的回归用例选取机制。**
|
||
|
||
在传统测试理念中，每次添加新功能或者修复缺陷，一般都需要在产品上线前进行一轮全回归测试，哪怕这次的改动只有一行代码。但是，全回归测试的测试用例数量以及执行代价一般都比较大。
|
||
这里，我们之所以要采用全回归测试，是因为我们无法准确地知道这次更新到底会影响哪些功能，也无法知道应该从测试用例集中选取哪些必要的测试用例，无奈之下只能两眼一抹黑地执行全部用例。
|
||
|
||
**第四大短板：测试结果的可信度不高。**
|
||
|
||
在传统软件测试中，人工因素占据了测试数据的统计分析的绝大部分比重，由此导致测试数据本身的技术公信力不够高，进而需要依靠管理手段来保证真实的测试数据被准确地记录。这种做法不仅可靠性差，而且执行成本高。
|
||
|
||
**第五大短板：无论是白盒测试技术还是黑盒测试技术都有其局限性。**
|
||
|
||
如果完全基于黑盒测试，那么注定无法深入代码实现的细节，也就无法做到有的放矢地设计测试用例；而如果基于白盒测试技术，为了保证代码质量，往往会采用代码级测试和代码覆盖率技术。
|
||
但是，这些测试方法都强依赖于产品代码，一旦代码发生改变，很多测试都会因此失效，因此很难适应快速迭代的开发流程。
|
||
另外，由于目前的代码级测试和代码覆盖率技术还不支持测试用例级别的覆盖率分析，而是要将所有测试结果混在一起，导致白盒测试时无法区分代码覆盖率的贡献到底来自于哪个测试用例，这将极大地限制白盒测试工具在测试结果分析上的作用。
|
||
|
||
## 精准测试简介
|
||
|
||
> 精准测试，就是借助一定的技术手段、通过算法的辅助对传统软件测试过程进行可视化、分析以及优化的过程。
|
||
>
|
||
> 它是一种代码和测试用例双向可追溯的软件测试技术。精准测试可以使得测试过程变得：可视、智能、可信和精准。
|
||
|
||
### 精准测试的核心思想
|
||
|
||
**精准测试是对传统测试的补充**
|
||
|
||
精准测试是基于传统测试数据的，并不会改变传统的软件测试方法，更不会取代传统测试。也就是说，精准测试在不改变原有测试集的基础下，能够优化测试过程和数据，提高测试效率。
|
||
|
||
**精准测试采用的是黑盒测试与白盒测试相结合的模式**
|
||
|
||
在执行黑盒测试时，收集程序会自动产生白盒级别的运行数据，然后通过可视化或者智能算法识别出测试未覆盖的变更代码，继而引导开发人员和测试人员有的放矢地补充测试用例。
|
||
同时，在黑盒测试的执行过程中，可以实现测试用例和产品代码的自动关联，将基于黑盒的功能测试直接映射到基于白盒的代码层测试，这将使智能回归测试用例选取的想法成为可能。
|
||
|
||
**精准测试的数据可信度高**
|
||
|
||
精准测试的数据都是由系统自动录入和管理的，人工无法直接修改数据，因此我们可以直接将传统测试产生的数据导入精准测试系统，用于测试结果的分析，从而使测试结果具有更高的可信度。
|
||
|
||
**精准测试过程中，不直接面对产品代码**
|
||
|
||
精准测试通过算法和软件实现对测试数据和测试过程的采集，因此并不会直接面向代码，也就不会强依赖于产品代码。
|
||
但是，精准测试能够实现测试用例和产品代码的自动关联，也就是说代码覆盖率的统计能够以测试用例为单位来进行，具体实现的核心思想还是基于代码覆盖率的统计，只是在代码覆盖率的元数据上增加了测试用例的信息。
|
||
因此，代码的改变并不会影响测试过程，但却能够将功能测试间接映射到代码级别。这样，精准测试就实现了测试用例和被测产品代码的双向追溯。
|
||
|
||
**精准测试是与平台无关的、多维度的测试分析算法系统**
|
||
|
||
精准测试系统是一种通用的测试分析系统，独立于任何测试平台，其内部算法和业务无关，因此适用于各种不同类型的产品。
|
||
同时，精准测试为我们提供了多维度的测试分析算法，拓展了白盒测试的范畴。而，精准测试对测试用例和产品代码的自动关联，使得它可以为测试过程提供大量的智能分析结果。
|
||
|
||
### 支撑技术
|
||
|
||
在现代测试环节中，我们往往会考虑如何避免多测，漏测，如何提高测试的效率和准确率。
|
||
|
||
由于系统之间的种种依赖以及测试人员对系统架构的理解并没有研发人员熟悉等因素，导致测试的数据可追溯性差，对结果的判断偏主观性，强依赖个人经验等种种痛点。
|
||
|
||
我们考虑到测试人员对这些问题的困扰，特别是跨系统，跨业务的测试复杂性，数据追溯等问题。
|
||
|
||
一套精准回归测试解决方案——跨应用精准回归、用例代码覆盖率技术、用例代码染色技术、用例代码双向追溯技术。
|
||
|
||
|
||
|
||
#### 跨应用精准回归
|
||
|
||
跨应用精准回归能力智能动态链路追踪技术，规避了传统静态代码扫描技术只能在单系统、单应用下做到代码质量静态分析的窘境，它能分析多个应用在多个集群之间的链路关系，
|
||
无论应用之间通过何种RPC或HTTP等协议互相调用，都能动态绘制调用链路图，跨应用、跨系统追溯代码变更，深度分析变更对测试用例的影响，针对影响发现需要回归的测试用例，
|
||
解决测试人员对应用架构理解不足的痛点，同时也解决系统之间的依赖变更所造成的漏测，未测等不确定因素。使精准回归做到跨系统、跨应用的能力。
|
||
|
||
主要作用：
|
||
|
||
● 评估影响范围 ：明确修改内容以及影响功能
|
||
|
||
● 根据变更圈定执行用例 ：解决测试冗余，漏测的问题
|
||
|
||
● 程序执行透明化 ：提供用例执行路径，帮助熟悉代码
|
||
|
||
● 评估精准测试结果 ：精准分析评估反馈，建立闭环
|
||
|
||
● 发现测试死角 ： 找到应该覆盖，但未覆盖的代码
|
||
|
||
● 标记冗余代码 ：为RD删代码提供数据参考
|
||
|
||
● 代码准入门槛 ： 增量覆盖率指标衡量RD自测程度
|
||
|
||
● 问题自动排查 ： 提供用例执行轨迹跟踪
|
||
|
||
● 建立更可信的自动化测试
|
||
|
||
#### 用例代码双向追溯技术
|
||
|
||
每一个测试用例与代码之间都拥有双向追溯能力，量化测试数据，不再依靠个人的主观判断。
|
||
|
||
#### 用例代码染色技术
|
||
|
||
用例代码染色技术智能分辨用例与代码之间的关联关系，细到每一个分支，每一个节点，让测试结果精准可信赖。
|
||
|
||
|
||
|
||
#### 用例代码覆盖率技术
|
||
|
||
采用白盒级的代码覆盖率来衡量测试的充分性和完整性。通过统计代码覆盖率找出潜在的遗漏测试用例，并有针对性的进行补充，同时还可以识别出代码中那些不可达的废弃代码。
|
||
|
||
覆盖率度量有不同的类型，但是大多数工具都关注行覆盖率，除了提供行覆盖率，仍然提供分支覆盖率、方法覆盖率，测试人员可以使用覆盖率数据来评估与功能测试有关的领域，
|
||
促进质量风险缓解。覆盖率测量为有效的测试过程提供了深度和精确度。
|
||
|
||
### 精准测试在测试流程中的体现
|
||
|
||
精准测试在整个迭代版本的测试生命周期中不同阶段的均有不同的价值输出。
|
||
|
||
|
||
|
||
|