性能测试方案性能测试的步骤

性能测试知多少----性能测试分类之我见

从这一篇开始，虫师向性能方面发力。

翻看自己的博客，最早的时候热衷于jmeter，于是写了几篇图文并茂的文章（其实，主要是操作截图加文字描述），之后，由于看到好多朋友关于性能的知识什么都不知道，下载个loadrunner 就说要做性能测试，结果可想而知，遇到各种概念与使用问题。

于是写了《在做性能测试之前需要知道什么》《在做性能测试之后需要知道什么》，关于loadrunner的我没有写一篇博客，因为介绍loadrunner的网站、资料、书籍和视频太多了。

我想这个系列我也会把关注点放在思想上。

性能测试常见分类 常会别人说到性能测试、负载测试、压力测试、并发测试，很多人都是混合使用，或者一会叫压力测试，一会叫并发测试。

这些概念除了非测试人员分不清楚，甚至许多专业测试人员也对这些名词也很模糊。

关于这个分类我翻阅了几个本比较好的书籍，他们讲的也比较模糊，没有给出本质上的区别。

只是从不同角度和关注点来解释。

好吧我们先来看他们之间比较普遍的解释。

性能测试（狭义） 性能测试方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。

通俗地说，这种方法就是要在特定的运行条件下验证系统的能力状态。

特点： 1、这种方法的主要目的是验证系统是否有系统宣称具有的能力。

2、这种方法要事先了解被测试系统经典场景，并具有确定的性能目标。

3、这种方法要求在已经确定的环境下运行。

也就是说，这种方法是对系统性能已经有了解的前提，并对需求有明确的目标，并在已经确定的环境下进行的。

负载测试 通过在被测系统上不断加压，直到性能指标达到极限，例如“响应时间”超过预定指标或都某种资源已经达到饱和状态。

特点：1、这种性能测试方法的主要目的是找到系统处理能力的极限。

2、这种性能测试方法需要在给定的测试环境下进行，通常也需要考虑被测试系统的业务压力量和典型场景、使得测试结果具有业务上的意义。

3、这种性能测试方法一般用来了解系统的性能容量，或是配合性能调优来使用。

也就是说，这种方法是对一个系统持续不段的加压，看你在什么时候已经超出“我的要求”或系统崩溃。

压力测试（强度测试）压力测试方法测试系统在一定饱和状态下，例如cpu、内存在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误 特点：1、这种性能测试方法的主要目的是检查系统处于压力性能下时，应用的表现。

2、这种性能测试一般通过模拟负载等方法，使得系统的资源使用达到较高的水平。

3、这种性能测试方法一般用于测试系统的稳定性。

也就是说，这种测试是让系统处在很大强度的压力之下，看系统是否稳定，哪里会出问题。

并发测试并发测试方法通过模拟用户并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或其者他性能问题。

特点：1、这种性能测试方法的主要目的是发现系统中可能隐藏的并发访问时的问题。

2、这种性能测试方法主要关注系统可能存在的并发问题，例如系统中的内存泄漏、线程锁和资源争用方面的问题。

3、这种性能测试方法可以在开发的各个阶段使用需要相关的测试工具的配合和支持。

也就是说，这种测试关注点是多个用户同时（并发）对一个模块或操作进行加压。

配置测试 配置测试方法通过对被测系统的软硬件环境的调整，了解各种不同对系统的性能影响的程度，从而找到系统各项资源的最优分配原则。

特点：1、这种性能测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。

2、这种性能测试方法一般在对系统性能状况有初步了解后进行。

3、这种性能测试方法一般用于性能调优和规划能力。

也就是说，这种测试关注点是“微调”，通过对软硬件的不段调整，找出这他们的最佳状态，使系统达到一个最强的状态。

可靠性测试 在给系统加载一定业务压力的情况下，使系统运行一段时间，以此检测系统是否稳定。

特点：1、这种性能测试方法的主要目的是验证是否支持长期稳定的运行。

2、这种性能测试方法需要在压力下持续一段时间的运行。

（2~3天） 3、测试过程中需要关注系统的运行状况。

也就是说，这种测试的关注点是“稳定”，不需要给系统太大的压力，只要系统能够长期处于一个稳定的状态。

上面的分类绝非全面，还有失效性测试，就是系统局部发生问题时，其它模块是否可以正常的运行。

这个在极少数情况下进行，这里就不介绍了。

性能测试分类之我见 上面的类分完了，似乎得到不少专家的认同，并无不妥。

但我们在性能测试过程中真的能把它们区别分的很清楚么?你能严格区分出你这次的测试到底并发测试还是压力测试。

笔者第一点不太赞同的是对“性能测试”的定义。

笔者认为性能测式测试包含了上面的所有分类。

而这种性能测试的定义只是一种狭义上的“性能测试”，属于性能测试的一种。

性能测试是相对功能测试来说的。

他们之间最本质的区别就是对系统有处理能力是否够成压力。

如果一个用户的一个操作（比如超大数据量的查询）对系统够成了压力，我也可以视其为性能测试。

其实，可以这样来划分性能测试 上面定交了那么多分类，是不是有点晕了。

其实，以笔者认为我们进行性能测试时关注的就两点。

耐力和爆发力。

初高中时练过几年体育，最好时代表学校参加县体育比赛，不过是去垫底的。

哈哈！哈一个体育运动员来说，那么多的体育项目，其实，考核他的就两方面。

一是爆发力。

二是耐力。

爆发力：拿一个举重选手来说，他的重点在重量上，因为你只要能举起三秒就算你成功了。

关键是看你能举起一个什么样的重量。

耐力：拿一个马拉松运动员来说，你百米速度跑得再快没用。

关键是这40公里路程中，最先跑到终点的人才是赢家。

整体协调性：当然，身为一个教练员，我在选拔选手的时候，除了看这个运动员的耐力和爆发力，身体的整体协调性也是我考核的一个很重要的指标。

比如一个运行员身体各位部位练得非常强壮，但右臂先天性萎缩。

他的跑步成绩虽然不错。

但他在跑的过程中，身体有各个部分都在分担右臂的不足。

右臂影响了整个体能的发挥。

再到系统的性能上说，爆发力就是这个系统能承受的最大压力，没准这个系统承受的压力很大。

但过半个小时之间就挂掉了。

耐力就是这个每系统长时间处于压力下的稳定性，这系统超级稳定，跑个几十年都不用重启服务器。

那么整体协调性就是看系统有没系统瓶颈，需不需要进行系统调优。

在做性能测试时请忘掉分类 这里只是告诉在做性能测试时不要想这个测试是属于性能测试的哪一类呢？是并发性测呢？还是压力测试？ 我们还拿上面的教练员选拔选手做例子。

1、双腿的考核，一个是步幅，就是步与步之间的距离。

一个是频率，两腿交替的频率。

如果你一步拉得很大的话，那么频率一定会下降。

如果想提高频率的话，那么一定会影响到步幅的大小。

2、双臂的考核，肩膀是否放松，摆臂是否有力，双臂的摆动与双腿的摆动是否协调。

3、呼吸是否匀称，目前的速度可以跑几圈。

我只做了一项体育运行，就考核了我这么多内容。

我们在做一个性能测试时也不局限在某一分类上，也可能我们的一个测试包含多个分类。

《web性能测试实战》： 么多类型的性能测试看起来很吓人，实际上它他们大多是密切相关的。

例如，运行8个小时来测试系统是否可靠，而这个测试极有可能包含了可靠性能测、强度测试、并发测试、负载测试，等等。

因此，在实施性能测试时决不能割裂它们的内部联系去进行，而应该分析它们之间的关系，以一种高效率的方式来设计性能测试。

性能测试的方法

对于企业应用程序，有许多进行性能测试的方法，其中一些方法实行起来要比其他方法困难。

所要进行的性能测试的类型取决于想要达到的结果。

例如，对于可再现性，基准测试是最好的方法。

而要从当前用户负载的角度测试系统的上限，则应该使用容量规划测试。

本文将介绍几种设置和运行性能测试的方法，并讨论这些方法的区别。

如果不进行合理的规划，对J2EE应用程序进行性能测试将会是一项令人望而生畏且有些混乱的任务。

因为对于任何的软件开发流程，都必须收集需求、理解业务需要，并在进行实际测试之前设计出正式的进度表。

性能测试的需求由业务需要驱动，并由一组用例阐明。

这些用例可以基于历史数据（例如，服务器一周的负载模式）或预测的近似值。

弄清楚需要测试的内容之后，就需要知道如何进行测试了。

在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。

基准测试可以在一个相对短的时间内收集可重复的结果。

进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。

例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。

这样在分析测试结果时就有迹可循。

下一小节我将介绍什么是基准测试，以及运行基准测试的最佳参数。

开发阶段后期，在应用程序中的bug已经被解决，应用程序达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。

这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试（peak-rest test)，它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。

对于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用模式都是不同的。

例如，容量规划测试通常都使用较缓慢的ramp-up（下文有定义），但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。

但是，要记住，因为更改了测试参数（比如ramp-up周期或用户的考虑时间（think-time)），测试的结果肯定也会改变。

一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。

基准测试的关键是要获得一致的、可再现的结果。

可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。

使用的性能测试工具可能会对测试结果产生很大影响。

假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。

服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。

很明显，与服务器通信的用户越多，负载就越大。

同样，请求之间的考虑时间越短，负载也越大。

这两个因素的不同组合会产生不同的服务器负载等级。

记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。

注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。

在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。

注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。

这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。

当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。

但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。

注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。

这是因为请求不能被及时处理。

为了获得真正可再现的结果，应该将系统置于相同的高负载下。

为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。

这样服务器会立即超载，并开始构建执行队列。

如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。

您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。

精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。

这称为“flat”测试。

与此相对应的是“ramp-up”测试。

ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。

ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。

因此，flat运行是获得基准测试数据的理想模式。

这不是在贬低ramp-up测试的价值。

实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。

ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。

然后可以据此选择以后要运行的flat测试的范围。

Flat测试的问题是系统会遇到“波动”效果。

注意波动的出现，吞吐量不再是平滑的。

这在系统的各个方面都有所体现，包括CPU的使用量。

注意，每隔一段时间就会出现一个波形。

CPU使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。

此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。

注意，每隔一段时间就会出现一个波形。

执行队列曲线与上面的CPU使用量图非常相似。

最后，系统中事务的响应时间也遵循着这个波动模式。

注意，每隔一段时间就会出现一个波形。

事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。

这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。

有两种方法可以从这种类型的结果中获得精确的测量值。

如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。

或者，可以只选取波形中两个平息点之间的测量值。

该方法的缺点是可以捕获数据的时间非常短。

对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。

此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。

引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。

通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。

例如，您可能想知道：如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。

要确定系统的容量，需要考虑几个因素。

通常，服务器的用户总数非常大（以十万计），但是实际上，这个数字并不能说明什么。

真正需要知道的是，这些用户中有多少是并发与服务器通信的。

其次要知道的是，每个用户的“考虑时间”即请求间时间是多少。

这非常重要，因为考虑时间越短，系统所能支持的并发用户越少。

例如，如果用户的考虑时间是1秒，那么系统可能只能支持数百个这样的并发用户。

但是，如果用户的考虑时间是30秒，那么系统则可能支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。

在现实世界中，通常难以确定用户的确切考虑时间。

还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。

于是就引入了随机性。

如果知道普通用户的考虑时间是5秒，误差为20%，那么在设计负载测试时，就要确保请求间的时间为5×（1 +/- 20%）秒。

此外，可以利用“调步”的理念向负载场景中引入更多的随机性。

它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1 +/- 25%）秒），然后再继续执行下一套请求。

将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。

进行实际的容量规划测试了。

接下来的问题是：如何加载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务器通信的状况。

这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个用户。

或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的用户同时加载到服务器。

两种不同类型的测试会产生没有可比性的不同测试。

例如，如果进行ramp-up类型的测试，系统可以以4秒或更短的响应时间支持5,000个用户。

而执行flat测试，您会发现，对于5,000个用户，系统的平均响应时间要大于4秒。

这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。

以门户应用程序为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。

这不是说不应该使用ramp-up测试。

对于系统负载在一段比较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。

这是因为系统能够随着时间不断调整。

如果使用快速ramp-up测试，系统就会滞后，从而报告一个较相同用户负载的flat测试低的响应时间。

那么，什么是确定容量的最好方法？结合两种负载类型的优点，并运行一系列的测试，就会产生最好的结果。

例如，首先使用ramp-up测试确定系统可以支持的用户范围。

确定了范围之后，以该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。

渗入测试是一种比较简单的性能测试。

渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。

这些测试将会通过内存泄漏、增加的垃圾收集（GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。

测试运行的时间越久，您对系统就越了解。

运行两次测试是一个好主意——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

测试应该运行几天的时间，以便真正了解应用程序的长期健康状况。

要确保测试的应用程序尽可能接近现实世界的情况，用户场景也要逼真（虚拟用户通过应用程序导航的方式要与现实世界一致），从而测试应用程序的全部特性。

确保运行了所有必需的监控工具，以便精确地监测并跟踪问题。

峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。

其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。

这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了内存或GC性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。

如何制定测试计划？

测试计划活动的输出是一份测试计划，它是一份或多份文档，应该由测试团队、开发团队和项目管理层复查。

测试计划确定了测试产品所需的资源，确定了我们将测试什么，测试将怎样进行，测试将得到怎样的输出或提交产物。

我们一直使用日事清来做软件测试工作。

日事清帮你来做软件测试工作计划：一是有明确的目标；二是有详细的计划；三是立刻采取行动；四是修复自己的行动。

以上四点是高效完成测试工作的四个基本条件。

首先把自己的软件测试计划通通列出来，清空大脑，做一个软件测试计划前的行动。

根据自己的轻重缓急来分配软件测试任务。

一是确定测试策略。

测试策略一般描述软件测试活动的一般方法和目标。

其中包括要进行的测试阶段（单元测试、集成测试和系统测试）以及要执行的测试类型（功能测试、性能测试、负载测试、强度测试等）。

确定测试需求：明确测试的工作范围，需要测试的对象、达到的指标等。

可以来源于软件需求，个人经验，以前发生的错误等。

二是确定测试系统。

确定测试环境。

确定测试工具。

确定配置情况。

确定测试资源。

测试人力资源。

测试非人力资源（计算机、工具等） 三是确定测试任务。

根据本阶段测试需求，细化测试任务。

划分任务优先级，和主要任务关联关系。

确定辅助任务清单（如培训等）。

确定资源情况。

四是评估和确定测试工作量。

目前没有任何一种方法能准确的评估出软件测试工作的工作量，要想更有效的做出估算，必须持之以恒的统计和分析历史数据。

主要的估算方法为：分析以前的同类项目、同行专家判断、分解细化项目、经验主意预估模型（代码行(LOC)和功能点(FP)估算法等）。

五是确定时间进度。

收集与进度相关的信息：总体工作量估算、人员数量、关键资源、项目时间安排等。

确定各阶段任务安排和资源分配，确定里程碑。

依据项目总体时间安排，形成进度计划。

确定时间段。

为每个测试目标规定合理的测试起始/中止时间。

通常情况下，功能性需求和非功能性需求的测试存在先后顺序，能并行。

六是评估风险。

风险分析、对测试计划中所有要执行的内容进行潜在的风险分析并给出规避措施、确定项目中可能会出问题的地方、如测试人员没有接受必要的培训、测试人员不足、需求变化过快、自动测试技术的采用等、评估风险的发生概率、如风险发生后可能的影响程度、如何降低风险乃至避免风险的方法。

七是确定测试过程评估方法。

确定测试过程评估方法、评估内容：测试工作进展/缺陷分布/质量评估、评估间隔：每天/周/月、评估人员/报告原则。

性能测试的定义?

性能测试方法是通过模拟生产环境运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。

性能测试是一种最常见的测试方法，这种测试方法就是要在特定的运行条件下验证系统的能力状况。

这种方法的特点有： （1） 这种方法的主要目的是验证系统是否有系统宣称具体的能力。

（2） 这种方法需要了解被测系统典型场景，并具有确定的性能目标。

所谓的典型场景就是具有代表性的用户业务操作，一个典型的场景包括操作 序列、并发用户数量条件。

其次， 这种方法需求有确定的性能目标，性能 目标的描述基本上是这样：“要求系统在100个并发用户的条件下进行某业务 操作，响应时间不超过5秒” （3） 这种方法要求在已确定的环境下运行。

性能测试的步骤

在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。

我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

由于工程和项目的不同，所选用的度量，评估方法也有不同之处。

不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。

步骤如下 1． 制定目标和分析系统 2． 选择测试度量的方法 3． 学习的相关技术和工具 4． 制定评估标准 5． 设计测试用例 6． 运行测试用例 7． 分析测试结果 每一个性能测试计划中第一步都会制定目标和分析系统构成。

只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。

目标： 1． 确定客户需求和期望 2． 实际业务需求 3． 系统需求 系统组成 系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。

了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。

系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。

例如：系统类别是bs结构，需要掌握 等。

所以甄别系统类别对于我们来说很重要。

系统构成：硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。

不同的系统构成性能测试就会得到不同的结果。

系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统功能是性能测试中要模拟的环节，了解这些是必要的。

经过第一步，将会对系统有清醒的认识。

接下来我们将把精力放在软件度量上，收集系统相关的数据。

度量的相关方面： * 制定规范 * 制定相关流程，角色，职责 * 制定改进策略 * 制定结果对比标准 性能测试是通过工具，模拟大量用户操作，对系统增加负载。

所以需要掌握一定的工具知识才能进行性能测试。

大家都知道性能测试工具一般通过winsock,http等协议记录用户操作。

而协议选择是基于软件的系统架构实现（web一般选择http协议，cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。

确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。

任何测试的目的都是确保软件符合预先规定的目标和要求。

性能测试也不例外。

所以必须制定一套标准。

通常性能测试有四种模型技术可用于评估： *线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

*分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来 *模仿：模仿实际用户的使用方法测试你的系统 *基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比 运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。

通过排除误差和其他因素，让测试结果体现接近真实情况。

不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。