马敏,王敏,肖凌瑶
(湖北广播电视大学,武汉430000)
随着近年来移动终端的迅速普及,高速网络的快速发展,越来越多的用户通过网络学习、办公、娱乐、购物。然而用户访问的高并发、高集中也给系统服务器带来极大的负荷。最新的例子是今年二月中旬开始的“停课不停学”,由于大量学生在上课时段集中访问,网络教学平台“雨课堂”、“职教云”、“蓝墨云班课”等集体“瘫痪”。系统性能的好坏直接影响用户的体验、产品的市场占用率、公司的盈利,因此系统的性能测试也越来越受到各大公司的重视。顺应行业需求,越来越多的高校软件工程专业或其它计算机应用相关专业开设了《性能测试》课程。
作为一门理论知识广泛,实践性也很强的专业课程,《性能测试》总学时是36 个课时,2 个学分。该课程主要内容包括性能测试的基本概念、常见性能指标、性能测试执行及结果分析等。该课程标准要求在前期软件设计及软件测试技能基础上提升高质量程序设计技能、掌握性能测试的基本技能、学会性能测试工具的使用方法。着重培养学生的熟练度、规范性、集成和项目能力[1]。如何在有限的学时内,让学生达到课程目标,满足企业测试岗位要求是一个值得研究的问题。
目前市面上关于软件测试的教材很多,但专注于性能测试的较少,并且以理论为主,配合实战案例的很少。这与高职强调实用、重视操作的培养目标不符。
性能测试概念较多,例如吞吐率、点击率、请求响应时间、事务响应时间等。以大二的学生开发水平和项目经历理解这些抽象的概念难度较大[2]。
性能测试是一门理论广度深度,实际操作要求都很高的课程,既需要学生掌握软件测试的基本理论和流程,又需要学生快速理解不同产品的业务逻辑和常见性能指标。然而由于学生缺乏实际的项目经验,加之现有的教材普遍停留与理论探讨阶段致使学生学习性能测试往往停留在表面,没有领会其中的要领。
近年来,微信小程序以其便捷出色的用户体验成为移动端主流应用。我学院受第三方公司委托,组织本学院教师,成功开发了“我的国际农场”小程序。该项目主要是为了满足日本关西地区面向中国市场推广本地的农副产品和观光旅游的需求。介绍日本茨城县地方种植户、加工厂、贩卖店及旅游公司、运动俱乐部(足球、高尔夫等)、旅馆,提供线上及线下的农场共享,旅日观光等服务。
《性能测试》课程案例选用“我的国际农场”这个实际商用作为被测系统,帮助学生体验真实的项目测试过程,避免所学与所用脱节。结合业内流行的抓包工具Fiddler 和性能测试工具LoadRunner,录制和修改脚本。通过设计测试场景,执行性能测试,分析测试结果,引导学生理解性能测试[3-5]。
《性能测试》课程知识点多而繁杂,实战性很强,但是仅有36 学时。如何保证教学的效率,让学生掌握实用的岗位技能是教学案例设计的需要考虑的重点。因此通过将教学案例选取本学院自研的商用小程序“我的国际农场”,对标业内主流的测试工具和测试方法进行设计,确保学生所学内容满足职业需求。
本课程中事务、集合点、检查点是非常重要的基本概念,但是现有教材偏重抽象理论,没有贯穿这三个基本知识点的案例,因此需要为这几个知识点设计基于LoadRunner+Fiddler 的项目教学案例。
测试手机可采用学生的个人手机,建议用版本低于Android 7.0 的设备。
PC 采用学院机房Win10 系统主机,为了不影响抓包工具正常使用,PC 需要关闭防火墙,退出杀毒软件。手机与PC 需要处于同一局域网中,PC 上安装抓包工具Fiddler 官网最新版本和LoadRunner 12.02 社区版。配置手机网络代理为PC 的IP 地址,端口号设为8888。Fiddler 设置侦听端口为8888,与手机配置的端口号一致,否则无法与手机正常连接。由于小程序发送接收HTTPS 消息,因此需要勾选“Decrypt HTTPS traffic“并安装证书。需要特别注意的是,Fiddler 配置后需要重启,否则可能无法抓包。
性能测试必须基于产品需求。小程序“我的国际农场”需求说明书中要求,50 个用户同时登录小程序并浏览商品列表,用户平均登录时间不超过2 秒,商品展示网页正常显示。因此性能测试场景应该围绕这个需求设计,生成50 个虚拟用户进行登录和浏览操作。为了确认网页的正常跳转,需要进行文本检查点设置。企业项目测试中,为了尽可能真实地模拟用户的操作,50 个虚拟用户通常使用不同的账号登录,需要用到参数化。由于本次教学内容不包括参数化的知识点,因此50 个虚拟用户均以相同的账号登录。
首先打开已经配置好的抓包工具Fiddler 开始录制,然后手机登录微信小程序“我的国际农场”,点击“我的工厂”菜单,页面跳转后浏览商品列表。将所有session 消息保存为login.saz。如图1 所示。
图1 Fiddler抓包消息
使用LoadRunner 打开脚本,删除无关内容,根据需求设置登录集合点、查询商品列表事务和检查点。案例要求对登录进行压力测试,因此需要在登录相关代码前设置集合点,并且统计登录事务的耗时。注意事务开始和结束是同一个事务名称,否则无法统计事务时间。为了验证商品列表正确地显示出来了,选择商品“日本娃娃”作为页面文字检查点,如图2。为了验证修改后的脚本的正确性,在单用户模式下运行脚本。如失败,结合运行日志进行修改,直至成功。
上面的脚本是单个用户的脚本。本次测试要求的是模拟50 个虚拟用户,因此需要打开LoadRunner 控制器,设置虚拟用户数量为50,脚本仅迭代一次。并添加服务器资源监控,关注测试执行过程中相关性能指标的变化情况。常用的资源监控有CPU 利用率、内存指标、TPS 等。设置完成后,点击运行,开始运行场景,同时观察资源监控波形图的变化。如多用户场景运行失败,需返回修改脚本或者场景设置。
图2 性能测试脚本
脚本成功执行完毕后,打开LoadRunner 分析器,通过分析图3,得出初步的测试结论:
图3 运行用户-事务平均响应时间
从图3 可看出,测试50 个人同时登录平均时间小于1 秒。“登录事务”平均响应时间与虚拟用户数量成正比关系。当并发虚拟用户数量达到最大值50,“登录事务”平均响应时间也随之达到最大值0.055 秒.根据小程序“我的国际农场”的产品需求,50 人登录时间小于2 秒即可。从测试日志也可看到返回页面包含“日本娃娃”关键字,检查点测试通过。综上所述,该小程序对于50 人以内的并发“登录事务”具有较好的处理能力,不存在明显的性能瓶颈。需要注意的是,在企业实际性能测试项目中,需要结合多个图表,针对当前测试环境进行瓶颈分析,并与开发人员沟通确认。教学中可简化为分析典型图表,得出初步结论即可。
实施本教学案例的过程中,学生使用测试工具遇到的问题颇多。例如,Fiddler 无法抓到有效数据包,HTTPS 协议解析不成功,LoadRunner 系统资源监控的设置方法等。脚本的编写方面,设置集合点和检查点的位置是一个难点,同学出错几率高,设置位置错误造成测试结果不准确。测试结果图表分析对于大多数同学是一个门槛,需要至少两节课进行理论到实例的讲解铺垫,可重点突出“拐点法”。
由于学生在实际操作过程中遇到的问题很多,因此在课堂上建议划分多个学习组进行团队互助学习交流。每个学习组由4-5 个同学组成,每个组指定一位专业成绩优异的同学担任组长,负责组织和协调工作,并代表本小组做测试汇报。
通过在《性能测试》课程中引入基于业内主流测试工具LoadRunner+Fiddler 的小程序测试案例,帮助学生在实际项目实践中融会贯通抽象的理论知识。学生在团队学习中主动投入,积极讨论,共同解决疑难问题,提高了学习的兴趣和信心,达到了较好的学习效果。
我学院目前已经在《功能测试》、《性能测试》课程中采用这种案例设计模式。接下来,我学院将在其他编程类课程中融入此类型案例。实践证明这种跟随业内主流技术,基于真实商业项目的教学案例更符合对理论广度和实践能力有较高要求的专业课程,更贴合企业的岗位需求,有利于增强学生的就业竞争力。