我现在在做一套中后台页面的测试代码生成 agent 。这个场景是前端的代码与测试代码都是二次封装的内部库（已经建了内部库的 skills ）
- 前端页面基于内部二次封装组件库开发
- 页面规律比较固定，很多开发本质上是在配置字段、组件、规则、联动
- 测试代码也不是直接写 Playwright ，而是基于 Playwright 又封装了一层内部测试库
- 所以最终想生成的，也不是原始 Playwright ，而是基于内部测试库的测试代码
也就是说，这不是一个“面对任意前端页面自由发挥”的问题，而是一个：
前端代码有固定规律、测试代码也有固定框架的场景里，怎么借助 AI 做测试生成。
典型前端字段表单配置代码（已脱敏）
{
component: 'CustomInput',
fieldName: 'fieldCode',
label: '字段 A',
rules: z
.string({ message: t('请输入字段 A') })
.min(1, t('请输入字段 A'))
.max(20, t('最多输入 20 个字符'))
.regex(/^[A-Za-z0-9\\-. *+\\/%$]+$/, t('格式不符合要求')),
rulesBlur: z.string().superRefine(async (value, ctx) => {
const checkResult = await verifyFieldUniqueness('fieldCode', value)
if (!checkResult?.passed && checkResult?.msg) {
return ctx.addIssue({
code: 'custom',
message: t(checkResult?.msg),
})
}
}),
}
这类页面里，很多逻辑不是散落在各处，而是通过字段配置表达：
- 用什么组件
- 字段名和标签是什么
- 主校验规则是什么
- 失焦时是否做异步校验
- 是否存在后端重复校验/业务校验
典型测试代码（已脱敏）
test('列表查询', async ({
page,
tableLocator,
searchLocator,
formActions,
selectActions,
datePickerActions,
}) => {
const search = searchLocator.createSearchArea(TABLE_ID)
const table = tableLocator.createTable(TABLE_ID)
await formActions.fillInput(search.getInput('keyword'), '示例关键字')
await datePickerActions.setDate(search.getField('period', 'custom-period'), '202601')
await selectActions.selectFromTableByIndex(search.getSelect('category'), 1)
await search.getQueryButton().click()
const row = await table.getRowData(0, ['displayName'])
expect(row.displayName).not.toBeUndefined()
})
也就是说，测试代码本身用的是内部封装的测试库，不是直接裸写 Playwright 。
我现在最关心的点
我最想解决的，不是“怎么生成一份测试代码”，而是：
测试数据不希望写死，而是尽量基于页面当前运行时的表格数据，再借助 AI 去推断。
也就是：
- 查询值不要硬编码
- 新增值不要硬编码
- 编辑值不要硬编码
而是尽量来自：
- 页面当前表格里的真实数据
- 页面代码里的字段 / 规则 / 联动 / 数据流
- 最后才是 AI 推断
因为在很多中后台页面里：
- 表格里已经有现成的业务数据
- 新增和编辑的数据其实应该参考这些真实数据来生成
- 如果测试数据写死，后面会比较脆，也不够通用
我现在卡的几个问题
1. 查询 / 新增 / 编辑的数据推断边界怎么设计更合理？
我更希望是：
- 先拿页面当前表格里的真实数据
- 再结合页面代码
- 最后才让 AI 推断
而不是让生成器或 LLM 一开始就直接猜测试值。
2. 复杂校验该怎么交给 AI ？
比如：
- A 字段必须大于 B 字段
- 如果 A 有值，B 必填
- 字段重复校验
- 多字段组合校验
这种场景下，是给 AI 更多源码片段更好，还是给：
- 结构化规则
- 局部源码证据
- 运行时表格数据
这种“证据包”更合理？
3. 这种场景里，AI 的边界怎么放更稳？
我现在倾向于：
- 规则代码负责提取事实
- 运行时负责提供真实数据
- AI 只负责高语义推断
- 最终生成的代码仍严格落在内部测试库能力范围内
但不确定这种拆法是不是更稳。
想请教大家的点
如果有做过类似：
- 内部组件库驱动页面
- AI 辅助测试生成
- 代码理解 agent
- 基于运行时数据生成测试数据
- 基于既有测试框架生成测试代码
很想听听大家的经验，尤其是这种：
前端代码和测试代码都有固定规律，而且测试数据尽量不写死，而是依赖页面当前运行时表格数据 + AI 推断
的场景下，怎么划分：
- 哪些必须规则化
- 哪些交给 AI
- 哪些一定要依赖运行时数据
由于才刚接触 agent 开发，熟悉一点 langchain 系列知识，不知道如何落地，如果大家有类似的开源项目，好的建议都可以推给我！
 |
1
Jgege 12 小时 31 分钟前
看到你提到的『證據包』方案，你的拆法（規則代碼負責事實，AI 負責語義推斷），我認為方向是對的，但在落地時我建議引入一個 Intermediate Representation (IR) 層：
Schema 驅動而非代碼驅動：既然你們是二次封裝的組件庫，那麼建議不要直接給 AI 原始碼，而是將前端配置轉成靜態的 JSON Schema 。AI 處理結構化數據的穩定性遠高於處理混亂的源碼。 數據劫持（ Data Injection ）：針對你擔心的數據寫死問題，我建議在 Playwright 層面封裝一個 context.inject(tableData) 的 Hook 。AI 生成的測試代碼只需調用這個 Hook 並指定字段名，具體的真實值由測試 Runtime 在執行時動態注入。 AI 的邊界在於『動作序列』而非『值』：讓 AI 負責決定『點擊哪裡』、『驗證哪個字段』。至於校驗邏輯（如 A > B ），應該在組件庫的 Metadata 裡定義好規則名，AI 只需要識別出該觸發哪個規則。 你目前卡的複雜校驗問題，本質是 Constraint Solving 。如果想更穩，我認為可以考慮用 LangChain 的 Structured Output 強制 AI 輸出固定格式的測試指令，而不是完整的測試腳本。 |
 |
2
licoded 8 小时 36 分钟前
做起来才能发现具体问题吧 在实践中去学习探索
看起来你这个场景属于人工经验已经积累得非常充分了，且没有太多需要 ai 的地方 或者说 工作流程设计划分已经比较清楚，需要 ai 去完成地方也比较清楚 所以，干就完了！ |
Select Language