SQL测试最佳实践

Question

除了自动化测试之外，SQL测试（存储过程，视图，查询，触发器......）的最佳实践是什么？ 大多数情况下，查询工作或返回数千行，因此检查它们有点困难。我想知道你通常如何测试SQL查询。 你能指点我一个好的（在线）参考吗？

Answer 1

尝试消除额外的变量。

如何做到这一点：

• 每个测试只应测试一个功能（视图，存储过程等）
• 使用已知的测试数据（它应该来自真实的环境（但实际上不是真实的环境）
• 使用最少量的测试数据来充分测试该功能。

Answer 2

对于插入，更新，删除，我在运行proc之前和之后检查表的状态，以查找符合插入更新或删除条件的记录。因此，如果我要添加7条记录，它们不应该事先在表中，并且应该在那之后。

选择拥有数千条记录可能会更难。没有什么可以替代实际了解您的数据以及您期望获得的数据。例如，我知道某个客户有大约2000名销售代表。如果我运行一个应该包含所有代表的查询，并且只有大约1000个，我知道有些问题。有时我会将查询结果放入临时表中，因此我可以对其运行统计信息。如果我正在做一个与会者报告，我可以看到根据我的查询在该时间段内报告中有200个不同的会议。如果我只看那张桌子并看到同一时间内有350次会议，我会去看看除了会议的内容，并且通常会查看一个或多个被排除的会议的详细信息以及相关的表格，看看为什么会这样没有出现。通常，您会发现需要考虑的状态或某种不良数据。

我也在寻找重复的记录。如果我期望每次会议有一条记录，并且同一次会议在那里两次，我知道其中一个连接表的记录比我对查询条件的预期要多。

我经常要求我们的一些操作人员查看报告查询的结果。因为他们比我更接近数据的使用，他们经常会发现我不知道的事情。

另一种技术是故意将用于测试的where子句限制为可以实际手动检查的较小数据子集，以查看您所期望的是否是您所获得的。如果您有大量计算或复杂计算，这将特别有用。无论何时我进行复杂的计算，我都会查看一个典型案例的原始数据，并从原始数据中手动计算公式，然后我可以查看我的查询中是否正确。

触发器我首先将它们编写为常规查询（在首先为#inserted和#deleted创建和填充临时表之后）进行测试。我确保将多个记录添加到临时表中，因为每个触发器必须能够正确处理多个记录插入/更新或删除。然后我编写代码来显示之前的状态和after状态，并将它全部放在一个事务中，这样我就可以在测试时回滚它。