CN101576844A - 软件系统性能测试方法和系统 - Google Patents

Abstract

本发明提出了一种软件系统性能测试方法和软件系统性能测试系统。其中，软件系统性能测试方法包括以下步骤：步骤S102，建立模拟软件系统的用户特征的用户测试场景；步骤S104，获取软件系统的交易量来建立模拟软件系统的业务特征的业务测试场景；以及步骤S106，在用户测试场景和性能测试场景下测试软件系统的性能。通过本发明，可以提高软件系统的总体质量并降低运行风险。

Description

软件系统性能测试方法和系统

技术领域

本发明涉及软件系统测试领域，尤其涉及一种软件系统性能测试方法和软件系统性能测试系统。

背景技术

在性能测试工作中，测试模型建立和指标确定是两个最重要的环节和步骤，根据软件系统性能测试理论，结合对近些年来实施信息技术应用项目性能测试工作，经过总结提炼现汇总形成软件项目系统性能测试模型建立和指标确定方法。一方面这些模型和指标均是评价应用系统是否具备投产条件时的重要参考资料，同时也是利用测试工具可以进行检测度量的指标。将这些指标总结形成检测标准，以期规范和指导各应用项目在投产前进行检测，从而协助提升系统质量，降低运行风险。

发明内容

鉴于以上所述的一个或多个问题，本发明提出了一种软件系统性能测试方法和软件系统性能测试系统，旨在提高软件系统的总体质量并降低运行风险。

根据本发明一个方面的软件系统性能测试方法，包括以下步骤：步骤S102，建立模拟软件系统的用户特征的用户测试场景；步骤S104，获取软件系统的交易量来建立模拟软件系统的业务特征的业务测试场景；以及步骤S106，在用户测试场景和性能测试场景下测试软件系统的性能。

其中，步骤S102包括以下步骤：步骤S102-2，确定软件系统的多个业务中的一个或多个关键业务；步骤S102-4，确定一个或多个关键业务的并发用户数目C；以及步骤S102-6，根据一个或多个关键业务和并发用户数目C来建立模拟软件系统的用户特征的用户测试场景。

其中，在步骤S102-2中，根据软件系统的多个业务的重要性和常用性来确定一个或多个关键业务。在步骤S102-4中，并发用户数目C＝(n*L)/T，其中，n为登录会话的数目，L为登录会话的平均长度，T为第一预定时间。

其中，在步骤S106中，通过确定以下信息中的一个或多个来测试软件系统的性能：软件系统的处理能力；软件系统对交易的响应时间；在第二预定时间内登录软件系统的用户数目；在单位时间内软件系统通过其所依托的网络设备和链路传输的数据数量；与软件系统相关的硬件资源的阀值；软件系统的错误率阀值；软件系统的在正常负载下稳定运行的最短时间；同时接入软件系统的最大用户数目；以及在单位时间内软件系统处理的数据记录数量。

根据本发明另一个方面的软件系统性能测试系统包括：用户测试场景模块，用于建立模拟软件系统的用户特征的用户测试场景；业务测试场景模块，用于获取软件系统的交易量来建立模拟软件系统的业务特征的业务测试场景；以及测试模块，用于在用户测试场景和性能测试场景下测试软件系统的性能。

其中，用户测试场景模块包括：关键业务确定模块，用于确定软件系统的多个业务中的一个或多个关键业务；并发用户数目确定模块，用于确定一个或多个关键业务的并发用户数目C；以及用户测试场景建立模块，用于根据一个或多个关键业务和并发用户数目C来建立模拟软件系统的用户特征的用户测试场景。

其中，关键业务确定模块根据软件系统的多个业务的重要性和常用性来确定一个或多个关键业务。并发用户数目C＝(n*L)/T，其中，n为登录会话的数目，L为登录会话的平均长度，T为第一预定时间。

其中，测试模块通过确定以下信息中的一个或多个来测试软件系统的性能：软件系统的处理能力；软件系统对交易的响应时间；在第二预定时间内登录软件系统的用户数目；在单位时间内软件系统通过其所依托的网络设备和链路传输的数据数量；与软件系统相关的硬件资源的阀值；软件系统的错误率阀值；软件系统的在正常负载下稳定运行的最短时间；同时接入软件系统的最大用户数目；以及在单位时间内软件系统处理的数据记录数量。

通过本发明的方法和系统，可以提高提高软件系统的总体质量并降低运行风险。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明的实施例的软件系统性能测试方法的流程图；以及

图2是根据本发明的实施例的软件系统性能测试系统的框图。

具体实施方式

下面参考附图，详细说明本发明的具体实施方式。

在本发明中，在通常的性能测试技术基础上，进行补充和提炼总结，使测试实现模型化并使测试结果分析指标化，以形成新的、更具备科学方法论的一套方法。

图1是根据本发明的实施例的软件系统性能测试方法的流程图。如图1所示，该软件系统性能测试方法，包括以下步骤：

步骤S102，建立模拟软件系统的用户特征的用户测试场景；

步骤S104，获取软件系统的交易量来建立模拟软件系统的业务特征的业务测试场景；以及

步骤S106，在用户测试场景和性能测试场景下测试软件系统的性能。

其中，步骤S102包括以下步骤：步骤S102-2，确定软件系统的多个业务中的一个或多个关键业务；步骤S102-4，确定一个或多个关键业务的并发用户数目C；以及步骤S102-6，根据一个或多个关键业务和并发用户数目C来建立模拟软件系统的用户特征的用户测试场景。

其中，在步骤S102-2中，根据软件系统的多个业务的重要性和常用性来确定一个或多个关键业务。在步骤S102-4中，并发用户数目C＝(n*L)/T，其中，n为登录会话的数目，L为登录会话的平均长度，T为第一预定时间。

其中，在步骤S106中，通过确定以下信息中的一个或多个来测试软件系统的性能：软件系统的处理能力；软件系统对交易的响应时间；在第二预定时间内登录软件系统的用户数目；在单位时间内软件系统通过其所依托的网络设备和链路传输的数据数量；与软件系统相关的硬件资源的阀值；软件系统的错误率阀值；软件系统的在正常负载下稳定运行的最短时间；同时接入软件系统的最大用户数目；以及在单位时间内软件系统处理的数据记录数量。

图2是根据本发明的实施例的软件系统性能测试系统的框图。如图2所示，该软件系统性能测试系统包括：用户测试场景模块202，用于建立模拟软件系统的用户特征的用户测试场景；业务测试场景模块204，用于获取软件系统的交易量来建立模拟软件系统的业务特征的业务测试场景；以及测试模块206，用于在用户测试场景和性能测试场景下测试软件系统的性能。

其中，用户测试场景模块202包括：关键业务确定模块，用于确定软件系统的多个业务中的一个或多个关键业务；并发用户数目确定模块，用于确定一个或多个关键业务的并发用户数目C；以及用户测试场景建立模块，用于根据一个或多个关键业务和并发用户数目C来建立模拟软件系统的用户特征的用户测试场景。

其中，关键业务确定模块根据软件系统的多个业务的重要性和常用性来确定一个或多个关键业务。并发用户数目C＝(n*L)/T，其中，n为登录会话的数目，L为登录会话的平均长度，T为第一预定时间。

其中，测试模块206通过确定以下信息中的一个或多个来测试软件系统的性能：软件系统的处理能力；软件系统对交易的响应时间；在第二预定时间内登录软件系统的用户数目；在单位时间内软件系统通过其所依托的网络设备和链路传输的数据数量；与软件系统相关的硬件资源的阀值；软件系统的错误率阀值；软件系统的在正常负载下稳定运行的最短时间；同时接入软件系统的最大用户数目；以及在单位时间内软件系统处理的数据记录数量。

以下描述本发明的另一个实施例。

根据性能测试的目标，进行模型建立的步骤如下：

确定用户模型：确定用户执行的关键业务；确定每个关键业务的并发用户量；以及设计模拟用户特征的测试执行方法。

确定业务模型：确定业务系统交易量；测试交易的基准执行时间；以及设计和实际系统相似的性能负载方法。

进行指标确定：确定系统处理能力；确定交易响应时间；确定并发用户数；确定网络吞吐量；确定系统资源阀值；确定错误率阀值；确定稳定性指标；确定并发接入能力；以及确定批量处理效率。根据项目特点和业务要求制定出各指标明确的数值需求并进行验证。

具体地，首先需要根据应用特点分析可能出现的业务高峰特点，确定那些业务需要重点考察，同时建立性能测试模型，保证测试场景能够真实模拟实际情况。根据实际情况编写测试计划。一般情况下，性能测试模型是依靠对过去一段时间内业务统计结果分析来建立。依照实际统计后得到的业务比例数据设计测试场景。若没有历史统计数据，需要和相应的业务人员沟通了解应用将来可能发生的并发情况。

然后开始进行建立测试模型的过程。不管使用的是什么性能测试工具，性能测试模型是否合理都会直接影响到测试结果的可参考性。因此，在开始性能测试之前，一个很关键的步骤就是建立合理的性能测试模型，将来所有的性能测试工作都会以此模型作为依据。测试模型会分为用户模型和业务模型两种，顾名思义，用户模型描述的是用户行为特点的模型。而业务模型则是描述系统业务特点的模型。

一般先开始建立的是用户模型，在用户模型的建立过程中，需要描述用户访问系统的特点，包括用户并发量，操作习惯等。

1、确定用户执行的关键业务

用户执行的关键业务较好确定，从系统业务特点根据业务的重要性和常用性分析出来。

2、确定每个关键业务的并发用户量

确定某一段持续时间内(T)并发用户量的参考方法：C＝(n*L)/T

C为并发用户数，n为登录会话(Login Session)的数量，L为登录会话的平均长度。T为持续的一段时间。其中登录会话为用户登录到系统内的时间(从登入系统开始计算，直到登出系统)。

上面计算的结果是一段时间内的一个平均并发用户数，估算峰值并发用户数方法类似，只是采集的时间区间有所区别。

接下来可以进行业务模型的建立：

首先是获取交易量，这些数据从系统日志中可以较容易的获得，如果没有系统日志，可以根据系统业务特点进行估算。

相对与用户模型，业务模型较容易获得。但是由于业务模型描述的是系统业务特点而不是用户行为特点，因此在使用性能测试工具设计场景的时候，接下来需要将业务量转换成为用户数。转化基础是首先获得个交易的基准执行时间，或通过调整间隔(Interval)时间或通过换算用户数，使的最终场景执行的结果交易量和各业务的比例尽可能的和实际系统相似。

测试的结果通过各种指标来进行综合体现，但是，应该获取哪些指标，这些指标如何去确定，在以往的性能测试方法中是缺失或未进行定义的，本发明针对此类空白进行补充和提炼：

首先是应该确定系统处理能力。

系统处理能力的确定方法是观测和记录系统在利用系统硬件平台和软件平台进行信息处理的能力。一般用HPS和TPS这两个值来记录和衡量系统处理能力。HPS(Hits Per Second)：每秒点击次数，单位是次/秒。TPS(Transaction per Second)：系统每秒处理交易数，单位是笔/秒。系统处理能力通过系统每秒钟能够处理的交易数量来评价，交易有两种理解：一是业务人员角度的一笔业务过程；二是系统角度的一次交易申请和响应过程。前者称为业务交易过程，后者称为事务或业务交易过程的步骤(STEP)。两种交易指标都可以记录和评价应用系统的处理能力，但在具体测试结果中必须说明TPS属于业务交易过程还是其步骤。一般的建议与系统交易日志保持一致，以便于统计业务量或者交易量。系统处理能力指标是性能检测中必须获得指标。

接下来是确定交易响应时间。

响应时间的确定方法是观测并记录用户从客户端发起一个请求开始，到客户端接收到从服务器端返回的响应结束，整个过程所耗费的时间。在性能检测中一般以测试环境中压力发起端至服务器返回处理结果的时间为计量，单位一般为秒或毫秒，该时间不同于模拟真实环境的用户体验时间。性能测试实施中，通过获得典型交易的响应时间来评估被测系统的交易响应时间数据。响应时间最主要的确定方法是观测系统稳定运行时间段内，同一交易的平均响应时间，以此可知，一般而言，交易响应时间均指平均响应时间。平均响应时间指标值应根据不同的交易分别去进行确定，一般情况下，分为复杂交易响应时间、简单交易响应时间、特殊交易响应时间。其中，特殊交易响应时间的设定必须明确该交易在响应时间方面的特殊性。部分应用系统需要设定交易时间戳才能获得完整的交易响应时间。

再接下来的是确定并发用户数。

并发用户数的确定方法是观测并记录同一时刻内，登录系统并进行业务操作的用户数量。并发用户数对于长连接系统来说最大并发用户数即是系统的并发接入能力。对于短连接系统而言最大并发用户数并不等于系统的并发接入能力，而是与系统架构、系统处理能力等各种情况相关。

再接下来的是确定网络吞吐量

网络吞吐量的确定方法是观测并记录在无网络故障的情况下单位时间内通过的网络的数据数量。单位为Byte/S。网络吞吐量指标用于衡量系统对于网络设备或链路传输能力的需求。当在性能测试过程中，发现网络吞吐量指标接近网络设备或链路最大传输能力时，则需要考虑升级网络设备。

再接下来的是确定系统资源阀值。

确定方法是观测并记录定义系统负载情况下，系统关键硬件资源的阀值。分别包括：

CPU利用率阀值：不同负载情况下各应用服务器、数据库服务器等主机的CPU上限。考虑系统稳定性和安全性，一般最大值为70％。

其余还包含：服务器内存占用率，存储设备的I/O吞吐率。

再接下来的是确定错误率阀值。

错误率阀值的确定方法是观测并记录系统在负载情况下，失败交易的概率。错误率＝(失败交易数/交易总数)*100％。不同系统对错误率的要求不同，但一般不超出千分之五。稳定性较好的系统，其错误率应该由超时引起，即为超时率。

再接下来是确定稳定性指标。

稳定性指标的确定方法是观测并记录最短稳定时间，系统在标准压力(系统的预期日常压力)情况下，至少能够稳定运行的最短时间。一般来说，对于正常工作日(8小时)运行的系统，至少应该能保证系统稳定运行10小时以上。对于7X24运行的系统，至少应该能够保证系统稳定运行48小时以上。

再接下来是确定并发接入能力。

并发接入能力的确定方法是观测并记录系统能够同时接入(或登录)的最大连接用户数。但在确定过程中，要注意的是，一般而言，并不是所有接入(或登录)的真实用户都在实时进行操作，部分用户接入(或登录)系统后，暂时不做业务操作，这样的用户操作习惯要求被测系统提供额外的系统并发接入能力。该指标反映出系统对多个连接的访问控制能力和连接状态跟踪能力，这个指标的大小直接影响到系统所能支持的最大信息点数量。

再接下来是确定批量处理效率。

批量处理效率的确定方法是观测并记录批量处理程序单位时间内处理的数据记录数量。一般用每秒处理的数据记录数衡量。处理效率是估算批量处理时间窗口最重要的计算依据。关于批量处理时间窗口，上游系统和下游系统的批量处理时间窗口在起止时间上可以部分重叠。另外，同一系统内部，也可能存在多个批量处理过程同时进行，其时间窗口相互叠加。

最后，根据项目特点和业务要求制定出各指标明确的数值需求，具体方法和过程如下：

1、按照测试目的和测试需求进行指标项的采用和考察。被测系统不同，测试目的不同，测试需求不同，考察的指标项也不相同。但一般性能验证测试包括指标1至7。

2、部分系统涉及额外的前端用户接入能力的，需要考察用户接入能力指标。

3、对于批量处理过程的性能验证，主要考虑批量处理效率并估算批量处理时间窗口。

4、在项目的具体测试需求中应根据相关指标项的定义，明确描述性能指标需求，并根据项目特点和业务要求制定出明确的数值标准。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种软件系统性能测试方法，其特征在于，包括以下步骤：

步骤S102，建立模拟所述软件系统的用户特征的用户测试场景；

步骤S104，获取所述软件系统的交易量来建立模拟所述软件系统的业务特征的业务测试场景；以及

步骤S106，在所述用户测试场景和所述性能测试场景下测试所述软件系统的性能。

2.根据权利要求1所述的软件系统性能测试方法，其特征在于，所述步骤S102包括以下步骤：

步骤S102-2，确定所述软件系统的多个业务中的一个或多个关键业务；

步骤S102-4，确定所述一个或多个关键业务的并发用户数目C；以及

步骤S102-6，根据所述一个或多个关键业务和所述并发用户数目C来建立模拟所述软件系统的所述用户特征的所述用户测试场景。

3.根据权利要求2所述的软件系统性能测试方法，其特征在于，在所述步骤S102-2中，根据所述软件系统的所述多个业务的重要性和常用性来确定所述一个或多个关键业务。

4.根据权利要求2所述的软件系统性能测试方法，其特征在于，在所述步骤S102-4中，所述并发用户数目C＝(n*L)/T，其中，n为登录会话的数目，L为所述登录会话的平均长度，T为第一预定时间。

5.根据权利要求1至4中任一项所述的软件系统性能测试方法，其特征在于，在所述步骤S106中，通过确定以下信息中的一个或多个来测试所述软件系统的性能：

所述软件系统的处理能力；

所述软件系统对所述交易的响应时间；

在第二预定时间内登录所述软件系统的用户数目；

在单位时间内所述软件系统通过其所依托的网络设备和链路传输的数据数量；

与所述软件系统相关的硬件资源的阀值；

所述软件系统的错误率阀值；

所述软件系统的在正常负载下稳定运行的最短时间；

同时接入所述软件系统的最大用户数目；以及

在单位时间内所述软件系统处理的数据记录数量。

6.一种软件系统性能测试系统，其特征在于，包括：

用户测试场景模块，用于建立模拟所述软件系统的用户特征的用户测试场景；

业务测试场景模块，用于获取所述软件系统的交易量来建立模拟所述软件系统的业务特征的业务测试场景；以及

测试模块，用于在所述用户测试场景和所述性能测试场景下测试所述软件系统的性能。

7.根据权利要求6所述的软件系统性能测试系统，其特征在于，所述用户测试场景模块包括：

关键业务确定模块，用于确定所述软件系统的多个业务中的一个或多个关键业务；

并发用户数目确定模块，用于确定所述一个或多个关键业务的并发用户数目C；以及

用户测试场景建立模块，用于根据所述一个或多个关键业务和所述并发用户数目C来建立模拟所述软件系统的所述用户特征的所述用户测试场景。

8.根据权利要求7所述的软件系统性能测试系统，其特征在于，所述关键业务确定模块根据所述软件系统的所述多个业务的重要性和常用性来确定所述一个或多个关键业务。

9.根据权利要求7所述的软件系统性能测试系统，其特征在于，所述并发用户数目C＝(n*L)/T，其中，n为登录会话的数目，L为所述登录会话的平均长度，T为第一预定时间。

10.根据权利要求6至9中任一项所述的软件系统性能测试系统，其特征在于，所述测试模块通过确定以下信息中的一个或多个来测试所述软件系统的性能：

所述软件系统的处理能力；

所述软件系统对所述交易的响应时间；

在第二预定时间内登录所述软件系统的用户数目；

在单位时间内所述软件系统通过其所依托的网络设备和链路传输的数据数量；

与所述软件系统相关的硬件资源的阀值；

所述软件系统的错误率阀值；

所述软件系统的在正常负载下稳定运行的最短时间；

同时接入所述软件系统的最大用户数目；以及

在单位时间内所述软件系统处理的数据记录数量。

Images