话说20世纪90年代初的某一天，国内第一台自主研发的大型固话交换机，终于千呼万唤地“闪亮”登场了。于是乎，这家公司马上向用户大力推销这款设备，但是用户提出了一个很实际的问题，彻底难住了这家公司，问题很简单，就是需要一份性能测试报告来证明这台设备真能支持宜称的话务容量那时候还没有成熟的电信领域性能测试工具，该怎么办呢?幸好有聪明的领导想出了一个中国式的解决办法某天下午，全公司的员工都放下了手头的工作，每人怀抱一部老式电话机(还要靠转盘来拨号)，等领导倒数“三、二、一”后集体打电话。据说当时人数不够，达不到用户要求的通话量，甚至出现了一个人操作两部电话机的情况。
当今社会“云计算”绝对是当前最热的IT词汇，甚至沾上一点“云”概念的股票都会一飞冲天。“云”听起来很虚幻，其实就是瘦客户端加网格计算。今后客户端不再会有大量的计算任务，计算和存储都被放在云上。今后的客户端应该就是一个浏览器，用户的所有操作都是通过浏览器来实现的。 Google刚发布的操作系统 Chrome OS，就是基于这一理念设计的。B/S和C/S架构的软件系统，应该会慢慢演进到 Browser/Coud(浏览器/云)模式。如此看来，在“云计算”时代，Web性能测试依然很重要，而且会越来越重要。
二、什么是性能测试
性能测试是通过自动化的测试工具模拟多种正常峰值及异常负载条件来对系统的各项性能指标进行测试。性能测试的目的是验证被测系统能否达到用户提出的性能指标，同时发现被测系统的性能瓶颈，为性能优化指引方向，从而达到优化系统性能的目的。
性能测试包括以下几个方面：
■评估系统的能力：测试中得到的负荷和响应时长数据可以被用于验证所计划的模型的能力，并帮助做出决策。
■识别体系中的弱点：受控的负荷可以被增加到一个极端的水平并突破它，从而修复体系的瓶颈或薄弱的地方
■系统调优：重复运行测试，验证调整系统的活动是否得到了预期的结果，从而改进性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中隐含的问题或冲突。
■验证稳定性( Resilience)、可靠性( Reliability)：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。
三、性能测试的使用场景
性能关注的是软件的非功能特性，所以一般来说性能测试介入的时机是在功能测试完成之后。性能测试是通过压力实现的。负载测试通过协议仿真，对服务器进行冲击。C/S程序使用Socket连接，会有私有协议在内，不好模拟。B/S是严格的Http协议，比较容易仿真。
性能测试应用场景（领域）主要有：能力验证、规划能力、性能调优、缺陷发现、性能基准比较，下表简单介绍和对比了这几个场景的各自用途和特点：
四、性能测试分类
性能测试包括负载测试、压力测试、容量测试、并发测试、疲劳测试、疲劳强度测试、配置测试、可靠性测试等。
负载测试( Load Testing)：
负载测试是指对系统不断地增加压力或增加一定压力下的持续时间，直到系统的某项或多项性能指标达到安全临界值，通过测试系统在资源超负荷情况下的表现，来发现设计上的错误或验证系统的负载能力。在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出预期工作量的情况下仍能正常运行。此外，负载测试还要评估性能特征，如响应时长、事务处理速率和其他与时间相关的性能指标。
压力测试( Stress Testing)：
在软件工程中，压力测试是对系统不断施加压力，评估系统处于或超过预期负载时系统的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。
容量测试( Volume Testing)：
容量测试确定系统可处理同时在线的最大用户数。
疲劳测试（稳定性测试）：
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。微软提出的经验值3*24（一般只针对电商、交通、物流等行业的软件），主要还是测试软件的稳定性和持久性。
疲劳强度测试：
（往“死”里测）
并发测试：
测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题
负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是当负载逐渐增加时，测试系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能供的最大服务级别的测试。
注意：性能测试之前要做好被测系统的备份
五、性能测试指标
1） 响应时间：response time
响应时间就是用户感受软件系统为其服务所耗费的时间。
对于网站系统来说，响应时间就是从点击了一个页面计时开始，到这个页面完全在浏览器里面展现计时结束的这一段时间间隔。
网站响应时间有一个原则：<2-5-8原则>
2-5s之内，响应还可以；
5-8s之内，响应较慢，但还可以接受；
8s以上，响应特别慢。
响应时间对于网站系统来说，是最重要的性能指标。
2） 吞流量（throughput）
指的是在单位时间内客户端和服务器成功传送数据的体量。
比如下载请求、下载的文件。如果吞吐量大，说明下载就快，吞吐量小，说明下载就慢。
网络上，吞度量就是带宽：带宽越大，吞吐量越大。
3） 资源使用率（resource utilization）
常见的资源有（服务器）：CPU占用率、内存使用率、磁盘I/O、网络I/O
比如：1000个用户，同时在线使用服务器服务器的CPU占用率如何？如果占用率不到50%说明性能很好
4） 每秒点击数：（hits per second）
指客户端每秒向服务器提交的请求的数量，如果客户端发出的请求数量越多，与之相对的吞吐量也应该越大。
报文：请求报文到响应报文的过程： 登陆的请求报文——>解析报文——>处理报文——>登陆响应报文
5） 并发用户数（concurrent users）
指的是在客户端的一批用户同时执行一个操作的数量。系统用户数 >= 在线用户数 >= 并发用户数。
并发数（并发用户数）反应了软件、系统的并发处理能力。
单线程、单进程 处理能力较差
多线程、多进程 处理能力较好
loadrunner选用的性能指标：
对于B/S架构的软件，一般会关注如下Web服务器性能指标：
■ Avg Rps：平均每秒钟的响应次数=总请求次数秒数Avg time to last byte per terstion( mates)：平均每秒业务脚本的选代次数。
■ Successful Rounds：成功的请求。
■ Failed Rounds：失败的请求。
■ Successful Hits：成功的点击次数
■ Failed Hits：失败的点击次数。
■ Hits Per Second：每秒点击次数。
■ Successful Hits Per Second：每秒成功的点击次数
■ Failed Hits Per Second：每秒失败的点击次数。
■ Attempted Connections：尝试连接数。
■ Throughput：吞吐率
对于C/S架构的程序，由于软件后台通常为数据库，所以我们更注重数据库的测试指标：
■ User Connections：用户连接数，也就是数据库的连接数量；
■ Number of Deadlocks：数据库死锁；
■ Butter Cache Hit：数据库 Cache的命中情况。
六、测试指标折算
测试环境平均并发数=(最大在线人数x10%)n
上式中，n是生产环境和测试环境服务器配置折算比，例如： n=公倍数 ( (生产Web服务器数 / 测试web服务器数),(生产APP服务器数 / 测试APP服务器数) ) × (生产服务器内存 / 测试服务器内存)，一般算下来n=4。
规律：一般20个虚拟用户的的并发，相当于200个用户的在线压力（1:10的比例），指定测试计划时可以根据此点作为参考。
七、测试结果分析
毫无疑问，分析性能测试结果非常重要，而且很有难度。可以这么说，会执行性能测试案例的人是“徒弟”，能够准确全面分析性能测试结果的人是“师父”。如何分析性能测试结果，后面再深入探讨……
八、生成性能测试报告
如何生成一份准确严谨的性能测试报告，是一项技巧性的工作。读者朋友只要遵循一定原则，并掌握一些文字技巧就不难办到。一份性能测试报告，至少应该包含如下内容：
■测试基本信息：包含测试目的、报告目标读者、术语定义、参考资料。
■测试环境描述：包含服务器软/硬件环境、网络环境、测试工具、测试人员。
■性能测试案例执行分析：需要详细描述钢个测试案例的执行情况，以及对应的测试结果分析。
■测试结果综合分析及建议：对本次性能测试做综合分析，并给出测试结论和改进建议
■测试经验总结。
九、解决性能瓶颈
找出问题后，需要各方面 （包括开发人员、 DBA、网络以及其他系统专家）的共同努力来解决瓶颈问题。调整后，再次运行负载测试来确认所做的调整是否达到了预期效果。重复此循环以优化系统性能。
资源调优：主要针对的是服务器，也可以针对数据库和程序代码调优（能用集合实现就不用数组实现，能用继承就不用重复代码）、服务器配置的调优（需要进行配置的挑选）。（下载时网速慢的原因可能是由于：服务器受攻击、服务器限速等等）
