Salesforce UAT：实用指南

Salesforce 中何时需要 UAT

用户验收测试只回答一个问题：业务部门能否在这个版本的 Salesforce 中完成工作？由实际做这些工作的人，用他们自己的话，在版本进入生产环境之前进行测试。在以下时刻您需要 UAT。

• 上线。首次启用 Sales Cloud 或 Service Cloud，或从其他 CRM 迁移过来。
• 新的云或重大变更。在 Sales Cloud 之外增加 Service Cloud、CPQ、与 ERP 的新集成，或新的个案路由方式。
• 每次 Salesforce 版本发布。Salesforce 每年有三次版本发布：Spring、Summer 和 Winter。Winter 版本在秋季推出，并使用下一年的编号。即使您自己什么都没改，每次版本发布也都可能改变您组织的运行方式。
• 沙盒预览。位于预览实例上的沙盒会比生产环境提前数周获得新版本。这就是您的测试窗口。每次版本发布前，Salesforce 都会公布哪些实例参与预览，以及如何让沙盒留在预览中。请及时检查，因为刷新可能会让沙盒进入或退出预览。

上线需要完整的 UAT。版本发布则需要针对最重要流程的较短回归测试。详见上线之后。

沙盒

切勿在生产环境中测试。Salesforce 有四种沙盒类型，其中两种适合 UAT。

规划刷新

刷新会用生产环境的新副本替换沙盒中的所有内容。每种沙盒类型都有两次刷新之间的最短间隔，其中 Full 沙盒的间隔最长。因此请提前规划：

• 在 UAT 之前刷新，切勿在 UAT 期间刷新。查看沙盒下一次可以刷新的时间。
• 刷新后再将版本部署到沙盒。只存在于沙盒中的工作会丢失。
• 完成刷新后的步骤：将集成和指定凭据指向测试系统而非生产环境，并关闭不应运行的计划作业。
• 检查电子邮件发送能力。新建或刷新后的沙盒只发送系统电子邮件。Web-to-lead 回复、审批和个案邮件需要更多设置，但 Full 沙盒中保存着您联系人的真实邮箱地址。在开放之前请改用测试地址。

测试数据

数据没有准备好，测试人员就会浪费数小时。请在第一个测试日之前准备好：

• 客户和联系人：为每种要测试的客户类型准备，并设置正确的所有人、区域和记录类型。
• 产品和价格手册。产品必须先在标准价格手册中有价格，才能加入其他价格手册。检查每个销售团队的价格手册是否已启用。
• 待处理的记录：处于不同阶段的业务机会、未结个案，如果测试权利，还要有接近里程碑的个案。
• 不使用真实个人数据，能避免就避免。Full 沙盒会复制全部内容，因此请对测试人员无需看到的数据进行掩码或匿名化处理。

按简档和权限集设置用户

UAT 要证明每个角色都能完成自己的工作，而且只能完成自己的工作。为要测试的每种简档、角色和权限集组合创建一个测试用户，例如销售代表、销售经理和服务坐席。每位测试人员拥有自己的用户，这样就不会有两个人同时使用同一个用户。

刷新后，Salesforce 会在每个用户名后加上沙盒名称，并在每个用户的邮箱地址后加上 .invalid。请将每个测试用户的邮箱设为测试人员会查看的地址，否则密码重置和审批邮件将无处可去。

Log in as 让管理员以另一个用户的视角查看 Salesforce。这是查看测试人员所报告问题的好方法。而测试本身，测试人员要使用自己的测试用户：这样才能确认简档和权限集是正确的。

关于沙盒要告诉测试人员什么

• 沙盒的地址。地址中包含沙盒名称，或者他们通过 test.salesforce.com 登录。Salesforce 的常规登录页面打开的是生产环境。
• 他们的用户名（以沙盒名称结尾），以及如何获取密码。
• 数据是测试数据：他们做的任何操作都不会影响真实客户，他们看到的任何内容也都不是最新的。
• 无法登录时该找谁，以免浪费一上午。

在 UAT Studio 中每位测试人员都有一个 Test role 和一个 Test account，在其测试顶部显示为 Log in as …。Notes for testers 中记录沙盒地址、测试邮箱以及联系人。

基于用户故事和流程的测试用例

从业务流程出发，而不是从 Salesforce 中的对象出发。两个流程涵盖了 Salesforce UAT 的大部分内容：

• 从潜在客户到回款（lead to cash）。潜在客户通过 web-to-lead 进入，被分配并转换。业务机会从价格手册中添加产品，创建并审批报价，赢单，然后订单或合同转交给下一个团队或系统。
• 个案管理。个案通过 email-to-case 或门户进入，被路由到正确的队列或坐席，遵循其权利和里程碑，借助知识文章解决，必要时升级，最后关闭。

将每个流程拆分为测试用例，每个测试用例对应一个业务场景，例如使用现有客户转换潜在客户。然后检查范围内的每个用户故事是否至少有一个测试用例。

业务测试人员看得懂的步骤

将每个步骤写成一个操作和一个预期结果，使用测试人员的语言。在需要的地方加上测试数据。测试人员永远不必猜测某个步骤是否通过。

优先级和风险

并非每个测试用例都同样重要。将每个测试用例标记为 Must、Should 或 Could：Must 是上线第一天就必须正常工作的内容，例如创建报价或路由个案。再加上风险：上线后出错的代价是什么。测试人员从 Must 和高风险开始，这样即使时间不够，重要的测试也已完成。

也要加入异常路径：必填字段留空、折扣超过上限、用户看到了不该看到的记录。

在 UAT Studio 中从 Excel 导入测试用例，包含 Priority 和 Risk 列，或从模板库中的 Salesforce 脚本开始（模板库是每个付费套餐的附加组件）。测试人员会先看到他们的 Must 测试用例。

测试人员

选择每天做这些工作的人：销售代表、服务坐席，以及负责审批、预测和报表的经理。从每个使用 Salesforce 的团队和国家选取测试人员，因为他们的流程和价格手册各不相同。

需要多少时间

按测试人员而不是按团队申请时间，并与其经理达成一致。规划好脚本，让每位测试人员都知道要做多少工作。为修复后的复测预留时间。仍在接电话或拜访客户的测试人员是完成不了的。

启动会

先开一个简短的启动会：他们的测试为什么重要，如何登录沙盒，如何记录结果，以及如何提交问题。让每位测试人员在启动会期间登录一次。大多数用户和密码问题都会在那时暴露出来，而不是在测试日。

一个测试日还是一周

• 一个测试日，在同一个房间或同一个通话中进行，能集中注意力并快速获得答复。适合范围较小、测试人员难以长时间抽身的情况。
• 分散在一周内，每次几个小时，在各时段之间留出修复和复测的空间。适合包含许多流程的上线。

无论哪种方式，都要每天固定一个分诊时间。

UAT 期间

记录问题

好的问题无需开会就能修复。请测试人员提供：

• 步骤、他们的预期以及实际发生的情况。
• 页面截图。
• 记录链接。它就在浏览器的地址栏中，能让开发人员直接进入出错的业务机会或个案。
• 他们测试时使用的用户，以便团队知道使用了哪个简档和权限集。

在 UAT Studio 中适用于 Chrome 和 Edge 的浏览器扩展会在 Salesforce 旁边的侧边栏中显示测试。失败的步骤会一并带上截图、记录链接和页面的错误消息。问题会以链接形式显示记录，包括所在沙盒。

分诊

每天与业务方和 Salesforce 团队一起过一遍新问题。为每个问题设定严重程度和负责修复的人，并做出决定：

• 修复：真实存在的问题，在本次版本中修复。
• 拒绝：Salesforce 按设计工作，或测试本身有误。
• 变更请求：是一个需求，而不是缺陷。它进入待办列表，而不是本次版本。

复测

修复部署到沙盒后，发现问题的测试人员会再次测试该步骤。记录每次复测是在哪个构建版本上进行的。大规模修复之后，还要重新测试其周边的流程。

每日状态

每天向指导委员会发送一份简短的状态报告：相对于计划的进度、按严重程度分类的未解决问题，以及阻碍因素。只讲事实。go/no-go 会议上不出意外。

在 UAT Studio 中分诊在共享屏幕上进行，使用 Fix、Reject 和 Change request。Ready for retest 会给复测人员发送邮件。每日概览通过邮件或 Microsoft Teams 发送，显示前一天的结果和问题。

签核与 go/no-go

UAT 以业务方的决定结束。在第一个测试日之前就商定退出标准，这样最后就不会有人为此争论：

• 没有未解决的 Critical 问题。
• 每个 Must 测试用例都已通过。
• 每个未解决的 High 问题都有业务部门接受的变通方案或修复日期。
• 范围内的每个测试用例都有结果。

谁来签核

由每个流程的负责人签核，例如销售总监负责从潜在客户到回款，客户服务主管负责个案管理。他们可以选择：接受、有条件接受或拒绝。记录每项条件，以及由谁在何时之前完成。随后由指导委员会决定是否上线。

报告包含哪些内容

• 哪些在范围内，哪些没有测试。
• 按流程或团队、按优先级的结果。
• 所测试的沙盒、版本和构建版本。
• 按严重程度分类的未解决问题，以及对每个问题的决定。
• 签核及其条件，以及上线最初几周的已知风险。

在 UAT Studio 中按分组签核：Accepted、Accepted with conditions 或 Rejected。默认情况下，只要存在未解决的 Critical 问题，任何人都无法接受。最后一个结果出来后，go/no-go 报告即可以 PDF 或幻灯片形式提供。

每次 Salesforce 版本发布的回归测试轮次

上线之后，版本发布会持续到来：每年三次。每次发布都可能改变某个页面、流或权限。您的 UAT 测试用例是您最好的回归测试，因为它们准确描述了业务方所接受的内容。

• 上线后保留测试用例，包括其步骤、测试数据和预期结果。
• 阅读即将发布版本的版本说明，并检查哪些功能会为您自动启用。
• 检查您的 UAT 沙盒是否在沙盒预览中，并在预览窗口内规划这一轮测试。
• 与几位业务测试人员一起再次测试 Must 测试用例，时间允许的话也测试 Should。
• 像 UAT 中一样记录问题，并在版本发布到生产环境之前修复它们。

在 UAT Studio 中将 Salesforce 选为项目的 CRM。项目页面随后会显示即将到来的 Salesforce 版本发布，包括沙盒预览日期、生产环境日期和版本说明。Start a regression round 会复制您选择的测试用例：Must and Should、Only Must 或 All test cases in scope。

免费使用

关于 UAT 之前、期间和之后需要安排的所有事项，请参阅 CRM 上线 UAT 检查清单，同样提供免费 Excel 文件。关于 UAT Studio 能为 Salesforce UAT 做什么，请参阅 Salesforce UAT。

Salesforce、Sales Cloud 和 Service Cloud 是 Salesforce, Inc. 的商标。UAT Studio 与 Salesforce 没有关联，也未获得其认可。