持续交付（第四章）—测试策略的实现
在上一章中介绍了持续集成，这让我们的项目在整个生命周期中都是可控的，一直处于可运行状态，对于后期的集成也是起很大的帮助的，但是要获得这些优点，就需要团队之间良好的协作，共同遵守一些良好的实践，比如，使用版本控制工具，频繁提交，多些注释，测试覆盖等。
那在这一章就讲其中一个很重要的实践——测试，主要讲解如何实现测试策略，而不涉及具体测试的书写。
持续集成
为什么要写测试
我们不应该将所有的检查都依赖于手工或者人为的检查，这样耗费时间不说，还会让代码的结构性降低。正确的做法应该是在项目一开始就一直做测试。
在一个理想的项目中，项目一开始，测试人员就会与开发人员一起写自动化测试，这些测试应该在开发人员开始要测试的功能之前就写好。这样，这些测试就成了一个可执行的且从系统行为角度描述的规格说明书。当这些测试全部通过以后，也足以说明客户所需要的功能实现了。这样在之后的修改重构时，也有了足够的保证。
测试的分类
测试象限
这是由Brian Marick提出的测试象限图，他将测试分为两个维度，一个是业务导向，还是技术导向，另一个维度是为了支持开发过程，还是为了对项目进行评价。
1.业务导向且支持团队的测试
这一象限的测试通常称作功能测试或验收测试。为了确保用户故事的验收条件得到满足，在开发一个用户故事之前，就应该写好验收测试，采取完美的自动化形式。
2.技术导向且支持开发过程的测试
这一象限的测试通常都包含：单元测试，组件测试，部署测试。单元测试用于测试一个特定的代码段，使用测试替身来模拟系统系统其他部分，不应该访问数据库，文件系统等外部系统。组件测试用于测试更大的功能集合，涉及更多的准备工作并执行更多的I/O操作。部署测试用于检查部署过程是否正确。
3.业务导向写评价项目的测试
这一象限的测试通常包含：探索性测试，易用性测试。都是手工测试验证我们实际交付的软件是否符合期望。这并不知识验证应用是否满足需求规格说明书，还验证需求说明规格书的正确性，及时的获取反馈并对需求说明规格书进行修改。
4.技术导向且评价项目的测试
这一象限的测试有非功能测试，比如：容量测试，性能测试，安全性测试等和项目功能无关的测试。我应该将非功能需求和功能需求放在同等的地位看待。
测试替身
测试替身用于在测试代替还未实现的模块数据。可以分为下面这几类：
- 哑对象
- 假对象
- 桩
- spy
- 模拟对象
流程
在项目开发中，我们应该尽可能提前写好各种自动化测试，并且实践敏捷开发，测试不仅仅是测试人员一个人的事，应该让整个开发小组以及客户参与进来，共同制定一些标准，并且在之后的开发过程中，开发人员要和测试人员紧密合作。对于检测出现的问题，进行进行处理，对于已有待修复缺陷的列表，应该重视起来，不要堆积。
总结
我的收获
- 有一些软件可以让客户参与测试的编写，需求更加清晰
- 演示是项目的核心，这样可以从客户那里确认是否需求理解正确
- 了解到测试替身这个概念
- 终于完全明白了非公能需求是啥
- 之前一直以为遗留系统就是之前留下的系统，现在看了这本书才知道是没有自动化测试的系统。
我的疑惑
- 回归测试是什么？，都包含哪些方面
- 对于测试替身中的几个分类，概念不清晰
- 书中描述的全方位测试的书写，持续交付的实践，现实中大多数人会这么做么？感觉准备工作太多了，是不是得自己衡量下。
- 为什么会有待修复缺陷列表的存在，有错误不是应该及时的修复么，堆积着开发总是有风险的。
