20

好的，所以我在一家近年来公开采用敏捷开发实践的公司工作。我们的单元测试和代码质量正在提高。我们仍在努力的一个领域是在自动化验收测试领域找到最适合我们的方法。我们希望采用格式良好的用户故事，并使用它们以测试驱动的方式驱动代码。这也将为我们提供每个用户故事的接受程度测试，然后我们可以将其自动化。

迄今为止，我们已经尝试过 Fit、Fitnesse 和 Selenium。每个人都有自己的优势，但我们也遇到了真正的问题。使用 Fit 和 Fitnesse，我们不禁觉得它们使事情变得过于复杂，而且我们在使用它们时遇到了许多技术问题。企业还没有完全购买这些工具，也不是一直特别热衷于维护脚本（并且不是表格样式的忠实粉丝）。Selenium 确实很好，但速度很慢，并且依赖于实时数据和资源。

我们现在考虑的一种方法是使用 JUnit 框架来提供类似的功能。为什么不使用 JUnit 来编写一个测试（使用 JUnit 框架）来覆盖应用程序的可接受水平范围，而不是使用 JUnit 测试一个小的工作单元？即拿一个新故事（“作为用户，我想查看我的策略的基本细节......”）并在 JUnit 中编写一个测试，该测试在策略细节链接的入口点开始执行应用程序代码，但涵盖所有代码和逻辑到存根数据访问层，然后返回到转发到应用程序中的下一页的点，断言用户应该在该页面上看到什么数据。

在我看来，这具有以下优点：

  • 简单（不需要额外的框架）
  • 与我们的持续集成构建服务器集成零努力（因为它已经处理了我们的 JUnit 测试）
  • 团队中已经存在完整的技能集（毕竟它只是一个 JUnit 测试）

缺点是：

  • 更少的客户参与（尽管他们在编写验收测试的第一时间就大量参与编写用户故事）
  • 与自由文本规范 ala Fit 或 Fitnesse 相比，JUnit 类中的用户故事和接受标准可能更难理解（或理解）

所以，我的问题是，你有没有试过这种方法？有没有考虑过？你觉得呢？你有没有什么想法？您喜欢和不喜欢这种方法的哪些方面？最后，如果你能说出你喜欢或不喜欢它们的原因，请只提及替代框架而不是这种方法。

4

7 回答 7

12

我将 JUnit 用于验收测试框架的经验。

我们公司做了一个非常相似的事情，我们从 FitNesse 开始，然后转到 JUnit。我们这样做主要是因为 FitNesse 已经在 J​​ava 之上，所以切换到 JUnit 很容易。FitNesse 似乎不适合（没有双关语）我们的需求。

以下是我使用 JUnit 的优缺点：

优点：

缺点：

  • 人们听到 JUnit 并想到单元测试。当人们开始将验收测试称为“JUnit 测试”时，这会变得令人困惑。
  • 要提供简化的测试环境，您必须花一些时间扩展框架和开发 DSL。

因此，总而言之，如果您愿意花时间将 JUnit 扩展到您自己的特定领域的测试环境中，那么 JUnit 就可以很好地用于验收测试。否则，我想我会在别处寻找更多开箱即用的东西。

于 2012-09-27T22:59:07.347 回答
6

业务和 UAT
业务大部分时间迟早会对任何测试工具失去兴趣。毕竟他们是业务而不是测试人员，因此他们不会在编写/维护测试脚本方面投入太多。他们是生意人，他们想做生意。从他们的角度来看，测试人员/开发人员/其他 IT 人员负责为他们提供一定质量的软件。
即使敏捷是您的方式，并且您从业务中获得了一定程度的承诺，也不要期望他们在每次冲刺/迭代或您拥有的任何东西时都表现得像测试人员。这真的不是他们的工作。
题外话：用户验收测试是由用户执行的手动测试，所以他（他们）可以说是他（他们）要求的产品。
因此，只要功能（或一组功能）准备就绪，就为业务做演示，让他们玩弄它，让他们说这是他们需要的。不要强迫他们在每次迭代时检查这个特性。

现在回到你的验收测试。每当您有来自客户的故事要做时，请在您的测试基础设施中为它实施测试。你编写它，你运行它，你维护它。使用 ADD/BDD/TDD 或任何您想称呼的方式测试功能和驱动开发可能是明智的。很明显，这个测试会在下一次迭代中对您的回归测试套件有所贡献。

所以我的观点是，企业不会热衷于编写/维护测试，尤其是当功能集增长时。不要与之抗争，适应它。让他们在迭代结束时对新功能进行（手动）用户验收测试。为了您自己的缘故，为他们想要的功能创建测试。为每个功能创建功能验收测试。让这些测试成为您的回归测试套件。接受你有责任维护它。

验收测试框架
JUnit，嗯？然后尝试使用WatiJ网页版和Abbot桌面版。请记住，这些测试不会是简单的单元测试。您想要测试真实应用程序功能的东西，您想要测试脚本执行特定的场景/业务流程。这意味着您需要像编写他们正在测试的应用程序一样编写这些测试：DRY、KISS、YAGNI、设计模式——一切都适用。最后，它将是编写软件，恰好是测试您编写的其他软件。

使用这种方法，这些测试是否会变得庞大而复杂？嗯，比单元测试更大更复杂。但他们不是在测试单个单元，而是整个应用程序。此外，它们将比您最初编写的应用程序更简单、更小。

你会写测试框架吗？如果您想通过这种方法取得成功，那么您将编写测试框架——测试类和帮助类的集合，这些类对您的应用程序实现有一定的了解。但是您不会扩展 JUnit。这里的 JUnit 只是您在框架中使用的一些 API。

于 2010-07-24T22:44:16.740 回答
5

使用 JUnit 编写验收测试是完全有效的。JUnit 只是一个测试执行框架，无论你是用它实际编写单元测试、组件测试、集成测试还是验收测试，都完全无关紧要。正如 user1704737 已经说过的，拥有一个可读的 DSL 来编写测试非常重要。

要在 JUnit 中编写测试，我建议尝试一下JGiven。它是一个轻量级框架，可以很容易地用普通 Java 中的给定时间符号编写验收测试。它使用 JUnit（或 TestNG）作为测试执行器，因此可以很容易地集成到现有的测试基础设施中。您还可以获得验收测试的 HTML 报告，您可以展示业务来验证测试是否符合要求。

免责声明：我是 JGiven 的作者

于 2014-07-27T07:50:15.763 回答
3

试试robotframework (www.robotframework.org)，我已经用了很多年了，赫尔辛基的Pekka Klarck 开发了它（诺基亚西门子网络从一开始就支持它，现在它也是开源的）。

robotsframework 使用表格格式的测试用例，支持 HTML、CSV 或纯文本（以特定语法编写）。它有一个库机制，支持导入 Selenium 函数。您可以使用 Python 或 Java 为机器人框架编写库。

对于 JUnit 作为验收测试框架，当然可以，但不值得这样做。更高级别的测试应该更少依赖软件的内部实现，甚至不依赖于软件的内部实现，而使用 JUnit（这是一个单元测试框架）编写验收测试时，您引入了很多依赖于它的内部函数调用。当软件设计发生任何变化时，这将是一个大麻烦，而高级测试不应该受到影响，而您会受到影响。

于 2012-06-23T05:26:55.660 回答
3

如果您遵循该路径，有一些建议：

  • 将您的验收测试放在另一个项目中，因为它们可能会比您通常的测试运行得更慢并且具有更多的依赖项
  • 创建构建器（可能使用流畅的界面）在测试夹具中设置模型，因为您会发现为测试设置所需的对象将是最无聊和最难维护的部分。
  • 看看 Groovy 和Spock 框架：它与 JUnit 兼容，但为您提供了一个很好的 DSL 以使您的测试可读。
于 2011-12-06T04:44:02.620 回答
1

你提到了一些关于利弊的好观点。我可以添加：

优点：我喜欢无需数据库、Web 服务器即可测试所有内容的想法。这极大地有助于理解代码和重构。

缺点：

JUnit 代码将很复杂且难以维护。您将不得不在 Junit 测试中重现代码和用户之间的所有交互，这很快就会变得复杂。如果您所做的只是测试一个入口点，那么这可能会很好，但如果您正在测试多个屏幕（一个向导或类似的东西），那么它很快就会变得脆弱和难以管理。根据我的经验，问题几乎总是页面之间的管道代码，或者页面所需的设置代码。

要考虑的另一件事是您尝试做的事情的灵活性。使用 Fitnesse，如果您发现错误，添加另一个测试相当容易。事实上，这就是 Fitnesse 背后的理念：“用户”可以添加另一个测试而无需更改代码。不要低估这个的价值。

所以我建议两点：

1）试一试。拿一个用户故事（不太复杂，不太简单），并在 JUnit 中完成。比较您使用 Selenium/Fitnesse 等所做的事情，看看是否值得。看看你 1. 是否真的发现了错误，2. 产生脆弱、难以管理的代码。

2）您能否使用 Fitnesse 创建的数据作为 JUnit 测试的输入（从而消除对 Web 服务器等的需求）。您可以直接读取数据并调用 Java 类中的方法。同样，您可能在设置和数据库代码方面遇到问题。

于 2010-04-23T07:32:31.653 回答
0

恕我直言，这不是一个好主意。除了您提到的两个缺点之外，构建一个可以处理您可能拥有的各种 web/UI/glue 场景的验收测试框架所需的大量工作如何？您的观点“简单（不需要额外的框架）”是不正确的，因为您的组织必须投资于在 JUnit 之上构建更精细的框架。它可能不止于 JUnit。

于 2010-04-22T21:18:15.663 回答