摘要：自动化测试用例执行时经常遇到因为测试数据变更，导致用例执行失败的问题。这时候就需要对自动化数据本身投入人力/时间来维护了。那有没有什么方法可以尽可能减少自动化数据维护的成本了，尽量让自动化数据长期处于稳定状态呢？下面就自己一些经验和感悟，聊聊自己的一些体会。
一、问题背景
自动化测试用例执行时经常遇到因为测试数据变更，导致用例执行失败的问题。具体的测试数据导致自动化执行失败的场景，大致可以分为如下几类：
1、测试数据，由于系统的定时任务，动态变动等原因，不满足自动化的执行需求了
2、测试数据由于是公用数据，其他测试人员/开发同学修改了/删除了对应的数据；
3、不同测试环境中的测试数据不共享，导致在测试环境A中跑通的case，在测试环境B中跑不通了；
上述无论哪种情况，跑自动化case的结果都是失败了，进而执行case的同学不得不费时费力去分析为什么失败，进而继续”修复“case，再将case执行起来。最后需要在下面的循环中不断维护case：执行case——>case失败——>排查case——>修复case。面对这样一个循环，自己在项目中的体会颇深，特别是项目频繁变动时期，往往还需要维护自动化数据，确保自动化case的运行通过。一方面此时维护自动化数据的人力投入很大，另一方面也容易分散精力，最终并没有达到预期的投入产出比。
那么，有没有什么方法，能够减少在上述不断维护case中的人力、时间的耗费呢？毕竟，如果大量时间&精力都花在了自动化case维护上，甚至投入比手动测试还要大，那么我们还有什么必要来维护自动化case呢？下面就自己在自动化数据维护方面的一些实践经验，说说自己在这反面的一些心得体会。
二、自动化测试数据维护需要考虑什么？
自动化测试数据维护的根本目标是尽可能确保每次自动化case运行的成功，尽可能高的测试覆盖率。为了达到这个目标，就要求自动化数据在每次自动化运行时的稳定性，即自动化数据在数据的量级上、单条数据的内容上都应该是尽可能稳定。
当然了，自动化数据的维护粒度也需要考虑自动化case的检查粒度。因而，自动化数据的维护，需要考虑以下几个方面：
1、自动化数据的数据量/数量级。这里的数据量/数量级，具体应该准备多少合适，其实没有一个硬性标准，总的原则是：自动化数据的数据量/数量级，至少需要满足自动化case检查的需要。当然了，如果测试环境、数据库、人力资源扛得住的情况下，多多益善。
举个例子，一个自动化case检查了排序功能，假如第一次运行时有10条数据(当然了，多了更好)，运行也通过了，那么可以认为排序功能没有问题。但假如第二次运行时，由于某种原因，只有1条数据了，这种情况下，即使自动化case运行通过了，由于数据量太少，也不能确定排序功能没有问题。
2、自动化数据满足测试场景的要求。为了确保自动化尽可能高的测试覆盖率，测试数据需要尽可能满足多种测试场景的需求。
举个例子，假如某个功能点的完整测试需要10种测试场景，那么测试数据至少要准备这10种测试场景需要的输入数据。当然了，假如你只有5种测试场景需要的数据，自动化case是可以运行通过的，只是你的覆盖率不会太高而已，甚至可能由于遗漏测试场景导致问题遗留到了线上。
3、尽量避免自动化数据的”动态变化“。这里的动态变化分为两种：
1）人为操作造成的变化。比如，为了某种调试/测试需要，删除/修改了某些自动化case用到的数据
2）系统实现造成的变化。比如，系统存在定时任务，会定期刷新某些自动化case用到的数据
为了保持尽可能高的测试覆盖率，那么我们需要做到前面的1、2条；另一方面，为了尽可能保证自动化case能够重复执行，我们需要尽可能避免自动化数据的”动态变化“，即确保自动化测试数据的稳定性。下面就如何保证自动化测试数据的稳定性，来谈一谈自己在这方面使用过的一些方法。
三、自动化测试数据稳定性方案
自动化测试数据维护，为了在长期自动化运行中保持其稳定，一般可以考虑如下原则：
1、与其他测试数据解耦合。满足需要的前提下，将自动化数据与其他测试数据解耦合，形成自动化专用的测试数据，即可以有专用的自动化测试数据库。
2、采用独立的数据集。满足需要的前提下，虽然只有一个测试数据库，可以将自动化数据与其他测试数据在业务上隔离开。比如，自动化数据采用账号A操作，其他测试采用账号B来操作
3、约定自动化数据范围。满足需要的前提下，当一批数据打标后，与其他同学约定：打标的数据为测试数据，不可随意增删改。
以上方法是从自动化测试数据能够长期稳定、尽可能免收”篡改“的角度，来维护数据的。但具体到每个业务中，可以参考以下的方法，并结合自身的业务特点，综合考虑、权衡利弊后，形成自己的一套自动化数据维护方案。
方法1：前置数据构造
这种方法的出发点是：既然自己之前使用的自动化数据可能被程序更改、或人为操作，导致自动化数据无法为自动化case反复使用。那自动化数据就不再反复使用了，而是每次运行自动化case前，先把其需要的测试数据”造“出来，接着再运行自动化case。在实际项目中，自动化整体执行大致分为如下步骤：
1）先自动化进行数据构造(比如，调用接口、SQL等方法插入所需数据)
2）运行自动化case
3）自动清理数据(比如，调用接口、SQL等方法删除所需数据)
这样这些自动化数据被程序更改、或人为操作的可能性就大大减少了。当然了，凡事没有绝对。这种前置数据构造的方法虽然将自动化测试数据被“篡改”的可能性大大降低了，但仍然可能由于系统本身的一些实现(比如：定时任务自动刷数据状态等)、或人为操作等，导致数据被“造”出来后，自动化case执行前被“篡改”了。
这种方法的优点显而易见了，但其缺点也不得不说，而且在某些数据库较多、且表关联十分复杂的项目中，此种方法的弊端就更多了。举一个自己身边的经历：当时有一个项目A，需要自动化。某几个接口涉及的表大概有十几个，而且要根据一张表的数据，去造另一些表的数据。而表的结构又频繁的变动，这种模式下维护起来的自动化数据由于耗时很大，自动化的维护很滞后了（往往是上线后才维护起来的），进而其发挥的作用也大打折扣了。
当然了，某些场景下，这种前置数据构造方法新建处理的数据是不适用的。比如，存在定时任务的场景，或存在消息机制、与第三方交互，并且第三方有回调的场景、有跨端/跨业务的场景。特别是当数据构造属于第三方的业务时，你就不得不”求助于“第三方的同学了。
方法2：数据监控
这种方法的出发点是：既然自己之前使用的自动化数据可能被程序更改、或人为操作，那么就实时监控自动化case用到的数据，一旦发现这些数据不符合要求了，立刻告警出来、或自动对数据进行维护。在实际项目中，整体执行大致分为如下步骤：
1）利用现有数据/创造某些自动化需要的数据
2）利用监控，检查自动化数据是否符合要求
3）一旦发现数据不符合要求，但发出告警/自动修复数据
......
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第五十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
