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

痛点小结：
服务器

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

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

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

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

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

• 线上质量，日志监控，因为“异常日志”难以构造，监控配置后没法验证。运维

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

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

验证平台（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. 经过页面启、停规则。

一个案例

1、部署vip-agent

2、建立规则

1. 选择场景；

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

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

3、启、停规则

方案拓展

构造并发场景

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

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

提早验证明时巡检

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

难点：

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

2. 精准污染核心字段；

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

解法：

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

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

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

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

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

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

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

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

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

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

vip还支持很是多的其它场景，再也不一一赘述。

异常场景分析

系统调用抽象

若是把系统中的一次核心的逻辑处理看做一个“业务操做”，那么一次服务系统被调用的过程大体能够划分为三个部分：业务处理前，业务处理中，业务处理后。

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

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

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

异经常使用例设计

主要的异常场景分类：

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

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

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

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

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