并发测试
并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在隐藏的并发问题，如内存泄漏、线程锁、资源争用问题。
特点：
•主要目的是发现系统中可能隐藏的并发访问时的问题
•主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。
•这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持
•也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。
场景测试
场景测试就是基于场景的软件测试。
什么是场景？
场景就是假设的故事，用来帮助人们理解一个复杂的问题或者系统。
一个完美的场景测试有几个特征：
- 基于一个用户怎么使用软件的故事，包括用户的动机
- 故事具有感染力，有影响力的干系人会促使这个场景测试失败的程序得到修复
- 故事要可信，不仅在真实的世界中可能发生，而且将很可能发生。
- 故事包含对软件的复杂的使用，或者复杂的环境或者一套复杂的数据
- 测试结果容易评估
为什么使用场景测试？
- 学习产品
- 将需求文档和测试联系起来
- 暴露产品却吸纳
- 探索程序的专业用法
- 将需求相关的问题引出到台面上
创建好场景的12个方法创建好场景的12个方法：
- 写出系统中对象的生命历程。
- 列出可能的用户，分析他们的兴趣和目标
- 考虑恶意用户，他们可能怎么攻击你的程序
- 列出系统事件，系统怎么处理这些事件？
- 列出特殊事件，系统怎么容纳这些事件？
- 列出收益并创建端到端的任务来检查他们。
- 与用户面谈，找出老系统中他们最不满意的地方。
- 与用户一起工作，观察他们怎么工作，做什么。
- 阅读类似的系统会做什么。
- 研究对这个系统以前版本和竞争对手的抱怨。
- 创建一个模拟业务，认真对待这个模拟业务并处理相关的数据。。
- 试着把竞争对手和以前版本的真实数据转换到新的系统。
场景测试的风险
- 在早期，不稳定的代码上，场景测试的效果不如其他方式，因为场景测试比较复杂，包含许多特性，一旦第一个特性出错，就会阻碍其他特性的测试。
- 场景测试不是为了全部覆盖整个程序。
- 场景测试经常发现的是设计问题，而不是代码问题，代码问题更适合由其他的测试来发现。
负载测试
通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
特点：
•主要目的是找到系统中所存在的性能问题
•需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力和典型场景、使得测试结果具有业务上的意义。
•一般用来了解系统的性能容量，或是配合性能调优来使用。
接口测试
接口测试是测试系统组件间接口的一种测试。
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
接口测试一般会用于多系统间交互开发，或者拥有多个子系统的应用系统开发的测试。接口测试适用于为其他系统提供服务的底层框架系统和中心服务系统，主要测试这些系统对外部提供的接口，验证其正确性和稳定性。接口测试同样适用于一个上层系统中的服务层接口，越往上层，其测试的难度越大。接口测试在淘宝的应用是一个自下而上的发展过程。
接口测试实施在多系统多平台的构架下，有着极为高效的成本收益比，接口测试天生为搞复杂性的平台带来高效的缺陷监测和质量监督能力。平台越复杂，系统越庞大，接口测试的效果越明显。
接口测试的目的是测试接口，尤其是那些与系统相关联的外部接口，测试的重点是要检查数据的交换，传递和控制管理过程，还包括处理的次数。外部接口测试一般是作为系统测试来看待的。
容量测试
通过性能测试，如果找到了系统的极限或苛刻的环境中系统的性能表现，在一定的程度上，就完成了负载测试和容量测试。
容量可以看作系统性能指标中一个特定环境下的一个特定性能指标，即设定的界限或极限值。
容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。
性能调优
指为软件提供较佳的性能，用于处理系统响应速度太慢等。
现象
一般观测性能问题的现象有：
• ? 系统响应速度太慢。
• ? 每秒所完成的系统输出/入低于预期。
• ? 相同的环境，但每秒钟所完成的批操作较先前少。
• ? 系统资源（如CPU、内存、硬盘或网络等）长时间处于耗尽的状态。
性能调优，首先是要确定性能调优的目标是什么，定义性能目标通常有这样几个指标：
1、最大并发数
2、Quality of Service 服务的质量，在软件系统方面我们认为主要表现在请求的出错率，系统的load等。
3、最长响应时间 对于任何请求所能承受的最大响应时间。
4、TPS 每秒需要支持的最大事务数，最典型的指标是：“某页面最高需要支撑每秒7000次的访问次数”。
例如一个web系统，需要定义出来的目标是：
并发目标：最高支撑200并发；
QoS：出错率须控制在万分之一，系统的load最高只能到达10；
TPS：每秒完成7000次请求的处理；
最大响应时间：最长允许的响应时间为5秒。
至于请求的平均响应时间这些就不在性能调优目标中定义，因为要达到TPS的要求，响应时间是必须要达到一个级别的，而且响应时间随着高并发是会出现劣化的。
也可以把性能指标定到更为细节，例如某个方法的TPS在100并发时需要达到多少。
尝试列出系统中各个组件合理的性能消耗，可以帮助你理清整个系统访问中，各个组件所占的性能消耗比例，哪些部分有可以调整的空间。另外，再搭配调整该部分的成本有多高，让你了解调整的优先级，并对系统的极限有更佳的认识。
可靠性测试（稳定性测试）
在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。
特点：
•这种性能测试方法的主要目的是验证是否支持长期稳定的运行。
•这种性能测试方法需要在压力下持续一段时间的运行。（2~3天）
•测试过程中需要关注系统的运行状况。
•也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。
压力测试（强度测试）
l模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间或超大负荷地运行测试软件，来测试被测系统的性能、可靠性、稳定性等。
特点：
•主要目的是检查系统处于压力性能下时，应用的表现。
•一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。
•一般用于测试系统的稳定性。
•让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。