持续交付发布可靠软件的系统方法（基础篇）第四章：测试策略的实现

《持续交付发布可靠软件的系统方法》读书笔记

项目在一开始阶段，测试人员就会与开发人员及客户一起写自动化测试。这些测试应该在开发前就写好。
以上这些测试仅仅是系统进行功能测试，容量、安全性及其非功能性试也应尽早建立，为它们写自动化测试套件。确保不符合需求的问题尽早暴露。

测试象限图

业务导向且支持开发过程的测试

在开发一个用户故事之前，应写好验收测试，采取完美的自动化形式。
系统的验收测试应运行在类生产环境（UAT)
验收测试有价值的特性：

• 它加快了反馈速度
• 减少了测试人员的工作负荷
• 让测试人员集中精力做探索性测试和高价值的活动
• 这些验收测试也是一组回归测试套件
• 行为驱动开发，可以以这些测试中自动生成需求说明文档

并不是所有的东西都需要自动化。我们倾向于将自动化验收测试限于完全覆盖Happy Path的行为，并仅覆盖其它一些极其重要的部分。每一种测试都应该覆盖应用程序的80%
验收测试一般都是端对端测试，但是这样很多时候验收测试的失败并不是因为真正的缺陷，而是因为界面的变更，这将导致增大了验收测试脚本的维护。有两种方法解决这个问题：

• 在测试与用户界面之间增加一个抽象层，以便减少因用户界面变更而导致的问题
• 通过公共API来运行这些验收测试，用户界面会使用这些公共API来执行真正的操作

技术导向且支持开发过程的测试

单元测试：不应该访问数据库，不应该使用文件系统，不与外部系统交互
组件测试：涉及更多的准备工作并执行更多的IO，需要连接数据库，文件系统，与外部系统交互
部署测试：用于检查部署过程是否正确

业务导向且评价项目的测试

其中非常tgsvr一种测试是：演示
探索性测试，并不只是发现缺陷，它还会致使创建新的自动化集合
易用性测试，为了验证用户是否能很容易使用该应用软件完成工作
Beta测试，金丝雀发布，多个版本同时运行在生产环境，收集不同版本的数据，如果分析证明新功能无法带来足够的价值，就删除它

技术导向且评价项目的测试

验收测试分两类：功能性测试，非功能性测试

测试替身

• 哑对象：那些被传递但不被真正使用的对象
• 假对象：可以真正使用的实现，但通常会利用一些捷径
• 桩：在测试中为每个调用提供一个封装好的响应，它通常不会对测试之外的请求进行响应，只用于测试
• SPY：一种可记录一些关于它们如何被调用的信息的桩
• 模拟对象：一种在编程时就设定了它的预期要接收的调用

现实中的情况与应对策略

新项目：一开始就要写自动化验收测试

• 选择技术平台和测试工具
• 建立一个简单的自动化构建
• 制定遵守INVEST原则【独立的，可协商的，有价值的，可估计的，小的，可测试的】用户故事及考虑其验收条件
• 客户、分析师和测试人员定义验收条件
• 测试人员与研发人员一起基于验收条件实现验收测试的自动化
• 开发人员编码来满足验收条件
• 只要有自动化测试失败，开发人员优先修复问题

项目进行中

• 引入自动化测试最好的方式是选择应用程序中那些最常见，最重要且高价值的用例为起点。
• 让测试覆盖的范围稍稍宽于通常的用户故事级别的验收测试。
• 如果发现对同一个功能重复进行了多次的手工测试，就判断该功能是否还会个性。如果不会，就将这个测试自动化，否则，说明这个测试覆盖的功能一直变化，可以与客户和开发确认后，把它从测试集合中先忽略掉，并尽可能详细地写注释
• 如果时间紧，最好利用各种各样的测试数据来确保一定的覆盖率

遗留系统

• 如果没有自动构建流程，最高优先级是创建一个自动构建流程，然后创建更多的自动化功能测试来丰富它
• 识别系统中高价值的功能，聚焦于系统中高价值的功能
• 基于高价值功能，创建一套广泛的自动化测试
• 逐渐为新增功能添加相应的测试
• 只写那些有价值的自动化测试，如果只是新增功能，而不需要修改提供支撑的框架代码时这部分代码不需要写全面的测试

集成测试

集成测试：那些确保系统的每个独立部分都能够正确作用于其依赖的那些服务的测试
集成测试应该在两种上下文中运行：

• 被测试的应用程序使用其真正依赖的外部系统来运行时，或使用由外部服务供应商所提供的替代系统
• 应用程序运行于你自己创建的一个测试用具之上
  确保在正式部署生产环境之前，应用程序不要与真实的外部系统进行交互，否则就要想办法告诉外部系统，应用所发送的数据只用于测试
• 在测试环境中使用“防火墙”，将该应用程序与外部系统隔离开来
• 在应用程序中用一组配置信息，让其与外部系统的模拟版本交互
  把关于集成的活动放到发布计划中是非常必要的。与外部系统的集成总是比较复杂，需要花时间并制定计划。每当增加一个外部系统集成点时，项目风险就会增，集成风险：
• 测试服务是否准备好了？它是否能正常运行？
• 外部服务供应商是否有足够的资源与人力来回答我们遇到的问题，修改缺陷，添加我们提出的一些定制功能?
• 我们是否能直接访问真实的生产环境，以便验证外部系统是否满足我们的容量要求或可用性要求？
• 外部服务提供的API是否很容易与我们自己开发应用软件时所采用的技术进行集成，我们团队是否需要某些专业技能才能使用这些API?
• 是否需要编写并维护我们的测试服务？
• 当外部系统的响应与我们所期望的行为不一致时，我们自己的应用程序是否能够正确地处理？
• 还需要构建与维护这个集成层及相关的运行时配置，测试服务与测试策略。

流程

• 找出最高优先级的测试场景
• 代码让这些验收条件变成可执行的测试
• 测试人员与研发人员在开发前应尽早一起讨论验收测试

管理待修复的缺陷列表

• 将待修复缺陷列表可视化
• 一种零缺陷，关注缺陷问题，并修复
• 像对待功能一样对待缺陷，将功能与缺陷一起做优先级排序，让开发按优先级进行开发