识别那些可能提高异常利润或损失发生概率的事件或情境，度量这些事件发生时银行资本充足率状况。测试的质量取决于构造合理、清晰、全面的情景。

银行的压力测试通常包括信用风险、市场风险、操作风险、其他风险等方面内容。压力测试中，商业银行应考虑不同风险之间的相互作用和共同影响。

压力测试包括敏感性测试和情景测试等具体方法。敏感性测试旨在测量单个重要风险因素或少数几项关系密切的因素由于假设变动对银行风险暴露和银行承受风险能力的影响。情景测试是假设分析多个风险因素同时发生变化以及某些极端不利事件发生对银行风险暴露和银行承受风险能力的影响。

压力测试能够帮助商业银行充分了解潜在风险因素与银行财务状况之间的关系，深入分析银行抵御风险的能力，形成供董事会和高级管理层讨论并决定实施的应对措施，预防极端事件可能对银行带来的冲击。对于日常管理中广泛应用各类风险计量模型的银行，压力测试应成为模型方法的重要补充。压力测试也能够帮助银监会充分了解单家银行和银行业体系的风险状况和风险抵御能力。

进行压力测试的方法，大致可归纳为两大类：

（1）敏感度分析（sensitiveanalysis）

此方法是利用某一特定风险因子或一组风险因子，将因子在执行者所认定的极端变动的范围内变动，分析其对于资产组合的影响效果。这一分析方法的优点在于容易了解风险因子在可能的极端变动中，每一变动对于资产组合的总影响效果及边际效果，缺点则是执行者对于每一逐渐变动所取的幅度及范围必须十分恰当，否则将会影响分析的结果与判断，特别是对于非线性报酬率的资产组合，这种情况将更为显著。

（2）情景分析（scenarioanalysis）

即一组风险因子定义为某种情景，分析在个别情景下的压力损失，因此此类方法称为情景分析。情景分析的事件设计方法有两种：历史情景分析和假设性情景分析。

① 历史情景分析（Historicalscenario）：利用某一种过去市场曾经发生的剧烈变动，评估其对资产组合会产生什么影响。例如考虑1987年美国股市崩盘，计算当时的历史变动幅度，并依此基础分析评估对资产组合的影响。BCGFS（2001）的研究显示，1998年俄罗斯政府违约事件，是金融机构用来在信用风险压力测试上使用的压力事件，其他如中南美洲比索风暴、东南亚金融风暴亦是很重要的压力事件。这种方法的优点是具有客观性，利用历史事件及其实际风险因子波动情形，在建立结构化的风险值计算上较有说服力，且风险因子间的相关变化情形也可以依历史数据作为依据，使模型假设性的情形降低许多。此外，这种模型较直觉，重大历史事件的深刻印象将使风险值与历史事件紧密结合，管理者在设定风险限额时，便可依历史事件的意义来进行评估，使决策更具说服力。

但这种方法的缺点在于现今金融市场变动非常迅速，许多金融商品不断创新，因此历史事件无法涵盖此类商品，且某些商品的历史价格未出现极端情况，亦无法利用此方法进行衡量。虽然过去发生过的情景未来不一定会再发生，但使用历史情景分析方法来对资产进行风险管理，至少可保证过去的压力事件，在事前预防下，未来不会重演。

② 假设性情景分析：仅以历史情景分析进行压力测试有其限制，参考历史事件并另建立对于每个风险因子可能产生的极端事件，将使得压力测试更具完整性，这就是假设性情景分析。这种分析方法银行可自行设计可能的各种价格、波动及相关系数等的情景，这些计算的设定主要来自经验及主观。

目的是在软件投入使用以前或软件负载达到极限以前，通过执行可重复的负载测试，了解系统可靠性、性能瓶颈等，以提高软件系统的可靠性、稳定性，减少系统的宕机时间和因此带来的损失。

情境压力测试即主体向被观察者布置一定任务和作业，借以观察个体完成任务的行为。工作样本测验、无领导小组讨论都可算作情境压力测验。

在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。网络游戏中也常用到这个词汇。

网络定义：

2009年9月7日下午，移动公司开商务车装载200多部电信手机，在温州某大学边上不停拨打，导致电信网络瘫痪。电信发现后连车带人押送到公安局，在公安局，移动自称没有违法，只是帮电信做压力测试。

“压力测试”与俯卧撑、打酱油等词汇一样，成为网络流行词汇。

压力测试、终端机性能功率、各项性能趋势指标等。

压力测试通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大的服务级别的测试。通俗地讲，压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。

极限压力测试举例：

1） 接收大数据量的数据文件时间；

2） 大数据恢复时间；

3） 大数据导入导出时间；

4） 大批量录入数据时间；

5） 大数据量的计算时间；

6） 多客户机同时进行某一个提交操作；

7） 采用测试工具软件；

8） 编写测试脚本程序；

9） 大数据量的查询统计时间。

实例：

在一个系统内，仅有一个用户登录使用相同的操作，对不同的数据量进行测试。记录下数据量和对应的资源占用率，响应时间。

案例：HKMA于2006年对香港零售银行业面临宏观经济冲击时的信用风险暴露进行压力测试。分析结果表明，银行贷款违约率与关键宏观经济因素（包括香港GDP、利率、房价以及内地 GDP）之间有明显的相关性。

测试的结果是以VaR计，在90%的置信水平上，银行能继续盈利，说明信用风险较小。在极端情况下，以VaR计，在99%的置信水平上，有些银行会面临损失，不过这种极端情况发生的概率非常低。这只是一个预警。

测试过程分成以下几个步骤：

步骤一：定义模型

步骤二：估计模型

步骤三：模型估计结果分析

步骤四：设计冲击场景

步骤五：构造频率分布

步骤六：计算均值和VaR

步骤七：测算银行盈利能力所受影响

把它的过程归纳成七个步骤，包括后面计算盈利能力的方面。首先是定义一下这个模型，在模型有自变量和应变量，它定义了4个应变量。应变量是它需要考察信用违约率，它违约率的定义是这样的，逾期3个月以上的贷款和贷款总额，不知道银行是不是用违约率这么一个数据。这个数据算出来也挺难的，平时公布的数据，还是不良贷款率公布得比较多，关于违约率的定义没有比较准确的，有的是定义上一期能够正常还款下一期不能正常还款的，所以看到违约率的定义也有几种。不良贷款毕竟前几年商业银行剥离的政策原因太大了，可能这个时间序列有一定的不可抵因素，就是歧义点太多。

看一下这个估计模型，这是94年4月到06年1月的零售银行的数据。前面是自变量，这是用历史数据估算出来的结果，包括了参数变量也体现出来了。最下面是观测值，还有测试的个数。

可以看得出来，它的符号还是一致的，因为前面是违约率用Log这个函数给它导了一下，所以经济环境越好的话，资产的质量会越高，这样的话，VaR的数值应该越低。可以看得出来，这跟经济增长和房地产的价格，跟利率是呈正相关的。

同时，这上面提了一下，其实自变量里面有很多的二级滞后项，这是剔除了一级滞后项以后得出的，原本很多其他的相关变量没有列进来了，所以这是最后模拟出来的结果。模拟出来这个方程以后，下一步是要设定的冲击场景。先要设计模型、估计模型，最后要把新的数据带到我们模型里面去。就是把先的自变量带到模型里面，让它变成新的应变量。那么，新的自变量怎么办呢？比如说我们的经济冲击发生以后，我们的影响是怎么样的。实际上，它和经济危机是差不多的，碰到了4个冲击点。一个是我刚才提到的4个自变量，它对于每个变量都有一个冲击，第一个是香港实际GDP的变化，还有一个是大陆实际GDP的变化，还有利率和房地产。它不是只对当期的自变量发生了变化，它实际上是延长了时间，把这个影响时间变成了2年。所以，在金融危机以后，这个应变量应该发生多大的变化。在97年的四季度利率是306个基点，后面两个季度下降了，第四个季度又上升了314个基点。可以看得出来，一开始是300多个基点，后面两个季度没有变化，第四个季度上升上来了，这跟当时的亚洲金融危机的冲击差不多。

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

通过算分布可以算出信用损失百分比的均值，还可以算出遭受损失的概率是多大，可以做这么一个精细的判断。这是计算以后的结果，它的均值是这样的，首先是基期没有发生信贷信用损失百分比，均值是0.34，压力期GDP冲击是1.59，房价冲击是1.21，利率冲击是0.71，大陆经济冲击是0.73。在VaR90%信用损失百分比是这个数据，随着置信区间的增加，损失的百分比也是递增的。最后一个是99.99%，这个时候已经是相当高了，后面两个已经接近10%，前面的已经超过10%了。

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

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

假设有一家银行，这家银行拨备前利润是30亿，贷款余额是1300亿港币。假设有一家银行规模是这么大，可以用上面的贷款损失百分比来测算，这家银行在发生了冲击以后，在不同的置信区间里面它的盈利能力会受到多大的影响，这是得出的结果。

单位用百万来表示，正的数据是表示盈利，负的就表示已经损失了，管理层看到这张表可能就比较清楚了银行可能发生多大的损失。

比如说在90%的区间里面，香港的GDP冲击情况下这家银行要亏损8.82万亿港币。那么，这个是99.99%，就是这个事情发生的概率非常强了，因为置信区间在99.99%，是0.001%的可能性，这个损失已经是到了133亿了。在不同的置信区间里面，它的损失是不一样的。回想一下，如果没有模拟，就是一个假设，假设GDP是多少，刚才已经提出来了，从前面可以看到，GDP的数据是多少，在每一个季度是多少，如果没有模拟，直接把这个数据带回到模型里面，只算出一个贷款百分比的数据。有了模拟以后，就知道它的均值是多少，在不同的置信区间里面是多少。这样，管理层可能会感觉清醒一点。比如说基期在没有违约的情况下，是2554百万，还是挺好的。如果做压力测试把这张表给管理层，就很清晰地知道损失有多大了。

最后有一个表述，在90%的置信水平下，VaR值是882万，如果在99%的水平下，VaR值是比较大的，导致这样的VaR的极端场景发生的概率是1%。

压力测试是指通过对系统加载过度的资源或者例系统没有应该具有的令系统可以正常运作的资源，来使系统崩溃（在某些情况的时候，它又可以叫做负面测试）。进行这个疯狂行为的主要目的是为了保证系统出 故障及可以适当的恢复，而这个恢复得怎么样的特性则是叫做可恢复性。 当性能测试需要的是一个可控制的环境和不断的测度的时候，压力测试则是令为欢喜的引起混乱及不可预测性（译者按：从这一点可以看出作者是一个很优秀的测试人员）。还是举WEB应用系统为例，下面是一些对系统可行的压力测试方法：两倍的已经基线的并发用户数或者HTTP连接数；随机的关闭及重开连接到服务器上的网络上集线器/路由器的端口（例如，可以通过SNMP命令来实现）；把数据库断线然后再重启；当系统还在运行的时候，重建一个RAID阵列；在WEB和数据库服务器上运行消耗资源（如CPU，内存，磁盘，网络）的进程。

负载压力测试有助于确认被测系统是否能够支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的，例如速度变慢、内存泄漏等问题的原因。负载压力测试是性能测试的重要组成部分，负载压力测试包括并发性能测试、疲劳强度测试、大数据量测试等内容。一般包括如下： 1、性能测试

性能测试用来保证产品发布后系统的性能能够满足用户需求。其中系统性能包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等。

2、性能评测

性能评测包括：在真实环境下，检查系统服务等级的满足情况，评估并报告整个系统的性能；对系统的未来容量作出预测和规划。

3、性能调优

性能调优一般的步骤为首先查找形成系统瓶颈或者故障的根本原因，其次是进行性能调整和优化，最后便是评估性能调整的结果。

4、负载测试

负载测试时通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试。

5、压力测试

压力测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能提供的最大服务级别的测试。

6、并发性测试

并发性测试的过程，是一个负载测试和压力测试的过程。即逐渐增加并发用户数负载，直到系统的瓶颈或者不能接收的性能点。并发性测试分为三类：

a、应用在客户端性能的测试；

b、应用在网络上性能的测试；

c、应用在服务器上性能的测试；

7、疲劳强度测试

8、大数据量测试 大数据量测试包括独立的数据量测试和综合数据量测试两类。