用于 QA 测试的后门 API - 好还是坏？ [关闭]答案

【问题标题】：Backdoor APIs for QA testing - Good or Bad? [closed]用于 QA 测试的后门 API - 好还是坏？ [关闭]
【发布时间】：2015-06-21 22:21:56
【问题描述】：

为了 QA 测试而使用 API 是好主意还是坏主意？

我们正在从头开始开发应用程序，并且我们一直在创建后门 API 来简化 QA 的工作。这些后门做了很多事情，比如更改服务器的日期以模拟时间的进展等。我对此很复杂。这些后门的数量几乎可以与生产环境中使用的真实 API 相媲美。

这是推荐的方法吗？这样做的明显好处是它使 QA 的生活变得更加轻松。我可以看到这样做的许多缺点，例如维护这些测试 API 的功能，确保这些后门 API 不会在生产中暴露。

如果其他人使用了这种方法，有什么好的方法可以确保这些 API 不会在生产环境中公开？

对于那些反对这种方法的人，是否有其他方法可以让 QA 的工作更轻松？

谢谢

【问题讨论】：

您不能将您的 API 分成两个不同的组：生产和 QA。对于测试，您可以使用 QA API。但是 QA API 永远不会投入生产。你甚至可以有一个类似 ping 的 QA api，你甚至可以在你的生产环境中添加一个看门狗，它会监控那个资源，如果它在那里，就会吹口哨。有意义吗？

【解决方案1】：

如果它没有导致 QA 遗漏问题，那是一件好事；如果您将来可以让他们的工作更轻松而无需任何成本，那就去做吧。

但是，通常只要您测试一个 API，而使用另一个 API，您实际上并没有测试真正投入生产的 API。如果 QA 对普通 API 进行了破解，他们还应该测试破解与现实世界之间的差异。

在这种情况下，听起来他们有帮助方法来修改状态，以启用测试。如果没有好的方法可以做到这一点，那么他们正在做的事情可能非常合理......或者，至少，可能有更好的方法来花时间改进事情。

但总体而言；是否经常（反复）导致他们错过他们应该抓住的错误？

【讨论】：

【解决方案2】：

您使用的是什么构建系统？

对于任何具有任何时间/调度逻辑的软件，我认为添加一个名为 SystemClock 的类和一个名为“currentTime()”的方法是非常必要的。

在我们的 Android 项目中，我们从 Gradle 变量中注入开始时间，然后我们可以确定代码无法在时间偏移的情况下投入生产（因为该变量仅用于调试构建） .

对于我们的 iOS 版本，我们能够使用扩展。这确实是一个很好的方法，因为它只编译到测试范围中。然后它用移位的方法替换 getCurrentTime 方法。

Java 世界中的另一个选项是 Aspects。它们可以方便地在测试构建中执行生产中不存在的混入。

【讨论】：