创维科技测试开发校招一面：AI 生成用例怎么评、平台本身怎么测

《面试题目》

1. 请做一下自我介绍
2. 如何判断一个测试场景是否适合自动化？
3. 如何验证 AI 自动生成的测试用例质量？
4. AI 如何判断哪些测试用例可以自动执行？
5. 如何验证自动化平台自身的可靠性？
6. Vue 3 中响应式数据发生变化，但页面没有更新，如何排查？
7. 如何设计生成式 AI 测试用例的评测指标？
8. pytest 中 fixture 的作用域如何影响测试结果？

《参考解析》

「AI 生成的用例有没有价值」要落到能不能发现问题。 判断标准不能是数量或措辞完整度，而应看四件事：是否有明确的前置条件、可控输入、可验证的预期结果，以及失败后能否定位。再看覆盖——是否覆盖了有效的业务状态、关键边界和异常路径；对 Agent 这类被测对象，还要覆盖错误工具选择、参数缺失、上下文污染、工具超时和多轮状态变化。最关键的判据是增量价值：如果把生成用例与历史缺陷、需求约束和风险等级关联后，发现它既没覆盖新状态、也没发现新问题，只是换了几种说法，那数量再多也没有意义。评测指标上可以拆成完整性、有效性、覆盖率、可执行性和缺陷发现能力几个维度，但要注意两点反直觉的地方：不能只用字符串相似度判断好坏（文字不同但覆盖同一风险不等于重复，表达相似但都漏掉关键异常也不合格），以及数量增长而缺陷发现能力没提升，说明生成策略只是在制造文本。

「哪些用例可以自动执行」不能交给模型自由心证。 正确做法是给 AI 提供明确的可执行性规则——是否存在稳定定位信息、数据能否自动准备、预期结果能否通过接口或日志验证、是否需要人工视觉或业务判断——让模型先做分类，再由规则引擎做最终判定。面试官设的坑就是「让模型只凭自然语言判断看起来能否自动化」，那会把需要人工确认的场景错误地塞进自动回归。落地时常见输出是分级的：把用例标成 fully / partial / manual，并列出可自动化的步骤与必须人工的步骤，这样部分可自动化的场景也能被利用起来，而不是一刀切丢弃。

自动化平台自身也要被测，而且重点是「不能把失败吞成成功」。 验证范围应覆盖任务创建、用例分发、执行调度、结果收集、失败重试、报告生成整条链路，重点场景包括任务重复提交、执行节点中断、测试环境不可用、部分用例超时、结果上报失败和任务取消。作者原帖强调的一点很关键：平台不能因为一个执行节点异常就把整个任务错误标记为成功——这类「假绿」是自动化体系里最危险的故障，因为它会让回归失去意义。另外要保证结果的可追溯性：代码版本、用例版本、环境信息、执行机器、依赖服务版本和失败日志，缺了这些就无法判断是产品缺陷还是环境抖动。

Vue 3 响应式失效的排查顺序。 先确认数据源是 ref 还是 reactive，以及修改方式是否符合对应 API 的规则——ref 要改 .value，reactive 对象不能整个替换，且解构会丢掉响应式引用（要用 toRefs）。再看计算属性的依赖有没有被正确收集（依赖是异步产生的、或在条件分支里没执行到，都会导致不更新）。如果数据来自异步请求，要确认回调真的更新了响应式对象、组件是否已经卸载（卸载后更新不会渲染）。列表渲染还要检查 key 是否稳定——用数组下标当 key 会让 Vue 复用错误的组件实例，表现为「数据变了但显示的还是旧的」。排查手段上，Vue Devtools 看数据是否真的变了、配合生命周期日志判断问题发生在数据更新、依赖收集还是渲染阶段，比盲改代码有效。

pytest fixture 的作用域是一道很实用的题。 作用域决定初始化和销毁的频率：function（默认）隔离性最好但成本最高，每条用例都重建；class 每类一次；module 每模块一次；session 全局一次，适合数据库连接、浏览器实例这类昂贵资源。它对测试结果的影响主要体现在三方面：共享状态可能让用例互相污染（前一条改了数据，后一条因此通过或失败），产生顺序依赖导致「单独跑绿、一起跑红」；以及并行执行（xdist）时 session 级 fixture 的共享语义会变化。工程上的经验是：默认用 function 保证隔离，只对确实昂贵且无状态污染的资源升到 module/session，并且对共享 fixture 显式做数据清理。

「怎么判断一个场景适合自动化」的答题框架。 可以从收益和成本两侧看：收益侧看执行频率（回归频繁的优先）、稳定性（需求变动少的优先）、以及人工执行的痛苦程度（重复、耗时、易错的优先）；成本侧看定位手段是否稳定（UI 定位是否可靠）、数据能否自动准备、预期结果能否自动断言、以及维护成本。典型不适合的是：一次性的探索性测试、依赖主观判断的体验类场景、以及需求还在快速变动的模块——自动化不是越多越好，脆弱的自动化用例会变成噪声，掩盖真正的问题。