14

I've been researching automated acceptance testing over the last few days, learning about BDD & JBehave, FitNesse & Slim, Selenium & WebDriver, etc.

I've just viewed this video by Robert C. Martin where he demonstrates how to use FitNesse to write and maintain such tests. Towards the end, somebody asks if these tests hit the UI. Martin goes on to explain that coupling acceptance tests to the UI can be costly since changes to the UI are quite frequent. I could guess also that such tests could only be written after the UI has been developed, which would bring testers behind schedule by definition.

I have to ask: what is the alternative? Martin seems to be implying that tests should be hitting a hidden layer that would manipulate the application's business layer. My understanding is that this would require additional work, not to mention that it would expose a new API which would need to be secured once in a production environment.

Could hitting the business layer through application services be sufficient?

What has been your experience?

Thanks for sharing!

4

6 回答 6

14

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

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

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

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

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

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

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

于 2011-07-26T10:39:47.157 回答
9

不幸的是，你需要两者。通常，您希望使用诸如适应度之类的东西来自动化业务层测试。避免使用 UI 基本上可以确保定义的业务规则始终有效。通过 UI 实现自动化可能需要更多的维护。但从好的方面来说，由于大部分 UI 使用平台提供的机制（例如 c#/Winforms），因此您的大部分 UI 测试只能在您对其他类型的测试（如业务层）进行了充分覆盖的情况下进行更改. 自动化测试需要维护和更新，但 UI 测试往往需要更多的维护，并且随着时间的推移往往不太可靠。

于 2011-07-26T03:53:04.243 回答
3

我强烈主张使用非 UI 自动化模式进行验收测试。您可能面临的问题是将这个想法卖给传统的代码盲测试人员，他们会发现接受标准的非视觉验证概念是不够的。我更喜欢通过两组测试来测试验收标准的中间方式。第一组纯粹是专注于逻辑的，因此针对 API/Service/Remote 层实现。这组是 100% 自动化的。第二组是同一需求的 UI 验证。由于其他答案中所述的原因，我个人的观点是不要自动化第二组。至于编写测试的层，这取决于团队。如果团队真正致力于质量，他们会将其视为产品开发的重要组成部分。然而，在现实世界中，这是一个很难卖的东西。除非在项目开始时明确调用它，否则很难在正在运行的项目中改造这样的接口。我建议，如果您想实施自动化验收测试，请尽早进行。随着产品的老化，实施此类黑客攻击的可能性急剧下降。

于 2015-04-02T09:11:15.667 回答
3

我只能说 UI 测试，问答风格：

A) 我们的 UI 是否已经稳定或仍有可能发生很大变化？

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

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

B) 我们的 UI 是稳定的，我们应该尽可能多地自动化它吗？

上帝不！

1) 获取所有测试脚本（例如 100 个）

2) 决定哪些是可自动化的 (80)

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

4）首先自动化阻止程序和关键程序（例如，20/80）

看看它是如何工作的，并在需要时实现更多自动化。

C) 自动化 UI 时我还应该考虑哪些其他因素？

一切如下图所示（测试金字塔是 Mike Cohn 提出的一个概念）：

在此处输入图像描述

于 2016-06-25T12:23:40.293 回答
1

创建测试接口是“测试人员的梦想”，但启用/禁用它将是部署的噩梦。您可能需要具有不同冒烟测试的“测试构建”和“部署构建”。但只要你限制 UI 自动化测试，任何妥协都是好的。

于 2011-08-01T16:34:37.757 回答
0

就移动自动化而言，我相信我们不需要单独的接口来进行非 UI 测试。现在有一些方法可以使用模式编写代码，这样代码是可单元测试的（例如依赖注入和一种提供测试中可用的私有方法的方法。（例如@VisibleForTesting）。

注意：我还没有写过非 ui 测试，也没有使用过这个注解。，但很期待。我只是想分享@VisibleForTesting 的东西来打破我们需要单独的方法作为测试接口的概念。）某人的帖子：https ://medium.com/@vadimpushtaev/how-to-test-private-methods -4bc57d4410ff

于 2019-05-21T07:22:20.857 回答