为什么选择仿真环境？

一、金融业务质量面临的挑战

蚂蚁本质上是一家带着浓厚金融属性的互联网公司，尤其作为持牌金融的数金业务，金融属性更强，业务复杂度也更高。蚂蚁的金融业务的复杂度高主要体现在：蚂蚁金融业务体量巨大、蚂蚁和金融业务本身对业务高质量要求，以及互联网+金融业务自身的高复杂度。

1）蚂蚁金融业务体量巨大。这个不用多说，蚂蚁全球服务着超过10个亿用户，数字金融也有x亿以上的用户，每天发生着亿笔以上的交易，单笔交易金额可能会超过数十万，在这样的用户体量下，任何细微的错误，给公司带来的伤害、修复成本都是巨大不可估量的。

2）蚂蚁金融业务本身质量的高要求。蚂蚁对业务质量的要求之高，用"苛刻"来形容也不为过，要求业务7*24小时可用，同时对资金要求绝对正确性，1分钱的资损就是P2故障。正是这种对用户资金安全的“苛刻”追求，也才能激发出我们质量技术人，对高质量交付孜孜不倦的追求。

3）互联网+金融 混合业态属性的高复杂度。生命周期长：金融业务相比互联网其他业务来说，一个非常大的特点就是生命周期长，只要有1个用户在线上，这款金融业务就无法真正从系统上进行下线操作，这将导致账户状态不断。互联网业务规则多且复杂：业务部门为了满足尽可能多的用户金融需求，会大量提出新的产品、新的业务功能、新的业务规则等，同时淘汰部分旧的产品，导致业务规则多。数据状态多：数亿的用户，在新老产品、业务规则下，产生了巨大的数据，这些数据长生命周期存在，数据状态影响着系统行为。整体金融业务高复杂度体现在，业务场景组合多：账户状态*业务产品*业务规则*数据状态，以花呗支付单个业务为例，这样的业务场景组合达到1w+

蚂蚁的金融业务的高复杂度、高要求、大体量，对于我们质量来讲，挑战巨大，并且随着整改带来的数据断流、多云多主体架构等改造，使得系统链路的复杂度成倍增长，进一步加剧对质量和技术风险的挑战。

二、现有测试模式遇到的困境

我们先回顾一下我们现有测试模式有哪些，主要有两种：

1）人工+自动化测试：人工识别定义出测试场景，将重复率高的工作尽可能实现自动化，比如造数、用例自动化、校验等等，这个模式极度依赖经验，几乎所有环节都必须依赖，这个几乎是当下最可靠的模式，但是这个模式经常会问题遗漏，一种是评估遗漏，人未识别到该场景，另一种是执行遗漏，分析到这个场景但是评估无影响不需要执行导致遗漏

2）录制回放类测试：主要代表是doom、回声墙，通过积累线上一段时间的流量，采用全mock的模式，进行单系统的流量回放，在一定程度上解决了单系统回归的问题，不能解决全链路的测试问题，叠加上每次代码改动都需要大面积配合修复用例，使用成本高，所以渐渐的这类回放系统缩小覆盖范围，只适合覆盖特定业务的回归场景。

第一种模式重度依赖人的业务经验和能力，这种模式工作到现在守底盘没有太大问题，未来该怎么面对如此庞杂的业务，保障业务不出问题？

第二种模式单系统的流量回放，已经被证明只能在某些特定领域（比如决策类系统）才能发挥作用，难以具备大面积使用的能力。

当集团开始all in业务增长时，我们质量如何才能支持业务复苏带来的快速迭代诉求？我们的测试模式如何进行创新和突破才能带来质的飞跃？

三、随着未来挑战逐步加大，我们该如何重新定义测试模式

在回答这个问题之前，我们先看一下测试的本质是什么？我认为测试本质就是控制风险，而控制风险的方式就是保障每个业务场景的正确性。那我们面临的问题就可以转化为：

1、知道（定义/识别）每个业务场景；

2、构造/执行 每个业务场景；

3、验证每个业务场景；

4、覆盖所有业务场景的效率和成本；

四、关于下一代测试模式的思考与实践

我们将测试保障的问题定义为保障每一个场景的正确性，那我们期望的测试模式该如何。

我们最理想的测试模式是什么样？测试可以分为回归和测新2大部分。回归：已经发生过（线上）的业务，在迭代未发布之前，可以自动覆盖我们期望验证的用例，而又不影响线上用户，达到0成本自动覆盖回归。测新：期望能在系统未变更之前，就用线上真实的用户（账号+数据）模拟出变更发布后的系统表现，甚至是业务效果表现。

要实现这样的理想测试模式，并不容易，线上数据和真实流量一直是我们测试无法在线上环境突破的屏障。直到技术风险部推出仿真环境，让线下拥有生产上丰富的数据和流量、稳定的执行环境，对于测试来说，它拥有着测试需要的一切基础条件，它有改变甚至突破我们现有测试模式的机会，剩下的就是如何利用仿真环境来保障每一个场景的正确性。

我们提出了第三种测试模式：以仿真环境作为基础设施，场景为核心的新一代测试模式

图1 测试模式升级

通过对线上的流量采集、分析，刻画出等同于线上的（累积）场景分母，通过引线上的流量，或者构造出类线上的流量，来覆盖我们需要测试的场景，并且整个过程自动化，不仅可以覆盖全被测系统/业务的场景，而且更加高效。

图2 测试模式对比图

      上图是几种测试模式的对比，过去一年我们以仿真环境作为基础设施，场景为核心的新一代测试模式进行了探索，并且在数金各bu的业务逐渐进行了落地。

图3 数金各BU使用效果

在测试模式落地的同时我们沉淀了平台能力。平台能力里有2个核心，一个是场景，场景代表的分母，场景分母的充分性决定了我们的上限，另外一个执行域，有了场景如何进行流量覆盖，执行域决定了最终的交付——到底覆盖了多少用例。场景域部分，我们通过对系统接口的出入参、db、子调用、代码路径等进行特征刻画，以及引入专家经验特征圈选和目录树的产品解决方案，非常好的对专家经验与无语义的特征组合形成关联，解决了场景理解问题，前期通过专家经验指导场景算法特征建模，来优化场景的分母确定，后续随着算法的迭代优化，将逐渐减少人的投入。执行域部分，我们围绕着场景覆盖这个命题，打造了一套引流/造流能力，目前在已有的场景中心分母的情况下，已经可以做到50%的场景自动覆盖率，未来我们会将50%提升到95%甚至100%，这代表这我们未来测试回归工作可以不需要人投入。

图4 数金仿真平台逻辑架构域划分

图5 执行域 场景覆盖率现状和目标

纵然仿真环境目前无法做到开箱即用，目前依然有种种的问题，比如链路的连通性、链路的稳定性、数据同步的限制性、流量的丰富度低等等，但是我们明确的知道现有以人经验为核心的测试模式，在人力成本叠加业务复杂度的情况下，未来这种模式一定不可持续：漏测导致业务受损，测试周期无法满足业务需求被diss，测试人员疲于应付迭代需求导致发展受限。我们看到仿真环境之后，坚信以仿真环境作为基础设施，场景为核心的新测试模式必将颠覆我们已有多年的旧测试模式，在产能上大大提升我们的生产力，也能更好的保障业务风险底盘。同时新一代测试模式也将成为我们的新的测试基础设施，将我们的质量工作标准化、数据化，为智能化测试铺平道路，chatgpt已经在加速引领着各行各业的智能化变革，对于我们来讲，“变则新,不变则腐;变则活,不变则板”。当前我们打造的新的测试模式依然有很多问题要去定义和解决，真诚期待更多的人能参与进来共同建设、共同成长，一起推动下一代测试模式的变革。

最后特别感谢 俊义、小瑕、泽火、鸣野、睿枢、术赤对业务仿真项目的指导与支持，感谢业务仿真项目组、蚂蚁仿真基础设施的所有小伙伴付出与坚持，以及所有业务仿真平台的用户大大们，正因为大家的一起努力，朝着一个目标搀扶前进，我们才有可能真的去改变这个测试行业，变成测试行业技术变革的引领者。

关注「阿里巴巴技术质量」阅读更多