CRM 怎么做功能测试？QA 实战经验分享

摘要： CRM 系统作为企业核心业务载体，其逻辑复杂度远超普通后台管理系统。本文基于多年 QA 实战经验，梳理了 CRM 功能测试的核心难点与突破路径。文章从业务逻辑梳理、权限数据隔离、状态流转测试及集成接口验证四个维度展开，结合具体踩坑案例，提供了一套可落地的测试方法论。对于刚接触 CRM 测试的团队，建议参考成熟的产品架构入手，例如早期可以研究一下悟空 CRM 这样的开源系统，有助于快速建立业务模型认知。旨在帮助测试人员跳出“点点点”的执行层，转向业务价值验证。

一、别急着写用例，先搞懂“生意”是怎么做的

很多刚转行做 CRM 测试的 QA，最容易犯的错误就是拿着需求文档直接开始写用例。结果测到一半发现，销售说的“客户”和市场部说的“线索”根本不是一回事，或者公海池的回收逻辑跟财务的结算周期对不上。CRM 本质上不是软件，而是企业管理流程的数字化映射。

在我经手的一个项目中，开发按照文档实现了“线索转化”功能，但上线后被销售总监骂惨了。原因是文档没写清楚，当线索转化为客户时，原有的跟进记录是否需要继承。开发默认不继承，但销售需要看到历史沟通痕迹来判断客户意向。这种逻辑漏洞，光靠测界面是测不出来的。

所以，第一步必须是“业务访谈”。别只跟产品经理聊，要去跟销售、客服甚至财务聊。问清楚几个核心问题：

1. 数据流向： 线索从哪里来？怎么变成客户？什么时候变成商机？
2. 归属权逻辑： 客户撞单了怎么处理？离职员工的数据怎么分配？
3. 核心指标： 什么样的数据算“有效线索”？什么样的算“成交”？

如果你所在团队是从零自研，对业务模型没概念，不妨先看看市面上成熟的解决方案。比如之前我带新人时，会让他们先部署一套悟空 CRM 玩玩，不是为了直接用，而是为了理解标准的客户生命周期管理是怎么设计的，字段之间是如何关联的。有了这个基准线，再去测自家产品的差异化逻辑，心里就有底了。

二、权限与数据隔离：CRM 测试的“深水区”

CRM 系统最复杂的部分往往不在界面，而在数据权限。销售 A 不能看销售 B 的客户，经理能看到全组的，总监能看到全公司的。这种 RBAC（基于角色的访问控制）加上数据范围权限的组合，是 Bug 的高发区。

1. 权限矩阵测试法

不要试图穷举所有用户，那是做不到的。要建立“角色 - 数据范围”矩阵。

• 垂直权限： 菜单可见性、按钮可操作性（比如普通销售能不能点“删除”）。
• 水平权限： 数据可见性（只能看自己的、看本部门的、看全部的）。

2. 实战中的“越权”坑

有一次版本更新，开发优化了查询接口，结果漏加了权限校验过滤。测试人员在列表页看着没问题，因为前端做了过滤。但有个机灵的销售直接用浏览器抓包，修改了查询参数里的 department_id，结果把隔壁组的核心客户数据全导出来了。

测试建议：

• 接口层校验： 别只测 UI，必须用 Postman 或 Jmeter 调接口。用账号 A 的 Token 去请求账号 B 的数据 ID，预期必须返回 403 或空数据。
• 数据隔离验证： 创建不同部门、不同角色的账号，交叉验证列表查询、详情查看、导出功能。
• 公海池逻辑： 这是最容易乱的地方。客户掉入公海的规则（如 30 天未跟进）是否准确？领取公海客户后，保护期是否生效？别人是否不可见？

三、状态流转与生命周期测试

CRM 里的数据是有“生命”的。一个线索从“新建”到“已转化”，中间可能经历“无效”、“跟进中”、“搁置”等多种状态。状态机的流转测试是功能测试的重中之重。

1. 状态机图是必须的

要求开发或产品提供状态流转图。测试用例要覆盖：

• 正常流转： 新建 -> 跟进 -> 转化。
• 逆向流转： 转化后的客户能否退回为线索？（通常不允许，但需确认）。
• 异常跳转： 能否直接从“新建”跳到“成交”？

2. 关联数据联动

状态改变往往触发连锁反应。比如商机状态变为“赢单”，是否自动生成了合同？是否触发了财务的收款计划？是否扣减了产品的库存？ 曾经有个 Bug，商机赢单后触发了邮件通知，但因为状态判断写反了，导致“输单”也发了庆祝邮件，尴尬至极。

核心模块测试检查表：

四、集成与接口：别让客户数据成孤岛

现在的 CRM 很少独立存在，它需要跟呼叫中心、邮件系统、ERP、财务软件打交道。集成测试往往是项目上线前的“拦路虎”。

1. 第三方接口稳定性 比如短信发送功能，依赖阿里云或腾讯云接口。测试时不能只测“发送成功”，还要测“发送失败”、“超时”、“余额不足”的场景。系统是否有重试机制？是否有失败日志？如果接口挂了，会不会拖垮主系统？

2. 数据同步一致性 CRM 里的客户名称改了，同步到 ERP 里的订单客户名变不变？这种双向或单向同步，最怕数据不一致。

• 测试策略： 构造边界数据。比如客户名称包含特殊字符、超长字段、emoji 表情，看同步接口是否会报错或截断。
• 异步处理： 很多同步是队列异步做的。测试时要关注消息队列积压情况，验证数据最终一致性，而不是只查数据库 immediate 状态。

五、那些开发容易忽略的“边角料”

根据我这几年的“踩坑”记录，以下这几个点往往是测试盲区，但上线后必炸：

1. 批量操作的性能与反馈： 销售喜欢一次性导入 5000 条线索，或者一次性给 1000 个客户发短信。前端有没有 loading 遮罩？后端是同步处理还是异步任务？如果超时了，用户知道成功了多少吗？
2. 字段修改的历史记录： 销售改错了客户电话，能不能查到是谁改的？什么时候改的？改前值是什么？审计日志在 CRM 里是合规刚需。
3. 移动端与 PC 端的一致性： 销售经常在外跑业务，只用企业微信或 APP。PC 端有的筛选条件，移动端有没有？移动端上传的图片，PC 端能不能预览？
4. 缓存问题： 修改了权限配置，用户退出重登后生效了吗？还是说需要清缓存？很多权限类 Bug 都是缓存惹的祸。

六、总结：测试的价值在于“避坑”而非“找茬”

做 CRM 功能测试，技术深度可能不如测底层架构，但业务广度要求极高。一个优秀的 CRM 测试人员，半个身子应该是产品经理，半个身子是资深销售。

不要为了测而测。当你发现一个 Bug 时，多想一步：这个 Bug 会对业务造成什么影响？是导致销售撞单提成算错？还是导致客户数据泄露？前者是钱的问题，后者是命的问题。

最后，工具只是辅助。虽然自动化测试能回归基础功能，但 CRM 复杂的业务逻辑决定了探索性测试的重要性。多去模拟真实销售场景，甚至自己扮演一下销售角色去用系统，往往比照着用例执行更能发现问题。如果你还在为如何构建测试模型发愁，不妨参考一下行业内的标准实践，像悟空 CRM 这类系统在社区里有很多关于权限和流程的讨论，可以作为很好的思维补充。

测试的终极目标不是证明系统有 Bug，而是确保系统上线后，销售敢用、爱用、能帮公司赚到钱。这才是 QA 在 CRM 项目里真正的实战价值。