敏捷测试价值观、方法和实践读书笔记（10）

第8章敏捷测试延伸实践

8.1 持续集成(Continuous Integration，CI)

持续集成定义

Grady Booch在1991年首次提出了术语"持续集成"

11条实践：

1. 维护单一代码库
2. 自动化构建
3. 让自动化构建可以自测试
4. 每天提交代码到主干
5. 每个主干上的代码提交都要在持续集成服务器上构建
6. 快速修复失败的构建
7. 保持快速的构建过程
8. 在生产环境的克隆环境上进行测试
9. 让每个人都能很容易地得到最新的可执行产物
10. 让每个人都可以看到整个过程发生了什么
11. 自动化部署

4条原则。

1. 保证软件构建单一可信源
2. 减少环境之间的差异
3. 自动化所有步骤
4. 让团队的工作快速得到反馈

持续集成与测试

只有在确定代码没有质量问题后，才会将其提交到主干进行合并，一旦代码合并，就进入了提交阶段。

在提交阶段，开发人员将代码合并到主干后会触发的相关活动，包括代码合并、服务器端编译构建、服务器端单元测试、静态代码扫描和动态覆盖率分析等。

提交阶段执行时长不超过 10分钟

提交阶段的活动完成并生成二进制包后，进入自动化验收阶段，此阶段包含自动部署、冒烟测试以及自动化测试等活动

与测试相关的持续集成实践

1. 提交前在本地运行所有的提交测试
2. 提交测试通过后再继续工作：保持部署流水线常绿是持续集成的基础
3. 不要轻易将测试失败的用例注释掉
4. 若测试运行变慢，则让构建失败
5. 若存在编译警告或代码风格问题，则让测试失败

基于Jenkins和Docker的微服务持续集成案例

运行Jenkins最理想方式是使用独立的服务器

略

8.2 持续部署(Continuous Deployment，CD)

持续部署实践

持续部署是一种软件工程方法，通过自动化部署频繁地交付软件功能

1. 自动化部署
2. 各环境的部署脚本尽量一致
3. 把部署流程集成在 CI/CD 中

基于环境的部署

1. 蓝绿部署
2. 金丝雀发布

基于应用的部署

• 特性开关
• 暗启动

8.3 持续反馈

1.A/B 测试

AB测试(A/B Testing)最早的应用应该是在2000年，Google 工程师用来测试搜索结果页面上每页应显示多少条搜索记录。

1. 做测试时不局限于2个方案：可以是多个
2. 不能使用新版本和上个时间段的老版本进行比较
3. A/B 测试只能有1个变量
4. 避免使用用户标识奇偶法分组

混沌工程

21世纪初，亚马逊的“灾难大师”(Disaster Master)杰西·罗宾斯(Jesse Robbins)以自身的消防员培训经历为灵感创建了一个名为“游戏日”(GameDay)的练习项目,旨在测试、培训和应对亚马逊可能发生的系统灾难。

Netflix从200年8月开始就将自己的数据转移到AWS云服务上,原因是当时一个主要的数据库出现崩溃，影响了3天的DVD发货。Netflix将Chaos Monkey(捣乱猴子)部署在AWS云服务上。

混沌工程的实施步骤

(1)稳定状态

(2)假设。一旦确定系统处于稳定状态，接下来就可以开始进行故障假设，例如:

• 如果这个推荐引擎停止运行了呢?
• 如果这个负载均衡器坏了怎么办?
• 如果缓存失败了怎么办?
• 如果延迟增加了300ms会如何?
• 如果主数据库停止运行了怎么办?

请牢记一点，不要进行已知会让系统失败的假设!只对系统中你认为有弹性的部分进行假设，这才是实验的重点。

（3）设计运行试验

• 有多少客户会受到影响?
• 哪些功能受损?
• 哪些地点受到影响?

(4)学习和验证。

包括:

• 检测时间
• 通知时间
• 升级时间
• 发布时间。
• 优雅降级时间
• 自我修复时间
• 恢复时间(部分和全部)
• 解除警报并恢复稳定时间

错误纠正(Correction-of-Eeeor)文档，简称 COE 文档。

COE 文档组成

• 发生了什么事(时间轴)?
• 对我们的客户有什么影响?
• 为什么会出现错误(5个Why原则)?
• 你学到了什么?
• 你将如何防止它在未来再次发生?

(5)改进和修正。

混沌工程的价值

(1)混沌工程能够帮助发现系统中的未知因素，并且能让我们在正常工作时间对其进行修复，避免牺牲休息时间。

(2)一个成功的混沌工程实践总会产生比预期多得多的变化,在这些变化中最重要的免责文化从“你为什么那样做”自然演变成“我们如何避免在未来这样做”，这会让团队快乐、更高效，也是其黄金价值所在。

生产环境中测试

1，上线后测试：测试环境与生产环境不一致

2、线上巡验

(1)避免“脏数据”

(2)尽量使用自动化测试。

(3)测试范围主要考虑核心业务

8.4 DevOps

DevOps 是 Development(开发)和 Operations(运维)的缩写的组合，DevOps一词来源于 2009 年在比利时根特市举办的首届 DevopsDays。

DevOps 三步工作法

• 流动
• 反馈
• 持续学习和实践

DevOps与测试

Katrina Clokie 在APractical Guide to Testingin DevOps 一书中提到，在DevOps 中，很少提到测试，是因为这些社区的组织者并不是测试背景出身，但这并不意味着测试就被弱化了，相反，测试应该作为重要的活动融入整个开发过程。

敏捷专家 Dan Ashby 在个人文章Continuous Testing in DevOps 中表示:你可以看到为什么人们很难理解在这样一个根本没有提到测试的模型中,测试处于这样的位置。对我来说，测试适用于 DevOps 模型的每一个环节。