浅谈软件测试之数据校验

注明:DBCheck即数据库数据校验;
一．为什么需要DBCheck?
你同学去年向你借了一万大洋，今天你打电话想他还钱给你，老同学很大方的给你说马上给你打到银行卡上。一会儿，回电话给你说，钱已经全部打到你银行卡了，让你等会儿去查询自己银行卡的来账。可是，你左等右等，等到西湖的水都干了，还是没有收到银行的进账通知......
此时，你该怎么办？你是不是很迷茫？
那么，在我们代码世界几乎很多这种场景。前端发送一个Request给后端进行相关业务的处理(你打电话给同学让他还钱)，后端也顺利的接收到了请求并给你返回正确的Response(同学回电话说钱已经给你打过去了)，但是，后端实际上却没有按照要求给你处理好前端的请求，比如:实际上没有给你进行数据库的增删改查或者对数据库操作错误了。
就像上面的例子一样，为了查清楚同学的钱是不是打错了，得让他去银行查下打款的对方账户是不是你的，或者问下银行刚才的打款是不是成功的。
这样，在我们的测试过程中，能够确定前端请求是否正确:1.如果是操作后台数据的请求，那么测试在发送请求后必须要进行数据库校验了，也就是文章提到的DBCheck，只有这样才能保证请求达到设计的目的；如果是请求新的资源(获取新的页面、下载后台资源等等)，就要求跳转后的页面是否是前端想要的结果......
这里，我们只论述前者，前端可能接收到后端返回成功就认为后端处理是正确的。但是，测试必须要去验证后端的成功是否是真正的成功，这就要求去验证数据处理的结果--数据库了。
你让同学还钱，你同学给你回复说已经打你银行卡上了.......如果，他说打款到你银行卡就是还钱了，你也认同，那此话题你不用往下看了；如果，你认同只有自己账户的余额增加了且打款方是对方才算对方是还款了，那你也就认同了测试过程DBCheck的重要性了(都是以数据说话)，也请耐心阅读下面内容。
二.如何进行DBCheck
要进行DBCheck，就必须要知道各个请求干了啥。就相当于化学实验，你每添加一步化学试剂就会产生不同的化学反应。在软件编程中也一样，每个请求都会处理不同的业务，不然这个请求就是无效的了，也就没有什么实际意义了。所以，在进行DBCheck之前，你必须要清楚接口请求的功能并熟悉系统的数据库设计，通过接口知道业务处理后落库的数据表及对应的各个字段。接口请求对数据的操作一般包含:增、删、改、查，当我们熟悉请求的后台业务后就能只能知道该请求是对数据进行了那种操作，操作了哪些数据表及各个表的数据是如何进行关联的。只有熟悉了这些，测试者才能真正的知道哪些字段是关键的，哪些字段是该次请求后必须要验证的或者说哪些字段是有意义的。
这里所说的DBCheck不是指对所有的字段都要进行验证，也不是场景A不用验证场景B也同样不验证，所有的测试工作(测试用例)都是根据测试的目的来设计的。例如:某个用户注册的接口(需要短信验证)，数据库要insert用户注册是用户名、登录密码及其他的用户资料，但数据库同样会保存住户注册提交的时间及系统发送验证短信的时间。我们在进行测试注册功能的时候，就只需要Check用户提交的信息就可以了；但是在测试用户注册时验证短信发送的性能(提交注册到发送验证短信的响应时间差)时就必须要验证两个时间差是否满足性能要求了。
总而言之，DBCheck就是在后台response之后通过查询数据库来比较数据库中的实际值与期望值是否相等。那么，DBCheck的步骤就是：
1.准备工作:
a.设计对应的测试用例及准备测试数据，弄清该接口的业务逻辑及确定最后落库的表和对应的字段（字段是否有价值需要根据不能的业务不能的场景及本测试用例的目的来确定，不是唯一的）；
b.根据测试数据准备好需要Check表及字段的sql语句及期望值；
2.执行阶段
a.系统发布后，执行测试用例，当用例的实际结果和期望结果相同时则该用例通过(此时DBCheck也肯定是通过的)，否则测试用例失败；
三.自动化测试的DBCheck思路
上面说到，前端Request之后后台一般对数据库的操作包含了:增删改查，我们只需要根据不同的场景准备好测试数据及对应的sql语句来验证数据库即可。
可能有同学说，准备sql语句不是应该很简单的吗？直接在各个测试用例的后面附上事先准备好的sql即可。但是，现在测试的门槛越来越高，越来越多的公司要求进行自动化测试。本小节就如何简单、明了、方面地准备复用性强的自动化DBCheck。
竟然DBCheck的本质就是要比较数据库的实际值与期望值是否相同。目的明确了，那现在就分解下内容，1.查询的条件该怎么写(where);2.实际值和期望值该如何比较(也就是常说的Assert)；
先看where部分：
一般在测试过程中，where后的条件比较简单,常用的就是select from tablename where columnname = ‘value’ 或者就是 select from tablename where columnname in (‘value1’,‘value2’)
再看Assert部分(数据的验证规则)：
可能在整个DBCheck中难点的地方就在于数据库的实际值和期望值的Assert方式多种多样，1.实际值和期望值是否完全相等(也就是常说的equal);2.只要求某一字段实际有值即可;3.要求比较该字段值与另外值的差值;4.要求实际值是某些值中的任意一个即可;
上面已经列出了DBCheck的要点，后面需要做的就是封装一个完整的类来实现上述的所有情况，这样下次就可反复的使用了。再者就是将其在控制台做成可视化的形式。作者本人是通过csv文件来进行数据准备的，DBCheck的结果如下图所示:

四.DBCheck的其他注意点
在实际中，还应该考虑到前端request后后台处理数据并数据落库的时间，如果机器性能不好数据落库慢，此时直接去进行DBCheck肯定会导致DBCheck失败的，应该考虑进行间隔时间多次DBCheck后失败才算真正的DBCheck失败。
五.欢迎关注作者公众号平台