背景介绍
2022年淘宝双11的互动游戏推出三款游戏：单人割草升级、多人组队PK、在线猜题闯关，兼顾了不同用户对休闲娱乐和竞技对抗的差异化诉求。
▐ 玩法核心策略
- 单人割草升级：魔性有趣的核心玩法吸引用户，创造记忆点；操作简单易上手，降低用户学习门槛。
- 多人组队PK：复刻盖楼狂欢，增加竞技的刺激感。
- 在线猜题闯关：每天定时开启价格竞猜玩法，营造大促氛围，打造话题爆点。
核心挑战
▐ 相较于往年大促的变化
- 猜价格玩法流量集中，严格时序，用户有异常退出、提前结束比赛的风险
猜价格每天12点、18点准时发车，用户需要提前停留在页面参与，因此会有集中的流量流入，预计千万量级用户参与。猜价格玩法要求严格时序，依次进行查看题目、提交答案、查看排名、使用复活卡等操作，过程中因用户网络超时或者切后台等原因导致用户没有在规定时间内完成对应操作，导致无法完成比赛。
- IGF游戏化架构重构了PK模型，引入的数据一致性风险
虽然PK玩法相较于过去两年没有明显的变化，但是技术架构的重构依然引入一些新的数据一致性风险和问题：
- 新的序列化协议数据压缩方案：序列化性能、对于某些特定的数据类型是否支撑，数据是否存在丢失的问题
- 新的玩家-战队-房间存储模型设计：今年核心数据首次选择了存储在RDB中，数据迁移过程中的异常重试，并发锁、幂等重试的逻辑需要重新设计，重点保障。
- RDB核心用户资产数据存储的稳定性：数据大小/QPS对存储的性能的影响，RDB对核心资产数据的监控和对账能力保障，数据丢失后的回补能力。
- 实时类互动对端性能要求更高
从端性能问题导致的影响来看，crash，渲染不出来等问题会直接影响到用户行为链路的中断，卡顿会导致用户关键操作的决策、失真，掉电过快等问题会导致用户对游戏品质的质疑从而流失。
从问题发生的概率来讲，这次整个地图渲染的实体更多，端计算存储量增多，更加对端性能提出了更高的要求。
- 割草玩法前端计算和存储，引入的场景覆盖、安全性等新问题
本次单人割草玩法，战斗逻辑写在客户端。战斗逻辑是包括技能逻辑、普攻、属性、伤害、移动、AI、检测、碰撞等等的一系列内容。这块在互动是全新的技术尝试，以往所有的逻辑都是在服务端处理。所以端计算数据存储稳定性&逻辑一致性的验证比以往的要求更高，例如数据丢失后的回档问题。
另外就是安全性问题，以往所有逻辑和数值都是在服务端，如果想作弊，就必须攻击服务器，而攻击服务器的难度比更改自己客户端数据的难度高得多，而且更容易被追踪，被追踪到了还会有极高的法律风险。而帧同步因为所有数据全部在客户端，所以解析客户端的数据之后，就可以轻松达到自己想要的效果，例如 moba 类游戏的全图挂，吃鸡游戏的透视挂，都是没办法防止的，而更改数据达到胜利的作弊方式（例如更改自己的英雄攻击力）可以通过服务器比对同局其他人的战斗结果来预防。
▐ 风险评估表
| 测试内容 | 风险等级 | 测试策略 | 风险点 |
| 单人-割草收能量 | 高 | 功能测试、前端碰撞模型算法测试、故障点测试、兼容性测试 | 1.草的割取和能量的收取的一致性2.关键地图信息、背包能量、PK道具buff等信息存储在indexDB&localStorage的稳定性保障3.客户端性能的风险：crash，渲染不出来，卡顿、失真4.前端防刷，防止有用户能快速刷满所有能量 |
| 单人-升级发红包 | 中 | 功能测试、故障点测试 | 1.能量和等级一致性保障，升级发红包 |
| 兑奖 | 中 | 功能测试、故障点测试 | 1.红包必得的逻辑保障 |
| IGF序列化协议 | 中 | 功能测试，性能测试 | 1.序列化后的字节数大小2.序列化和反序列化的效率3.是否支持被序列化对象新旧版本的兼容性问题。4.是否可以直接序列化对象，而不需要额外的辅助类 |
| 猜价格-并发度 | 高 | 功能测试、故障点测试、性能测试 | 1.通过性能压测摸底，合理安排资源和限流，最大程度保障用户体验2.限流情况下的产品/前端表达，引导用户重试 或 补偿3.前端打散请求4.前端防刷，减少无效请求 |
| 猜价格-排名算法 | 中 | 功能测试、故障点测试、性能测试 | 1.排名算法时效性要求高，从方案层面设计未能及时产出结果的保障方案2.通过性能压测摸底，合理设计限流，最大程度保障用户体验 |
| 猜价格-选品一致性 | 中 | 方案设计保障、定时巡检 | 1.从方案层面，保证选品价格不能轻易变更 或者 活动方案不依赖选品实时状态2.保证项目组能第一时间感知选品价格变更、上下架变更 |
| 猜价格-异常重连 | 中 | 功能测试、故障点测试 | 1.方案层面保障用户在任何异常（主动退出、crash等）、任何状态下，都能有重连的机制 |
质量保障方案
本次双11的测试目标是“大规模用户同时在线下的实时游戏类互动的质量保障”。目标是0故障、0资损、用户游戏体验流畅度，千万用户同时在线。
▐ 目标
核心策略如图所示：
▐ 目标完成情况
- 定义了双11主互动体验的目标，新增回档率等体验指标，分析过程中数据，优化提升体验水位：中断率、可视时间、帧率等，高峰期无大规模体验舆情，主互动发热、卡顿显著改善。舆情15分钟定位。
- 无稳定性问题造成的大规模用户舆情和核心链路不可用问题：事前压测数据构造了亿级战队，高峰期千万用户行为模拟；上线前期通过观察流量占比/数据存储大小，发现地图上报接口流量模型不一致的风险；根据当前架构梳理出低成本的线上可压测方案，具备稳定性变更可验证的能力。
- 自动生成用例占比76%：冒烟用例场景开发可执行占比67%，异常场景覆盖占比85%
专项建设和结果
▐ 稳定性测试策略——线上压测能力建设
除了事前——让压测方案更加趋近真实、和事中——数据观察，模型修正的方案外，本次双11稳定性测试想要重点建设线上压测的能力。
- 解决的问题
预期外的流量，作为线上容器&存储的扩容的演练手段压测模型评估不准确的情况下，线上需要变更的验证能力
- 核心原则
线上容器&存储资源等系统稳定性不受影响
- 线上压测执行
压测实战最重要的两点是确保压测结果的可靠性以及保证压测对线上性能无影响。
- 不影响线上稳定性的几个关键点
容器的稳定性
- 理想情况：将服务单独部署到相同规格的机器上，从物理层面将压测系统与真实业务系统进行隔离，确保压测对真实业务系统的硬件资源无影响。缺点：成本高
- 可行性方案：线上压测的目的不是为了压系统的瓶颈，是为了验证预期流量下的系统表现，因此可以在业务流量低峰期在当前集群进行线上压测，拉起流量还原发生问题时的场景，对容器的压力可控，风险较低。
数据隔离的安全性
- DB的数据隔离：DB数据隔离一般有两种方式：通过新建影子表或新建一套db来保证压测数据与真实业务数据隔离，确保压测数据不会污染线上数据。
新建db的时间成本和资金成本很高，本次互动玩法DB只存储个人-战队-房间的索引关系和流水，单行的数据量较小。经过压测验证，读写的高峰发生在匹配和结算的定时任务时，系统可以通过限制任务的执行的速度，使DB性能处于安全水位之下。用户自然流量对于DB的读写的峰值按照200%的流量模型评估在QPS、TPS、接口成功率、RT评估均无性能风险，因此可以采用影子表作为数据隔离策略。
在压测系统水位时以影子表作为数据隔离策略，需要注意的是影子表与真实的线上表存在于一个db中，压测对db整体性能存在影响，可以选择用户访问量低谷时间段内进行压测来能保证压测不影响线上用户且保证压测结果的可靠性。 - RDB的数据隔离：RDB是本次核心数据的存储，RDB没有DB影子表的隔离能力，可以通过申请新的RDB实例进行物理隔离，底层IGF框架通过配置进行压测流量的路由。
- LDB的数据隔离：LDB支持影子链路存储的隔离能力，业务层无需改造
- 本地缓存隔离：记录时需要带上影子标记，和正常流量进行区分
中间件隔离
- 压测服务使用单独的版本号，可以将压测服务与真实业务服务隔离，确保线上流量不会打进压测系统；
- 通过修改压测应用groupId实现定时任务的分组隔离，保证线上任务不会调用压测机器执行等等。
- 保证压测结果可靠性的几个关键点
压测接口要满足压测需求：
在对存在上下游依赖的业务链路压测时，会将该业务链中的功能接口组装成几个压测接口，该压测接口应体现真实业务链路的上下游依赖。
业务逻辑改动要仿真业务场景：
在不改变业务请求对系统性能产生的影响时，开发同学可能会修改部分业务逻辑进行压测。比如：真实业务链路的非幂等性导致同一用户在同一状态下只能进入该业务链路一次，这种场景对压测造成的最直观影响是需要生成极大量入参来满足压测需求。为解决该问题，开发同学可能会将压测的业务链路修改为幂等业务链，此时便需要注意当前修改不能改变请求对系统稳定性的影响。
qps配比要仿真业务场景：
在同一场景下，不同接口的qps配比是否能够反映真实业务场景是判断压测结果是否可靠的重要依据。qps配比需要基于能够衡量真实业务访问量的统计结果来制定。
入参满足业务仿真的需求：
如果入参的取值对系统稳定性影响较大（比如：不同的入参对cpu计算量或者io访问时长影响较大；相同的入参并发请求时，对io阻塞影响较重；等等。）,需要调研真实业务场景的入参并发间隔、入参离散程度来设计压测入参。
影子数据满足业务仿真的需求：
若通过分析发现，db数据不是本次压测需求的瓶颈或关键点，可以忽略此条建议。不过最好还是在压测前将线上数据同步到影子表，做到高度仿真，RDB同理。
- 关键问题
数据准备
线上真实数据同步到新的RDB实例，目的是能做到数据存储大小的仿真。
备份恢复方案概览
| 类别 | 实施方案 | 说明 | 是否采纳 |
| 数据备份 | 自动或手动备份 | 云数据库Redis支持数据持久化，会按照默认的策略自动备份数据（基于 RDB ），您可以根据业务需求修改自动备份策略，也可以手动发起临时的备份。 | 是 |
| 下载备份文件 | 云数据库Redis的备份文件会免费保留7天，如果需要更长时间的备份存档（例如监管或信息安全需要），您可以将备份文件下载到本地进行存储。 | 备份文件过大，无法本地存储 | |
| 使用redis-shake备份Redis实例 | 通过Redis-shake的dump模式，您可以将Redis实例中的数据备份为RDB文件并存储至本地。 | 备份文件过大，无法本地存储 | |
| 数据恢复 | 从备份集恢复至新实例 | 云数据库Redis支持从指定的备份集创建新实例，新实例中的数据将和该备份集中的数据一致，可用于数据恢复、快速部署业务或数据验证等场景。 | 是 |
| 通过数据闪回按时间点恢复数据 | 开启数据闪回功能（基于 AOF ）后，在备份文件的保存期内，您可以恢复指定时间点（精确到秒级）的Redis数据，可最大限度地避免误操作带来的数据损失，或者在频繁回档的业务场景快速完成数据切换。说明 该功能仅在企业版（内存型）中支持。 | 否 | |
| 使用redis-shake恢复数据 | 借助Redis-shake的restore模式，您可以恢复RDB文件到Redis。 | 否 |
参考：https://help.aliyun.com/document_detail/43886.html
链路改造
上线前的压测链路改造保留
压测环境
准备时长：千万账号登录加压测数据上传同步amazon压测平台时间较长，可在流量低峰期操作减少登陆的时间。
▐ 瓦力——基于强化学习引擎的PK全链路场景自动生成
互动瓦力机器人是大淘宝技术互动测试团队于2019年推出的一款用户行为链路仿真平台，底层基于强化学习引擎实现了用例的自动生成，解决了互动业务测“新”的痛点问题，如今已广泛应用于天猫淘宝大促主互动场景和芭芭农场、淘金币等多个日常业务。
之前我们的工作模式更多是在提测后做质量保障工作，包括功能验证、稳定性性能、资损等等，通过提测后问题发现和风险发现，来保障整体的交付质量，往往在最后的提测阶段暴露大量的风险和问题，导致整个项目再最后时间压力最大。从2022年618开始，我们尝试重点解决开发自测和前后端联调阶段，开发不明确自测场景范围以及测试数据/环境无法快速构造，自测用例无法执行的痛点问题。
以本次的“喵糖总动员”的结算场景为例，需要先组成多个战队，离线DTS任务匹配，穿越到PK期，升级/助力，最后才能进入结算，整个链路的测试成本是非常高的。
借助强化学习用例生成引擎，简化了测试用例前置条件（用例特征）的构造成本，用例特征原子化，在提测前快速生成了60+的冒烟用例，占比全用例的76%，提测通过率100%，提测冒烟时间从过去的3天缩短至1天。
- 挑战与技术创新点
借助瓦力机器人提升了核心场景的自动生成能力问题和风险前置，提高了联调和冒烟阶段开发自测的效率，提前发现问题19个沉淀了可稳定执行的场景case，变更后可快速回归验证
- 问题和展望
- 继续提升开发联调和自测阶段可执行用例的占比，提升研发自测的幸福感
- 简化用例的表达和执行结果的描述，减少用户理解的成本
▐ 大白——业务异常场景自动生成
业务容灾平台-bighero大白，一种不需要编写脚本，通过分析正常流量的核心调用依赖批量生成异常用例，并通过互动机器人，鹰眼标，凤凰和jvm-sandbox构造流量隔离的异常用例执行环境，最后针对异常用例结果进行系统化布防的测试工具；目标是在上线前自动识别出系统的潜在风险，并通过布防等方式将业务损失降到最小。
- 挑战与技术创新点
- IGF框架的引入，放大了同方法多次调用异常精准命中需求，本次基于链路上下文，开发了指定方法index||参数的用例生成&攻防
- 满足特殊异常链路的覆盖，自定义异常返回
- 异步消息链路的异常测试
- hsf接口进行异常用例的自动生成和攻防（将定时任务包成hsf接口进行同逻辑小数据测试）
- 避免同接口异常误命中，叠加参数进行攻防对象的流量筛选
- 落地效果
- 自动化产出喵果总动员有效容灾用例：216条
- P1P2故障点覆盖率为：82.6%
- 多人：15个P1P2故障点，12个覆盖，占比80%
- 开奖：4个P1 P2故障点，4个覆盖，占比100%
- 单人：4个P1P2故障点，3个覆盖，占比75%
- 展望
- 提升大白-异常测试平台的产品化程度，降低异常测试的使用门槛，简化使用流程
- 提高异常场景的覆盖面：MT、并发、奥格、安全等
- 提升异常攻防的自动化程度
未来展望
挑战：
大规模用户实时在线游戏已经成为互动游戏发展的必然趋势，同时在线、低时延、3D渲染等新的课题对互动游戏化架构的稳定性保障、体验标准衡量等提出了更高的要求。
短期规划：
- 通过完善交付场景用例的生成和执行能力，提供给开发更多的自测验证的场景和手段，提升研发自测阶段的效率，提升交付的质量。
- 预研大规模用户实时在线游戏下的架构，梳理相关问题和技术难点，构建相应的质量保障策略和方案。
团队介绍
我们是大淘宝技术质量团队，负责保障整个淘宝和天猫主站的业务质量，一直致力于技术驱动，构建业界领先的质量体系。
我们有QCon、QECon、MTSC、GIAC、绿盟、TOP100 Summit等众多行业大会的讲师，有GitHub获得3.2k Star的开源产品JVM-Sandbox作者，最关键的是有对技术极致追求，对生活充满热爱的大家庭，欢迎加入我们，简历投递邮箱：wenbo.shb@alibaba-inc.com。
