规模化软件开发的必由之路—大规模自动化测试

作者：刘冉

2022 年 5 月 22 日
本文字数：2507 字
阅读完需：约 8 分钟

介绍

过去几十年中，基础系统软件和专业应用软件的规模已经发展到超大型的规模，质量要求也是极度的高，比如数据库（比如 Oracel DB，Postgre DB 等），操作系统（Linux，Windows，Android，iOS 等），虚拟平台（JVM，.NET Framework 等）,科学与工业软件（MatLab，AutoCAD，Cadence，PSCAD 等）都实施了大规模自动化测试的。并且随着软件系统规模的不断增加，自动化测试的规模也会不断增加。随着中国软件的崛起，出现了越来越多的国产基础系统软件和专业应用软件，而这些软件势必需要实施大规模自动化测试。针对大规模自动化测试，一般都容易忽略它是一个系统化工程，而不是简单编写和增加自动化测试用例。比如测试 JVM 的 TCK 和测试 Linux 系统的 LTP 等，都是一个完整的软件系统。它一般都拥有一套完整的软件架构设计，从测试驱动层到测试呈现层，从测试管理到测试运行时，从测试主套件到测试插件，包括测试分类与分层，测试用例与测试数据的管理与分析，测试执行与测试结果分析等等。有些特殊的测试系统还需要考虑辅助工具和特定的测试硬件，比如测试 JVM 的 TCK 就需要一套特殊的硬件系统和一个 Relay Server 来测试 JVM 中的短信功能。只有一个独立并且完整的测试系统才有可能较好的实施大规模自动化测试，比如 TCK 包含了上万个自动化测试用例，而 LTP 也包含了几千个自动化测试用例。在业界，这种即完整的既包含测试系统，又包含测试用例和测试数据等的平台还有一个专业的术语，叫 Test Harness。

难点

大规模自动化测试与常规的小规模自动测试相比，最大的难点包括三个：1，就是测试用例和测试数据的管理，2，执行速度快和稳定性高，3，支持插件系统，易于扩展。首先，大规模自动化测试最大的特点就是测试用例和测试数据的数量和类型庞大，所以一定需要对测试用例进行有效的管理。可以通过不同的维度对测试用例和测试数据进行管理，比如可以根据功能进行分类管理，也可以根据测试优先级进行分类管理等。其次由于测试用例规模大，测试系统需要执行速度快，或者支持分布式执行。并且对于稳定性的要求很高，一般不能出现由于测试系统本身的问题而带来的易碎测试。最后，由于测试用例规模很大，有可能需要一些特殊的功能来实现一些特殊的测试和辅助功能，所以测试系统需要支持插件系统，从而可以在需要这些特殊功能的时候通过编写插件来实现。如果使用基于 Serverless 的测试服务化平台，则可以解决大规模自动化测试的许多问题，让大规模自动化测试更容易实施。

问题

当前业界中自动化测试实施所遇到的最大的问题是资源问题，而管理层主要根据投资回报比来决定是否要实施自动化测试或者大规模自动化测试。特别是对于大规模自动化测试，其投资回报比是最为重要的一个因素。因为很多项目的自动化测试无法实施或者中途停止，最为主要的因素就是管理层觉得自动化投入太大，但是没有得到什么收益或者收益不明显，从而觉得实施自动化测试是一种浪费。造成这种情况的原因很多，比如项目质量需求不高，没有动力做自动化测试；或者没有自动化测试经验，不知道应该投入多少资源，所以要么投入过少而导致自动化测试效果不好，要么投入过多，导致投资回报比很多，从而打击管理层做自动化测试的信心；或者无法找到合格的测试工程师，从而无法有效的实施自动化测试，导致自动化测试成本大大增加，并且收益无法达到预期。

对于自动化测试的投资回报率可以从两个维度进行思考，即基于测试本身的维度进行分类，和基于自动化测试和手动测试对比的维度进行思考。首先基于测试本身的维度思考投资回报率，它就等于（自动/手动）测试的价值除以（自动/手动）测试实施的成本。由于测试本身的价值一般是等于没有测试之后出现问题的损失，这是一个后验逻辑，所以很难在出现损失之前算清楚，导致测试本身的价值一直都是一种信念和博弈，很难被精确计算。不过一般情况下，越是重要的软件，价值越大的软件，比如医疗，军工，金融等软件，测试的价值一般都越大，这个共识大家还是有的；对于一些不能直观感知价值大小或者价值大小有待验证的软件，比如初创的一些互联网软件，一些创新性的软件等，连老板或者产品经理都没有办法确定它的价值大小，那么这种软件系统的测试价值就非常难以判断。因此基于测试本身的维度是非常难以计算测试的投资回报率的，但是还是可以基于概率论中的正态分布和隐马尔可夫链总结出来，不过由于实际意义不大，这里就不再赘述。

其次是基于自动化测试和手动测试对比的维度，主要是指项目在认可了测试价值的情况下，已经开始实施手动测试了，然后像计算计算自动化测试相比手动测试的投资收益比，这种需求在现实情况中最为常见，并且计算公式也相对简单。但是这个公式可以计算的前提是已经做了大量的手动测试，并且能获取稳定和明确的手动测试成本数据，不然这个公式也是只能停留在理论阶段。

基于自动化测试和手动测试对比的维度自动化测试投资回报率公式

收益 = 手动回归测试成本 回归测试次数 - 自动化测试基础设施成本 -（自动机测试用例开发和维护成本）*

at.png

这个公式虽然很简单，但是体现了出来了手动测试和自动化测试在收益之间的关系，即随着需要做的回归次数的增加，做了自动化测试后的的收益也会跟着增加。当然，出了这个公式计算的成本，自动化测试还有其他优势，但是劣势也非常突出，即自动机测试用例开发和维护的成本也比较高的，导致很多项目不愿意投入自动化测试。但是对于大型项目，比如像 Chrome，JVM，AutoCAD 等软件系统，需要大规模的团队，并且开发和维护周期也非常长，从而使得手动全回归测试的成本很高，特别是需要持续交付的情况下更是成本更加巨大。其次大规模手动测试耗费的时间很长，往往无法在计划时间内完成全回归测试，特别是发布前的最后一次回归测试，如果发现很多 bug 并修复之后，靠手动是不可能完成全回归测试的，只有冒险发布，这个也是很多靠手动测试的软件有很多 bug 的重要原因之一，而靠自动化全回归测试则是有可能的。