《LoadRunner 没有告诉你的》之五——无所不在的性能测试-CSDN博客

提到性能测试，相信大家可以在网上找到很多种不同的定义、解释以及分类方法。不过归根结底，在大多数情况下，我们所要做的性能测试的目的是“观察系统在一个给定的环境和场景中的性能表现是否与预期目标一致，评判系统是否存在性能缺陷，并根据测试结果识别性能瓶颈，改善系统性能”。

本文是《LoadRunner没有告诉你的》系列的第五篇，在这篇文章中，我希望可以跟大家一起来探讨“如何将性能测试应用到软件开发过程的各个阶段中，如何通过尽早的开展性能测试来规避因为性能缺陷导致的损失”。

因此，本文的结构也将依据软件开发过程的不同阶段来组织。

另外，建议您在阅读本文前先阅读本系列文章的第三篇《理发店模型》和第四篇《理解性能》。

需求阶段

我们不可能将一辆设计载重为0.75吨的皮卡改装成载重15吨的大型卡车，如果你面对的正是这样的问题，那么恐怕你只能重做一辆，而且客户不会为你之前那辆付钱。对于一个已经完成的应用系统来说也是如此。

如果我们在系统结构确定之前就能够了解到系统的将要面对的压力，用户的使用习惯和使用频度，我们就可以更早也更有效的提前解决或预防可能发生的性能缺陷，也将会极大的减少后期返工和反复调优所带来的工作量。如果我们预期到系统的容量将会不断的增长，我们还可以给出相应的解决方案来低成本的解决这类问题，就像上面那辆皮卡，也许你可以有办法把20辆皮卡捆在一起，或者把15吨的东西分由20辆来运。

分析设计阶段

系统性能的优化并不是要等待整个系统全部集成后才能开始的，早在分析设计阶段，我们就可以开始考虑系统的技术架构和数据库部分的优化。

数据库通常位于整个系统的最底层，如果直到系统上线前才发现因为数据库设计不合理而导致性能极差，通常使用任何一种方法来优化都已经于事无补了。要避免这类问题，最常见的做法是在数据库结构确定后，通过工具或脚本向数据库中注入大量的数据，并模拟各种业务的数据库操作。根据对数据库性能的观察和分析，对数据库表结构和索引进行调整以优化数据库性能。

在系统的技术架构方面，要明白先进的技术并不是解决问题的唯一方法，过于强调技术的作用反而会将你带入歧途。例如：某些业务虽然经常面临着巨大的压力，并且业务本身的复杂性决定了通过算法的优化来提高系统的性能收效甚微。但是我们知道用户对于该业务的实时性要求并不高，并且返回结果对于不同用户来说是相同的。那么我们完全可以考虑将每次请求都动态生成返回结果的方式改为每次用户请求都返回一个定期更新的静态页面。

另外，所谓“先进技术”通常都会在带来某一方面改进的同时带来另一方面的问题，未经试验就盲目的在系统中加入各种流行元素未必是最好的选择。例如ORM可以提供一些方便，但是它生成的SQL是未经优化的，有时甚至比人工编写的SQL效率更低。

最后，要知道不同厂家的设备性能是不同的，而且不同的硬件设备搭载不同的操作系统、数据库、中间件以及应用服务器，表现出来的性能也是不同的。如果有足够的资源，应当考虑提前进行软硬件平台的对比选型；如果没有足够的资源，可以考虑通过一些专业的组织或网站来获取或购买相关的评估报告。

编码阶段

一片树叶在哪里最难被发现？——当这片树叶落在一堆树叶里面的时候。

如果你只是在系统测试完成后才开始性能测试，那么即使发现系统存在性能缺陷，并且已经有了几个可供怀疑的对象，但是当一段因为使用了不当的算法而导致执行效率很低的代码藏身于一个庞大的系统中时，找出它是非常困难的。避免这种情况出现的方法是尽早开始核心业务代码的性能测试，重点集中在对算法和实现方法的优化上。

另外，及早开始的测试也可以帮你更容易找到内存泄漏的问题。

测试阶段

产品终于交到我们手上了，搭建测试环境，设计测试场景，执行测试，找到系统的最佳并发用户数和最大并发用户数，将系统进行分类，评判系统的性能表现是否满足需求中定义的目标——如果有需求的话 ^_^

如果发现系统的性能表现与预期目标相去甚远，则需要根据执行测试过程中收集到的数据来分析和识别性能瓶颈，优化系统性能。

在这个阶段还有很多值得我们深入思考和讨论的东西，在本系列后续的文章中，我们将会更多的关注这一部分的内容。

维护阶段

维护阶段通常遇到的问题是需要在实验室中模拟客户环境，重现在客户那里发现的缺陷并修复缺陷。相比功能缺陷，性能缺陷与某一具体环境和场景的关联更加密切，所以在测试前需要检查生产环境中各服务器的资源利用率、系统访问日志、应用服务器的日志、数据库的日志。如果客户使用了专门的系统来监测各个服务器的软硬件资源使用情况的话，检查该系统是否记录下了软硬件资源的异常或者警告。

与性能测试相关的其他测试

可靠性测试（Reliability Testing）对于一个运营商级的系统来说，能够保证提供7×24的连续稳定的服务是非常重要的。当然，你可以通过一些“高可用性（High Availability）”技术方案来增强系统的可靠性，但是对于系统本身的可靠性测试是不能被忽略的。

常用的测试方法是使用一定的负载长时间向服务器加压，并观察随着加压时间的延长，响应时间、吞吐量以及资源利用率的变化。要注意的是，所使用的负载应当是系统的最佳并并发用户数，而不是最大并发用户数。

可伸缩性测试（Scalability Testing）对于一个系统来说，在一个给定的环境下，它的最佳并发用户数和最大并发用户数是客观存在的，但是系统所面临的压力却有可能随上线时间的延长而增大。例如，一个在线购物站点，注册用户数量不断增多，访问站点查询商品信息和购买商品的人也不断的增多，我们应该用一种什么样的方案，在不影响系统继续为用户提供服务的前提下来实现系统的扩容？

一种常用的方案是使用负载均衡（Load Balance）和集群（Cluster）技术。但是在我们为客户提供这种方案之前，需要先自己进行测试，保证该技术的有效性——我们是否真的可以通过简单的增加服务器数据和修改某些参数配置，就能够使得系统的容量得到线性的增长？

可恢复性测试（Recoverability Testing）虽然我们已经可以准确的估算出系统上线后将要面对的压力，并且可以保证系统的最佳并发用户数和最大并发用户数是足以应对这些压力的，但是这个世界上总是有些事情上我们所无法预料到的——例如9.11事件发生后，AOL的网站访问量在短时间内增长到了平时的数十倍。

我们无法保证系统可以在任何情况下都能为用户正确无误的提供服务，但是我们需要确保当意外过去后，系统可以恢复到正常的状态，并继续后来的用户提供服务——就像从未发生过任何事情一样。

如果要实现“可恢复性测试”，我们可以借助于测试工具或脚本来逐渐的增大并发用户数，直至并发用户数已经超过了系统所能承受的最大并发用户数，并导致软硬件资源利用率饱和，响应时间无限延长，大量的请求因为超过响应时间要求或无法获得响应而失败；之后，我们逐渐的减少并发用户数，并观察资源利用率、响应时间、吞吐量以及交易成功率的变化是否与预期目标一致。

当然，这一切的前提是在系统负载达到峰值前，Server一直在顽强的挣扎着而没有down掉 ^_^