测试不趁早，“持续测试”搞不好

一说起 DevOps，闯入脑海的就是 CI/CD（Continuous Integration/Continuous Delivery，即持续集成和持续交付）。

但是，要想构建能够支撑起数字化转型要求的软件研发能力，与之适配的软件测试能力必不可少。

随着敏捷宣言的发布，业界开始提倡测试驱动开发、验收测试驱动开发，开始关注自动化测试，加强测试工具和测试框架的开发，尽可能做到回归测试自动化、测试管理自动化。

而 DevOps 的兴起之后，人们更是要求测试要有“左移”和“右移”的能力，还要求在线测试（Test in Production，TIP）等。

于是，Continuous Testing（持续测试）走进我们视线中。

01 测试已死？“持续测试”才是未来

在 GTAC 2011 的一场名为《测试已死》的演讲中，Alberto Savoia 描述了几个测试人员必须要面对的开发趋势：

首先，所有的 checking 工作（包括 validation 和 verification）都可以自动化；其次，随着云计算出现，部分用户可以在云上对开发版本做出测试；最后，开发者自己做测试几乎是不可避免的趋势。

在演讲中，Alberto Savoia 认为传统的 QA 方式隔离了开发和测试并不合理

在传统测试方法中，测试团队通常采用的实践是：测试管理- 规划测试工作-识别需要的测试-创建手动测试-收集现有测试-执行测试-跟踪和报告测试进度。

因此，传统测试需要关注的是：测试工作是否按计划完成？

其中的缺点也是显而易见的。首先，手动运行所有测试是低效或无效的，在许多情况下不可行；其次，这个方法并没有服务于软件开发项目，无法创建稳健且可维护的测试自动化框架，没法实现最终的项目目标。

而这些问题在敏捷和 DevOps 时代，得到了足够重视。

敏捷的出现，大大引入了自动化测试的比例。因此，敏捷时期的测试呈现出以底层运行速度快、消耗小的单元测试为主的正三角模式；强调测试持续进行，通过各部门的协同工作，持续发现缺陷并迅速修复。

到了 DevOps 时代，“持续测试”的概念涌现，在这个概念中，测试应该是开发过程的一部分，而不是在开发完成后的“保健”任务。

持续测试是持续交付流水线中的一环，让开发过程可随时且具有连续性的自动化测试流程。但是，持续测试并不等同于自动化测试，而是大于自动化测试。IBM 认为，测试自动化与服务虚拟化的组合称为 “持续测试”。

在整个持续交付流程中，包括了计划、编码、构建、测试、发布、部署、运维和监控 8 个环节，既要求“速度”也要求“质量”。其中，持续测试保障的就是整个开发流程的质量问题。

总的来说，持续测试需要在正确的时机将可行的反馈意见提供给正确的利益相关，侧重于业务风险，并提供有关软件是否可以发布的见解。

因此，持续测试关注的是：提供的有关软件是否可以发布？

02 “持续测试” 的 7 个方法论

“持续测试”虽好，但建立持续测试文化需要投入人员、实践、工具和时间。

1. 持续测试的完整时间，需要取得公司高层的支持，制定清晰的转型战略、建立指导团队。

2. 建设内容包括：研发团队测试能力建设、工具与框架建设以及最佳实践落地。

3. 整个过程需要通过合理量化跟踪体系，去量化持续测试建设的进展和影响。

以下七个方面，是构建持续测试的关键：

1、You can’t continuously if you don’t start testing early.

发现 bug 的时间越早越好。在测试中，尽早发现了风险元素，就可以不断重用这些测试、尽早地直接向开发团队提供代码质量的迭代式反馈。

在生命周期中，更早和更频繁地执行测试（“提前测试”），使团队能够持续地编译、部署、测试和收集反馈。

而在生产中发现问题时，不仅解决成本非常高，而且可能严重损害公司的声誉，甚至对客户忠诚度产生持久的影响。如果没有及时的测试和反馈，公司就无法真正地快速提高质量。

2、开发级测试至关重要

在一定程度上，开发与测试的确日渐融合，这样可以确保开发得到快速的反馈，而且保障了结果符合预期。

在持续集成中，们测试反馈越及时，越来越多的测试操作，例如静态或者动态分析、security checks、API validation……越可能被纳入其中，被集中的信息越丰富，项目的结果就越有保障。

3、自动化是提速降本的利器

执行过程要达到“足够快”，以满足整体迭代的效率。这要求每个阶段都引入尽可能多的自动化工具和能力。比如，云平台提倡基础设施即代码（IaC）和容器领域的编排技术（以 K8s 为代表）都在一定程度上实现了环境的自动化部署。

近来，国内外也涌现了不少针对测试的自动化工具及平台。以国内的飞算 SoFlu 全自动软件工程平台为例，近期上线的全自动测试平台主要通过创建项目—创建测试用例—编辑测试场景—创建测试计划—接口测试—性能测试这 6 步流程来实现。

据了解，该平台具备三大特性：一是测试生命周期管理。它提供测试用例管理、测试用例评审、测试计划跟踪和测试报告生成等测试生命周期管理相关功能。二是测试数据管理。全自动测试平台基于测试脚本与测试数据分离的思路，方便研发测试协同、方便自动化测试中的测试数据使用，支持 UI、接口等自动化工具中快速可重复地使用。三是精准回归测试。它在项目测试时，可以自动识别所有变动接口，自动查找接口关联的所有测试用例，进行精准回归测试。

值得注意的是，全自动测试平台随其全自动开发平台联动，开发测试一键关联，自动生成测试用例完成软件测试，1 人就即可完成开发、测试整套流程。

https://www.feisuanyz.com/testv/

4、服务虚拟化是稳定性的重点

用户被测系统通常并不孤立存在，它依赖各种外部系统才能正常运行。但是在测试环节中，这些外部系统依赖可能会因为各种原因而不具备支持持续测试正常运行。

服务虚拟化是解决自动化测试中外部依赖不稳定或者不可得的关键手段。

服务虚拟化需要能够快速、准确地模拟外部依赖系统。从而，只需明确测试需求，而不需要太多关注真实的业务逻辑。此外，服务虚拟化尤其注重自身的稳定性。它的初衷是解决外部系统依赖的稳定性和可获得性，如果其自身不够稳定，就无法支撑持续测试的高效、高频运行。

5、快使用虚拟机和容器技术

虚拟机通过机器镜像解决整个运行机器的环境管理，而容器技术则采用更为轻量的运行时封装模式构建。

这样就可以屏蔽业务系统依赖的底层基础设施差异，研发团队只需要管理好虚拟机和容器的镜像版本，基本就能保障多个测试环境的一致性。

目前，好用的容器包括 Docker、 Mesos 或者 LXC 等等，他们大多都拥有很高的适配性。

6、从产品的角度开展测试

正如前文所述，充分考虑到产品最终形态，也就是产品偏向，是“持续测试”的特点之一。因此，在测试设计阶段，就应该开始向生产思维的配置靠近，去模拟产品类似的测试氛围。

7、逐步进化测试数据管理

如何处理好测试数据，往往是一个重大的挑战。很多情况下，人们不知道什么样的数据是测试所需要的、什么样的数字管理是好的。

简单来说，测试数据管理随着 DevOps 实践的深入程度，呈现出 4 个阶段：

第一阶段：测试数据以个人管理为主，生成机制随机，质量无法保障。

第二阶段：通过文件或者数据库形成初步的测试数据集中管理，但是无合理的版本管理机制，无数据生成和质量保障机制。

第三阶段：有集中的测试数据管理平台，平台数据进行合理的版本管理，有较为丰富的数据生成和生产数据脱敏机制，数据质量稳定。

第四阶段：测试数据集中管理，数据版本和质量可靠，测试数据与测试用例和自动化测试场景形成良好关联和互动。

当然，随着持续测试实践的程度越高，我们所要求的测试数据管理能力自然也就越高。