接口测试 关于接口自动化的一些疑惑 (必看)！！
本文就接口自动化中的一些技术难点及接口自动化的意义做一些探讨，请耐心看完，或许有不小的收获
首先，针对本人从事的项目情况做一些介绍，一套类似电商的系统
团购业务系统（类似淘宝）、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，就算能测出来基本也只是环境崩了之类的。。全是通过的自动化是不存在任何意义和价值的！！说到这里就越发怀疑自己的价值，懂那么多技术，为何还无法提升自动化的质量和效率？问题到底出在哪里？？或许当所有测试都拥有自动化测试的能力了，才能做好自动化吧...
说到这里，都是一把辛酸泪啊！
到底自动化如何才能做好？如何才能让自动化真正的产出成果？如何真正的为苦逼的功能测试们减负？
这可能是目前做自动化测试的各位大佬们一个共同的疑问吧
这个问题的答案或许会在不久的未来，有人为我们解答！
脚本读取 excel 用户批量造数据，先把新建用户这一过程自动化
个人想法，说错勿怪，自动化框架还是有用的，只是看框架的设计本身。框架设计包含了设计者对自动化测试认知，如何使框架在技术上符合大多数测试场景，设计上规避掉自动化测试的主要风险，使用上降低使用者的入门难易度、增强团队协作和易用性，是否有设计者对框架使用规范上做出建议等等。出发点都是提升自动化的优势，降低自动化的劣势，平台化能好用，是因为它本身集各个数据于一身，在做数据关联和数据统计时，会更加有优势，但底层运行依然是以自动化框架为基础。不是框架不好，而是要考虑是否框架已足够好。
- 你这个只能算半自动化，本身用例管理就应该有一套专门的系统，不应该把功能测试用例和自动化测试用例分开，自动化测试用例其实就是功能测试用例的自动化实现
- 自动化测试用例不应该是自动化测试团队写，自动化测试团队负责工具研发和推广，工具不好用就想办法优化，实际用例应该是各个业务组写，因为只有各个业务的测试人员才最了解业务，工具不应该是障碍，掌握起来不应该有有太多难度，如果这些东西都学不会，测试人员的能力说不过去，这也得看领导的支持力度和推动的决心
- 自动化测试的价值在快速回归，执行高效通过率高，能保证系统质量的底线，前端有 Bug 不会影响核心功能，只要接口能保证没问题，就不会出大问题
- 测试数据的构建是一个大问题，建议有能力就自己开发一套测试数据的构建系统，针对一些测试数据提供一套通用的接口，保证生成的测试数据独立，互不干扰，不受数据库迁移影响
- 接口文档不规范是整个研发体系的不规范，这不是测试的问题，需要测试去主动推动规范，而且现在微服务化之后，其实这块会越来越容易，对微服务来说服务的注册信息极其重要，不然运行时就会有问题。测试可以直接取这些信息，未必非得让人家提供一个文档啥的
最后一段话，说明你们对自动化的价值没考虑好，建议先想好预期收益再做。
1、功能测试不相信自动化。说明文化没上来，大家还没认可自动化。这个需要不断重复宣传，让大家了解自动化，再谈相信
2、自动化投入少。同上，说明你们只是试水，可能 Leader 自己都没认可自动化，不敢投入太多。
3、自动化出 bug 少。这是非常正常的，回归测试本身发现 bug 就少，何况是它的自动化子集。说明对自动化的价值没想好。
分享一下我们的大致路线:
1、明确自动化是每个人都要掌握的，只会有开发框架的专员，不会有自动化测试专员。自动化用例每个人自己写。当然，更多从"这是一个难得让大家提升能力的机会，大家要珍惜"的角度讲。
2、招聘时，代码能力、api 自动化经历是基本要求，获得一批本身就认可自动化的人，起带头作用
3、先从造数据入手，写出来的自动化用于提升造数据效率，进而提升测试效率。由于自己就是作者，自然没信任问题
4、复用造数据的代码或用例，加上适当的断言，直接变成测试用例
另外，前面的没接口文档、后端没参数校验，我猜测你们现在是缺少后端测试的，都是全流程纯黑盒测试，没有关注后端质量的文化，所以现在自动化有点过早了。建议先把后端测试建立起来，倒逼后端要做好文档和参数校验，开始做接口测试，再谈自动化。
共鸣啊，和我当前的状况一样，自动化团队也就 2 人，还时不时被抽走去测功能。
之前测试经理要我们先搞 UI 自动化，好了，框架脚本啥啥啥写好了，3 个月后才意识到版本迭代太快界面经常改变，维护成本太大，就放弃了
后来转战弄接口自动化，也同样的接口文档完完全全不能入目，只能靠自己抓包分析和开发交流解决，心酸啊。
好了，现在连测试经理也跑了，剩下我们在这苦苦挣扎。
顶一下//同样的困境/希望大佬提提建议
testlover
回复
第一条有些不赞同/功能测试用例不可能全部变现成自动化测试用例/自动化测试用例要求简单,目的明确/覆盖增删改查/
一味的贪多/导致后面维护更加困难
陈恒捷
回复
多谢大神指点，我们部分观点是一致的，我觉得公司领导本身不了解自动化也是一个重要的原因，我曾多次跟领导提出 “” 后端未做校验，做场景的覆盖测试是毫无意义的！！“，目前应该做的应该是规范后端的一个接口开发和相关文档后，再考虑异常的一些场景覆盖，从而实现自动化！！
膨化先生
回复
我们现在有部分数据是通过 jmeter 去并发造出来的，但是某些数据，如订单、运单的数据就很难造，因为流程过长导致脚本执行的效率低，这是现在的一个问题
testerYZ
回复
我并没有说 要全部实现自动化 自动化的目标应该是测试场景的自动化 而不是针对接口或者某个功能的自动化 只能说借助某个接口（接口自动化）或者某个功能（UI 自动化）达到场景覆盖的目的 自动化实现有成本 但是因为接口相对更稳定些 所以实现起来效果更好 性价比更高 UI 变动更频繁 执行效果差 性价比低 要不要把某些场景自动化 得综合考虑 业务重要程度 测试资源 执行频率 和实现难度
管理好自动化的投入和产出的预期。
江楷
回复
难造的数据，使用自动化来做，我认为正合适。调用接口 30 多个，订单、运单，应该还会有不同身份用户的操作，页面上操作简直就是灾难
脚本的执行效率低？可以看看在哪些接口上出现了问题，找一下原因
个人观点：自动化测试开发应该独立于业务之外来设计工具。让业务测试人员可以与代码剥离，他们来设计接口用例的参数。参数化，非空遍历，sql 注入等这些通用功能可以封装成功能开关，而工具设计者本身应当着眼于可以提升设计效率，降低难度。
建议写业务接口测试，不要使用这种数据固定的用例，维护成本很高；
业务接口测试，所有的数据都从接口或数据库里面拿，拿已经有的数据；
在上家公司，被招进来搞自动化，进来之后发现版本迭代速度太快，每周至少俩版本，就决定暂时先只做接口的，然后也是各种文档不规范，说错了，是各种文档缺失，然后就自己去找人挨个的了解业务，抓包……终于框架搭好了，重点场景的用例写好了，然后领导觉得自动化这玩意好像没啥用，也就批量产生数据这块有点价值，让我以后先全职去搞功能，自动化先放放。部门自动化就我一人，自动化这东西本来就不是那么好推广起来的，也需要领导有魄力才行，好吧，我走，走人还不行嘛……
我不会服输的，我要搞好接口自动化啊！
同款 report
我觉得自动化 没有必要做全流程吧 做关键的部分 要不然不得累死
testerYZ
回复
testlover 的功能测试用例和自动化测试用例不分开的观点（第一条）我认同，你说的功能测试用例不可能全部自动化实现的观点我也认同，你俩本身就是不同的观点，都对！
质量管理系统里只有测试用例一说，通常测试用例默认的执行方式是手工，可以在 “是否自动化执行” 一项里改为 “是”。
自动化不可能实现所有的测试用例，这是基于多方面的考虑，有的用例本身就不适合自动化比如需要物理动作参与完成，有的用例自动化实现成本过高也需要做出取舍。
造数据没必要通过业务接口去造，可以通过调用较底层的 service 造数据，一般都是可以将流程简化的。
