FAQ

本页汇总用户最常见的问题。若需要系统性了解产品能力，建议同时阅读：

• 产品概览
• 录制测试
• 步骤配置
• 回放测试
• 结果与排障
• 失败类型与排障

这份 FAQ 更偏实际使用和排障，不重复介绍基础产品能力。

录制与步骤调整

为什么录制的是一个下拉框，回放却点到了另一个相似下拉框？

这通常出现在两个组件结构很像、但业务语义不同的场景里。建议优先：

1. 查看失败截图，确认是否点到了错误组件
2. 在步骤配置里修正 CSS 或 XPath
3. 如果是复杂下拉、浮层、表格行内操作，优先局部重录该段

如果页面本身缺少可区分的标识，最好让研发补充更稳定的元素标识。

如何获取当前对象的 XPath 和 CSS？

最直接的方式是用 Chrome 开发者工具：

1. 在页面上右键目标元素
2. 点击“检查”
3. 在 Elements 面板中定位到当前节点
4. 右键该节点
5. 选择：
   • Copy > Copy selector 获取 CSS
   • Copy > Copy XPath 获取 XPath

实战建议：

• 先看复制出来的选择器是否过长、是否明显依赖很多层级
• 如果是非常长的绝对 XPath，通常不够稳，建议适当简化
• 如果能拿到稳定 id、data-testid、name 这类信息，优先用它们
• 改完后最好立刻单条回放验证，不要一次改很多步

CueCast 是如何提高用例稳定性的？

CueCast 的稳定性，不是只依赖一条 CSS 或 XPath。回放时会优先走更接近真实用户操作的浏览器控制链路，并按一套从强到弱的定位顺序逐层尝试。

主路径大致可以理解为：

1. 先用系统自动记录的智能定位信息

   • 这是录制时保存下来的“元素身份信息”
   • 会综合元素语义、组件结构、文本和上下文
   • 这是最高优先级，也是最主要的稳定性来源

2. 再尝试稳定标识

   • 例如稳定的 #id
   • 这类标识通常比普通 class 或层级选择器更稳

3. 再尝试 XPath 和普通 CSS

   • 这部分更多是兼容兜底
   • 如果页面结构变化不大，仍然可以帮助命中目标

4. 最后再做文本和组件级兜底

   • 例如下拉选项文本、组件根节点、浮层触发关系
   • 主要用于复杂控件和动态界面

所以从实战上看，CueCast 的稳定性主要来自两件事：

• 先走真实浏览器交互链路，而不是一上来直接改 DOM
• 不把元素定位压在单一选择器上，而是保留多层次的识别线索

这也是为什么有时候你改了一条 CSS，但回放行为不一定立刻完全改变。因为系统可能仍优先命中了录制时保存的更高优先级定位线索。

我改了 CSS 或 XPath，为什么回放还是像没按我改的走？

因为系统回放时，会优先使用录制时自动保存的智能定位信息；步骤里的 CSS 和 XPath 主要是兼容兜底。

这意味着：

• 改了 CSS / XPath，不代表一定会成为第一优先级
• 如果系统自动记录的定位线索仍然能命中，回放可能还是先按那套逻辑执行

遇到这种情况，建议先结合失败截图、页面状态和步骤目标一起判断，而不是只盯着单条选择器。

页面改版后需要整条重录吗？

不一定。建议先查看失败步骤，只修复失败步骤附近的定位、断言或等待时间。只有业务路径整体变化时才建议整条重录。

动态输入值适合什么时候用？

适合“每次新建数据都不能重名”的场景，例如：

• 新建项目
• 新建任务
• 新建规则
• 录入唯一编号

如果字段必须保持固定值，例如登录账号、稳定查询条件或固定断言前置数据，就不要改成动态值。

回放与失败调整

回放失败后，应该先看什么？

建议按这个顺序排查：

1. 失败步骤截图
2. 错误信息
3. 页面当时是否真的进入了预期状态
4. 目标元素、断言内容或测试数据是否已经变化

不要一上来就重录整条用例。大多数问题都集中在局部步骤。

如果你正在看一条具体的失败记录，先读 结果与排障。
如果你想按失败类型系统排查，再看 失败类型与排障。

用例失败后通常怎么调整？

先判断失败属于哪一类：

• 页面没到预期状态：先看登录态、前置数据、权限、业务弹窗或接口错误
• 页面对了，但元素找不到：优先调整 CSS、XPath，或局部重录
• 元素找到了，但值不对：修改输入值、断言值或动态值配置
• 只是页面慢一点：增加执行前等待

核心原则是：先判断失败是页面状态问题，还是步骤表达问题，再决定改哪里。

更完整的排查顺序和失败分类，可参考：

• 结果与排障
• 失败类型与排障

为什么页面已经跳转到别的路由了，步骤还在按原页面执行？

这通常说明当前页面起点和用例预期不一致，例如：

• 浏览器里已经有旧登录态
• 前一步操作后页面自动跳走
• 从中间开始录制或回放时，当前所在页面不是原本预期页面

这种情况下，不要先急着改选择器。优先确认：

1. 当前 URL 对不对
2. 页面是不是已经进入别的业务状态
3. 这条用例是否依赖特定前置数据或登录态

如果页面起点错了，后面的定位往往都会连锁失败。

登录流程里有验证码怎么办？

先区分验证码类型和测试环境诉求。

如果是测试环境中的简单图片验证码，可以尝试用智能步骤识别图片并填写。例如在智能步骤中描述：

识别登录表单中的验证码图片，并填写到验证码输入框。

如果页面有稳定选择器，也可以写得更明确：

识别图片 #captchaImg，并输入到 #captchaInput。

如果是短信验证码、邮箱验证码、滑块验证码、点选验证码或强对抗人机校验，不建议把 CueCast 当成绕过验证码的工具。更推荐和业务系统约定测试环境方案：

• 提供固定测试验证码。
• 对测试账号或测试环境做白名单。
• 使用 API 前置登录或登录准备能力。
• 将登录用例放入执行计划的「登录准备」，已登录时自动跳过，未登录时再执行。

验证码本质上是安全机制。CueCast 可以辅助测试环境里的简单识别场景，但不应绕过生产环境的真实安全校验。

为什么页面明明有报错弹窗，失败分析却说是用例问题？

失败分析会结合截图、错误信息和页面内容判断，但如果页面报错信息不明显，或者步骤本身也存在不稳定定位线索，就可能偏向用例侧判断。

遇到这种情况，建议仍然先以失败截图和页面实际状态为准。AI 分析适合加速排查，不应替代人工判断。

智能步骤

AI 步骤是否必须使用？

不是。稳定的核心路径建议优先使用录制步骤和明确断言。智能步骤适合补充处理复杂页面或难以稳定录制的少量操作。

智能步骤和普通步骤怎么选？

• 普通步骤：更确定，适合关键路径、发布准入、稳定断言
• 智能步骤：更灵活，适合复杂页面、动态界面、少量难录制操作

如果普通点击、输入、断言已经能稳定表达，就不建议为了“更智能”改成智能步骤。

智能步骤里的“自然语言指令”和“步骤描述”有什么区别？

系统会优先使用“自然语言指令”来执行智能步骤；如果这个字段为空，才会退回使用“步骤描述”。

因此：

• 想给团队看备注：写步骤描述
• 想明确控制智能步骤怎么执行：填写自然语言指令

为了避免备注误参与执行，建议智能步骤始终明确填写自然语言指令。

其他

CueCast 会自动收集我的浏览数据吗？

不会。扩展只在用户主动录制或回放时工作，处理的数据用于测试用例生成、执行和排障。

在哪里看完整的风险说明？

见 免责声明与重要提示；法律文本以官网 用户协议、隐私政策 为准。