AI 时代 SaaS ERP 自动化测试路线：先补接口级黄金流程

摘要

AI Coding 让代码产出速度变快，但它也把一个老问题放大了：

text 复制代码

代码写得更快了，谁来证明老业务没有被改坏？

尤其是 SaaS ERP 这类复杂业务系统，问题通常不在某一个方法有没有返回值，而在一条完整链路是否仍然成立：

text 复制代码

登录
  -> 鉴权验签
  -> 租户上下文
  -> Controller
  -> Service
  -> DB
  -> 内部服务调用
  -> 返回结果
  -> 库存 / 应收 / 流水 / 日志 联动

如果自动化测试只停留在局部单元测试，它能兜住部分规则，但很难挡住 AI 改代码后破坏真实业务闭环。

这篇文章聊一个更务实的路线：

text 复制代码

不要从测试平台开始
不要从报告美化开始
不要从 UI 自动化开始

先补接口级黄金流程回归测试

一句话结论：

text 复制代码

AI 时代的自动化测试，不是为了证明 AI 写得多快，而是把"哪些业务不能坏"变成可重复执行的判断标准。

1. AI 时代，测试的重心变了

以前研发改代码，很多风险来自人：

text 复制代码

人忘了边界
人漏了历史兼容
人没想到某个配置组合
人只测了 happy path

AI 参与之后，这些问题不会消失，只是换了一种表现：

text 复制代码

AI 能快速改出一版看起来合理的实现
AI 能补出一堆看起来像样的单元测试
AI 能解释业务规则，但不一定真的覆盖业务不变量
AI 能复用已有代码风格，但可能误伤历史语义

所以 AI 时代真正需要增强的，不是"让 AI 多写几条测试"，而是建立一套可执行的回归安全网。

这张网至少要回答：

text 复制代码

哪些流程是 P0，坏了就不能发布？
哪些业务不变量必须长期成立？
哪些历史 bug 必须变成永久回归？
每次 AI 改代码后，应该交付什么验证证据？

如果没有这张网，AI Coding 很容易变成：

text 复制代码

写得更快
错得更快
回滚得也更快

2. 先别选工具，先定义"哪些业务不能坏"

自动化测试最容易走偏的一条路是：

text 复制代码

先选工具
  -> 先搭框架
  -> 先接报告
  -> 最后才想测什么

这条路的问题是，测试的本质不是工具，而是业务正确性的可执行表达。

更合理的路径应该是：

text 复制代码

先定义核心业务不能坏的流程
  -> 再定义每个流程的前置条件、步骤、预期结果
  -> 再选维护成本最低的工具
  -> 最后接报告、流水线、通知和门禁

以 SaaS ERP 为例，AI 不能替你决定这些问题：

text 复制代码

商品创建后哪些字段必须可查？
库存初始化后哪些维度必须一致？
销售订单创建后库存应该扣多少？
收款后应收、流水和账务应该怎么联动？
租户 A 的数据为什么不能被租户 B 查询？
历史订单在配置变更后是否还能按原语义展示？

这些不是工具问题，而是业务系统自己的正确性定义。

所以，自动化测试的第一步不是：

text 复制代码

我要用什么测试框架？

而是：

text 复制代码

哪些业务事实必须长期成立？

3. SaaS ERP 测试应该分层

自动化测试不是一种工具打天下，而是一组不同层级的组合。

层级	主要验证什么	常见工具	建议定位
单元测试	单个类、方法、规则、helper	JUnit、TestNG、Mockito	必须保留，负责局部规则
集成测试	Spring Bean、Service、Mapper、事务、DB	SpringBootTest、Testcontainers、测试库	按风险补，不盲目铺开
接口自动化	从系统外部调用 HTTP API，验证业务闭环	RestAssured、Karate、Postman/Newman	第一阶段主线
UI 自动化	浏览器真实点击、输入、断言	Playwright、Cypress、Selenium	后置，覆盖少量关键页面
AI UI 测试	用视觉模型和自然语言操作页面	Midscene、mabl、Testim	试点，不做第一层强门禁
性能测试	并发、吞吐、响应时间、容量	k6、JMeter、Locust	后置，针对高风险链路

3.1 单元测试：必要，但不充分

单元测试的价值很明确：

text 复制代码

快
定位准
成本低
适合覆盖规则、helper、金额计算、枚举转换、边界分支

它的问题也很明确：

text 复制代码

大量 mock 不走真实数据库
不经过真实 HTTP
不经过网关、鉴权、验签、拦截器
很难验证跨模块闭环

所以单元测试是必要条件，不是充分条件。

3.2 集成测试：定位问题很有用，但别一开始就大铺

集成测试通常在 JVM 内部跑：

java 复制代码

@SpringBootTest
public class OrderServiceIntegrationTest {

    @Test
    public void testCreateOrder_shouldPersistOrderAndItems() {
        orderService.createOrder(request);
        // 查询数据库或调用 Service 校验结果
    }
}

它能验证：

text 复制代码

Spring Bean 是否正确装配
Service 和 Mapper 是否协同正常
事务是否正常
数据库写入和查询是否正常

但它通常不经过真实 HTTP、登录态、请求头、签名和网关策略。

我的建议是：

text 复制代码

不要为了"自动化测试体系"先大规模补集成测试。
接口黄金流程失败后，如果定位到 Service / Mapper / 事务问题，再补对应集成测试。

3.3 接口自动化：当前最该补的一层

接口自动化从系统外部发起请求，尽量接近真实前端调用：

text 复制代码

测试代码
  -> HTTP API
  -> 鉴权验签
  -> 拦截器
  -> Controller
  -> Service
  -> DB
  -> 内部服务调用
  -> 响应结果

它能验证：

text 复制代码

接口路径是否正确
请求头是否完整
token 是否有效
签名是否正确
租户上下文是否正确
Controller 入参序列化是否正确
Service 业务规则是否正确
数据库真实状态是否正确
内部服务调用是否可用

这层最适合防 AI 改代码后破坏老业务。

4. 为什么第一阶段要补"接口级黄金流程"

很多团队做自动化测试时，会同时想做：

text 复制代码

单元测试补覆盖率
接口自动化
UI 自动化
测试报告平台
性能压测
AI UI 测试
CI 门禁

结果往往是摊子铺得很大，但没有一条流程稳定跑起来。

对 SaaS ERP 来说，第一阶段更应该做的是：

text 复制代码

5-10 条 P0 接口黄金流程

所谓黄金流程，不是随便调几个接口，而是能代表业务闭环的最小链路。

比如：

text 复制代码

登录成功，拿到 token
创建商品分类
创建商品单位
创建普通商品
查询商品详情
查询商品分页
校验当前租户可查
校验其他租户不可查

再往后可以扩到：

text 复制代码

商品
  -> 库存初始化
  -> 销售订单
  -> 库存扣减
  -> 客户应收
  -> 收款流水

这类测试的价值不只是"接口返回 200"，而是验证一条真实业务链路还活着。

5. 工具选型：优先选团队维护成本最低的

如果团队主语言是 Java，项目本身是 Spring Boot，并且已有 TestNG/JUnit 测试基础，那么第一阶段可以直接选择：

text 复制代码

Java + TestNG/JUnit + RestAssured

原因很简单：

text 复制代码

语言一致
Maven 接入自然
CI 接入自然
可以复用 DTO、枚举、签名工具
后端团队维护成本低
代码评审和 Git diff 友好

也可以考虑 Karate。Karate 在 API 测试、断言表达、并行执行、mock 等方面很成熟，适合偏测试平台化的团队。

Postman / Apifox 更适合：

text 复制代码

手工调接口
接口文档
临时验证
前后端协作

但不建议把它们作为核心黄金流程资产。复杂业务断言、测试数据准备、验签逻辑和 Git 评审，代码化通常更稳。

Python + Pytest 也很好，但如果团队本来就是 Java 后端团队，引入 Python 意味着新增一套语言、依赖、运行环境和维护习惯。除非团队已有测试开发基础，否则不是第一阶段最低成本路线。

6. 第一阶段用例不要平铺，要分级

SaaS ERP 的业务线很多：

text 复制代码

基础资料
商品
库存
采购
销售
客户
供应商
财会
餐饮
报表
设置
营销

如果一开始平铺写测试，很快会失控。

更合理的是分级：

text 复制代码

P0 冒烟用例：
最核心、最不能坏的 5-10 条流程。
每次改代码、发版前跑。

P1 黄金流程：
主要业务闭环，约 20-40 条。
每天或大版本前跑。

P2 回归用例：
更多边界、异常、配置组合。
夜间或发版前跑。

第一阶段只做 P0。

不要追求一开始就 100% 覆盖。能稳定跑起来的 8 条 P0 用例，比一份宏大的测试平台设计更有价值。

7. P0 为什么建议从商品线开始

商品是 ERP 的基础对象。

没有商品，后续很多链路都很难稳定验证：

text 复制代码

库存
采购
销售
餐饮菜单
报表
财会流水

所以第一阶段从商品线切入是合理的。

一个最小 P0 可以是：

text 复制代码

1. 登录成功，拿到 token
2. 客户分页查询成功
3. 创建商品分类成功
4. 创建商品单位成功
5. 创建普通商品成功
6. 商品详情查询成功
7. 商品分页可查到当前商品
8. 当前租户可查，其他租户不可查

这 8 条稳定后，再串：

text 复制代码

商品
  -> 库存
  -> 销售订单
  -> 收款
  -> 应收
  -> 财务流水

后续扩展顺序可以是：

text 复制代码

第一阶段：商品 -> 库存 -> 销售订单
第二阶段：客户 -> 收款 -> 应收 -> 财务流水
第三阶段：供应商 -> 采购订单 -> 入库 -> 付款 -> 应付
第四阶段：价格策略 -> 促销 -> 支付方式 -> 打印配置
第五阶段：餐饮桌台 -> 菜单 -> 点餐 -> 加菜 -> 结算 -> 沽清
第六阶段：库存报表 -> 销售报表 -> 财务报表

这个顺序的核心是：

text 复制代码

先基础对象
再库存事实
再交易闭环
再财会联动
再页面和报表

8. 测试数据策略：别让清理逻辑比业务还复杂

接口黄金流程会真实写入测试环境数据库。

这不是坏事，正是它的价值：

text 复制代码

验证事务是否真实提交
验证库存是否真实变化
验证订单和明细是否真实落库
验证租户隔离是否真实生效
验证查询接口是否能查到真实状态

但测试数据必须受控。

常见方案有三种：

方案	做法	优点	缺点
用例后删除	每条用例结束后清理数据	环境干净	ERP 强关联数据删除复杂
运行前重置测试库	每次跑前还原数据库快照	最干净	需要环境和脚本支持
专用测试租户 + 唯一编码	数据带 AUTO_TEST 前缀和 runId	最容易落地	数据会积累，需要定期清理

第一阶段我更建议第三种：

text 复制代码

专用测试租户
固定测试账号
所有自动化数据加 AUTO_TEST 前缀
每次运行生成 runId
测试只查询和断言当前 runId 的数据
每天或每周清理 AUTO_TEST 数据

示例：

text 复制代码

AUTO_TEST_20260826_101500_PRODUCT_001
AUTO_TEST_20260826_101500_CUSTOMER_001
AUTO_TEST_20260826_101500_ORDER_001

第一阶段不要强制每条用例实时删除数据。

ERP 数据链路复杂，订单、库存、账务、报表、日志可能都有关系。强行清理，很容易让测试框架本身变得比业务还复杂。

9. 登录、token、请求头和签名要真实走

很多接口自动化做不稳，是因为跳过了真实认证链路：

text 复制代码

固定 token
绕过签名
直接调用内部接口
手写一套和前端不一致的 header

第一阶段要尽量贴近真实调用。

推荐策略：

text 复制代码

每次测试启动时登录一次
不要长期依赖固定 token
请求头由统一 SignedApiClient 构造
签名逻辑优先复用项目已有工具
密钥、账号、baseUrl 通过环境变量或 CI 密钥配置注入

需要输出和排查的内容包括：

text 复制代码

baseUrl
method
path
request headers
request body
response status
response body
runId
业务编号
traceId / requestId

这里有一个原则：

text 复制代码

测试代码不要重新发明一套安全协议。

如果项目已经有签名工具、请求头规范和登录模型，测试工程应该复用或严格对齐。

10. AI 在测试体系里的正确位置

AI 很适合做这些事：

text 复制代码

根据接口文档生成测试草稿
根据 curl 生成 RestAssured 调用代码
根据 bug 复盘补充回归用例
根据业务规则生成测试矩阵初稿
根据失败日志辅助定位问题
根据断言缺口提醒未覆盖场景

但 AI 不应该替你决定：

text 复制代码

哪些流程是 P0
哪些业务不变量必须成立
哪些历史兼容不能破坏
哪些测试失败必须阻断发布
哪些测试数据可以清理
哪些截图或数据可以发给外部模型

AI Coding 的质量治理应该有一条底线：

text 复制代码

AI 可以参与实现，但不能用"看起来没问题"作为交付证据。

每次高风险改动，至少要交付：

text 复制代码

改动路径
风险点
已跑测试
未验证场景
历史兼容说明
回归矩阵或业务不变量核对

成熟做法不是靠人脑记边界，而是把边界沉淀成：

text 复制代码

回归矩阵
业务不变量
永久回归测试
CI 门禁

11. CI 接入顺序：先固定一条命令

CI 平台不是重点。

Jenkins、GitLab CI、GitHub Actions、云效 Flow，本质都是自动化执行平台。

正确顺序是：

text 复制代码

1. 本地把接口自动化跑通
2. 固定一条 Maven 命令
3. 确认这条命令在任意机器都能跑
4. CI 执行这条命令
5. 再配置报告、归档和通知
6. 稳定后再决定是否阻断部署

例如：

bash 复制代码

mvn -pl saas-erp-e2e-test test -Denv=test

流水线可以抽象成：

text 复制代码

拉代码
  -> 设置 JDK / Maven
  -> 配置私服权限
  -> 注入测试账号和密钥
  -> 执行测试命令
  -> 归档 surefire / allure 报告
  -> 失败通知或阻断发布

第一天不要先接 Allure。

更稳的顺序是：

text 复制代码

先跑通测试
  -> 再看 Maven/TestNG 原生报告
  -> 5-10 条黄金流程稳定后再接 Allure

报告很重要，但它不是第一阶段的瓶颈。

12. UI 自动化和 AI UI 测试要后置

UI 自动化有价值，但不应该成为第一阶段主线。

原因很现实：

text 复制代码

页面选择器容易变
权限菜单容易变
测试账号状态容易变
弹窗、加载、分页会增加不稳定性
失败定位不如接口测试直接

如果要做 UI 自动化，长期稳定需要前端配合：

text 复制代码

关键按钮加 data-testid
测试环境提供稳定账号
验证码和二次校验有测试策略
菜单权限固定
测试数据可控

AI UI 测试更适合试点。

Midscene 这类工具通过视觉和自然语言操作页面，上手成本低，对 DOM 选择器依赖少。但也要接受它的现实边界：

text 复制代码

执行慢
稳定性需要观察
失败原因不如接口测试清晰
截图和业务数据可能涉及合规

所以我的建议是：

text 复制代码

接口黄金流程做第一层门禁
UI 自动化覆盖少量关键页面
AI UI 测试用于探索、冒烟和辅助排查

13. 失败定位必须产品化

自动化测试失败不可怕。

可怕的是失败后只看到：

text 复制代码

expected true but was false

接口黄金流程失败时，必须输出足够定位的信息：

text 复制代码

测试用例名称
runId
业务编号
请求 URL
请求 method
请求 header
请求 body
响应 status
响应 body
traceId / requestId

后续可以增强：

text 复制代码

每个请求生成 requestId
请求头带 x-request-id
服务端日志打印 requestId
失败时按 requestId 查询日志平台
报告里附请求响应和关键业务编号

这样测试失败才会变成可处理的工程事件，而不是噪音。

14. 常见误区

14.1 误区一：先做测试平台

第一阶段不需要测试平台。

你需要的是：

text 复制代码

一条能稳定跑的命令
几条能代表业务闭环的 P0 用例
失败后能定位的日志

平台化可以后置。

14.2 误区二：用 UI 自动化替代接口自动化

UI 自动化能证明页面可用，但它不适合承载所有业务断言。

库存、应收、流水、租户隔离这类断言，通过接口和数据库查询更直接。

14.3 误区三：AI 生成了测试，所以质量就有保障

AI 生成的是代码，不是业务正确性。

真正有保障的是：

text 复制代码

业务不变量
回归矩阵
高风险路径核对
可重复执行的自动化验证

14.4 误区四：每条用例都强行清数据

ERP 的数据关系很深。

第一阶段强行清理，可能会制造更多测试脆弱点。

专用测试租户 + runId + 定期清理，通常更务实。

14.5 误区五：一开始就追求全覆盖

全覆盖是结果，不是起点。

第一阶段最重要的是稳定：

text 复制代码

少量 P0
真实链路
重复执行
失败可定位
CI 可接入

15. 一张图总结

这张路线图的核心不是"工具越来越多"，而是"证据越来越硬"：

text 复制代码

单元测试证明局部规则
接口黄金流程证明业务闭环
CI 门禁证明每次交付都跑过
回归矩阵和不变量证明历史经验被沉淀

16. 最后总结

AI Coding 改变了软件交付速度，但没有改变软件质量的底层逻辑。

越是 AI 能快速生成代码，越需要有人定义：

text 复制代码

什么叫业务正确
什么叫不能发布
什么叫已验证
什么叫历史兼容

对 SaaS ERP 来说，最务实的自动化测试路线不是一开始搭一个大平台，而是：

text 复制代码

从一个测试租户开始
从一条真实登录开始
从一个代表性请求开始
从商品线开始
从 5-10 条 P0 接口黄金流程开始
逐步串到库存、销售、采购、财会、餐饮和报表

能稳定跑起来的黄金流程，才是 AI 时代真正有价值的回归安全网。

一句话：

text 复制代码

AI 负责更快地产生实现，人负责定义业务正确性，自动化测试负责反复证明它没有被改坏。

参考资料

RestAssured 官方文档：rest-assured.io/docs
TestNG 官方文档：testng.org/
Karate 官方文档：docs.karatelabs.io/
Allure Report 官方文档：allurereport.org/docs/
Playwright 官方文档：playwright.dev/
Cypress 官方文档：docs.cypress.io/
Midscene.js 官方文档：midscenejs.com/
云效 Flow 官方文档：help.aliyun.com/zh/yunxiao/...