CRM 发版后，最值得优先回归的，往往不是某个页面能不能打开，而是一名销售能不能把客户工作继续做下去。

新客户能不能建档？联系人和客户等级能不能修改？拜访或电话跟进提交后，是否真的进入了客户时间线？

这些操作手工测试时不难，却需要每次发版反复填表、搜索、进入详情、修改和核对。一旦漏测，影响的也不只是一个按钮，而可能是从客户建档到持续跟进的整条业务链路。

所以，CRM 的 UI 自动化不应按菜单一页页录制，而应该围绕一个更明确的目标展开：每次发版后，客户仍然能够被创建、找到、更新和持续跟进。

先把回归范围收窄到一条客户主链路

CRM 里可以自动化的功能很多：客户公海、线索转换、客户分配、商机、合同、权限、报表……如果第一批用例就想把所有模块都覆盖，很容易变成“录了很多，发版前却不敢跑”。

更适合起步的方式，是先守住客户管理中最常用的四个结果：

1. 新客户可以成功创建。
2. 创建后可以通过列表或搜索找回这个客户。
3. 修改客户资料后，新值可以正确保存和回显。
4. 跟进记录可以提交，并且关联到正确的客户。

这里的重点是“结果”，不是把每个按钮都点一遍。UI 自动化负责确认一个真实用户能不能在页面上完成关键任务；更细的字段规则、批量数据校验和接口异常分支，可以继续由单元测试和接口测试承担。

别录成一条超长用例，拆成三条可维护路径

最直观的做法，是把“创建 → 编辑 → 跟进”全部录进一条用例。这样看起来很完整，但创建只要失败，后面的编辑和跟进就全部失去了验证价值。页面只改了一段，也可能要维护整条用例。

正式回归更适合拆成三条短路径。

用例一：创建客户并确认真正保存

一条基本的创建用例可以这样设计：

进入客户列表
→ 点击“新建客户”
→ 填写客户名称和必填信息
→ 点击保存
→ 断言页面出现“保存成功”
→ 返回客户列表
→ 搜索本次创建的客户
→ 断言列表中出现该客户

很多用例停在“页面弹出保存成功”就结束了。但 toast 出现过，不代表列表里已经有这条数据，更不代表下次打开时还能找到它。

所以创建类用例至少要做两层确认：第一层是页面告诉你保存成功，第二层是在列表或详情中再次找到本次创建的客户。

用例二：编辑客户并验证刷新后的回显

编辑用例可以选择一两个结果清晰、发版时风险较高的字段，例如主联系人、客户等级或备注。没有必要为了“覆盖率”把几十个字段全部改一遍。

准备一条可编辑客户
→ 搜索并进入客户详情
→ 修改客户等级或备注
→ 点击保存
→ 断言更新成功
→ 刷新页面或重新进入详情
→ 断言目标字段仍然显示修改后的值

最后一步非常重要。如果只检查“更新成功”，测到的可能只是按钮响应和提示文案；重新进入详情后核对字段，才能更有力地证明数据已被保存。

编辑用例还要避免一个隐性问题：每次执行都把字段改成同一个值。如果客户备注本来就是“自动化回归”，再保存一次即使通过，也未必证明编辑真的生效。可以将备注设置为带时间戳的内容，再校验本次生成的新值。

用例三：新增跟进记录并确认客户归属

跟进记录是 CRM 里最适合做业务结果断言的场景之一。一条跟进不仅要能提交，还要出现在正确客户的动态、时间线或跟进列表中。

进入目标客户详情
→ 点击“新增跟进”
→ 选择跟进方式
→ 填写本次跟进内容
→ 设置下次跟进时间
→ 提交
→ 断言页面提示新增成功
→ 断言客户时间线中出现本次跟进内容

这条用例不建议只断言“提交成功”。如果记录被写到错误客户、列表没有刷新，或跟进内容在保存过程中丢失，一条只看成功提示的用例都可能放过这些问题。

能不能反复跑，先看测试数据怎么设计

CRM 回归用例最常见的失败原因，不一定是页面改了，而是上一次执行留下的数据影响了下一次。

例如，第一次创建了名为“测试客户”的客户，第二次再跑就可能提示名称重复；某条跟进记录已经完成，下一轮却还想用它验证“待跟进”状态。这些失败很容易被误判为定位不稳或等待不够。

创建数据：用可识别的唯一名称

客户名称建议使用“固定前缀 + 时间戳”，例如：

自动化客户-1757408400000
CRM回归-1757408400000

这样既能避免重名，又方便测试或运维人员在环境中识别和清理自动化数据。如果 CRM 对客户名称长度有限制，可以换成更短的前缀，或使用符合业务格式的组合值。

不要让所有字段都随机。地区、客户等级、跟进方式等本来就是回归条件的字段，应该保持固定；需要变化的是客户名称、内部编码和本次跟进内容这类容易冲突或需要识别本次执行的数据。

后续还要查询：保存变量，不要再写回录制时的旧值

客户创建后，后续搜索、详情校验和跟进都必须围绕同一个客户。如果搜索框里仍然写着录制当天的固定客户名，下次执行时就会创建 A、查询 B。

更稳定的处理方式是：

输入唯一客户名称
→ 保存本次客户名称为变量 customer_name
→ 创建客户
→ 搜索 {{customer_name}}
→ 断言列表包含 {{customer_name}}

如果客户编号由 CRM 自动生成，可以在客户详情页将编号保存为 customer_id，后续查询和断言继续引用 {{customer_id}}。

这种变量链路适用于同一条用例内的前后数据依赖。已经拆开的编辑和跟进用例，应使用各自明确的前置数据，不要默认它们一定能读到另一条用例的运行时变量。

编辑和跟进：固定数据与现用现建怎么选

编辑和跟进用例需要一条已存在的客户，通常有两种准备方式。

长期保留一条专用测试客户。

好处是流程短、执行快。但要明确这条数据的初始状态，避免其被人工修改、删除或转移。编辑时也要使用每次不同的目标值，跟进时则要用本次唯一的跟进内容做断言。

在用例内先创建客户，再完成编辑或跟进。

好处是每次执行相互隔离，不容易被历史状态污染；代价是用例更长，创建步骤失败时会阻断后面的业务验证。

没有哪一种适合所有 CRM。对执行速度敏感、测试环境数据稳定的团队，可以使用专用客户；对数据隔离要求高、环境经常被多人共用的团队，现用现建更稳妥。

断言要对准业务结果，不要只证明按钮被点过

自动化用例能把操作跑完，不等于它真的完成了测试。CRM 主链路里，这几个节点最值得放置断言：

业务节点	不够充分的验证	更有价值的验证
创建客户	出现“保存成功”	列表中能搜索到本次客户
编辑客户	点击了保存按钮	刷新或重新进入后，字段仍是新值
新增跟进	出现“提交成功”	正确客户的时间线出现本次跟进内容

断言也不是越多越好。每一步后面都放一个断言，会让用例对页面文案和中间状态过度敏感。更好的原则是：保存、页面跳转、列表刷新和状态变更后，选择一两个能代表业务结果的稳定信号。

对本次才生成的客户名称、客户编号和跟进内容，可以结合数据变量断言，确保用例验证的是本次执行对应的客户，不是页面上恰好存在的另一条旧数据。

用回演 CueCast 录制时，可以按这个顺序处理

如果团队不想先搭建 Selenium 或 Playwright 脚本工程，可以在真实 CRM 页面上使用回演 CueCast 录入这三条路径。录制完成后，不要马上把它们放进回归计划，先做几次整理：

第一，删掉录制时的无关操作。

临时点开的菜单、输错后删除的文字、为了找入口多点的几下，都不应该保留在正式用例中。步骤越接近真实业务必需动作，后续维护越容易。

第二，处理每次都需要变化的输入。

将客户名称、跟进内容等容易重复的值改为随机字符串、时间戳、“前缀 + 时间戳”或组合值。这些动态值只改变回放时的输入内容，不改变目标输入框的定位。

第三，把前后要关联的值保存为变量。

当本次客户名称、系统生成的客户编号或跟进内容需要在后续搜索、下拉选择或断言中继续使用时，保存变量并在后续步骤中引用，避免将录制时的旧值写死。

第四，在关键结果后补断言。

保存成功、列表出现客户、编辑字段正确回显、跟进记录进入时间线，都应该有明确的结果判断。CueCast 支持在整页文本、指定元素、错误提示或 URL 上配置文本断言，可以根据 CRM 的实际界面选择稳定目标。

第五，连续回放两到三次。

只成功一次，可能只是当时数据和登录状态恰好正确。连续执行可以更早暴露客户重名、编辑值没有变化、跟进记录状态被污染等问题。

CueCast 保存的是可编辑、可维护的步骤，不是一次性的页面宏。当 CRM 局部改版时，可以先检查失败步骤，再修改输入、断言、CSS/XPath 兜底定位，或局部重新录制，不必每次都推倒整条用例。

发版前分两层跑：先冒烟，再完整回归

三条核心用例稳定后，可以把它们加入长期保留的 CRM 执行计划，但不要把所有场景都塞进同一组。

CRM 冒烟计划

适合在部署完成后立即执行，只保留最短的主链路：

完成登录准备
→ 创建一个客户
→ 搜索并打开该客户
→ 新增一条跟进记录

这组计划的价值是尽快判断当前版本是否值得继续测试，可以使用“失败即停止”策略。如果登录或创建客户已经失败，没有必要继续堆积一批缺少前置条件的后续红灯。

CRM 完整回归计划

在冒烟通过后，再执行更广的回归：

• 创建客户及必填项校验。
• 客户列表的关键字搜索和状态筛选。
• 联系人、客户等级、备注等字段编辑。
• 电话、拜访或其他关键跟进方式。
• 不同角色对客户的查看、编辑和转移权限。
• 重复客户、必填项缺失、无权限操作等负向场景。

完整回归更适合选择“全部执行完成”，让团队一次看到该版本在不同 CRM 路径上的结果，而不是遇到第一个非阻断问题就结束。

如果 CRM 登录态容易过期，可以为执行计划配置一条独立的登录用例作为登录准备。计划执行时先判断当前是否已登录，需要时先完成登录，再进入客户业务用例，避免把会话过期误判成页面功能失败。

用例失败时，先看现场，再决定要不要改定位

CRM 页面里的“元素未找到”不一定是选择器失效。例如，搜索结果中没有客户编辑按钮，可能是前面的客户没有创建成功；跟进入口没有出现，也可能是登录态过期、当前账号没有权限，或页面打开的根本不是预期客户。

更有效的排查顺序是：

1. 看失败步骤和当时的页面截图。
2. 确认是否被跳回登录页或无权限页。
3. 检查本次客户名称、客户编号和变量解析值。
4. 确认当前页面是否进入了正确客户和正确业务状态。
5. 页面状态正确但目标控件确实变化时，再维护该步骤或局部重新录制。

CueCast 的执行结果会保留失败步骤、截图、错误信息和执行明细，并尽量将问题区分为登录态、权限、页面状态、定位、断言、测试数据或业务错误等方向。对需要更易读失败结论的用例，也可以开启 AI 失败分析作为辅助。

这里 AI 的价值是结合已有执行证据帮助缩小排查范围，核心用例仍然来自真实页面上已经录入和沉淀的可回放步骤。

最后

CRM 客户流程的自动化回归，不需要一开始就覆盖每个字段、每个角色和所有边界条件。

先把“创建客户 → 找回客户 → 编辑资料 → 新增跟进”这条主链路跑稳，再通过唯一测试数据、数据变量和业务结果断言，让它能够一次次重复执行。当这组用例真的可以在发版前替团队走完关键流程、提供清晰结果时，它才开始变成可信任的回归资产。

后面再逐步扩展到客户分配、客户转移、公海、商机和权限等场景，会比第一天就追求用例数量更容易成功。

回演 CueCast 提供的正是这样一条落地路径：从真实 CRM 页面操作开始，把客户主链路沉淀成可回放、可编辑、结果可追溯的零代码自动化用例。