测试之道测试发展之路

Posted 2022-05-17 sysu_lluozh

一、测试团队面临的困局

随着互联网的发展，持续集成及DevOps等软件工程方法的提出和普及，软件测试技术也发生了很大的变化。自动化测试、敏捷测试和测试左移等方法论被广泛应用于实践，研发团队对测试技术和测试团队有更高的期待。与此同时，测试团队也面临着不少的困难，其中具有普遍性的有：

• 测试自动化难

自动化测试程序编写成本高、执行成本高、维护成本高。测试的技术债在业务高速发展的过程中越积越多：

1. 一边修复老的用例，另一边出现新的失败用例
2. 一边补充自动化，另一边又因为项目的时间压力遗留了未自动化的用例

一些可以自动化完成的功能，回归测试还得依赖手动测试，效率低、问题遗漏多

• 测试结果的噪声大

回归测试的通过率比较低，每次回归测试都需要排查大量的失败用例，大部分的失败都是由于测试环境及相互干扰，而不是被测服务的缺陷引起，这样导致测试人员很难获得成就感
另外，测试结果的噪声多次导致回归测试已经发现的问题在排查中遗漏，变成线上问题

• 测试不充分

测试分析和用例枚举非常依赖测试人员的经验和业务领域知识，测试人员很容易出现测试遗漏。同时，缺少有效的技术手段度量和提升测试的充分性

• 测试人员对自身成长的焦虑

测试团队的困局导致测试人员需要把大量的时间花在各种重复工作和琐事上，没有时间和精力提升自身能力、追求技术创新，也缺少沉淀积累

二、理解测试的本质

2.1 代码门禁

开发人员一般都是通过git push origin命令将代码直接提交到远程的项目分支和迭代分支。虽然一直明确要求开发人员必须确保代码在本地编译及通过所有的单元测试和接口级别的功能测试后才能提交，但偶尔有些开发不遵守这个规定。而且由于环境的差异，有些代码能在本地通过测试，但是在其他地方运行还是会失败，代码门禁可以彻底杜绝这些问题
代码门禁的做法如下：

• 在公共分支(包括项目分支、迭代分支、主干分支、紧急发布分支)上，禁用git push，只允许通过pull request来提交代码
• 研发平台对每个提交到公共分支的pull request都会执行各项检验，包括编译、单元测试和接口级别功能测试、静态代码扫描。只有通过这些检验，pull request才能够被合并

代码门禁就是简单地把持续集成前移：从代码提交后提前到代码提交前
简单的前移，彻底改变了研发模式，从以前的"先欠债再还"变成"每个代码提交都不能欠债"

门禁虽然很重要，但是还必须做一些关键的优化才能有效的推广：

1. 缩短时间

• 制定代码门禁的测试执行时间的目标。要求每个微服务代码门禁执行时间都不超过10分钟
• 基于MariaDB4j的本地数据库方案，解决了被测代码对远程数据库的依赖问题
• 精准测试，只运行和变更代码相关的用例。记录每个用例的代码覆盖的详细数据，当代码门禁测试开始时，基于这些数据反查出和变更代码相关的用例

2. 提高稳定性

• 制定代码门禁的测试稳定性的目标，即90%的成功率。也就是说整个测试用例集如果执行100次，其中至少有90次是通过的
• 本地数据库方案和精准测试提高稳定性。使用精准测试后执行的用例数量降低，出现噪声的可能性也降低

2.2 测试的本质是反馈

代码门禁是测试团队打破困局的第一步，但远远不是全部。在进一步阐述破局的思路前，有必要先弄清楚测试的本质

测试的本质是反馈，就是回答一个问题：代码是不是好的
这里的好的定义并不是一成不变的，对于不同的需求，好的定义和标准都是不同的。换句话说，测试的目的是提供质量反馈，为整个软件开发过程中不同的节点提供以下3个用于决策的质量反馈

• 代码门禁中的单元测试和接口测试接口，为判断是否可以接受代码提交提供决策依据
• 功能回归的测试结果，为判断是否可以将当前版本的代码推进到预发布和灰发验证阶段提供决策依据
• 预发布环境和灰度验证的结果，为判断是否可以将当前版本的代码进一步部署到整个线上环境提供决策依据

只要测试是足够全面、结果是足够可信，且所有测试都通过，就可以直接做出决策。希望减少对人的经验、知识和判断的依赖。一个组织一定会不断的新陈代谢，一个人能了解整个系统的各种细节和一块业务的方方面面的可能性越来越低

测试团队是从缩短提供反馈的时间、降低提供反馈的成本和提高反馈的可信度三个维度来提升测试反馈能力，这三个维度既是质量视角，也是效能视角

2.3 效能提升对质量的作用

有人认为质量提升和效能是一对矛盾体，要提升效能就要牺牲质量，要提高质量就要牺牲效能。其实质量和效能并不是一对矛盾体，而是既要…也要…的关系。效能提升可以让我们更快地得到反馈，以更快的节奏去迭代和试错

2.3.1 效能提升对提高质量的直接作用

• 效能提升能够让代码中的质量问题更及时地暴露出来
  例如用例执行到BUG A抛错，直到BUG A修复，用例才能继续执行，之后遇到BUG B，其实BUG B早就存在，只是一直被BUG A掩盖

• 效能提升能够让代码的质量问题更容易地暴露出来
  可以让质量问题暴露，而不是淹没在各种噪声中。例如接口测试或者全链路回归的确出现了问题，但是由于信噪比长期很低，有效信号很容易被开发人员和测试人员忽视

• 更完善的工具和基建，能够直接减少人为错误的发生

2.3.2 效能提升对提高质量的间接作用

• 降低心力、脑力的负担
  在项目周期长、多个项目并发的情况下，测试工程师每天都要在各个项目之间频繁进行上下文切换，对心力和脑力都是极大的负担，不免挂一漏万，增加了漏测和未能识别的潜在风险存在 的可能性

• 提升测试开发人员的价值
  工具和基础建设做的更好，可以把花在解决比较低级问题上的时间节省下来，用在对测试和质量有更大价值的地方。反过来，质量的提高可以让我们更有信心用更少的资源、更短的时间做出决策和判断

2.4 破局的方向

在对测试困局进行破局的过程中，以及未来的道路上，做的工作基本上都可以映射到反馈的时间、成本和可信度3个维度上

2.4.1 缩短反馈弧(时间)

• 测试用例向测试金字塔的下层迁移
• 提高测试并发执行的能力
• 减少数据准备的时间，既要能够更好的复用测试数据，又要避免因测试数据复用导致的测试不稳定
• 打造精准测试能力，能够自动准确地剔除无关的用例
• 能够通过对测试用例有效性、代码覆盖率和业务覆盖率的准确度量，帮助更好地进行等价类分析，对测试用例集进行持续瘦身，避免用例集不断膨胀

2.4.2 降低反馈成本

测试用例向金字塔的下层迁移，将更多的测试用更快、更省资源的小型测试实现，精简测试用例、只运行相关的用例，通过缩短测试执行时间来减少对资源的占用
从硬隔离向软隔离转变，用更多的逻辑隔离替代实例隔离

2.4.3 提高反馈可信度

• 提高测试的可信度，降低测试结果的噪声
• 提高测试的代码覆盖率和业务覆盖率
• 提高测试的有效性
• 自动生成测试用例
• 减少人工进行测试分析和罗列测试用例产生的测试遗漏

在以上3点中，缩短反馈弧是关键

三、测试的提升

3.1 缩短反馈弧

3.1.1 为什么缩短反馈弧是关键

没有度量就没有改进，其实这句话是不完整的。度量对于改进的作用是给出反馈，但是光有度量还不够，还要度量得足够频繁、度量得足够快，这样才能更有效地改进
工作中有很多例子：

• 线上变更强调可监控
  做了一个变更，如果能马上得到高质量的反馈(高质量的反馈=监控覆盖率高+噪声低+阈值设定得合理)，就非常有助于判断这个变更是好的还是不好的。因此，缩短反馈弧非常有助于及时发现问题、及时采取对策

• 业务试错也是反馈
  试错就是试一下，看看错不错，如果错了就掉头，如果对了就继续投入。快速试错要求缩短业务效果的反馈弧。没有试错能力，就是反馈弧长

3.1.2 怎么才算反馈弧短

反馈弧短不短，可以从两个方面衡量

• 反馈的前置等待时间
  理想状态是：反馈不需要等，任何时候想要反馈都可以
• 反馈本身的耗时
  理想状态是：反馈本身的耗时很短，结果立等可取

一名开发人员，写好一行代码，想知道这行代码有没有问题，这就是反馈
把某个功能需要的代码写好，现在想知道这个功能是不是能工作，代码还要不要改，这也是反馈

在有些团队里，这些反馈弧还很长，长在两个方面：
一个是要等，不是任何时候想要得到反馈都可以
一个是反馈本身耗时长、成本高，结果也不是立等可取的

反馈弧一长，开发效率就降低。在一些团队中，反馈弧在开发联调中体现为：

• 反馈不是随时随地的，要等
  因为反馈不是随时随地都可以发起的，也不是每个人都知道怎么发起的，只有特定的人员才知道怎么发起

• 反馈不是立等可取的
  就算发起了反馈，还要找一个个域的人员校验数据。同时，反馈的质量因人而异，因为校验是人做的，不同人校验的方法是不完全一样的

平时一直做各种动作，比如改代码，给数据库加字段、修改DRM值、在数据库中插入数据等。持续集成就是在这些动作发生之后，尽可能快的给出反馈，缩短反馈弧
持续指反馈要随时随地都可以得到，自动化是缩短反馈弧的必要条件(但不是充分条件，此外还包括覆盖率、充分性、有效性等要素)
如果还有人工步骤，就不可能做到反馈弧很短，因为人是不可能随时随地都能一呼即应，而且人的动作也很难控制的

3.1.3 缩短反馈弧的成本和投入产出比

要缩短反馈弧，就要建设持续集成
虽然持续集成的确需要投入成本，但是不仅要看到建设持续集成的投入，也要看到回报。这个做好，能节省多少时间，在缩短反馈弧上投入的成本是能从其他地方收回来的

对于每个项目来说，如果每个联调用例和校验都有自动化的投入，在项目进行的过程中就会有回报。比如，人工做一次校验可能需要15分钟，而校验自动化需要2小时(包括自动化及后期的维护成本)，只要整个项目过程中校验超过8次，自动化就是划算的，而且如果实现自动化，校验就会执行很多次，因为希望可以随时随地得到反馈
另外，随时随地做校验、随时随地地得到反馈，还有一个好处，就是能让排查问题变得很方便

不能孤立地看待投入在建设持续集成上的成本。如果只从单个开发人员的视角看，那么也许在某些情况下，用原来的方式对个人更方便。但在更多情况下，个体收益往往导致群体受损，进而导致每个个体都受损。相反，个体做出一些小的付出，会导致整个群体受益，也就是让每个个体都受益

3.2 提升测试的稳定性

很多测试团队面临的最大难题就是自动化测试的通过率低、噪声大。在理想情况下，希望每个失败的测试用例都是由真正的缺陷引起的。但在实际情况是，自动化测试经常因为其他原因导致失败，例如：

• 同时执行的用例之间相互影响
• 人对测试环境的影响
• 测试环境底层基建的不稳定
• 测试环境里的脏数据
• 测试用例本身有问题

自动化测试稳定性差带来的后果：

• 失败用例的排查工作量非常大

• 对自动化测试丧失信任和信心

• 如果发现大部分失败用例都是由于非代码缺陷原因，有些人员就不会重视，这样很多真正的缺陷就会被遗漏

• 更多的问题被掩盖

接下来重点讲述如何达到和保持很高的测试稳定性，提升测试稳定性有三斧子半的招式：第一招 ---- 高频，第二招 ---- 隔离，第三招 ---- 用完即抛，最后半招 ---- 不自动重跑

3.2.1 高频

高频之所以排在第一位，是因为它不但对提高测试稳定性有奇效，也有很多其他软件工程中解决问题的方法