API 测试：我可以通过增加单元测试来减少 API 功能测试的工作量吗？我可以用单元测试替换功能测试吗？

Question

我正在尝试优化我的 API（restful 和 SOAP 服务）测试工作。我在想，这样做的一种方法是消除多余的功能测试。我称它们为多余的，因为可能在单元测试级别执行相同的测试。

我了解开发人员对单元测试存在偏见，因此独立的功能测试至关重要。我不是试图通过执行广泛的单元测试来替换功能测试，而是试图通过消除一些功能测试同时在单元测试级别覆盖它们来优化我的测试工作。

我怎样才能做到这一点？单元测试和功能测试有什么关系？

我们以 customerAccount/add 服务为例。假设我有 6 个测试、2 个正面（快乐路径）测试、2 个超出边界值测试、1 个客户未找到测试、1 个无效客户测试。如果这 2 个在单元测试级别进行测试，我可以消除 2 个阳性测试和 2 个“超过边界值”测试之一吗？所以现在，单元测试级别涵盖了 2 个测试，功能测试级别涵盖了 4 个。

开发人员可能不会针对端点测试服务，他们可能会测试类和方法。但是在上面的例子中，我们仍然在测试端点。所以这已经涵盖了。

您如何看待这种方法？

Answer 1

我同意应避免进行冗余测试。但是 - 是什么让测试变得多余？我的观点是，如果该测试打算检测的所有潜在错误也打算由其余测试发现，则该测试是多余的。

单元测试、交互测试（又名集成测试）、子系统测试（又名组件测试或功能测试）的区别在于各自的测试目标，这意味着各自的测试打算捕捉哪些错误.

单元测试是关于通过测试小的（甚至是最小的）孤立的软件片段来捕捉那些你可以发现的错误。由于单元测试是最早的测试步骤，也有机会深入到代码中，所以经验法则是，如果单元测试已经发现了一个错误，你应该通过单元测试找到它，而不是试图在更高级别的测试中捕获该错误。这似乎与您“消除冗余功能测试”的方法一致，其中“可能在单元测试级别执行相同的测试”。例如，如果您的目标是在某些代码中出现算术溢出时发现潜在的错误，那么这应该通过单元测试来完成。试图在集成测试或子系统测试级别上找到相同的问题是错误的方法。

但是，您应该知道，子系统测试的目标（如果您和我在这里使用相同的术语，则为功能测试）可能与单元测试级别上外观相似的测试不同。在子系统级别上，您可以旨在捕获集成错误，例如，如果组合了错误版本的类（在这种情况下，每个类的相应单元测试都可能全部通过）。 Subsystem-tests 也可能旨在查找构建系统错误，例如，如果为您手动编写的代码环境生成的类未按预期生成。以此类推。

因此，在消除冗余测试之前，请确保您已了解这些测试的测试目标，以确定这些测试是真正的冗余。