Power Automate - 如何测试您的流程

开发者最讨厌两件事：测试和文档。我知道它们很重要，但就是很无聊😎

但我认为测试是一种投资，10 分钟的测试可以节省 1 小时的调试时间，而比调试更糟糕的事情就是在生产环境中进行调试。

测试主要分为两种类型：

1. 单元
2. 从头到尾

它们都能创造价值，但关键在于两者都要做好，否则最终会导致重复劳动和浪费。

1. 单元

单元测试是一种模块化方法，专注于解决方案的一部分。它们应该由开发人员在构建过程中完成。这些测试通常从小规模开始，随着解决方案的扩展而增加，但规模应该适中。关键在于确定单元测试的极限：规模太小，测试耗时过长；规模太大，调试耗时过长。你需要找到一个合适的平衡点。

流程的设计和构建方式对测试的影响最大。如果构建一个庞大的单体流程，测试将会非常困难。最佳方法是将流程的操作数限制在 50 个以内，并使用预定义输入/输出的子流程。这样，单元测试就变得简单：输入是否得到预期的输出。由于代码与其他流程隔离，如果某个流程出现故障或需要更新，我们只需要测试该流程即可。

在构建过程中，我们可以使用一些技巧/工具来帮助我们进行单元测试。

测试流程：
这显而易见，但我遇到过太多人不知道。你有两种选择：手动和自动。如果不是手动触发流程，那么手动测试只是增加触发轮询的频率。

简而言之，自动触发器实际上是一个定时 API，它会持续询问“现在是否应该运行？”。例如，On Email 会不断向 Outlook API 发出请求：“您有邮件吗？”。如果您查看触发器的代码，就能看到具体的运行计划。它取决于您的许可证和连接器，并且是最低限度的运行频率（如果 Microsoft 有足够的资源，它会进行更频繁的检查）。运行测试会将运行频率更改为每秒一次。

自动测试会重用之前的运行结果，因此比不断发送电子邮件来测试“新邮件触发流程”要好得多。

这样做的问题在于，流程会影响流程之外的操作（例如删除电子邮件），这可能会导致下一个测试失败（因为邮件不能删除两次），而且流程总是会运行到最后，即使该部分尚未完成。幸运的是，我们有两种方法可以缓解这些问题。

静态结果
警告：此功能仍处于预览阶段（因此可能会有所更改，但由于它是一个开发工具，所以我不太担心它的使用）。静态结果意味着您可以指示某个操作返回一个值，而无需实际离开当前流程。

所以，在我提到的删除邮件示例中，程序会显示已删除邮件并继续执行，但实际上并没有删除邮件。这种方式也非常适合异常处理，因为即使输入有效，你也可以强制操作失败。

你也可以返回一个集合主体，只需从之前的运行历史记录中复制输出并将其添加进去即可。

设置静态结果还有另外两个主要好处：

• 速度——比等待 API 响应更快
• 一致性——从测试中移除一个变量（不再会因为突然出错而感到困惑，最终发现是 API/数据发生了外部更新）。

终止操作
会在流程的该点结束流程，因此我们可以随时添加它来停止流程运行。我将其命名为“断点”，这样在开发完成后我可以快速搜索，确保不会遗漏它们。

希望未来的更新能够像静态结果那样添加一个断点，这样我们就可以直接点击操作中的设置，而无需添加操作。

2. 端到端

端到端测试会检查整个流程（我知道这个名称已经很明显了）。这项测试的关键在于：

• 测试计划
• 职责分离

测试计划：
切勿在没有测试计划的情况下进行端到端测试。测试计划可确保所有环节都经过测试，并始终达到预期结果。

它需要覆盖

• 所有预期输入
• 所有可能的输入（分组且合理）
• 幸福之路的结果
• 异常路径结果

快乐路径是我们希望发生的事情，例外路径是当发生坏事时我们希望发生的事情。

测试计划应该分解成涵盖所有内容的测试场景。

例如，我有一个流程：“收到电子邮件时，将其附件（PowerPoint 文件）保存到我的 OneDrive 文件夹中”。我的测试计划如下：

职责分离：
端到端测试人员不应是开发人员，必须明确划分职责，以确保测试的完整性。理想情况下，测试人员应来自业务部门（这也是为什么它有时被称为用户验收测试），但至少不应与开发人员属于同一团队或同一主管。这或许听起来有些过分，但：

• 如果你已经制作完成并测试了几个小时，那么人性决定了你要么会偷工减料，要么会以最积极的态度看待所有结果。
• 如果测试人员受到部署截止日期的影响，他们更有可能以最积极的态度看待所有结果。

无论测试多么麻烦，它都极具价值，从长远来看，它总是值得的。