测试与验证

第 5 课 · 共 6 课 约 8 分钟

桩数据与单元测试、只校验、预演、评测集；AIDC 用校验、预演和自己维护的评测集。

本课目标

读完这一课，你将能够

  • 说出测试逻辑的三层办法：单元测试、试跑、评测集
  • 用只校验和预演在不写任何数据的前提下测试改数据的逻辑
  • 为一个用模型判断的工作流写出一份评测集，并说明为什么每个用例要跑多遍

先试，再信：三层测试

逻辑上线之前要能回答两个问题：写对了吗？改了之后变差了吗？标准模型用三层办法回答。

UNIT

单元测试

用桩对象（内存里造的假对象）当输入。测改数据的函数，就断言它返回了哪些改动：新建了什么，改了哪个对象的哪些属性，有没有多余的改动。也可以给对象搜索和聚合预设答案，例如「这次聚合返回 55」。

TRIAL

试跑

在开发环境里直接跑一个函数，看结果。改数据的函数只返回改动清单，不会真的改对象。

EVAL

评测集

给「每次结果不一定相同」的逻辑，尤其是模型。一批测试用例（输入加期望结果），被测的逻辑，和评测函数：把实际输出与期望比，得到真假或分数。

评测有几条规矩：

  • 用例可以手写，也可以由一个对象集生成，每个对象一条用例；
  • 评测函数返回真假或数字。每个指标要设目标：布尔指标要真还是要假，数值指标越大越好还是越小越好，还可以设阈值，据此判定通过与否；
  • 改数据的逻辑在模拟环境里跑，真实数据不受影响；
  • 语言模型的输出每次可能不同，每个用例至少跑三次，看整体通过率，不看单次结果。
3 次模型逻辑每个用例建议至少跑的次数
10 个评测默认同时跑的用例数，遇到限流可以调小

在 AIDC 里：校验、预演、你自己的评测集

AIDC 已能发布和执行 Function。测试应覆盖真实查询函数的输出、编辑函数的改动，以及 Action 的规则和条件。新文档没有说明专用函数单元测试框架、桩对象、模拟环境或评测运行器。可以自行维护用例与断言，再用下面四种办法验证：

  1. 只校验

    $validateOnly：每个参数、每条提交条件逐项给出结果（VALID 或 INVALID），什么都不写。命令行是 --validate-only，不通过退出码为 2。

  2. 预演

    工作流 mode: "preview"（--preview）：读、算、AI 分析照跑，Action 只返回将要写入的计划。x-aidc-dry-run: true 只校验输入；定义和部署也有 --dry-run。

  3. 桩数据

    预演读的是真数据，只是不写。要用捏造的数据练手，就用示例本体（Ontology），数据全是虚构的；要试定义的改动，放到分支上，读取时带 --branch。

  4. 评测集

    你自己维护一个文件：每条是输入加期望结果。每次改提示词、换模型、改表达式，就把整套重跑，每条跑三遍。

下面是「有延期风险的订单」的评测集，文件格式是你自己约定的，AIDC 不会读它：

{
  "workflow": "order-risk",
  "cases": [
    { "name": "late-and-short",  "input": { "order_no": "SO-2001" }, "expect": { "at_risk": true } },
    { "name": "on-time",         "input": { "order_no": "SO-2002" }, "expect": { "at_risk": false } },
    { "name": "no-work-order",   "input": { "order_no": "SO-2003" }, "expect": { "at_risk": true, "needs_review": true } }
  ]
}
for i in 1 2 3; do
  aidc semantic automate run order-risk --param order_no=SO-2001 --preview --json > runs/SO-2001-$i.json
done

正式运行一次之后，用 aidc semantic edits-history workOrder --pk WO-1001 核对到底改了什么。这套做法和 AIDC 训练数字员工的「真题」是一个思路：至少十道真实的题，通过率不到门槛就不上线，上线后犯的错回流进题库。

测什么，怎么判

判断有两类。确定性的部分，如表达式算出的余量、提交条件是否拒绝，逐条断言精确的值。模型的部分，把要比对的结论声明成 boolean、number 或枚举字段，逐条精确比对；自由文本的原因不能精确比对，抽查，交给人看。

随口一问

跑了一次，结果看上去对，上线。

好的交代

12 条用例，每条跑 3 遍，at_risk 字段与期望逐条比对，通过率写进版本说明；改提示词后整套重跑，与上一版对比。

要点

  • 测试逻辑有三层：单元测试（桩对象与断言改动）、试跑、评测集。
  • 只校验与预演都不写数据：前者逐项检查参数和提交条件，后者让读、算、AI 分析照跑，写入只返回计划。
  • 评测集 = 输入加期望结果；模型输出会变，每个用例至少跑三遍，看通过率。
  • 把要比对的结论声明成 boolean、number 等类型化字段，才能逐条自动判定。

练一练

为「有延期风险的订单」写一份评测集

用示例工厂的订单、工单和产线，先想清楚期望，再去跑。

输入订单号，期望 at_risk。至少要有：没有工单的订单；看上去晚、其实够的订单；工单已全部完成的订单。

小测

选一个答案，马上看解析。

Q1想在不写任何数据的前提下，看一个工作流会把哪些改动写进 Semantic，用什么？

Q2模型步骤每次的输出可能不同，评测时应该？

Q3下面哪个输出最适合做逐条的自动比对？

延伸阅读