首先澄清的第一个概念是什么是软件性能，作者分别从用户视角，管理员视角和开发人员的视角在这个问题域列出下面的问题，这些就是所谓的软件性能，而寻求答案的过程及其结论就是软件性能测试
1. 用户所体会到的系统响应时间是否够快?
2. 应用服务器的资源使用情况是否合理？
3. 数据库服务器的资源使用情况是否合理？
4. 系统能最多支持多少用户的访问？最大的业务处理量是多少?
5. 系统是否支持 7*24小时的业务访问？
6. 系统是否能够实现扩展？更换那些设备可以提高系统性能？
7. 系统的架构设计是否合理？
8. 数据库设计是否合理？
9. 代码是否存在性能问题？
10. 内存使用是否合理？
11. 线程同步是否合理？
12. 资源竞争是否合理？
13. 如果存在性能瓶颈，应该如何调整？
几个主要术语
1. 响应时间 : 响应时间分解为 网络传输时间， 应用延迟时间，数据库延迟时间，呈现时间。对响应时间的分解是为了方便定位性能瓶颈的所在。
2. 并发用户数 : 并发用户数首先要区别于同时在线用户数。在我们进行测试计划和测试目标的阶段通常会有明确的系统用户数和同时在线人数的参考依据，但并发用户数是不确定的。并发是针对某一个或某几个业务的行为，所以并发用户数取决于用户的行为即业务模式。所以确定用户的行为建立真实的模拟业务场景在性能测试中尤为重要。
3. 吞吐量 : 单位时间内系统处理的客户请求的数量。 通常以请求数/秒或者页面数/秒 衡量
软件性能测试方法论
1. SEI Load Testing Planning Process: 是一个关注于负载测试计划的方法，目标是产生 “清晰，易理解，可验证的负载测试计划”. 区别生产环境和测试环境的不同，分析用户的行为以产生用户和用户场景.
2. RBI (Rapid Bottleneck Identify) : 是 Empirix 公司提出的快速识别系统性能瓶颈的方法。首先确定是由并发还是吞吐量引发的性能瓶颈，通过不断增加并发用户数和吞吐量观察系统的性能表现，然后从网络，数据库，应用服务器和代码本身4个环节确定系统性能的瓶颈。
3. 性能下降曲线分析法: 分析随着用户数增长响应时间或吞吐量下降的曲线，通过定位性能拐点找到性能瓶颈产生的地方.
4. Load Runner 性能测试过程 : 计划测试-->测试设计-->创建VU脚本-->创建测试场景-->运行测试场景-->分析结果
5. Segue 性能测试过程: 从确定性能基线开始，通过单用户访问获取性能取值基线，然后设定可接受的性能目标，用不同的并发用户数进行 Try-Check的重复测试.
软件性能测试分类
1. 性能测试 : Performance Testing 这是一个容易混淆的概念，通常泛指所有的性能测试。本文特指在特定条件下验证性能是否达到预期指标的测试为性能测试。
2. 负载测试 : Load Testing 是指模拟真实的用户行为，通过不断加压直到性能出现瓶颈或资源达到饱和。负载测试是我们最经常进行的性能测试，用于测量系统的容量，发现系统瓶颈并配合性能调优。有时候也称为可量性测试 Scalability Testing.
3. 压力测试 : Stress Testing 是指测试系统在一定的饱和状态下系统的处理能力。负载测试的不断加压到一定阶段即是压力测试，两者没有明确的界限。压力测试通常设定到CPU使用率达到75%以上，内存使用率达到 70%以上，用于测试系统在压力环境下的稳定性。此处是指过载情况下的稳定性，略微不同于7*24长时间运行的稳定性。
4. 可靠性测试 : Reliability Testing 是指加载一定的业务压力，同时让此压力持续运行一段时间，测试系统是否可以稳定运行. 可以理解为压力测试关注的是过载压力，可靠性测试关注的是持续时间。
5. 并发测试 : Concurrency Testing 是模拟用户并发访问同一应用的测试，用于发现并发问题诸如内存泄漏，线程锁，资源争用，数据库死锁。
6. 配置测试 : Configuration Testing 验证各种配置对系统性能的影响，用于性能调优和规划能力.
7. 失效恢复测试 : Failover Testing 针对有冗余备份和负载均衡的系统，检验系统局部故障时用户所受到的影响
