《持续交付》读书笔记-第四章-实施测试策略

关于《持续交付》这本书，有评论称之为“持续交付精华的蒸馏水”

---

“Continuous Delivery: Reliable Software Releases Through Build, Test, and and Deployment Automation”, Jez Humble, David Farley, Addison Wesley, 2010

1. 京东中文版有售：https://item.jd.com/10843669.html
2. 英文亚马逊地址： 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用自动化测试覆盖

遗留系统

定义

• 无自动化测试的系统

和用户一起识别高价值的功能

• 用冒烟测试覆盖

仅写出出那些有价值的自动化测试

集成测试

上下文

• 和真实的外部依赖系统一起测

• 由外部服务商提供的替代系统

• 用自己创建的测试用具测

时机

• 尽早做自动化集成测试

• 作为发布计划的一部分

流程

团队沟通不畅导致编写验收测试成本高

召集所有人参与识别最高优先级的测试场景

开发和测试人员尽早一起讨论验收测试

管理待修复缺陷

建立backlog

立刻修复缺陷

可视化它们

分四个级别

小结

测试主要是建立反馈环

驱动开发、设计和发布活动

每次修改都能触发自动化测试集合是最短的反馈环

“完成”—Done

用测试方法定义它

测试结果是制定项目计划的基石

测试与完成的定义相互关联