automated-tests - 自动化验收测试 - UI 还是 API？

Question

这几天我一直在研究自动化验收测试，学习了 BDD & JBehave、FitNesse & Slim、Selenium & WebDriver 等。

我刚刚看过this Robert C. Martin 的视频演示了如何使用 FitNesse 编写和维护此类测试。接近尾声时，有人问这些测试是否命中了 UI。 Martin 继续解释说，将验收测试与 UI 耦合可能会很昂贵，因为对 UI 的更改非常频繁。我还可以猜测，此类测试只能在 UI 开发完成后编写，这会使测试人员落后于计划。

我不得不问:有什么选择？ Martin 似乎在暗示测试应该触及一个隐藏层，该隐藏层将操纵应用程序的业务层。我的理解是，这需要额外的工作，更不用说它会暴露一个新的 API，需要在生产环境中保护一次。

通过应用服务触及业务层就足够了吗？

你有什么经验吗？

感谢分享!

Answer 1

通过 UI 进行测试或者直接打到业务层，可以看作是两种不同类型的测试，各有优劣。

如果您直接测试 UI，那么您就是在测试用户所看到的内容，您无需更改代码即可对其进行测试。但是，测试极端情况或系统如何对异常情况(例如异常)使用react变得非常困难。正如罗伯特·马丁所说，它很脆弱。如果你的界面改变了，你需要改变你的测试。因此，通过 UI 进行测试取决于 UI 的成熟度。在项目的后期，UI 更加稳定，因此通过 UI 进行测试更有意义。此外，通过 UI 测试一些东西是困难的或复杂的。

如果您正在测试业务层，那么您可以更轻松地测试角落条件，并且您不太容易受到 UI 变化的影响。但是，正如您所说，软件必须以允许进行此类测试的方式编写。您甚至可能必须公开一个新接口(interface)以允许它，然后必须对其进行维护。根据我的经验，有时很难让开发人员支持这种接口(interface)。它被认为不如真正的界面重要。但这总是可能的。这种界面需要开发人员的支持，否则随着时间的推移，您可能会面临“不支持”的风险。

如果您没有外部接口(interface)，请尝试询问它。你永远不知道，你也许可以说服他们这是个好主意。在项目开始时更容易。

如果您有外部接口(interface)，则使用它来测试您的业务逻辑。

否则，您将不得不使用 UI 来测试这些东西。一种方法是使用 UI 进行冒烟测试，以回答以下问题:该软件是否可测试？想想每次从开发人员那里获得构建时必须测试的常见事物。我可以登录，我可以注销，主页是否出现，我可以做一个简单的订单吗？选择其中的 5 或 6 个，并构建一个自动化测试套件来测试这些东西。使用这些测试作为指南，了解您可以通过 UI 实际测试多少功能，以及它有多大用处。

然后，当您向开发人员询问外部接口(interface)时，您可以将其用作参数。