测试开发，一个对于初入门或者已经有小几年经验的测试伙伴来讲，是一个大多数人会去选择的一个方向。纵观整个测试发展的长河，至今已不再像早些年一样，只要会点点点你就能胜任一份测试工作，而今CICD大肆盛行，敏捷DevOps逐步被人所重视，任何一个层面都要求测试人员必须具备基础开发和设计能力，今天小k老师就从接口自动化的几个方面给大家分享一些心得。
01
选择篇
相信大家如果接触过接口自动化，或多或少会用到一些工具以及框架，像基于TestNG的APIAutoTest、基于postman jenkins newman形式的接口自动化框架等。
话不多说，我们以APIAutoTest为例，来看一下这个框架的设计，如图：
从图中我们可以看到，选择采用这套框架的一个优点是比较轻量级的
1. 采用了TestNG作为了基础测试框架
2. 用Excel作为测试用例数据载体，通过Apache的POI解析，驱动用例执行
3. 请求采用通用的HTTPClient
4. 解析数据层面用了阿里的fastjson和Jsoup
5. 断言部分做的还不错，采用封装jsonpath进行检查
6. 与Jenkins集成，方便自动构建、自动交付与测试
7. 报告采用了ExtentReports支持Email
非常轻量级的一套配置，确实能满足小型项目的常规接口测试需求了，没毛病。
02
这个框架会遇到哪些困难
但是我们一起来看一下实际如果遇到一些复杂的项目，这套框架会遇到哪些困难。
1、没有平台化：首先既然是采用了框架集成的方式进行接口自动化，在维护上对人员的要求就相对高一点，如果能平台化进行维护，那自然更亲民一点也容易让不同层次的测试人员上手（当然这点会有所取舍，毕竟框架应对变化频繁的需求还是会更加灵活一点）。
2、请求方式比较单一：采用HTTP类型的请求方式虽然是常规请求手段，但是如果面对复杂项目请求的类型不一定就只有HTTP一种，如：分布式微服务中大量采用了RPC接口调用（如dubbo接口调用，以下均用dubbo接口为例）
3、数据管理存在维护和执行的瓶颈：
(1) excel形式在多人协作模式下很难做到信息实时统一，也无法做一定的校验，写错了某些东西只能在执行层面发现用例数据写错了，太滞后。
(2) 测试数据量大的一些场景，POI读写方面还需要进行独立优化，否则性能上会带来内存大量开销甚至内存溢出发生。
(3) 面对需要构造大批量测试用例时，人工构造成本太大。
以上三点问题是较为通用性的一些问题，还有一些涉及到复杂业务场景的，小k老师会在后续的一些文章当中会给大家深入提供分析和解决方案参考。
那么对于这类问题有没有好的解决方案呢？答案是必须的！
03
解决方案
前两个问题其实都不算太大的问题，可以在已选框架层面套个前端框架，比如Vue，然后对后端做一些改造补充，使其支持RPC调用方式就行了，那么问题又来了。
Dubbo接口调用的用例数据怎么维护？Excel去维护明显不现实，这时候你只能还是老老实实在后端框架中加用例层，并用前端去管理维护它。那么既然都不采用Excel的方式，那么就索性新老用例统一用数据库的方式存储测试用例就行。
如下图：
04
大批数据如何构造
然后就剩下最后一个问题了，如果遇到大批量数据需要构造如何进行快速构造的问题
对于这部分，我相信特别是处于大数据行业的朋友就深有体会。那么小k老师今天介绍的一个方案是基于数据工厂来帮助提升造数效率。
数据工厂基本功能：
1、采用抽象工厂模式进行不同类型数据的生产模型创建
2、按照不同数据类型的原始模板动态生成所需数据
3、批量生成测试环节中所需的各种数据
4、补全Mock导致的业务数据不全问题
如图所支持的场景：
其实数据工厂用途还可以再细化扩充使其在测试平台搭建的过程中解决更多实际的数据问题，这里小k老师的一套自动化管理平台，目前上述所提到的点都已经在平台上实现了。
