实施Microsoft Dynamics 365 CE-10. 测试和用户培训计划，解释如何为您的项目规划和执行测试

本章将帮助您了解如何准备测试计划文档以及包含哪些常见部分。我们将讨论测试Dynamics365CE的不同选项，如手动或自动测试。您还将了解手动测试和自动测试之间的区别。稍后，我们将讨论用户接受测试（UAT）以及如何执行。最后，我们将探讨如何制定最终用户培训计划，以及如何进行最终用户培训，以使Dynamics 365 CE的实施成功。

我们将在本章中讨论的主要主题如下：

• 准备测试计划
• 进行手动测试
• 进行自动化测试
• 进行UAT
• 准备最终用户培训计划

技术要求

尽管本章将帮助您使用UAT进行测试和规划，但您应该熟悉测试概念。为了编写自动化测试用例，您需要具备编程知识。您还应该熟悉使用GitHub。

准备测试计划

我们知道如何定制和扩展Dynamics365CE，所以让我们来谈谈测试我们的定制和开发。根据您使用的方法，您可能需要在开发阶段结束时执行测试，例如在瀑布模型中，或者在第一个sprint结束时需要执行测试时，例如在敏捷模型中。无论选择何种方法，我们项目的测试都是根据测试计划进行的，因此在测试阶段开始之前制定计划至关重要。在准备测试计划之前，我们需要了解什么是测试计划。

什么是测试计划？

测试计划基本上是一份文档，它解释了测试阶段的范围以及我们将在测试阶段执行的所有活动。测试计划文件的主要目的是验证产品或项目设计及其是否符合客户提供的要求。测试计划文档为测试过程提供了完整的指导方针，其中包括测试环境细节、测试资源、测试方法、测试活动和时间表。测试计划文档主要由测试团队经理或领导创建。以下是测试计划的主要功能：

• 它定义了测试程序。
• 它提供了关于哪些在测试范围内，哪些不在测试范围的明确信息。
• 它提供了有关测试活动的详细信息，帮助我们估计测试所需的工作量。
• 它提供了有关测试资源需求的详细信息。
• 它提供了有关测试可交付成果的详细信息。

现在我们对测试计划有了一个初步了解，让我们讨论如何准备测试计划文档。

如何编写测试计划

测试计划可以手动创建，也可以使用测试计划软件创建。要编写测试计划，基本标准是了解我们将要测试的产品、将要使用该系统的目标用户，以及客户为什么要实施这个新系统。如果我们不清楚这些细节，就很难写出一份好的测试计划文档。建议阅读需求收集文档并了解有关Dynamics 365 CE的基本详细信息。

编写测试用例的另一个关键方面是了解测试范围：Dynamics 365 CE的哪个模块是为客户实现的，他们将使用哪些特定功能？这有助于我们设置测试范围。我们还应该清楚我们的测试方法。测试计划文件中应该提到我们是要手动执行测试，还是要使用自动测试方法。我们应该意识到那些将在日常活动中使用这一新系统的最终用户的期望。我们的测试文件应包括下图中列出的常见部分：

介绍

顾名思义，本节提供了测试计划文档的总体摘要。我们可以在本节下包括一些小节，这些小节可以提供有关测试计划文件目标、范围、环境细节和所需的测试资源：

• 目标：本节应提供测试计划的目标。我们可以包括有关拟议系统的详细信息以及将用于开发拟议系统的工具。例如，在我们的案例中，我们可以在这里详细介绍HIMBAP汽车服务中心是什么，以及我们计划使用Dynamics 365 CE实现什么。以下是一个好的测试计划的一些目标：
  • 针对功能性和非功能性需求对拟议系统进行测试。
  • 确保我们符合客户提供的质量规范。
  • 应识别和记录问题，以便进行报告。
  • 所有问题都应在上线前解决。
  • 它还应包括有关UAT活动的详细信息。
• 测试环境：本节应提供有关我们将要执行测试的环境的详细信息，以及访问信息。
• 范围：测试计划的范围定义了需要测试的内容。在这里，我们提到了哪些功能性或非功能性需求在范围内，以及哪些功能性和非功能性要求在范围外。
• 团队成员：在这里，我们提供了关于将要执行测试的测试团队的团队成员详细信息，以及他们在团队中的角色。

测试方法

测试方法取决于用于项目管理的项目方法，以及项目的发布周期。例如，如果使用敏捷实现方法，那么测试团队将在1或2周的测试后获得迭代。如果使用瀑布方法论，那么在所有开发结束后将开始测试，因此这可能取决于项目的方法论。但是，当具体谈到Dynamics 365 CE时，如果我们记住每年发布的两个平台更新以及随后的小型功能和安全更新都是由微软全年发布的，那么自动化测试是一个不错的选择。

这里提到的另一件事是，我们是要使用手动测试还是自动测试。让我们快速回顾一下：

• 手动测试：这是最古老的测试方法，所有测试用例都由测试团队手动执行。使用基于用例创建的测试用例来执行测试。这些用例与建议的解决方案功能相关联。测试期间捕获的任何错误/问题都会在错误跟踪系统中报告。错误跟踪系统可以是软件，也可以是简单的Excel表格。基于这些错误，准备了一份测试报告，并与开发团队共享，以解决这些问题。
• 自动化测试：这是测试的另一个选项，其中测试脚本以代码的形式编写，以自动化测试用例的执行。在自动化测试的情况下，测试脚本也是使用自动化测试工具编写的。
  市场上有许多自动化测试工具。公司根据其专业知识和要求选择工具。使用自动化测试的主要目标是提高测试效率并提高所提出的系统质量。测试完成后会准备一份错误报告以供提交。

现在我们了解了这两种测试方法，让我们看看这两种程序之间的区别：

手动测试	自动化测试
测试人员手动编写和执行测试用例。	我们可以使用自动化工具来编写和执行测试用例。
编写和执行测试用例是一个耗时的过程。	自动化测试比手动测试更快，因为不需要太多的人工交互。
手动测试需要对经验丰富的测试资源进行投资。	我们需要投资于自动化测试工具。
手动测试可能会出现错误。	考虑到所有测试用例都设计正确，这是完全自动化的，因此出错的可能性较小。
这种测试不能帮助我们执行应用程序的性能测试。	我们可以使用自动化测试工具进行性能测试和压力测试。
如果需要重复测试，则不适用。	它适用于重复测试。

上表有助于我们理解手动和自动培训方法之间的基本区别——我们可以根据自己的需求使用这两种方法。现在，让我们看看测试阶段的主要可交付成果是什么。

测试可交付成果

本节提供了我们将向客户提供的文档的详细信息。没有测试可交付成果的具体列表，但在提供给客户的文档中通常可以找到以下部分：

• 测试计划文件
• 测试脚本
• 测试场景详细信息
• 测试数据
• 错误报告
• 测试报告
• 整体测试状态报告

风险

在本节中，我们将提供风险详细信息（如果有的话）。例如，以下几点可能是任何项目的常见风险：

• 未定义的产品范围：如果项目范围没有明确定义，可能会延迟测试过程。
• 资源不足：如果测试资源不足，可能会延迟测试。
• 频繁更改的需求：如果需求持续更改，我们可能需要重新测试功能。

现在我们已经了解了测试计划文档中包含的常见部分，在下一节中，我们将讨论如何进行手动测试

进行手动测试

手动测试是基于测试脚本或测试用例进行的，这些脚本或用例由测试团队负责人或高级测试资源创建。这些测试用例可以手动创建，也可以使用自动化测试工具创建。进行手工培训涉及许多步骤。下图描述了标准手动测试生命周期：

分析需求评审

这是手动测试过程的第一步。为了进行测试，完全理解需求是至关重要的。测试团队可以审查在项目开始时生成的需求文档，并了解需求。这有助于他们了解需要测试的内容。一旦需求明确，下一步就是编写测试用例。

编写测试用例

另一个关键步骤是创建一个测试用例。测试用例基本上是由测试人员执行的一组指令，用于验证应用程序或产品的功能。这些指令清楚地定义了哪些特定输入应该输入到源应用程序中，以及这些输入的结果应该是什么输出。在编写测试用例时，建议以简单的方式包含说明，以便易于理解。在为Dynamics 365 CE编写测试用例时，我们可以使用以下通用字段：

• 用例ID：每个测试用例都应该使用其唯一的ID进行识别。我们可以根据模块或功能创建一个用例ID，具体取决于我们的需求。
• 模块：在模块字段中，我们可以提供有关编写测试用例的主题或模块的详细信息。例如，如果我们正在为客户功能编写测试用例，我们可以在模块名称中使用客户管理。
• 测试用例描述：此字段提供有关测试用例描述的信息。例如，如果我们希望测试在Dynamics365CE中创建客户记录，那么我们的测试用例描述可以是创建新客户。
• 目的：我们还可以包括这个字段，它提供了特定测试用例的目标。例如，对于“创建新客户”测试用例，我们的目标是确保在Dynamics 365 CE中创建和保存客户记录时没有任何问题。
• 详细步骤：此字段提供执行操作以测试某些功能的详细步骤。这些步骤包含完整的导航详细信息以及我们需要输入到应用程序中的测试数据。
• 预期结果：此字段提供有关执行详细步骤后应生成的输出的详细信息。例如，在我们的“创建新客户”测试用例中，应该在没有任何错误的情况下创建客户记录。
• 实际结果：此字段提供有关我们是否收到基于预期结果的输出的详细信息。通常，此字段有两个选项，通过或失败，测试人员可以根据输出进行选择。
• 评论：这个测试可以提供一些关于实际结果的额外细节。这些注释有助于开发人员重现和修复特定问题。
• 作者：此字段提供有关测试用例作者的详细信息。
• Tested By：此字段提供执行测试用例的测试人员的详细信息。

现在，我们了解了添加到测试用例模板中的常见字段。我们可以根据可用性在Excel或任何其他编辑器中编写测试用例。以下是用于客户创建的示例测试用例：

Case ID	101
Module	Customer Management .
Description	Create a new customer .
Purpose	To make sure a user can create a new customer record without any issues .
Detailed steps	• Log in to the Dynamics 365 CE environment. • Navigate to Auto Service | Customers and click on the New button. • Create a customer with the following details: • Name : HIMBAP • Phone: 12324341 • Website : himbap.com • Relationship Type : Customer • Click on the Save button.
Expected result	A new Customer record is created with all the information that is filled out.
Actual result
Comments
Author
Tested by

类似地，我们可以编写另一个测试用例来更新现有的客户记录、创建联系人和更新现有的联系人记录。我们还可以为其他与自动服务相关的实体创建一个测试用例。例如，以下是一个车辆实体的示例测试用例：

Case ID	501
Module	Vehicle Management .
Description	Create a new vehicle record.
Purpose	To make sure a user can create a new vehicle record without any issues .
Detailed steps	• Log in to the Dynamics 365 CE environment. • Navigate to Auto Service | Vehicle and click on the New button. • Fill in the following details: • Vehicle Name : Alto Black • Vehicle Number : HR 26-1029 • Customer : Select Mahender from the lookup • Issue Date : 09-05-2016 • Make : Select Maruti Suzuki from the lookup • Model : Select Maruti Alto K10 from the lookup • Manufacturing Year : Select 2015 from the lookup • Vehicle Type : Hatchback • Vehicle Category : Automatic • Click on the Save button.
Expected result	A new vehicle record is created with all the information that is filled out.
Actual result
Comments
Author
Tested by

我们可以根据刚才介绍的示例测试用例创建一个测试用例。一旦我们的测试用例准备好了，下一步就是执行它。

进行测试用例

在这个步骤中，测试人员执行基于应用程序的功能或模块编写的测试用例。所有的测试用例都应该按原样执行，而不需要做任何假设。建议测试人员应具备Dynamics 365 CE的基本知识，以便执行Dynamics 365 CE测试用例。

错误日志记录

一旦我们执行了所有的测试用例，我们就会将报告的问题记录到问题跟踪系统中。我们可以使用来自不同供应商的错误跟踪应用程序，也可以使用Dynamics365CE创建自己的内部应用程序。一旦记录了所有问题，测试人员就可以准备一份错误报告，并将其提交给项目经理进行审查。

重新测试缺陷

这是测试的最后一步，在开发人员修复了所有缺陷后，将重新测试这些缺陷。一旦一切正常，产品或应用程序就可以进行UAT了。手动测试就是这样进行的。现在我们有了手动测试的想法，我们可以详细讨论它。

进行自动化测试

当涉及到对拟议系统进行测试时，另一种选择是自动测试。我们已经讨论了手动测试和自动测试之间的区别。自动化测试主要是在我们的资源较少并且需要执行重复测试的情况下进行的。与手动测试类似，自动化测试过程也有一个生命周期，如下图所示：

范围界定自动化测试

在这个阶段，我们设置了自动化测试的范围。在设置范围时，将对自动测试进行可行性检查，以确保可以对目标系统进行自动测试。在大多数情况下，一旦我们有了手动测试用例，就会计划自动测试。我们可以回顾现有的测试用例，并可以找出对现有测试用例进行自动化测试的可行性。在此阶段，我们执行以下活动：

• 识别可以和不能自动化的测试用例
• 确定可以使用自动化测试进行全面测试的模块
• 确定用于自动化测试的资源

一旦我们定义了自动化测试的范围，我们就可以进入下一阶段。

选择正确的工具

在这个阶段，我们确定了可以用于自动化测试的正确工具。此活动对于自动化测试至关重要，因为此测试依赖于自动化测试工具，因此我们需要根据需求找到正确的工具。在寻找工具的同时，如果我们计划使用付费工具，我们需要保持我们的技术技能和成本。由于我们正在讨论Dynamics365CE的测试选项，因此让我们讨论Dynamics365CE的一些自动化测试工具。

EasyRepro

这是Microsoft为Dynamics 365 CE UI自动化测试提供的开源框架。此框架提供对Dynamics 365 CE版本8.2至9.1的支持。此框架可从https://github.com/microsoft/EasyRepro并且包含以下Dynamics 365 CE统一界面（UI）和web客户端的示例。

我们可以使用这个框架的API进行快速UI测试。这些API包含我们在日常工作中使用的核心Dynamics 365 CE命令。例如，下面是GitHub的一个示例测试，用于通过设置name、telephone1和websiteurl字段来创建帐户实体记录。在这个示例测试中，我们可以看到它获取了连接Dynamics 365 CE所需的凭据，然后从Sales区域导航到Accounts子区域并创建帐户记录：

您可以在GitHub上找到有关此框架的更多详细信息。

除此之外，还有一些可供开发人员用于单元测试的自动化测试工具。让我们讨论一些可用的工具。

FakeXrmEasy.365

这是一个开源框架，是为单元测试Dynamics365CE代码而开发的。从Dynamics CRM 2011到Dynamics 365 CE，我们可以使用FakeXrmEasy对我们的代码进行单元测试。这个框架最好的部分是它提供了mock对象，这样我们就可以连接Dynamics365CE。例如，它提供IOOrganizationService的mock对象和内存中的插件上下文。运行单元测试变得简单快捷，因为它不与实际的Dynamics365CE服务对象连接。

例如，我们可以简单地使用以下行来获取我们的服务和插件上下文对象：

var context = new XrmFakedContext();
var PlugCtx = context.GetDefaultPluginContext();
var service = context.GetFakedOrganizationService();

开发人员可以在VisualStudio中开发他们的单元测试，并在需要时运行它们。您可以访问Dynamics Value 

您可以从GitHub下载FakeXrmEasy，网址为

https://github.com/jordimontana82/fake-xrm-easy

xrm-ci-framework

这是另一个可以帮助您自动化Dynamics 365 CE解决方案测试和部署的工具。它使用DevOps管道，这使您可以轻松地部署Dynamics 365 CE解决方案更加频繁，具有更高的一致性和质量。

您可以从下载此工具 
GitHub - WaelHamze/xrm-ci-framework: xRM CI Framework provides you with the tools automate the build and deployment of your CRM Solution. Using the framework to implement a fully automated DevOps pipeline will allow you to deploy more frequently with added consistency and quality.
 

Moq

另一个可用于Dynamics365CE的单元测试框架是Moq。该框架还提供了一个模拟对象，我们可以使用该对象连接到Dynamics365CE服务对象并执行单元测试。例如，要设置服务对象，我们可以使用以下语句：

var Dynamics365serviceMock = new Mock<IOrganizationService>();
IOrganizationService OrgService = Dynamics365serviceMock.Object;

在前面的代码中，我们正在创建一个Mock类型的对象，它可以像Dynamics365CE的组织服务一样工作，我们在第7章“扩展Dynamics365 CE”中了解到了这一点。我们可以使用此对象来执行组织服务操作。

您可以从下载并获取有关Moq的更多详细信息

https://github.com/moq/moq

准备测试

一旦确定了自动化测试工具，我们就可以为测试做准备。在这个阶段，将执行不同的活动，例如准备和设置测试环境；为测试脚本的创建准备了指导方针；根据开发的模块为测试数据编制指南；最后，为缺陷记录和报告制定了指导方针。负责的团队开始根据新系统的功能或模块准备测试用例。

执行测试脚本

在此阶段，将执行测试脚本。在早期阶段准备的测试脚本将被执行，并以测试环境的设置为目标。如果测试脚本针对多个环境和平台，则可以执行测试脚本，以确保我们的新系统与客户使用的所有环境或平台兼容。在执行测试脚本时，所有错误都会被收集并报告给开发团队。

报告

这是测试生命周期的最后阶段。在这个阶段，团队致力于收集基于模块报告的所有错误的报告。错误报告是根据模块编写的，以确定哪个模块报告的错误数量更多。报告编制完成后，将与所有相关团队共享，如开发团队和利益相关者。

这就是我们在系统上执行自动化测试的方式。到目前为止，我们已经了解了手动和自动测试中涉及的高级步骤。现在，我们将讨论如何执行用户接受测试。

进行UAT

用户验收测试（UAT）是在测试团队确认系统无缺陷后进行的。测试人员是技术资源，他们根据需求的规范文档来验证新系统。他们根据对Dynamics 365 CE的了解来解释这些要求。但在UAT中，用户进行测试以确保系统根据他们的需求工作。UAT的结果是用户对开发的Dynamics365CE解决方案的认可。在UAT中，对端到端业务流程进行测试，以确保系统基于客户的期望。UAT基本上是由非常了解该系统并使用该系统执行日常活动的关键用户执行的。准备一个类似于生产环境的单独环境，该环境具有类似于生产数据的样本数据。下图向我们展示了在任何项目中进行UAT的情况，并强调了与其他阶段相比，UAT的权重要大得多：

一旦进行了UAT，客户将对最终结果进行分析，以准备UAT的结果。UAT过程让客户有机会了解最终系统将如何运行。他们可能意识到，在进行UAT后，他们需要添加一些新功能，这通常在增强阶段完成。

为什么UAT很重要

UAT是任何项目的一个重要阶段，因为执行多少功能和单元测试并不重要——当使用真实的业务数据和实际的最终用户进行测试时，系统的行为可能仍然不同。以下是我们应该执行UAT的关键原因：

• 它提供了在最终用户使用系统之前验证功能测试用例的机会。
• 它提供了在早期发现问题并加以解决的最佳机会。
• 它有助于根据客户的反馈提高系统的质量。
• 由于UAT是由最终用户和客户端完成的，它验证新系统是否是基于客户端规范开发的。
• 它有助于我们在系统准备生产之前从客户那里获得最终确认。

要进行UAT，应采取以下步骤：

1. 计划和准备UAT检查表：第一步是计划UAT活动，准备UAT清单有助于我们保持专注。为了使UAT成功，我们可以遵循此检查表。该清单应包括我们将在UAT阶段执行的所有任务。这有助于我们了解哪些任务已完成，哪些任务未完成。
2. 定义验收标准：在进行UAT之前，准备验收标准非常重要。UAT接受标准可能只包括关键的业务流程，因为在UAT阶段再次测试完整的应用程序是不现实的。项目经理应与客户合作，确定关键业务需求并确定其优先级。所有验收标准都应记录在案，以便UAT签字。
3. 识别关键用户：UAT由关键用户执行，包括不同类型的用户，如管理员用户，也称为超级用户；高管；管理者；以及团队成员。在UAT开始之前，从客户那里获得用户列表以设置他们的用户是很重要的。在设置用户后，我们还需要根据他们的工作档案设置他们的安全角色，以确保他们能够访问与其日常职责相关的区域。
4. 设置UAT环境：另一项重要任务是设置UAT的环境。在单独的环境中进行UAT是很重要的，该环境应类似于生产环境。它可能包含历史数据的副本（如果有的话），或者应该有最终用户可以执行测试的示例业务数据。
5. 培训关键用户：这是我们应该培训关键用户和利益相关者的另一个重要步骤，以便他们熟悉新系统。他们可能使用具有不同导航的旧系统，因此在新系统中，他们应该了解新导航，以便访问他们的工作区域。
6. 在UAT期间协助关键用户：尽管我们将为关键用户提供培训，但在UAT阶段协助他们是很重要的。可以指派一个功能顾问团队来帮助关键用户。这有助于我们在约定的时间内完成UAT。
7. 倾听关键用户：在UAT阶段，倾听关键用户的关于新系统的反馈。这有助于提高系统的可用性，因为关键用户可能会建议对UI进行一些更改，以使他们对新系统更满意。
8. 错误报告程序：在UAT开始之前，我们应该定义UAT错误报告程序，以便所有UAT成员都知道报告UAT期间发生的任何错误的程序。稍后，应该收集这些bug，这有助于我们确定当前产品是否准备好进行生产发布。
9. UAT签字：一旦UAT结束，我们应该从UAT团队获得UAT签字。UAT签字确认产品是否已准备好用于生产。

这就是我们为应用程序或产品执行UAT的方式。现在，让我们学习如何准备用户培训计划。

准备最终用户培训计划

任何Dynamics365CE项目的成功实施取决于最终用户对新系统的了解程度。最终用户培训是Dynamics 365 CE成功实施的关键之一。最终用户培训使用户在生产中使用Dynamics365CE时更加舒适。他们在日常活动中使用Dynamics 365 CE的次数越多，Dynamics 365 CE实施就越成功。Dynamics 365 CE实施失败的最常见原因是没有在日常活动中使用Dynamics 365 CE应用程序，这可能是由于多种原因造成的，例如缺乏适当的培训、应用程序运行缓慢或性能问题。我们将在下一节中更详细地讨论用户培训。

为什么我们需要最终用户培训

组织中Dynamics 365 CE的新实施对大多数最终用户来说可能是一个巨大的变化，因为他们以前可能使用过不同的CRM系统或使用过早期版本的Dynamics CRM。可能很难适应Dynamics 365 CE的新变化。根据客户以前使用的版本，他们可能会在Dynamics 365 CE中看到不同的UI、新的命令按钮和新功能。Dynamics 365 CE最终用户培训可帮助用户了解为什么以及如何使用新的Dynamics 365 CE功能来执行日常活动。

有时，组织会跳过最终用户培训，从而导致Dynamics 365 CE用户采用失败。最终用户培训可以真正帮助Dynamics 365 CE的实施，并确保输出的最大效率。最终用户培训可以由咨询公司或客户自己聘请的专业培训师进行。在为Dynamics 365 CE实施计划最终用户培训时，重要的是要确定最终用户的日常活动，以便最终用户培训可以相应地包括主题。最终用户培训还应包括客户业务流程的实际示例，因为它可以帮助最终用户了解Dynamics 365 CE如何融入其业务流程。

最终用户培训的好处

以下是最终用户培训的好处：

• 最终用户在使用该系统之前就已经非常了解该系统，因此可以提高工作效率；他们不知道某些功能的可能性较小。
• 在培训过程中，他们了解新的Dynamics 365 CE实施的目的，因此它可以通过使用新的Dynamics 365CE功能帮助他们高效工作。
• 提高了最终用户的生产力和效率，从而实现了Dynamics 365 CE的投资回报。
• 最终用户培训提高了用户采用率。
• 错误数据输入系统的可能性较小。

既然我们知道了终端用户培训的优势，那么让我们讨论一下如何进行终端用户培训，以及我们需要执行的主要步骤。

进行最终用户培训

要进行最终用户培训，我们可以按照以下屏幕截图中的最终用户培训步骤进行。这通常从了解用户开始，到捕捉最终用户反馈结束：

1. 了解用户：在进行最终用户培训之前，了解最终用户非常重要。我们应该知道我们要培训谁，他们的技术能力是什么。他们是否已经了解Dynamics 365 CE或早期Dynamics CRM版本？每个组织都有不同类型的用户；例如，我们可能有用户将只在某些任务中使用新的Dynamics 365 CE，例如生成报告和查看客户数据，或者有用户将广泛使用Dynamics 365 CE。但重要的是要理解，每个用户都需要根据自己的工作情况进行培训和支持。
2. 时间表和成本：在进行最终用户培训之前，我们需要确定培训时间表和预算。在进行培训时，我们需要确保所有培训课程都在培训计划内完成。事先与客户分享培训时间表也很重要，以确保他们能够做出所有必要的安排。
3. 设定培训目标：在进行最终用户培训之前，首先设定培训目标非常重要。最终用户培训的主要目标是提高最终用户的效率。在制定培训目标时，我们需要牢记最终用户的需求。例如，对于服务部门，我们可能需要设定与销售部门不同的目标——培训目标不同。
4. 选择培训师：最终用户培训应由熟悉Dynamics 365 CE应用程序的认证Dynamics 365 CE培训师进行。他们应该了解实施Dynamics 365 CE的客户目标。
5. 定制培训：除了通用的Dynamics365CE培训外，培训师还应通过样本实验室练习为用户准备定制培训。可能有来自不同部门的不同用户担任不同的角色，因此我们需要确保根据组织中所有可能的角色来准备培训。
6. 捕获反馈：在进行培训时，我们应该始终捕获用户的反馈。这可以在训练期间完成，也可以在训练结束后捕捉。它有助于我们了解用户对新Dynamics 365 CE的兴趣，以及他们在培训课程中的体验。

在这里，我们讨论了制定最终用户培训计划所需的主要步骤。前面的所有步骤都非常重要，无论是了解最终用户还是在培训后获取反馈。了解用户使我们有机会根据他们的需求高效地进行培训，而获取反馈有助于我们跟踪培训的有效性。现在，让我们讨论Dynamics365CE培训的一些来源。

Dynamics 365 CE培训参考资料

在本节中，我们将讨论Dynamics365CE培训，所以让我们谈谈我们可以用于此培训的参考资料。

Dynamics 365 CE SDK

了解Dynamics 365 CE的一个流行且免费的地方是Dynamics 365 CE SDK，它可以在线获得。我们可以从访问Dynamics 365 CE的所有文档 Dynamics 365 文档 | Microsoft Learn，就像这样：

本文档提供了有关Dynamics 365 CE的所有详细信息。如前面的屏幕截图所示，我们可以看到不同的导航选项来获取有关Dynamics365CE的详细信息。我们可以在what's new部分看到最近发布的内容；我们可以在您的部署FastTrack下看到Dynamics 365 CE开发的最佳实践；我们可以在这个页面上找到微软的电子学习课程。

导航到Dynamics 365 on Microsoft Learn | Microsoft Learn针对Dynamics 365的不同学习路径。

Dynamics学习门户

如果您是Microsoft合作伙伴或365人才门户的成员，则可以访问Microsoft Dynamics学习门户。在这里，您可以获得Dynamics 365 CE考试的培训材料和大量电子学习资源。您可以访问Dynamics学习门户，网址为https://mbspartner.microsoft.com/

如前面的屏幕截图所示，我们为Dynamics 365的所有应用程序提供了培训选项。

Microsoft培训合作伙伴

Microsoft培训合作伙伴是与Microsoft合作为Dynamics 365 CE提供培训的培训公司。我们可以通过导航到 Find a Learning Partner | Microsoft Learn

除了前面的培训来源，还有其他可用的来源，如YouTube的Dynamics 365 CE频道、Dynamics 365 CE团队和Dynamics 365 CE社区博客。

总结

在本章中，我们了解了有关测试Dynamics365CE应用程序的信息。我们讨论了如何创建测试计划，以及我们应该在测试计划文档中包含哪些部分。
然后，我们讨论了手动和自动测试方法。我们还了解了为什么UAT对Dynamics365CE的实现很重要，以及如何执行UAT。最后，我们讨论了如何为Dynamics365CE实施进行最终用户培训。

在下一章中，我们将讨论从早期版本的Dynamics CRM升级到Dynamics 365 CE时可以遵循的不同路径，以及如何将现有数据迁移到Dynamics 365 CE。