可靠性测试：
可靠性测试一般选取系统日常处理的平均负载，其评估的性能指标通常是响应时间、错误率和系统资源占用率。为了更好地发现问题，一般可靠性测试的测试周期都比较长，比如压力测试执行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语句。
性能问题定位的一般策略
确定性能问题一般有自顶向下分析和自底向上分析法。
自顶向下分析：指将应用系统划分为若干部分，采用排除法或归谬法首先确定问题出现的位置，然后再这个部分寻求问题的原因和解决方案。自顶向下分析在确定问题属于哪一部分的时候，往往采取一种逐渐细分的方法，从比较粗的定位到非常细的功能模块划分，它分析重视文体产生的条件，即出现问题之前和出现问题之后的不同，通过对产生问题条件的归谬确定存在问题的部分。
自底向上分析方法注重问题的现象。通过考察性能问题现象的各种细节与以往出现问题的现象进行对比，确定性能问题的类型。自底向上分析方法往往直奔问题的日志或其他细节。
找到性能问题出现的原因，就可以确定问题的解决方案了。并不是所有的性能问题都需要修改程序代码解决，有些可以通过调优性能参数解决，有些则必须通过修改软硬件配置解决。
--->既然我们知道性能问题的定位比较困难，在设计测试计划和用例的时候，对于一些新的功能，如果想要验证它的性能，最好能让用例的设计相对独立一些。换句话说，就是避免多个可能引起性能问题的新功能之间互相影响。
常见问题一览
并发：引起并发问题的原因有很多，大多数是由多个并发线程抢夺资源引起的：
等待队列里的事务出现超时或回滚，从而导致访问出错
竞争锁资源时导致了死锁
超时：使用监视工具得到监视结果并分析实际使用的资源数是否小于系统设置的最大资源数并作相应提高。
死锁：出现在多个进程相互持有对方需要的锁而得不到自己所需要的锁的情况下：数据库死锁、进程死锁。数据库死锁一般会在应用进程的日志中抛出异常，进程死锁指线程之间相互占用所需资源而不释放导致的死锁。
性能下降主要是指在负载没有变化的情况下，系统的性能指标随时间而逐渐下降。
在性能测试中发现或重现性能下降问题主要是通过可靠性测试用例，即通过较长的执行时间发现各种性能指标的变化趋势。
应用服务性能下降问题由以下单个或多个原因混合导致：
应用程序资源使用问题，主要是内存使用问题：内存碎片、内存泄漏等
应用程序设计问题，主要存在可扩展性或可靠性问题
数据库访问问题
性能下降问题中做问题定位的一个重要手段是分段和比较。
性能参数调优是指通过调整配置参数改进应用系统性能的过程。性能参数调优的最低目标是避免由于不恰当的调优参数引起的性能问题。
性能参数调优的基本方法，就是通过反复的系统性能监测及分析，以配置参数调优为手段对系统资源进行合理的配置及调整，从而最大限度地提高系统性能，避免潜在性能问题的发生。
总结
性能测试的设计人员必须透彻理解产品的需求和设计，尤其是设计中关于性能目标的定义，之后设计出能够有效覆盖这些性能目标的性能测试计划。性能测试计划需要从产品的并发能力、响应时间、可扩展性、可靠性、安全性等多方面保证产品符合性能通过标准。
与其他测试不同，性能测试过程中不仅要看用例本身的执行情况，还要对测试系统和被测系统进行适当调优、实时监控，及时发现问题，合理收集所需要的监视日志，为后面的性能分析或问题定位做好准备。
