《持续交付》笔记——第4章 测试策略的实现

测试是跨职能部门的活动，是整个团队的责任，应该从项目一开始就一直做测试。——摘自本书

测试的分类(Brian Marick提出的测试象限图)

	支持开发过程的	评判项目的
业务导向的	测试验收测试 （自动的）	演示 易用性测试 探索性测试 （手工的）
技术导向的	单元测试 集成测试 系统测试 （自动的）	非功能验收测试 包括容量测试 安全性测试等 （手工的/自动的）

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

自动化验收测试的价值

1、加快了反馈速度；

2、减少了测试人员的工作负荷；

3、可让测试人员集中精力做探索性测试和高价值的活动；

4、也是一组回归测试套件；

往往验收测试会通过直接操作用户界面的方式来运行。一旦界面改变了（哪怕是一点儿），测试也会被破坏，偶合紧。书中提到有二种方法来解决这个问题：一种是测试与用户界面之间增加一个抽象，以减少因用户界面变更而导致的工作量。另一种是通过API来隔离，而用户界面也会使用这些API来执行真正的操作。（我们原来某项目就是采用第二种方法）。当然并不是说不需要用户界面测试了，这样分离的好处就是验收测试可以直接验证业务逻辑，把用户界面测试成本减少到更低。

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

这种自动化测试单独由开发人员创建和维护。这一节讲得比较少，简单地概括包含单元测试、集成测试（组件测试）和部署测试（系统测试）。

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

这类手工测试可以验证我们实际交付给用户的应用软件是否符合期望。这节也是简单介绍了演示、易用性测试和探索性测试。一种非常重要的面向评介项目的测试就是演示。每次迭代结束时敏捷团队会向用户演示所完成的功能，以确保尽早发现与需求一致。最后文中也提了一下Beta测试。

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

验收测试分为两类：功能测试和非功能测试。主要提到非功能测试（包括容量测试、安全性测试等）是属于支持导向且评介项目的测试。

现实中的情况与应对策略

在新项目中

最重要的是一开始就要写自动化验收测试。

建立自动化构建；

制定遵守INVEST原则；

客户、分析师和测试人员定义验收条件；

测试人员和开发人员一起基于验收条件实现验收测试的自动化；

只要有自动化测试失败，无论是单元测试、组件测试还是验收测试，开发人员都应该把修复测试失败定为最高优先级；

在项目进行中

引入自动化测试最好的方式是选择那些最常见、最重要且高价值的用例为起点。

遗留系统

在这种情况下，如果没有自动化构建流程，最高优先还是创建一个，然后再慢慢丰富。

总结

该章总体来说还是提倡尽可能多的自动化测试，并结合相应的手工测试，比如探索性测试和演示。文中提到测试主要是建立一种反馈循环，而这种反馈环会驱动开发，设计等活动。若将测试推迟到后期最终将会导致项目成本增加甚至失败。