简介
在设计系统后，解决方案架构师仍需要继续工作。 他们的下一个任务是确保系统由实际用户部署和使用。
测试和上线中的解决方案架构师角色
通常，解决方案架构师是最了解解决方案工作方式，并能指导测试团队对该解决方案进行测试的人员之一。
解决方案架构师在测试中具有关键角色，他们应做到以下几点：
- 一直参与直到测试结束，以确保成功。
- 帮助对测试团队就解决方案体系结构进行培训，以确保他们充分测试所有组件和集成。
- 会审在测试和试运行期间以及上线后出现的复杂问题。
- 与上线团队一起规划和实施上线策略。
测试概述
适当测试对于确保项目成功至关重要。
注意
测试必须是一项持续工作，从构建第一个组件一直持续到上线；不能是一次性的大规模演练。
测试不仅仅是将要求映射到功能的过程。 虽然构建和实施这些类型的测试很重要，但还应测试解决方案的更多方面。 无论要测试的具体指标是什么，流程都相似。
测试流程包括以下步骤：
规划 - 审查总体测试策略，制定测试计划，并对基准指标执行所需的分析。 确定范围内和范围外的关键业务场景。 记录要求（如果该步骤尚未完成）。
准备 - 设置性能测试和用户验收测试等所需的环境。 在执行迁移测试之前和之后，检查收到的要迁移的数据。 验证高级系统要求，然后开发所需的脚本。
执行 - 运行测试脚本，分析结果，识别潜在的瓶颈，然后检查失败和行为。
报告 - 准备对报告计划、结果和行动计划的详细评估。
测试类型
解决方案架构师应参与有关项目所需测试的数量和类型的讨论。
Microsoft Power Platform 中的常见测试类型包括：
单元测试 - 由应用构建者、业务分析师、功能顾问或开发人员执行。
功能测试 - 验证实现是否满足要求。
验收测试 - 由用户执行以期获得正式批准。
回归测试 - 测试未更改的功能以检测回归问题，通常每次进行系统更新时都会执行这些测试。
集成测试 - 目标是让所有集成的系统协调工作。 集成测试验证包括来自其他来源的集成服务和数据在内的各个部分是否都能协同工作。
性能测试 - 这些测试使用预期的峰值负载和峰值事务量进行验证，通常自动执行，并在上线之前运行。
迁移测试 - 实践数据迁移以确保数据质量。 这些测试与了解客户数据的主题专家密切协商执行。 这些专家应该了解数据转移和转换，并能够在适当的上下文中确认迁移的数据是有效的。
灾难恢复测试 - 如果灾难恢复计划不起作用，则是无用的。
上线测试 - 完整解决方案和上线流程的试运行。 这些测试通常在上线之前执行。
并非所有类型的测试都是必需的；这由项目的规模和范围决定。
单元测试
可以使用单元测试来检查应用的特定功能或特性是否正常工作。 单元测试通常由应用制作者和开发人员执行。 每个团队成员都应在交接前检查自己的工作。
建议执行单元测试，但并非必需。 如果是刚开始，或者解决方案中的代码数量相对减少，您可能会发现，用在编写测试上的时间多于用在创建解决方案中包含的功能上的时间。 当解决方案变得更大、更复杂时，单元测试的好处将开始增多，特别是对于服务器端开发，您可能会发现，通过将模拟数据或虚设数据与测试框架一起使用在本地进行调试将带来显著的好处。
可以对所有应用、业务规则和插件进行手动测试。有些测试可以使用 Microsoft Power Apps Studio 和 Visual Studio 自动执行。 服务器端开发的常用单元测试框架是 Fake Xrm Easy。
解决方案架构师应确定将用于单元测试的工具，以及应使用的自动化级别。
集成测试
解决方案架构师需要帮助测试团队了解如何测试集成组件。
Microsoft Power Platform 的其中一个优点是其强大的集成功能。 集成是业务流程实现的最重要方面之一，因为它可确保实现正常运行并且对整体采用具有很强的影响。
解决方案架构师和客户应评审涉及与其他业务线应用程序集成的测试方案，以确保创建端到端测试方案。 本评审可能要求客户计划为他们其他的应用程序设置测试环境。
每项集成可能具有各自的测试方法，需要加以定义。 测试团队应该尽早参与进来，以确定他们将如何测试每个集成方案。 团队需要确保必要的集成能够配置为支持测试。
集成测试的一个关键方面应侧重于流入和流出集成的数据。 数据验证测试一节中的大部分论述也适用于集成中涉及的数据。
由于集成测试可能涉及其他系统，因此需要确保将测试环境用于所有组件。 您不希望集成测试与实时系统通信，然后意外修改生产数据。 有时，测试方案会在应用程序集成中驱动配置选项，使其可测试。 能够禁用集成可以帮助您在不调用集成的情况下进行测试。
构建集成的流程现在更加易于完成，因此项目团队中的更多人更容易参与进来。 通常，集成可能会在 Power Apps 画布应用程序或 Microsoft Power Automate 流中隐藏起来。 由于应用程序使用来自其他源的表面连接器，因此人们经常不会发现这些隐藏的集成。 计划应将这些集成视为与任何其他集成一样，然后相应地测试它们。
用户验收测试
用户验收测试 (UAT) 由用户执行以期获得正式批准，并测试系统的可用性。 验收测试通常在推出功能之前作为最终检查进行。 本测试旨在确保制作者已构建的内容与用户最初请求的需求匹配。
有关从 UAT 获得良好结果的提示：
- 使用实际用户进行测试。
- 选择具有多种 IT 技能级别的用户。 这样，您可以获取不同的反馈。
- 不要向用户提供说明；看看他们能否直观地了解该应用。
- 观察用户在无辅助的情况下如何在应用中导航，然后确定设计可改进的方面。
- 当用户在某个屏幕上止步不前时，请求他们解释他们的期望。
- 试验不同的设备，以确保测试用例的行为相似。
- 理想情况下，如果应用使用脱机功能，请在用户的实际环境或位置中测试该应用。
- 请求用户尝试“破坏”应用，例如在文本列中输入异常字符。
- 用户通常会测试“正常路径”（用户在一切正常时所采用的路径）。 请求用户测试其他方案，例如取消而不提交支出报表，或拒绝而不批准支出报表。
用户可能不熟悉测试软件。 告知他们您想要获取的反馈类型。 为 Bug 提供模板通常很有帮助，可确保测试人员确切地说明他们做了什么、实际发生的情况、他们期望发生的情况，以及有关其测试环境的相关信息（例如设备类型和浏览器）。
需要由解决方案架构师帮助会审用户在测试期间引发的问题。
安全测试
安全测试对于确保应用程序的安全性以及遵守法规要求很重要。 本测试应包括漏洞评估，以确保应用程序是安全的。 它还应包括在不同类型的用户的安全上下文中进行测试，以确保相应级别的数据和功能可用。
安全测试还应查看应用程序内的安全模型，以访问其数据和功能。 测试应包括具有不同角色和访问特征的不同用户的方案，以确保安全模型能够保持成功。 安全模型测试应确保不会发生过度共享或共享不足。 完成安全模型测试的一种方法是为每个主要角色集创建专用的测试用户帐户。
解决方案架构师应帮助定义要执行的安全测试级别。