压力测试,性能测试,负载测试.

《压力测试,性能测试,负载测试.》由会员分享，可在线阅读，更多相关《压力测试,性能测试,负载测试.（23页珍藏版）》请在金锄头文库上搜索。

1、网站压力测试压力测试通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。 极限压力测试举例： 1） 接收大数据量的数据文件时间； 2） 大数据恢复时间； 3） 大数据导入导出时间； 4） 大批量录入数据时间； 5） 大数据量的计算时间； 6） 多客户机同时进行某一个提交操作； 7） 采用测试工具软件； 8） 编写测试脚本程序； 9） 大数据量的查询统计时间。 实例： 在一个系统内，仅有一个用户登录使用相同的操作，对不同的数据量进行测试。记录下数据量和对应的资源占用率，响应时间。压力测试案例

2、案例：HKMA于2006年对香港零售银行业面临宏 观经济冲击时的信用风险暴露进行压力测试。 分析结果表明，银行贷款违约率与关键宏观经 济因素（包括香港GDP、利率、房价以及内地 GDP）之间有明显的相关性。 测试结果：以VAR计，在90%的置信水平上，银 行能继续盈利，说明信用风险较小。在极端情 况下，以VAR计，在99%的置信水平上，有些银 行会面临损失，不过这种极端情况发生的概率 非常低。 步骤一：定义模型 步骤二：估计模型 步骤三：模型估计结果分析 步骤四：设计冲击场景 步骤五：构造频率分布 步骤六：计算均值和VaR 步骤七：测算银行盈利能力所受影响 只是把它算的过程归了一下类，分了这几

3、个步骤。这是在06年对香港的零售银行业，它也假设一家 银行面对宏观经济冲击时的信用风险暴露进行的压力测试。分析结果表明银行贷款违约率与关键宏观经济因素有相关性，宏观经济因素主要是香港的GDP和利率、 房价以及内地的GDP。测试的结果是以VaR计，在90%的置信水平上，银行能继续盈利，说明信用风险较小。在极端情况下，以VaR计，在99%的置信水 平上，有些银行会面临损失，不过这种极端情况发生的概率非常低。这只是一个预警。 把它的过程归纳成七个步骤，包括后面计算盈利能力的方面。首先是定义一下这个模型，在模型有自变量和应变量，它定义了4个应变量。应变量是它需要考察信用违约率，它违约率的定义是这样的，

4、逾期3个月以上的贷款和贷款总额，不知道现在的银行是不是用违约率这么一个数据。这个数据算出来也挺难的，平时公布的数据，还是不良贷款率公布得比较多，关于违约率的定义没有比较准确的，有的是定义上一期能够正常还款下一期不能正常还款的，所以现在看到违约率的定义也有几种。不良贷款毕竟前几年商业银行剥离的政策原因太大了，可能这个时间序列有一定的不可抵因素，就是歧义点太多。 看一下这个估计模型，这是94年4月到06年1月的零售银行的数据。前面是自变量，这是用历史数据估算出来的结果，包括了参数变量也体现出来了。最下面是观测值，还有测试的个数。 可以看得出来，它的符号还是一致的，因为前面是违约率用Log这个函数给

5、它导了一下，所以经济环境越好的话，资产的质量会越高，这样的话，VaR的数值应该越低。可以看得出来，这跟经济增长和房地产的价格，跟利率是呈正相关的。 同时，这上面提了一下，其实自变量里面有很多的二级滞后项，这是剔除了一级滞后项以后得出的， 原本很多其他的相关变量没有列进来了，所以这是最后模拟出来的结果。模拟出来这个方程以后，下一步是要设定的冲击场景。先要设计模型、估计模型，最后要把 新的数据带到我们模型里面去。就是把先的自变量带到模型里面，让它变成新的应变量。那么，新的自变量怎么办呢？比如说我们的经济冲击发生以后，我们的影响 是怎么样的。实际上，它和经济危机是差不多的，碰到了4个冲击点。一个是我

6、刚才提到的4个自变量，它对于每个变量都有一个冲击，第一个是香港实际GDP的 变化，还有一个是大陆实际GDP的变化，还有利率和房地产。它不是只对当期的自变量发生了变化，它实际上是延长了时间，把这个影响时间变成了2年。所以， 在金融危机以后，这个应变量应该发生多大的变化。在97年的四季度利率是306个基点，后面两个季度下降了，第四个季度又上升了314个基点。可以看得出来，一开始是300多个基点，后面两个季度没有变化，第四个季度上升上来了，这跟当时的亚洲金融危机的冲击差不多。 然后，紧接着下来是要模拟了，因为把这个数据输入到模型里面去以后，可以模拟出来的数据以后， 可以把新的概率分布算出来了。当然，

7、这还有一个假设，就是在四季度以后不再有冲击了，对每一个基期场景和压力场景对未来违约率路径进行1万次的模拟。有了 新的频率分布以后，可以构造我们信用损失百分比的频率分布。刚才模拟的是违约率的频率分布，我们的损失百分比的数据应该是违约率乘上违约损失率。 现在要定义一下违约损失率这个数据，这个数据现在比较有争议，到底怎么定？如果没有合适的统计量，对于市场的有关信息来赋值，通常定为50%。按照 BASELII要求LGD取45%，但这个数字并不十分合理。所以，现在定义为2%低点的公式。这样，可以用违约损失率乘以我们刚刚计算出的违约率的数， 这样可以得出一个信用损失百分比频率分布的数据。冲击发生了以后，实

8、际上我们把频率往右移了，可以看出信用损失百分比的数据，出现高的数据频率增加了，原 来是把这个频率往外偏移，所以可以看出较高信用损失百分比出现的频率增加了，较小的信用损失百分比出现的频率减少了。 通过算分布可以算出信用损失百分比的均值，还可以算出遭受损失的概率是多大，可以做这么一个精细的判断。这是计算以后的结果，它的均值是这样的，首先是基期没 有发生信贷信用损失百分比，均值是0.34，压力期GDP冲击是1.59，房价冲击是1.21，利率冲击是0.71，大陆经济冲击是0.73。在 VaR90%信用损失百分比是这个数据，随着置信区间的增加，损失的百分比也是递增的。最后一个是99.99%，这个时候已经

9、是相当高了，后面两个已经接 近10%，前面的已经超过10%了。 在90%的置信水平的情况下，可以看出3%以下还是过得去的。在99%的情况下，数值已经比较 高了，这是在3.22，这是最低的值，最高的到了5.56，应该是比较高了。这跟金融危机发生1年以后的情况是比较吻合的，所以做压力测试要考虑一下当期 和影响的延长期还是比较符合实际的。这里面的测算是在亚洲金融危机以前，银行用这个测算可以算出银行贷款损失率为1.4%，贷款损失率上升到6.0%，但是这个估计是基于估计LGD为70%。那么，这就给提出一个问题，这是不是合理，这可能是在测试的时候需要考虑的。 最后一步是测算冲击对银行盈利能力的影响。也许银

10、行管理层觉得，这个VaR值或者是概率是多 少，可能在90%的置信期间里面有多大的，在99%到底有多大，这对于盈利能力有多少？盈利下降了多少？是不是可以给这么一个数据，那么也可以通过一个测 算算得出来。如果认可前面的测算，就是贷款损失百分比，通过这个可以算出来，损失肯定是等于贷款损失百分比乘贷款余额。 就是冲击发生以后，银行的盈利能力发生的变化。首先，没有发生违约的情况下，那么它未来冲击发生以后它的盈利应该比当前或者是基期是一样的。如果我盈利是 30亿，那么冲击以后属于没有发生违约，那么这个盈利是一样的。如果发生了冲击以后，如果我下降了，下降了多少就是损失。 假设有一家银行，这家银行拨备前利润是

11、30亿，贷款余额是1300亿港币。假设有一家银行规模是这么大，可以用上面的贷款损失百分比来测算，这家银行在发生了冲击以后，在不同的置信区间里面它的盈利能力会受到多大的影响，这是得出的结果。 单位用百万来表示，正的数据是表示盈利，负的就表示已经损失了，管理层看到这张表可能就比较清楚了银行可能发生多大的损失。 比如说在90%的区间里面，香港的GDP冲击情况下这家银行要亏损8.82万亿港币。那么，这 个是99.99%，就是这个事情发生的概率非常强了，因为置信区间在99.99%，是0.001%的可能性，这个损失已经是到了133亿了。在不同的置信 区间里面，它的损失是不一样的。回想一下，如果没有模拟，就

12、是一个假设，假设GDP是多少，刚才已经提出来了，从前面可以看到，GDP的数据是多少，在每 一个季度是多少，如果没有模拟，直接把这个数据带回到模型里面，只算出一个贷款百分比的数据。现在有了模拟以后，就知道它的均值是多少，在不同的置信区间 里面是多少。这样，管理层可能会感觉清醒一点。比如说基期在没有违约的情况下，是2554百万，还是挺好的。如果做压力测试把这张表给管理层，就很清晰地 知道损失有多大了。 最后有一个表述，在90%的置信水平下，VaR值是882万，如果在99%的水平下，VaR值是比较大的，导致这样的VaR的极端场景发生的概率是1%。性能测试性能测试是通过自动化的测试工具模拟多种正常、峰

13、值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。应用在客户端性能的测试应用在客户端性能测试

14、的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能性能测试图像测试是重点。 并发性能测试是重点 并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够

15、接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。 并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。 当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候，尤其是以后在生产环境中实际使用起来，用户往

16、往会产生疑问，这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。 举例说明：电信计费软件 众所周知，每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为 两步，首先要根据用户提出的电话号码来查询出其当月产生费用，然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤，但当成百上千的终 端，同时执行这样的操作时，情况就大不一样了，如此众多的交易同时发生，对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力，预见软件的并发承受力