《持续交付》 - 自动化验收测试

一 验收测试

---

验收测试的最终目标就是为了验证应用程序是否提供了用户所需要的功能。这在单元测试中是体现不出来的，单元测试只是验证了代码的某一部分是按照开发人员的思路运行的。所以去做验收测试是很有必要的，对于每一个验收测试来说，只有其满足了验收从条件（功能和非功能性的），我们才能确定我们真的完成了当前这一用户故事或需求。 验收测试阶段的工作流程：

验收测试流程

对项目进行验收测试是必不可少的，而相对于手工测试来说，自动化验收测试应该是我们的首先，它可以带来：

• 通过合理的创建和维护自动化验收测试套件，其成本远小于手工验收
• 发布高质量软件

二 创建自动化验收测试

---

1、分析人员和测试人员的角色

理想状况下，每个项目开发团队中都应该有专门的分析人员和测试人员，而且分析人员在团队中起着非常重要的作用

• 与客户一起识别需求，排定优先级
• 与开发人员一起工作，对开发人员进行指导，确保开发人员能改很好的理解应用程序从而交付真正有价值的用户故事
• 与测试人员一起工作，确保测试人员开发的验收条件被合理的阐明出来

但在真实的情况下，很多的项目团队并没有专业的分析人员和测试人员，那么这种情况下，开发人员便应该去做分析人员的工作或者是测试人员去做分析人员的工作，又或者团队在一起担任分析人员的角色。

2、迭代开发项目中的分析工作

迭代开发的核心就是部署流水线线，即“在任何时候都可以让应用程序运行在选定的环境上”，为了达成这一目的。分析人员和测试人员应该积极的协作一起编写有效的验收测试，编写完成后应该和客户进一步的确定，避免扭曲了用户的需求。而开发人员在分析需求时也应该积极且频繁的去询问分析人员。

3、将验收条件变成可执行的规格说明书

既然是迭代开发的项目，那么也就意味着需求的变动也会比较频繁，那么需求规格说明书的编写者便会非常的痛苦了。所以行为驱动开发(BDD)的理念就诞生了，即验收测试应该以用户期望的应用程序行为的方式来书写。也就是说我们应该把验收条件直接在应用程序上编写并运行，这样就可以很好的验证其是否满足规格说明了。

4、应用程序驱动层

程序应用驱动层是一个知道如何与应用程序（即被测试的系统）打交道的层次。应用程序驱动层所用的 API 是以某种领域语言表达的，可以认为是一种针对它自己的领域专属语言。

DSL（Domain-Specific Language，领域专属语言）是一种计算机编程语言，用于解决某个具体问题域的某个问题，它与通用编程语言不同，因为它无法像通用编程语言那样可以解决很多类型的问题，它专门为解决某个专属问题域的问题而设计。
DSL 分为两种：内部的和外部的，外部的 DSL 在其指令被执行之前就需要明确的解析。而内部的 DSL 需要直接在代码中表达。

5、窗口驱动器模式，让测试和 GUI 解耦

窗口驱动器模式是通过提供一个抽象层（相应的测试工具），减少验收测试和被测试系统 GUI 之间的耦合。这样我们在对 UI 进行了修改后，只需要对窗口驱动器做相应的应该即可，不需要去修改测试。

三 实现验收测试

---

1、验收测试中的状态

由于验收测试要模拟用户在真实的应用场景下与系统进行交互，那么这个时候便会建立并依赖系统中所管理的状态信息，这也就是说在进行测试前，系统就应可处于一个特定的已知状态。面对这种情况，我们应该去编写一组脚本（存储在版本库中）用于初始化当前的状态。其次我们应该让我们的测试具有原子性的（创建自己的初始条件，结束时将环境清理干净），保证每个测试都尽量的和其它的测试隔离。从而可以得到快速的反馈。

2、过程边界、封装和测试

尽量避免为了方便测试而去编写后门。

3、管理异步与超时问题
4、使用测试替身对象

四 验收测试阶段

---

1、确保验收测试一直处于通过状态
2、部署测试

验收测试的环境应该尽量和生产环境保持一致，或者使用虚拟技术来模拟生产环境。在部署测试前我们应选择运行一次冒烟测试用来证明我们的配置环境是否和期望一致。一旦部署测试失败，我们应该让整个验收测试失败。

五 验收测试的性能

---

1、重构通用任务

比如设计测试共用的 API

2、共享昂贵资源

比如在创建一个空白的应用程序实例，将通用的实例进行统一的创建，最后统一的销毁。

3、并行测试