ATDD - 验收测试从哪里开始？

Question

我正在尝试理解验收测试，但我很困惑它开始的地方或涉及什么样的测试。 我是否必须使用自动化GUI测试框架或者是否必须使用单元测试？验收测试的界限是什么？

编辑：我的问题是自动验收测试。

Answer 1

在开发和集成整个应用程序/软件之后进行验收测试。 验收测试主要是为了测试应用程序是否满足用户要求。

主要有两种验收测试。

• Alpha测试
• Beta测试

验收测试主要由客户（要求开发软件的人）和最终用户完成。

Alpha测试由客户完成。他得到了开发人员的帮助。 客户在这里查看软件以确保满足他的所有要求。

Alpha测试完成后，

Beta测试完成。 此处，该应用程序将发布给一组充当最终用户并使用该应用程序的人员。

Answer 2

单元测试不应与验收测试相混淆。

验收测试基本上是要求，写成测试，以便：

1. 很明显何时符合要求;
2. 实际测试更容易规划和运行。

单元测试是针对少量代码的自动测试，用于密切关注所有小位，而无需持续（并且非常讨厌）手动检查。

Answer 3

你可以走UI路。 Selenium或WatiR是可用于运行基于ui的测试套件的可靠工具。 如果你是Dot.Net开发人员，你可以使用WatiN，但问题是它似乎已经死了，因为它自2011年4月以来没有新版本。

我确实设法为我准备了一些不错的测试套件，整合了SpecFlow（稍后会详细介绍）和watiN，它运行良好。

然而，随着时间的推移，我意识到当我进行基于UI的测试时，我所做的只是加载页面，点击某些内容，然后检查数据库中的结果。有时候，我还检查过屏幕上还显示了预期的消息，但就是这样。这个结论促使我摆脱了基于UI的测试。

我开始做的是确保UI建立在规则和习语之上。现在的工具（asp.net mvc，razor模板或更好的 - knockout.js）允许我们这样做而不会有太多的痛苦。当UI是有条不紊地构建的，而不是每个人都在页面上抛出他们喜欢的任何字段时，大多数时候你需要测试的是构建它的方法，而不是结果。 Ofcurse，如果我想测试它（在某些情况下，你会），用QUnit，

等工具测试它会更容易（也更快）

所以我的实践ATDD的方式：

1. 使用specflow将业务需求纳入测试代码。
2. 仅测试“背后的代码”。
3. 使用knockoutJS进行UI管道（使用大量自定义绑定）
4. 为返回到视图的模型创建标准。
5. 将UI行为测试视为单元测试。

这是specflow的一个很好的起点：http://www.infoq.com/articles/Spec-Flow