性能测试是为了保证产品发布后其性能能够满足用户的需求，本文结合具体案例介绍了应用系统性能测试的六大步骤。
在本文介绍的这个案例中，被测应用系统是一家公司的客户信息系统，它主要用来录入、修改以及查询全球客户的信息，并将客户信息转入到业务系统。但是，在应用过程中，客户经常投诉在某个时刻新建或者修改一个客户信息非常慢，正常情况下完成该操作只需要1～5秒，而异常时却需要10分钟左右，而且系统管理员发现系统资源使用率都比较低，这种情况的出现并没有规律性。
在这个案例中我们发现了系统存在性能问题，下一步工作就是要在性能测试过程中查找形成系统瓶颈和故障的根本原因，在此项工作中我们应该按照如下几个步骤进行。
目录
[隐藏]
* 1 确定明确的测试目标
* 2 测试需求分析
* 3 测试用例设计
* 4 脚本开发数据的准备以及测试执行与监控
* 5 测试分析
* 6 系统调优与验证
* 7 参考资料
o 7.1 相关条目
o 7.2 外部连接
确定明确的测试目标
性能调优是是无止境的，所以在测试之前应确定一个明确性能调优目标，这也是后面“评估性能验证”的一个基准，也是测试终止的一个基准。在本案例中目标设定为: 在相同系统环境配置下30个并发用户在1～5秒钟内完成各类在线操作。
测试需求分析
性能调优的测试分析主要目的是要挖掘出可能造成系统瓶颈的因素，并为后面的测试用例设计提供保证。影响系统性能有很多种原因，在此应关注如下几个关键点:
* 应用配置需求: 例如应用整体框架、涉及到哪些第三方的组件、应用层与数据库层的接口、使用了什么数据库等。
* 系统配置需求: 例如用户客户端配置、客户端与服务器端的网络配置、应用服务器或数据库服务器操作系统等。
* 用户使用情况需求: 例如用户分布情况; 哪些模块用户使用比较频繁; 在用户操作的数据有哪些特点等。
这方面工作是非常繁杂的，而且要求测试人员具有挖掘可能造成系统瓶颈因素的洞察力和敏锐感，但是很多测试人员在接手测试之后，很快进入到测试用例设计阶段。实践证明，这样做往往都适得其反，要么工期延期，要么项目开发失败。这个过程在测试整体过程中是非常关键的一环。性能测试分析有个特点: 它关注的是应用的整体，或者会仔细分析围绕着应用的各种外部因素，比如说它所涉及到的硬件、第三方软件，而不会深入到项目具体的内部。这是因为性能测试关注的是项目整体、是一种黑盒测试方法，我们关心一个项目的整体在运行时所暴露出来的问题。在此案例中我们获取到如表所示需求。
测试用例设计
此过程主要目的是设计出一些合理的场景去验证在需求分析阶段获得的可能影响性能的因素是否是造成系统瓶颈的因素。测试用例设计一般包括测试策略、测试案例、测试内容。
测试策略一般包括对比测试环境与真实的业务操作环境，真实业务操作环境又可能涉及局域网测试环境与机房测试环境等
测试案例主要是根据测试需求分析的结果制定出在测试执行时系统的执行方法，比如本案例中“5个人同时录入不同的新客户信息，以及具体的模拟步骤”。在测试案例设计时应注意如下几点:
* 虚拟用户的操作步骤要尽量类似于真实用户的操作。
* 操作的数据要类同于真实用户实际使用数据，例如在案例中用户录入客户信息时，根据需求得到的结果，我们可以设计有3～4个虚拟用户在录入一些小客户的信息，1～2个虚拟用户在录入大客户的信息等。
* 在案例设计时要充分考虑到需求中用户对模块的使用频率。使得在模拟时每个模块使用情况尽量地类似于真实环境。
测试内容一般包括并发性能测试、疲劳强度测试、大数据量测试以及系统资源监控等，我们在做性能调优测试时主要是做并发性能测试以及系统资源监控这些方面的工作。从对系统产生并发性能测试过程中监控系统中各种资源的变化，来判断导致性能瓶颈的原因。
脚本开发数据的准备以及测试执行与监控
测试执行与监控的主要目的是根据设计方案去验证系统是否存在瓶颈，给测试分析提供各种分析数据。此过程会与下面的“测试分析”过程不断进行重复执行，直至真正确定出系统瓶颈所在。
笔者认为，在此过程中如果有测试工具能够满足测试要求，那么应尽量使用测试工具，不要手工去开发测试程序，因为做企业项目往往时间紧张，而且测试工具毕竟是一个成熟的产品，在各方面都得到验证。使用工具将会缩短测试周期，而且现在市场上有很多成熟的测试软件。例如: Mercury的LoadRunner、IBM的Robot、Compuware的QALoad等。在这个案例中笔者使用的是Mercury的 LoadRunner。关于一些技术细节笔者就不再赘述了，在这里主要提两点。
一是数据的准备。数据准备一定要关注数据的质量和数量，不要出现一些不符合业务逻辑的废数据，并且数据量要满足测试运行的需要。例如测试需要100组数据，但是实际只准备了50组，从而导致测试执行结果出现大的偏差。
二是测试执行。除了正确按照设计的要求去设置各种参数之外，还要关注系统是否存在功能问题，这往往成为性能测试的“盲点”。原则上性能测试之前必须确保功能测试已经完备，但是任何事情都不绝对，所以一般做性能测试之初，都会模拟一个用户去运行设计的场景，主要是确保“测试脚本正确性”、“在设计的场景中应用系统不存在功能上的问题”。很多性能测试过程往往因为功能问题导致性能测试失败，或者是测试延期的现象。
本案例的测试执行结果如图所示。
测试分析
测试分析的主要目的是要根据测试执行获取到的数据去判断造成系统出现瓶颈的位置，挖掘造成系统瓶颈的真正原因。这个过程是技术含量最高的一环，因为在测试执行过程获取到的数据会涉及到各个方面，在这个案例中就涵盖了网络方面的知识、系统方面的知识、应用方面的知识等，测试人员需要从这些繁杂的数据中挑出异常，系统越大越复杂在这个方面对测试人员要求会更高。但是这里面也有一些技巧:
* 在做测试分析时人员组成建议为: 开发人员、系统人员、测试人员共同组成。这样会在技术上填补个人技术上的不足。实际每个项目涉及到的技术都可能各有不同，对于个人来说不可能每样都精通。
* 反复比较一个类型的参数在不同时间的跳跃值，或者不同场景下同一个类型参数的变化。
* 在发现参数有异常变化时，不要轻易下结论，而是要尽量挖掘可能影响这个参数的其他参数值。在长期的测试过程中发现往往发现第一个所谓的瓶颈都是因为其他因素造成的。
* 在测试分析时使用较多的一种方式是排除法，根据开始获取到的信息大概能将问题定位在某一层面上。但具体在什么地方，就可以采取排除的方法去定位。
* 尽量使用一些比较成熟的工具协助分析工作，这样将大大减轻工作负担。
* 在确定出真正的性能瓶颈时，可以做一些小的测试模型去做验证，确定分析的正确性。
在本案例中，在测试结果经过各种比对之后，最后确定是数据库层上出现问题。但是问题究竟出现什么地方呢？笔者在分析过程中采用了许多排除法，比如更新索引的统计值、将数据库中的表从页级锁改为行级锁等，但是都效果甚微。
所以，我们回到上面看与数据库层相关的需求:
* 因为业务需要，需要使用很多模糊查询。此类操作会进行表扫描。为了防止脏读，会向数据库申请表级意向锁。
* 因为客户关系复杂，所以数据库设计的时候，存在多表关联。
* 在应用开发时，我们使用了Hiberate这个组件，这些组件对于开发人员来说是一个黑盒，而且存在一些局限性: 在更新记录时会同步更新所有相关联的表，即使关联表不需要更新; 同步更新的记录操作会涵盖一个事物处理过程中，会产生大事务操作; 无法利用SQL优化技术去优化他所产生出来的SQL语句。
研究之后发现: 在进行模糊查询与大客户信息录入与修改的操作时，由hiberate这个组件产生的大事务SQL导致了数据库的互锁，是系统瓶颈所在。为了验证这一判断的正确性，笔者做了一个小的模型去验证。
假设库中有A、B、C三张表，现在有三个虚拟用户同时在上面进行操作: 用户Vuser1需要查询客户信息，他只知道客户的姓氏，所以他采取了模糊查询; 用户Vuser2正在修改一个客户信息，正准备保存; 用户Vuser3正在查询客户办公信息，也需要模糊查询。
Vuser1操作先得到执行，在表扫描中出现表级意向锁; 此时Vuser2进来需要修改A、B、C三张表对应记录，并成功的锁定了B、C两张表对应的行（因为是行级锁），然后进行了修改，但是无法修改表A，所以 Vuser2此时等待Vuser1释放锁; 此时Vuser3进来了，需要查询C表，因为Vuser2并没有释放锁，此时Vuser3也处在等待状态。验证显示，在出现大数量的操作并且在多用户的操作下，此瓶颈将不断地暴露出来。
系统调优与验证
将获取的分析数据交付到开发组进行调优，经过调优后一般都需要再次进行验证，验证主要关注调优后的结果是否解决了所发现的系统性能瓶颈和是否产生了新的性能瓶颈。这方面的工作主要由开发人员来完成。在本案例中，去掉了Hiberate组件，改为由应用自身控制，尽量减少了大事物的出现概率，并同业务部门商议，降低了模糊查询操作的次数。在后来再做“性能评测”时确认系统达到了预期目标。