基于移动终端的应用软件性能测试

杜春业++吴建华++宋巍

摘 要随着移动终端的迅速发展，移动应用正逐渐渗透到人们生活和工作的各个方面。手机游戏、移动流媒体、位置服务、新闻资讯、即时通讯、移动音乐等丰富多彩的移动互联网应用正在改变着信息时代的社会生活。针对这种情况，提出基于移动终端的应用软件性能测试，分析移动应用软件性能测试技术和测试方法。实验结果表明，性能测试可以预测真实环境中对应用系统的压力，将应用系统中存在的问题暴露出来，通过对测试获得的各项数据进行分析，对优化应用系统的性能提供帮助。

【关键词】性能测试 移动终端 移动应用 测试技术 测试方法LoadRunner

目前，互联网技术正在膨胀的发展，互联网产品正在影响人们生活和工作的各个方面，以往的生活方式和习惯已经彻底发生了改变。作为当今社会互联网中最重要的移动终端，其移动应用已经得到了广泛的普及。

随着应用程序的功能大量增多，逻辑越来越复杂，用户对应用的要求不再仅仅是实现功能，而更多关注的是处理业务时的性能指标，例如并发量、响应时间、吞吐率等是否满足需求。如何最大限度地利用资源、有效地整合资源、降低运行成本、节省运行移动终端所需要的能源，从而提高移动应用软件的整體性能，则变得更为重要。

1 移动应用系统架构介绍

目前，移动应用大多数是部署在iOS、Android、WinCE/Windows Mobile等移动终端的操作系统上。通过建立统一的UI，功能和API接口来满足业务应用的跨平台特性；并通过建立移动应用支撑平台服务端和客户端之间的通信数据通道，来达到构建移动应用服务端逻辑和客户端逻辑的无缝结合的目的。同时，基于高效可靠的移动终端，采用移动通讯、3G/4G网络、Wi-Fi等网络，建立一个安全可靠、稳定高效、智能便捷的移动平台，实现智能化移动应用运转的持续性与完整性、信息处理的实时性与精准性。

2 性能测试实践

2.1 测试内容

本次被测的移动应用软件是一款电子商务软件，为消费者提供网上交易服务，例如：网上订购、网上支付、电子账户、订单查询、统计分析等功能。被测移动应用软件部署在Android操作系统的移动终端上，用户可通过互联网访问此移动应用软件。具体的网络拓扑结构如图1所示。

2.2 测试工具

本次测试采用的是商业测试工具Loadrunner。Loadrunner是一种预测系统行为和性能的负载测试工具，通过模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，预测系统行为并评估系统性能。Loadrunner脚本采用测试描述语言-C语言，支持多种协议和技术，可组织多台机器执行测试。

2.3 手机协议脚本录制原理

移动应用的录制方式是虚拟脚本生成器通过Proxy实现的。通过一个Proxy，该Proxy作为客户端和服务器之间的中间人，接受从客户端发送的数据包，记录并转发服务端；接收从服务端返回的数据流，记录并返回给客户端。这样，无论是客户端还是服务端都认为自己在一个真实的运行环境中，而虚拟脚本生成器通过这种方式截获客户端和服务器之间的数据流。截获数据流之后，虚拟脚本生成器进一步根据录制时选择的协议类型，对数据流进行分析，然后用脚本函数将客户端和服务器之间的数据流交互过程体现为脚本语句。

2.4 测试目的与需求

本次测试目的主要是通过不同的并发用户数，对该移动应用软件进行性能测试，考察系统的响应情况及各服务器的资源使用情况。同时，验证系统的实际性能和稳定性是否能达到系统设计指标的要求。

本次测试需求则是目前性能测试领域中默认的常规需求。在测试期间，考察是否满足以下几点需求：

2.4.1 事务失败率

信息系统事务失败率不得超过0.1%。

失败率=失败次数÷（成功次数+失败次数）。

2.4.2 响应时间

响应时间即对发出的请求做出响应所需要的时间。响应时间包括网络传输时间、应用服务器处理时间和数据库服务器处理时间。

响应时间=网络传输时间+应用服务器处理时间+数据库服务器处理时间。

（1）登录、注销响应时间不得超过5秒，普通界面打开不得超过5秒。

（2）简单查询、添加和删除业务的响应时间不得超过5秒，执行复杂的综合业务（同时包括查询、添加、删除等操作请求）的响应时间不得超过8秒。

（3）表格式报表处理、图片报表处理等统计类型的业务响应时间不应超过20秒。

2.4.3 系统资源性能

（1）CPU利用率：当系统并发用户数在设计要求范围内时，应用服务器和数据库服务器的CPU平均利用率不得超过80%，且CPU利用率不得连续30秒超过95%。

（2）内存使用率：当系统并发用户数在设计要求范围内时，应用服务器的内存平均使用率不得超过80%，且内存使用率不得连续60秒超过85%。

2.4.4 可靠性

在承受最大并发用户数持续运行4小时的情况下，系统运行平稳，业务失败率不超过0.1%，CPU 平均占用率低于80%，内存占用率没有明显增长且1小时后内存恢复初始值。

2.5 性能测试点的选择

可通过以下几种方法选择性能测试点：

（1）关键业务：关键业务是用户最为关注的那些业务，需要保证其性能和质量。

（2）使用频度高：使用频度高的业务用户数量较多，如果发生失效影响面相应较广。

（3）资源占用大：某些业务流程可能不是关键业务，但有很高的吞吐量，导致用户响应较慢，例如网站首页。

（4）大数据量：某些业务操作需要访问的数据量较大，当用户较多时，可能会造成系统不稳定。

（5）数据接口：与不同子系统间的数据交互。

基于以上原则，本次测试选取三个性能测试点：网上订购、订单查询、统计分析。

2.6 脚本录制

使用LoadRunner工具对移动终端的应用软件进行性能测试，测试前需要在已安装LoadRunner的电脑上共享网络，并且手机可以连接上共享出的Wi-Fi网络。同时，配置手机Wi-Fi连接的HTTP代理地址和端口，代理地址配置为电脑的IP地址，端口可以写1-65535，而此次使用端口为8080。随后，便可使用LoadRunner脚本编辑器，录制协议选择为Mobile Application-HTTP/HTML协议，并且录制模式选择为Proxy Recording，端口就填写手机上设置的8080端口。点击开始录制按钮，随后在手机上打开需要录制的移动应用程序，一步步操作需要录制的性能业务点，业务点操作完毕后，点击结束录制按钮。此时，通过LoadRunner代理方式将手机上的移动应用程序脚本录制下来了。录制后的部分脚本如下：

Action（）

{ lr_start_transaction（"搜索商品"）；

web_submit_data（"getBrandSortList"，

"Action=http：//vgoapi.xjh.com/xjh_app-openapi/appapi/getBrandSortList"，

"Method=POST"，

"RecContentType=application/json"，

"Referer="，

"Snapshot=t9.inf"，

"Mode=HTML"，

ITEMDATA，

"Name=body"， "Value={＼"params＼"：{＼"terminalCode＼"：＼"＼"，＼"version＼"：＼"＼"}}"， ENDITEM，

LAST）；

lr_end_transaction（"搜索商品"， LR_AUTO）；

lr_start_transaction（"加入购物车"）；

web_submit_data（"operateMemberCart"，

"Action=http：//vgoapi.xjh.com/xjh_app-openapi/appapi/operateMemberCart"，

"Method=POST"，

"RecContentType=application/json"，

"Referer="，

"Snapshot=t20.inf"，

"Mode=HTML"，

ITEMDATA，

"Name=body"， "Value={＼"params＼"：{＼"cartId＼"：[]，＼"flag＼"：＼"1＼"，＼"merchantId＼"：＼"＼"，＼"shopCartList＼"：[{＼"merchantId＼"：＼"＼"，＼"packageId＼"：＼"＼"，＼"productId＼"：＼"2041008000000004778＼"，＼"quantity＼"：＼"1＼"}]，＼"terminalCode＼"：＼"＼"，＼"token＼"：＼"1462332974967＼"，＼"userId＼"：＼"0114001000000000277＼"，＼"userName＼"：＼"byl＼"，＼"version＼"：＼"＼"}}"， ENDITEM，

LAST）；

lr_end_transaction（"加入購物车"， LR_AUTO）；

return 0；

}

2.7 测试场景

对测试业务功能点，使用LoadRunner性能测试工具模拟多用户并发测试，考察各个业务点的响应时间，并同步监控服务器的资源利用情况。测试期间，并发用户运行设置采用如下方式进行：

（1）单点操作负载测试场景设计为分别模拟1、50、100个用户并发，采用静态或动态加压方式（1个用户采用静态加压方式；50、100个用户采用动态加压方式），测试时不设置脚本的思考时间Think Time（或根据不同业务需求调整），测试持续10分钟，同时监控服务器的资源利用情况。

（2）混合业务负载测试场景设计为模拟100个用户并发，对被测业务点进行混合压力测试，采用动态加压方式，平均分配用户比例，测试时不设置脚本的思考时间Think Time（或根据不同业务需求调整），测试持续时间为10分钟，同时监控服务器的资源利用情况。

（3）稳定性测试场景设计为100个用户并发，对被测业务点进行稳定性测试，采用动态加压方式，平均分配用户比例，测试时不设置脚本的思考时间Think Time（或根据不同业务需求调整），测试持续时间为4小时，同时监控服务器的资源利用情况。

2.8 分析测试结果

网上订购、订单查询、统计分析在1、50个用户并发时平均响应时间均小于3秒，但在100个用户并发时，移动应用开始报错，报错信息为Java.sql.SQLException错误和WebLogic 连接池泄露问题。在与开发方进行沟通后，排除服务器端网络性能问题和应用软件设计问题，将问题定位为数据库配置问题和应用软件参数设置问题。因此，配合开发方对数据库进行了调优，并对WebLogic连接池参数进行了配置。对调优后的移动应用软件执行第二轮回归测试，三个性能点的100个用户并发平均响应时间均小于5秒，混合业务和稳定性测试也均达到了本次测试目的与需求。同时，服务器CPU利用率、可用内存和磁盘I/O也未见异常波动。如图2，图3，图4，图5，表1，表2，表3，表4所示。

3 结束语

随着移动终端的快速普及和发展，移动应用软件的性能至关重要。在移动应用系统上线发布之前，对其开展性能测试，及时发现不足，为系统正式运行后提供了有效的质量保障。本文通过一个测试实践介绍了性能测试的手机协议脚本录制原理、测试目的与需求、性能测试点的选择、脚本录制、测试场景及分析测试结果等。实验结果表明，性能测试可以模拟和预测真实环境中对应用系统的压力，将应用系统中存在的问题暴露出来，并通过对测试获得的各项数据进行分析，对优化应用系统的性能，选择合适的软硬件环境，提供帮助。当然，移动应用软件除了好的性能，安全测试也是很重要的一方面，希望在以后的研究过程中，把性能和安全有机结合，提供更多的解决方案。

参考文献

[1]靳鸿著.测试系统设计原理及应用[M]. 北京：电子工业出版社，2013.

[2]宋巍，张春柳，邬斌亮.Web系统性能测试研究与实践[J].计算机应用与软件，2015，32（03）：4-6.

[3]简玲.B/S系统性能测试的设计与实现[J].计算机工程，2009，35（10）：51-53.

[4]杨怡君，黄大庆.Android手机自动化性能测试工具的研究与开发[J].计算机应用，2012，32（02）：554-556.

[5]陈绍英，刘建华，金成姬.LoadRunner性能测试实例[M].北京：电子工业出版社，2007.

[6]王立群，杨静.移动应用软件性能测试研究[J].科技风，2015，21（21）：115-115.

[7]張靖，彭新光.Android智能手机渗透测试研究[J].计算机应用与软件，2014，31（12）：29-32.

[8]邓璐娟，范乃梅，孙义坤等.基于Web应用的性能测试模型研究[J].计算机工程与应用，2013，49（01）：75-77.

[9]李少杰.面向移动智能终端应用性能测试平台的研究[D].广州：华南理工大学，2014.

[10]陈鹏.基于Android应用的性能监控系统的研究与实现[D].广州：华南理工大学，2015.

[11]孟跃伟，胡爱群，宋宇波等.无线局域网安全性能测试系统的设计与实现[J].计算机工程，2013，39（07）：193-199.

[12]刘 严，胡 敏.性能测试中脚本捕获的方法研究与应用[J].计算机工程，2006，32（22）：94-95.

作者简介

杜春业（1987-），女，上海人。大学本科学历。现为中级工程师。主要研究方向为软件测试。

作者单位

上海市计算机软件评测重点实验室 上海市 200112