白盒测试SQL的用例设计

最新推荐文章于 2024-04-24 14:26:32 发布

Mindclicer

最新推荐文章于 2024-04-24 14:26:32 发布

阅读量200

点赞数 1

文章标签：测试用例 sql

本文链接：https://blog.csdn.net/mindclicer/article/details/131155470

版权

5月初，我写了一篇《从黑盒和白盒来测试SQL》的文章论述测试SQL语句的一些观点，现在进行一些补充和修正。

原文中将测试SQL的思路总结为2条，

1测试SQL能否正常运行(不要报错)

2测试SQL查询结果是否符合需求和业务逻辑

一. 对总结1的补充

程序的行为大多数时候就是在处理数据，而和数据库相关的行为也可以归为2类，一类是取/存，一类是处理。

结合持久层的交互，一次代码进行查询数据库的流程大致如下：

1编程语言通过持久层代码向数据库软件发送SQL

2数据库返回查询结果

3持久层把查询结果映射为编程语言的数据类型

4编程语言根据代码对查询结果赋值的变量进行处理

所以，持久层的测试是必要的，但不需要和第4步的接口测试混在一起。(持久层具体的测试过程可以看我写的关于MyBatis的文章)

二. 对总结2的补充和修正

假如把SQL中查询得出的数据称为原生数据，而持久层只会做映射，而不会对这些数据进行改动。那么就可以大致认为，对原生数据的改动的来源是SQL函数/group by子句和编程语言。

因为取数据这一行为本身一般只是为了达到某个目的的过程之一，而测试这个行为则是使用预期结果和实际结果进行比对，如果一个行为还没有产生目的，那就是无法或者说不需要测试的。

假设有一个需求是这样写的，模块X需要一个新的查询功能，需要查询具有属性A=1和属性B=2的有效数据。模块X只对应一个表X，所谓有效数据是指没有被逻辑删除，那么SQL语句如下：

Select A,B from table X where A =1 and B = 2 and deleted = 0

由于需求写明了筛选项，所以SQL的编写非常清晰，开发和测试都有着很明确的依据，不会有问题。然而现实是，需求不可能对程序所有的行为都写明步骤，往往只会给出最终的目的，这就给了开发不同程度自由发挥的空间，所以测试人员也将只能根据最终的目的来进行验证。

三. 验证SQL目的的用例设计

编程语言中的函数/方法其实来源于数学中的函数，二者的性质是相同的。可以把每个不同的SQL语句看作是一个个不同入参的函数，我们关注的是程序如何使用SQL语句的输出。在大部分情况下SQL语句的输出都是一个范围，我们要测试这个范围是否正确，要保证不是过大或者过小。所谓的范围过大，意思是有不正确的数据包含在现有的SQL命令输出的数据中，而过小，则是把正确的数据遗漏了。

用具体SQL来对此进行说明，查询一个或多个表时，不写where子句，数据库将返回这些表存在的所有数据，用where子句指定筛选项的值后，输出的数据就变少了，所以可以得出【筛选条件减少，输出范围增加，筛选条件增加，输出范围减少】。

还是以这个SQL为例子，

Select A,B from table X where A =1 and B = 2 and deleted = 0

目前其输出的范围由3个筛选项决定，假如这个输出范围比正确的范围小了，意味着有一些正确的数据被遗漏了，且在目前的输出范围之外。使用上一段得出的推论，我们应该减少筛选条件，扩大输出范围去找到哪些被遗漏的数据，通过它们来验证我们的想法。那么如何快速的找到这些数据呢？

先看一张维恩图：

这张图的重点在于3个圆交汇的中间部分，如果把3个圆各自想象成SQL中的一个筛选项，那么3圆交汇的部分就是同时满足3个筛选项的数据范围。而中间部分还与3个部分相邻，它们一起构成了3片类似花瓣的图形，这3个图形去掉中间的共通部分，其实就是3圆中任意2个圆交汇但不与第3圆相交的部分，用数据来说明，就是只满足2个筛选项，第3个不满足的数据。而这3个部分的数据就是当前SQL的外部边界。用SQL来表示就是这样：

Select A,B from table X where A =1 and B = 2 and deleted <> 0

Select A,B from table X where A =1 and deleted = 0 and B <> 2

Select A,B from table X where B = 2 and deleted = 0 and A <> 1

(<>是SQL语句使用的不等于运算符)

这样的用例设计方法就是将边界值和等价类混合使用得到的，如果上述3种SQL中的数据有正确的，就说明使用了不等于运算符的筛选项是不必要的。

那么上述情况的反向场景，也就是正确的输出范围比当前范围小，这样的情况也能使用类似的方法找到用例吗？

首先，假设我们认为当前输出的数据范围比正确的输出范围大，那么只要从当前的输出中找到错误的数据就能完成验证。

但很明显，穷举法是不可行的，这里仍旧要运用【筛选条件增加，输出范围减少】这个推论。

还是使用同样的SQL作为例子：

假设

Select A,B from table X where A =1 and B = 2 and deleted = 0 and C = 3

才是正确的范围。