背景与现状：

以笔者目前了解，接口自动化实现通常有以下三种方式：
方式一：基于用例的逻辑，直接编写接口自动化脚本，
方式二：将关键字的入参出参展示在前端，通过前端步骤对不同关键字的顺序以及入参描述，生成接口自动化脚本
方式三：按照文本用例步骤描述，在前端进行操作，基于生成的 har 文件，解析里面 har 文件的调用顺序进行关键字生成和封装，生成接口自动化脚本

三种不同方式的优缺点分析：

方式一：脚本编写人能需熟悉接口自动化代码结构，对脚本能直接掌控，比较灵活
方式二：之前的论坛上看到过相关的应用，个人觉得表面上看起来高大上，实际不但没有提升构建效率，反而降低了效率，一方面每条用例的各个关键字模块的入参还是需要人工理解和填写，而且增加了前端人员操作的工作量，且校验点判断等较方式一更加复杂化，实用性较差
方式三：该方式通过人工步骤生成的 har 文件中接口调用顺序能辅助生成对应用例的自动化脚本，接口入参能自动填充，问题在于生成的自动化代码可能换了前置条件后无法使用（接口入参发生变化），且校验点部分也需要人工编写

笔者思考的方式四：

基于 har 文件中接口调用顺序，与前后接口出参与入参的关系生成该用例的核心执行脚本，然后人工写对应的前置部分与生成的核心执行脚本拼接，并手工写校验点（核心其实只优化了核心执行步骤脚本的实现效率）

待优化点：

1、如何自动化生成前置和校验点部分
2、同模块业务不同用例间执行步骤具有高度相关性，这些高度重复的步骤事实是可以组合形成新的关键字，所以是否还是需要借用前端，将手工写的前置、生成的核心执行步骤关键字暴露出来，进行共享，修改，那么方式四相对于方式二的提效好像仅仅是节省了封装关键字的时间 。

其它问题点：

1、接口自动化脚本的评审有没有什么好的方法和评价标准呢？
2、项目重构接口变了，导致之前的脚本用不了大家是怎么办的呢？

有没有其它更好的提升构建方法呢？欢迎大家讨论交流呀~