为什么 CRM 需要回归测试
上线之后，即使您自己的团队什么都没改，您的 CRM 也在不断变化。Salesforce 和 Microsoft 会为每个客户更新平台。大多数变更都是改进。有些会改变某个页面、某个默认设置或某项功能的工作方式，偶尔还会破坏您的业务所依赖的东西。
回归测试回答一个问题：业务方在上线时接受的内容现在还能正常工作吗？它不是一次新的 UAT。它是对最重要流程的一次简短、有针对性的检查，在变更到达用户之前，由熟悉业务工作的人来完成。
您自己的版本发布也需要同样的检查。新的集成、报价上的新字段、个案路由的变更：每一项都可能影响以前正常工作的内容。
Salesforce：每年三次版本发布
Salesforce 每年有三次主要版本发布：Spring、Summer 和 Winter。Winter 版本在秋季推出，并使用下一年的编号。每个组织都会升级，日期由 Salesforce 提前公布。
- 沙盒预览。位于预览实例上的沙盒会比生产环境提前数周获得新版本。这就是您的测试窗口。每次版本发布前，Salesforce 都会公布哪些实例参与预览，以及如何让沙盒留在预览中。刷新可能会让沙盒进入或退出预览，因此请及时检查。
- 版本说明。阅读与您使用的云和功能相关的内容。留意哪些内容会自动为您开启，以及哪些会改变用户日常使用页面的外观。
- 发布更新。有些变更会在 Setup 中公布，并附有强制执行的日期。在该日期之前先在沙盒中测试，以免它们在生产环境中让您措手不及。
因此对于 Salesforce，节奏是既定的：在每次版本发布的预览窗口内进行一轮回归测试，每年三次。
在 UAT Studio 中将 Salesforce 选为项目的 CRM。从版本发布前大约两个月起，项目页面会显示 Coming CRM releases，包括沙盒预览日期、生产环境日期和版本说明链接。Salesforce 仍可能调整这些日期，因此请查看版本说明。
Dynamics 365：全年持续更新
Microsoft 不再把 Dynamics 365 的变更集中在每年两次的发布波次中。新功能和变更全年陆续推出。发布计划已于 2026 年 10 月存档；即将推出的内容现在发布在 Microsoft 路线图 aka.ms/AIatWorkRoadmap 上。
这意味着每年不再有一个可以围绕其规划测试的重大时刻。变更以更小的步伐、更频繁地到来。等待一次大版本发布已经行不通了，而每次变更后都测试又太多。
选择固定节奏
答案是按固定节奏进行回归测试轮次，不管 Microsoft 在此期间发布了什么：
- 每月一次：当 CRM 是业务核心、您使用许多应用和功能，或者经常开启新功能时。
- 每季度一次：适用于稳定的配置，自己的变更很少。
- 额外一轮：在您自己的变更上线之前，或者当 Microsoft 的某项变更明显涉及您的某个关键流程时。
把全年的日期都放进测试人员的日历。固定节奏比每次有事才临时规划的轮次更容易坚持。
每轮之前
- 阅读 Microsoft 路线图以及 Microsoft 365 管理中心里发给管理员的消息，记下哪些变更涉及您的流程。
- 预览版功能先在沙盒环境中试用，再让它们到达您的用户。
- 确保您测试所用的沙盒与生产环境具有相同的版本和相同的解决方案。
在 UAT Studio 中将 Dynamics 365 选为项目的 CRM，并从上线项目或上一轮的项目出发，用 Start a regression round 开始每一轮。
在 UAT Studio 中在 Setup 下的 Check the Dynamics 365 updates 中选择 Every quarter 或 Every month。项目页面随后会显示当前周期并附有路线图链接，管理员每个周期会在周期开始前两周收到一封电子邮件。
选择要重新测试的内容
回归测试轮次不是把所有内容再测一遍的地方。按以下顺序选择：
- Must 测试用例。每天都必须正常工作的内容：创建报价、转换潜在客户、路由个案、审批。每一轮都要测试这些。
- 变更涉及的内容。对照您的流程清单阅读版本说明或路线图。涉及报价的变更意味着要测试报价相关的测试用例，包括 Should 和 Could 的用例。
- 集成和自动化。与 ERP、网站或邮件的连接，以及在后台运行的流程。它们会悄无声息地出故障，所以要专门测试。
- Should 测试用例，在有时间时测试。
然后看看您自己的团队自上一轮以来改了什么。凡是您自己构建、且没有与平台变更一起测试过的内容，也都应纳入本轮。
保留一份简短的关键清单
一次性写下业务方一天都离不开的十到二十个流程。它们是每一轮回归测试的核心。每半年与流程负责人一起审核一次这份清单，并在您自己的每次重大变更之后审核。
在 UAT Studio 中使用 Release readiness 附加组件后，Review the release 会显示一次 Salesforce 版本发布或 Dynamics 365 更新影响您的哪些测试用例及原因，为尚未覆盖的部分提出测试用例建议，并列出必需更新及其日期。回归测试轮次随后恰好包含 Must 测试用例、您保留的受影响测试用例以及您批准的新测试用例。轮次中的失败会说明它与哪项变更有关。每月 €99：在 Plan & billing 中添加。
复用您的测试用例
您拥有的最好的回归测试，就是上线 UAT 中的那套测试用例。它们准确描述了业务方所接受的内容，包含步骤、测试数据和预期结果。不要每一轮都重新编写。
- 上线后把测试用例保存在一个地方，并保留其优先级。
- 当您自己的流程发生变化时更新它们，让下一轮测试的是现在的 CRM，而不是上线时的 CRM。
- 每轮之前检查测试数据。沙盒刷新或生产环境副本可能会删除或改变测试用例所用的记录。
- 为生产环境中发现的每个严重问题添加一个测试用例，以便下次能及时发现。
在这里，业务测试人员能照着执行的测试用例是值得投入的：它们会被反复使用。请参阅编写业务测试人员看得懂的测试用例。
在 UAT Studio 中Start a regression round 会复制您所选起始项目的测试用例，包括步骤、测试数据和预期结果。选择要带入哪些：Must and Should、Only Must 或 All test cases in scope；没有优先级的测试用例按 Should 计算。新项目会沿用分组和设置，您在 Setup 中邀请测试人员。不会编造或修改任何内容。
由谁测试，需要多久
由谁测试
回归测试轮次需要的人比 UAT 少，但仍应来自业务部门。每个流程请一两位关键用户：每天做这项工作、一有异常就能马上察觉的人。CRM 管理员负责准备这一轮并测试后台运行的内容，但不应成为唯一的测试人员。
让同一批人一轮接一轮地测试。他们会越来越快，也能注意到新测试人员会忽略的细微变化。
期限
- 准备：一两天时间阅读变更、选择测试用例并检查测试数据。
- 测试：每位测试人员几个小时，月度轮次分布在一两天内，变更较多的 Salesforce 版本发布最长可达一周。
- 修复和复测：在变更进入生产环境之前预留几天，用于处理发现的问题。
对于 Salesforce，这些都必须安排在预览窗口内。在窗口初期就开始，而不是最后一周。
记录发现的问题
像在 UAT 中一样记录问题：步骤、您的预期、实际发生的情况、截图以及记录链接。每天与 CRM 团队一起进行分诊。对于由平台引起的问题，先查看版本说明或路线图：这往往是一项已知变更，只需调整某个设置。
在 UAT Studio 中每一轮都会记录其版本、构建和环境，因此 go/no-go 报告会说明测试的是什么。修复之后，在仪表板上用 Failed and blocked only 执行 Start round 2，只重新测试出问题的内容；之前轮次的结果会保留。
进入生产环境前签核
回归测试轮次与 UAT 一样以决定结束，只是更简短。一次性商定退出标准，并在每一轮中使用：
- 每个 Must 测试用例都已通过。
- 没有未解决的 Critical 问题。
- 每个未解决的 High 问题都有业务方接受的变通方案，或者在变更进入生产环境之前完成修复。
每个流程的负责人为自己负责的部分签核：接受、有条件接受或拒绝。对于 Salesforce 版本发布，您无法阻止升级，因此拒绝意味着在生产环境日期之前完成修复或找到变通方案，并通知用户。对于您自己的变更，拒绝意味着它需要等待。
保留每一轮的结果。一年后，您就会有一份清晰的记录：每次变更后测试了什么，以及由谁接受。关于如何准备决定，请参阅go/no-go 决策。
在 UAT Studio 中回归测试轮次是一个独立的项目，以该版本作为其 Release，因此它的 go/no-go 报告会说明涉及哪个 CRM 版本。流程负责人按分组签核，签核属于该轮次。
免费使用
CRM 上线 UAT 检查清单同样适用于回归测试轮次，可作为免费 Excel 文件获取。各平台的情况，请参阅 Salesforce UAT 和 Dynamics 365 UAT。
Salesforce 是 Salesforce, Inc. 的商标。Microsoft 和 Dynamics 365 是 Microsoft 集团公司的商标。UAT Studio 与 Salesforce 或 Microsoft 没有关联，也未获得其认可。