在测试中怎样对的测试数据进行建模
作者:网络转载 发布时间:[ 2013/1/8 15:22:07 ] 推荐标签:
A模型是:
user.性别 : {"男" , "女" , "不知道"}
user.年龄 : {"10" , "20" , "30" , "40"}
B模型是:
user.状态 : {"未认证" , "认证" , "删除" }
user.等级 : {"新人" , "熟练手" , "砖家" }
每个模型都必须有一个的名称,目的是为了方便测试设计和交流。比如这个Test Suite(一组Test Case的集合)需要使用A模型,那个Test Suite需要B模型。这里的A、B只是一个代号,真实工作中可以根据产品特点重新定义命名规则。
测试数据模型的真正内涵是:把业务逻辑关联强的数据对象属性聚在一起建立group,并列举出需要的属性值,方便测试用例的设计,更为重要的是,模型让开发和测试在围绕“测试数据问题”进行讨论的时候,有一个标准。由于模型里面已经封装了很多信息,只要指明模型的名称,交流变得更加简单了。
当然文章里这个案例的逻辑非常简单,实际工作中并不需要测试数据建模,不过当数据对象比较多时,价值能体现出来了。比如淘宝的下单,可能会出现这样的数据模型:
商品.价格 : {"",""}
卖家.状态 : {"",""}
买家.所在地 : {"",""}
类目.XXX : {"",""}
复杂的数据模型,可能会有10个以上的数据对象属性。不过我们不能把所有对象属性,都堆在一个模型里,那样没有任何意义,我们需要根据业务逻辑对属性进行分类,建立不同的模型,比如优惠、运费计算是不同的业务逻辑,因此需要建不同的模型。而围绕优惠这个概念,还会根据不同属性组合关系,建立多个模型。
我想每个测试场景,需要建立的数据模型并不会很多,2、3个左右。数据模型必须是常用的,这样才有实际意义。时间久了,研发团队每个成员的脑海里,对于测试数据模型的概念,会越来越深刻,甚至对于模型里的某个Test Case,如果被执行的次数够多的话,也会被大家记住。到时候Test Case也会需要名称,为了方便大家记忆交流。
在实际工作中,开发工程师经常反映,要执行某个Test Case,只修改某个数据对象(比如user)的属性,根本不够,必须要把多个数据对象(比如user、order、item)同时修改,才能完成。这其实是一个典型的需求:这个Case需要一个复杂的测试数据模型。
当测试数据模型被大家接受以后,我们可以围绕模型做一些工具开发,来简化准备测试数据的工作。如果工具只能分别修改某个对象的属性,那么可用性不会太好,需要人为进行组合操作。如果工具能以测试数据模型为单元,可以很快生成数据模型里的某个Test Case,这样会大大简化测试准备工作。
需要说明的是,本文是基于工作现状的推理,这种建模方式仅仅是“原型”,还缺少一些佳实践。如果本文的论述能引起你的共鸣,欢迎你在自己的产品测试中试一试。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11