什么是事务？
事务（Transaction）是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。对应数据库，它可以是一条或者一组SQL语句；对于程序，它可以是一条或者一组对同一或不同数据源的操作。
事务必须具备以下四个属性，简称ACID 属性：
原子性（Atomicity）：事务是一个完整的操作。事务的各步操作是不可分的（原子的）；要么都执行，要么都不执行
一致性（Consistency）：当事务完成时，数据必须处于一致状态
隔离性（Isolation）：对数据进行修改的所有并发事务是彼此隔离的，这表明事务必须是独立的，它不应以任何方式依赖于或影响其他事务
永久性（Durability）：事务完成后，它对数据库的修改被永久保持，事务日志能够保持事务的永久性
上面事务的每一个属性都能拉出一篇文章来说明，我们在这里就不赘述了。从事务的定义我们可以知道，事务其实就是对数据的一系列操作，这一系列操作要么全部执行成功，要么撤销不执行，对数据源的改变只会在全部执行成功后才会生效，在执行的过程中是不会产生任何影响的。
事务是测试无法忽视的，因为有很多的操作都需要保证原子性。比如A转账100元给B，A的账户会减少100元，B的账户会增加100元，这两步操作只要有一步出错就应该全部撤销，不会对数据库产生任何改变。所以测试在业务初期就需要明确这种功能是需要事务实现的。
通常狭义的认为事务是对于数据库的操作，其实无论对于任何数据存储媒介都可以适用，也就是整体业务数据的事务。但在使用过程中也有可能踩坑。这也本文提醒大家注意的一点。
举个栗子
假设有一个功能有三步操作，第一步及第三步都是对数据库的操作，第二步是调用一个第三方接口，去发送一个推送消息。我们把这几步做成一个事务，其中有一步出错就回滚，行不行？
答案是不行，问题出在第二步。因为推送消息是个发送完就无法撤回的操作，这是违反事务定义的。第一步出现问题还好说，不会有任何的副作用产生；但是如果第三步出了问题，就算回滚了，第二步做的操作也回不去了，所以合理的安排事务中的动作是必须的。
不得不说，测试过程中发现此类问题有点困难，最直接的方式是依靠代码走查，这个对测试人员的走查代码能力要求很高。另外一个方式是了解本次开发中事务的使用细节，创造回滚的场景，最后再通过数据和功能校验来验证是否有BUG。
测试人需关注
对于测试来说，除了需要考虑业务是否有事务的需要及回滚验证，也需要考虑事务中是否调用了第三方接口或功能，对其他资源产生了影响，比如发了消息，那就无法实现回撤了。也同时要考虑一个事务中对于不同数据存储媒介的情况，一步出错，均要回滚。
网友评论