录制完脚本怎么做接口自动化测试_接口自动化测试设计

题外：新年Flag

大年初一，立个Flag。19年希望能够持续关注测试及相关行业的发展，不断加深对测试的理解，专注于测试技术在测试左移与测试右移的应用与创新。

测试技术的应用不仅限于功能测试、自动化测试、性能测试、可用性(用户体验)测试随着测试左移与右移的发展，还引入了数据分析(用户行为)、线上质量运营等方向，相信还会衍生出更多的方向，比如正在逐步发展壮大的算法测试。

自动化测试的认知

一些错误的认知：

1. 使用自动化完全替代手工测试。
2. 使用自动化测试发现更多的新BUG。

应该形成怎样的认知：

1. 自动化测试的目的不单纯是为了减少或者替代手工测试，而是为了测试人员能够做更多更有意义的测试，比如更深入的需求分析、测试设计或者对测试右移的投入；减少或抽调人力投入；适应开发模式的转变，比如类敏捷、devops模式下的频繁迭代、持续部署。
2. 自动化测试是用来验证以前能够正常工作的功能是否依旧可以正常工作。

为何自动化测试

要清楚不是为了自动化而自动化，是为了实现一套解决方案来解决某些问题而开展某种自动化 ，肯定是解决某些测试过程中的问题而引入自动化测试。既然选择自动化解决某些问题，首先要清楚自动化测试的利与弊，如下：

利

1. 关于成本，机器资源成本代替人力成本，一定程度解决了重复性的测试执行成本问题。
2. 关于效率，提高测试执行效率，缩短测试周期，一定程度解决了测试周期随版本迭代次数的增加(功能点增加)而增长的问题。
3. 关于测试覆盖，通过自动化测试工具的录制回放及数据驱动来测试功能，可以提高测试覆盖率，一定程度解决了回归测试中测试覆盖率低的问题。
4. 关于发现问题，自动化测试具有较好的一致性和可重复性， 一定程度解决了手工反复执行过程中的一致性的问题。
5. 关于流程，自动化测试工具作为一种角色引入到整个测试流程中，提高测试执行流畅性。

弊

1. 关于人员，额外要求测试人员具备定测试开发能力，引入了对测试人员能力要求较高的问题。
2. 关于成本，自动化测试开发成本因选择自动化框架(或工具)而异，但都具有较高的开发成本，引入了开发成本的问题。
3. 关于维护， 随着版本迭代和功能变更，引入了自动化代码的开发维护的问题。
4. 关于发现问题，受其本身的局限性(大多应用在回归测试、稳定版本场景中)， 自动化测试发现问题较少。

工欲善其事必先利其器

IT行业甚至其它行业的产品都是能够做到自动化的，所以是否自动化不是能与不能的问题，而是是否存在合适的时间或阶段以及合适方式去做的问题，实施自动化测试之前需要对产品开发过程进行分析，同时自动化测试是一把双刃剑， 所以通常自动化的开展需要同时满足以下条件：

• 软件需求变动不频繁(超过10%的变动是频繁变动，当然10%不是一个定值)
• 项目周期足够长
• 自动化测试用例可重复使用

通常适合于软件测试自动化开展的场景如下：

• 回归测试，重复单一的测试操作造成了不必要的浪费

上文中也提到肯定是解决某些测试过程中的问题而引入自动化测试，如果是为了自动化而自动化，无疑它将是失败的。

何为自动化测试

自动化测试是把以人为驱动的测试行为转化为机器执行代码的一种过程。

通常，在设计测试用例并完成评审之后 ，由测试人员根据测试用例一步步执行侧试，得到实际结果与期望结果的比较。

在此过程中，为了降低人力、时间或硬件资源的投入，提高测试执行效率，便引入了自动化测试的概念。

飞机还是大炮

框架、工具的选择是我们确认开展自动化后首先面临的问题。之前网上有个梗，泡面煮着吃是没有灵魂的，当然这是一种调侃。自动化测试开展一定要结合被测系统的特点进行选择，不顾被测系统(系统框架)特性、场景而盲目选择自动化测试框架(或工具)， 它是没有灵魂的，自动化失败概率会相对高很多。

下面我们先简单的介绍一下自动化开展的几种自动化测试驱动框架。

首先我们需要明白自动化测试框架更倾向于一种设计思想 ，这种思想指导工具的使用或者自研开发，并且不是只能使用仅仅一种框架，结合被测系统本身特性一般是选择多种测试框架的组合，来满足测试和设计需求(开发、维护角度)。

---

录制回放测试框架

录制回放测试框架所采用的原理是通过录制应用程序产生的线性脚本进行回放从而达到自动化测试的目的。

• 优点：对测试人员测试开发能力要求最低，通过录制就可以得到所需脚本。
• 缺点：一般不具有逻辑判断的能力 ，可维护性差 ，效率低。
• 适应场景：不推荐，传统的UI自动化测试逐步弱化。关于U自动化，一定要清楚 被测系统是否满足开展自动化的条件，在被测系统变动频繁的项目中，开展UI自动化无疑是挖了一个很大的坑，其后期维护工作足以让大心疲惫，被迫放弃自动化测试。

---

测试库构架框架

测试库构架框架的核心思想可以概括为系统功能操作和业务逻辑的解耦。将所有的针对测试系统支持的功能操作封装在测试库中，测试脚本调用测试库的同时传递外部的测试数据，测试库的编写由自动化测试发工程编写(可以不懂业务)，负责控件的变更和维护， 测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写，负责业务逻辑、测试数据的变更和维护。

• 优点：被测试系统无论是哪层发生变化(代码层或业务层等)，只需要相应的人员进行变更维护即可。
• 缺点：变更引起的维护工作同时附加在自动化测试开发工程师与业务测试人员身上，维护代码建级大。
• 适应场景：基于各种自动化开展方式(基于工具如Jemet或不基于工具的自研研发+持续集成)一般都会应用该框架。

---

数据驱动的自动化测试框架

数据驱动的核心思想可以概括为数据(测试数据、配置数据)与代码解耦。该种框架的原理是采用了数据驱动脚本进行测试，数据驱动脚本是将数据输入存储在独立的数据文件中，脚本只存代码，运行时脚本的输入直接从文件中读取，如此相同的脚本(代码模版)可以运行于不同的测试用例中，实现了代码与数据的分离。

• 优点：对于业务人员由面向代码的开发转换为面向配置的设计(参数组合设计)， 降低了开发难度与开发成本，同时提高了测试用例的易扩展性，可以快速扩展相似测试，实现了自动化代码不随用例的增长而增
• 缺点：测试脚本的维护由自动化测试开发工程师负责，要求懂自动化编程和业务逻辑，初始测试脚本设计成本较大，具有一定局限性 (针对相同的测试内容并具有相同的测试逻辑).
• 适用场景：更适应于测试内容测试逻相重复度高，被测对象对测试用例易扩展性、可复用性要求较高的场景。

---

关键字驱动的自动化测试框架

关键字驱动是对数据驱动的逻相扩展，它的核心思想可以概括为数据代码流程(逻辑)解耦，同时完成了代码与测试描述(针对被测对象的测试描述)的映射。该框架的原理是基于数据驱动的基础上，完成了对被测对象的拆分、抽象、 封装使之映射成一个“关键词” (测试描述)，编写测试用例时，仅需要对关键词进行组合 ，即可完成不同场景的测试用例开发。

• 优点:对于业务手工测试人员，由面向代码或配置的开发转化为面向自然语言(测试描述)的开发，最大程度的降低了开发难度与维护成本，同时提高了测试用例的易扩展性、易组织性，实现了自动化代码不随用例的增长而增多。
• 缺点:对测试人员的测试开发能力以及业务了解程度要求很高。
• 适用场景:被测对象包含复杂业务流程(逻辑)，当然复杂的能做简单的更ok。

仅仅从实现上讲，很多种自动化测试框架(或工具)都可以开展自动化，或者说任意一种也不是很勉强， 所以在自动化框架(或工具)的选择上，不是人为核心的(我会什么， 或有哪种框架比较好掌握)，而是以被测对象为本来选择自动化框架(或工具)。

以目标为导向

着重考虑自动化覆盖率、效率提升率、投资回报率(ROI)、效率转换等指标，按季度或产品版本为周期，进行持续性的评估，以便感知落地后的自动化测试是否持续性的发挥着原定作用，通常我们会收集一下数据并依据此设定不同等级进行评定，以便区分优劣，具体如下：

• 自动化覆盖率 = 当前版本该项目自动化测试点/当前版本该项目所有测试点。
• 效率提升率 = 1- 单轮次自动化执行时间/单轮次手动执行时间(针对被自动化测试所覆盖的用例而言)
• 标准盈余时间 = (单轮次手工执行时间-单轮次自动化执行时间)*自动化执行次数
• 实际盈余时间 = 结合标准盈余时间估算
• 投资回报率(ROI) = (标准盈余时间/自动化测试开发投入时间)*100%
• 效率转换 = 对实际盈余时间的分配及相关产出

自动化测试前移

随着敏捷、devops等开发模式的引入，软件交付周期逐渐缩短，相对传统的自动化测试准入原则，已不能满足现有的发展要求，比如“版本功能相对稳定后开展自动化测试”。此时，我们提出了自动化测试前移的设想，基于这个设想我们首先要解决哪些问题？

1. 开发成本，由于自动化前移，会影响前期对测试设计、分析的时间投入。
2. 维护成本，由于自动化前移，由于接口或设计调整而引入的自动化用例变更维护的可能性更大。

因此自动化测试前移是否具备可行性，取决于开发成本和维护成本的是否在可以缩减到一定范围内，这同样也涉及到自动化测试的可持续性问题。

自动化测试策略

依托合适的自动化测试框架，进行自动化测试设计来解决。这里我们主要基于关键字驱动的自动化测试框架进行自动化测试设计，其中有几个设计细节可以借鉴一下，比如：

将接口自动化测试分解为请求响应关键字、响应体特定内容提取关键字、数据校验关键字等几个模块：

• 其中请求响应关键字支持http、https协议的多种请求方式，同时支持JSON、xml等响应体的校验(如，接口响应体为JSON类型时，针对特定Key进行校验或跳过特定Key进行校验)，请求响应关键字的参数包含，URL、请求方式、请求体、期望结果，此时通过该关键字可以实现所有类似接口的自动化测试；
• 特定内容提取关键字支持特定内容的提取，以便在集成接口自动化测试场景下，提取上游接口响应体特定内容，作为下游接口参数输入；
• 数据库校验关键字支持多种类型数据库的增删改查，以及查询结果与期望结果比对等功能；
• 基于关键字驱动的自动化测试框架一定程度解决了随着用例数量的增加维护代码量也越来越多的问题。

如何实现不输入期望的自动化测试用例开发模式？，

• 比如针对幂等性接口，我们在初次运行的时候，重复调用接口10次，然后区分响应体不发生变化的内容和发生变化的内容，再根据不发生变化的内容自动生成期望，回填到用例中，这样大大就提高了自动化的开发效率。

除此之外，关键字驱动的自动化测试，还解决了测试人员与测试开发人员的解耦问题，即测试人员负责用例设计，对产品质量负责。测试开发人员负责框架和关键字维护，对测试效率负责。