基于移動終端的應用軟件性能測試

杜春業++吳建華++宋巍

摘 要隨著移動終端的迅速發展，移動應用正逐漸滲透到人們生活和工作的各個方面。手機游戲、移動流媒體、位置服務、新聞資訊、即時通訊、移動音樂等豐富多彩的移動互聯網應用正在改變著信息時代的社會生活。針對這種情況，提出基于移動終端的應用軟件性能測試，分析移動應用軟件性能測試技術和測試方法。實驗結果表明，性能測試可以預測真實環境中對應用系統的壓力，將應用系統中存在的問題暴露出來，通過對測試獲得的各項數據進行分析，對優化應用系統的性能提供幫助。

【關鍵詞】性能測試 移動終端 移動應用 測試技術 測試方法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-），女，上海人。大學本科學歷?，F為中級工程師。主要研究方向為軟件測試。

作者單位

上海市計算機軟件評測重點實驗室 上海市 200112