业务测试痛点（一）---解决复杂场景的合同再造

迭代测试进行到中期时，简单场景的测试与bug修改基本完成，开始尝试复杂场景的测试。

制作复杂的场景包含的步骤很多，并且一步接一步，步骤前后得卡着服务器时间来进行，遗漏步骤会导致构造的合同不符合预期场景而作废，步骤顺序错误也会导致合同不符合预期场景而作废，制造时间在30-40分钟。

个人的测试习惯：总是对bug进行二次确认再提交，确认的过程是对bug的确认，也是更清晰的梳理操作步骤和整理需要提供的bug数据，方便提交bug时清晰的展示问题的出现过程。

试想，两次进行这种数据的制造需要花费的时间和精力，这不包含如若出现差错而导致数据不符合预期，那时心里真的很崩溃的，再造数据又得花费相当的时间和精力，影响测试进行。

越早解决这个痛点，保证源源不断的测试数据，就能为测试进度和质量，甚至bug的修改建立最根本的基础。

这里为什么会涉及bug的修改，原因是这样的：开发同事在修改bug时，如果能带着数据去走断点查看错误发生点，就能直观地查找到问题点并解决。所以开发同事对数据有着和我们同样的需求，同样的需要产生在bug复测阶段。

那么开工把！

理论上讲合同经过业务代码正向符合预期的形成，那么我们就可以将库中数据逆向还原到任何点上。道理讲得通，但是还没怎么写时就发现，这里是个坑。不同的合同不同的出账方式不同的时间点上业务代码的处理都是不同，按照逆向还原的思路来，我们是要逆着重新写一个业务系统出来，显然是不可行的。

那有没有其他办法？

Navicat中右键单条数据包含的一条操作是复制为insert语句，这里给我启发。

能不能在数据发生变化前备份这份数据相关的所有insert语句，如果在进行操作后发现bug，多次使用备份的数据进行确认，修改、复测即可。

围绕这个思路，分为三个步骤。

1、在数据发生变化的步骤前备份数据的insert语句

2、出现bug

3、使用备份数据确认、修改、复测

具体需要做的是：

1、新建copy表，包含ID、订单号、SQL语句三列

2、使用INSERT INTO...SELECT复制各张表的INSERT语句到copy表，并且插入订单号

3、将复制时涉及的8-10张表写入存储过程1，设置订单号为in型参数，提供执行效率

4、书写存储过程2，删除订单号原始数据

5、书写存储过程3，执行copy表中INSERT语句

产生错误的数据复现在了错误产生前，单人平均每复杂场景的bug测试时间加快20分钟左右，加快开发修复bug时间正无穷。