CN101625658B

CN101625658B - 一种软件系统性能测试方法

Info

Publication number: CN101625658B
Application number: CN2009101615888A
Authority: CN
Inventors: 余昌德; 邱世魁
Original assignee: Aspire Information Technologies Beijing Ltd
Current assignee: Aspire Information Technologies Beijing Ltd
Priority date: 2009-08-04
Filing date: 2009-08-04
Publication date: 2011-01-12
Anticipated expiration: 2029-08-04
Also published as: CN101625658A

Abstract

本发明涉及一种软件系统性能测试方法，包括(1)确定测试点和系统性能容量；(2)记录初始状态下某场景组合中各测试点的测试数据；(3)逐步加压，记录测试点在不同压力状态下的测试数据；(4)得出测试点性能变化情况；(5)获得性能恶化测试点；(6)对恶化测试点加压，若加压过程中系统性能符合设计要求，则继续(7)；若不符合要求，则进行相应记录，转入(8)；(7)对恶化测试点进行更大容量压力测试；(8)减小压力，使系统回退至初始状态；(9)若回退后系统正常，则选择一种新的场景组合，转入(2)；若回退后系统不正常，则进行记录，结束测试。本发明能够动态调整各测试点的压力分配量，克服了传统静态测试方法的缺点。

Description

一种软件系统性能测试方法

技术领域

本发明属于计算机应用技术领域，具体涉及一种计算机软件性能测试方法。

背景技术

性能测试作为测试领域一个重要的组成部分，越来越为广大的系统建设者和使用者所重视。往往一些系统在功能上完全负荷需求和设计要求，但就是因为某些局部的性能问题没有全面的测试到就仓促上线，导致系统的重大故障，最终功败垂成。所以，性能测试与功能测试同样需要在系统上线前有一个全面的完整的测试，杜绝系统可能发生的问题。

传统的性能测试方法缺点在于静态的策略模式，在测试执行过程中不可以更改测试分配在各测试点的流量，这是一种简单化的机械式的执行流程。这种流程的主要问题如下：

首先，传统的性能测试方法不仅要对被测系统有个全面的了解，明确各个测试点，而且还必须知道，系统的瓶颈在哪里，哪个被测试点是短板，哪些使用场景组合能造成系统的最大负荷。只有以上的情况都了解清楚了，整个性能测试工作才能顺利进展并完成。而摸索哪些测试点是系统瓶颈的过程，往往要耗费大量的性能测试时间，致使性能测试效率的降低。

其次，传统的性能测试方法对于单次性能测试操作来说，只能获得一组性能测试数据，这组数据是针对本次性能测试场景的结果描述。如要获得多组性能测试结果，必须设计多个性能测试脚本，并触发多次性能测试操作来完成，而往往被测系统的性能很难用一两组性能数据来描述其全貌，这就要求性能测试人员反复进行脚本的设计和操作的触发来完成，其效率也是受影响的。

再次，对一些较为复杂的场景组合或一些不可预见的场景，如果测试人员之前没有在脚本设计时注意到，通过传统的性能测试方法来测试就会造成性能测试疏漏，有可能没有真正捕捉到系统的瓶颈，有可能得出的系统性能指标虚高。这就是为什么有时经过性能测试的系统，在现网运行期间，经历设计运行的用户流量使用过程中，出现由于某些性能问题意外宕机的现象。

发明内容

本发明的技术解决问题是：克服现有技术的不足，提供一种软件系统性能测试方法。该测试方法利用测试工具与被测系统交互时获得的数据实时进行计算，随时调整在各测试点上的压力分配量，克服了传统静态测试方法的缺点。

本发明的技术解决方案是：

一种软件系统性能测试方法，包括以下步骤：

(1)确定系统测试点和系统性能容量，编制测试脚本，所述测试脚本涵盖所述测试点；根据系统的复杂度选取适当数量的系统场景组合；

(2)记录系统初始压力状态下某种系统场景组合中各测试点的性能测试数据；

(3)逐步加压，记录所述测试点在不同压力状态下的性能测试数据；

(4)分析所述测试点在不同压力状态下的性能测试数据，得出测试点性能变化情况；

(5)根据测试点性能变化情况，获得性能恶化的若干测试点；

(6)对性能恶化的若干测试点进行加压，判断加压过程中系统性能是否符合设计要求；若系统性能符合设计要求，则继续下一步；若系统性能不符合设计要求，则记录下该系统场景压力情况及压力数据，转入步骤(8)；

(7)对所述性能恶化的若干测试点进行更大容量压力测试；

(8)减小压力，使系统回退至初始压力状态；

(9)判断回退至初始压力状态后的系统是否正常，若系统正常，则避开已经检验过的系统场景组合，选择一种新的系统场景组合，转入步骤(2)；若系统不正常，则记录下系统在该场景组合下的压力表现，结束测试。

进一步地，所述步骤(1)中确定系统性能容量为：在有预知系统性能容量的情况下，确定该预知系统性能容量为系统性能容量；在没有预知系统性能容量的情况下，保守地预估一个性能容量，将其确定为系统性能容量。

所述步骤(3)中逐步加压为均匀地加压或随机地递增加压。

所述步骤(4)中对所述测试点在不同压力状态下的性能测试数据进行纵向和横向比较，得出测试点性能恶化排序；所述纵向比较，是指每个测试点以时间轴为依据，比较自身的性能变化情况；所述横向比较，是指在某个特定时间点上，比较多个测试点的性能变化情况。

所述步骤(6)中对性能恶化的若干测试点进行重点加压，对别的测试点非重点加压、保持压力或减轻压力。

所述步骤(7)中对所述性能恶化的若干测试点进行更大容量压力测试为：继续加压，直至系统临界正常，获得系统在此种场景组合下所支持的最大用户数。

所述步骤(7)中对所述性能恶化的若干测试点进行更大容量压力测试为：依次按系统预估性能容量的120％、150％及200％输出压力，继续进行施压，并记录每个压力里程碑的系统表现，检查系统的鲁棒性。

所述步骤(9)中若回退至初始压力状态后的系统响应正常，且系统的性能指标与初始压力状态下的系统表现基本一致，则避开已经检验过的系统场景组合，选择一种新的系统场景组合，转入步骤(2)。

所述步骤(9)中若回退至初始压力状态后的系统响应正常，但系统的性能指标达不到初始压力状态下的系统表现，则记录这一现象，然后避开已经检验过的系统场景组合，选择一种新的系统场景组合，转入步骤(2)。

所述步骤(5)中，获得性能恶化测试点的方法为：看压力加在哪个测试点上使得系统发生的形变比例最大(注意是形变的比例而不是形变的绝对值，因为形变的绝对值无法完全描述相对形变的量值)。方差判断法是按比例判断法中常用的一种判断法，本发明采用方差法来判断。方差判断法是看压力加在哪个测试点上使得系统各测试点的方差最大，即通过公式

\sqrt{1 / n [{(x 1 - {x 1}_{m})}^{2} + {(x 2 - {x 2}_{m})}^{2} + {(x 3 - {. x 3}_{m})}^{2} + . . . + {(xn - {xn}_{m})}^{2}]}

(其中，n为测试点的个数，m为初始压力状态，x1～xn为某一压力状态下系统各测试点的表现，x1_m～xn_m为初始压力状态下系统各测试点的表现)计算多个系统场景组合中各测试点的方差，找出相同压力量输入下方差最大的那个系统场景组合。

本发明与现有技术相比具有如下优点：

第一，本发明的测试方法是一种智能的测试方法，它不同于以往依靠测试人员不断修改和设计新的测试脚本来反复测试的性能测试模式，而是采用了以测试压力输入和被测系统性能反馈为基础，进行一定的数据分析和比较，确定出系统瓶颈的可能位置。克服了传统静态测试模式在测试执行过程中不能更改测试分配在各测试点的流量的缺点。

第二，本发明的测试方法在测试过程中可动态调整策略，在测试之初无需由测试人员确定出一整套的测试路径和策略，无需限定死向各个测试点输出的压力量。本发明根据系统在压力状态下的表现和逐步获得的测试结果，能够随时调整压力测试策略，向系统可能存在的瓶颈点加压，从而得出系统的最可能出性能问题的地方和系统的最大负荷。克服了常规的相对固化的性能测试方法的不足，能够随着性能测试的深入进行对系统适应性地调整性能测试策略，从而找到该系统若干可能的瓶颈和典型的性能弱点，为系统的深度优化创造了条件。

第三，本发明的测试方法是一种探索式的性能测试方法，随着测试进程的深入，测试工具能够结合系统的反馈，探索出几条可能的测试场景，分别代表着系统的几类性能瓶颈，最后获得一次触发测试，得出多种场景结果的高效的性能测试方式。而传统静态测试方法只是相对固化的性能测试方法，只能获得一种系统瓶颈场景组合。

第四，本发明的性能测试方法通过模拟不同的用户场景组合，启动一次测试就能够探索出未知的多个系统瓶颈场景组合出来。相比传统测试方法，效率优势更加明显，并且便捷。

附图说明

以下将结合附图对本发明的具体实施方式进行说明。

图1为本发明的软件系统性能测试方法流程图。

具体实施方式

如图1所示，本发明的软件系统性能测试方法包括以下步骤：

1)人工对被测系统进行评估，找到若干个希望得到性能数据的测试点。

2)用测试工具录制测试脚本或在测试工具上编写测试脚本，涵盖前面评估的测试点。

3)对于有预知系统性能容量的情况下，在测试工具上输入此性能容量，在没有预知系统性能容量的情况下，可先相对保守的预估一个性能容量并输入到测试工具中。

4)测试工具采用对系统多个测试点逐步加压的方式进行压力输出，起初可以是均匀或随机的递增压力。

5)性能测试开始阶段，测试工具所获得的性能测试数据结果，为基础值，表征系统在无压力或极小压力的情况下，各测试点的性能表现。

6)随着性能测试进程的深入，测试工具对于上述若干个测试点会获得更多的性能数据，这些数据所体现的系统性能是不断动态变化的，测试工具记录下这些变化。

7)测试工具进行纵向(每个测试点以时间轴为依据，比较自身的变化情况)和横向(在某个特定时间点上，比较多个测试点的性能变化情况)比较这些数据的变化，得出测试点性能恶化(性能下降很快，系统响应变慢)排序。

8)测试工具经过比较可得出性能恶化最大的两到三个测试点，对这几个测试点进行有针对性的加压，别的测试点可非重点加压、保持压力或减轻压力(在总用户量一定的情况下，为保证对恶化测试点足够的压力)。

在测试压力小于系统设计容量的情况下，在多个业务用户容量点上轮流加压，若发现某个或某几个测试点上系统的性能下降比较大，则重点增加这些测试点的用户量，直至达到系统的设计容量，观察系统瓶颈点上系统性能的表现。

具体操作举例如下：

例一：两个业务用户容量的组合为系统的设计用户容量，当压力增长到系统的设计容量50％时，即A业务用户容量和B业务用户容量的组合总容量为某应用系统的设计用户容量的50％。可动态地调整A业务用户容量与B业务用户容量的比例，从5％∶95％到95％∶5％，对于每个容量比情况计算一次方差，每次A业务用户容量递增变化5％，这样就覆盖了A业务用户容量和B业务用户容量的各种比例变化，将之前获得的若干个方差值相互比较，得出最大值，则该方差最大值对应的场景组合就是系统的瓶颈所在。

例二：三个或三个以上的业务用户容量的组合为系统的设计用户容量50％时，即A业务用户容量、B业务用户容量和C业务用户容量的组合总容量为某应用系统的设计用户容量。可首先固定A业务用户容量为5％，动态地调整B业务用户容量、C业务用户容量的组合，计算此时系统的方差；然后提高A业务用户容量的比例(如提升到10％)，再动态地调整B业务用户容量、C业务用户容量的组合，计算系统的方差；直到A业务用户容量的比例提升到95％，依然计算系统的方差，这样就覆盖了系统的各种业务用户容量组合。将之前获得的若干个方差值相互比较，得出最大值，该方差最大值对应的场景组合就是系统的瓶颈点。若A、B、C三个点的业务容量比例为90％∶5％∶5％时方差值最大，则说明A测试点对系统的性能影响最大，剩余的系统设计容量的50％压力都应该加给A测试点。

9)加压过程中，若系统的性能表现已经不符合设计要求，则由测试工具记录下该系统整体场景压力情况及压力数据。最后，性能测试工具减少压力，回退至初始状态。

10)加压过程中，若压力加载已达系统的预计估算容量，系统的性能表现还属正常范围内，则有几种选择，一是继续加压，直至系统临界正常，从而获得系统在此种场景下的所支持的最大用户数；二是按系统预计估算容量的120％、150％及200％输出压力(120％没问题就用150％，150％再没问题就用200％)，进行继续施压，并记录每个压力里程碑的系统表现，从而检查系统的鲁棒性。最后，性能测试工具减少压力，回退至初始状态。

11)性能测试工具经过前一轮的大量输出压力得到一轮数据，并回退到初始状态后，工具观察系统是否响应正常，若响应非正常则记录系统各方面情况，结束测试，由测试人员根据之前的测试结果来判断系统故障情况。

12)性能测试工具经过前一轮的大量输出压力得到一轮数据，并回退到初始状态后，工具观察系统是否响应正常，若响应正常，且系统的性能指标与之前低压力情况下系统的表现基本一致说明暂时没有发现系统资源未释放现象，若系统响应正常，但系统的性能指标达不到之前相同低压力情况下的系统表现，说明系统的某些资源没有很好的释放，测试工具记录这一现象，等测试结束后由测试人员进行进一步的系统故障情况分析。

13)性能测试工具经过前一轮的大量输出压力得到一轮数据，并回退到初始状态后，在系统响应正常的情况下，性能测试工具再重复之前的随机加压的方式，并避开之前已经检验过的系统场景组合，探索新的未知系统瓶颈场景。

14)如此周而复始，根据系统的复杂度获得数量不等的系统瓶颈场景情况，对于小型系统来说可以获得典型的3～5个瓶颈场景，对于中型系统来说可以获得典型的8～10个瓶颈场景，对于大型系统来说可以获得典型的15～20个瓶颈场景。

实施例：对某帐务系统进行性能测试。

人工对被测系统进行评估，找到3个系统可能存在瓶颈的测试点：A(查询用户当前帐期的欠费情况)、B(查询用户所能享受的各项优惠情况)、C(对用户当前帐期的帐务做销帐处理)。用测试工具录制测试脚本或在测试工具上编写测试脚本，涵盖前面评估的3个测试点。本帐务系统的设计性能容量为1秒钟最多支持100次业务访问，且对于单次业务访问的最大系统响应时间不超过10秒钟。测试工具采用对系统多个测试点逐步加压的方式进行压力输出，起初可以是均匀或随机的递增压力。性能测试开始阶段，测试工具所获得的性能测试数据结果为基础值，表征系统在无压力或极小压力的情况下，3个测试点的性能表现如下：A场景耗时2.15秒，B场景耗时1.05秒，C场景耗时3.70秒。加大系统压力到系统设计容量的50％，即每秒50次访问，A、B、C三个场景按照5％的递进比例进行分配压力，并对每个压力组合按公式：

\sqrt{1 / n [{(x 1 - {x 1}_{m})}^{2} + {(x 2 - {x 2}_{m})}^{2} + {(x 3 - . {x 3}_{m})}^{2} + . . . + {(xn - {xn}_{m})}^{2}]}

进行方差计算，计算结果如下表所示：

A、B、C的比例	方差值
		5％∶5％∶90％	7.47
5％∶10％∶85％	7.13
		5％∶15％∶80％	6.85
......	......
		35％∶5％∶60％	5.22
35％∶10％∶55％	5.19
		......	......
60％∶15％∶25％	2.33
		60％∶20％∶20％	2.31
......	......

85％∶5％∶10％	2.73
		85％∶10％∶5％	2.68
90％∶5％∶5％	2.57

经比较方差得出A、B、C场景比例为5％∶5％∶90％时系统性能最差，且发现对于C点的压力的增加对系统的性能影响最大，则把余下50％的压力都加给C点，得出系统的性能表现，发现C点的响应时间已经恶化为21.45秒，高于系统要求的10秒响应时间。最后，性能测试工具减少压力，回退至初始状态，发现系统表现正常，说明暂时没有发现系统资源未释放现象。

综上所述，本发明的性能测试方法通过模拟不同的用户场景组合，启动一次测试就可以探索出未知的多个系统瓶颈场景组合出来。

本方法克服了常规的相对固化的性能测试方法，可以随着性能测试的深入进行对系统适应性的调整性能测试策略，从而找到该系统若干可能的瓶颈和典型的性能弱点，为系统的深度优化创造了条件。

本发明说明书中未作详细描述的内容属于本领域专业技术人员公知技术。

本发明不局限于权利要求和上述实施例所述及的内容，只要是根据本发明的构思所创作出来的任何发明，都应归属于本发明的保护范围之内。

Claims

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

(5)根据测试点性能变化情况，获得性能恶化的若干测试点；

(7)对所述性能恶化的若干测试点进行更大容量压力测试，记录相应的测试数据；

(8)减小压力，使系统回退至初始压力状态；

2.根据权利要求1所述的软件系统性能测试方法，其特征在于，所述步骤(1)中确定系统性能容量为：在有预知系统性能容量的情况下，确定该预知系统性能容量为系统性能容量；在没有预知系统性能容量的情况下，保守地预估一个性能容量，将其确定为系统性能容量。

3.根据权利要求1所述的软件系统性能测试方法，其特征在于：所述步骤(3)中逐步加压为均匀地加压或随机地递增加压。

4.根据权利要求1所述的软件系统性能测试方法，其特征在于：所述步骤(4)中对所述测试点在不同压力状态下的性能测试数据进行纵向和横向比较，得出测试点性能恶化排序；所述纵向比较，是指每个测试点以时间轴为依据，比较自身的性能变化情况；所述横向比较，是指在某个特定时间点上，比较多个测试点的性能变化情况。

5.根据权利要求1所述的软件系统性能测试方法，其特征在于：所述步骤(6)中对性能恶化的若干测试点进行重点加压，对别的测试点非重点加压、保持压力或减轻压力。

6.根据权利要求1所述的软件系统性能测试方法，其特征在于，所述步骤(7)中对所述性能恶化的若干测试点进行更大容量压力测试为：继续加压，直至系统临界正常，获得系统在此种场景组合下所支持的最大用户数。

7.根据权利要求1所述的软件系统性能测试方法，其特征在于，所述步骤(7)中对所述性能恶化的若干测试点进行更大容量压力测试为：依次按所述系统性能容量的120％、150％及200％输出压力，继续进行施压，并记录每个压力里程碑的系统表现，检查系统的鲁棒性。

8.根据权利要求1所述的软件系统性能测试方法，其特征在于：所述步骤(9)中若回退至初始压力状态后的系统响应正常，且系统的性能指标与初始压力状态下的系统表现基本一致，则避开已经检验过的系统场景组合，选择一种新的系统场景组合，转入步骤(2)。

9.根据权利要求1所述的软件系统性能测试方法，其特征在于：所述步骤(9)中若回退至初始压力状态后的系统响应正常，但系统的性能指标达不到初始压力状态下的系统表现，则记录这一现象，然后避开已经检验过的系统场景组合，选择一种新的系统场景组合，转入步骤(2)。