关于《持续交付》这本书，有评论称之为“持续交付精华的蒸馏水”
“Continuous Delivery: Reliable Software Releases Through Build, Test, and and Deployment Automation”, Jez Humble, David Farley, Addison Wesley, 2010
- 京东中文版有售：https://item.jd.com/10843669.html
- 英文亚马逊地址： http://www.amazon.in/dp/0321601912
内容概要：
- 一本持续交付早期的书
- 它的出版其实在 DevOps 被热炒之前，但是它还是道出了DevOps概念的精华
- 此书分为三部分：Foundation, The Deployment Pipeline, 和 The Delivery Ecosystem
- 本书基于作者的时间经验，并涉及到重要的方面，如功能割接
以下是本章读书笔记脑图的图片以及之上的文字内容。
本图在Mac OS X上用MindNode软件编辑。下载MindNode原文件
脑图文字导出版
引言
测试的定位
需要进行自动化测试
是跨部门的活动
整个团队的责任
项目一开始就进行
质量内嵌
多层次写自动化测试案例
作为部署流水线的一部分执行
测试策略的目标
识别和评估项目风险优先级
建立信心
测试能约束开发团队使用更好的开发实践
测试的分类
分类维度
业务导向
支持开发
评价项目
技术导向
支持开发
评价项目
四种定位
业务导向-支持开发过程
-
类型
功能测试或者验收测试
自动化执行
保证满足用户故事的需求
-
理想情况下
用户或客户会写验收测试
测试通过-覆盖到所有需求，用户故事被认为是完成的
-
自动化功能测试工具
Cucumber
JBehave
Concordion
Twist
-
测试执行路径
-
Happy path
given-when-then
自动化测试应该全覆盖
对于开发人员，它等同于冒烟测试
Alternate path
Sad path
-
-
测试覆盖率
-
手工测试是不可避免和替代的
易用性测试
界面一致性测试
探索性测试
-
高于80%
全面的测试
单元测试、组件测试和验收测试每一类都高于80%
-
-
优化
识别自动化案例
消除并自动化掉重复的手工测试
考虑测试的维护成本
根据不同的需求，选择新增的测试案例的路径
技术导向-支持开发过程
由开发人员建立并维护
自动化执行
-
三类
-
单元测试
-
不应该访问
数据库
文件系统
外部系统
不应该有组件之间的交互
覆盖每个代码的分支路径
-
-
组件测试
测试更大的功能集合
-
需要访问
数据库
文件系统
外部系统
有时候亦称“集成测试”
-
部署测试
检查部署的过程是否正确
-
应用正确地被
安装
配置
启动服务
服务能调用并响应
-
-
依赖
- 测试替身
业务导向-评价项目
-
手工执行
确认软件是否符合用户期望
建立快速有效的迭代反馈
-
三类
-
应用系统演示
- 团队在每个迭代完成向用户演示新功能
-
探索性测试
优化测试设计
分析测试信息
设计更优的测试
-
易用性测试
用户是否能容易地使用软件完成工作
验证软件是否能交付价值给用户
-
做法
-
场景调查
记录/分析测试用户的操作细节
请用户对软件的满意度打分
网站对部分特定用户的Beta测试
金丝雀发布
-
-
技术导向-评价项目
手工的或自动的
-
测试系统特性
容量
易用性
安全性
可变性
可用性
-
特点
低频
秏资源-耗时间
依赖特殊的环境/技能的人
依赖测试工具
通常与其他测试相比，频度低；并不是应该频度低
回归测试
跨象限
所有自动化测试的合集
测试替身
术语来源
作者：Gerard Meszaros
书籍：《xUnit Test Patterns》
test double
dummy object
fake object
stub
spy
mock
实战的情势和对策
新项目
有机会进入本书描绘的理想国
重要
一开始就要写自动化验收测试
精心编写验收测试
期望的良性循环
- 在正确的时机写测试会产出更好的代码
进行中的项目
引入点
最常见、最重要、最高价值的用例
把happy path用自动化测试覆盖
遗留系统
定义
- 无自动化测试的系统
和用户一起识别高价值的功能
- 用冒烟测试覆盖
仅写出出那些有价值的自动化测试
集成测试
上下文
和真实的外部依赖系统一起测
由外部服务商提供的替代系统
用自己创建的测试用具测
时机
尽早做自动化集成测试
作为发布计划的一部分
