《LoadRunner 没有告诉你的》之五——无所不在的性能测试 (已完稿)

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

本文是《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掉 ^_^

 

 

性能测试，并不是网络应用专属

软件的性能和性能测试都是伴随着网络应用的兴起而逐渐被重视起来的，可是软件性能和性能测试却并不是网络应用的专属名词，由于单机版的应用一样须要考虑性能问题。下面举几个简单的例子来方便你们的理解：

1.               当使用Word来编辑一个500多页，并包含了丰富图表、图片和各类格式、样式信息的文档时，是否每次对大段的文字或表格的修改、删除或从新排版，都要等待系统花几秒钟的时间进行处理？

2.              当在Excel中使用嵌套的统计和数学函数对几万行记录进行统计分析时，是否每次都要两三分钟才能看到结果？

3.              杀毒软件是否每次都要花费两个小时才能完成一次对全部的分区的扫描？

4.              是否每次在手机的通信簿中根据姓名搜索某我的的联系方式都要三四秒钟才有响应？

若是你们有兴趣，也能够经过Google搜索到更多的有关单机应用性能测试的资料。