database - 您使用哪些最佳实践来测试数据库查询？

Question

我目前正在测试我们的解决方案，该解决方案具有整个“范围”层：UI、Middle 和无所不在的数据库。

在我加入我现在的团队之前，查询测试是由测试人员手动制作的查询完成的，理论上这些查询会返回一个结果集，存储过程应该根据各种相关性规则、排序、你有什么来返回。

这会产生副作用，即针对测试人员的查询提交的错误比针对有问题的实际查询更频繁。

我建议实际使用已知结果集，您可以推断它应该如何返回，因为您控制存在的数据 - 以前，数据是从生产中提取、清理，然后填充到我们的测试数据库中。

人们仍然坚持创建自己的查询来测试开发人员创建的内容。我怀疑很多人仍然是。我认为这根本不理想，只会不必要地增加我们的测试足迹。

所以，我很好奇，您使用哪些实践来测试这样的场景，以及在不引入混乱数据的情况下，什么是您可以获得的最佳端到端覆盖的理想选择？

我遇到的问题是在哪里进行测试的最佳地点。我是否只是直接戳服务，并将该数据集与我可以从存储过程中提取的数据集进行比较？我有一个粗略的想法，并且到目前为止已经足够成功，但我觉得我们在这里仍然缺少一些重要的东西，所以我正在寻找社区，看看他们是否有任何有价值的见解可能有助于制定我的测试方法更好的。

score 3 · Accepted Answer

测试存储过程将要求每个测试人员都有一个单独的数据库实例。这是一个要求。如果您共享环境，您将无法依赖测试结果。他们将一文不值。

您还需要确保在每次测试后将数据库回滚到之前的状态，以使结果可预测且稳定。由于需要在每次测试后回滚状态，因此这些测试将比标准单元测试花费更长的时间来完成，因此它们可能是您想要在夜间运行的东西。

有一些工具可以帮助您解决这个问题。DbUnit 就是其中之一，我也相信微软有一个工具 Visual Studio for Database Professionals 包含一些对 DB 测试的支持。

score 3 · Accepted Answer

以下是一些指导方针：

有关 Enterprises Services Transaction 技术，请参见以下链接：

score 1 · Accepted Answer

作为我们持续集成的一部分，我们每晚运行数据库查询的“构建”。这涉及一组数据库调用，这些调用会根据代码中的实际调用以及任何预期的临时查询定期更新。

这些调用是定时的，以确保：

1/ 他们不会花太长时间。

2/ 他们与前一天晚上没有太大的不同（以一种糟糕的方式）。

通过这种方式，我们可以快速捕获错误查询或数据库更改。

score 1 · Accepted Answer

查询计划器是您的朋友，尤其是在这种情况下。最好的做法是检查索引是否在您期望的时候被使用，并且查询不需要完成额外的工作。即使您的套件中包含压力测试，在您的应用程序开始停止运行之前捕获昂贵的查询仍然是一个好主意。

score 1 · Accepted Answer

我们为每个开发人员和测试人员预留了一个空白数据库。

运行测试时 - 每个测试都会清除数据库并加载它期望使用的数据。这给了我们任何时候一个已知的状态。

然后我们可以在同一个数据库上测试几个不同的场景（一个接一个），我们永远不会踩到另一个测试人员的脚趾。

这包括测试数据访问本身。对于服务测试，我们做了很多相同的事情，但我们只测试服务的内部——我们实际上并没有点击服务，而是创建了一个服务处理类的实例并传递了我们需要的一切。这样我们测试的是代码而不是基础设施（消息等）

score 1 · Accepted Answer

Django 提供了数据库单元测试功能。您可以借用他们的设计理念并在其他环境中进行复制。

Django 人员提供了 Python 标准 unittestTestCase类的子类，该类使用已知的固定装置（一组已知的数据行）填充数据库。

对于 Django（和 Python），从 JSON 数据提取中填充数据库是最简单的。夹具的其他文件格式可用于其他框架。例如，如果您在 Oracle 中工作，您可能会发现 CSV 文件更易于使用。

这个TestCase子类允许编写一个典型的测试用例，用已知的数据夹具来测试数据库。

此外，Django 测试运行程序会为测试目的创建一个临时模式。这对 Django 来说很容易，因为它们有一个完整的对象关系管理组件，其中包括 DDL 创建。如果您没有这个可用的，您仍然需要 DDL 脚本，以便您可以创建和处置用于单元测试目的的测试模式。

score 1 · Accepted Answer

SQLServerCentral在这里有一篇关于称为 tsqlUnit 的 TSQL 单元测试框架的文章（您可能需要注册，但它是免费的且没有字符串）。它是开源的，并且沿袭了 xUnit 框架的传统。

它遵循 SEAT TDD 模式：

设置 - 通过操作对象、表格和/或数据来准备测试条件

练习 - 调用生产代码

断言 - 检查实际结果是否等于预期结果

拆解 - 将所有内容恢复到测试开始前的状态。这实际上是通过回滚事务来完成的，它使一切保持整洁。

虽然我没有使用它，但它看起来很有希望，而且我肯定会更详细地研究它。

该框架可以在这里下载。

score 0 · Accepted Answer

我发现测试发送到数据库的 SQL 而不是查询数据库的结果很有用。

并不是说我不这样做，但我发现测试它比让数据库过多地提升要快得多。

score 0 · Accepted Answer

这是一个繁重的设置，但我推荐 TDDing 容器。

运行测试脚本后，构建一个新容器，在其中运行您的数据库，使用模拟数据为其播种，然后运行查询并测试返回的内容以及查询是否成功。

通过这种方式，您可以控制测试环境与生产的接近程度。

9 回答 9