Performance Test and Result Analysis of College
Comprehensive Service Platform App Based on
Loadrunner and CCProxy
Liu Guangyong
School of Information Technology and Engineering
Tianjin University of Technology and Education
Tianjin, China
82972130@qq.com
Abstract²With the development of big data and mobile
intelligent terminal technology, campus App has become the best
medium for integrating and sharing school resources and
connecting teachers and students. The multi-user concurrency
performance of the campus App directly determines experience
effect of the users. The article proposes a solution to test campus
App performance based on Loadrunner and CCProxy. The
solution records the App script through CCProxy proxy mode,
uses Loadrunner 11 to simulate the number of virtual users,
continuously pressurizes the server, sets the rendezvous point for
common transactions, and finally evaluates the performance
status of the system.
Keywords—college comprehensive service platform;
performance test; App; Loadrunner; CCProxy
I. INTRODUCTION
In recent years, big data technology has become the
mainstream technology of Internet development, and resource
sharing has become the main way of information exchange in
today's society [1]. With the development of big data and
mobile intelligent terminal technology, campus App has
II. TEST ENVIRONMENT CONFIGURATION
Equipment and software required for this test: 1 laptop
(Loadrunner 11 and CCProxy 8.0 installed), 1 smartphone
(Huawei, Android 8.2).
A. Proxy Settings[2]
,QRUGHUWRFRUUHFWO\FDSWXUHWKHVFULSWWKDWWKH$SSUXQVLW¶V
necessary to make sure that the mobile phone and the laptop
belong to the same local area network, and Internet access
mode of mobile phone must be set to access the Internet
through the laptop agent. To do this, you need to install and
enable the CCProxy 8.0 proxy server software on your laptop.
The HTTP proxy mode of the mobile wireless LAN is set to
the manual mode; IP address and port are set by referring
CCProxy settings.
B. Record and Edit the App script[2]
Before the scripts are recorded, the following steps must be
operated. They are Starting HP Virtual User Generator,
creating a new VuGen script file with Mobile App
become the best medium for integrating and sharing school
resources and connecting teachers and students. The emergence
of the campus App has greatly enhanced the campus
information management and service concept, reduced the
management cost, and improved the management efficiency of
student information and educational information.
However, there are many types of campus Apps with
different functions, and uneven performance, which leads to
both good and bad comments of users. According to survey
among users, App performance plays a crucial role in the user
experience. The article takes the App of a university
comprehensive service platform in Tianjin as an example.
Combining Loadrunner11 and CCProxy tools, two methods of
stress test and concurrent test are used to test its performance,
including transaction response time, server resource occupancy,
etc., and analyze the test results.
978-1-7281-3584-7/19/$31.00 ©2019 IEEE
1495
Authorized licensed use limited to: Auckland University of Technology. Downloaded on July 26,2020 at 18:34:36 UTC from IEEE Xplore. Restrictions apply.
+773+70/ SURWRFRO VHOHFWLQJ ³5HFRUG DQG $QDO\]H
7UDIILF´ LQ WKH UHFRUGLQJ PRGH GHIDXOWLQJ WKH 85/ DGGUHVV
filling in the corresponding port number, selecting the correct
proxy network card.
Then, here comes the step of recording script. When you
click the "Start Recording" button, you can operate the App on
your phone. At this time, Loadrunner 11 will record all online
behaviors of the phone in the background. When the operation
is completed, click "Stop Recording" to generate a script
package file. Finally, the captured packets are parsed into a
VuGen script and the content unrelated to this test is deleted [3].
C. Test Scenario Configuration
This test uses Loadrunner 11. Though simulating the
number of virtual users, it constantly pressurizes the server,
tests the rendezvous points of common transaction settings,
records the test data, comprehensively analyzes, and finally
evaluates the performance of the App [4].
Before performing performance testing, you need to design
test cases, record VuGen scripts according to the description of
the use cases, and design test scenarios, including 1.614 seconds, but the CPU usage increased, reaching 55%.
pressurization and rendezvous policies, to simulate the user's The test passed.
operations. ^ĐĞŶĂƌŝŽEŽ͘ 'ƌĂƉŚ DĞĂƐƵƌĞŵĞŶƚ DŝŶŝŵƵŵ ǀĞƌĂŐĞ DĂdžŝŵƵŵ
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ Ϭ ϮϮ͘ϳϮϱ ϵϴ͘ϲϵϴ
III. PERFORMANCE TEST AND RESULTS ANALYSIS ^ϬϬϭ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƵƐĞƌůŽŐŝŶ Ϭ͘ϭϴϵ ϯ͘ϯϳϭ ϭϰ͘ϯϰϵ
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƉĂŐĞďƌŽǁƐŝŶŐ Ϭ͘ϬϬϯ Ϭ͘ϮϮϵ ϰ͘ϯϭϯ
This test is performed to simulate PXOWLSOH XVHUV¶ tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ Ϭ Ϯϵ͘ϰϮϴ ϵϴ͘ϴϯϰ
concurrent operations, and observe various common indicators ^ϬϬϮ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƵƐĞƌůŽŐŝŶ Ϭ͘ϭϴϳ ϱ͘ϴϰϱ Ϯϭ͘ϰϱϭ
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƉĂŐĞďƌŽǁƐŝŶŐ Ϭ͘Ϭϯϰ Ϯ͘ϰϮϲ ϴ͘ϯϰϯ
of the server from the perspectives of login, information query, tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ ϯ͘ϳϱϲ ϱϱ͘ϰϯϭ ϴϬ͘ϯϭϭ
data writing, etc. Among them, the number of concurrent users ^ϬϬϯ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƵƐĞƌůŽŐŝŶ Ϭ͘Ϭϳϱ Ϭ͘ϯϮ ϭ͘ϲϭϰ
is mainly estimated based on the number of teachers and ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƉĂŐĞďƌŽǁƐŝŶŐ Ϭ͘ϬϬϯ Ϭ͘ϭϮϮ ϭ͘ϭϭϲ
students in the school. It is assumed that the maximum number Figure 1 The test results of LRTCase01 case
of online users is 15% of the total number of teachers and
students in the school, about 2,000, and the number of B. Curriculum Query Test Case
concurrent users is 1/10 of the maximum number of online Table 2 shows the test case for the curriculum query. This
users, that is, 200. test case tests the performance of the system when multiple
users concurrently query the specified information from the
A. User Login Test Case perspective of information query.
Table 1 shows the user login test case. This use case is
designed to test the performance of the system when 100 users TABLE 2 CURRICULUM QUERY TEST CASE
and 200 users concurrently login while browsing the specified
Use Case
page. Name
curriculum query Use Case No. LRTCase02
300 users login to the comprehensive service platform
TABLE 1 USER LOGIN TEST CASE[5] App (teacher side), query the classrooms of the 3 and
Use Case
4th class at the 10th week and "Li Ruolan" teacher's
Description
Use Case schedule details. This use case contains 2 transactions:
user login Use Case No. LRTCase01
Name no-class classroom, curriculum query
300 users login to the comprehensive service platform 1. In the case of 100 user concurrent queries, the page
Expected
App (teacher side), and browse the school response time meets the 2/5/8 principle
Use Case Target
DQQRXQFHPHQW³'HVFULSWLRQRIWhe classification of the 2. Server resource usage is normal
Description
JUDGXDWLRQGHVLJQWKHVLVVXEMHFWW\SH´7KLVXVHFDVH Test Scenario
contains 2 transactions: user login, page browsing Pressure Rendezvous ThinkTime
Scenario No. Vusers
1. in the case of 200 users concurrent login, login and policy policy /RunTime
Expected
page response time meet the 2/5/8 principle[6] no-class
Target
2. Server resource usage is normal classroom ignore /5
Test Scenario SC004 200 10user/3s /curriculum minutes after
Pressure Rendezvous ThinkTime query: full 50 pressurization
Scenario No. Vusers
policy policy /RunTime releases
ignore /5 curriculum ignore /5
user login: full
SC001 200 10user/3s minutes after SC005 300 10user/3s query: full 100 minutes after
100 releases
pressurization releases pressurization
ignore /5 ignore /5
user login: full
SC002 300 10user/3s minutes after SC006 400 10user/3s disabled minutes after
200 releases
pressurization pressurization
ignore /5
SC003 300 10user/3s disabled minutes after The test results are shown in Figure 2. It can be seen from
pressurization
the figure that when 200 users login and 50 of them
concurrently search for the no-class classrooms and the teacher
The test results are shown in Figure 1. As can be seen from /L 5XRODQ¶V FODVVHV WKH DYHUDJH UHVSRQVH WLPH RI WKH
the figure, when the number of virtual users is 200 and the transaction is 0.982 seconds, 1.504 seconds. The occupancy
number of concurrent login users is 100, the response time (that rate of CPU is less than 50% and the performance is excellent.
is, the average transaction response time, the same below) is When the number of users increases to 300, the "no-class
3.371 seconds. The response time of the page is 0.229 seconds, classroom" rendezvous policy is disabled, while the number of
while the CPU usage is only 22.725%. The result fully meets concurrent enquiries to the curriculum reaches 100, the query
the international general guidelines - 2/5/8 principle. When the time of the "no-class classroom" drops to 0.614 seconds, and
number of virtual players increases to 300 and the number of the query time of the "Li Ruolan" teacher's curriculum rises to
concurrent logins increases to 200, the response time for user 2.565 seconds. It is logical to further illustrate the use of a
login is 5.845 seconds, and time for the maximum response is rendezvous policy to simulate concurrent query operations for
21.451 seconds. The waiting time is slightly longer. However, real users.
in actual use, this kind of concurrent login is rare, and the
system performance is basically satisfactory. After the When the rendezvous is disabled, since the number of
rendezvous policy was disabled, the system response time was operators becomes 400, the response time of the above two
significantly shortened. The maximum response time was only transactions is 1.509 and 1.8 seconds respectively, which is still

1496

Authorized licensed use limited to: Auckland University of Technology. Downloaded on July 26,2020 at 18:34:36 UTC from IEEE Xplore. Restrictions apply.
very fast. However, at this time, the CPU usage rate is high, D. Test Case of School Rules Exam
rising to 85.477%, and the server pressure is gradually Table 4 shows the test cases for the exams. Not only do you
increasing. Considering that LoadRunner iteratively have to read a lot of information concurrently, but you also
implements the operations of the user login script, queries of need to write tens of thousands of data records concurrently.
"no-class classroom" and "curriculum query" for 6-7 times This use case is designed to test the performance of the system
during the test, which results in an increase in server resource when users read large amounts of data.
occupancy, the result is understandable.
^ĐĞŶĂƌŝŽEŽ͘ 'ƌĂƉŚ DĞĂƐƵƌĞŵĞŶƚ DŝŶŝŵƵŵ ǀĞƌĂŐĞ DĂdžŝŵƵŵ TABLE 4 TEST CASE OF SCHOOL RULES EXAM
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ Ϭ͘ϱϭϴ ϰϵ͘Ϯϭϴ ϵϴ͘ϵϳϰ
^ϬϬϰ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ŶŽͲĐůĂƐƐ Ϭ͘ϭϬϴ Ϭ͘ϵϴϮ ϯ͘ϳϯϴ Use Case
school rules exam Use Case No. LRTCase04
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ĐƵƌƌŝĐƵůƵŵ Ϭ͘ϭϮ ϭ͘ϱϬϰ ϯ͘ϵϱϳ Name
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ Ϭ ϱϵ͘ϯϳϰ ϵϵ͘ϯϱϮ 500 users login to the comprehensive service platform
^ϬϬϱ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ŶŽͲĐůĂƐƐ Ϭ͘Ϭϯϭ Ϭ͘ϲϭϰ ϰ͘ϯϲϱ
App (student side), click and enter the exam. After the
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ĐƵƌƌŝĐƵůƵŵ Ϭ͘ϭϮϯ Ϯ͘ϱϲϱ ϱ͘ϯϬϳ
Use Case system randomly generates a test paper containing 50
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ ϲ͘ϯϰϳ ϴϱ͘ϰϳϳ ϵϵ͘ϲϭϵ
Description multiple choice questions, the students select the answer
^ϬϬϲ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ŶŽͲĐůĂƐƐ Ϭ͘Ϭϰϰ ϭ͘ϱϬϵ ϱ͘ϲϱϱ
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ĐƵƌƌŝĐƵůƵŵ Ϭ͘ϭϬϭ ϭ͘ϴ ϱ͘ϰϭϴ
and submit the results. This use case contains 2
Figure 2 The test results of LRTCase02 case transactions: entering test, submission answer
1. In the case of 200 users concurrently taking the test,
Expected
the page response time meets the 2/5/8 principle
C. Student Leave Test Case Target
2. Server resource usage is normal
Table 3 shows the student's leave test case. The amount of Test Scenario
Scenario Pressure Rendezvous ThinkTime
data written is general. It is designed to test the performance of Vusers
No. policy policy /RunTime
the system when multiple users write the specified information entering test/
concurrently. ignore /5
submission
SC010 300 10user/3s minutes after
answer: full
pressurization
100 releases
TABLE 3 STUDENT LEAVE TEST CASE entering test/
ignore /5
Use Case submission
student leave Use Case No. LRTCase03 SC011 500 10user/3s minutes after
Name answer: full
pressurization
300 users login to the comprehensive service platform 200 releases
Use Case App (student side), click "I want to take time off", and ignore /5
Description submit a leave request. This use case contains 1 SC012 500 10user/3s disabled minutes after
transaction: leave request pressurization
1. In the case of 100 users submitting applications
Expected concurrently, the page response time meets the 2/5/8 The test results are shown in Figure 4. It can be seen from
Target principle the figure that after 300 users login, 100 students enter the test
2. Server resource usage is normal
to generate the test paper concurrently, and submit 100 test
Test Scenario
Scenario Pressure Rendezvous ThinkTime
paper answers concurrently. The transaction response time is
No.
Vusers
policy policy /RunTime 1.444 seconds and 0.452 seconds respectively. The maximum
ignore /5 response time is no more than 9 seconds, and the CPU usage is
leave request:
SC007 200 10user/3s
full 50 releases
minutes after about 53%, which is good. When the number of users increased
pressurization to 500 and the number of concurrent users changed to 200, the
leave request: ignore /5 response time was 3.432 seconds and 1.042 seconds
SC008 300 10user/3s full 100 minutes after
releases pressurization
respectively. The resource occupancy rate did not change
ignore /5 significantly, but the maximum response time was extended to
SC009 300 10user/3s disabled minutes after 24 seconds. However, at this time, the amount of data written
pressurization concurrently is as high as 10,000 (namely, 200*50), which is
acceptable in a sense. Therefore, when the system is dealing
The test results are shown in Figure 3. It can be seen from with a large amount of data, the performance is good regardless
the figure that when 200 or 300 users login, whether it is 50 of the case where the amount of large data is concurrent.
users or 100 users concurrently writing data, the overall ^ĐĞŶĂƌŝŽEŽ͘ 'ƌĂƉŚ DĞĂƐƵƌĞŵĞŶƚ DŝŶŝŵƵŵ ǀĞƌĂŐĞ DĂdžŝŵƵŵ
performance of the server is quite excellent. This reflects from tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ ϭ͘Ϯϵϱ ϱϮ͘ϵϭϲ ϳϴ͘ϵϯϴ
the side that the background database server can easily handle ^ϬϭϬ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ĞŶƚĞƌŝŶŐƚĞƐƚ Ϭ͘ϬϲϮ ϭ͘ϰϰϰ ϵ͘ϰϱ
the writing of ordinary data, the response speed is extremely ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƐƵďŵŝƐƐŝŽŶ Ϭ͘Ϭϳϭ Ϭ͘ϰϱϮ ϵ͘ϲϭϮ
fast, and the CPU usage is extremely low. ^Ϭϭϭ
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ
йWƌŽĐĞƐƐŽƌ
ĞŶƚĞƌŝŶŐƚĞƐƚ
ϭ͘ϰϮϰ
Ϭ͘ϬϲϮ
ϱϬ͘ϳϱϭ
ϯ͘ϰϯϮ
ϴϯ͘ϵϮϭ
Ϯϰ͘ϳϲϱ
^ĐĞŶĂƌŝŽEŽ͘ 'ƌĂƉŚ DĞĂƐƵƌĞŵĞŶƚ DŝŶŝŵƵŵ ǀĞƌĂŐĞ DĂdžŝŵƵŵ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƐƵďŵŝƐƐŝŽŶ Ϭ͘Ϭϳϴ ϭ͘ϬϰϮ ϮϬ͘ϲϭ
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ Ϭ͘ϯϴϴ ϵ͘ϰϵϳ ϰϵ͘ϰϳϵ tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ ϯ͘ϴϴϲ ϳϮ͘ϲϬϭ ϴϰ͘Ϯϴϳ
^ϬϬϳ ^ϬϭϮ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ĞŶƚĞƌŝŶŐƚĞƐƚ Ϭ͘Ϭϳϴ Ϭ͘ϵϳϲ ϯ͘ϵϴϵ
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƐƚƵĚĞŶƚůĞĂǀĞ Ϭ͘ϬϭϮ Ϭ͘ϭϭ ϯ͘ϲϳ
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ Ϭ ϭϮ͘ϱϯϱ ϳϱ͘ϱϭϴ ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƐƵďŵŝƐƐŝŽŶ Ϭ͘ϬϲϮ ϭ͘ϲϱϴ ϰ͘ϵϮ
^ϬϬϴ Figure 4 The test results of LRTCase04 case
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƐƚƵĚĞŶƚůĞĂǀĞ Ϭ͘Ϭϯϭ Ϭ͘ϳϭϭ ϳ͘ϯϱϳ
tŝŶĚŽǁƐZĞƐŽƵƌƐĞƐ йWƌŽĐĞƐƐŽƌ ϭ͘ϭϲϱ ϭϳ͘ϯϭϭ ϰϰ͘Ϭϰϭ
^ϬϬϵ
ǀ͘dƌĂŶƐZĞƐƉŽŶƐĞdŝŵĞ ƐƚƵĚĞŶƚůĞĂǀĞ Ϭ͘Ϭϯϯ Ϭ͘ϭϭ Ϭ͘ϱϳϱ
Figure 3 The test results of LRTCase03 case

1497

Authorized licensed use limited to: Auckland University of Technology. Downloaded on July 26,2020 at 18:34:36 UTC from IEEE Xplore. Restrictions apply.
 IV. CONCLUSION
The BUGs found during the test must be repaired
immediately before they can be put into operation. The App
was put into trial operation at the end of 2017. It has been a
year and a half since the trial. Some errors were found during
the trial. For example, the three-level page could not be
displayed properly; the upload template format was incorrect,
and so on. But all these errors have been corrected. At present,
the system works well, the user responds faster during the login
process, and most of the functions are used normally and
promoted fully. In addition, the case of more than 600
freshmen taking the test normally at the same time proves that
the system is in good condition. In general, the performance of
the system is basically consistent with the test results, which
fully confirms the necessity of software testing.

REFERENCES
[1] Chi Ruifeng, Li Huibin, Tang Yumo. Research on the Availability of
App Interface Based on Educational Resource Sharing [J]. China High
Technology Enterprises,2016(17):6-8.
[2] App Stress Test for Mobile Phone With Loadrunner & Jemeter[EB/OL].
https://www.cnblogs.com/tester-l/p/7772391.html. 2017-11-02.
[3] Feng Xingli, Fan Zhaozhong, Luo Junfeng, Suo Zhihai. Automatic load
test for WeChat public accounts based on Fiddler and Loadrunner [J].
Journal of Computer Applications,2018,38(S2):262-264.
[4] Xiao Dong-ping, Li Ling-lin. Design and implementation of
performance testing program in the software system [J]. Technological
Development of Enterprise,2014,33(13):21-22.
[5] Han Zhao. Performance Testing of Web Application Based on
WebSocket Protocol [D].College of Engineering and Information
Technology, University of Chinese Academy of Sciences,2014.
[6] 2-5-8 Principle in Performance Testing[EB/OL].
https://www.cnblogs.com/zeroempty/p/5075742.htm. 2015-12-30.

1498

Authorized licensed use limited to: Auckland University of Technology. Downloaded on July 26,2020 at 18:34:36 UTC from IEEE Xplore. Restrictions apply.