让AI成为测试伙伴：公式类校验工具的落地实践

一、背景：测试正在被”算数”拖垮

在门店公式类需求中，测试复杂度并不在流程，而在计算逻辑：

1. 多字段驱动，全是数据
2. 一个公式能串起6~7个变量
3. 每个变量存在不同的取值规则
4. 对账单、统计表、结算单层层递进，多数据累加

综上，计算一个字段就需要耗费较长的时间，一整个需求中产生大量的数据计算，一时间陷入：

造数据 → 算数 → 再造数据 → 再算数

二、传统测试方式：为什么越做越累？

从实践来看，公式类测试通常经历四个阶段：

• 青铜选手：手动计算器党
  手动逐个获取到计算公式用到的每个字段，打开计算器开始算缺点：需要执行大量重复的计算，耗时且容易出错
• 白银选手：简易脚本党
  跳过按计算器的阶段，手动输入各个字段，写个数据构造帮我执行计算逻辑缺点：一个字段中的计算公式中多达6 7个字段，还是需要手动获取数据手输到数据构造中
• 黄金选手：自动化脚本党
  写个方法前置获取公式计算所需的所有字段，代码处理公式计算逻辑缺点：计算公式易更新，容易沦为一次性工具
• 王者选手：可配置工具党
  在上述工具的基础上，将计算公式抽离出来，公式变更只需更改配置中的公式即可，成为可复用性的工具，一次搭建，终身受益

三、关键突破：校验工具产出

工具核心能力

在经历了前面各阶段的不断摸索过程，决定产出该公式校验工具，工具核心能力如下：

• 输入层前端输入回收单号，是否抖音订单，线上or线下订单，品类为手机数码or聚合；
• 数据层根据回收单号查询回收单信息、成交价、加价金额、估价器报价等基础信息，再根据回收单上的门店id查询门店对应的加盟规则获取对应的分润比例；
• 规则层公式定义，公式各变量取值规则；
• 执行层自动计算，并与rd数据对比，返回校验结果。

本前后端整体设计如下：

页面呈现如下：

四、落地过程：如何用 Cursor 快速做出工具？

面临的挑战

1.前端小白，没接触过前端技术，开发前端页面不好上手

2.刚开始接触cursor，不熟悉如何给出指令实现工具

具体如何给cursor指令？

核心原则：精准是第一生产力

Cursor 本质是”指令执行机器”，输入越精准，结果越可控。

必须明确三个核心：

• 要做什么明确功能需求（比如“计算门店结算金额”）
• 用什么做指定编程语言和技术栈，需要调用的接口（比如“用Java实现调用XXX接口，入参为A，B，C”）
• 达到什么效果给出约束条件和预期结果（比如“支持多场景变量取值”）

三类高效指令

1. 基础代码生成（从0到1）

• 告诉他我想定义一个什么样的接口A，入参是什么，返回值类型是什么，并将其实现；
• 具体的实现中可以告知他在接口A中需要调哪些接口，获取接口返回值中的哪个字段；
• 将所有字段获取到以后，告知文字描述计算公式，将公式中的字段与当前代码定义的实际字段名称对应，即可实现公式校验

如：

2. 代码优化

告诉他我想如何修改当前代码，具体修改为什么样的

3. 问题排查

配合cursor描述问题现象，如在排查问题初期会加一些日志，根据他加的日志，截图给他或者直接告知他，让他继续分析

五、价值收益

效率提升

1.原来人工测试对账单、统计表、结算单的用例至少要16小时，工具执行仅需10小时
2.原来开发过程中调试一个bug要花半天，现在只要10分钟

质量提升

减少了大量重复的计算，把更多精力放在思考业务逻辑和优化方案上，线上bug数量减少

成本节省

前置获取数据接口可以满足大部分公式计算，在不进行大变动的场景下，基本可以覆盖所有公式所需变量，减少了后续测试人员的重复工作量

六、方法论沉淀：公式类测试通用解法

以上可供大家根据实际场景参考使用。

七、未来展望

未来将进一步升级为：

AI驱动的公式校验能力

实现：

• 输入业务规则 → 自动生成校验代码
• 自动获取变量数据
• 自动执行校验

最终达到：

从”人工算数” → “自动校验” → “智能测试”

总结

公式类测试的本质不是”算得快”，而是：

让系统替你算，让人专注判断。