《持续交付》 - 测试策略的实现
现在很多的项目团队都只是依靠手工的验收测试来验收软件是否满足它的功能需求和非功能需求。他们也知道这样会大大的影响项目的交付质量和进度，但他们依旧会这么做，因为他们可能已经尝试过去写测试，尝试着搭建自动化测试的相关服务，但最终并没能从中获取到很大的好处而且浪费了大量的精力，所以他们宁愿去手动去测试，遇到 bug 了手动去排除并修复。
当然了，这并不是说写测试不好，相反的，写测试是非常重要的，但更重要的是我们必须要认识到相关的测试策略并正确的选用它，从而为自动的项目实现一套合适自身的部署流程线。测试策略的设计目的主要是识别和评估项目风险的优先级，以决定采用哪些行动来缓解风险的一个过程。这也就意味着，写一次测试并不是一劳永逸的，对于一些自动化测试，我们应还需要不断的去维护测试以保证客户需要的功能被正确的实现，在开发功能之前我们就应该将测试写好，一开始就将质量内嵌到自动化测试中，这样我们才能从中获取最大的好处。
一 测试的分类
为了确保交付高质量的应用软件， Brian Marick 对测试进行了相应的建模，他根据两个维度对测试进行了分类：
- 业务导向还是技术导向
- 支持开发过程还是为了对项目进行评价
分类
** 1、业务导向且支持开发过程的测试**
对应的分类
这一象限的测试也叫功能测试或验收测试，目的是为了验收当前开发的功能需求是否被正确的完成，验收测试也可以测试系统特性的各方面，比如功能、容量、易用性和可变性等。一般我们应该在开发一个功能前就把验收测试写好，并采取自动化的形式去验收，提前写验收测试也可以很好的明确功能需求，通过这些测试我们可以知道我们要做哪些功能。
系统的验收测试应该运行在类生产环境，自动化测试的一些特性：
- 加快反馈的速度
- 减少了测试人员的工作负荷
- 让测试人员可以集中精力去做探索性测试和一些必须手动测试的活动。
- 验收测试也是一组回归测试
- 写出可读的测试套件，这样就可以从测试中生成需求说明文档。这样也就可以保证了文档不会过时。
2、技术导向且支持开发过程的测试
对应的分类
这些自动化测试应该单独由开发人员来创建和维护，这一象限的测试可以分为：
- 单元测试：一般需要依赖测试替身来模拟数据。因为不需要使用数据库、文件系统...，所以速度会很快，这也意味着会得到更快的反馈，单元测试也是回归测试套件的主要部分。
- 组件测试：用测试更大的功能集合，需要使用数据库、文件系统 ...，所以速度会相对较慢，组件测试也被称为“集成测试”。
- 部署测试：为了检查部署过程是否正常，也就是程序是否被正确的安装、配置。
3、业务导向且评价项目的测试
对应的分类
这类测试一般需要我们手工测试，目的是为了验证实际交付给用户的应用软件是否符合其期望，包括需求规格说明是否满足以及其正确性。
几种测试的方案：
- 演示：频繁的向客户演示新功能，以此快速的获取反馈信息
- 探索性测试：执行测试时，测试人员因该积极的去发现隐藏的缺陷，并创建新的自动化测试集合去覆盖
- 易用性测试：验证用户是否能很容易的使用软件完成工作（用户体验）
- beta 测试：验证用户是否对隐藏的新功能感兴趣，从而判断该功能的价值
4、技术导向且评价项目的测试
对应的分类
非功能测试是指除了功能之外的系统及其它方面的质量，比如：容量、可用性、 安全性等。对非功能性的测试也是非常重要的，因为这因素可能会导致很大的潜在风险。 当然非功能性测试所需要的环境也更加苛刻，它需要专业的人员搭建一些特殊的环境来能实现，而且花费的时间也较长，所以非功能性测试的频率会比较低，而且应该在开发的后期去进行测试。
二 测试替身
在自动化测试时测试替身扮演着一个非常重要的角色，比如在单元测试中通过模拟对象来代替系统的一部分，这样就可以大大的提高测试的速度。
测试替身的分类：
- 哑对象(dump object)：指那些被传递但不被真正使用的对象，这些对象一般只是用于填充参数列表，只是起到一个占位的作用，没有具体的含义。(如测试A类的run方法，需要在创建A类的实例时需要传入B类实例，但run方法并没有用到B类实)
- 假对象(fake object)：假对象相对于哑对象来说，要对耦合的组件有一些简单的实现，实现我们在测试中要用到的方法，指定期望的行为（如返回期望的值）。假对象适用于替换产品代码中使用的全局对象，或者创建的类
- 桩(stub)：测试桩与假对象有点类似，也要实现与产品代码耦合的组件，指定期望的行为。这里最大的不同是测试桩需要注入到产品代码中，从而在测试产品代码时替换组件，执行桩的行为。使用测试桩不需要进行备份和还原。
- spy：与测试桩类似，但是可以记录桩使用的记录，并进行验证。
- 模拟对象(mock)：设定期望的行为，然后验证期望的行为是否发生，从而达到测试产品代码行为的目的。适用于验证一些void的行为。
三 现实中的情况和对应策略
1、新项目
当我们着手开始一个项目的时候，这也是最容易开始做持续集成的时候，那么毫无疑问最重要的事情应该是先自动化验收测试。我们需要
- 选择技术平台和测试工具
- 建立一个简单的自动化构建
- 制定遵守 INVEST 原则（独立的、可协商的、有价值的、可估计的、小的、可测试的）的用户故事及其考虑其验收条件
步骤：
- 客户、分析师和测试人员定义验收条件
- 测试人员和开发人员一起基于验收条件实现验收测试的自动化
- 开发人员编码来满足验收条件
- 只要有自动化测试失败，开发人员都应该将它定义为最高优先级并修复它。
2、正在进行中的项目
对一个正在进行中的项目去做自动化测试相比项目一开始就写测试面临着更大的压力。最好的自动化测试的方式就是选择应用程序中那些最常见最重要的用例开始写测试，让这些测试尽可能覆盖更多的选项，一般覆盖的范围都会宽于用户故事级别的验收测试。
3、遗留的系统
去测试那些你修改的代码就可。前提是你已经搭建好自动化构建流程。
几个概念
- 可用性测试：让用户通过使用产品来评估产品的技术。
- 探索性测试：在进行测试的时候同时探索开发更多类型的测试从而改善测试流程。
- happy path：一个正确的执行路径
- alternate path ：多个可以相互替代的 path ，入口和过程可以不一样，但是最终产生的用户价值是一样的
- sad path ：选择一条执行路径产生的错误处理
