对于一个应用服务的性能来说，客户的关注点：
页面/客户端的响应时间：直接影响最终用户的使用体验，在很大程度上影响用户忠诚度
服务器的吞吐量：系统每小时处理的业务量
最大并发用户数：在响应时间合理的情况下，能够承受的并发用户数
是否能稳定的长期运行，最大数据规模等。
如何理解性能测试？
让系统工作在一定的负载状态下，把系统工作的性能指标与期望的性能指标相比较。
主要关注的两方面性能指标：
功能业务指标：响应时间（RT）、并发数、业务成功率、吞吐量（QPS/TPS）等等。
硬件资源指标：内存、CPU、Nerwork I/O等资源消耗情况。
性能测试策略和方法的出发点，就是要模拟客户对系统的访问行为，包括并发、压力、长时间的访问等。
性能测试的分类：
客户端性能测试：关注用户体验，即访问应用程序时的响应时间。
服务器端性能测试：注重在不同负载条件下的应用程序的健壮性。
性能测试的类型：
压力测试：
限时抢购，是一种短时间内把系统负载压到极限的例子，测试时，一般通过压力测试来模拟。
压力测试主要考察让系统运行在比较大的负载条件下的性能表现。可以发现系统工作在多任务并发情况下可能出现的性能问题。由于压力测试下系统工作在非常高的负载情况下，所以衡量性能运行指标一般为吞吐率和错误率，而不包括响应时间。
压力测试的目的：
发现并解决在并发、长时间运行或者大量数据情况下才出现的系统缺陷，如数据库死锁，代码级死锁，内存泄漏等。
在指定并发用户数下是否能达到吞吐率目标。
从上述两个方面可以得知，压力测试按照目的的不同可以分成两类：
系统的性能瓶颈：通过标准是系统在CPU运算能力饱和状态下（CPU占有率大于95%）的吞吐率和错误率。
系统的崩溃点：不关心具体的吞吐率和错误率指标，关注考察吞吐率、错误率指标与负载关系曲线。
--->什么是吞吐率？
通常吞吐率是指应用系统在单位时间内实际处理的交易数量（交易吞吐率）或页面点击数量（页面点击吞吐率）。
压力测试通过的标准：
在承受指定负载的前提下，系统的吞吐率是否达标、并发用户数是否达标、出错率是否达标。
吞吐率测试往往可以用于产品新旧版本之间的比较试验。比如，在新版本增加某个新功能之后，你想验证新功能的引入会不会对性能产生负面的影响，就可以通过在相同的硬件条件下做吞吐率的比较试验来确认。
响应时间测试：
响应时间测试是另一个常见的衡量系统快慢的运行指标。一般来说，响应时间越短越好。
响应时间测试测的是在正常负载状态下，被测系统的服务器端和客户端响应时间（不考虑外部网络传输影响）。即，响应时间的测试结果更接近通常状态下系统真实性能表现。
响应时间测试的目的：正常负载（CPU使用率50%左右）前提下，保证服务器或者客户端的操作响应时间不超过规定的标准。
--->网页响应时间的组成：在网络上传输数据、在服务器端处理、服务器将响应数据传回到客户端、在浏览器中显示。
在网络上数据传输的时间取决于页面数据量的大小、网络速度和网络上的拥挤程度。
在浏览器中显示的时间取决于客户端程序(JavaScript,Dojo,Flash等)的复杂程度以及运行浏览器的客户计算机的处理速度。
可靠性测试：
可靠性测试一般选取系统日常处理的平均负载，其评估的性能指标通常是响应时间、错误率和系统资源占用率。为了更好地发现问题，一般可靠性测试的测试周期都比较长，比如压力测试执行3小时，对应可靠性测试可能需要执行72小时甚至更长时间。
可靠性测试的目的：
评估长时间的性能指标是否满足要求，往往考察平均值。
考察性能指标的变化趋势，发现可能存在的内存泄漏、性能下降等于执行时间相关的性能问题。
考察某些维护性操作是否会对前台用户访问的性能造成大的影响。
可扩展性测试：
可扩展性测试(Scalability Test)是验证被测试系统随着计算能力的扩展是否能够承受更大的负载。负载的增大包括数据规模、业务种类、数据复杂度等。
可扩展性测试的目的：
针对系统在某一个负载方向上的可扩展性，通过一组测试评估系统在不同负载下的性能情况，从而分析系统在此负载变化方向上的可扩展性。
在不同的负载下衡量系统响应时间或吞吐率的变化趋势。
--->任何性能指标的好坏，除了与软件本身的并发性能好坏有关，还在很大程度上取决于硬件系统的处理能力。
性能测试流程
编写性能测试计划--设计与实现测试用例--执行测试--性能问题确定与调优--编写测试报告
制定性能测试计划：
内容：
开始的必要条件，即开发人员、其他类型测试人员为了保证性能测试顺利进行而必须做的工作。
退出条件，定义什么时候性能测试结束，通常与产品的质量控制标准有关。
目标与范围，目标往往直接来自于用户需求规格说明书中的非功能性需求描述。
测试用例，包括测试场景的描述、输入/输出描述。
--->性能需求的来源:
性能需求根本上应该来自实际用户的需求，对于有明确性能指标定义的描述都应该在测试计划中制定相应的测试用例，量化的性能指标应该成为制定测试用例通过标准的依据。
以前版本的用户缺陷报告
行业的质量标准
由于硬件/软件版本升级带来的性能提升测试需求
--->一个完整的测试用例描述如下：
测试场景，描述待测系统处理的业务内容，或者说测试用户所执行的业务操作<---->系统交互的角色/角色所执行的业务流程。
测试负载和通过标准，并发用户数、思考时间、测试持续时间等。通过标准包括吞吐率、页面响应时间、资源占用率通过标准。
测试数据规模，测试数据的设计应该从实际用户的需求出发。
待测系统软/硬件配置和拓扑结构，测试计划中应明确描述操作系统版本在内的所有测试相关软件版本信息、硬件平台和详细配置信息及系统的拓扑结构。
性能测试一般不会涵盖系统所支持的所有可能的功能场景，设计测试用例的原则之一就是用尽可能小的测试场景覆盖尽可能多的测试目标。
测试用例设计不合理有可能导致测试结果的无效性，进而引起测试返工甚至有可能发现不了系统性能缺陷。