Dynamics 365 UAT：实用指南

Dynamics 365 中何时需要 UAT

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

• 上线。首次启用 Dynamics 365 Sales 或 Customer Service，或从其他 CRM 迁移过来。
• 新的应用或模块。在 Sales 之外增加 Customer Service、为某个团队新建模型驱动应用、客户门户，或启用 Copilot 功能。
• 重大变更。与 ERP 的新集成，或新的案例路由方式。
• Microsoft 的更新。Microsoft 不再把 Dynamics 365 的变更集中在每年两次的发布波次中。新功能和变更全年陆续推出。发布计划已于 2026 年 10 月存档；即将推出的内容现在发布在 Microsoft 路线图 aka.ms/AIatWorkRoadmap 上。即使您自己什么都没改，任何一次更新都可能改变您系统的运行方式。

上线需要完整的 UAT。更新则需要按固定节奏，针对最重要流程进行较短的回归测试。详见上线之后。

环境

切勿在生产环境中测试。在 Power Platform 管理中心，每个环境都有一个类型。UAT 需要使用沙盒环境。

生产环境的副本

最接近真实情况的，是沙盒环境中的生产环境副本。复制环境时，您可以选择要带过去的内容：

• 所有内容：自定义项、架构和全部数据。最接近生产环境，但其中包含真实客户数据以及用户创建的每一条记录。
• 仅自定义项和架构：只有配置，没有数据。之后再加载您自己的测试数据。

复制会替换目标环境中的内容，因此要在 UAT 之前复制，切勿在 UAT 期间复制。之后，将集成和 Power Automate 流指向测试系统而非生产环境，检查邮箱，并在环境准备就绪后关闭管理模式。

解决方案与构建版本

项目的变更以解决方案的形式进入 UAT 环境。请将它们作为托管解决方案导入（如果有管道，就通过管道导入），这样 UAT 环境获得的内容就与之后生产环境获得的完全一致。

• 商定测试进行期间何时导入解决方案，例如每天分诊之后导入一次。在测试中途导入可能会让测试人员眼前的界面发生变化。
• 记录 UAT 环境中有哪些解决方案及其版本。解决方案的版本号就是您所测试的构建版本，每个问题和每次复测都对应一个构建版本。

测试数据

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

• 客户和联系人：为每种要测试的客户类型准备，并设置正确的负责人和业务部门。
• 产品和价目表。产品必须有价目表项，才能以正确的价格添加；而且必须先发布，销售代表才能使用。检查每个销售团队的价目表是否都已就绪。
• 队列、SLA 和知识文章（用于 Customer Service）：案例要路由到的队列、已激活的 SLA，以及可供查找的已发布文章。
• 待处理的记录：潜在顾客、处于不同阶段的商机以及未结案例。
• 不使用真实个人数据，能避免就避免。使用 所有内容 创建的副本包含全部数据，因此请对测试人员无需看到的数据进行掩码或匿名化处理。

安全角色、业务部门和每个角色的用户

UAT 要证明每个角色都能完成自己的工作，而且只能完成自己的工作。在 Dynamics 365 中，这取决于用户的安全角色、业务部门和团队。应用也是通过安全角色共享的：没有正确的角色，用户甚至看不到该应用。

• 列出要测试的角色，例如销售代表、销售经理、服务代理和服务主管，以及他们所属的业务部门。
• 在 UAT 环境中为每位测试人员分配一个恰好具有该角色的用户。每个用户都需要许可证，在沙盒中也一样。
• 如果一个人测试多个角色，请为每个角色使用单独的测试用户，或在两次测试之间更换角色，并记录使用的是哪个角色。
• 切勿使用系统管理员角色测试。它能看到并执行一切，因此恰恰会掩盖 UAT 应该发现的问题。

关于环境要告诉测试人员什么

• UAT 环境的地址。平常的书签打开的是生产环境。
• 打开哪个应用（例如 Sales Hub 或 Customer Service workspace），以及用哪个账户登录。
• 数据是测试数据：他们做的任何操作都不会影响真实客户，他们看到的任何内容也都不是最新的。
• 无法登录或看不到应用时该找谁。

在 UAT Studio 中每位测试人员都有一个 Test role（例如安全角色）和一个 Test account，在其测试顶部显示为 Log in as …。Notes for testers 中记录环境地址、测试邮箱以及联系人。测试人员通过邮件验证码或 Sign in with Microsoft 登录 UAT Studio。

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

从业务流程出发，而不是从 Dataverse 中的表出发。两个流程涵盖了 Dynamics 365 UAT 的大部分内容：

• 从潜在顾客到商机再到报价单。潜在顾客进入后，被授予资格并生成客户、联系人和商机。商机遵循业务流程，从价目表中添加产品，创建、审批并激活报价单，赢单后转交给下一个团队或系统。
• 案例管理。案例通过电子邮件或门户进入，被路由到正确的队列或代理，遵循其 SLA，借助知识文章解决，必要时升级，最后解决关闭。

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

业务流程

业务流程按阶段引导用户，某些步骤可以设为进入下一阶段前的必填项。请像用户一样测试它：

• 每个阶段，以及必填步骤为空时会发生什么。
• 每个分支，以及每个角色：业务流程可以只对部分安全角色启用。

路由、SLA 和知识

在 Customer Service 中，很多工作无需点击就会发生。请测试系统应自动完成的事情：一封电子邮件变成对应客户的案例，案例进入正确的队列，SLA 显示正确的时间并在到期前发出警告，代理能找到正确的知识文章。

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

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

优先级和风险

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

也要加入异常路径：必填字段留空、折扣超过上限、另一个业务部门中不该看到某条记录的用户。

在 UAT Studio 中从 Excel 导入测试用例，包含 Priority 和 Risk 列，从 Azure DevOps Test Plans 读取，或从模板库中的 Dynamics 365 脚本开始（模板库是每个付费套餐的附加组件）。借助 AI test design，AI 会根据您在 Azure DevOps 中的用户故事建议测试用例，也可以在贵公司自己的模型上运行，例如 Microsoft Foundry / Azure OpenAI。在您批准之前，任何建议都不会成为测试用例。

测试人员

选择每天做这些工作的人：客户经理、服务代理，以及负责审批、队列和仪表板的经理。从每个使用 Dynamics 365 的团队和国家选取测试人员，因为他们的流程、业务部门和价目表各不相同。

需要多少时间

与测试人员的经理商定每位测试人员的时间，并为复测预留时间。仍在接电话或拜访客户的测试人员是完成不了的。

启动会

先开一个简短的启动会：他们的测试为什么重要，如何打开 UAT 环境，如何记录结果，以及如何提交问题。让每位测试人员在启动会期间登录一次并打开应用。大多数许可证、角色和环境错误的问题都会在那时暴露出来，而不是在测试日。

一个测试日还是一周

一个测试日能集中注意力并快速获得答复，适合范围较小的情况。分散在一周内、每次几个小时，则为新构建版本和复测留出空间，适合包含许多流程的上线。无论哪种方式，都要每天固定一个分诊时间。

UAT 期间

记录问题

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

• 步骤、他们的预期以及实际发生的情况。
• 页面截图，如果有错误消息，也一并截入。
• 记录链接。它就在浏览器的地址栏中，能让顾问直接进入出错的商机或案例。
• 用户以及他们测试时使用的安全角色。

在 UAT Studio 中适用于 Chrome 和 Edge 的浏览器扩展会在 Dynamics 365 旁边的侧边栏中显示测试。失败的步骤会一并带上截图、记录链接和页面的错误消息。问题中会在测试人员姓名旁显示其角色。

分诊

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

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

将需要修复的问题发送给开发人员（通常在 Azure DevOps 中），附带截图和记录链接。

复测

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

每日状态

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

在 UAT Studio 中分诊在共享屏幕上进行，使用 Fix、Reject 和 Change request。问题会成为 Azure DevOps 中的 Bug 工作项；在那里完成后，问题变为 Ready for retest，测试人员会收到邮件。每个轮次都会保留其版本、构建版本和环境。新问题、测试轮次和签核会发送到 Microsoft Teams 频道。

签核与 go/no-go

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

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

谁来签核

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

报告包含哪些内容

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

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

按固定节奏进行回归测试轮次

上线之后，更新会全年持续到来，每一次都可能改变某个窗体、流或权限。您的 UAT 测试用例是您最好的回归测试：它们准确描述了业务方所接受的内容。

• 选择一个节奏，例如每月或每季度进行一次回归测试轮次，现在就把日期写进测试人员的日历。
• 每轮开始前，阅读 Microsoft 路线图和发给管理员的消息，并记下哪些变更涉及您的流程。
• 预览版或早期访问中的功能，先在沙盒环境中试用，再让它们到达您的用户。
• 与几位业务测试人员一起再次测试 Must 测试用例，时间允许的话也测试 Should。
• 像 UAT 中一样记录问题，并在变更到达您的用户之前修复它们。

在 UAT Studio 中将 Dynamics 365 选为项目的 CRM。Start a regression round 会复制您从之前某次 UAT 中选择的测试用例，包括步骤、测试数据和预期结果：Must and Should、Only Must 或 All test cases in scope。

免费使用

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

Microsoft、Dynamics 365、Power Platform、Azure DevOps 和 Microsoft Teams 是 Microsoft 集团公司的商标。UAT Studio 与 Microsoft 没有关联，也未获得其认可。