几年来，我一直在使用一个名为 qmTest 的测试工具，它允许我为一些 Firebird 数据库进行测试驱动的数据库开发。我为一个新特性（表、触发器、存储过程等）编写一个测试，直到它失败，然后修改数据库直到测试通过。如果有必要，我会在测试上做更多的工作，直到它再次失败，然后修改数据库直到测试通过。一旦功能测试完成并通过 100% 的时间，我将其保存在数据库的其他测试套件中。在继续进行另一个测试或部署之前，我将所有测试作为一个套件运行，以确保没有任何问题。测试可以依赖于其他测试，结果会记录并显示在浏览器中。
我敢肯定，这里没有什么新鲜事。
我们的商店的目标是在 MSSQLServer 上实现标准化，我想使用相同的过程来开发我们的数据库。有谁知道允许或鼓励这种开发的工具？我相信 Team System 确实如此，但我们目前不拥有它，而且可能在一段时间内不会拥有它。
我不反对脚本，但会欢迎更多图形环境。
有什么建议么？
Team System is probably the best-known solution, but you could also try TSQLUnit (SourceForge).
I haven't used it myself, but this article does a decent job of introducing it.
在我无法访问 db pro 的团队系统的项目中，我使用了结合 msbuild 的 sql 脚本和用于 msbuild 的 sdc 任务库（http://www.codeplex.com/sdctasks）。msbuild 脚本调用 sdc 任务以特定顺序（例如创建数据库、创建表等）和特定连接字符串运行我的 sql 脚本。脚本始终检查对象是否存在并首先进行拆卸并重新构建它。
我将 sql 和 msbuild 脚本放在一个常规的 Visual Studio 数据库项目中（没有什么特别的，所以你可以选择使用一个简单的空项目），所以一切都是源代码控制的。
使用这样一组脚本，您可以为每次测试运行设置一个新数据库。然后，您可以使用插入脚本来填充数据并针对它运行单元测试。
这些脚本对于在不同环境（DEV/TST/QUA/...）中从头开始设置数据库也很有用
Checkout http://www.sqlservercentral.com/articles/Testing/66553/ and http://www.sqlservercentral.com/articles/Database+Design/66845/
This is a fairly crude article about doing everything within T-SQL.
Have you thought about using NHibernate and using TestDriven or similar just for the tests?
我能够使用 TSQLUnit 对 SQL Server 数据库充分应用测试驱动的开发风格。我遵循与您描述的相同的流程，首先编写一个失败的单元测试存储过程，然后进行必要的更改以使测试通过。随着时间的推移，我还在执行时建立了一套测试，验证了在进行任何新更改时没有任何问题。
有一些难点（包括为现有存储过程编写测试的极端困难），但它特别适用于模式更改。但是，我建议查看TST T-SQL Test Too1，它与 TSQLUnit（我必须自己动手）不同，它内置了对断言的支持。