阿里测试之道读书笔记
阿里测试之道-第1章
测试团队的发展之路
1.1 测试团队面临的困局
测试自动化难
- “技术债”越积越多：
- 一边修复老的用例，一边出现新的失败用例
- 一边补充自动化，一边遗留未自动化的用例
- 一些可以自动化完成的功能、回归测试，还得依赖手工测试
测试结果的噪声大
- 回归测试的通过率低
- 排查大量的失败用例，大部分是测试环境及互相干扰，而不是代码导致的
- 噪声多导致问题在排查中漏掉，变为线上问题
测试不充分
- 测试分析和用例枚举，非常依赖测试人员的经验和业务领域知识
- 缺少有效的技术手段度量和提升测试的充分性
测试人员对自身成长的焦虑
- 上述各种困局使测试人员把大量时间花在各种琐事上，没有时间和精力提升自身能力、追求技术创新，也缺少沉淀积累。
1.2 建立代码门禁
1.2.1 什么是代码门禁
Gated Checkin
- 在公共分支（包括项目分支、迭代分支、主干分支、紧急发布分支）上，禁用 git push，只允许通过pull request 来提交代码
- 研发平台对每个提交到公共分支的 pull request 都会执行各项检验，包括编译、单元测试和接口级别功能测试、静态代码扫描。只有通过这些检验，pull request才能够被合并
- 代码门禁就是简单的把持续集成前移：从代码提交后（post-submit）提前到了代码提交前（pre-submit）
- 这简单的前移，彻底改变了我们的研发模式：从以前的“先欠债了再还”，变成了现在的“每个代码提交都不能欠债”
1.2.2 代码门禁的效果
2018年，阿里巴巴集团的一个团队
- 平均每个月有超过3000次 pull request执行了代码门禁
- 被代码门禁拦截的有问题的约 800次，占总数的 20%以上，其中：
- 代码编译问题（包括jar包依赖问题）约占 1/2
- 用例失败问题占 1/4
- 静态代码扫描发现问题约占 1/4
- 少数的其他检验发现的问题
1.2.3 落地与优化
原来只需要一个命令，几秒钟就能提交完成
=>
要等上至少十几分钟，另外可能还需要重新运行一次或多次，进一步增加提交需要的时间和精力
因此，除了花时间解释代码门禁的重要性，还需要做出一些比较关键的优化。
1. 缩短时间
- 代码门禁的测试执行时间都不应该超过 10分钟。（经验值）
- 用基于 MariaDB4j 的本地数据库方案。（内存数据库，便于快速测试）
- 精准测试，只运行和变更代码相关的用例。（据阿里巴巴集团某团队的数据显示，精准测试可以缩短代码门禁中 43%的测试时间）
2. 提高稳定性
- 制定代码门禁的测试稳定性的目标，即 90%的成功率。整个测试用例集如果执行 100次，至少应该有 90次是通过的（经验值）
- 本地数据库方案和精准测试也能提高稳定性。
1.2.4 更多的用途
Bug Jail（拘留所）：一个开发人员有很多高优先级的 Bug长时间不修复，我们就可以把他关进“Bug Jail”，意思就是不允许其在开发新功能，必须先修复这些已有的 Bug，直到他名下的 Bug数量降到一定水平以下。对被关进 Bug Jail的开发人员，代码门禁不允许其 pull request合并
代码围栏：对于一些核心代码，我们要求所有相关的 pull request都要经过有经验的人员的代码检查。通过配置代码门禁的规则，将其作为必要条件
组件升级：代码门禁提供了一个强制升级的机制，即如果某个系统的该升级的jar包一直不升级，那么经过一个”黄牌警告“时期后，我们可以通过配置代码门禁的规则来阻断这个系统的所有 pull request，强制升级
1.3 理解测试的本质
测试的本质反馈，就是回答一个问题：代码是不是好的。（对不同的需求，好的定义和标准都是不同的）
测试的目的是提供质量反馈，提供下面三个（节点）用于决策的质量反馈：
- 代码门禁中的单元测试和接口测试结果：为判断是否可以接受代码提交提供决策依据
- 功能回归的测试结果：为判断是否可以将当前版本的代码推进到预发布和灰度验证阶段提供决策依据
- 预发布环境和灰度验证的结果：为判断是否可以将版本的代码进一步部署到整个线上环境提供决策依据
测试团队提升测试反馈能力的 3个维度：（既是质量视角，也是效能视角）
- 缩短提供反馈的时间
- 降低提供反馈的成本
- 提高反馈的可信度（Confidence Level）
实际上，质量和效能是”既要…也要…“的关系，效能提升可以让我们更快地得到反馈，以更快的节奏去迭代和试错。
效能提升对提高质量的直接作用：
- 效能提升能够让代码里的质量问题更及时地暴露出来
- 效能提升能够让代码的质量问题更容易地暴露出来和被注意到，而不是淹没在各种噪声里。