“事务回滚测试”你知道吗？

lsekfe

前些天有个朋友问测试事务的回滚有什么建议，当时结合自己的实际工作经验简单说了一下，之后就开始思量着写点什么作为经验总结和沉淀，于是就有了这篇博文。
　　相信你对事务这个概念不会陌生，它是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。由于计算机可能会因停电、网络中断等而出现故障，因此有可能更新了一个表中的行，但没有更新另一个表中的行。如果事务中的某个点发生故障，则所有更新都可以回滚到事务开始之前的状态。如果没有发生故障，则通过以完成状态提交事务来完成更新。我们测试的目的就是为了确保在事务中某个点发生故障时，所有更新都可以回滚到事务开始之前的状态。
　　通常事务回滚会以单元测试的方式进行覆盖，那如果不是单元测试，而是功能测试，要如何进行测试呢？在掌握了事务及事务回滚的概念后，我们可以想到，只要事务中最后一个节点发生故障，那事务回滚后，最后一个节点之前所有的更新都会不会成功被更新到数据库中。那么我们只要知道某个事务会依次对哪些表进行操作，并对最后一个表或最后一个表待更新的数据库“动动手脚”，人为的使事务提交失败而回滚，然后在程序执行完后查看这个事务将要操作的表是否有数据更新就可以了。知道怎么“动手脚”？你别告诉我你不知道怎么“动手脚”噢~~咳咳，最简单的就是删表、改表结构，或者从业务逻辑的角度将有效的数据改为无效。
　　看到这儿，你是不是对从功能测试角度覆盖事务回滚胸有成竹了，而且觉得它非常的简单？上面说到的是在有多个数据表更新的前提下，用等价类划分方法再一想，那没有多个数据表的更新的事务怎么测试它是否成功回滚呢？以mysql数据库为例，如果这样的事务失败而没有回滚，数据库资源很有可能会被占用一段时间，因为没有程序告诉数据库要收回资源，直到mysql自己回收资源。所以理论上来说，第一次失败后，连续的执行第二次，即使不人为使事务回滚也会导致事务提交失败，因为你要访问的资源已经被占用了。你也可以通过“SHOW PROCESSLIST”来查看是否有有进程长期访问某个数据表或数据行，从之前测试的经验来看，SELECT语句会占用大概一分半钟不释放，这种情况可能不会导致数据库更新不一致或不完整，但是严重影响数据库的性能。之前我接触的开发中就有人以为没有数据更新的事务出现异常不需要回滚，而被测出来有问题。
　　说了这么多，总结下来也就两点，一个是多个数据表有更新的事务回滚，另一个是没有多个数据不更新的事务回滚。一般涉及事务回滚测试，算是比较深层次的测试，在一些对业务数据准确度要求比较高的项目中，通常都会需要测试进行事务回滚测试。