7

与我之前的问题相反，我将尝试给出我的要求。

我正在尝试找到一些适合以下内容的框架/方法/“事物”：

  • 能够使用 C# 编写自动化测试，最好用 Visual Studio 编写。
  • 测试应该像用户一样驱动 Web 浏览器并与 SUT 交互。
  • 测试应该能够在数据库中设置测试场景。
  • 测试应该能够断言用户交互在 DB 中具有预期的效果。
  • 测试完成后，它应该能够回滚它在数据库中所做的所有更改。

我的第一次尝试是使用 NUnit 测试来驱动 Selenium（以及之前的 Watin），但我在使用 TransactionScope 回滚 Selenium 驱动的浏览器在数据库中所做的更改时遇到了一些问题（检查上面的链接）。

有没有人在“现实世界”中做过这样的事情？我通过谷歌找到了一些参考资料，但还没有找到任何具体的例子来说明如何实现这一点。如果我要进行单元测试，就不会有任何问题。在那种情况下，TransactionScope 就足够了。

编辑： R. Harvey 向我指出了这个问题，这与我的情况几乎相同。

然而，这个问题几乎是相同的。我的应用程序是一系列服务的一部分，它们都访问同一组数据库表。所需的测试数据量不允许有效使用 drop/create-scripts，那么是否有一些替代解决方案？

我们使用的是 SQL Server 2005，而且我对数据库魔法不是很精通，所以如果除了 drop/create 之外还有其他方法可以使用 sql 脚本，那么这可能是一个选择。

编辑2：

根据答案和一些额外的头疼问题，我们将为开发人员寻找更轻量级的数据库来执行单元、集成和功能测试。这使我们能够使用 sql 脚本来设置和拆除测试。

4

3 回答 3

7

事务中所做的更改仅在所述事务中可见。同样将测试包装在事务范围内（如果可能）会使测试在一个非常关键的方面（事务）表现得与真实事物不同。

最好使用在每个测试套件之前还原的数据库映像。这样，在套件完成并完成验证后，您将删除测试数据库。下一次运行，在套件设置期间，从保存的图像重新创建数据库，处于原始状态，准备进行测试。更好的是拥有一个从头开始部署数据库并在套件设置期间运行该脚本的脚本。

顺便说一句，在每次测试之前恢复到原始状态是不可行的。更一般地，具有冗长的单独测试设置和清理步骤是不可行的。随着您添加更多测试，在测试之间将数据库恢复到测试就绪状态所花费的时间将变得难以管理。包含数百个测试的套件非常常见，数万个测试的完整测试运行意味着仅花费数小时和数小时来恢复数据库以进行测试。设计您的个人测试，以便它们可以独立运行，即。即使测试 N-1 失败，测试 N 也必须产生有效结果。

要考虑的另一件事是失败调查，您希望失败的测试使数据库处于可以调查有意义的信息的状态，并且您希望后续测试能够运行并产生有效结果。有时这些要求会相互矛盾，但您必须考虑它们并围绕它们设计测试。

于 2009-09-24T06:12:27.103 回答
7

如果将数据库恢复到已知良好状态所需的数据量禁止删除/创建脚本，并且您正在 SQL 2005 的 Developer 或 Enterprise 版本上运行测试，则可以考虑创建良好状态的数据库快照，并在每次测试前恢复它。这比完全还原要快得多，尽管如果您有数百个测试，它可能仍然太耗时。

于 2009-09-24T07:27:06.437 回答
0

不要错过我在这个相关问题上推荐的失忆症。

于 2011-12-06T19:40:56.020 回答