《阿里测试之道》第二章笔记

2.1 大促全链路的风险和挑战

2.1.1 全球最大洪峰下的高可用挑战

2019年双11零点交易峰值是2009年的1360倍

2018年收货地址不可修改

2.1.2纷繁复杂的用户场景

2.1.3 无处不在的用户体验

自动检查用户上传的图片，书写的推销文字等

2.1.4 三位一体的保障

水平：交易中台、搜索中台、阿里妈妈中台等

行业：天猫服饰、天猫美妆、电器城、居然等

专项：资损专项、预案专项、强弱依赖专项等

2.2 全链路压测

全链路压测技术

全链路压测影子体系：基础

全链路压测模型：决定压测质量

全链路压测执行策略：提供精准高并发流量输出

常态化智能压测：进一步提升压测效率

2.1.1 全链路压测影子体系

流量隔离

全链路贯通

资源共享

2.2.2 全链路压测模型

各个业务入口集合

包含各个后端模型

预测各个场景QPS

预测和各个后端的比例

压测模型要和大促玩法深度结合

构造压测模型

2.2.3 全链路压测执行策略

1 千万级的施压能力

压测引擎结构图

2 压测执行策略

脉冲压测

摸高

限流验证

破坏性测试

2.2.4 常态化智能压测

1.总控

2.智能环境和报告

3.智能模型

4.智能预热

5.智能施压

6.智能监控

7.智能排查

8.弹性容量

9.性能基线及报告

常态化智能压测流程

2.3 全链路功能

核心：影子体系

全链路功能

1.统一的环境隔离：隔离环境和修改时间

2.全链路影子数据：同步大批量线上数据到数据表中

3.大促用例精简：精简用例，减少回归和排错成本

2.3.1 统一环境隔离

1 流量隔离

2 时间控制

修改JVM时间

3 预案开关推送（https://blog.csdn.net/weixin_35881820/article/details/113015410）

2.3.2 全链路影子数据库

影子与正式表同库，表结构完全一致，表名加前后缀

1 影子数据

2 影子数据生成

关于过滤

电话、地址敏感信息在线上不存在

商品ID、用户ID核心数据偏移到其他数据空间

真实

海量

准备成本低

3影子数据的使用

充足的“炸弹”

2.3.2 全链路大促销用例精简（RBC）

3000万->40万

1“双11”链路级应用精简方案

2 RBC针对全链路用例执行过程执行进行改造

3 精简效果

2.4 全民预演

2.4.1 什么是全民预演

用全链路视角，拉动集团资源，针对大促上线功能进行有侧重点的整体测试回归

通过集成测试的多种策略消除用例覆盖盲点并提升整体效率

2.4.2 全民预演的核心目标

1 提高全链路验证业务的正确性

2 大促产品验收

3 探索式测试

2.4.3 全民预演如何实时

1 预演人员构成

测试、产品经理、用户研究、视觉、UED（用户体验设计）、研发、客满、内控

2 预演范围

功能预演：交易链路

氛围预演：氛围+价格

验收预演：交易+导购

线下预演：新零售业务

3 用例梳理策略

核心业务场景

横向通用用例

用户行为覆盖

用例行为路径覆覆盖

预演用例来源

核心链路业务人员梳理及往届大促用例沉淀

本次大促线上报名数据分析

历史交易订单分析

4 预演环境准备

应用部署环境：多地多单元部署、云环境、非云环境

无线客户端测试包

无线网络环境：内网环境、外网环境、WiFi、4G

2.4.4 预演执行策略的制定

全民预演轮次及内容

2.4.5 预演问题收集及跟进

当日复盘模式进行复晒

201.9 延迟修复140例 告知客服，安抚客户

2.4.6 大促持续集成

2.4.7 全民演练支撑平台

1 准备过程自动化

90%（550条）用例自动生成

超8900个预演数据一键生成

自动领取资产5.2万次

节约成本169人日

2 环境稳定性

服务端环境：底层接口

客户端环境：浏览器、APP

3 无缝对接大促持续集成

自动录制1.1万条应用级流量脚本

录制客户端链路脚本70多条

覆盖1000多个交易组件

自动化生成链路接口用例310条 70核心域手淘Android/iOS用例执行和验证工作

全民演练:手工->半自动化

2.5 预案开关

预案：提前预案，应急预案

2.5.1 预案的使用场景

1大促预案

2日常预案

2.5.2 预案评估方式

1 强弱依赖是服务预案的必要条件

2 预估流量、压测验证、确定外部服务是否需要提前降级

2.5.3 预案流程

2.5.4 预案平台

1 平台简介

2 平台功能

预案平台功能——大促态、日常态

2.5.5预案与攻防

2.5.6 预案的目标与展望

2.6 全链路预热

2.6.1 解法

1 系统预热

2 数据预热

缓存穿透：缓存中只有Key，没有Value

3 预热场景编排和调度

2.6.2适用业务场景

1 分布式缓存预热

2 本地缓存预热

3 DB预热

4 缓存文件分发式预热

5 缓存失效场景

2.6.3 核心应用场景

1 热点商品的TAIR（阿里内部的缓存中间件）预热

2 数据库预热

3 本地缓存预热

4 本地缓存预热——GCIH预热

5 大促预热活动编排调度

6 其他应用

2.7 快速缩/扩容

2018年双11用户无法修改收货地址是由于容量不够，扩容超过半小时

2.7.1 分析

2.7.2 方案

水平伸缩：增加/减少实例数

垂直伸缩：调整CPU、Memory等

2.7.3 优化

1 垂直伸缩优化:cgroup

2 水平伸缩优化:扩容步骤简化、新技术架构演进、串行到并行

3 扩容步骤简化：28步->8步

4 技术架构演进：DADI（Data Accelerator Disaggregated Infrastructure:数据加速器分散基础架构）

2.7.4 演练

2.7.5 效果

2.7.6 展望

1.对应用启动速度优化

2.Severless：Serverless的全称是Serverless computing无服务器运算，又被称为函数即服务（Function-as-a-Service，缩写为 FaaS），是云计算的一种模型。以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供。国内外比较出名的产品有Tencent Serverless、AWS Lambda、Microsoft Azure Functions 等。

2.8 风险识别系统压测

2.8.1 分析问题

2.8.2 延伸