《持续交付》读书笔记-第四章-实施测试策略
关于《持续交付》这本书，有评论称之为“持续交付精华的蒸馏水”
“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原文件
CD-4-实施测试策略
脑图文字导出版
引言
测试的定位
需要进行自动化测试
是跨部门的活动
整个团队的责任
项目一开始就进行
质量内嵌
-
多层次写自动化测试案例
-
作为部署流水线的一部分执行
测试策略的目标
识别和评估项目风险优先级
建立信心
测试能约束开发团队使用更好的开发实践
测试的分类
分类维度
业务导向
-
支持开发
-
评价项目
技术导向
-
支持开发
-
评价项目
四种定位
业务导向-支持开发过程
-
类型
-
功能测试或者验收测试
-
自动化执行
-
-
保证满足用户故事的需求
-
理想情况下
-
用户或客户会写验收测试
-
测试通过-覆盖到所有需求，用户故事被认为是完成的
-
-
自动化功能测试工具
-
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用自动化测试覆盖
遗留系统
定义
- 无自动化测试的系统
和用户一起识别高价值的功能
- 用冒烟测试覆盖
仅写出出那些有价值的自动化测试
集成测试
上下文
-
和真实的外部依赖系统一起测
-
由外部服务商提供的替代系统
-
用自己创建的测试用具测
时机
-
尽早做自动化集成测试
-
作为发布计划的一部分
