Power BI 实施规划：验证内容
注意
本文是 Power BI 实现规划系列文章中的一篇。 本系列着重介绍 Microsoft Fabric 中的 Power BI 体验。 有关该系列的介绍，请参阅 Power BI 实施规划。
本文帮助你在管理内容生命周期的过程中验证内容。 主要面向以下对象：
- 卓越中心 (COE) 和 BI 团队：负责在组织中监督 Power BI 的团队。 这些团队包括决定如何管理 Power BI 内容的生命周期的决策者。 这些团队还可能包括处理内容发布生命周期的发布管理员，以及创建和管理有效使用和支持生命周期管理所需组件的工程师。
- 内容创建者和内容所有者：创建内容的用户，他们希望将内容发布到 Fabric 门户以与他人共享。 这些人员负责管理其创建的 Power BI 内容的生命周期。
生命周期管理包括用于处理内容创建到最终停用的过程和做法。 在生命周期管理的第二阶段，你将开发内容并管理变更，其中涉及到有关如何开发内容以及设置工作区和版本控制的关键决策。 在第三阶段，你将验证内容以测试其是否已准备好部署。
注意
通常你会在连续的开发和验证周期中迭代执行第二阶段和第三阶段。
验证内容对于确保解决方案的质量和可信度至关重要。 因此，在将内容更改部署到生产环境之前测试内容更改至关重要。
下图描绘了 Power BI 内容的生命周期，突出显示了第三阶段，你将在此阶段验证内容。
注意
有关内容生命周期管理的概述，请参阅本系列的第一篇文章。
本文重点介绍有关在整个内容生命周期中验证内容的关键注意事项和决策。 有关如何验证内容的详细指南，请参阅：
- 迁移到 Power BI：验证内容：此文介绍了从其他技术迁移到 Power BI 时进行验证的关键注意事项和决策。
- BI 解决方案规划：验证内容：此文介绍了在规划 Power BI 或 Fabric 解决方案时如何规划迭代开发和验证周期。
验证内容涉及到做出具体决策或采取具体措施来确保内容按预期执行。
验证内容时，将会评估解决方案的不同方面。
- 功能：构成解决方案的项和功能是否有效。 测试功能的一个示例是语义模型是否可以完成计划的刷新。
- 数据准确度：显示的数据和结果是否完整且符合业务预期。 测试数据准确度的一个示例是报表中的值是否与已知基线一致。
- 性能：查询是否对可用用户资源或用户等待时间造成轻微的影响。 测试性能的一个示例是数据流是否能够可靠地刷新，而不会达到超时或经历很长的刷新持续时间。
- 安全性：是否限制未经授权的个人查看或访问信息或整个解决方案。 测试安全性的一个示例是在验证行级安全性 (RLS) 时模拟用户或角色。
- 有效性：解决方案是否可以解决相关的业务问题或流程，并充分支持预期的业务目标。 测试有效性的一个示例是在执行用户验收测试 (UAT) 时收集用户反馈。
- 辅助功能：解决方案是否符合已知的辅助功能标准，以便尽可能多的人能够使用它。 辅助功能测试的一个示例是检查报表是否符合 Microsoft 报表辅助功能清单。
可以通过执行不同类型的测试来验证内容。 以下部分描述了有关内容创建者和内容使用者如何执行测试的决策的关键注意事项。
注意
许多团队使用源自软件开发的测试方法，例如单元测试、集成测试和冒烟测试。 还有许多同样有效的内容测试和验证方法。 最重要的是，需要使用最适合需求和团队工作方式的方法来测试内容。
确定创建者应如何验证内容
内容创建者应验证他们自己对内容的更改，以确保所做的更改符合质量和功能要求。 测试通常在开发工作区中进行，其中包含解决方案的最新工作版本。 内容创建者在将内容部署到测试工作区以供用户验证之前测试自己的更改。
注意
内容创建者在将自己的内容提供给用户之前必须验证其内容。 如果向测试用户提供明显有问题的解决方案，则会削弱他们对该解决方案的信任。 即使在测试时，用户也希望看到最终产品的合理表现。 此外，功能性解决方案能使用户专注于识别与其业务领域相关的问题。
内容创建者可以通过两种方式验证内容。
- 手动测试：手动测试涉及到通过主观评估或与某些客观测试标准进行比较来手动验证内容。 手动测试很容易执行，但也容易出现人为错误或偏见。 此外，当内容达到一定规模时，正确执行手动测试可能会变得困难。 可以通过两种方式进行手动测试。
- 独立评审，这涉及到测试你自己的内容，例如语义模型和报表。
- 同事评审，这涉及到对内容进行主观评估，以批判性地评价解决方案并提供改进建议。
- 自动测试：自动测试涉及到预先准备的测试，无需人工干预即可自动评估。 通常，自动测试会根据特定基准或基线检查部分解决方案代码。 自动测试更难执行，并且需要花费时间和精力来完成设置。 不过，自动测试在企业方案中至关重要，可以确保大型实现和业务关键型解决方案的质量和可信度。
以下部分介绍了内容创建者执行手动测试、自动测试和同事评审的不同方式。
执行手动测试
你应该自行对创建的内容执行手动测试。 这些测试应确保更改符合预期并达到所需的质量标准。 通常，手动测试涉及到对内容或特定内容更改的使用和主观评估，以及描述和记录结果。
下面是测试你自己的内容时的一些注意事项。
- 预先确定并记录测试条件和成功标准。
- 全面测试并记录测试结果。 但是，请确保避免多余的测试，这样测试实践就不会减慢开发速度。
- 为每个项的类型创建一组标准测试以提高可重复性。
- 记录测试结果和结论。
- 多次测试，以确保测试结果最好地反映现实而不是随机几率。
- 使用可代表生产环境的测试条件。
以下部分描述了有关手动测试的其他关键注意事项。
手动测试语义模型
语义模型是 Fabric 和 Power BI 解决方案的重要组成部分，因为它们是报表、仪表板以及其他客户端工具和 Fabric 工作负载的上游源。 因此，在部署之前验证语义模型非常重要。
回答以下问题可帮助你验证语义模型。
- 表中是否包含意外缺失、重复或不正确的值？
- DAX 度量是否在查询时间不长的情况下返回预期结果？
- 计划的刷新是否可以在刷新时间不长的情况下成功完成？
- 是否在视觉对象、筛选器或查询结果中观察到因引用完整性违规而导致的（空白）结果？
- 数据安全性（例如 RLS 或对象级安全性 (OLS)）是否足以防止未经授权的个人访问模型或其数据？
- 模型对象（例如 DAX 度量或表列）是否已组织到显示文件夹中？
可以借助不同的工具和方法来验证语义模型。
- Power BI Desktop：Power BI Desktop 允许使用各种功能来验证语义模型的不同方面。 有助于测试语义模型的 Power BI Desktop 功能示例包括：
- 视觉对象画布：通过拖放视觉对象测试模型功能和准确度。
- DAX 查询视图：测试模型准确度，以及可以保存并供以后重用的包含 DAX 查询的 DAX 代码。
- 查询诊断：通过获取有关如何在 Power Query 中评估查询的诊断信息来测试刷新性能。
- Fabric：使用 Fabric 门户中的功能和项，可以在将语义模型部署到工作区后对其进行各方面的验证。
- 安全性：通过模拟安全角色或用户来测试模型安全性。
- 笔记本：使用语义链接测试模型功能和准确度。
- 监视中心：测试和监视语义模型和其他 Fabric 数据项的数据刷新。
- 第三方工具：使用第三方工具可以通过提供更多详细信息或其他有助于验证的功能来验证语义模型的其他方面。 有助于测试语义模型的第三方工具示例包括：
- DAX Studio：通过接收 DAX 查询计时和查询计划的明细来测试和优化 DAX 代码的性能。
- 表格编辑器：通过接收有关如何评估 DAX 查询以及哪些评估上下文处于活动状态的详细信息来测试和调试 DAX 代码的准确度。
提示
可以使用查询诊断从使用 Power Query 的其他项（例如数据流）手动验证和优化 Power Query 的性能。
此外，可以使用 DAX 查询视图和第三方工具（例如 DAX Studio）来验证和优化分页报表与记分卡的 DAX 查询。
手动测试报表
报表是用户与数据交互的常用方式。 许多用户依赖于报表来做出决策并采取措施，以实现其业务目标。 因此，在部署之前验证报表非常重要。
回答以下问题可帮助你验证报表。
- 报表是否满足记录的业务要求？
- 是否使用了正确的视觉对象类型来解决正确的问题？
- 报表页是否清晰简洁，没有过多的色彩或过多的视觉对象？
- 当筛选为一小部分数据时，报表是否按预期运行？
- 报表是否允许导出到 Excel，如果可以，是否允许检索汇总数据或基础数据？
- 报表是否可用于跨报表钻取或视觉对象个性化？
可以借助不同的工具和方法来验证报表。
- Power BI Desktop：Power BI Desktop 允许使用各种功能来验证报表的不同方面。 有助于测试报表的 Power BI Desktop 功能示例包括：
- 视觉对象画布：使用切片器、筛选器和其他交互式元素测试报表功能。
- 性能分析器：通过度量视觉对象呈现和 DAX 查询时间来测试报表性能。 可以从性能分析器中复制视觉对象 DAX 查询以在其他工具中使用，并保存性能结果以便生成文档记录。
- 查询限制模拟：通过在用于部署报表的容量中模拟内存限制来测试报表性能。
- Fabric：使用 Fabric 门户中的功能和项，可以在将报表部署到工作区后对其进行各方面的验证。
- 更新应用：在 Power BI 应用中分发报表以及设置不同的应用受众以确定谁可以查看哪些内容时，测试报表功能和安全性。 使用应用受众时，可以预览他们有权访问哪些报表，并自行测试应用体验。
- 阅读工作区或应用中的视图：通过在与用户相同的环境中使用报表来测试报表的功能和准确度。
注意
只能在 Fabric 门户中开发和验证仪表板。
重要
在 Power BI Desktop 中以及在 Fabric 门户中部署后测试报表至关重要。 与 Fabric 工作区中的报表相比，视觉对象呈现在本地计算机上的行为可能有所不同。 此外请注意，从工作区或应用使用报表的用户体验与在 Power BI Desktop 中使用报表的用户体验有很大不同。
通过执行同事评审进行手动测试
手动验证内容的另一种方式是执行同事评审。 在同事评审中，内容创建者将解决方案或解决方案的一部分提供给同事进行评估。 同事评审的目的是通过利用多个内容创建者的集体经验和专业知识来改进解决方案。 可以在手动和自动测试期间和之后执行同事评审。
注意
同事评审是许多行业使用的标准方法。 众所周知，此方法可以提高内容、产品和流程的质量。
提示
如果你是解决方案的唯一内容创建者，请考虑在其他团队中找到另一位内容创建者来评审你的解决方案，并主动为他们做同样的事情。
可以通过多种方式执行同事评审。
- 功能评审：功能评审侧重于解决方案应满足的功能、流程或业务要求。 在功能评审中，评审人员像最终用户一样使用解决方案。 他们会记录他们发现的任何缺陷或问题，同时记录任何主观评论，以改进实现。
- 技术评审：技术评审侧重于解决方案的技术方面，例如数据建模、代码或设计。 在技术评审中，评审人员评估某些功能或更改的实现方式，并提出替代方法或强调当前方法的潜在缺陷或风险。
- 拉取请求：执行源代码管理时，你将创建一个拉取请求 (PR)，以将更改合并到最新版本的解决方案。 技术所有者将评审提议的更改并评估源代码。 这种评审对于确保代码遵守标准约定非常有用，例如设置 DAX 或 M 代码的格式，或者识别反模式或可能有问题的代码。
提示
我们建议在内容更改进入用户验收测试阶段之前执行某种正式的同事评审和审批。 这是因为，即使在测试期间，劣质内容也会损害用户对你的数据解决方案的信任。 此外，同事评审还可以促进团队成员之间的协作和知识分享。
完成同事评审周期后，应该记录并整合任何建议的更改。 如有必要，应在进入用户测试阶段之前重新提交更改以供审批。 通常，仅当有许多更改或需要测试一些复杂更改时，才需要多次迭代执行同事评审。
自动测试
内容创建者可以将测试自动化，以便在部署之前自动执行测试。 自动测试通常涉及到预先准备的测试条件，这些测试条件以编程方式运行和协调以响应特定的操作，例如保存内容或提交拉取请求 (PR)。 自动测试的结果会自动存储供以后参考和记录。
自动测试的目的是减少验证内容更改所需的时间和精力，同时提高测试一致性及其结果的可靠性。 当内容通不过自动测试时，通常会阻止其部署，直到内容创建者解决问题为止。
有效的自动测试是实现 DataOps 的关键条件。 DevOps 允许团队通过采用改进和加速数据交付与分析的做法来自动化和缩放流程。
重要
为了有效地自动执行测试，应该创建精心设计的测试。 创建此类测试可能需要付出大量时间和精力。 如果测试条件和期望的定义不完善，自动测试将无法验证内容的正确方面，并且自动化这些测试对你几乎没有好处。
提示
与企业内容发布方案中的解决方案部署集成后，自动测试可以发挥最大的作用。 例如，可以使用 Azure Pipelines 作为验证管道的一部分来自动执行测试，以确保内容做好部署准备。 有关详细信息，请参阅第 4 阶段：部署内容。
以下部分描述有关自动测试 Power BI 语义模型和报表的关键注意事项。
自动测试语义模型
自动测试语义模型是可以做到的，不过，它通常需要使用第三方工具和框架进行自定义设置。
可以使用不同的工具和方法来自动测试语义模型。
- 最佳做法分析器 (BPA)：最佳做法分析器允许指定可用于评估语义模型的规则。 可以使用表格编辑器运行 BPA，这样可以识别语义模型中的任何违规情况。 可以将表格编辑器命令行接口 (CLI) 与 Azure DevOps 配合使用，或者用作另一个计划流程的一部分，以自动检查 BPA 违规情况。
- 构造笔记本和语义链接：Fabric 中的笔记本允许你使用语义链接以编程方式与语义模型交互。 可以使用笔记本运行 Great Expectations (GX) 等框架来验证数据。 此外，还可以评估度量和 DAX 查询，然后根据已知基线测试结果。
- Power Automate：Power Automate 允许你对语义模型运行查询，并使用 Power BI REST API 导出报表。 可以根据已知基线检查查询结果，然后执行下游操作，例如向内容所有者触发警报。
提示
考虑将语义模型的自动测试和协调相结合。 例如，可以在刷新之前使用笔记本或 Power Automate 对数据源和语义模型执行自动测试。 如果测试失败，可以阻止刷新，这也可以防止出现刷新错误或者不正确的数据进入业务报表。
自动测试报表
可用于自动测试报表的选项有限。 这些选项依赖外部工具或社区解决方案来自动验证视觉对象或报表属性，例如验证报表元数据或模拟用户与报表的交互。
可以使用不同的工具和方法来自动测试报表。
- 报表最佳做法分析器：有多种第三方工具支持类似于最佳做法分析器的功能，它们可以通过检查报表定义来自动检测报表中的问题。 支持此功能的两个工具是 PBI Explorer 和 PBI Inspector。
- Power Automate Desktop：Selenium for Python 或 Power Automate Desktop 等 UI 自动化工具允许模拟用户鼠标与报表的交互。 通过定义用户流，可以测试导航和交互。 在能够完成流时会通过这些测试，而在检测到屏幕上的特定文本或图像（例如错误消息或空白视觉对象）时，这些测试会失败。
确定用户应如何验证内容
内容通过手动测试、自动测试和同事评审后，可以继续执行用户测试。 当用户测试内容时，他们会提供有关该内容是否满足业务要求并达到他们的期望（包括返回准确的结果）的主观反馈。
用户验证通常发生在测试工作区中。 设置测试工作区时，请注意以下事项。
- 创建测试应用：如果你打算使用 Power BI 应用分发内容，请为测试用户设置一个测试应用以验证内容。 测试应用应该与你要在生产环境中设置的应用相同。 在测试应用的导航栏中，考虑包含文档、培训和反馈表单的链接。
- 预配访问权限：在社区中找到一部分愿意验证该解决方案的用户。 与这些用户联系，并就他们何时以及为何验证此内容达成一致。 然后，确保为他们提供对内容的访问权限，并为他们添加适当的安全角色。 与用户共享内容或测试应用的链接，以便他们可以开始测试。
- 设置计划的刷新：用户验证通常会持续较长时间。 在测试工作区中设置数据项的计划刷新是值得的，以便用户可以使用最新数据进行测试。
重要
将内容部署到测试工作区时，需要手动更新应用，然后用户才能看到报表和仪表板的更改。
注意
无法将应用从一个工作区部署或复制到另一个工作区。 对应用进行任何更改都必须在该工作区的配置中手动进行。
在开始执行用户验证之前，应该完成必要的准备。
- 规划何时进行用户验证。
- 指定用户验证是否局限于特定时段或迭代过程的一部分。
- 创建收集反馈的方法，例如使用 Microsoft Forms。
- 与参与验证的用户沟通规划和期望事宜。
- 对用户验证的开启活动进行组织规划，以指导用户并管理期望。
- 为用户提供培训以演示验证和反馈流程。
下面是一些有助于对内容执行用户验证的不同方法。
- 观察测试：观察测试是一种简短会话，内容创建者在其中观察一个或多个用户在没有接受指导或指示的情况下使用内容。 在这些会话中，内容创建者可以利用他们观察到的问题来识别潜在缺陷、问题或解决方案的改进。 这些测试非常有价值，因为只需付出很少时间和精力即可组织，并且可以限定于解决方案的特定功能或组成部分。 观察测试非常有利于获取有关设计或方法的早期反馈，例如概念证明 (POC)。
- 焦点小组测试：焦点小组测试是由一小群用户组织的有限会话，他们一起浏览内容。 这些焦点小组是特选的关键利益干系人和主题专家，他们可以提供有关某些特性或功能的最佳反馈。 焦点小组测试可以在多个交互式会话中进行。 焦点小组测试比观察测试需要更多的时间和精力，但可以提供有关解决方案的更详细反馈。
- 用户验收测试：用户验收测试（UAT）是一个正式过程，其中一组来自用户社区的个人验证并提供有关解决方案的异步反馈。 组织 UAT 所要付出的时间和精力最多，但也是执行用户测试的最彻底方式。 一旦测试用户接受解决方案并且反馈问题得到解决，就可以将内容部署到生产工作区。
确定如何验证内容后，可以规划如何将内容部署到工作区以及在工作区之间部署。
清单 - 规划如何验证内容时，关键决策和操作包括：
- 设计并记录测试条件：描述要执行的测试、测试的内容以及测试的执行方式。
- 确定同事评审流程：描述除了你之外，还要由谁来验证内容。
- 确定手动测试方法：确定使用哪些工具和功能来验证创建的内容。
- 确定是否使用自动测试：确定内容的规模和范围是否值得你设置自动测试。 如果是，请务必规划所需的时间和资源来设计和实现这些测试，以便它们按预期进行验证。
- 将内容从开发工作区部署到测试工作区：将更改从开发工作区部署到测试工作区，以便用户可以看到更改。 确保已在测试工作区中完成所需的部署后活动，例如设置和更新测试应用。
- 确定用户测试方法：确定用户如何验证内容。
- 确定测试用户：确定用户社区中的哪些人将验证内容。 与这些人就他们的参与范围和期望达成一致。
- 收集用户反馈：设置工具和流程来自动收集反馈。 例如，可以使用 Microsoft Teams 或 Microsoft Forms 中的“任务和计划程序”。
- 记录测试结果：记录所有内容验证的结果，以及由于测试结果而要进行的任何更改。 确保此记录易于查找。
- 规划部署到生产环境：用户测试结束后，准备好将内容从测试工作区部署到生产工作区。
相关内容
在本系列的下一篇文章中，了解如何在管理内容生命周期过程中部署内容。