【面试题】AI测试常考问题

1、为什么UI自动化不推荐大量使用sleepPlaywright的自动等待解决了什么问题大量使用sleep的本质问题time.sleep()是固定时长的盲等待属于“用时间换概率”的粗放方案核心缺陷有四个稳定性与效率不可兼得时间设短了环境/网络稍慢就出现偶现失败时间设长了元素早已加载完成仍继续空等整套脚本执行效率指数级下降。环境适应性极差本地开发机跑得快、CI服务器跑得慢同一套脚本在不同环境下表现完全不一致维护成本极高。无法解决“元素存在但不可操作”问题sleep只能等元素出现在DOM里但元素可能被遮挡、处于动画中、按钮未激活此时强行操作依然会报错。掩盖真实性能问题大量sleep会把页面加载慢、接口响应慢的问题隐藏起来无法暴露前端性能瓶颈。Playwright自动等待的核心价值Playwright 在执行所有元素交互动作点击、输入、悬停、拖拽等之前会自动执行一整套可操作性检查全部满足后才执行动作超时则抛出明确错误。检查项包括元素已挂载DOM、元素可见、元素稳定无动画、元素未被遮挡、元素处于启用状态、输入框可编辑。机制本质条件触发式等待条件满足立刻执行不浪费1毫秒超时才报错兼顾速度与稳定性。它解决了UI自动化的头号痛点偶现失败。不用再手动写等待逻辑脚本维护量减少60%以上执行速度比sleep方案快2~5倍同时稳定性大幅提升。2、XPath、CSS Selector和语义定位各有什么优缺点Agent时代XPath还有必要学吗三者核心优缺点对比定位方式核心优势核心劣势适用场景CSS Selector语法简洁、性能最优、浏览器原生支持、前端开发对齐度高无法反向查找父/祖先元素、无法按文本内容定位、复杂嵌套场景表达力弱绝大多数常规元素定位、有稳定id/class/属性的元素XPath表达能力最强支持轴定位父、兄弟、祖先、支持文本匹配、支持复杂条件组合语法复杂学习成本高、性能略低于CSS、相对路径依赖DOM层级前端改结构易失效CSS搞不定的复杂场景按文本定位、反向查找、多层条件组合语义定位 getByRole/getByText/getByLabel最稳定与DOM结构、样式完全解耦符合用户真实视角可维护性最高极端复杂场景定位精度不足部分无语义的自定义组件无法直接使用现代Web应用首选90%以上的常规场景都可以覆盖Agent时代XPath还有必要学吗有必要但优先级大幅降低从“核心技能”变为“兜底技能”。Agent日常生成脚本时会优先使用语义定位更符合人类操作逻辑生成的脚本也更稳定这是主流趋势。但Agent经常会生成错误、脆弱、低效的定位器遇到深层嵌套组件、无语义的老旧系统、特殊业务场景时依然需要XPath兜底。你必须能看懂、能调试、能修正Agent生成的XPath而不是完全依赖AI。结论不用死记硬背复杂轴定位语法但必须掌握核心用法能读懂、能改、能处理疑难场景即可。3、MCP和普通API调用到底有什么区别为什么Agent需要MCPMCPModel Context Protocol模型上下文协议是专门为大模型Agent设计的工具交互协议和普通API调用的本质区别是面向的调用主体不同。核心区别对比维度普通API调用MCP调用主体人类编写的程序代码大语言模型Agent契约方式强契约调用方必须提前知道接口地址、参数格式、返回结构手动写代码拼接解析标准化自描述工具自动向Agent暴露自己的能力、参数schema、使用方式Agent可自动理解发现机制需提前阅读文档人工接入支持自动发现Agent可以动态感知有哪些可用工具交互模式单次请求-响应无状态支持多轮交互、流式返回、上下文传递、状态保持接入成本每个API都要单独写胶水代码、写Prompt描述、做参数解析符合协议的工具可即插即用无需逐个适配安全管控每个接口单独做权限、认证、审计协议层统一认证、权限、审计、沙箱隔离为什么Agent需要MCP解决工具接入的碎片化问题没有MCP之前每接入一个工具就要写一遍工具描述、参数定义、结果解析Agent框架和工具之间强耦合生态无法复用。提升工具调用准确率标准化的schema和描述规范让模型更容易理解工具的用途和入参要求大幅减少参数传错、工具误用的幻觉。支持复杂工具交互普通API只能单次调用MCP支持工具和Agent多轮对话比如工具需要补充信息、确认操作适配更复杂的业务场景。统一安全与治理企业级Agent需要统一管控工具权限、调用审计、数据隔离MCP在协议层提供了标准能力不用每个工具重复建设。4、如果让DeepSeek Harness调用Playwright完成Web自动化测试你会怎么设计Tool核心设计原则语义化封装、操作可观测、失败可兜底、风险可控绝对不能把Playwright原生API直接丢给Agent否则会出现大量定位错误、操作失控、结果不可信的问题。整体分为四层工具体系第一层原子操作工具基础能力收敛底层API只开放语义化操作不开放底层定位器Agent只需要描述“做什么”不需要写“怎么定位”。页面导航打开页面、刷新、前进后退、切换标签页/iframe元素交互点击按钮、输入文本、选择下拉框、勾选复选框、上传文件信息获取获取元素文本、获取页面标题/URL、截图、获取页面源码所有操作内置Playwright自动等待失败自动重试1次返回结构化结果{success: bool, message: str, data: dict, error: str}第二层断言校验工具独立裁判避免自证自明把校验能力单独做成工具强制Agent操作后必须调用校验不能自己说成功。元素校验元素是否存在、是否可见、是否可点击文本校验页面是否包含指定文本、元素文本是否等于预期业务校验URL是否符合预期、表单是否提交成功、列表是否新增数据第三层流程封装工具高频场景开箱即用把测试常用的复合操作封装成高级工具减少Agent决策步数降低出错概率。登录工具传入账号密码自动完成登录登录态校验表单提交工具传入字段键值对自动填充提交校验结果数据清理工具测试完成后自动清理测试数据避免脏数据第四层护栏与调试工具风险管控域名白名单校验禁止访问非测试域名防止Agent失控跳转操作次数限制单任务设置最大操作步数防止无限循环全链路日志每一步操作自动记录操作内容、页面状态、截图全程可追溯禁止执行任意JS、禁止修改浏览器配置等高风险操作按需单独授权5、Agent告诉你“测试执行成功”为什么不能直接相信你会怎么设计Evaluator为什么不能直接相信本质是执行者与裁判身份重合Agent既是操作的执行者又是结果的评判者天然存在“自证自明”的失真风险具体有四类常见问题操作幻觉Agent声称完成了点击、输入但实际定位错了元素、操作没生效自己脑补了成功结果。断言缺失只执行了操作步骤完全没做校验或者只做了最表层的校验比如只看页面不报错就判定成功。假阳性误判业务实际已经失败比如接口返回业务错误码、数据没写入数据库但Agent只看页面提示就认为成功。步骤遗漏漏掉了部分测试点、边界场景只跑完了主流程就宣称全部测试通过。Evaluator设计思路执行权与评判权分离多维度交叉验证Evaluator是独立于执行Agent的第三方裁判从四个层级做校验最终输出结构化结论。操作痕迹层校验客观底层一票否决核对操作日志每一步操作是否有真实的执行记录、DOM事件、页面跳转痕迹。页面状态校验自动抓取执行后的页面截图、URL、关键元素文本和预期结果逐项比对不采信Agent的口头结论。业务数据交叉验证涉及数据增删改的场景直接调用后端接口/查询数据库确认数据真实生效不只看页面显示。用例覆盖层校验对照原始测试用例核对所有测试步骤、检查点是否全部执行有没有遗漏、跳过。校验断言的充分性是否只校验了状态码/页面可见没有校验核心业务字段。语义一致性校验LLM-as-Judge使用独立的、更高能力的模型作为裁判输入测试用例要求、完整执行日志、页面状态、Agent结论。由独立模型判断测试是否完整执行、结果是否符合预期、有没有遗漏风险点。关键原则裁判模型和执行模型必须隔离避免自循环。异常负向校验检查执行过程中的控制台报错、接口4xx/5xx、页面异常弹窗确认Agent没有忽略异常。检查是否产生了非预期的脏数据、副作用。最终输出测试是否通过、置信度分数、通过/未通过的检查项、证据附件截图、日志、数据低于置信度阈值的自动触发人工复核。6、Selenium和Playwright有什么区别两者最本质的区别是底层通信架构不同由此延伸出稳定性、能力、效率的全面差异。对比维度SeleniumPlaywright底层协议基于WebDriver协议通过浏览器驱动ChromeDriver中转通信中间层多基于CDPChrome DevTools Protocol直接和浏览器内核通信浏览器厂商级支持等待机制无原生自动等待需手动写隐式/显式等待大量依赖sleep偶现失败多内置全场景自动等待操作前自动校验可操作性偶现失败率极低浏览器支持支持所有主流浏览器及大量旧版本兼容性最广支持Chromium/Firefox/WebKit自带浏览器二进制无需装驱动旧版浏览器支持弱原生能力仅基础元素操作网络拦截、文件上传、多标签页等能力需第三方插件原生支持网络Mock/拦截、文件上传下载、多iframe/多标签页、移动端模拟、权限设置、暗色模式执行速度慢驱动通信开销大快比Selenium快2~3倍定位能力仅支持CSS、XPath无语义定位原生支持语义定位getByRole等定位更稳定调试能力弱需自行实现截图、录屏排查问题困难自带Inspector调试器、Trace Viewer全链路回放可回看DOM、网络、控制台调试效率极高适用场景兼容老旧浏览器、遗留系统迁移、已有深厚Selenium技术栈的团队现代Web应用、高稳定性要求的自动化测试、UI接口一体化测试7、显式等待和隐式等待有什么区别两者都是Selenium体系中的等待方案Playwright中已被自动等待替代核心区别是作用范围和等待条件不同。隐式等待Implicit Wait定义设置一个全局超时时间所有查找元素的操作如果没立刻找到元素就轮询等待直到元素出现或超时。特点全局生效设置一次影响所有findElement只能等待“元素存在于DOM中”无法判断元素是否可见、可点击。典型问题判断元素不存在时会等满整个超时时间脚本极慢和显式等待混用会导致等待时间叠加行为不可控。显式等待Explicit Wait定义针对特定元素、特定条件设置等待直到条件满足或超时比如“等待按钮可点击”“等待页面包含指定文本”。特点局部生效只针对当前操作支持丰富的等待条件可见、可点击、文本变化、URL变化、属性变化等条件满足立刻执行不浪费时间。优势精准、灵活、高效是手动编写等待逻辑的推荐方案。核心区别总结维度隐式等待显式等待作用范围全局局部针对指定条件等待条件仅元素存在于DOM可见、可点击、文本、属性、URL等任意条件执行效率低元素不存在时必然等满超时高条件满足立即继续稳定性差元素存在但不可操作仍会报错好可等到元素满足操作条件灵活性差只能设置超时时间强可自定义任意条件补充Playwright的自动等待本质是内置的、更完善的显式等待它把元素可操作性的检查做成了默认行为不用开发者手动编写。8、让Agent自己操作浏览器怎么保证它每次都操作正确核心思路放开执行权收住规则权和裁判权不靠“Prompt写得好”而是靠一套“约束-校验-兜底-评审”的闭环体系保障正确性。第一层前置约束从源头降低出错概率工具能力收敛不开放原生Playwright底层API只开放封装好的语义化工具。Agent只需要描述“点击提交按钮”底层自动完成定位等待操作避免Agent写出脆弱、错误的定位器。操作规范强制通过系统提示词明确操作范式操作前确认元素、操作后必须校验结果、异常必须上报设置单任务最大操作步数防止无限循环。边界护栏域名白名单、操作权限分级高风险操作如删除数据需二次确认、禁止执行任意JavaScript。第二层过程校验每一步闭环不累积错误操作前置校验Agent发起操作后底层工具先独立校验元素是否存在、是否可操作不通过直接返回失败原因不执行无效操作。操作后置校验每一步操作执行完成自动做结果校验比如点击后检查页面跳转、提示文本把真实结果返回给Agent不由Agent自己判断成功。异常实时捕获自动捕获控制台报错、接口异常、页面弹窗强制Agent处理不能静默忽略。第三层容错兜底出错自动修正失败自动重试元素定位失败、操作超时底层自动重试1次重新定位/刷新页面同时给Agent更详细的错误信息引导修正。定位降级策略语义描述定位不到自动降级尝试模糊文本匹配、角色匹配、CSS兜底多种策略尝试后再返回失败。状态回滚能力关键操作失败后支持一键回滚到上一稳定状态返回上一页、重置表单避免脏状态影响后续步骤。第四层独立评审最终结果不由Agent说了算任务结束后由独立Evaluator从操作日志、页面状态、业务数据三个维度交叉验证输出最终结论和置信度高风险场景、低置信度结果触发人工复核。第五层持续迭代优化所有操作失败、决策错误都沉淀到Bad Case库定期优化系统提示词、工具封装、校验规则让Agent的准确率持续迭代提升。