通过 C# 测试测试你的数据库

Question

我被分配了测试我们的数据库的任务。它是一个测试数据库，我们可以对它做任何我们想做的事情并轻松地回滚它。我被赋予了这项任务，因为我们仍处于设计阶段（这意味着在项目的任何时间点都可能发生任何更改......将 Person.FirstName 列重命名为 [First_Name]，然后将其重命名为 [名字]。我的目标是粗略估计我们在进行更改时会遇到什么样的痛苦，以便我们可以提前计划。我们也可以在生产过程中预期这些类型的更改。

我的清单上的项目是并且已经针对以下项目进行了书面测试：

• 发送单词 null（不是字面的 null，而是“null”），因为使用动态 SQL 可能会认为您真的是指 null。我们发现这一点是因为姓“null”的人导致抛出异常。

• 使用单引号是因为动态 SQL 不可能使用单引号。再一次，有人以他们的名义造成了崩溃。

以前从未这样做过，这就是我所知道的可能崩溃的全部内容。还有其他想法吗？我们正在尝试模拟用户可能输入的数据。

编辑 1：我们的问题是我们有一个搜索屏幕，其中包含大约 25 个可以搜索的字段。其中一些搜索字段很简单（例如名字），一些不太简单（类别 1 的日期小于 2，但也有类别 2 的日期大于 2 或在任何时间段都有类别 4）。搜索屏幕允许用户使用这 25 个字段中的每一个字段选择不同的操作符和谓词。有没有比动态 SQL 更好的方法来处理这个问题？我处于一个位置和时间点，如果它更好，我们可以改变一些不同的东西。

编辑 2：我不知道是否值得一提，但我们使用 LINQ 来访问存储过程。我的研究表明，动态 LINQ 不会像动态 SQL 查询那样做我们需要它做的事情。不过可能是错的。

Answer 1

“'; Drop Table Person;--”也会导致崩溃吗？

您确实应该考虑将策略从动态 SQL 转移到参数化查询，以避免 SQL 注入技术。

至于数据库的 C# 测试，您可以使用事务化查询和 nUnit 进行单元测试——这是一种时尚。严格来说，单元测试应该将您的应用程序与数据存储区分开，以便可以测试组件部分而不会因访问和修改数据存储区而造成性能损失。但是，如果您决定这样做，您可以使用非常相似的技术来测试您的数据存储。在 TestFixtureSetup 中创建事务并在 TestFixtureTearDown 中将其回滚，这样您的数据库将在测试完成后恢复到原始状态。

您当然应该知道，以这种方式测试数据存储时会降低性能。您的单元测试不会像您的应用程序的其余部分那样执行 - 假设您的应用程序的其余部分进行了性能调整。