自动化测试数据之可不可复用

发表于:2011-11-11 10:12

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:刘毅    来源:51Testing软件测试网原创

  摘要:我认为测试数据不仅是自动化测试的核心要素,也是所有类型的测试所共有的一个基本元素,离开测试数据的测试基本上就丧失了它的可靠性与意义。当然,对于自动化测试来说,它对测试数据的使用和管理又有着它自己的特殊要求:可反复使用、能够自动生成或更新,可轻松迁移……可能有些人对一个系统拥有三、四套乃至更多的测试环境,同时存在多个版本的并行测试没有概念,那么这些人在自动化测试的其他方面要有着更高的追求,但是对于测试数据来说,却从不曾为之忧心和烦恼。

  关键字:自动化测试;测试数据;回归测试;数据复用;存储过程

  需求背景

  我们的应用是基于Weblogic和Oracle的B/S结构保险业务系统,应该属于标准的J2EE架构。自动化测试力量现阶段集中在UI层验证测试,主要应用于系统测试中的冒烟和回归测试。常规版本周期从半个月到一个月不等,紧急需求或生产缺陷引发的非常规版本测试周期从一个工作日到一个月不等——想必比起互联网应用的发布速度,我们算是比较宽松的。虽然比较宽松,但是由于系统耦合度极高,业务逻辑极其复杂且不具有通用的规则引擎,数据种类千变万化,系统内外关联影响很大,我们任何一个版本的任意一个小小的改动点都有可能引发生产L-1级别的程序缺陷乃至重大故障。考虑到关联影响的分析太过依赖个人能力,不具备高度的可复制性和易推广性,所以我们对回归测试和的要求很高,也是因为对回归测试的要求很高,我们对冒烟测试的要求也很高,并且要求能够快速完成。

  逆向思考

  最初我们纠结于可用的数据如何从数据库抓出来,抓出来之后是直接使用还是先做本地存储然后定期更新。后来我们发现无论如何操作,从一个4TB数据库中抓取可用的数据似乎又是一个漫长的过程,尤其是部分同事对SQL效率优化没有太多概念的时候,测试脚本常常因此运行太长时间而被自动化测试管理平台的超时控制机制强行终止。即便是获取数据的速度不慢,而有些特殊业务的数据量也不能支持长久的测试运行和测试环境的切换,依赖上游数据的产生根本不具备及时性和稳定性。

  似乎我们大部分人反对使用固定数据进行测试,因为这个观念从自动化测试入门开始就被灌输到我们的脑子里了,绝大多数接触过自动化测试的人都知道测试脚本需要参数化,并且实现测试数据和脚本操作的分离。参数化和数据分离是正确的,只不过数据分离并不代表测试数据不可以固定使用,如果一条数据可以进行千万次的对系统的功能验证,只要它是有效的,我们是否非要去不停地更新掉这条数据呢?我觉得未必!其实我们所说的固定数据更多的是指,在一个功能点中存在多种数据处理方式,也就是存在多个代码分支的情况下,只使用一条或几条相同的数据去覆盖其中的一个分支。那么如果我们能够去分析一下这些代码分支,针对不同的逻辑分支去构造数据进行测试,那么每一个分支上的测试数据即便是固定的,测试遗漏也不会比我们的正交覆盖更多。所以,只要我们努力理清代码的逻辑分支,并且实现测试数据的使用完回退,那么测试数据的固化对于自动化回归测试来说并没有什么问题。

  因此我觉得,只要参照被测功能的代码,在数据库层面书写被测功能的逆向数据状态转换过程,在测试运行之前进行调用,那么每一次测试执行都可以使用同一组数据去进行。而且,这种方法的一个最大优点是,我们可以很轻易地在代码中找到每一个终止条件,我们就可以编写对应的判断,让我们的数据依据被测程序代码逻辑来构造。而后在本地的数据源或者文本中存储这些数据,运行时引用并且有针对性(按照指定的数据修改比全库查询更加快速)的进行修改,使其满足运行的需要,运行过程中出现的任何异常都可以交给每天的定时任务去清理,完成对数据场景的恢复和还原。那么这种解决方案到底如何实施并且对我们的测试能起多大作用,我们下面通过一个简单的养老险保全项目来看一下。

  ……………………

  查看全文请点击下载:http://www.51testing.com/html/54/n-247254.html

  ● 对于同一保单下操作的互斥性,我们使用通用的过程去处理,其代码可参见下表。而对于任何异常引发的运行失败或中断,考虑到我们可能需要及时重新运行,那么我们也可以把异常数据场景的恢复纳入这么一个过程中,把所有已经写入临时表但是尚未保全确认的数据全部清理掉。作为所有保全项目的公用代码,下面这个“按申请号撤销指定的保全申请”这个过程代码样例虽然简单,但实际上包含数据的修改删除是非常多的,这里不再赘述。

撤销当前保单下所有与将要发起的任务互斥的申请(鉴于篇幅有限,下面省略代码若干)

procedure cancel_alltask_mutexing(p_policy_no     in varchar2,

                                   p_endo_type in varchar2is  

  cursor c_get_mutex is

select distinct apply_no

 from pos_base_info

where policy_no= p_ policy_no

  and pos_item_type in

    (select distinct mutex_pos_item_code

      from pos_mutex_setting

    where current_pos_item_code = p_endo_type)

       and pos_status not in ('0', '2', '8');

--查询出所有与当前保单所要发起申请互斥的未完成申请任务

v_apply_no pos_base_info.apply_no%type;  

  begin  

    open c_get_mutex;

    loop

      fetch c_get_mutex

        into v_apply_no;

      exit when c_get_mutex%Notfound;

cancel_appointed_task(v_apply_no);

commit;

    end loop;

    close c_get_mutex;

  end;

按申请号撤销指定的保全申请(鉴于篇幅有限,下面省略代码若干)

procedure cancel_appointed_task(p_apply_no in varchar2) is

--修改保全申请状态和工作流状态控制表

update workflow_data_table set current_step = '90', current_processor = null where apply_no = p_apply_no;   

--作为一个通用的过程,这里需要删除和修改数十张临时表

delete from processing_xxx_temp where apply_no = p_apply_no;

delete from processing_xxx_detail where apply_no = p_apply_no; 

--修改保全申请互斥控制数据

update task_mutex_info Set isdel = 'Y' where apply_no = p_apply_no;     

--删除已经生成的财务数据关联

delete from finance_collection where apply_no = p_apply_no; 

end;

21/212>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号