以上的具体场景都发生在应用发布前的联调阶段，其实在发布后，线上质量保障部分也同样存在一些难以验证的场景，例如：核对脚本无验证直接上线，日志监控无验证等。

痛点小结：

• 请求异常场景难以构造：消息乱序、并发场景等；

• 下游超时场景难以构造：超时成功、超时失败等；

• 研发节奏不一致，下游应用没有开发完毕，无法联调；

• 下游的业务异常难以模拟；

• 线上质量，实时核对脚本，由于线下“异常数据”难以构造，往往没有验证直接上线；

• 线上质量，日志监控，由于“异常日志”难以构造，监控配置后无法验证。

简单来说，质量保障过程中存在非常多的“不可测”场景，而此类场景如果被忽视往往会带来非常严重的故障。以下游超时场景为例，在电商下单过程中如果出现了支付超时，需要非常谨慎的处理，一旦出现逻辑漏洞就会导致用户资损。更多关于异常场景的分析，可以翻阅本文附录--异常场景分析。

验证平台的出现，就是为了解决上述“不可测”场景，降低联调成本、扩展测试边界。

验证平台（VIP）Verification  Platform

目标：

一个简单通用的提供异常场景测试、mock能力的辅助测试平台。

架构设计

验证平台由两部分组成，server和agent。其中agent部署到应用服务器上，并通过jvm attach的方式关联上应用进程，从而实现基于函数+精准流量粒度的字节码增强；server 独立部署，管控了agent、服务器、规则等核心实体，提供操作页面和hsf接口服务，支撑手工联调以及自动化。

• vip-server核心能力：应用入驻、服务器管理、规则管理、agent管理等。

• vip-agent核心能力：规则解析、规则启停、服务器信息采集、心跳、增强报告等。

• 支持的场景：超时异常、请求异常、污染数据、mock。

工作原理

vip-server端，负责创建和维护规则，同时通过应用维度来管理相关的线下、预发服务器，监听agent的心跳和增强报告。

vip-agent不持久化规则，实时监听server的指令，并定时（默认30秒）上报心跳，以及命中规则后上报增强报告。

以此来确保服务端的规则全局唯一，不会产生串扰，同时规则可以灵活的复用。同时服务端通过心跳来监控所有的agent状态，确保有一个全局的视野，方便用户进行应用维度的管控。

工作流程示意图：

简要流程说明：

1. server提供了一键式入驻的功能，给应用下发vip-agent并启动。不会阻断应用运行;

2. 在server上创建规则，规则的定义见下一小节；

3. server下发规则到应用B（待测系统），并控制启停状态;

4. 应用A发起请求到应用B（待测系统），规则生效，对特定流量进行增强：构造乱序、并发，构造超时场景，污染DB、日志，mock下游返回等等。

规则定义

规则：一个原子化的增强能力，包含了定位和处理两部分。

规则状态机：

平台使用

极速使用说明

1. 确认服务器地址，一键安装并启动agent；

2. 通过页面创建规则；

3. 通过页面启、停规则。

一个案例

一、部署vip-agent

二、创建规则

1. 选择场景；

2. 填写基础信息：对应的应用名、规则名称、描述；

3. 填写定位信息：类名（实现类）、方法名、方法入参（默认全部）、匹配请求（默认全部）；

三、启、停规则

方案拓展

构造并发场景

平台提供了延迟执行的能力，在特定的请求达到指定的函数后，会暂停指定的时间（延迟执行规则中的延迟时间），在这个时间段内，另一个请求打到应用中，以此来构造并发的场景。

图中的请求1和请求2不一定是相同的业务类型，例如在电子凭证系统中，可以是一个核销的请求和一个退款的请求同时到来，产生并发。

提前验证实时巡检

实时巡检是通过编写比对脚本，在生产环境进行应用间的数据一致性校验，用以保障生产环境的数据正确性。脚本的触发、运行、结果触达、异常报警等往往由巡检平台提供。巡检脚本往往无法在测试环境进行验证，难点如下。

难点：

1. 构造测试环境全链路的真实数据；

2. 精准污染核心字段；

3. 触发测试环境的待测实时核对脚本。

解法：

1. vip创建规则，篡改DAL层写入DB的数据；

2. 跑全链路自动化用例，落全链路真实数据；

3. 通过实时核对平台接口触发，运行待测的核对脚本。

下图是一个使用案例，其中关键的几个平台、工具说明如下：

• 链路级自动化平台：一个自动化开发、运维平台，本案中用于构造测试环境的全链路真实数据；

• 一键校验工具：触发测试环境的待测实时核对脚本的工具；

• 实时核对平台：巡检脚本的运行容器；

• 交易中心：真实应用，控制交易的业务流程；

• 凭证中心：真实应用，用户购买虚拟商品（券），最终落成用户名下的电子凭证。

如图所示，虚拟商品交易场景下，交易中心和凭证中心的数据应该是一致的，例如：用户、商户、商品、金额、订单状态机和凭证状态机等。本案的做法为，第一步通过vip创建污染DB数据的规则，并使之生效；第二步，通过自动化平台发起购买流程，在凭证中心往DB写用户名下的电子凭证时，vip-agent会篡改部分数据，导致凭证中心和交易中心的数据不一致；第三步，运行“待测的巡检脚本”，通过脚本是否校验出数据的不一致，来检验脚本本身是否符合预期。

vip还支持非常多的其它场景，不再一一赘述。

异常场景分析

系统调用抽象

如果把系统中的一次核心的逻辑处理看作一个“业务操作”，那么一次服务系统被调用的过程大致可以划分为三个部分：业务处理前，业务处理中，业务处理后。

业务处理前，系统主要的过程可以划分为：参数校验和幂等校验。参数校验，验证服务调用方传入的参数是否符合要求，类型是否正确、必填的参数是否都填了、非0校验等；幂等校验，验证请求是否是合法的，例如由于网络抖动等原因引起的重发，可能调用方发起了一次服务调用，而SUT（被测系统）却收到了两次一样的请求。

业务处理中，SUT（被测系统）具体处理业务逻辑的过程，可以归类为：业务校验、业务处理、数据持久化。业务校验是基于业务层面的校验，例如付款时，需要校验用户余额是否充足等；业务处理是程序中正式处理数据和计算的部分，例如从用户余额中扣除资金并增加到商家账户中等；数据持久化就是将数据落到数据库。

业务处理后，SUT在完成业务处理后，根据处理的情况：是否成功，失败的原因等，组装结果，返回给服务调用方。

异常用例设计

主要的异常场景分类：

• 业务处理前：入参异常、幂等异常；

• 业务处理中：业务异常、下游异常、DB异常；

• 业务处理后：返回异常。      

下图所示模板从左向右依次细化异常场景，直至到一个具体的案例，因此每个叶子节点对应了一个用例。该模板方便使用者有体系化的进行异常场景测试用例设计。

说明：“异常用例设计模版”已获国家发明专利授权（注意：可以借鉴但不要随意使用～）：CN109240908B