阿里测试之道

1. 代码门禁

• 流程：PR 时进行编译、静态扫描 (SonarQube)、接口级功能测试
• 2018 年数据：
  • 月均 PR 量：3000+ 次
  • 拦截率：20%（约 800 次）
  • 编译问题：50%
  • 用例失败：25%
  • 静态扫描问题：25%
• 技术实现：
  • PR 环境容器化沙箱
  • 自动同步主分支 DB Schema
  • 合并后自动销毁
• 笔记：
  • 小公司可简化（无需完整 PR 环境）

2. 代码门禁优化

• 痛点：验证时间从秒级→10 分钟
• 优化目标：
  1. 缩短至<10 分钟（开发者耐心阈值）
  2. 内存数据库
  3. 精准测试
  4. 成功率>90%（建立信任）

3. 测试本质：质量反馈

• 三级决策依据：
  1. 代码门禁 → 是否接受提交
  2. 功能回归 → 是否推进预发布
  3. 灰度验证 → 是否全量上线
• 笔记：
  • 当前公司主要依赖功能测试
  • 接口测试多用于告警/流程类

4. 可信测试三要素

1. 测试全面性
2. 结果可信度
3. 全部通过

5. 质量与效能关系

• 效能→质量：
  1. 暴露问题更快（及时性）
  2. 问题更易被关注（可信度）
  3. 工具减少人为错误
• 质量→效能：
  • 高质量支撑快速决策

6. 测试破局三维度

维度	关键措施
缩短反馈时间	测试金字塔下移、并发执行、数据准备优化、精准测试、用例瘦身
降低反馈成本	小型测试为主、逻辑隔离替代实例隔离
提高可信度	提升稳定性、代码/业务覆盖率、自动生成用例

7. 缩短反馈时间实践

• 两个理想状态：
  1. 反馈零等待
  2. 结果立等可取
• 团队协作：
  • 个体小牺牲 → 群体大收益（如遵守 CI 规则）

8. 提升可信度策略

稳定性提升

• 四原则：
  1. 高频执行
  2. 隔离环境（终极目标：TiP）
  3. 用完即抛
  4. 禁止自动重跑（暴露偶现问题）

有效性度量

• 传统公式： 缺陷逃逸率 = 测试发现Bug数 / (测试发现+线上发现)
• 阿里创新：
  • 变异测试
  • 缺陷逃逸密度 = (变更代码行数×线上Bug数)/1000

充分性保障

• 解决方案：
  • 用例自动生成
  • 业务覆盖率度量

9. 防错设计

• 经典案例： ```sql ORDER BY gmt_create, detail_id -- 增加主键确保排序唯一性 # 阿里测试之道

10 影子数据（test in product 的核心数据）

全链路功能根植于影子体系，按照之前的介绍，影子体系是通过影子标来标记影子流量、通过影子表保存影子体系数据的。影子表和正式表同库，表结构和线上保持一致，只是表名加前缀，如同影子一般，因此，存储在影子表中的数据被称作影子数据。

影子数据的生成：
全链路功能要提前验证大促招商的所有数据，涉及的影子数据是上亿级的，且是各库表的各种类型的数据，如何圈定线上数据，将线上数据迁移成可用的影子数据，并且不会对线上数据造成影响，就成为首先需要解决的问题。
影子数据平台是在解决这个问题的过程中诞生的，它构建了一条通道，将正式表的数据搬运到影子表中，产生可用的影子数据，影子数据的生成过程如图 2-7 所示。
影子数据的生成过程，并不是完全的复制过程。虽然有了影子表，有了中间件作为媒介透传影子表、识别影子流量

（小公司可以通过通过 X-Shadow-Test: true 等 Header 或 URL 参数标记压测影子数据，然后数据库影子表统一同步，读写数据都通过影子表来完成）

11 SQL 预热

数据库执行 SOL 查询的时候，会先在缓存池中查询是否已经有结果，如果没有则会进入下面长长的解析、优化和计划执行等过程。因此如果能提前向缓存池中放入热 SQL 的执行结果，则能大大降低请求到数据库的处理响应时间。预热系统也可以同时预热多个单元的数据库实例，支持按照用户单元规则将热点数据进行路由。
（确实存在缓存，如查询 gps 数据能感觉到第一次查询很慢，有了缓存之后才快起来）

12 SOLOPI

设想一下:当需要编写一个用户注册流程验证的自动化用例时，我们可以利用 SoloPi 的录制回放功能，按正常流程进行注册，这时 SoloPi 会同步生成一份 UI 操作自动化脚本。为了能够重复利用其间的注册信息，我们可以利用 Mock 功能将当次的请求数据保存下来同步关联到上述录制的脚本中，完成注册流程验证的自动化用例编写。同时为了后续能够定时执行，我们还可以将用例放置在云测平台上，设定定时执行时间和结果通知方式，这是一件多么惬意的事呀!

13 APP 测试

主要事在自动化，一机多控、性能、兼容性（不同机型不同策略）、android 或 ios 升级等方面、云测、mock 等方面展开

14 软件开发模式

DDD(Deadline-Driven Development) 截止日期驱动开发

BDD 行为驱动开发

TDD 测试驱动开发

15 测式三定律

1）软件总会出错（人非圣贤）

2）测试不可穷尽

3）质量的设计出来的，不是测试出来的（比如 A 项目 1000 个 bug 修复了 到了 B 下项目也是 1000 个 bug 甚至更多 请问质量提高了吗）

16 对于质量和效率之间的平衡点

服务端测试倾向于离效率更近一些，客户端测试倾向于离质量更近一些，因为服务端 Bug 更容易被修复。最后，工程能力的提升，会帮助我们找到新的平衡点。