9.3 测试实现
9.3.1 编写测试用例
性能测试环境大功告成后Peter和Lucy着手准备测试用例。对于用例的准备Lucy并没有实战经验,于是向Peter请教细节。
Lucy:Peter,性能测试用例和手工测试用例写作的方式有什么不同? Peter:本质上没什么不一样的,都是介绍操作步骤,只是更关注脚本创建要用到的优化策略。 Lucy:你说的优化策略是指脚本录制中用到的参数化、关联、集合点这些内容吗? Peter:是的,在实际脚本创建中要用到的技术点我们需要在用例写作中明确下来。 Lucy:那我先看你演示一个,如果没问题就让我写,你来检查如何? Peter:好的,没问题。 |
本次性能测试用例共涉及“首页访问”“用户登录”“浏览商品”“信息检索”和“用户订单”5个模块,详细用例描述如下。
【特别说明】:这里我们可以把一个用例看作是完整的业务场景,在一个场景中可以有一个或多个事务组成,事务数不代表业务数。
【特别说明】:服务器无IP请求限制,意味着我们无需为每个用户分配不同的IP地址进行测试,也就意味着本次测试可以不考虑使用IP欺骗。
【特别说明】:一个用例就是我们后续创建的一个脚本,在一个脚本中可以包含多个参数,但在LR12中最多不能超过64个。如果一个脚本中的参数过多,建议拆分脚本。
3.浏览商品用例描述
4.信息检索用例描述
5.用户订单用例描述
【特别说明】:用户下订单的方式有多种,因银行付款涉及同第三方系统对接,作为教学案例无法正常演示,本次仅考虑对“货到付款”方式进行脚本编写和执行。
Lucy:Peter,测试用例写出来了,请检查。 Peter:很好,没什么问题,剩下的就等我们实践的时候调整和验证了。 Lucy:写完后我有一个疑问,感觉不写用例也能直接创建脚本呢? Peter:(笑)这没什么好奇怪的,用例是设计者脑子里所想的,目前脚本量不大,而且执行人和业务模型分析都是我们,所以你才会有这样的感觉。 Lucy:原来如此,那以后如果项目规模不大,时间又相对紧张,我们可以跳过用例进行脚本创建。 Peter:对,要活学活用,没有什么流程是固定的,适合企业的实际状况就好。 |
学习笔记
笔记一:性能测试用例多用在业务规模较大,且执行人和设计人可能不是同一个人的情况,小型项目可依据实际情况裁剪。但如果是外包项目,用户明确要求提交测试用例,则无论规模大小都应该编写用例。
笔记二:测试用例本身只是初步构想,编写用例的关键还是要熟悉业务,如果业务不熟悉,脚本设计本身就存在问题,后续的实施也会遇到诸多阻碍。即使熟悉业务,在实际脚本创建过程中也会适当调整录制过程和优化策略。
9.3.2 基础数据准备
数据准备一般来讲分为两类:一类是安装软件时系统自带的演示数据(也叫基础数据),另外一类就是为测试工作而提前准备的业务数据,这类数据需要我们在业务场景执行前提前准备。
Lucy发现本次要准备的数据量并不少,手动添加肯定是不靠谱的,于是针对要准备的数据做了一张列表(表9-11)。
【特别说明】:系统要求支持60万的用户访问量/天,而我们需要提前准备100万用户数据,目的是为负载测试提供更多基础数据。
1.用户数据准备过程
以下是用户数据准备过程。
介于需要构造的数据量庞大,一般采用如下两种构造办法:一种是直接在数据库后台找到相关数据库表通过SQL语句插入数据,另一种是利用LR构造随机数据,并执行脚本完成数据插入。
因系统注册用户和用户收货地址仅涉及ecs_users和ecs_user_address两张数据库表,数据关系相对简单,推荐采用第一种方式批量添加数据,SQL语句执行顺序如下所示,相关SQL命令可在http://www.51testing.com/html/92/n-3719892.html处下载(ECSHOP批量插入测试 数据):
01.f_randnum.sql //随机生成指定范围的整数 02.f_randstr.sql //生成指定长度的随机字符串(只包含小写字母) 03.f_randomSelectRegion.sql //从ECShop的地区表中随机选择指定ParentID下的省市县或地区 04.p_generateUserAddress.sql //自动生成指定User的默认地址信息,并返回AddressID 05.p_generateTestUsers.sql //自动生成指定数量的User数据 00.Initialize_100w_userdata.sql //初始化1000000个用户,密码是123456(如果想要修改密码可利用LR ?????????????????????????????????????//重新生成注册脚本,获取数据库中加密存储的密码) |
如果想采用第二种办法,需要先录制注册和添加地址脚本,在注册脚本中找到username,将参数设置为Date/time类型,参数取值设置为“testuser_%Y%m%d%H%M%S.000”,如图9-6所示。
图9-6 username参数取值
此方法将以精确到毫秒的时间参数作为username的实际取值,避免了参数的重复性。在此基础上将注册脚本放入Controller场景中持续执行,直到产生足够多的注册用户数,再从数据库中取出这些用户名作为登录的参数即可。
【特别说明】:用户注册未纳入到业务模型的原因在于60万业务访问量下,并发用户注册是小概率事件,在业务规则相对简单的操作中,小于5%的业务量并不会对系统性能产生较大影响,所以本次五大场景中并未考虑用户注册场景。
2.商品数据准备过程
以下是商品数据准备过程。
添加新商品涉及多张数据库表和相关属性,且商品货号为系统自动生成,商品图片需提前准备,这些都加大了构造批量数据的难度。为方便读者操作,本次将利用ECShop后台管理系统商品复制功能,准备100条可下单商品数据,操作步骤如下所示。
(1)进入ECShop后台管理系统http://192.168.1.124/admin/index.php。
(2)菜单栏选择“商品管理”->“商品列表”,选择任意商品复制。例如,联想P806,单击“复制”按钮,如图9-7所示。
图9-7 复制当前商品
(3)为复制商品添加缺失信息,包括在通用信息Tab页添加商品名称,上传商品图片,去掉促销价复选框,如图9-8所示;在其他信息Tab页修改商品库存数据量(修改商品库存数量为最大值65535),如图9-9所示;最后单击“确定”按钮。
图9-8 修改复制商品的通用信息
图9-9 修改复制商品的其他信息
3.其他准备过程
以下是其他准备过程。
为了让用户能够在指定地址收到货物,除了提前设置收货地址外,还需要在ECShop后台管理系统中选择“系统设置”->“配送方式”,安装“上门取货”组件,如图9-10所示。
图9-10 已安装“上门取货”组件
安装“上门取货”组件后需要设置配送区域,单击图9-10中的“设置区域”选项,单击“新建配送区域”按钮,如图9-11所示。
图9-11 新建配送区域
进入配送区域设置页面,添加配送区域为中国,单击+号按钮提示中国已全部勾选,单击“确定”按钮,如图9-12所示。
图9-12 设置配送区域为中国
设置好配送区域后还需要安装付款方式才能成功下单,请在ECShop后台管理系统中选择“系统设置”->“支付方式”,安装“货到付款”组件,如图9-13所示。
图9-13 已安装“货到付款”组件
学习笔记
性能测试数据准备往往需要花费大量的时间和精力,需要测试人员熟悉系统业务,并了解数据库表结构间的关系,插入数据缺失或顺序不对都可能导致系统无法正常运行。所以性能测试团队成员最好能在项目初期介入,共同参与项目需求分析和设计。
9.3.3 测试脚本创建
准备好数据后,Lucy和Peter一起手动操作了五个业务场景,确定功能无误后开始了性能测试脚本的录制,相关脚本请在http://www.51testing.com/html/92/n-3719892.html处下载(ECSHOP脚本)。
本书读者交流QQ群:425860640,欢迎加入~~
本文选自《性能测试学习笔记之 LoadRunner实战》第五章,本站经人民邮电出版社和作者的授权。
版权声明:51Testing软件测试网获人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。