《持续交付》(第四章)——测试策略的实现

测试初探

测试是跨职能部门的活动，是整个团队的责任，应该从项目一开始就一直做测试。测试因该在开发人员开始开发要测试的功能之前就写好。这样，这些测试就成了一个可执行的且从系统行为角度描述的规格说明说。
测试策略的设计主要是时别和评估项目风险的优先级，以及决定采用哪些行动来缓解风险的一个过程。

测试的分类

1.业务导向且支持开发过程的测试
这一象限的测试通常称为功能测试或验收测试，验收测试确保用户故事的验收条件得到满足。
并不是所有的测试都适合自动化测试，我们倾向于将自动化验收测试限于完全覆盖Happy Path（根据用户执行的动作，找到用户程序中一个中规中矩的执行路径）的行为，并覆盖一些对同一个测试重复做过多次手工测试，并且你却行不会花太多时间来维护的测试。
2.技术导向且支持开发过程的测试
这些自动化测试单独由开发人员创建并维护，包括单元测试、组件测试和部署测试。
单元测试用于单独测试一个特定的代码段。
组件测试用于测试更大的功能集合。
部署测试用于检查部署过程是否正常。
3.业务导向且评价项目的测试
这类手工测试可以验证我们实际交付给用户的应用软件是否符合其期望。在开发过程中，我们应该频繁的向客户演示功能，以确保尽早发现对需求规范的错误理解或有问题的需求规范。
4.技术导向且评价项目的测试
验收测试分为两类：功能测试和非功能测试。在发布之前遇到性能的问题这是很多的，所以我们应该在项目开始时就至少要建立一些基本的非功能测试。

我的收获&疑问

收获

• 测试可以有固定的格式，比如：“give-when-then”模式
• 不是所有的测试都需要自动化测试
• Beta测试和金丝雀发布
• 单元测试时可以使用测试替身模拟系统其他部分
• 创建用户故事时写验收条件是很有必要的

疑问

• 测试的容量都包含哪些内容？
• 什么是回归测试？
  引入变化以后，测试是否会导致已有功能异常。