接口自动化测试的一点总结，浅谈接口自动化测试

本文是关于接口自动化测试-总结

前言

本文是我在公司总结的一点点个人建议, 可能有非常多的遗漏, 先记录下来这时候我的理解。公司是做共享单车业务的, 所以场景基本上也可以复用, 毕竟大家都骑过单车。注明: code是我司接口返回的标志。

编写之前

• 接口相关(这块总结不全)

  了解接口的功能及其使用场景(正常/异常)及接口具体做的事情。

• 接口实现了什么功能

• 接口是否有操作了数据库对应字段

• 接口是否有操作了redis对应key

• 接口的入参

  包括必填项和选填项丢失/多余带来的影响, 入参字段的长度是否有限制, 如身份证姓名等

• 接口的出参

  包括正常/异常场景下code, msg等字段的校验, 如有返回数据, 对返回数据的校验如何去做

• 接口的设计是否符合功能的预期

  如数据不允许重复时, 连续调用接口2次是否会插入2条数据

• 场景准备

• 掌握每个场景所需要的前置条件

  如关锁接口在 正常使用时，他的前置条件为该车辆的锁已经打开。

• 考虑如何设计场景

  可选择数据库/redis添加测试数据或调用接口新增数据的办法(==接口之间会存在依赖, 一旦添加数据的接口出错, 此场景也无法验证==)

• 用例数据准备

• 尽可能的动态准备测试数据

  如车辆编号, 可选择从数据库捞取。如有身份证号+姓名这种较为复杂的数据, 可写在变量里。但需要多挑选几组数据, 随机读取

• 数据依赖

  优先采取新增数据的方式, 保证之前数据完好, 新增数据如有name等字段, 可带上特定标识+时间戳的方式。在用例执行完成之后将其清除, 如果出现垃圾数据, 也便于使用定时任务进行清理。

• 尽量不要把数据写死

• 断言

  对比较重要的字段作断言, 如需要展示给用户的字段。

• http状态码校验

• code/msg校验

• db校验(业务相关, 如无类似情况可忽略)

  存在接口名返回与数据库不一致的情形, 应以接口为主。db目前多使用下划线式, 接口出参常使用驼峰式。编写sql查询语句的时候, 使用select ride_type as rideType此类。

• 异常场景db校验

  为了防止: 接口出参返回code不为0, 但db却被修改。

• redis校验

  如有涉及到redis, 需要对redis字段做断言。

• 最近比较火的异步接口

  异步接口如何做断言, 本人没有太多接触。由于http协议是无状态的, 异步接口一般是调用后将任务放入消息队列, 接口就成功返回了。我的理解是去检查消息队列是否存在消息, 如有如果被消费了, 可起一个收尾类似tearDown的用例专门针对异步接口, 当他们消费完毕之后, 再对数据库/redis进行相关校验。

开始编码

• 编码

  gat是公司内部封装的基于golang的自动化测试框架, 其实只封装了http请求和做了一部分单元测试框架的工作。

• 用例描述

  用例编写之前, 脑海里应该有以下几点。如何设计场景, 覆盖哪些场景, 如何做断言。可以在文件顶部, 写入自己的思路, 这样在编码过程中会游刃有余, 不至于乱了方寸。之后维护的时候也不至于被业务逻辑绕晕。

• setUp和tearDown

  目前gat框架是由TestFuncName为入口, 我们可以在函数开始执行后, 调用setUp()函数, 将自己想处理, 想得到的数据都处理完成。再后面就是逻辑的代码, 到最后使用tearDown进行清理。

• 用例名称与Action对应, 文件名尽量与结构体名一致

• 大体结构

• 注释要多写, 常用方法可以封装

  /*
  测试功能点: 检查用户行程
  
  覆盖到的场景:
  1. 用户正在骑行中
  2. 用户未骑行
  
  数据准备:
  这里填写, 你将怎样制作数据
  
  数据清理:
  这里填写, 你将如何清理脏数据
  
  用例执行流程:
  这里写你的执行思路, 首先检测什么测试点, 然后....
  
  断言:
  写出断言的标准, 理由, 如何做(这也是评审的一部分)
  
  */package UserCenterimport (        "fmt"
          "testing"
          )type struct UserRideCheck {
      Data []map[string]interface{} // 测试数据
      Action string  //调用接口名}func (u *UserRideCheck) setUp() {
      fmt.Println("用例正准备执行!")
  }func (u *UserRideCheck) tearDown() {
      fmt.Println("用例执行完毕, 正在清理!")
  }func (u *UserRideCheck) TestUserRideCheck() {
      setUp()  // 初始化
      //主逻辑, 可再封装函数
      defer tearDown()  // 清理(后续可添加Recovery防止用例失败阻塞)}func init() {    // 自己框架添加用例的逻辑
      data := initStruct()
      testcase.Cases["UserCenter"] = append(testcase.Cases["UserCenter"], data)
  }func initStruct() *UserRideCheck{    return &UserRideCheck {
          Action: "user.ride.check"
      }
  }// unittestfunc UnitTestUserRideCheck(t *testing.T) {
      u := initStruct()
      u.TestUserRideCheck()
  }

附加:

• 如果可能的话, 对开发做代码走查, 尽可能覆盖其if else分支

• 我们自身的代码也会出错, 我们需要用日志记录测试过程中接口出现的问题以及自己的问题

• 如果可以, 与CI结合

昨晚在某个测试交流群，听了一个测试老司机分享接口自动化测试的内容，对接口自动化有了更深的一些认识，也为接下来公司的接口自动化实施，提供了更多的思路。

这篇博客，就说说功能测试到接口自动化的进阶，以及接口自动化的一些事。。。

前言

自动化测试，算是近几年比较火热的一个话题，当然，更是软件测试未来的一个发展趋势。未来，功能测试等非核心的测试工作，都将被外包。

想要在软件测试这个行业继续前行，就必须拥有核心竞争力，掌握自动化测试技术，是必不可少的一个技能。

在《Google软件测试之道》一书中有介绍到：在Google，70%的自动化测试工作集中于单元测试，20%集中于接口测试，剩下10%才是UI测试。

诚然，我们没有Google那么完善的机制和工程师文化，没必要一切照搬Google，但Google作为互联网2.0时代最耀眼的一个公司，它的技术发展方向，流程管理等可以说是不久的将来，

我们也要到达的方向。选择适合自己的，落地应用，是当下我们应该做的。

目前国内的互联网行业，大环境来说，还处在一个快速发展，需要流程化标准化的时期，如何跟上不断变幻发展的节奏，除了不断了解接触新的东西，还需要不断学习，提升自身，以内在

的驱动力，去紧跟时代浪潮。即使做不了弄潮儿，也不能变成时代淘汰的那一批。说到这里，推荐2本书：吴军的著作《浪潮之巅》、《硅谷之谜》，感兴趣的童鞋可以去看看。。。

一、接口测试的必要性和意义

接口，即API，应用程序编程接口，关于接口的介绍，之前的博客就有详细介绍过，感兴趣的童鞋可以去看看：接口测试简介

这里主要说说接口测试的必要性和意义：

接口测试实施在多系统的平台架构下，有着极为高效的成本收益比（当然，单元测试收益更高，但实施单元测试的成本投入更大，技术要求更高，所以应该选择更适合自身的才是最好的方案）。

接口测试天生为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台复杂，系统越庞大，接口测试的效果越明显。

总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益驱动作用下的最佳方案，主要体现在如下三个方面：

1、节省了测试成本

   根据数据模型推算，底层的一个程序BUG可能引发上层的8个左右BUG，而且底层的BUG更容易引起全网的死机；接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。

2、接口测试不同于单元测试

   接口测试是站在用户的角度对系统接口进行全面高效持续的检测。

3、效益更高

   将接口测试实现为自动化和持续集成，当系统复杂度和体积越大，接口测试的成本就越低，相对应的，效益产出就越高。

二、做接口测试需要哪些技能

关于这点，在之前的博客也说过，传送门：做接口测试需要哪些技能

做接口测试，需要的技能，基本就是以下几点：

业务流：了解系统及内部各个组件之间的业务逻辑交互；

数据流：了解接口的I/O（input/output：输入输出）；

协议：包括http协议，TCP/IP协议族（之前的博客有系统的介绍过协议，传送门：http协议：菜鸟入门系列）

工具：工具可以辅助我们更好更高效的完成工作，常用的接口测试工具有：jmeter、loadrunner、soapui、postman等；

数据库知识：无论是从数据库获取知识，还是确认数据落地，抑或接口对数据执行了哪些操作，都需要确认，因此数据库知识（其实就是增删改查）就很有必要；

补充：接口文档的几个必要点：完整性、一致性、容错性；

三、接口自动化测试

1、如何开展

首先，调试单个接口，保证单个接口的正确和通畅（类似于性能测试中的基准测试）；

其次，明确数据流，业务流；

最后，将N个接口测试脚本串起来，执行即可；

最重要的一点，别想太多太复杂，先把最基础最简单的做起来，就成功一大半了，至于扩展性的第三方接口、https、定时任务、自动出测试报告、自动发邮件等等功能，这都是不断累计和优化的，

行动起来就行，想太多不如行动起来，让接口自动化测试落地，才是我们首先需要考虑的！

2、开展之前需要知道的

现在的测试对象包含几个页面？

每个页面涉及几个接口？

分别在哪一步调用？

每个接口包含哪些字段？

各个字段对应数据库哪张表？

每个表中各个字段是什么意思？

各个接口对表产生了怎样的操作？

3、自动化框架

什么是框架？你可以理解为一个完整的环，也可以理解为让接口测试脚本运行的一整套环境，平台，随便什么都可以；一般一个自动化测试框架包含以下几点：

数据池：即测试数据的存储管理，一般集成为一个data包，其中包括：

       log（日志文件）、report（测试报告文件，一般为xml格式）、case-data（单个接口的测试数据，一般为json格式）、server-data（接口业务串联的数据，可以用excel管理）

脚本管理中心：接口测试脚本的统一管理、存储、调度中心，常用的工具有maven、ant等，或者可以使用编程语言中的单元测试框架提供的功能，选择自己适用的即可；

运行平台：一般是借助工具来运行这些测试脚本，工具可以使用上面提及到的几种（jemter、loadrunner、soapui等），同样，选择合适的很重要；

持续集成工具：最常见的就是Jenkins，它的作用就是监控外部程序的调用执行，定时或者触发调度任务，测试脚本执行等功能；

通信服务：dubbo、spring_boot、thrift等RPC、REST同步调用服务；

测试结果统计管理中心：比如testlink，目的是为了测试结果自动更新上传，更好的统计测试结果，以便后期的优化；

上面说了这么多，实际上它的意义就是：数据与脚本分离，测试结果自动提交通知，提高测试脚本和测试数据的维护便利等等。。。

我正在使用的框架为：jemter+maven+Jenkins+dubbo+MySQL......

关于接口自动化测试，基本就是上述的内容，当然，选择适合自身实际情况的框架，落地实施，才是重点，行动起来，才能咸鱼翻身。。

以上就是小编为大家整理的接口自动化测试-总结

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。