软件性能测试在账单查询系统中的应用

摘要账单系统是行业的一个重要的商家服务系统为后期商家查询、下载账单提供支持。为了保证商家服务质量从账单系统的架构以及特点出发文章对其性能测试的要求、场景、指标、流程、策略以及用例设计进行分析并研究测试方法采用阿里体系内的服务压测平台进行后端服务的性能测试。结果表明性能测试有助于发现系统中存在的问题为系统进一步优化提供依据。

关键词性能测试;账单系统;系统;性能调优

中图法分类号：TP311文献标识码：A

Application of software performance test in bill query system

Ll Jiang

（ Alipay（China）Network Technology Co.，Ltd.，Shanghai 200135，China）

Abstract; Billing system is an important business service system in 020 industry，which providessupport for later businesses to query and download bills. In order to ensure the service quality ofmerchants，starting from the architecture and characteristics of the billing system，this paperanalyzes the requirements，scenarios，indicators，processes，strategies and use case design of itsperformance test，studies the test methods，and uses the service pressure test platform in Alibabasystem to test the performance of back-end services. The results show that the performance test ishelpful to find the problems existing in the system and provide a basis for further optimization of thesystem.

Key words： performance test，billing system，Web system，performance tuning

1  引言

隨着“互联网+”的飞速发展，O2O 行业用户日益增多，用户与系统之间产生的交互、沉淀的数据量也猛增。因此，作为服务端，不仅仅要满足用户功能上的需求，同时要考虑大量用户、海量数据的背景下，系统的表现能力。为了在发布之前有效保障用户体验，账单系统除了要完成功能测试，还要验证后端服务的各项性能指标，发现系统存在的瓶颈，并针对这些瓶颈进行优化、改善，最终满足发布要求，以保障用户体验[1 ]。

2  性能测试概述

性能测试是指在一定的软件、硬件、网络环境下，通过模拟用户请求，针对系统进行测试，考察监控服务的响应能力。在一定的压力负载下，测试系统的响应时间、空间资源是否达到预期。如果没有达到预期，对结果指标进行分析，为软件调优提供解决方案[2]。

在互联网行业，如果将性能测试按照被测对象进行划分，可以分为客户端性能测试（ APP 或者 Web）、服务端性能测试、全链路性能测试。按不同的测试目的，又可分为压力测试、负载测试、疲劳度测试、稳定性测试[3]。

经过性能测试后，会出现一些常用的监控指标，如服务器（CPU 使用率、内存使用率、处理器队列、磁盘状态等）、数据库（连接数、数据库读写响应时间长度、数据库读写吞吐量等）、服务（吞吐量、响应时间）、缓存（缓存容量、连接数、吞吐量）。

在业界，常用的性能测试工具较多，包括开源工具和公司内部工具。开源工具有LoadRunner，Jemter，WebLoad，QALoad[4]等;在蚂蚁体系（阿里体系）内，出于数据安全考虑，采用自己的压测平台。蚂蚁压测全链路压测方案如图1 所示。

完整的性能测试流程一般分为以下几个过程：测试需求分析、性能指标的划定、执行、数据统计、结果分析、优化、测试报告声称。

3  账单查询系统性能测试需求分析及方案设计

3.1  需求分析

图2 所示是账单系统功能图。

测试目标：账单系统作为订单系统的下游，需要支持日均1000万的订单数据同步;支持商户按周、月查询账单，方便对账。从功能上看，账单系统分为两大块：订单状态变更时，通过同步调用同步数据;商户会通过 Web 页面查询一段时间内的汇总和明细数据。

写数据的量：取决于上游订单并发量。日均1000万订单创建量对应的就是峰值100万tps的订单创建量。也就是说，高峰时间，同时会有100万人下单。因此，账单同步数据接口也需要满足100万tps的请求量。

读数据的量：商户在后台查询并发量并不大，10tps 即可。但是，对于头部商户而言，一个月交易量达上千万条时，查询接口需要针对海量数据进行测试。

3.2  方案设计

（1）账单系统性能测试目的

数据同步能支持100万tps压力订单创建的压力值。数据读取能支持千万级别数据量汇总以及明细下载。

（2）工具

蚂蚁压测中心，对接口进行压测。

（3）环境

线上环境，直接在线上进行压测，更加真实。时间点选择在真实用户较少的晚上，对实际客户影响较小。

服务器：64位，8核 CPU，16GB 内存，150GB 硬盘，千兆以太网网络，Linux 操作系统，线上服务器总量为200台。

数据库：MySQL l6。

（4）监控

服务端：监控 CPU 利用率、内存占用率、磁盘 IO 。

客户端：压测期间体验良好，不卡顿。

3.3  场景设计

场景设计如表1 所列。

4  账单查询系统性能测试实施及结果分析

4.1  性能测试实施

（1）性能测试脚本开发

创建订单代码：createOrderAction

（2）场景的执行

每个读写 case 关联 Action ，通过压测平台配置并发数量及持续时间，配置参考图3 。

4.2  性能测试结果

第一轮测试结果（详见表2、表3）：账单同步数据接口，通过上游创建订单连动同步数据，对上游创建订单进行并行调用1000tps。

4.3  性能結论

从第一轮压测结果看，数据同步和查询均未达到产品需求标准，问题包括：写高峰时，DB 负载过大，导致查询无法正常进行;商家的数据量大时，查 DB 的时间过长导致接口响应超时，商家通过页面无法看到结果。

4.4  性能初步调优

（1）性能瓶颈判断

经过开发、运维的协商判定，在不增加线上服务器的前提下，针对上述两个问题，计划做以下优化改造：当写出现“洪峰”时，采用“蓄洪、泄洪”，即当前单机请求量超过2000tps 时，同步请求到账单系统，账单不做存 DB 处理，而是将请求缓存到本地临时文件中（蓄洪）;系统另外起线程，匀速读取临时文件，异步处理，不做实时返回，单次处理1000条（泄洪）。针对热点商户，采用“预缓存”数据，即每日 0点，以周/月为单位，后台事先将头部商户的数据进行汇总计算、明细下载到文件中，商户请求时，头部商户直接从文件中拉取，普通商户走 DB 实时拉取。

（2）性能调优效果

经过上述改造，重新部署，进行第二轮压测，结果见表6 。当负载为5000tps 时，超过2000tps ，自动切换到“蓄洪”模式，接口只对请求进行文件转存，并不做实质性逻辑处理，因此处理速度很快。“泄洪”线程控制单次处理1000条请求，处理也正常。

5  结论

本文通过完整的性能测试思考、执行流程，描述了其在账单系统中的有效应用。性能测试在当下互联网测试中必不可少，在海量数据、大量用户的背景下，是对功能测试的一种补充，能发现功能测试发现不了的问题，帮助开发、运维人员发现问题，完善架构设计，给用户带来更加平滑的体验。

参考文献：

[1] 刘一蒙.基于 web 下网络安全工具的测试与分析[ D].西安：西安电子科技大学，2012.

[2] 丁秀兰.Web 测试中性能测试工具的研究与应用[ D].太原：太原理工大学，2006.

[3] 刘蒙华.基于 OA 系统性能测试的研究与应用[ D].西安：西安科技大学，2017.

[4]郑润萍.基于 LoadRunner 的 Web 软件性能瓶颈分析调优研究与实践[D].广州：华南农业大学，2016.

作者简介：

李江（1986—），工程师，研究方向：软件测试。