接口自动化测试~用例模板设计（一）

转载至：接口自动化测试~用例模板设计（一）

        我们平常所谓的接口自动化、UI自动化实质都是功能性的自动化，不管是我们用自动化做冒烟测试？回归测试？还是批量数据校验也好，等等。都实质都是通过工具来模拟人工完成这些验证。

        那么，这个时候有的同学就有疑问了，我们用自动化可以大大缩短测试周期，而且还可以进行数据整合、统一管理、智能监控、重复使用等等

        而且还有的同学会跳出来说，“模拟人工” 哪有那么简单，这设计框架的时候，不得考虑：易用性、可靠性、稳定性、健壮性、可扩展性、高并发、兼容性吗???等等

        大家说的都没错，其实说到的上面几点，完全可以概括为自动化测试的优点，以及框架设计的一些思想。

        不管是自动化测试的优点也好，还是框架如何设计，我们后面带大家都会一一讲解，我们最后要做到的是，我们的框架不管在哪里都可以直接使用，即便是每个公司的项目有不同的定制化需求，我们也可以通过灵活配置，来完成特定需求，甚至我们要达到，在维护case的时候，大家都不用写一行代码，全部自动生成。

        我相信很多同学在入手自动化测试的时候，尤其在编写测试用例这个阶段，首先直接写测试用例对象，在这里呢，我建议大家首先要设计一个用例模板，我们通过读取用例模板的数据，结合数据驱动+关键字驱动来完成测试，这样做有哪些优点呢：

• 便于后期维护、统一管理

• 结构层次分明，易于阅读

• 统一规范，不易出错、易于排查错误

• 不用重复造轮子

• 高效性

• ......

接下来带大家设计一个简答的用例模板（.yaml文件），当然Excel维护的关键字一样

#基本信息test_info:  product_name: 产品名称  module_name: 模块名称  tester: 测试人员  developer: 开发人员  host: ${host/ip地址}#接口信息api_datas:    #接口数据    - case_id: 测试用例id      case_title: 测试用例标题_1      http_type: 请求协议类型      request_type: 请求方式      parameter_type: 请求内容类型      headers: {头信息}      address: 接口请求地址      timeout: 接口响应超时时间      parameter: {        #请求参数      }      #断言      check:        #断言

• 基本信息

  • 产品名称、模块名称、测试人员、开发人员：我们维护这四个字段，主要是为了测试报告、钉钉提醒、邮件中展示，当然我们也为了后期与其他的平台打通（如禅道落库、QA平台数据统计）

  • host地址： 一般我们都有测试环境、预上线环境、线上环境，所以这里配置的一个变量，通过读取配置文件里面的运行环境，自动获取当前运行环境下的host地址，从而实现自动替换，这样我们可以实现一套数据不同环境自由切换

• 接口信息

  • 这里的接口信息主要是放在一个列表里面，可能有些同学会问，这怎么就是列表了，若是有该疑问的话，可以看一下yaml文件的语法

  • 维护到一个列表里面，主要是为了数据驱动使用

  • 其他的信息就是我们接口中的基本信息，这里我们在模板里面做了注释，比较简单，不做详解释

• 重点来了

  • 我们在做接口的时候，需要用到前置处理，就比如我们当前所测试的接口请求参数中，某些请求参数的value值是需要依赖上一个接口响应报文中的某些value值的，这怎么弄呀？

  • 前置处理的一些数据来源啊，以及一些中间件的启动、连接之类的

  • 还有的同学会问，后置处理，我们需要断开一些连接呀，以及清理垃圾数据呀，这个又怎么弄呀？

• 难道只有这些吗？

• 前置处理（数据来源）

  • 有的是需要依赖上个接口，但是有的是需要从数据库里面获取的呀

  • 有的是需要我们通过一些封装好的工具方法自动生成的，就像一些随机数呀，时间戳呀等等

  • 还有的业务比较复杂，是需要我们自定义编写脚本把所需数据处理、整合之后传给其他参数使用的，就比如，我们某些请求参数的value值，是需要通过查询数据库获取到某个值之后，再将这个值与其他的值进行计算，还有的情况是通过多个接口响应报文中的某些值计算之后得来的，那这些又怎么处理？

• 后置处理

  • 断开一些连接呀，这些都不说了，这些可以通过上下文可以进行处理，那说到清理脏数据又怎么处理呀？尤其是在线上环境呢？

  • 其实对于数据清理这一块，可能很多同学会说不就是写sql清理吗？那若是涉及到多表关联？这样做安全吗？这里其实涉及到一个数据打标签的概念

• 断言

  • 有的可能也有这样的疑问，我们的断言中，也有一些数据是动态的，就像时间戳呀，还有一些也是需要其他数据做依赖的，就像前置处理（数据来源）谈及的的一部分，那这种情况又要怎么处理呢？

• Mock

  • 还有同学会说，我们接口需要一些mock支撑的，那这种又是怎么处理呢？

• 多渠道数据来源

  • 有的同学他们公司用的是微服务架构，每个模块可能就对应一个数据库，并不能通过配置公共的数据库，这种模式进行处理，那这种又如何处理呢？

  • 还有的同学说，我们有的数据是从mysql中获取到的，有的呢，是从Redis中取的，那这种又如何处理呢？

以上所有的种种疑惑，我们框架中都已包含在内，甚至远远超过这些，针对不同的数据来源，针对用例的不同运行机制，针对成果物的输出控制我们都有涉及到，而且都是可配置的，后面我们会逐一讲解。