摘要:自动化测试用例执行时经常遇到因为测试数据变更,导致用例执行失败的问题。这时候就需要对自动化数据本身投入人力/时间来维护了。那有没有什么方法可以尽可能减少自动化数据维护的成本了,尽量让自动化数据长期处于稳定状态呢?下面就自己一些经验和感悟,聊聊自己的一些体会。
一、问题背景
自动化测试用例执行时经常遇到因为测试数据变更,导致用例执行失败的问题。具体的测试数据导致自动化执行失败的场景,大致可以分为如下几类:
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内容的全部版权,未经明确的书面许可,任何人或单位不得对本网站内容复制、转载或进行镜像,否则将追究法律责任。