自动验收测试 - UI或API？

Question

过去几天我一直在研究自动化验收测试，了解BDD＆amp; amp; JBehave，FitNesse＆amp;苗条，硒和WebDriver等

我刚看过Robert C. Martin的this视频，他演示了如何使用FitNesse编写和维护此类测试。接近尾声时，有人问这些测试是否会触及用户界面。 Martin接着解释说，对UI的耦合验收测试成本很高，因为对UI的更改非常频繁。我还可以猜测，这些测试只能在UI开发之后编写，这将使测试人员按照定义落后于计划。

我不得不问：替代方案是什么？ Martin似乎暗示测试应该是一个隐藏的层，它会操纵应用程序的业务层。我的理解是，这需要额外的工作，更不用说它会暴露一个新的API，需要在生产环境中进行一次安全。

可以通过应用程序服务访问业务层吗？

你的经历是什么？

感谢分享！

Answer 1

通过UI进行测试或直接点击业务层可以看作是两种不同类型的测试，具有不同的优缺点。

如果您正在直接测试用户界面，那么您正在测试用户看到的内容，而您无需更改代码即可对其进行测试。但是，测试极端情况或系统如何对异常情况（例如异常）做出反应变得非常困难。正如罗伯特马丁所说的那样脆弱。如果您的界面发生变化，则需要更改测试。因此，通过UI进行测试取决于UI的成熟度。在项目的后期，UI更加稳定，因此通过UI进行测试更有意义。此外，通过UI测试一些内容很难或很复杂。

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

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

如果您有外部接口，那么使用它来测试您的业务逻辑。

否则，您将不得不使用UI来测试这些内容。一种方法是使用UI进行烟雾测试，回答以下问题：该软件是否可测试？想想每次从dev获得构建时必须测试的常见事项。我可以登录，我可以退出，主页面是否出现，我可以做一个简单的订单吗？选择5或6个这样的东西，并构建一个自动测试套件来测试这些东西。使用这些测试可以指导您可以通过UI实际测试多少功能，以及它的实用性。

然后，当您转到开发人员并要求外部接口时，您可以将其用作参数。

Answer 2

不幸的是你需要两者。一般而言，您可能希望使用健身等自动化业务层测试。避免使用UI基本上可以确保定义的业务规则始终有效。通过UI自动化可能需要更多的维护。但是从好的方面来说，由于UI的大部分都使用了平台提供的机制（例如c＃/ Winforms），因此只有在您完全覆盖其他类型的测试（如业务层）时，才能进行大量的UI测试。 。需要维护和更新自动化测试，但UI测试往往需要更多维护，并且通常不太可靠。

Answer 3

我强烈建议使用非UI自动化模式进行验收测试。您可能面临的问题是将这个想法卖给传统的代码盲测试者，他们会发现接受标准的非可视化验证概念不足。我更喜欢通过两组测试来测试验收标准的中途。第一组纯粹以逻辑为重点，因此针对API /服务/远程层实现。该套装100％自动化。第二组是相同要求的UI验证。我个人的意见不是出于其他答案中陈述的原因自动化第二组。至于编写测试的层，它取决于团队。如果团队真正致力于质量，他们会将此视为产品开发的重要组成部分。然而，在现实世界中，这是一个很难卖的东西。除非从项目的开始明确地调出它，否则很难在正在运行的项目中改进这样的接口。我建议，如果你想实施自动验收测试，请尽早完成。随着产品的老化，实施此类黑客攻击的可能性大幅下降。

Answer 4

我只能说UI测试，Q＆amp; A style：

A）我们的用户界面是否已经稳定或仍有可能发生很大变化？

稳定 - 自动化带来额外价值

可能会改变 - 不要自动化，您将花费更多时间来维护（重做）这些测试。

B）我们的用户界面稳定，我们应尽可能自动化吗？

上帝不！

1）拿走所有测试脚本（比如100）

2）决定哪些是可自动化的（80）

3）按优先级排序（阻截者，关键，次要）

4）首先自动化阻滞者和关键阻滞者（比如说，20/80）

了解其工作原理，并在需要时自动完成更多工作。

C）自动化用户界面时应考虑哪些其他因素？

如下所示的一切（测试金字塔是Mike Cohn开发的概念）：

Answer 5

创建测试界面是“测试人员的梦想”，但启用/禁用它将是部署的噩梦。 U可能需要使用不同的冒烟测试进行“测试构建”和“部署构建”。但是，任何妥协都是好的，因为长期限制UI自动化测试。

Answer 6

就移动自动化而言，我认为对于非UI测试，我们不需要单独的界面。如今，有许多方法可以使用模式来编写代码，以使代码可以进行单元测试（例如，依赖注入和提供甚至测试中可用的私有方法的方法。（例如， @VisibleForTesting ）。）

注意：我尚未编写过非ui测试，也从未使用过此批注。 ，但期待它。我只是想分享@VisibleForTesting东西，以打破我们需要单独的方法作为测试目的接口的观念。） 某人的帖子：https://medium.com/@vadimpushtaev/how-to-test-private-methods-4bc57d4410ff