新型接口自动化解决方案与框架可行性分析

接口自动化现状

传统的接口自动化方案有一定的收益，但成本过高， 导致整体性价比过低。另外当团队人力增长和后续业务发展预期不匹配时，再使用传统自动化方案无法满足自动化测试需求。

成本高主要是体现在三方面：

整体开发成本高，开发时间跨度大， 对测试开发人员有一定的能力要求

维护成本高， 随着被测试系统持续迭代， 测试人员需要持续更新测试脚本，否则产出就会下降

复用性差， 一套代码适用一个系统， 换一个系统就需要重新开发， 成本是线性增加。

而产出或效果方面，

覆盖度不够，也限制了自动化的产出。覆盖度和成本成正相关。

产出不足， 对数据的验证较为简单，自动化有效性下降。验证复杂度和成本成正相关。

在成本限制的情况下， 覆盖度和产出都不会很高，最终结果还是性价比低。

要解决的问题

假设以覆盖率100%为前提，做一个项目的自动化测试成本分析

从上表来看， 最大的工作量是在开发用例和维护用例上， 这也是提升自动化测试性价比的关键。

为了解决自动化的性价比问题， 需要解决两方面问题

大幅提升覆盖率

低成本或完全自动化地开发测试脚本

解决方案

方案目标和内容

传统自动化是人工分析，人工编写，自动执行。而咱们要实现的目标是人工分析，自动生成，自动执行。

根据测试用例分析理论和市面上开源的测试工具库，结合接口测试的过程(参数组合，接口关联，数据传递和结果验证)，

开发一个基于少量的人工定义，实现全自动化的接口测试框架。最终实现快速响应多项目自动化的需求，快速落地产品的功能自动化测试和环境自动化巡检。

核心内容包括：

接口入参自动化组合， 基于测试理论分析，给出人工定义，自动化确定取值，组合参数，自动生产用例， 覆盖更全。

接口结果验证， 实现多重校验策略，包括code验证，json结构验证，基于LLM SQL的数据库验证，用户自定义代码验证等， 更精准地验证，提升自动化可信度。

接口自动化组合，基于接口关系进行接口自动化组合，自动生产用例，覆盖更全；提供用户自定义流程用例。

以上内容基于框架的自动化功能完成， 只有少量工作需要人工介入， 包括接口参数定义， 接口关系及参数传递关系。而非自动化能完成的复杂业务流程(相对少数)和 用户自定义代码验证，根据测试需求可选。

实现形式：

主要给用户提供前端入口，降低门槛，方便使用，后端实现主体框架功能。

可行性分析

参数自动化生成：根据等价类和边界值理论，由用户设入参的范围。以有限的规则可以适配大部分的情况

结果验证：实现多重校验策略，包括状态码验证、业务字段验证、JSON结构验证、自定义函数验证、基于LLM SQL的数据库验证等。前四者在技术上是成熟的。后者基于现在的语言大模型可以准确的转化出简单的sql而实现数据查询并自动验证。

参数自动化组合：主要是基于策略的自动化组合并生成接口用例再自动执行，不存在技术难度。

成本效益分析

开发成本：自动化框架的开发需要一定的前期投入， 大概2个月~3个月， 占一个大项目完整实现自动化的40%~60%的工作量。

维护成本：维护成本取决于框架的可扩展性和易用性。主要是BUG修复和项目特殊需求的适配性开发。

复用性：框架的复用性是关键。这框架与业务无关， 不同项目基本不需要重复开发， 可以复用。

收益：实现此方案后，以测试人员完成一个项目的接口自动化开发为例做对比

另外，也注意到，传统的接口测试方案（pytest）的覆盖率很难达到100%， 一般大投入的情况下，覆盖率最多就达到70%~80%， 时间基本要1~2季度。

实现上面方案，可以达到这几点效果：

大幅减少自动化用例开发的工作量，快速实现自动化，适应初期项目多变的情况

极大提升覆盖率，提升自动化结果的可信度，真实地产出

框架的可复用性可以减少多个项目的重复工作

框架的规范性降低人员交接的难度

风险评估

技术风险：框架的开发可能面临技术难题， 比如设计不当，工具调研不充分等情况，都可能造成资源浪费，影响进度

框架易用性需要持续打磨（但不会太久，因为是内部使用框架，能用即可）

业务风险：框架放弃了一定的灵活性来换取低成本，对业务逻辑复杂的部分场景，可能需要测试脚本作为补充

以上仅为个人经验之谈， 欢迎大家来一起探讨一起进步