请教一个“基于内部组件库页面代码 + 运行时表格数据 + AI 生成 E2E 测试”怎么落地的问题
- 内容介绍
- 文章标签
- 相关推荐
我现在在做一套中后台页面的测试代码生成 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系列知识，不知道如何落地，如果大家有类似的开源项目，好的建议都可以推给我！
网友解答：--【壹】--：
我现在在做一套中后台页面的测试代码生成 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系列知识，不知道如何落地，如果大家有类似的开源项目，好的建议都可以推给我！
我现在在做一套中后台页面的测试代码生成 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系列知识，不知道如何落地，如果大家有类似的开源项目，好的建议都可以推给我！
网友解答：--【壹】--：
我现在在做一套中后台页面的测试代码生成 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
- 哪些一定要依赖运行时数据