性能测试是产品测试流程的必经之路，产品性能的好坏不但关系到产品的用户体验，对于像电子商务这一的应用来说，性能的好坏直接关系到客户的网站是否有好的用户忠诚度，从而也就影响到订单转化率等跟客户盈利直接相关的指标。
客户与用户
客户指的是购买我们产品的企业，他们购买了产品之后，经过定制上线，展示给最终的用户来使用。因此客户非常关心用户的使用感受，因为这直接决定他们的网站或者终端是不是受欢迎，能不能留住用户。
对于一个应用服务的性能来说，客户的关注点：
页面/客户端的响应时间： 直接影响最终用户的使用体验，在很大程度上影响用户忠诚度
服务器的吞吐量：系统每小时处理的业务量
最大并发用户数：在响应时间合理的情况下，能够承受的并发用户数
是否能稳定的长期运行，最大数据规模等。
如何理解性能测试？
简单的说，就是给系统一些压力，看系统跑得快不快，好不好。说得文一些，就是让系统工作在一定的负载状态下，把系统工作的性能指标与期望的性能指标相比较。
性能测试策略和方法的出发点，就是要模拟客户对系统的访问行为，包括并发、压力、长时间的访问等。
性能测试的分类：
客户端性能测试：关注用户体验，即访问应用程序时的响应时间。
服务器端性能测试：注重在不同负载条件下的应用程序的健壮性。
性能测试的类型：
压力测试：
限时抢购，是一种短时间内把系统负载压到极限的例子，测试时，一般通过压力测试来模拟。
压力测试主要考察让系统运行在比较大的负载条件下的性能表现。可以发现系统工作在多任务并发情况下可能出现的性能问题。由于压力测试下系统工作在非常高的负载情况下，所以衡量性能运行指标一般为吞吐率和错误率，而不包括响应时间。
压力测试的目的：
发现并解决在并发、长时间运行或者大量数据情况下才出现的系统缺陷，如数据库死锁，代码级死锁，内存泄漏等。
在指定并发用户数下是否能达到吞吐率目标。
从上述两个方面可以得知，压力测试按照目的的不同可以分成两类：
系统的性能瓶颈：通过标准是系统在CPU运算能力饱和状态下（CPU占有率大于95%）的吞吐率和错误率。
系统的崩溃点：不关心具体的吞吐率和错误率指标，关注考察吞吐率、错误率指标与负载关系曲线。
--->什么是吞吐率？
通常吞吐率是指应用系统在单位时间内实际处理的交易数量（交易吞吐率）或页面点击数量（页面点击吞吐率）。
压力测试通过的标准：
在承受指定负载的前提下，系统的吞吐率是否达标、并发用户数是否达标、出错率是否达标。
吞吐率测试往往可以用于产品新旧版本之间的比较试验。比如，在新版本增加某个新功能之后，你想验证新功能的引入会不会对性能产生负面的影响，就可以通过在相同的硬件条件下做吞吐率的比较试验来确认。
响应时间测试：
响应时间测试是另一个常见的衡量系统快慢的运行指标。一般来说，响应时间越短越好。
响应时间测试测的是在正常负载状态下，被测系统的服务器端和客户端响应时间（不考虑外部网络传输影响）。即，响应时间的测试结果更接近通常状态下系统真实性能表现。
响应时间测试的目的：正常负载（CPU使用率50%左右）前提下，保证服务器或者客户端的操作响应时间不超过规定的标准。
--->网页响应时间的组成：在网络上传输数据、在服务器端处理、服务器将响应数据传回到客户端、在浏览器中显示。
在网络上数据传输的时间取决于页面数据量的大小、网络速度和网络上的拥挤程度。
在浏览器中显示的时间取决于客户端程序(JavaScript, Dojo,Flash等)的复杂程度以及运行浏览器的客户计算机的处理速度。
可靠性测试：
可靠性测试一般选取系统日常处理的平均负载，其评估的性能指标通常是响应时间、错误率和系统资源占用率。为了更好地发现问题，一般可靠性测试的测试周期都比较长，比如压力测试执行3小时，对应可靠性测试可能需要执行72小时甚至更长时间。
可靠性测试的目的：
评估长时间的性能指标是否满足要求，往往考察平均值。
考察性能指标的变化趋势，发现可能存在的内存泄漏、性能下降等于执行时间相关的性能问题。
考察某些维护性操作是否会对前台用户访问的性能造成大的影响。
可扩展性测试：
可扩展性测试(Scalability Test)是验证被测试系统随着计算能力的扩展是否能够承受更大的负载。负载的增大包括数据规模、业务种类、数据复杂度等。
可扩展性测试的目的：
针对系统在某一个负载方向上的可扩展性，通过一组测试评估系统在不同负载下的性能情况，从而分析系统在此负载变化方向上的可扩展性。
在不同的负载下衡量系统响应时间或吞吐率的变化趋势。
--->任何性能指标的好坏，除了与软件本身的并发性能好坏有关，还在很大程度上取决于硬件系统的处理能力。
性能测试流程
编写性能测试计划--设计与实现测试用例--执行测试--性能问题确定与调优--编写测试报告
制定性能测试计划：
内容：
开始的必要条件，即开发人员、其他类型测试人员为了保证性能测试顺利进行而必须做的工作。
退出条件，定义什么时候性能测试结束，通常与产品的质量控制标准有关。
目标与范围，目标往往直接来自于用户需求规格说明书中的非功能性需求描述。
测试用例，包括测试场景的描述、输入/输出描述。
--->性能需求的来源:
性能需求根本上应该来自实际用户的需求，对于有明确性能指标定义的描述都应该在测试计划中制定相应的测试用例，量化的性能指标应该成为制定测试用例通过标准的依据。
以前版本的用户缺陷报告
行业的质量标准
由于硬件/软件版本升级带来的性能提升测试需求
--->一个完整的测试用例描述如下：
测试场景，描述待测系统处理的业务内容，或者说测试用户所执行的业务操作<---->系统交互的角色/角色所执行的业务流程。
测试负载和通过标准，并发用户数、思考时间、测试持续时间等。通过标准包括吞吐率、页面响应时间、资源占用率通过标准。
测试数据规模，测试数据的设计应该从实际用户的需求出发。
待测系统软/硬件配置和拓扑结构，测试计划中应明确描述操作系统版本在内的所有测试相关软件版本信息、硬件平台和详细配置信息及系统的拓扑结构。
性能测试一般不会涵盖系统所支持的所有可能的功能场景，设计测试用例的原则之一就是用尽可能小的测试场景覆盖尽可能多的测试目标。
测试用例设计不合理有可能导致测试结果的无效性，进而引起测试返工甚至有可能发现不了系统性能缺陷。
执行测试：
执行测试从测试用例的实现开始，包括测试脚本和测试数据集的开发、测试执行、测试过程中的系统监视、收集测试结果、分析测试等。
性能测试的特点决定了性能测试的执行与其他类型测试相比要复杂得多。性能测试执行过程中至少要监视待测系统各方面的运行状况，所以性能监视技术是性能测试人员必备的技能。
一个明确的测试执行清单有助于测试执行过程的规范化，且测试执行清单应该像测试脚本和数据一样被实时和定期维护。
与功能测试不同，性能测试结果如果不满足通过标准不一定是应用系统本身的缺陷，因此，执行测试用例得到的结果需要进行分析。
执行测试的步骤：
1. 熟悉测试计划与测试用例：由于性能测试的复杂性，反复阅读测试计划中队测试方法和测试用例直至彻底理解是开始执行测试的前提。
2. 搭建或检验测试客户端：性能测试的运行通常需要依赖于一定的自动化测试工具或框架，测试工具通常运行在测试客户端的计算机上，并检验客户端的相关配置是否满足要求。
3. 搭建或检验测试服务器环境：待测系统的软/硬件配置及正常工作状态时得到有效测试结果的前提。
4. 设置调优参数：不要因为片面追求调优带来的好的性能而掩盖了应用程序代码本身的性能问题，因此，参数调优应该只作为一种必要的辅助手段。
5. 编写或校验测试脚本和数据：测试脚本的执行需要配合测试所需要的数据。
6. 预热执行及逐步增加并发用户负载：预热执行还可以弥补自动测试数据生成工具的不足。对于大并发用户数下的压力测试一般不采用将大量并发用户同时开始的方法，而是采用从少到多逐步增加的方式。
7. 配置监视工具：在测试执行清单中应该对各种类型的测试需要对监视工具做何种配置有明确规定。
8. 执行测试：定期通过监视工具检查服务器和测试客户端的运行状态，同时注意监视工具的开销。
9. 收集、分析测试结果并整理测试报告：不论测试是否通过，都应该按照测试执行清单的要求收集各种结果信息。收集测试失败的日志反而对于分析解决问题至关重要。
--->测试系统的性能监视一般有性能测试人员或开发人员进行。测试系统的系统运行时间短而压力大。
--->生产系统的性能监视一般由系统维护人员进行。系统长时间运行，出现性能问题的可能性较小，但一旦出问题，产生的影响大。
以上两种系统上进行性能监视的目的都是为了尽早地发现性能问题。
性能监视一般采取从前到后的监视顺序。监视系统的性能运行指标，在测试环境中一般通过测试工具进行。找到问题出现的时间点往往很重要，因为系统日志很多时候是先从引起问题的根源处开始记录出错的。
一般来说，基于应用服务器的系统一般需要做以下几个级别的监视：操作系统级别，数据库级别，应用服务器级别
操作系统的监视
监视各种系统资源的使用状况：CPU占用情况，内存占用情况，I/O使用情况
--->当系统性能出现瓶颈时，查看系统的I/O情况也是确定问题的重要手段。
数据库的监视
使用DB2快照监视其时，一个典型的过程如下：
a. 首先查看数据库监视对象开关状态
db2 GET MONITOR SWITCHES
b. 查看数据库管理系统监视对象开关状态的命令
db2 GET DBM MONITOR SWITCHES
c. 打开指定的数据库监视对象开关的命令
db2 Update MONITOR SWITCHES USING switch-name ON/OFF
可以一次打开一个或多个开关
db2 Update MONITOR SWITCHES USING LOCK ON BUFFERPOOL ON
d. 再执行
db2 GET MONITOR SWITCHES
此时，会发现缓冲池监视开关和锁的监视已经打开了
e. 执行命令
db2 GET SNAPSHOT
---> 数据库上发生死锁是并发访问时很常见的问题，尤其是压力测试用例这种比较极端的用例。因此监视死锁也是对数据库监视很重要的一部分。
有时候没有出现死锁问题，而仅仅是怀疑某些操作使用的SQL语句不合理，因此可以监视特定操作使用的SQL语句。
性能问题定位的一般策略
确定性能问题一般有自顶向下分析和自底向上分析法。
自顶向下分析：指将应用系统划分为若干部分，采用排除法或归谬法首先确定问题出现的位置，然后再这个部分寻求问题的原因和解决方案。自顶向下分析在确定问题属于哪一部分的时候，往往采取一种逐渐细分的方法，从比较粗的定位到非常细的功能模块划分，它分析重视文体产生的条件，即出现问题之前和出现问题之后的不同，通过对产生问题条件的归谬确定存在问题的部分。
自底向上分析方法注重问题的现象。通过考察性能问题现象的各种细节与以往出现问题的现象进行对比，确定性能问题的类型。自底向上分析方法往往直奔问题的日志或其他细节。
找到性能问题出现的原因，就可以确定问题的解决方案了。并不是所有的性能问题都需要修改程序代码解决，有些可以通过调优性能参数解决，有些则必须通过修改软硬件配置解决。
--->既然我们知道性能问题的定位比较困难，在设计测试计划和用例的时候，对于一些新的功能，如果想要验证它的性能，最好能让用例的设计相对独立一些。换句话说，就是避免多个可能引起性能问题的新功能之间互相影响。
常见问题一览
并发：引起并发问题的原因有很多，大多数是由多个并发线程抢夺资源引起的：
等待队列里的事务出现超时或回滚，从而导致访问出错
竞争锁资源时导致了死锁
超时：使用监视工具得到监视结果并分析实际使用的资源数是否小于系统设置的最大资源数并作相应提高。
死锁：出现在多个进程相互持有对方需要的锁而得不到自己所需要的锁的情况下：数据库死锁、进程死锁。数据库死锁一般会在应用进程的日志中抛出异常，进程死锁指线程之间相互占用所需资源而不释放导致的死锁。
性能下降主要是指在负载没有变化的情况下，系统的性能指标随时间而逐渐下降。
在性能测试中发现或重现性能下降问题主要是通过可靠性测试用例，即通过较长的执行时间发现各种性能指标的变化趋势。
应用服务性能下降问题由以下单个或多个原因混合导致：
应用程序资源使用问题，主要是内存使用问题：内存碎片、内存泄漏等
应用程序设计问题，主要存在可扩展性或可靠性问题
数据库访问问题
性能下降问题中做问题定位的一个重要手段是分段和比较。
性能参数调优是指通过调整配置参数改进应用系统性能的过程。性能参数调优的最低目标是避免由于不恰当的调优参数引起的性能问题。
性能参数调优的基本方法，就是通过反复的系统性能监测及分析，以配置参数调优为手段对系统资源进行合理的配置及调整，从而最大限度地提高系统性能，避免潜在性能问题的发生。
总结
性能测试的设计人员必须透彻理解产品的需求和设计，尤其是设计中关于性能目标的定义，之后设计出能够有效覆盖这些性能目标的性能测试计划。性能测试计划需要从产品的并发能力、响应时间、可扩展性、可靠性、安全性等多方面保证产品符合性能通过标准。
与其他测试不同，性能测试过程中不仅要看用例本身的执行情况，还要对测试系统和被测系统进行适当调优、实时监控，及时发现问题，合理收集所需要的监视日志，为后面的性能分析或问题定位做好准备。