当前位置：搜档网 › 性能测试方法及分析方法

性能测试方法及分析方法

一、性能测试简介

1.1什么是软件性能

一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。

性能的及时性用响应时间或者吞吐量来衡量。响应时间是对请求作出响应所需要的时间。

对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。比如，“用户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到这个用户任务中，可能有多个具体的事务需要完成，每个事务都有其单独的响应时间。

对交互式的应用（例如典型的Web应用）来说，我们一般以用户感受到的响应时间来描述系统的性能，而对非交互式应用（嵌入式系统或是银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。

通常，对软件性能的关注是多个层面的：用户关注软件性能，管理员关注软件性能，产品的开发人员也关注软件性能，下面将从3个不同层面来对软件性能进行阐述。

1.1.1用户视角的软件性能

从用户的角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮、发出一条指令或是在Web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。图1.1以一个Web系统为例，说明了用户的这种印象。

服务器

应用界面

呈现时间

图1.1 Web系统的响应

必须要说明的是，用户所体会到的“响应时间”既有客观的成分，也有主观的成分。例如，用户执行了某个操作，该操作返回大量数据，从客观的角度来说，事务的结束应该是系统返回所有的数据，响应时间应该是从用户操作开始到所有数据返回完成的整个耗时；但从用户的主观感知来说，如果采用一种优化的数据呈现策略，当少部分数据返回之后就立刻将数据呈现在用户面前，则用户感受到的响应时间就会远远小于实际的事务响应时间（顺便说一下，这种技巧是在C/S结构的管理系统中开发人员常用的一种技巧）。

关于响应时间的进一步讨论请见1.2.1节对“响应时间”的解释。

1.1.2管理员视角的软件性能

从管理员的角度来看，软件系统的性能首先表现在系统的响应时间上，这一点和用户视角是一样的。但管理员是一种特殊的用户，和一般用户相比，除了会关注一般用户的体验之外，他还会关心和系统状态相关的信息。例如，管理员已经知道，在并发用户数为100时，A业务的响应时间为8秒，那么此时的系统状态如何呢？服务器的CPU使用是不是已经达到了最大值？是否还有可用的内存？应用服务器的状态如何？我们设置的JVM可用内存是否足够？数据库的状况如何？是否还需要进行一些调整？这些问题普通的用户并不关心，因为这不在他们的体验范围之内；但对管理员来说，要保证系统的稳定运行和持续的良好性能，就必须关心这些问题。

另一方面，管理员还会想要知道系统具有多大的可扩展性，处理并发的能力如何；而且，管理员还会希望知道系统可能的最大容量是什么，系统可能的性能瓶颈在哪里，通过更换哪些设备或是进行哪些扩展能够提高系统性能，了解这些情况，管理员才能根据系统的用户状况制定管理措施，在系统出现计划之外的用户增长等紧急情况的时候能够立即制定相应措施，进行迅速的处理；此外，管理员可能还会关心系统在长时间的运行中是否足够稳定，是否能够不间断地提供业务服务等。

因此，从管理员的视角来看，软件性能绝对不仅仅是应用的响应时间这么一个简单的问题。

表1-1给出了管理员关注的部分性能相关问题的列表。

表1-1 管理员关注的部分性能相关问题

1.1.3开发视角的软件性能

从开发人员的角度来说，对软件性能的关注就更加深入了。开发人员会关心主要的用户感受——响应时间，因为这毕竟是用户的直接体验；另外，开发人员也会关心系统的扩展性等管理员关心的内容，因为这些也是产品需要面向的用户（特殊的用户）。但对开发人员来说，其最想知道的是“如何通过调整设计和代码实现，或是如何通过调整系统设置等方法提高软件的性能表现”，和“如何发现并解决软件设计和开发过程中产生的由于多用户访问引起的缺陷”，因此，其最关注的是使性能表现不佳的因素和由于大量用户访问引发的软件故障，也就是我们通常所说的“性能瓶颈”和系统中存在的在大量用户访问时表现出来的缺陷。

举例来说，对于一个没有达到预期性能规划的应用，开发人员最想知道的是，这个糟糕的性能表现究竟是由于系统架构选择的不合理还是由于代码实现的问题引起？由于数据库设计的问题引起？抑或是由于系统的运行环境引发？

或者，对于一个即将发布到现场给用户使用的应用，开发人员可能会想要知道当大量用户访问这个系统时，系统会不会出现某些故障，例如，是否存在由于资源竞争引起的挂起？是否存在由于内存处理等问题引起的系统故障？

因此，对开发人员来说，单纯获知系统性能“好”或者“不好”的评价并没有太大的意

义，他们更想知道的是“哪些地方是引起不好的性能表现的根源”或是“哪里可能存在故障发生的可能”。

表1-2给出了开发视角的软件性能关注内容。

表1-2 开发人员关注的性能问题

1.1.4总结

以上我们描述了3个不同层面上的软件性能关注点，由此可见，不同的对象对软件系统性能的关注是有着显著的差异的。从项目管理的角度，以我们的系统干系人来分析，大部分用户对性能的理解属于“用户视角”，项目的维护人员或是用户方的项目经理一般会从“管理员视角”来看待软件性能的问题，而项目的创建者——开发人员（包括设计人员）自然就是从“开发视角”来关注软件性能了。

因此，对软件性能测试来说，在不同的层面上要求我们关注不同的内容：从直接体验的用户的角度来说，表现为软件系统对用户操作的响应时间；在系统或是管理员的关注层面，我们还需要从软件的性能表现分析系统的可扩展性、并发能力等指标；最后，从最贴近软件的创建者——开发人员的角度来说，还需要为软件性能问题进行定位，了解性能的制约因素和引起性能问题的关键原因。

1.2软件性能的几个术语

接触过软件性能测试的人，会经常听到这样一些词汇：响应时间、并发用户数、吞吐量、性能计数器，在使用性能测试工具进行测试时，还会接触到“思考时间（Think Time）”的概念，那么，这些术语的确切含义究竟是什么呢？

本节重点介绍以上的各个术语。

1.2.1 响应时间

在1.1节和1.1.1节中都提到了“响应时间”的概念，响应时间是“对请求作出响应所需要的时间”，而且，我们把响应时间作为用户视角的软件性能的主要体现。

图1.1将用户所感受到的软件性能（响应时间）划分为“呈现时间”和“系统响应时间”两个部分，其中“呈现时间”取决于数据在被客户端收到响应数据后呈现页面所消耗的时间，例如，对一个Web应用，呈现时间就是浏览器接收到数据后用户把数据呈现出来的时间；而“系统响应时间”指应用系统从请求发出开始到客户端接收到数据所消耗的时间。在一般的性能测试中，我们并不关注“呈现时间”，这是因为呈现时间在很大程度上取决于客户端的表现，例如，一台内存不足的客户端机器在处理复杂页面的时候，其呈现时间可能就很长，而这并不能说明整个系统的性能。在后续的软件性能测试的讨论中，我们不会区分“系统响应时间”和“响应时间”，直接把这里的“系统响应时间”等同于“响应时间”。

响应时间可以被进一步分解。图1.2描述了一个Web应用的页面响应时间的构成。从图中可以看到，页面的响应时间可被分解为“网络传输时间”（N1+N2+N3+N4）和“应用延迟时间”（A1+A2+A3），而“应用延迟时间”又可以分解为“数据库延迟时间”（A2）和“应用服务器延迟时间”（A1+A3）。之所以要对响应时间进行这些分解，主要目的是为了能更好定位性能瓶颈的所在。在后续的实例讨论中，读者将会看到如何应用这些响应时间的分解进行性能问题的定位。

图1.2 Web应用的页面响应时间分解

关于响应时间，要特别说明的一点是，对客户来说，该值是否能够被接受是带有一定的用户主观色彩，也就是说，响应时间的“长”和“短”没有绝对的区别。

例如，对一个电子商务网站来说，在美国和欧洲，一个普遍被接受的响应时间标准为2/5/10秒，也就是说，在2秒之内给客户响应被用户认为是“非常有吸引力的”，在5秒之内响应客户被认为是“比较不错的”，而10秒是客户能接受的响应的上限。

但考虑一个税务报账系统，该系统的用户每月使用一次该系统，一次花费2小时以上进

行数据的录入，当用户单击“提交”按钮后，即使系统在20分钟后才给出“处理成功”的消息，用户仍然不会认为该系统的响应时间不能接受——毕竟，相对于一个月才进行一次的操作来说，20分钟确实是一个可以接受的等待时间。

因此，在进行性能测试时，“合理的响应时间”取决于实际的用户需求，而不能依据测试人员自己的设想来决定。

1.2.2 并发用户数

在阐述这个术语之前，先来看看为什么在性能测试中需要关注这个“并发用户数”。

首先，如果性能测试的目标是验证当前系统能否支持现有用户的访问，最好的办法就是弄清楚会有多少用户会在同一个时间段内访问被测试的系统，如果使用性能测试工具模拟出与系统的访问用户数相同的用户，并模拟用户的行为，那得到的测试结果就能够真实反映实际用户访问时的系统性能表现，这样一来，也就能够通过性能测试了解到当系统处于实际用户访问时，会具有怎样的性能表现。这里提到的在同一个时间段内访问系统的用户数量，也就是我们说的并发用户数的一个概念，这种并发的概念通常在性能测试（Performance Testing）方法中使用，用于从业务的角度模拟真实的用户访问，体现的是业务并发用户数。

如果抛开业务的层面，仅从服务器端承受的压力来考虑，那么，对C/S或是B/S结构的应用来说，系统的性能表现毫无疑问地主要由“服务端”决定。在什么时候“服务端”会承受最大的压力，或者说，在什么时候“服务端”表现为最差的性能呢？毫无疑问，肯定是在大量用户同时对这个系统进行访问的时候。为了说明这个“同时”，参见图1.3。

图1.3 用排球击打墙面

图1.3用“排球击打墙面”说明这种“同时”，毫无疑问，越多的球同时击打到墙面，墙面承受的压力也就越大。如果把击打排球的人看成是系统的使用者，墙壁代表了我们可怜的服务端，显然，当越多的用户同时使用系统，系统承受的压力越大，系统的性能表现也就越差，而且，此时很可能出现由于用户的同时访问导致的资源争用等问题。我们在这里提到

了“并发用户数”的另一个概念，该概念不从业务角度出发，而是从服务端承受的压力出发，描述的是同时向客户端发出请求的客户，该概念一般结合并发测试（Concurrency Testing）使用，体现的是服务端承受的最大并发访问数。

下面我们用一个更接近实际的例子来说明这两个并发概念之间的不同。

图1.4所示是实际应用系统的演示。

应用界面

图1.4 实际应用系统

对服务端来说，每个用户和服务端的交互都是离散的。如果仅考虑一个单独的用户对系统的使用，过程大致如下：用户每隔一段时间向服务端发送一个请求或是命令，服务端按照用户的请求执行某些操作，然后将结果返回给用户。

从用户的角度来看，在一个相当长的时间段内（例如1天），都会有基本固定数量的使用者使用该系统，虽然每个使用者的行为不同，但从业务的角度来说，如果所有这些用户的操作都没有遇到性能障碍，则可以说该系统能够承受该数量的并发用户访问，这里的并发概念就是前面讨论的业务并发用户数。

然而，如果考虑整个系统运行过程中服务器所承受的压力，情况就会不同了：在该系统的运行过程中，把整个运行过程划分为离散的时间点，在每个点上，都有一个“同时向服务端发送请求的客户数”，这个就是所称的服务端承受的最大并发访问数。如果能找到运行过程中可能出现的最大可能的服务端承受的最大并发访问数，则在该用户数下，服务器承受的压力最大，资源承受的压力也最大，在这种状态下，可以考虑通过并发测试（Concurrency Testing）发现系统中存在的并发引起的资源争用等问题。

在实际的性能测试中，经常接触到的与并发用户数相关的概念还包括“并发用户数”、“系统用户数”和“同时在线用户人数”，下面用一个实际的例子来说明它们之间的差别。

假设有一个OA系统，该系统有2000个使用用户——这就是说，可能使用该OA系统的用户总数是2000名，这个概念就是“系统用户数”，该系统有一个“在线统计”功能（系统用一个全局变量计数所有已登录的用户），从在线统计功能中可以得到，最高峰时有500人

在线（这个500就是一般所说的“同时在线人数”），那么，系统的并发用户数是多少呢？

根据我们对业务并发用户数的定义，这500就是整个系统使用时最大的业务并发用户数。当然，500这个数值只是表明在最高峰时刻有500个用户登录了系统，并不表示实际服务器承受的压力。因为服务器承受的压力还与具体的用户访问模式相关。例如，在这500个“同时使用系统”的用户中，考察某一个时间点，在这个时间上，假设其中40%的用户在饶有兴致地看系统公告（注意：“看”这个动作是不会对服务端产生任何负担的），20%的用户在填写复杂的表格（对用户填写的表格来说，只有在“提交”的时刻才会向服务端发送请求，填写过程是不对服务端构成压力的），20%部分用户在发呆（也就是什么也没有做），剩下的20%用户在不停地从一个页面跳转到另一个页面——在这种场景下，可以说，只有20%的用户真正对服务器构成了压力。因此，从上面的例子中可以看出，服务器实际承受的压力不只取决于业务并发用户数，还取决于用户的业务场景。

那么，该系统的服务端承受的最大并发访问数是多少呢？这个取决于业务并发用户数和业务场景，一般可以通过对服务器日志的分析得到。

在实际的性能测试工作中，测试人员一般比较关心的是业务并发用户数，也就是从业务角度关注究竟应该设置多少个并发数比较合理，因此，在后面的讨论中，也是主要针对业务并发用户数进行讨论，而且，为了方便，直接将业务并发用户数称为并发用户数。

那么，究竟应该如何获得测试人员关心的并发用户数的具体数值呢？

下面给出了一些用于估算并发用户数的公式。

nL C = （1） C C C

3?+≈ （2）在公式（1）中，C 是平均的并发用户数；n 是login session i

的数量；L 是login session 的平均长度；T 指考察的时间段长度。例如，对一个典型的OA 应用，考察的时间段长度应该为8小时的工作时间。公式（2）则给出了并发用户数峰值的计算方式，其中，C

?指并发用户数的峰值，C 就是公式（1）中得到的平均的并发用户数。该公式的得出是假设用户的login session 产生符合泊松分布而估算得到的。

下面根据上述给出的方法进行实例计算。

实例：假设有一个OA 系统，该系统有3000个用户，平均每天大约有400个用户要访问该系统，对一个典型用户来说，一天之内用户从登录到退出该系统的平均时间为4小时，在

一天的时间内，用户只在8小时内使用该系统。

则根据公式（1）和公式（2），可以得到：

C=400×4/8=200

C?200+3×200=242

≈

当然，这是种可行的方法，但仔细考究起来，其并不是惟一，甚至说不上是最精确的方法，因为在公式中仍然需要估算“平均用户数”和“login session的长度”，而要精确估算这两个值并不容易。另外，考虑到用户的业务操作存在一定的时间集中性（也就是说，用户对系统业务的访问往往不是平均分布在整个考察时间段内，而是相对集中地分布在某几个时间段内），采用公式（1）和公式（2）进行计算仍然存在一定的偏差。

我们给出对该公式使用的一些建议，遵循这些建议，可以更精确地计算得到并发用户数：（1）以更细的时间粒度进行考察：例如，可以设定1个小时为考察时间的粒度，对一个典型的OA系统，将一天的上班时间划分为8个区间，这样可以解决前面提到的业务操作存在的时间集中性的问题。

（2）考虑典型的业务模式：不同的应用有不同的业务模式，例如，一个内部系统一般在上班开始后的30分钟至1个小时集中出现用户的登录；一个账务系统在每月的结账日前几天会比较繁忙；一个门户网站在重大消息发布的前后会有访问高峰；一个旅游的网站在节假日前夕会有大量用户的访问……因此，在考虑计算并发用户数时，可以结合应用的业务模式，多考虑一些可能发生的场景，基于这些场景进行估算。

除了这种介绍的方法之外，对于企业内部使用的Web系统来说，一个更一般的（当然精度更差）经验公式是：

=（3）

C n

?（4）

≈

也就是说，用每天访问系统用户数的10%作为平均的并发用户数，并发用户数的最大值由并发用户数乘上一个调整因子r得到，r的取值一般为2～3。

公式（3）和公式（4）可以在要求不太严格的性能测试，或是只有很少数据支持分析的性能测试中使用。

在本节的前面部分提到了“日志分析”方法。所谓“日志分析”方法是指通过对应用服务器的日志进行分析，从而了解系统用户的使用状态，从日志中计算出“服务器承受的最大并发用户访问数”数据。这种方式得到的数据准确度和可信度都比较高，对于Internet应

用等无法估计用户数量和用户行为模式的应用，这种方式最为可信。

1.2.3 吞吐量

吞吐量是指“单位时间内系统处理的客户请求的数量”，直接体现软件系统的性能承载能力。一般来说，吞吐量用请求数/秒或是页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或是处理的业务数/小时等单位来衡量。当然，从网络的角度来说，也可以用字节数/天来考察网络流量。

例如，对一个Web应用系统来说，从系统的处理能力考虑，可以以页面数/秒作为吞吐量的标准；对一个银行的业务前台系统来说，可以以其处理的业务数/小时作为吞吐量的标准。

在本章的开始部分，已经讨论过，对于交互式应用，用户直接的体验是“响应时间”，通过“并发用户数”和“响应时间”可以确定系统的性能规划；但对于非交互式应用，用“吞吐量”来描述我们对系统性能的期望可能更加合理。

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力。在容量规划的测试中，吞吐量是一个重点关注的指标，因为它能够说明系统级别的负载能力；另外，在性能调优的过程中，吞吐量指标也有重要的价值，例如，Empirix公司在报告中声称，在他们所发现的性能问题中，有80%是因为吞吐量的限制导致的。

在对Web系统的性能测试过程中，吞吐量主要以请求数（单击数）/秒、页面数/秒或是字节数/秒来体现，吞吐量指标可以在两个方面发挥作用：

（1）用于协助设计性能测试场景，以及衡量性能测试场景是否达到了预期的设计目标：在设计性能测试场景时，吞吐量可被用于协助设计性能测试场景，根据估算的吞吐量数据，可以对应到测试场景的事务发生频率、事务发生次数等；另外，在测试完成后，根据实际的吞吐量可以衡量测试是否达到了预期的目标。

（2）用于协助分析性能瓶颈：吞吐量的限制是性能瓶颈的一种重要表现形式，因此，有针对性地对吞吐量设计测试，可以协助尽快定位到性能瓶颈所在位置。例如，RBI（Rapid Bottleneck Identify）方法就主要通过吞吐量测试发现性能

瓶颈。

以不同方式表达的吞吐量可以说明不同层次的问题。例如，以字节数/秒方式表示的吞吐量主要受网络基础设施、服务器架构、应用服务器制约；以单击数/秒方式表示的吞吐量主要受应用服务器和应用代码的制约。

作为性能测试时的主要关注指标，吞吐量和并发用户数之间存在一定的联系。在没有遇到性能瓶颈的时候，吞吐量可以采用如下公式计算：

vu N R F T

?= （5）其中，F 表示吞吐量；N vu 表示VU （Virtuae User ，虚拟用户）的个数；R 表示每个VU 发出的请求（单击）数量；T 表示性能测试所用的时间。但如果遇到了性能瓶颈，此时吞吐量和VU 数量之间就不再符合公式（5）给出的关系。

常用于分析吞吐量的图形是“吞吐量——VU 数量”的关联图。图1.5给出了两个“吞吐量——VU 数量”关联图的示例。

从图中可以看到，吞吐量在VU 数量增长到一定程度的时候产生了性能瓶颈。

最后，必须要说明的是，虽然吞吐量指标可被看作是系统承受压力的体现，但在不同并发用户数量的情况下，对同一个系统施加相同的吞吐量压力，很可能会得到不同的测试结果。本文给出了一个示例。

图1.5 “吞吐量——VU 数量”关联图示例

对同一个应用进行两次不同的性能测试，测试A 采用100个并发，每个VU 间隔1秒发出一个请求；测试B 采用1000个并发，每个VU 间隔10秒发出一个请求；对测试A ，测试时的吞吐量（页/秒）为100×1/1=100；对测试B 来说，吞吐量（页/秒）为1000×1/10=100，仍然是100。但从测试结果来看，执行测试A 时，应用在50页/秒出现性能瓶颈，而测试B 在25页/秒出现性能瓶颈。

1.2.4 性能计数器

性能计数器（Counter ）是描述服务器或操作系统性能的一些数据指标。例如，对Windows 系统来说，使用内存数（Memory In Usage ），进程时间（Total Process Time ）等都是常见的计数器。

计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是在分析系统的可扩展性、进行性能瓶颈的定位时，对计数器取值的分析非常关键。但必须说明的是，单一的性能计数

器只能体现系统性能的某一个方面，对性能测试结果的分析必须基于多个不同的计数器。

与性能计数器相关的另一个术语是“资源利用率”。该术语指的是系统各种资源的使用状况。为了方便比较，一般用“资源的实际使用/总的资源可用量”形成资源利用率的数据，用以进行各种资源使用的比较。

例如，我们会说到，“某某系统在承受10000用户的并发访问时，Web 服务器的CPU 占用率为68%，平均的内存占用率为55%”，这其中，68%和55%就是典型的资源利用率的数值。

在性能测试中常用资源利用率进行横向的对比，例如，在进行测试时会发现，资源A 的使用率达到了接近100%的数值，而其他的资源利用率都处于比较低的水平，则可以很清楚地知道，资源A 就很有可能是系统的一个性能瓶颈。当然，资源利用率在通常的情况下需要结合响应时间变化曲线、系统负载曲线等各种指标进行分析。

性能计数器是性能测试分析的主要参考值，本书的第3章对其进行了详细的解释说明，并说明了如何利用这些计数器分析系统性能瓶颈。

1.2.5 思考时间

思考时间（Think Time ），也被称为“休眠时间”，从业务的角度来说，这个时间指的是用户在进行操作时，每个请求之间的间隔时间。前面已经讨论过，对交互式应用来说，用户在使用系统时，不大可能持续不断地发出请求，更一般的模式应该是用户在发出一个请求后，等待一段时间，再发出下一个请求。

因此，从自动化测试实现的角度来说，要真实地模拟用户操作，就必须在测试脚本中让各个操作之间等待一段时间，体现在脚本中，具体而言，就是在操作之间放置一个Think 的函数，使得脚本在执行两个操作之间等待一段时间。

在测试脚本中，思考时间体现为脚本中两个请求语句之间的间隔时间。不同的测试工具提供了不同的函数或者方法来实现思考时间，本书附录A 中对思考时间进行了的详细描述，另外，本书实践篇也有一些使用思考时间的实际例子。

在实际的测试中，设置多长的思考时间最为合理是许多性能测试工程师关心的问题。其实，思考时间与迭代次数、并发用户数和吞吐量之间存在一定的关系。

公式（5）说明吞吐量是VU 数量N vu 、每个用户发出请求数R 和时间T 的函数，而其中的R 又可以用时间T 和用户的思考时间T s 来计算：

T T R （6）

用公式（5）和公式（6）进行化简运算可得，吞吐量与N vu成正比，而与T s成反比。

不少性能测试工程师在实际的应用中都对如何给定合适的思考时间存在疑问，那么，在具体的测试实践中，究竟该怎样选择合适的思考时间呢？下面给出一个计算思考时间的一般步骤：

1．首先计算出系统的并发用户数；

2．统计出系统平均的吞吐量；

3．统计出平均每个用户发出的请求数量；

4．根据公式（6）计算出思考时间。

当然，为了让性能测试场景更加符合实际情况，可以考虑以步骤4计算得出的思考时间为基准，让实际的思考时间在一定幅度内随机变动。LoadRunner和Segue Silk Performer 等工具都支持以这种方式设置思考时间。

最后要说明的是“0思考时间”。有些文章建议在测试中使用“0”作为思考时间，以给系统更大的压力。在本人的实际性能测试过程中，对于交互式的应用系统，很少遇到这样的要求。因为从业务的角度考虑，思考时间用于更真实地模拟用户操作，设置思考时间为0，基本上不具有实际的业务含义。

但在非交互式应用的性能测试过程中，有时候确实会将思考时间设置为0，这时候是模拟一种尽可能大的压力，研究系统在巨大压力下的表现。

可以说，如果测试的目的是为了“验证应用系统具有预期的能力”（也就是所说的“能力验证”的应用领域），就应该尽量模拟用户在使用业务时的真实思考时间；如果目的是进行更一般的研究，例如“了解系统在压力下的性能水平”或是“了解系统承受压力的能力”（也就是所说的“规划能力”的应用领域），则可以采用0思考时间。

二、性能测试方法论与方法

“没有规矩，不成方圆”。对性能测试来说，如果没有合适的方法论指导，性能测试很容易成为一种随意的测试行为，而随意进行的性能测试很难取得实际的作用和预期的效果，因此本章将简单介绍几种常见的性能测试过程和方法，并着重介绍常用的性能测试方法。

2.1 性能测试方法论

2.1.1 SEI负载测试计划过程

SEI负载测试计划过程（SEI Load Testing Planning Process）是一个关注于负载测试计划的方法，其目标是产生“清晰、易理解、可验证的负载测试计划”。SEI负载测试计划过程包括6个关注的区域（Area）：目标、用户、用例、生产环境、测试环境和测试场景。

SEI负载测试计划过程将以上述6个区域作为负载测试计划需要重点关注和考虑的内容，其重点关注以下几个方面的内容：

1．生产环境与测试环境的不同：由于负载测试环境与实际的生产环境存在一定的差异，因此，在测试环境上对应用系统进行的负载测试结果很可能不能准确反映该应用系统在生产环境上的实际性能表现，为了规避这个风险，必须仔细设计测试环境。

2．用户分析：用户是对被测应用系统性能表现最关注和受影响最大的对象，因此，必须通过对用户行为进行分析，依据用户行为模型建立用例和场景。

3．用例：用例是用户使用某种顺序和操作方式对业务过程进行实现的过程，对负载测试来说，用例的作用主要在于分析和分解出关键的业务，判断每个业务发生的频度、业务出现性能问题的风险等。

从SEI负载测试计划过程的描述中可以看到，SEI负载测试计划过程给出了负载测试需要关注的重点区域，但严格来说，其并不能被称为具体的方法论，因为其仅仅给出了对测试计划过程的一些关注内容，而没有能够形成实际的可操作的过程。

同功能测试一样，性能测试也必须经历测试需求、测试设计、测试执行、测试分析等阶段，但由于性能测试自身的特殊性（例如，需要引入工具，分析阶段相对重要），性能测试过程又不能完全套用功能测试过程。

SEI负载测试计划过程在负载测试需要关注的具体内容上提供了参考，但其并不是一个完整的测试过程。

2.1.2 RBI方法

RBI（Rapid Bottleneck Identify）方法是Empirix公司提出的一种用于快速识别系统性能瓶颈的方法。该方法基于以下一些事实：

1. 发现的80%系统的性能瓶颈都由吞吐量制约；

2. 并发用户数和吞吐量瓶颈之间存在一定的关联；

3. 采用吞吐量测试可以更快速定位问题。

RBI方法首先访问服务器上的“小页面”和“简单应用”，从应用服务器、网络等基础的层次上了解系统吞吐量表现；其次选择不同的场景，设定不同的并发用户数，使其吞吐量保持基本一致的增长趋势，通过不断增加并发用户数和吞吐量，观察系统的性能表现。

在确定具体的性能瓶颈时，RBI将性能瓶颈的定位按照一种“自上而下”的分析方式进行分析，首先确定是由并发还是由吞吐量引发的性能表现限制，然后从网络、数据库、应用服务器和代码本身4个环节确定系统性能具体的瓶颈。

RBI方法在性能瓶颈的定位过程中能发挥良好的作用，其对性能分析和瓶颈定位的方法值得借鉴，但其也不是完整的性能测试过程。

2.1.3 性能下降曲线分析法

性能下降曲线实际上描述的是性能随用户数增长而出现下降趋势的曲线。而这里所说的“性能”可以是响应时间，也可以是吞吐量或是单击数/秒的数据。当然，一般来说，“性能”主要是指响应时间。

图1.6给出了一个“响应时间下降曲线”的示例。

图1.6 一条典型的响应时间性能下降曲线示例

从图1.6可以看到，一条曲线可以分为以下几个部分：

（1）单用户区域——对系统的一个单用户的响应时间。这对建立性能的参考值很有作用。

（2）性能平坦区——在不进行更多性能调优情况下所能期望达到的最佳性能。这个区域可被用作基线或是benchmark。

（3）压力区域——应用“轻微下降”的地方。典型的、最大的建议用户负载是压力区域

的开始。

（4）性能拐点——性能开始“急剧下降”的点。

这几个区域实际上明确标识了系统性能最优秀的区间，系统性能开始变坏的区间，以及系统性能出现急剧下降的点。对性能测试来说，找到这些区间和拐点，也就可以找到性能瓶颈产生的地方。

因此，对性能下降曲线分析法来说，主要关注的是性能下降曲线上的各个区间和相应的拐点，通过识别不同的区间和拐点，从而为性能瓶颈识别和性能调优提供依据。

2.1.4 LoadRunner的性能测试过程

图1.7给出了LoadRunner的性能测试过程。LoadRunner将性能测试过程分为计划测试、测试设计、创建VU脚本、创建测试场景、运行测试场景和分析结果6个步骤。

图1.7 LoadRunner的性能测试过程

计划测试阶段主要进行测试需求的收集、典型场景的确定；测试设计阶段主要进行测试用例的设计；创建VU脚本阶段主要根据设计的用例创建脚本；创建测试场景阶段主要进行测试场景的设计和设置，包括监控指标的设定；运行测试场景阶段对已创建的测试场景进行执行，收集相应数据；分析结果阶段主要进行结果分析和报告工作。

LoadRunner提供的这个性能测试过程已经涵盖了性能测试工作的大部分内容，但由于该过程过于紧密地与LoadRunner工具集成，没有兼顾使用其他工具，或是用户自行设计工具的需求，也不能被称为是一个普适性的测试过程。

另外，LoadRunner提供的该性能测试过程并未对计划测试阶段、测试设计阶段的具体行为、方法和目的进行详细描述，因此该方法最多只能被称为“使用LoadRunner进行测试的过程”，而不是一个适应性广泛的性能测试过程。

2.1.5 Segue提供的性能测试过程

图1.8给出了Segue公司Silk Performer提供的性能测试过程。该性能测试过程与Performance Testing Lifecycle描述的一致，是一个不断try-check的过程。

Silk Performer提供的性能测试过程从确定性能基线开始，通过单用户对应用的访问获取性能取值的基线，然后设定可接受的性能目标（响应时间），用不同的并发用户数等重复进行测试。

Segue提供的这种性能测试方法非常适合性能调优和性能优化，通过不断重复的try-check过程，可以逐一找到可能导致性能瓶颈的地方并对其进行优化。

图1.8 Segue Silk Performer提供的性能测试过程

但Segue提供的这个性能测试过程模型存在与LoadRunner的性能测试过程同样的问题，就是过于依赖工具自身，另外，该过程模型缺乏对计划、设计的阶段的明确划分，也没有给出具体的活动和目标。

2.2 性能测试的方法

性能测试的方法很多，常见的比如说的“负载测试”和“压力测试”就是其中一些类型，此外还存在其他的一些类型的性能测试方法。

根据大范围的性能测试的概念的界定，性能测试可包括如下几种方法：

性能测试（Performance Testing）；

负载测试（Load Testing）；

压力测试（Stress Testing）；

配置测试（Configuration Testing）；

并发测试（Concurrency Testing）；

可靠性测试（Reliability Testing）；

失效恢复测试（Failover Testing）；

2.2.1 性能测试（Performance Testing）

性能测试（Performance Testing）方法是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。Performance Testing是一种最常见的测试方法，通俗地说，这种测试方法就是要在特定的运行条件下验证系统的能力状况。

这种方法的特点有：

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

Performance Testing方法包括确定用户场景、给出需要关注的性能指标、测试执行和测试分析这几个步骤，这是一种完全确定了系统运行环境和测试行为的测试方法，其目的只能是依据事先的性能规划，验证系统有没有达到其宣称具有的能力。

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

Performance Testing方法需要首先了解被测西欧他能够的典型场景，所谓的典型场景，就是指具有代表性的用户业务操作，一个典型场景包括操作序列、并发用户数量条件。其次，这种方法需要有确定的性能目标，性能目标的描述基本上是这样的方式：“要求系统在100个并发用户的条件下进行某业务操作，响应时间不超过5秒”。

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

Performance Testing方法的运行环境必须是确定的。软件系统的性能表现与非常多的因素相关，无法根据系统在一个环境上的表现趋推断其在另一个不同环境中的表现，因此对这种验证性的测试，必须要求测试时的环境（硬件设备、

软件环境、网络条件、基础数据等）都已经确定。

2.2.2 负载测试（Load Testing）

负载测试（Load Testing）方法通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。

这种测试放大可以找到系统的处理极限，为系统调优提供数据。在某些情况下，这种方法有时也被称为可量性测试（Scalability Testing）。该方法有这样一些特点：（1）这种性能测试方法的主要目的是找到系统处理能力的极限。

Load Testing方法通过“检测-加压-直到性能指标超过预期”的手段，其主要目的是找到系统处理能力的极限，这个极限一般会用“在给定条件下最多允许120个并发用户访问”或是“在给定条件下最多能够在1小时内处理2100笔业务”这样的描述来体现。而“预期的性能指标”一般会被定义为“响应时间不超过10秒”、“服务器平均CPU利用率低于65%”等指标。

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

Load Testing方法由于涉及到“预定的性能指标”等需要进行比较的数据，也必须在给定的测试环境下进行。另外，Load Testing方法在“加压”的时候，必须选择典型场景，在增加压力时保证这种压力具有业务上的意义。

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

Load Testing方法可以用来了解系统的性能容量（系统在保证一定响应时间的情况下能够允许多少并发用户的访问），或是用来配合性能调优，用这种方法比较调优前后的性能差异。

2.2.3 压力测试（Stress Testing）

压力测试（Stress Testing）方法测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。

Stress Testing方法具有以下特点：

（1）这种性能测试方法的主要目的是检查系统处于压力情况下时，应用的表现。

Stress Testing方法通过增加访问压力（例如，增加并发的用户数量等），使应用系统的资源使用保持在一定的水平，这种测试方法的主要目的是检验此时的应用表现，重点在于有无出错信息产生，系统对应用的响应时间等。

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

一般情况下，会把压力设定为“CPU使用率达到75%以上，内存使用率达到70%以上”这样的描述，在这种情况下测试系统响应时间、系统有无产生错误。除了CPU和内存使用率的设定外，“JVM的可用内存”、“数据库的连接数”、“数据库服务器CPU利用率”等都可以作为压力的依据。

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

用压力测试的方法考察系统的稳定性是出于这样的考虑：“如果一个系统能够在压力环境下稳定运行一段时间，那么这个系统在通常的运行条件下应该可以达到令人满意的稳定程度”。在压力测试中，会考察系统在压力下是否会出现错误，测试中是否有内存等方面的问题。

2.2.4 配置测试（Configuration Testing）

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

这种方法具有以下的特定：

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

此配置测试方法不同于与功能测试并列的那个“配置测试”方法。对整个系统来说，配置测试是针对软件而言，其主要目的是验证软件能否在不同的软硬件环境中正常运行，其主要是功能上的验证。而这里提到的配置测试方法，是在性能测试领域内的配置测试方法，它的主要目的是了解各种因素对系统性能的影响程度，从而判断出对性能影响最大的因素。

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

Configuration Testing方法需要在确定的环境和操作步骤、确定的压力条件下进行。该方法在每次执行测试时更换、扩充硬件设备，调整网络环境，调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统性能的影响，找出影响最大的因素。

-需求分析方法论

需求分析方法论原则上，需求分析阶段IT中心应尊重需求方的项目管理和项目分析能力；在具体的任务开展上，以不干扰需求方的自主权为主，除非在项目过程中发现需求方的项目管理以及项目分析能力存在很大的差距和不足。为了保证项目的成功，IT中心必须加强项目管理和项目分析工作，在具体的操作上可以坚持吸收、同化、贯彻的方法和手段。其中，需求分析是一个项目的开端，也是项目建设的基石。在以往的信息化建设失败的案例中，80％是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一，就是对需求分析的把握程度。而项目的整体风险往往表现在需求分析不明确、业务流程不合理，用户不习惯或不愿意去用应用管理软件。作为IT中心，必须提醒需求方重视需求分析的重要性，采用必要的手段和方法来进行需求调研，同时IT 中心也应深入具体的需求调研中去。只有这样才能切切实实地把握用户的需求和方向，才能在将来的功能界定、实施上有发言权。一、如何进行需求分析需求分析不象侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S={D1，D2，D3，…Dn} 问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di={P1，P2，P3，…Pm} 问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj={F1，F2，F3，…Fk} 需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术人员都合适。在写需求说明书时应该注意两个问题： 1、最好为每个需求注释“为什么”，这样可让双方（IT中心、需求方）了解需求的本质，以便选用最合适的技术来实现此需求。 2、需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。二、重点监控需求分析由于项目的特殊性和行业覆盖的广阔性，以及需求分析的高风险性，软件需求分析的重要性是不言而喻的，同时需求分析又的的确确难做。其原因基本是由于以下情况造成的。 1、用户说不清楚需求有些用户对需求只有朦胧的感觉，当然说不清楚具体的需求。例如总部各部门及各地的很多店铺在进行应用系统以及网络建设时，需求方的办公人员大多缺乏IT系统建设方面的专家和知识。此时，用户就会要求IT中心系统分析人员替他们设想需求。项目的需求存在一定的主观性，为项目未来建设埋下了潜在的风险。 2、需求自身经常变动根据以往的历史经验，随着用户对信息化建设的认识和自己业务水平的提高，他们会在不同的阶段和时期对项目的需求提出新的要求和需求变更。事实上，历史上没有一个软件的需求改动少于三次的！所以必须接受“需求会变动”这个事实，在进行需求分析时要懂得防患于未然，尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求，以便在系统选型及实施时，将软件的核心建筑在稳定的需求上，同时留出变更空间。IT中心在需求分析的功能界定上担任一个中间、公平、公正的角色，所以也必须积极参与到需求分析的准备中来，以便协助需求方来界定“做什么”、“不做什么”的系统功能界限。 3、IT中心分析人员或用户理解有误系统分析人员不可能都是全才，更不可能是行业方面的专家。用户表达的需求，不同的分析人员可能

阳极氧化膜性能测试及国家标准

阳极氧化膜性能测试方法 1. 光泽 1.1 目视法目视检测法：包含对颜色、色差、表面光泽和表面表面缺陷的检测。其观察距离一般是0.5m；（GB/T14952.3-1994） 1.2 光泽仪由于光泽目视时无法量化，所以采用了相应的仪器：光泽仪（目前的产品由于形状所限制，无法采用）；（GB/T5237.4-2000）2. 色泽 2.1 目视法在自然散射光或标准光源D65用目视法检测，视力达到1.0，与产品垂直或呈45°角；（GB/T14952.3-1994） 2.2 色差仪目视法受到产品、环境和人的因素影响，判断的偏差较大，所以一般采用色差仪，色差仪一般采用D65标准照明体，测量400~700nm的可见光波；（ISO7724.1~3-1984、ISO/TR8125-1984和GB/T11186.1~3-1989） 3. 膜厚度（现有一个膜厚计） 3.1 显微镜测量横断面厚度采用的方法是将产品截断，用金相显微镜测试，影响的因素有表面粗糙度、横断面的斜度、覆盖层变形和机加工缺陷；（GB/T6462-1986和ISO1463-1983） 3.2 分光束显微镜测量法仅限于银色阳极氧化膜的测量；（ISO2128-1976、GB/T8014.3-200X） 3.3 质量损失法适用于膜厚大于10μm（GB/T8014.2-200X、ISO2016-1982） 3.4 涡流法（现有的膜厚计即为此种）采用涡流法有快速、方便、非破坏性，因此应用很广，原理是采用涡电流，并要求金属非磁性且表面不导电，当侧头与试样接触时，测头产生高频电流磁场，在基体金属中会感应出涡电流，此涡电流产生的附加电磁场会改变测头参数，而（GB/T4957-1994和ISO2360-1982）测头参数的改变取决于与氧化膜相关的测头到基体的距离，然后经芯片分析得到数值。 4. 阳极氧化膜封孔质量 4.1 指印试验用橡胶“手指”模拟人的手指进行试验，“手指”放在试样的待测表面上5min，然后移去并用丙酮擦干净检查，有指印为不合格；（BS1615-1945） 4.2 染色斑点试验适用于检验在大气曝晒与腐蚀的环境下使用的氧化膜，特别适用于对耐污染性有要求得氧化膜：将产品在25mL/L的硫酸和10g/L的氟化钾溶液中浸泡1min，擦干，再在23℃、PH=5±0.5的染色溶液中浸泡1min。0-2级合格，5级最差。具体操作详见（ISO2143-1981） 4.3酸化亚硫酸钠试验先将产品放在18~22℃的1：1硝酸中浸泡10min，擦干，称重，再在90~92℃酸化亚硫酸钠溶液（10g/L，PH=2.5）中浸泡20min，擦干，称重，计算质量损失来衡量封孔质量；（ISO2932-1981、GB/T14592.2-1994） 4.4 乙酸-乙酸钠试验先将产品放在18~22℃的1：1硝酸中浸泡10min，擦干，称重，再在沸腾的乙酸-乙酸钠溶液中（乙酸的浓度为0.5g/L，乙酸浓度为100mL/L，）浸泡15min，擦干，称重，计算质量损失来衡量封孔质量；（ISO2932-1981、GB/T14592.2-1994）； 4.5磷-铬试验适用于暴露在大气中以装饰和保护为目的、偏重抗污染的氧化膜，方法是擦干产品，称重，在38±1℃，20g/L的三氧化铬和35mL/L的磷酸混合溶液中浸泡15min，干燥，称重，失重为30mg/dm3为合格，（ISO3210-1983，GB/T8753.1~.2-200X，EN12373.7-1999）； 4.6导纳试验将产品擦干，导纳仪的一个电极接到产品上，再用橡皮圈做成的电解池粘到产品的测试部位，在电解池中注入35g/L的氯化钠溶液，并将另一个电极插入电解池，读取数据，国际上以低于400μS/t（t为膜厚）（ISO2931-1981，GB/T8753.3-220X）5. 耐腐蚀性 5.1铜加速乙酸盐雾腐蚀试验（CASS）在专用的盐雾箱进行，在50±2℃，PH=3.0-3.1条件下，用压缩空气将氯化钠50±5g/L、乙酸、氯化铜0.26±0.02g/L溶液雾化，然后沉降在产品的表面；（GB/T5237.2~.5-2000、GB/T10125-1997、ISO9227-1990） 5.2含SO2潮湿大气腐蚀试验先将产品在外观面用刀划深至基体的交叉线，再放入含有2L SO2、2L CO2的300±10L的气密箱中，温度控制在40±3℃。

培训需求分析的方法和工具

培训需求分析的方法和工具培训需求分析是企业培训的出发点，也是最重要的一步工作。如果需求分析不准确，就会让接下来的培训偏离轨道，做无用功，浪费企业的人力、物力和财力，却收不到应有的效果。企业要进行有效的需求分析，就必须采取合适方法和工具，本文全面介绍了通常情况下培训需求分析使用的方法以及对应的工具。一、需求分析的方法和工具 1.1 调研问卷法调研问卷法是最普遍也最有效的收集资料和数据的方法之一。一般由培训部门设计一系列培训需求相关问题，以书面问卷的形式发放给培训对象，待培训对象填写之后再收回进行分析，获取培训需求的信息和数据。调研问卷法进行培训需求分析，可以遵循以下五个步骤，见表1：在设计调研问卷的问题时，应该注意下几个问题： 1、问题尽量简短，并注意使用简单的、固定用法的术语，避免使用读者不了解或者容易引起歧义的名词； 2、一个问题只涉及一件事，避免“结构复杂”的问句； 3、题目设计要简单，不要使作答者作计算或逻辑推理； 4、避免出现诱导答案的问题，保证作答者完全陈述自己观点。

备注：填表时在对应的内容下面用“√”标明。 1.2 访谈法访谈法也是数据收集的一种重要方法。它是指为了得到培训需求的数据和信息，与访谈对象进行面对面交流的活动过程。这个过程不只是收集硬性数据，比如事实、数据等，包括印象、观点、判断等信息。访谈法可以遵循以下几个步骤进行，见表3：

1.3现场取样法现场取样法一般较多使用于服务性行业的培训需求调查（如饭店、卖场等），是通过选取培训对象现场实际工作的部分片段进行分析，以确定培训需求的一种分析方法。现场取样法主要包括两种形式：拍摄和取样。拍摄是指在培训对象的工作环境中安装监控录影机、摄像机等拍摄设备，对培训对象的现场工作过程进行实际拍摄，事后通过录影带进行观察分析，得出培训需求结论。表5为拍摄样板的示例。

性能测试方案讲解

1.引言说明测试方案中所涉及内容的简单介绍，包含：编写目的，项目背景、参考文档，以及预期的读者等。 1.1.编写目的本文档描述××系统性能测试的范围、方法、资源、进度，该文档的目的主要有： 1.明确测试目的范围。 2.明确测试范围和目标。 3.明确测试环境需求，包括：测试需要的软、硬件环境以及测试人力需求。 4.确定测试方案，测试的方法和步骤。 5.确定测试需要输出的结果和结果表现形式。 6.分析测试的风险，寻找规避办法。 1.2.项目简介简要描述与测试项目相关的一些背景资料，如被测系统简介，项目上线计划等。 1.3.参考文档说明文档编写过程参考引用的资料信息。 2.测试目的、范围与目标 2.1.测试目的

根据项目总体计划明确项目测试目的。常见的测试目的如下（依据项目的实际情况修改。本次性能测试的主要目的在于： ?测试已完成系统的综合性能表现，检验交易或系统的处理能力是否满足系统运行的性能要求； ?发现交易中存在的性能瓶颈，并对性能瓶颈进行修改； ?模拟发生概率较高的单点故障，对系统得可靠性进行验证； ?验证系统的生产环境运行参数设置是否合理，或确定该参数； ?获得不同备选方案的性能表现，为方案选择提供性能数据支持。 2.2.测试功能范围说明本项目需要进行测试的待测系统功能范围，列出被测对象的测试重要性及优先级等，提供一份简要列表。对于交易类功能要细化到每一个交易码；对于页面类功能要细化到每一个发起页面。下面表格供参考，非强制使用。如果测试目的为方案验证，需要文字列出需要验证的方案项。明确列出说明本次测试需要关注的测试指标的定义及范围，不需要关注的测试指标也应列出。下面的内容供参考。本次性能测试需要获得的性能指标如下所列：

PC性能测试方法

性能测试 (2) 1 概述 (2) 1.1 目的 (2) 1.2 背景 (2) 1.3 范围 (2) 1.4引用文档 (2) 2 测试概要 (2) 2.1 测试环境 (2) 2.2 测试环境（也可按表格方式简述所要测试的部件参数）............... 错误！未定义书签。 2.3 人力资源 (6) 2.4 测试环境 (6) 3 测试内容及方法 (6) 3.1 测试需求/目标 (6) 3.2 测试内容 (6) 3.3 测试工具 (6) 4 测试结果及分析 (7) 4.1 Memory性能评估 (7) 4.2 硬盘、阵列存储性能 (8) 4.3 进程性能采样图 (11) 4.4 处理器性能评估 (14) 服务器性能综合分析： (16) 分析结果 (16) 建议： (16)

性能测试 1 概述 1.1 目的本测试报告为医院信息系统的性能测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求，查找系统存在的问题，提出解决方案。 1.2 背景医院信息系统，XX科技有限公司目前正在进行性能测试。考虑到用户数量及数据的增多给服务器造成压力不可估计，因此计划对XX网站负载性能测试，在系统配置不变的情况下，在一定时间内，在业务高峰先期，服务器在高负载情况下的性能行为表现，便于对系统环境进行正确的分析及评估。 1.3 范围本次测试主要是对在用医院信息系统的性能测试。 1.4引用文档下表列出了执行测试过程所引用的文档： 2 测试概要 2.1 测试环境下图描述测试该项目所测试的硬件环境：（使用LAVALYS工具，计算机－系统摘要－全部复制，粘贴所得）项目数据

阳极氧化膜性能测试与国家实用标准

阳极氧化膜性能测试方法 1.光泽 1.1 目视法目视检测法：包含对颜色、色差、表面光泽和表面表面缺陷的检测。其观察距离一般是0.5m ；（ GB/T14952.3-1994 ） 1.2 光泽仪由于光泽目视时无法量化，所以采用了相应的仪器：光泽仪（目前的产品由于形状所限制，无法采用）；（GB/T5237.4-2000） 2.色泽 2.1 目视法在自然散射光或标准光源 D 65用目视法检测，视力达到 1.0 ，与产品垂直或呈45°角；（ GB/T14952.3-1994 ） 2.2色差仪目视法受到产品、环境和人的因素影响，判断的偏差较大，所以一般采用色差仪，色差仪一般采用D65标准照明体，测量400~700nm 的可见光波；（ ISO7724.1~3-1984 、 ISO/TR8125-1984 和 GB/T11186.1~3-1989 ） 3.膜厚度（现有一个膜厚计） 3.1 显微镜测量横断面厚度采用的方法是将产品截断，用金相显微镜测试，影响的因素有表面粗糙度、横断面的斜度、覆盖层变形和机加工缺陷；（GB/T6462-1986 和 ISO1463-1983 ） 3.2 分光束显微镜测量法仅限于银色阳极氧化膜的测量；（ ISO2128-1976 、 GB/T8014.3-200X ） 3.3 质量损失法适用于膜厚大于10μm（ GB/T8014.2-200X 、 ISO2016-1982 ） 3.4 涡流法（现有的膜厚计即为此种）采用涡流法有快速、方便、非破坏性，因此应用很广，原理是采用涡电流，并要求金属非磁性且表面不导电，当侧头与试样接触时，测头产生高频电流磁场，在基体金属中会感应出涡电流，此涡电流产生的附加电磁场会改变测头参数，而测头参数的改变取决于与氧化膜相关的测头到基体的距离，然后经芯片分析得到数值。（ GB/T4957-1994 和 ISO2360-1982 ）4.阳极氧化膜封孔质量 4.1 指印试验用橡胶“手指”模拟人的手指进行试验，“手指”放在试样的待测表面上 5min ，然后移去并用丙酮擦干净检查，有指印为不合格；（ BS1615-1945 ） 4.2 染色斑点试验适用于检验在大气曝晒与腐蚀的环境下使用的氧化膜，特别适用于对耐污染性有要求得氧化膜：将产品在25mL/L 的硫酸和 10g/L 的氟化钾溶液中浸泡1min ，擦干，再在23℃、 PH=5± 0.5 的染色溶液中浸泡1min 。 0-2 级合格， 5 级最差。具体操作详见（ ISO2143-1981） 4.3 酸化亚硫酸钠试验先将产品放在18~22 ℃的 1：1硝酸中浸泡 10min ，擦干，称重，再在 90~92 ℃酸化亚硫酸钠溶液（10g/L ，PH=2.5 ）中浸泡 20min ，擦干，称重，计算质量损失来衡量封孔质量；（ ISO2932-1981 、 GB/T14592.2-1994） 4.4 乙酸 -乙酸钠试验先将产品放在18~22 ℃的 1： 1 硝酸中浸泡 10min ，擦干，称重，再在沸腾的乙酸-乙酸钠溶液中（乙酸的浓度为0.5g/L ，乙酸浓度为100mL/L ，）浸泡 15min ，擦干，称重，计算质量损失来衡量封孔质量；（ ISO2932-1981、GB/T14592.2-1994 ）； 4.5 磷 -铬试验适用于暴露在大气中以装饰和保护为目的、偏重抗污染的氧化膜，方法是擦干产品，称重，在38±1℃， 20g/L 的三氧化铬和 35mL/L的磷酸混合溶液中浸泡15min ，干燥，称重，失重为 30mg/dm 3为合格，（ ISO3210-1983，GB/T8753.1~.2-200X， EN12373.7-1999 ）； 4.6 导纳试验将产品擦干，导纳仪的一个电极接到产品上，再用橡皮圈做成的电解池粘到产品的测试部位，在电解池中注入35g/L的氯化钠溶液，并将另一个电极插入电解池，读取数据，国际上以低于 400μS/t（ t 为膜厚）（ ISO2931-1981 ，GB/T8753.3-220X） 5.耐腐蚀性

频性能测试性能测试方法

关于关于用电信息采集微功率无线通信单元用电信息采集微功率无线通信单元用电信息采集微功率无线通信单元射射频性能性能测试测试测试方法方法方法的说明的说明本文档参照了Q/GDW 1374.3《电力用户用电信息采集系统技术规范第3部分：通信单元技术规范》、Q/GDW 1376.2《电力用户用电信息采集系统通信协议第2部分：集中器本地通信模块接口协议》、DL/6452007《多功能电能表通信协议》、Q/GDW11016-2013《电力用户用电信息采集系统通信协议第4部分：基于微功率无线通信的数据传输协议》，进一步明确了微功率无线通信单元的射频测试流程，稳定精确地完成发射性能测试（发射功率、数传频偏、杂散辐射），接收性能测试（接收灵敏度、可接受中心频率偏移），指导相关产品的设计、开发和测试工作。1．样品类型微功率无线通信主节点：一型集中器本地通信单元；微功率无线通信从节点：一型采集器通信单元、二型采集器、三相电能表通信单元、单相电能表通信单元。2．测试要求 1）发射性能测试中,各送检通信单元在正常的工作模式下，其串口应能接收下文所示的命令帧并正确返回确认帧，进而空口持续稳定发送码流； 2）接收性能测试中,各送检通信单元在正常的工作模

式下，其空口应能接收下文所示的空中测试指令报文，并能将空中报文的数据载荷域通过串口发给上位机。 3）发射性能测试中,空口输出的M4码流不需要做白化,但需添加物理层帧分隔符0x98，0xF3； 4）串口波特率应自适应，一型集中器本地通信单元默认为9600bit/s，一型采集器通信单元、二型采集器、三相智能电能表通信单元、单相智能电能表通信单元默认为2400bit/s；3.发射性能测试3.13.1．．测试测试流程流程微功率无线通信单元发射性能测试流程为：1）通信单元上电； 2）通信单元关联表地址(一型集中器本地通信单元及二型采集器无此步骤)； 3）上位机通过串口向通信单元发送命令帧；4）通信单元通过串口向上位机回复确认帧；5）通信单元空口在规定时间、规定频点连续发送规定码流； 6）使用无线通信综合测试仪进行发射功率测试；7）使用无线通信综合测试仪进行杂散辐射测试；8）使用无线通信综合测试仪进行数传频偏测试。3.23.2．帧格式．帧格式

纺织品燃烧性能测试方法大全

纺织品燃烧性能测试方法大全关键词：燃烧实验法;限氧指数法;表面燃烧实验法;发烟性试验法;闪点和自燃点测定及点着温度测定;阻燃整理热分析;锥形量热计;锥形量热计 1、燃烧实验法燃烧实验法，主要用来测定试样的燃烧广度(炭化面积和损毁长度)、续燃时间和阴燃时间。一定尺寸的试样，在规定的燃烧箱里用规定的火源点燃12s，除去火源后测定试样的续燃时间和阴燃时间。阴燃停止后，按规定的方法测出损毁长度。根据试样与火焰的相对位置，可以分为垂直法、倾斜法和水平法。垂直法是目前最为普遍的测定方法。这类实验比45°方向、水平方向燃烧更为剧烈。垂直燃烧实验又分垂直损毁长度法，垂直向火焰蔓延性能测定法、垂直向试样易点燃性测定法和表面燃烧性能测定法。GB/T5456-1997规定了纺织品燃烧性能垂直方向试样火焰蔓延性能的测定，该法用规定的点火器所产生的规定点火火焰，按规定点火时间对垂直向纺织试样点火，测定火焰在试样上蔓延至标记线(规定距离)所用的时间(以秒计)。亦可同时观察、测定和记录试样的其他有关火焰蔓延的性能。GB8746-88规定了纺织织物燃烧性能垂直向试样易点燃性的测定，该法用规定点火器产生的规定火焰，对垂直向纺织试样点火，测量织物点燃所需要的时间。GB8745-88规定了纺织织物表面燃烧性能的测定，在规定的试验条件下，在接近项部处点燃支承于垂直板上的干燥试样的起毛表面，测定火焰在织物表面向下蔓延至标记线的时间。垂直法可用于测定服装织物、装饰织物、帐篷织物等的阻燃性能;倾斜法适用于飞机内装饰用布;水平法适用于地毯之类的铺垫织物。 2、限氧指数法限氧指数法是目前广泛使用的纺织品燃烧性能测试方法，它是指在规定的实验条件下，在氧、氮混合气体中，材料刚好能保持燃烧状态所需最低氧浓度，用LOI表示，LOI为氧所占混合气体的体积百分数。GB/T5454-1997规定了纺织品燃烧性能试验氧指数法，将试样夹于试样夹上垂直于燃烧筒内，在向上流动的氧氮气流中，点燃试样上端，观察其燃烧特性，并与规定的极限值比较其续燃时间或损毁长度。通过在不同氧浓度中一系列试样的试验，可以测得维持燃烧时氧气百分含量表示的最低氧浓度值，受试试样中要有40%-60%超过规定的续燃和阴燃时间或损毁长度。

《Web项目测试实战》性能测试需求分析章节样章

5.1.2性能测试需求提取复习了一些常见的理论概念后，我们开始性能测试需求的提取。这个过程是非常重要的，往往测试失败，就是因为在这个过程中不知道如何得到确切的性能指标，而导致测试无法正常开展。性能测试需求提取一般的流程如图5- 1所示。图5- 1性能测试需求提取流程分析提取指标在用户需求规格说明书中，会给出系统的功能、界面与性能的要求。规范的需求规格说明书都会给出明确的性能指标，比如单位时间内访问量要达到多少、业务响应时间不超过多少、业务成功率不低于多少、硬件资源耗用要在一个合理的范围中，这些指标都会以可量化的数据进行说明。如果，实际项目并没有这些正规的文档时，项目经理部署测试任务给测试组长时，一般就会说明是否要对项目的哪些业务模块进行性能测试，以及测试的要求是什么的。最麻烦的就是项目经理或者客户要求给出一个测试部门认为可以的数据，这样非常难做的。可是“甲方”往往都是提要求的，“乙方”只能“无条件”接受！表5- 1需求规格说明书中的性能要求表5- 1给出的指标非常明确，在测试过程中，我们只需收集用户登录模块的响应时间、登录成功率、并发数、CPU使用率、内存使用率的数据，然后与表5- 1的指标进行比较即可，通过的，就认为达到了客户要求的性能，未达到就分析原因，并给出测试报告及解决建议。大多数是没有明确的需求，需要我们自己根据各种资料、使用各种方法去采集测试指标。以OA系统为例，假设《OA系统需求规格说明书》中并未指明系统的性能测试要求，需要测试工程师自己分析被测系统及采集性能衡量指标。分析OA系统的结构，所有功能中仅有考勤模块可能是被测系统最终用户经常使用的业务点，那么我们的重点应该在放在该模块上。一般我们可以从下面三个方面来确定性能测试点：第一、用户常用的功能。常用的功能一旦性能无法满足，比如登录功能，从输入用户名与密码点击登录按钮到显示成功登录信息，花了5分钟，这样的速度是人无法忍受的。而对于用户不常用的，比如年度报表汇总功能，三个季度甚至是一年才使用，等个10分钟也是正常的，这些是跟用户的主观感受相关的，得根据实际情况区分。

氧化膜连续性测试

阳极氧化膜连续性测试方法阳极氧化膜的连续性测试（大孔性）（本测试用于评定铝合金阳极氧化膜连续性）要求：将20克的硫酸铜CuSO4溶解到1升去离子水中，并搅拌均匀。往此溶液中添加20cc的盐酸溶液，并继续搅拌均匀。将此混合溶液滴到产品表面任意四个位置。如果有必要，可以用纸巾将产品表面清除干净，以确保表面有污点存在。暴露五分钟后，如果产品表面没有暗点，则可判定产品可以通过氧化膜连续性测试。本试验至少测3件样本（注意：在产品封孔性及连续性测试时，只要溶液滴在不同位置上，即封孔性及连续性测试可以在同一件产品上做测试）。求助:黑色不能过,不锈钢色可以过阳极氧化膜性能测试方法 1.光泽 1.1目视法目视检测法：包含对颜色、色差、表面光泽和表面表面缺陷的检测。其观察距离一般是 0.5m；（GB/T14952.3-1994） 1.2光泽仪由于光泽目视时无法量化，所以采用了相应的仪器：光泽仪（目前的产品由于形状所限制，无法采用）；（GB/T5237.4-2000） 2.色泽 2.1目视法在自然散射光或标准光源D65用目视法检测，视力达到1.0，与产品垂直或呈45°角；（GB/T14952.3-1994） 2.2色差仪目视法受到产品、环境和人的因素影响，判断的偏差较大，所以一般采用色差仪，色差仪一般采用D65标准照明体，测量400~700nm的可见光波；（ISO7724.1~3-1984、ISO/TR8125-1984和GB/T11186.1~3-1989） 3.膜厚度（现有一个膜厚计） 3.1显微镜测量横断面厚度采用的方法是将产品截断，用金相显微镜测试，影响的因素有表面粗糙度、横断面的斜度、覆盖层变形和机加工缺陷；（GB/T6462-1986和ISO1463-1983） 3.2分光束显微镜测量法仅限于银色阳极氧化膜的测量；（ISO2128-1976、GB/T8014.3-200X） 3.3质量损失法适用于膜厚大于10μm（GB/T8014.2-200X、ISO2016-1982） 3.4涡流法（现有的膜厚计即为此种）采用涡流法有快速、方便、非破坏性，因此应用很广，原理是采用涡电流，并要求金属非磁性且表面不导电，当侧头与试样接触时，测头产生高频电流磁场，在基体金属中会感应出涡电流，此涡电流产生的附加电磁场会改变测头参数，而测头参数的改变取决于与氧化膜相关的测头到基体的距离，然后经芯片分析得到数值。（GB/T4957-1994和ISO2360-1982） 4.阳极氧化膜封孔质量

综合性能检测安全技术操作规程示范文本

综合性能检测安全技术操作规程示范文本 In The Actual Work Production Management, In Order To Ensure The Smooth Progress Of The Process, And Consider The Relationship Between Each Link, The Specific Requirements Of Each Link To Achieve Risk Control And Planning 某某管理中心 XX年XX月

综合性能检测安全技术操作规程示范文本使用指引：此操作规程资料应用在实际工作生产管理中为了保障过程顺利推进，同时考虑各个环节之间的关系，每个环节实现的具体要求而进行的风险控制与规划，并将危害降低到最小，文档经过下载可进行自定义修改，请根据实际需求进行调整与使用。 1 、严格遵守学院制定实训“十要”、“十不准”规章制度。 2 、操作人员应详细阅读有关资料，对各种使用的设备应掌握操作方法，熟悉工作原理，测试中，谨慎、认真、小心，防止误操作损坏设备。 3 、实训前，听从老师讲解及演示，熟悉项目内容范围，爱护设备仪器，保证完好无损。 4 、检测时，集中精力操作，严守规程，仔细观察仪表变化，发生异常，立即停机切断电源，待排除故障后再进行操作。 5 、发动机或车辆在指导教师启动检测时，人身不可

靠近旋转运动部位，注意“油、水、电、气”防止泄漏。 6 、停机后，发动机要关闭点火开关，各种设备要切断电源。请在此位置输入品牌名/标语/slogan Please Enter The Brand Name / Slogan / Slogan In This Position, Such As Foonsion

塑料薄膜的性能测试方法

塑料薄膜的性能测试方法塑料薄膜、复合膜具有不同的物理、机械、耐热以及卫生性能。当塑料薄膜应用为包装材料时，需要根据包装物以及应用环境的不同，选择合适的材料来使用。如何评价包装材料的性能呢？国内外测试方法有很多。我们应优先选择那些科学、简便、测量误差小的方法，优先选择ISO、ASTM、以及我国国家标准、行业标准，如BB／T 标准、QB／T标准、HB／T标准等等。 GBT 2918-1998 《塑料试样状态调节和试验的标准环境》等同国际标准ISO 291:1997《塑料一状态调节和试验的标准环境》，提出了各种塑料及各类试样在相当于实验室平均环境条件的恒定环境条件下进行状态调节和试验的规范，并给出标准实验环境定义，是大部分塑料性能测试方法引用的标准。 1．规格、外观测试方法塑料薄膜作为包装材料，它的尺寸规格要满足内装物的需要；外观直接影响商品形象；其厚度则又是影响机械性能、阻隔性的因素之一，需要在质量和成本上找到最优化的指标。因此这些指标就会在每个产品标准的要求中作出规定，相应的要求检测方法一般有： 1.1厚度测定塑料一般具有一定的弹性，因此其厚度测定一般需要施加一定的接触负荷。 GB／T6672－2001《塑料薄膜和薄片厚度测定机械测量法》等同采用ISO4593：1993《塑料－薄膜和薄片－厚度测定－机械

测量法》。规定了机械法测量法即接触法测量塑料薄膜或薄片样品厚度的试验方法，但不适用于压花材料的测试。 1.2.长度、宽度塑料材料的尺寸受环境温度的影响较大，解卷时的操作拉力也会造成材料的尺寸变化。测量器具的精度不同，也会造成测量结果的差异。因此在测量中必须注意每个细节，以求测量的结果接近真值。 GB／T 6673－2001《塑料薄膜与片材长度和宽度的测定》非等效采用国际标准ISO 4592：1992《塑料－薄膜和薄片－长度和宽度的测定》。该标准规定了卷材和片材的长度和宽度的基准测量方法。标准中规定了卷材在测量前应先将卷材以最小的拉力打开，以不超过5m的长度层层相叠不超过20层作为被测试样，并在这种状态下保持一定的时间，待尺寸稳定后在进行测量。 1.33.外观塑料薄膜的外观检验一般采取在自然光下目测。外观缺陷在GB／T 2035 《塑料术语及其定义》中有所规定。 2．物理机械性能测试方法 2.1拉伸性能塑料的拉伸性能试验包括拉伸强度、拉伸断裂应力、拉伸屈服应力、断裂伸长率等试验。采用拉力试验机进行测试。 GB／T 1040－1992 《塑料拉伸性能试验方法》一般适用于厚度大于1mm的材料热塑性、热固性材料，这些材料包括填充和纤维增强的塑料材料以及塑料制品。

软件需求分析方法

需求分析方法一需求分析概括需求分析应该先了解宏观的问题，再了解细节的问题。一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。 S＝｛D1，D2，D，…Dn｝问题域Di由若干问题（记为P）组成，每个问题对应于子系统中的一个软构件。 Di＝｛P1，P2，P3，…Pn｝问题Pi有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。 Pj＝｛F1，F2，F3，…Fk｝需求说明书应该对于那些只想了解宏观需求的领导和需要了解细节的技术员都合适。在写需求说明书时，应该注意两个问题： 1.最好为每个需求注释“为什么”，这样可以让程序员了解需求的本质，以便选用最合适的技术来实现此需求 2.需求说明不能有”二义性”，更不能前后矛盾。如果有二义性或前后矛盾，即要重新分析此需求。二需求分析方法论第一阶段：“访谈式”

第一阶段是和具体用户方的领导层、业务层人员的访谈沟通，主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等等具体情况、客观的信息。建立起良好的沟通渠道和方式。针对具体的职能部门以及各委办局，最好能指定本次项目的接口人。实现手段：访谈、调查表格输出成果：调查报告、业务流程报告第二阶段：“诱导式” 结合第一阶段的基本信息，做出简单的用户流程页面，同时结合以往的项目经验对用户采用诱导式，启发式的调研方法和手段，和用户一起探讨业务流程设计的合理性、准确性、习惯性。用户可以操作简单演示的DEMO，感受整个业务流程的设计合理性、准确性等等问题，以及提出改进意见和方法。实现手段：诱导（拜访）、原型演示输出成果：调研分析报告、原型反馈报告、业务流程报告第三阶段：“确认式” 此阶段在上述两个阶段成果的基础上，进行具体的流程细化、数据项的确认阶段。这个阶段承建方必须提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。通过审查，提出反馈意见，并对已经可接受的报告、文档签字确认。实现手段：拜访（回顾、确认），提交业务流程报告、数据项表；原型演示系统输出成果：需求分析报告、数据项、业务流程报告、原型系统反馈意见（后三者可以统一归到需求分析报告中）

软件性能测试方案

性能测试方案

目录前言 (3) 1第一章系统性能测试概述 (3) 1.1 被测系统定义 (3) 1.1.1 功能简介 (4) 1.1.2 性能测试指标 (4) 1.2 系统结构及流程 (4) 1.2.1 系统总体结构 (4) 1.2.2 功能模块描述 (4) 1.2.3 业务流程 (5) 1.2.4 系统的关键点描述（KP） (5) 1.3 性能测试环境 (5) 2 第二章性能测试 (6) 2.1 压力测试 (6) 2.1.1 压力测试概述 (7) 2.1.2 测试目的 (7) 2.1.3 测试方法及测试用例 (7) 2.1.4 测试指标及期望 (8) 2.1.5 测试数据准备 (9) 2.1.6 运行状况记录 (99) 3第三章测试过程及结果描述 (90) 3.1 测试描述 ................................................................................................. 错误！未定义书签。 3.2 测试场景 ................................................................................................. 错误！未定义书签。 3.3 测试结果 ................................................................................................. 错误！未定义书签。 4 第四章测试报告 (11)

膜性能测试

中空纤维超滤膜性能测试一、实验目的 1.掌握超滤膜组件封装分离的实验操作技术； 2.掌握中空纤维膜渗透通量和分离效率的测试方法。二、实验原理膜的性能包括物理化学性能和分离透过性能。膜的物理化学性能是指承压性、耐温性、耐酸碱性、抗氧化性、耐生物与化学侵蚀性、机械强度、膜的厚度、含水量、毒性、生物相容性、亲水性和疏水性、孔隙率、电性能、膜的形态结构以及膜的平均孔径等。膜的分离透过特性主要是指渗透通量和分离效率。超滤膜分离基本原理是用压力差作为推动力，利用膜孔的渗透和截留性质，使不同的组分实现分离，因此要达到良好的分离目的，要求被分离的组分间相对分子质量至少要相差一个数量级以上。超滤膜分离的工作效率以渗透通量和分离效率作为衡量指标。膜通量计算如下式： t S V J ?= 式中，J 为膜的渗透通量（通常测试纯水通量）（L/m 2h ，0.1 MPa ）； S 为中空纤维膜的有效面积（通常指外表面积，内压法为内表面积）（m 2）； V 为透过液体的体积（L ）；t 为时间（h ）。组分截留率的定义如下： %100C C 1R 0 1 ?- = 式中—R 为截留率； C 0为原溶液浓度； C 1为透过液浓度。将中空纤维膜封成膜组件后，进行中空纤维膜的通量与截留率的测试。进料液可以从膜的内表面透过膜，也可以通过膜的外表面透过膜，因此测试水通量和截留率的方式分为：内压法和外压法，如图1所示。另一方面，根据料液在膜组件中流动方式的不同，测试水通量和截留率的方式又可以分为：错流法和死端法。综上所述，测试中空纤维膜的水通量和截留率的方式可以分为：内压错流法、外压错流法、内压死端法和外压死端法，如图2所示。本实验中测试中空纤维膜的通量和截留率用的都是内压错流过滤，如图2 (a)所示。图1内压法和外压法示意图

需求分析方法主要步骤

1.1主要步骤遵循科学的需求分析步骤可以使需求分析工作更高效。需求分析的一般步骤如图2-3所示。需求涉及的方面有很多。在功能方面，需求包括系统要做什么，相对于原系统目标系统需要进行哪些修改，目标用户有哪些，以及不同用户需要通过系统完成何种操作等。在性能方面，需求包括用户对于系统执行速度、响应时间、吞吐量和并发度等指标的要求。在运行环境方面，需求包括目标系统对于网络设置、硬件设备、温度和湿度等周围环境的要求，以及对操作系统、数据库和浏览器等软件配置的要求。在界面方面，需求涉及数据的输入/输出格式的限制及方式、数据的存储介质和显示器的分辨率要求等问题。 1.1.1获取需求，识别问题开发人员从功能、性能、界面和运行环境等多个方面识别目标系统要解决哪些问题，要满足哪些限制条件，这个过程就是对需求的获取。开发人员通过调查研究，要理解当前系统的工作模型和用户对新系统的设想与要求。此外，在需求的获取时，还要明确用户对系统的安全性、可移植性和容错能力等其他要求。比如，多长时间需要对系统做一次备份，系统对运行的操作系统平台有何要求，发生错误后重启系统允许的最长时间是多少等。

遗漏需求是最难修订的需求错误。 --RobertL.Glass 获取需求是需求分析的基础。为了能有效地获取需求，开发人员应该采取科学的需求获取方法。在实践中，获取需求的方法有很多种，比如，问卷调查、访谈、实地操作、建立原型和研究资料等。问卷调查法是采用调查问卷的形式来进行需求分析的一种方法。通过对用户填写的调查问卷进行汇总、统计和分析，开发人员便可以得到一些有用的信息。采用这种方法时，调查问卷的设计很重要。一般在设计调查问卷时，要合理地控制开放式问题和封闭式问题的比例。开放式问题的回答不受限制，自由灵活，能够激发用户的思维，使他们能尽可能地阐述自己的真实想法。但是，对开放式问题进行汇总和分析的工作会比较复杂。封闭式问题的答案是预先设定的，用户从若干答案中进行选择。封闭式问题便于对问卷信息进行归纳与整理，但是会限制用户的思维。访谈通过开发人员与特定的用户代表进行座谈，进而了解到用户的意见，是最直接的需求获取方法。为了使访谈有效，在进行访谈之前，开发人员要首先确定访谈的目的，进而准备一个问题列表，预先准备好希望通过访谈解决的问题。在访谈的过程中，开发人员要注意态度诚恳，并保持虚心求教的姿态，同时还要对重点问题进行深入的讨论。由于被访谈的用户身份可能多种多样，开发人员要根据用户的身份特点，进行提问，给予启发。当然，进行详细的记录也是访谈过程中必不可少的工作。访谈完成后，开发人员要对访谈的收获进行总结，澄清已解决的和有待进一步解决的问题。关注用户的行为而不是他们的言语。

WEB性能测试方法

性能测试用例主要分为预期目标用户测试，用户并发测试，疲劳强度与大数据量测试，网络性能测试，服务器性能测试五大部分，具体编写测试用例时要根据实际情况进行裁减，在项目应用中遵守低成本，策略为中心，裁减，完善模型，具体化等原则；一、WEB 全面性能测试模型 Web 性能测试模型提出的主要依据是：一种类型的性能测试可以在某些条件下转化成为另外一种类型的性能测试，这些类型的性能测试的实施是有着相似之处的； 1. 预期指标的性能测试系统在需求分析和设计阶段都会提出一些性能指标，完成这些指标的相关的测试是性能测试的首要工作之一，这些指标主要诸于“系统可以支持并发用户200个；”系统响应时间不得超过2 0秒等，对这种预先承诺的性能要求，需要首先进行测试验证； 2. 独立业务性能测试独立业务实际是指一些核心业务模块对应的业务，这些模块通常具有功能比较复杂，使用比较频繁，属于核心业务等特点。用户并发测试是核心业务模块的重点测试内容，并发的主要内容是指模拟一定数量的用户同时使用某一核心的相同或者不同的功能，并且持续一段时间。对相同的功能进行并发测试分为两种类型，一类是在同一时刻进行完全一样的操作。另外一类是在同一时刻使用完全一样的功能。 3. 组合业务性能测试通常不会所有的用户只使用一个或者几个核心业务模块，一个应用系统的每个功能模块都可能被使用到；所以WEB性能测试既要模拟多用户的相同操作，又要模拟多用户的不同操作；组合业务性能测试是最接近用户实际使用情况的测试，也是性能测试的核心内容。通常按照用户的实际使用人数比例来模拟各个模版的组合并发情况；组合性能测试是最能反映用户使用情况的测试往往和服务器性能测试结合起来，在通过工具模拟用户操作的同时，还通过测试工具的监控功能采集服务器的计数器信息进而全面分析系统瓶颈。用户并发测试是组合业务性能测试的核心内容。组合并发的突出特点是根据用户使用系统的情况分成不同的用户组进行并发，每组的用户比例要根据实际情况来匹配； 4. 疲劳强度性能测试疲劳强度测试是指在系统稳定运行的情况下，以一定的负载压力来长时间运行系统的测试，其主要目的是确定系统长时间处理较大业务量时的性能，通过疲劳强度测试基本可以判定系统运行一段时间后是否稳定； 5. 大数据量性能测试一种是针对某些系统存储，传输，统计查询等业务进行大数据量时的性能测试，主要针对某些特殊的核心业务或者日常比较常用的组合业务的测试；第二种是极限状态下的数据测试，主要是指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试的对象也是某些核心业务或者常用的组合业务。第三种大数据量测试结合了前面两种的测试，两种测试同时运行产生较大数据量的系统性能测试；大数据量测试通常在投产环境下进行，并独立出来和疲劳强度测试放在一起，在整个性能测试的后期进行；大数据量的测试可以理解为特定条件下的核心业务或者组合业务测试； 6. 网络性能测试主要是为了准确展示带宽，延迟，负载和端口的变化是如何影响用户的响应时间的，在实际的软件项目中主要是测试应用系统的用户数目与网络带宽的关系。网络测试的任务通常由系统集成人员完成； 7. 服务器（操作系统，WEB服务器，数据库服务器）性能测试