2

我们的团队 (QA) 面临以下问题：

我们有一个数据库，只能由我们的应用程序访问，该应用Core程序是一个WCF services应用程序。我们的客户端应用程序正在使用Core访问数据库。

在某些时候，我们获得了我们的新版本Core application和我们的Database. 该Dev部门还给了我们一个 sql 脚本，它改变了我们的database Core data. core data用于描述我们系统的Core Application逻辑，因此对该数据的每次更改都可能影响我们客户端应用程序的任何功能。

我的问题是：

  • 我们应该再次测试我们所有的应用程序（即使它们已经完全测试）还是有更有效的方法来测试 SQL 脚本？
  • 是否有用于数据完整性/迁移测试的测试技术/工具？

在运行迁移脚本后，我正在寻找对数据库的快速有效性/完整性测试。这将防止我们通过应用程序对其进行测试而浪费时间。如果有效性/完整性测试成功，那么我们可以测试应用程序。

4

4 回答 4

2

有可用于 T-SQL 的单元测试框架。TSQLUnit项目就是这样一个框架。您可以使用它来设置自动化测试，就像在应用程序中一样。

于 2012-05-17T14:45:17.063 回答
2

正如@Tim Lentine 已经发布的那样，我建议测试完整的应用程序。正如您所评论的，根据您的描述，您的团队收到的新 sql 脚本在结构和数据本身方面对数据库开发的核心进行了重要更改。因此，为了确保一切都在一块，我最好做一个完整的应用程序测试。至于工具或技术，我可以推荐名为“SQL 测试”的 SSMS 上的新 RedGate（不，我不为他们工作）插件。它使用单元测试开源 tSQLt来实现其目的。它唯一的缺点是有人需要首先学习如何使用 tSQLt，但它很简单。

于 2012-05-21T07:23:43.213 回答
1

根据您给出的描述：

我们有一个只能由我们的核心应用程序访问的数据库......我们获得了一个新版本的核心应用程序和我们的数据库......

告诉我单独测试数据库不是您的团队的责任，但您可以从客户的角度测试核心服务，因此假设数据库是正确的。

将 Core 应用程序和数据库视为黑盒并使用单元测试进行测试。这些测试不应该要求您在数据库中四处寻找，因为任何使用您的核心应用程序的应用程序都不知道也不应该关心信息实际上存储在数据库中的所有意图和目的。您的开发团队可能会在 6 个月内决定将数据存储在云中，在这种情况下，您的所有数据库测试都将被破坏。

如果您确实必须查看数据库以检查数据是否已正确存储，那么您的核心服务接口存在问题，因为您输入的任何数据都应该可以通过相同的接口检索（我只知道有人会评论他们的应用程序确实存储了无法回读的数据，但如果没有更详细的应用程序描述，则更容易概括）。

回到现实世界，我假设您是 QA 团队的一员，除非数据库开发人员正在进行一些测试（他们是，不是吗？），否则您很可能必须验证数据库更改。

最后，您可能有兴趣阅读我在 DBA Stack Exchage 站点上发布的关于在两个不同模式之间执行数据比较的问题。剧透：没有简单的答案。

于 2012-05-24T20:27:03.420 回答