以上的具体场景都发生在应用发布前的联调阶段,其实在发布后,线上质量保障部分也同样存在一些难以验证的场景,例如:核对脚本无验证直接上线,日志监控无验证等。 痛点小结:
简单来说,质量保障过程中存在非常多的“不可测”场景,而此类场景如果被忽视往往会带来非常严重的故障。以下游超时场景为例,在电商下单过程中如果出现了支付超时,需要非常谨慎的处理,一旦出现逻辑漏洞就会导致用户资损。更多关于异常场景的分析,可以翻阅本文附录--异常场景分析。 验证平台的出现,就是为了解决上述“不可测”场景,降低联调成本、扩展测试边界。 验证平台(VIP)Verification Platform目标: 一个简单通用的提供异常场景测试、mock能力的辅助测试平台。 架构设计验证平台由两部分组成,server和agent。其中agent部署到应用服务器上,并通过jvm attach的方式关联上应用进程,从而实现基于函数+精准流量粒度的字节码增强;server 独立部署,管控了agent、服务器、规则等核心实体,提供操作页面和hsf接口服务,支撑手工联调以及自动化。
工作原理vip-server端,负责创建和维护规则,同时通过应用维度来管理相关的线下、预发服务器,监听agent的心跳和增强报告。 vip-agent不持久化规则,实时监听server的指令,并定时(默认30秒)上报心跳,以及命中规则后上报增强报告。 以此来确保服务端的规则全局唯一,不会产生串扰,同时规则可以灵活的复用。同时服务端通过心跳来监控所有的agent状态,确保有一个全局的视野,方便用户进行应用维度的管控。 工作流程示意图: 简要流程说明:
规则定义规则:一个原子化的增强能力,包含了定位和处理两部分。 规则状态机: 平台使用极速使用说明
一个案例一、部署vip-agent二、创建规则
三、启、停规则方案拓展构造并发场景平台提供了延迟执行的能力,在特定的请求达到指定的函数后,会暂停指定的时间(延迟执行规则中的延迟时间),在这个时间段内,另一个请求打到应用中,以此来构造并发的场景。 图中的请求1和请求2不一定是相同的业务类型,例如在电子凭证系统中,可以是一个核销的请求和一个退款的请求同时到来,产生并发。 提前验证实时巡检实时巡检是通过编写比对脚本,在生产环境进行应用间的数据一致性校验,用以保障生产环境的数据正确性。脚本的触发、运行、结果触达、异常报警等往往由巡检平台提供。巡检脚本往往无法在测试环境进行验证,难点如下。 难点:
解法:
下图是一个使用案例,其中关键的几个平台、工具说明如下:
如图所示,虚拟商品交易场景下,交易中心和凭证中心的数据应该是一致的,例如:用户、商户、商品、金额、订单状态机和凭证状态机等。本案的做法为,第一步通过vip创建污染DB数据的规则,并使之生效;第二步,通过自动化平台发起购买流程,在凭证中心往DB写用户名下的电子凭证时,vip-agent会篡改部分数据,导致凭证中心和交易中心的数据不一致;第三步,运行“待测的巡检脚本”,通过脚本是否校验出数据的不一致,来检验脚本本身是否符合预期。 vip还支持非常多的其它场景,不再一一赘述。 异常场景分析系统调用抽象如果把系统中的一次核心的逻辑处理看作一个“业务操作”,那么一次服务系统被调用的过程大致可以划分为三个部分:业务处理前,业务处理中,业务处理后。 业务处理前,系统主要的过程可以划分为:参数校验和幂等校验。参数校验,验证服务调用方传入的参数是否符合要求,类型是否正确、必填的参数是否都填了、非0校验等;幂等校验,验证请求是否是合法的,例如由于网络抖动等原因引起的重发,可能调用方发起了一次服务调用,而SUT(被测系统)却收到了两次一样的请求。 业务处理中,SUT(被测系统)具体处理业务逻辑的过程,可以归类为:业务校验、业务处理、数据持久化。业务校验是基于业务层面的校验,例如付款时,需要校验用户余额是否充足等;业务处理是程序中正式处理数据和计算的部分,例如从用户余额中扣除资金并增加到商家账户中等;数据持久化就是将数据落到数据库。 业务处理后,SUT在完成业务处理后,根据处理的情况:是否成功,失败的原因等,组装结果,返回给服务调用方。 异常用例设计主要的异常场景分类:
下图所示模板从左向右依次细化异常场景,直至到一个具体的案例,因此每个叶子节点对应了一个用例。该模板方便使用者有体系化的进行异常场景测试用例设计。 说明:“异常用例设计模版”已获国家发明专利授权(注意:可以借鉴但不要随意使用~):CN109240908B 你可能还喜欢 关注「阿里巴巴技术质量」阅读更多 |
|