单元测试的局限性是什么？

Question

在为我想要实现的目标寻找正确类型的单元测试大约 (2) 个工作日后，我觉得我想要一些无法获得的东西。 阅读 (8) 年前的一篇文章后： 单元测试中的“坏”属性是什么？ 我现在相信我要求测试一个荒谬的配置。

我本质上是在尝试使用 Google 测试框架对各种因素的组合（如 n=729 不同配置中的各种组合）进行黑盒测试，这似乎是我在问不可能的问题。 我只是想一次测试太多东西，就像评论中的某个人写的那样。

我知道自动化是软件 QA 中非常有用的工具（我的应用程序基于桌面以供将来参考），但是在此之前我的简单单元测试只更改了每个配置的一个参数，并且仍然需要大量的工作。 与我现在想做的事情相比，那是容易的部分。 由于需要我进行多少思考/外部行动，我基本上排除了此选项。

我复制了一个旧链接到昨天的一篇文章，下面描述了我的问题以及我到底想测试什么以供参考： 是否有有效的黑盒测试方法可以避免冗余？

我很感激任何人对他们认为对单元测试要求太多的意见。

Answer 1

您所做的很可能不是真正的单元测试。

单元测试是在小的、孤立的代码段中发现错误。 这意味着，您通常是在测试一个类的单个函数或方法，在极少数情况下会测试稍微（！）较大的代码部分。 请参阅https://stackoverflow.com/a/55153145/5747415 ，或者，要了解单元测试与集成测试等其他测试阶段的区别，请参阅https://stackoverflow.com/a/56120843/5747415 。

还在想你在做单元测试吗？ 那么也许黑盒不是要走的路。

虽然您可以在单元测试期间应用黑盒测试方法，但单元测试是最接近代码级别的测试阶段（例如，与集成测试相比）：开发人员通常为自己的代码创建单元测试，而他们在代码上工作，这意味着他们当时已经记住了。 由于这个和其他原因，单元测试更自然地以玻璃盒测试风格进行。

以详尽的方式进行黑盒测试会导致大量测试用例，因为您正在创建输入值集的笛卡尔积。 但是，在典型的代码中，有一些特殊情况（例如错误情况）会提前处理。 例如，如果第一个参数无效，代码可能会立即退出并抛出异常。 然后，用来自剩余参数的笛卡尔积的每个组合来测试场景“第一个参数无效”没有任何价值。 在严格的黑盒测试中，您无法知道“第一个参数无效”情况下的提前退出，但在单元测试中，您将利用这些知识。

仍然相信所有组合都很重要？

那么很可能函数/方法/类或任何你正在单元测试的东西太大了，应该分成更小的函数。 您尚未在问题中显示任何代码，这对于单元测试问题来说是不典型的。

Answer 2

我相信您面临的问题不是因为单元测试本身，而是因为您的单元测试中缺少方法。

如果您的特定问题是测试用例过多（检查的可能性太多），我强烈建议您使用以下两种方法进行选择（基于https://www.guru99.com/equivalence-partitioning-boundary-value -analysis.html ):

等价类划分

定义在系统中执行相同路径的输入值类。 例如，如果您有一个检查输入整数是否大于等于 18 的方法 isAdult，您可以将输入分为三类：

• 无效的年龄值（即输入 < 0）
• 非成人年龄（0 <= 输入 < 18）
• 成年年龄（输入 > 18（通过从每个等价类中为您的测试用例选择一个代表值，您可以很好地覆盖输入值的整体空间。

边值分析

让您从等价类中选择最有效的代表。 这是通过探索两个等价类之间的边界来完成的，那里通常具有最大的错误检测潜力。 但我不想详细介绍 - 如果您有兴趣，可以查看例如https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html以获取一些示例和视觉效果（在两种方法上）。

工具支持

在定义等价类时，您（理论上）甚至可以在此元级别上工作并与测试用例交互。 无需关心从等价类生成的许多测试用例。 在实践中，诸如https://www.devmate.software/ （我个人使用的工具）或https://www.tricentis.com/products/automate-continuous-testing-tosca/ （对我来说太贵了- 并且不确定它是否明确支持等价类分区，但是）允许您通过从您的等价类自动生成和管理测试用例代码来做到这一点。

单元测试最佳实践

如果您还有其他问题（除了“测试用例过多”方面），您还应该评估您的单元测试并尝试坚持常见的最佳实践。 你可以找到一些关于好/坏单元测试的例子，例如： https : //www.devmate.software/good-unit-tests-vs-bad-unit-tests-with-c-and-nunit-examples/基本上，他们归结为

• 应用允许测试用例可维护性的方法
• 使测试用例定义和代码对其他人可解释和可读（无需进一步解释）
• 坚持单元测试的规定（可重复，只测试一个单元，与系统的其余部分分离）。