阿里QA导读：在软件研发过程中，发布前跨多个系统的联调测试是不可或缺的一环，而在联调过程中，经常会遇到一些比较棘手的困难，阻塞整个联调进程。其中比较典型的有：第三方的研发节奏不一致，导致无法联调；下游的业务异常难以构造，待测系统的处理逻辑无法验证；其它的一些异常场景，例如下游超时等。这些问题如何解决呢？阿里巴巴高级测试开发专家雨清带来了他的解决方案。
以上的具体场景都发生在应用发布前的联调阶段，其实在发布后，线上质量保障部分也同样存在一些难以验证的场景，例如：核对脚本无验证直接上线，日志监控无验证等。
痛点小结：
请求异常场景难以构造：消息乱序、并发场景等；
下游超时场景难以构造：超时成功、超时失败等；
研发节奏不一致，下游应用没有开发完毕，无法联调；
下游的业务异常难以模拟；
线上质量，实时核对脚本，由于线下“异常数据”难以构造，往往没有验证直接上线；
线上质量，日志监控，由于“异常日志”难以构造，监控配置后无法验证。
简单来说，质量保障过程中存在非常多的“不可测”场景，而此类场景如果被忽视往往会带来非常严重的故障。以下游超时场景为例，在电商下单过程中如果出现了支付超时，需要非常谨慎的处理，一旦出现逻辑漏洞就会导致用户资损。更多关于异常场景的分析，可以翻阅本文附录--异常场景分析。
验证平台的出现，就是为了解决上述“不可测”场景，降低联调成本、扩展测试边界。
验证平台(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状态，确保有一个全局的视野，方便用户进行应用维度的管控。
工作流程示意图：
简要流程说明：
server提供了一键式入驻的功能，给应用下发vip-agent并启动。不会阻断应用运行;
在server上创建规则，规则的定义见下一小节；
server下发规则到应用B(待测系统)，并控制启停状态;
应用A发起请求到应用B(待测系统)，规则生效，对特定流量进行增强：构造乱序、并发，构造超时场景，污染DB、日志，mock下游返回等等。
规则定义
规则：一个原子化的增强能力，包含了定位和处理两部分。
规则状态机：
平台使用
极速使用说明
确认服务器地址，一键安装并启动agent；
通过页面创建规则；
通过页面启、停规则。
一个案例
一、部署vip-agent
二、创建规则
选择场景；
填写基础信息：对应的应用名、规则名称、描述；
填写定位信息：类名(实现类)、方法名、方法入参(默认全部)、匹配请求(默认全部)；
三、启、停规则
方案拓展
构造并发场景
平台提供了延迟执行的能力，在特定的请求达到指定的函数后，会暂停指定的时间(延迟执行规则中的延迟时间)，在这个时间段内，另一个请求打到应用中，以此来构造并发的场景。
图中的请求1和请求2不一定是相同的业务类型，例如在电子凭证系统中，可以是一个核销的请求和一个退款的请求同时到来，产生并发。
提前验证实时巡检
实时巡检是通过编写比对脚本，在生产环境进行应用间的数据一致性校验，用以保障生产环境的数据正确性。脚本的触发、运行、结果触达、异常报警等往往由巡检平台提供。巡检脚本往往无法在测试环境进行验证，难点如下。
难点：
构造测试环境全链路的真实数据；
精准污染核心字段；
触发测试环境的待测实时核对脚本。
解法：
vip创建规则，篡改DAL层写入DB的数据；
跑全链路自动化用例，落全链路真实数据；
通过实时核对平台接口触发，运行待测的核对脚本。
下图是一个使用案例，其中关键的几个平台、工具说明如下：
链路级自动化平台：一个自动化开发、运维平台，本案中用于构造测试环境的全链路真实数据；
一键校验工具：触发测试环境的待测实时核对脚本的工具；
实时核对平台：巡检脚本的运行容器；
交易中心：真实应用，控制交易的业务流程；
凭证中心：真实应用，用户购买虚拟商品(券)，最终落成用户名下的电子凭证。
如图所示，虚拟商品交易场景下，交易中心和凭证中心的数据应该是一致的，例如：用户、商户、商品、金额、订单状态机和凭证状态机等。本案的做法为，第一步通过vip创建污染DB数据的规则，并使之生效；第二步，通过自动化平台发起购买流程，在凭证中心往DB写用户名下的电子凭证时，vip-agent会篡改部分数据，导致凭证中心和交易中心的数据不一致；第三步，运行“待测的巡检脚本”，通过脚本是否校验出数据的不一致，来检验脚本本身是否符合预期。
vip还支持非常多的其它场景，不再一一赘述。
异常场景分析
系统调用抽象
如果把系统中的一次核心的逻辑处理看作一个“业务操作”，那么一次服务系统被调用的过程大致可以划分为三个部分：业务处理前，业务处理中，业务处理后。
业务处理前，系统主要的过程可以划分为：参数校验和幂等校验。参数校验，验证服务调用方传入的参数是否符合要求，类型是否正确、必填的参数是否都填了、非0校验等；幂等校验，验证请求是否是合法的，例如由于网络抖动等原因引起的重发，可能调用方发起了一次服务调用，而SUT(被测系统)却收到了两次一样的请求。
业务处理中，SUT(被测系统)具体处理业务逻辑的过程，可以归类为：业务校验、业务处理、数据持久化。业务校验是基于业务层面的校验，例如付款时，需要校验用户余额是否充足等；业务处理是程序中正式处理数据和计算的部分，例如从用户余额中扣除资金并增加到商家账户中等；数据持久化就是将数据落到数据库。
业务处理后，SUT在完成业务处理后，根据处理的情况：是否成功，失败的原因等，组装结果，返回给服务调用方。
异常用例设计
主要的异常场景分类：
业务处理前：入参异常、幂等异常；
业务处理中：业务异常、下游异常、DB异常；
业务处理后：返回异常。
下图所示模板从左向右依次细化异常场景，直至到一个具体的案例，因此每个叶子节点对应了一个用例。该模板方便使用者有体系化的进行异常场景测试用例设计。
说明：“异常用例设计模版”已获国家发明专利授权(注意：可以借鉴但不要随意使用～)：CN109240908B
