接口自动化测试

接口自动化测试概述

接口自动化测试的目的是在一定的人力的基础上，花最少的时间，达到最大化的测试收益。
因此接口自动化测试需要考虑3个方面：人力，时间，收益。

总体来说就是要提高自动化接口测试的投资回报率：减少投入成本和增加使用率。

减少投入成本：

1. 减少用例录入成本(测试用例的录入操作要简单)
2. 减少用例维护成本(测试用例维护只需要简单的输入，而不需要修改代码)
3. 减少用例优化成本(通过一些统计数据，进行有针对性、有目的性的用例优化)
4. 减少工具开发的成本(尽可能使用已有的，或是业界成熟的工具或组件)
   增加使用率:
5. 手工能用(类似postman)
6. 工具使用(一些接口测试用例，构建测试环境)
7. 每日使用(每日构建测试)
8. 开发的在构建之后也能触发测试(基本功能点测试)

我们需要看到“收益”，不能为了总想看到100%的成功，而少做或者不做校验，但是校验多了维护成本一定会增多，可能每天都需要进行大量的维护。

自动化测试框架

接口自动化测试框架可以理解为让接口测试脚本运行的一整套环境。正常一个自动化测试框架有以下几个管理模块：

• 数据管理：即测试数据的存储管理，其中包括：log（日志文件）、report（测试报告）、单个接口的测试数据（如：json格式）、接口业务串联的数据(如登陆数据）
• 脚本管理：接口测试脚本的统一管理、存储、调度中心；
• 平台管理：一般是借助工具来运行这些测试脚本，持续集成，测试结果统计等

很多团队都是使用这样的结构来进行接口自动化测试，因为这种框架的学习和迁移成本低都会比较低

脚本设计

1.@DataSource为测试数据，测试数据与脚本分离，在测试平台可以更换测试数据。
2.@AutomationTestCase，name表示测试用例名称，在测试平台可以按照此模版扩展测试用例，增加测试用例。

测试用例直接写在Java文件中，带来的问题：修改测试用例需要改动大量的代码；代码也不便于交接给其他同学，因为每个人都有自己的编码风格和用例设计风格，这样交接，最后都会变成由下一个同学全部推翻重写一遍；如果测试平台更换，无法做用例数据的迁移，只能手动的一条条重新输入。
测试数据与脚本分离是非常有必要的

用例设计

通用操作

简单、方便

1. 用例数据与脚本分离，简单、方便
2. 免去上传脚本的动作，能避免很多不必要的错误和维护时间

模板化

1. 数据结构一致，便于批量操作
2. 抽象出通用的模板，可快速拓展

可统计、可拓展

1. 可统计、可开发工具
2. 可开发用例维护工具，批量生成工具

校验操作

• 足够多的检查点，检测出更多服务缺陷
• 尽量少的误报，减少维护成本
• 模块化验证点，减少验证代码，提高代码使用率

健壮

被测系统出错：自动化测试真正地发现了一个Bug，用例发挥了它的价值
测试工具出错：不希望看到的，自动化相当于白跑了。
测试数据错误：这是我们要避免的，既然数据容易失效，那我在设计测试平台的时候，就需要考虑如果将所有的数据跑“活”，而不是只写“死”。
不可抗力：这部分是我们也很无奈的，但是这样的情况很少发生。
参考地址：https://tech.meituan.com/2018/01/09/lego-api-test.html