学会单步调试与撰写测试用例 | 简单易懂的现代魔法

type

status

date

slug

summary

所谓的单步调试其实是一个编程概念，指在调试程序时，通过逐行执行代码，以便可以观察每一行代码的执行情况和程序状态的变化。这种调试方式可以帮助开发者更精确地定位和解决代码中的问题。

但是在 n8n 之中，我们可以认为单步调试 ≈ 单个节点调试，即查看单个节点的执行成功与否。因为 n8n 大部分节点都不支持我们做二次改造，节点对于我们来说是一个黑盒，我们只需要关心节点的输入和输出是否符合我们的预期，如果符合，就说明这个节点是 Work 的，没有任何问题。

即使是最简单的程序，在 n8n 之中往往也可能有 5-6 个步骤，所以强烈建议在制作工作流的时候进行单步调试。

推荐这么做的原因有三个：

即使是借助 n8n，我们也可能因为各种各样的原因编写出错误的程序，或者在编写程序的过程中发现执行不成功，如果程序的步骤很多，那么检查工作会变得异常困难，需要从头检查，反过来说如果在开发工作流的过程中我们能够对每一个单独的节点进行充分的测试和调试，那么就能基本确保所有程序连在一起的时候是执行成功的；

在 n8n 的应用过程中，我们经常会试用大模型相关的功能节点，在吴恩达的 Prompt 课程中重点强调了一个关键，这个世界上没有完美的 Prompt，只有经过测试和根据测试结果不断迭代修正出来的优秀 Prompt，通过 Test Step 获得能够完美执行我们任务的 Prompt 是必备的技能；

每个步骤执行成功，都能让你在过程中获得一些快乐，不要小瞧这些快乐，在低代码配置的过程中会遇到很多挫折，多给自己一些奖励是很有必要的，而且可能在执行的过程中你也许会发现中间步骤给出的结果已经能满足需求了，这个时候就可以直接结束工作了；

单步调试需要用到的最核心的功能有两个，一个是 Test Step：

另一个是 OUTPUT 窗口，OUTPUT 窗口不仅仅会展示正确的结果，如果出错时也会给出错误吗，如果看不懂错误码，可以询问 ChatGPT 错误码的含义。

关于具体如何进行单步调试，如何查看日志，请阅读文档：

需要使用 n8n 编写低代码的场景，往往和“重复”，“批量”紧密相关，因为有大量的重复性工作，所以我们希望用低代码平台编写自动化程序，用机器替代人力解放我们的双手。

但是要怎么保证此时此刻我们的程序 Test 是成功的，在我们不管它的时候，它也是能够执行成功的呢？

或者说如何保证在处理当前的数据是成功的，以后处理别的数据也是成功的呢？

这就需要引入测试用例的概念，测试用例（Test Case）是软件测试过程中用于验证软件系统或其某个功能是否按预期工作的具体实例。

因为 n8n 所有的节点都是输入-处理-输出的概念，所以你可以认为所有的测试用例都是针对单个节点的，并且只需要想清楚在输入为 A 的情况下，输出一定为 A1，这样的用例就可以了。

在实践的时候，不是每一类节点都需要测试用例，因为 n8n 的大部分节点都是现成的开发好的，经过了充分的测试，但是有两类情况是例外的：

需要进行大量数据处理的场景：数据源质量可能是有问题的，这是非常常见的情况，比如你在处理数据的时候有些逻辑可能会依赖某个字段，但是假如这个字段为空，或者其枚举值超出了预期，程序就可能会中断，所以这个时候需要做一些柔性的设计，需要充分考虑字段为空的用例，除非数据源十分可靠；

需要使用大模型的场景：大模型本身会有幻觉的问题，如果想要使用大模型做一些类似于打标的工作，最好人工准备 10-20 个案例，并且自己人工先标注一下结果，再让大模型打标，根据大模型打标的结果调试 Prompt，从而实现最佳的打标效果，而且从实际情况来看，大模型打标正确率能有 90% 就已经很不错了，所以这个时候还需要进行一些取舍；

最后有人可能会问，即使这个程序通过了所有的测试用例，是不是也不代表万无一失。

是的，所有测试用例都有它的局限性，但是因为这个程序通过了所有的测试，所以我们就可以认为它是正确的程序。

就好像这边有一个噬元兽，如果它看起来像橘猫、游泳像橘猫、叫声像橘猫，那么它可能就是只橘猫，你不能认为它一定是一个噬元兽，然后特意去用 X 光照一下，这样很不经济。

🧪学会单步调试与撰写测试用例