质量保证测试的后门API - 好还是坏？

Question

为了QA测试的好坏，有API吗？

我们正在从头开发一个应用程序，我们一直在创建后门API以简化QA的工作。这些后门处理很多事情，比如更改服务器的日期以模拟时间进程等。我对此非常不满。这些后门的数量几乎可以与生产中使用的真正的API相媲美。

这是推荐的方法吗？显而易见的好处是，它使质量保证的生活变得更加简单。我可以看到许多缺点，例如维护这些测试API的功能，确保这些后门API不会在生产环境中暴露。

如果其他人使用了这种方法，有什么方法可以确保这些API在生产环境中不被暴露？

对于那些反对这种方法的人来说，是否有替代方案可以使QA的工作更容易？

感谢

Answer 1

如果它不造成QA错过的问题，这是做了一件好事;如果你可以在未来没有成本的情况下让自己的工作更轻松，那就去做吧。

但是，通常情况下，只要您测试一个API，但使用时使用另一个API，则实际上并未测试正在投入生产的真实API。如果QA对正常的API有破解，他们也应该测试黑客和真实世界之间的差异。

在这种情况下，听起来像他们有助手方法来修改状态，以启用测试。如果没有好的方法来做到这一点，否则他们正在做的事情可能相当合理......或者，至少，可能有更好的方法来花时间改善事情。

但总体而言;它是否定期（重复）导致它们错过应该捕获的错误？

Answer 2

你正在使用什么构建系统？

对于具有任何时间/调度逻辑的任何软件，我认为这是非常重要的，以添加一个名为SystemClock类与调用方法“（）currentTime的。”

在我们的Android项目中，我们从Gradle变量中注入开始时间，然后我们可以确定代码无法通过移动时间进入生产（因为该变量仅针对调试版本定义）。

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

你在Java世界中有另一种选择是各个方面。他们可以很方便地在测试版本中进行混入，而这些混入在生产中不存在。