本文就接口自动化中的一些技术难点及接口自动化的意义做一些探讨，请耐心看完，或许有不小的收获

首先，针对本人从事的项目情况做一些介绍，一套类似电商的系统

团购业务系统（类似淘宝）、CRM（客户关系管理系统）、OMS（订单管理系统）、WMS（仓库管理系统）、TMS（物流管理系统），这五个系统存在一个承接关系，数据在五个系统进行流转，如一笔订单系统，现在团购系统生成，流转到 OMS 系统进行订单分发，再到 WMS 系统进行订单入库，配货生成运单等，最后到 TMS 系统进行运单处理，团购系统的一些基础数据是在 CRM 系统进行配置，如产品管理、用户管理等等

现在针对这一整套流程，考虑实现自动化，目前遇到的难点如下：

• 项目流程过程，造数据困难
  目前尝试过几种方式去生成测试数据：
  1.前端造数据（笑笑就好）
  2.通过 jmeter 造数据：这种方式看似有效，实际由于项目流程过长，写脚本的难度很大，造一条运单数据要调用 30 多个，存在于不同系统的接口，光是写接口关联就很头疼了，况且脚本执行的效率也不是很高，唯一的优点就在于，数据能真实可用
  3.利用存储过程直接往数据库插数据：目前仅仅是一个想法，看到几十张或者更多表的关联，我选择了放弃，开发都不一定清楚的，我怎么会知道 = - =

• 接口文档不规范，接口场景缺失
  1.就目前来说，本人基本不看公司的接口文档，无力吐槽，全都是自己先理流程再一个个抓包去看，各个接口间的逻辑关系也靠自己去猜，效率很慢。
  2.接口本身的场景存在缺失，后端很多接口并未做校验，全靠前端限制，EXCUSE ME？？那我还做啥接口测试，连传个异常类型的字符串都不限制，后端直接返回框架原生的报错给我了，这让我思考针对目前的接口开发情况，到底要不要去测试异常场景
  3.本身接口开发存在问题，enum 写的少，场景少，又存在大量的接口数据依赖，那该如何统计场景的覆盖率，又以什么指标来衡量我们自动化的成效？

• 接口用例的维护成本过大
  1.目前我们接口用例是写在 excel，一条一条传给框架去遍历执行的，ps:谁告诉我写 excel 好用的，虽然写代码麻烦，但是写 excel 写的眼睛疼
  2.基于流程的测试，按照 excel 顺序读取下来，流程和流程间很难区分出来，测试报告里仅仅是以列表的形式展示测试的结果，一旦流程间的某个接口出现错误，后续的接口会批量报错（可能是因为本人框架设计的不好导致的,请大佬们指点），但是说实话，本人并不觉得自动化框架是个好用的东西，它只不过是一个能快速实现自动化的解决方案而已，真正能解决问题的，还是一个功能强大的测试平台。

  测试用例

  

用例结果展示

3.自己只能维护自己的用例，你让我去维护别人的！做梦！就算想维护，我也看不懂啊！
4.自动化的数据准备，占用用例的很大一部分，如我需要下单，首先我必须创建一个团购用户，而且团购项目里要有产品，产品又是在合作方下面的，那么好，我去 CRM 把合作方和产品加好，注册一个团购用户....等等，等做了一堆事情后发现，我是要测试啊！我的测试用例呢？花了那么多时间写在了造数据的脚本上面！(有的人可能会问为什么要准备数据，你系统数据被清了，脚本不是白写了？到时候哭都来不及啦！)

• 接口自动化的价值没有体现

1.功能测试不信自动化：虽然说现在都是敏捷流程，靠人工去点肯定是来不及的，回归得靠自动化，但是有了自动化就不用点了吗？测了接口，就算正确了，还不是要前端去回归一下，毕竟接口是看不见莫不着的，不懂技术的功能测试肯定不信这一套
2.自动化投入少，无人支持：单单靠我们（自动化团队 2 人）写用例肯定是不全的，又得熟悉多个系统，又要花时间理清接口间的逻辑关系，靠我们俩效率肯定是很低的。那好吧，我们把这一部分交接出去，让功能测试也开始写接口用例。好了又出现一堆问题：功能测试人员水平有限（http 协议、接口是啥都不懂）、功能测试不相信自动化，并且会觉得增加了他们的工作量（编写用例，维护用例）...这让我思考自动化的意义何在，我们自动化不是为了减少手工吗？为什么反而给功能测试增加了工作量？这就违背了自动化测试的初衷
3.自动化测试出 Bug 少：由于自动化场景覆盖率低下，用例数少（仅靠两人编写），确实难以测试出 Bug，就算能测出来基本也只是环境崩了之类的。。全是通过的自动化是不存在任何意义和价值的！！说到这里就越发怀疑自己的价值，懂那么多技术，为何还无法提升自动化的质量和效率？问题到底出在哪里？？或许当所有测试都拥有自动化测试的能力了，才能做好自动化吧...

说到这里，都是一把辛酸泪啊！
到底自动化如何才能做好？如何才能让自动化真正的产出成果？如何真正的为苦逼的功能测试们减负？
这可能是目前做自动化测试的各位大佬们一个共同的疑问吧
这个问题的答案或许会在不久的未来，有人为我们解答！