WEB开发之性能测试

一、性能测试的目的

性能测试的目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

包括以下几个方面

1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。

2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。

3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。

4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

二、类型

性能测试类型包括负载测试，强度测试，容量测试等。

负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。

压力测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。

容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。

性能测试中包含以下测试类型：

基准测试 - 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。

争用测试：- 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。

性能配置 - 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。

负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。

强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。

容量测试- 核实测试用户同时使用软件程序的最大数量。

性能评价通常是和用户代表一起协作并且以多级方法执行的。

性能分析的第一级涉及单一主角/用例实例的结果评价和多个测试执行的结果比较。例如，在测试对象上没有其他活动的情况下，记录单一主角执行单一用例的性能行为，并将结果与相同主角/用例的其他几个测试执行进行比较。第一级分析有助于确定可以表明系统资源中存在争用的趋势，该趋势将影响从其他性能测试结果所得出的结论的有效性。

分析的第二级检查特定主角/用例执行的摘要统计信息和实际数据值，以及测试对象的性能行为。摘要统计信息包括响应时间的标准偏差和百分位分布，这些信息显示了系统响应的变动情况，正如每个主角所见到的一样。

分析的第三级有助于理解性能问题的起因和加权值。该详细分析采用低级数据并且使用统计方法，帮助测试员从数据中得出正确的结论。详细分析为决策提供客观和定量的标准，但是它耗时较长，并且要求对统计学有基本的理解。

当性能行为差异确实存在，或是由于某些与测试数据收集相关的随机事件引起时，详细分析使用统计加权值的概念来帮助理解。即认为在基本级上，任何事件都具有随机性。统计测试确定是否存在无法用随机事件解释的系统差异。

三、指标

性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

在实际工作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？

Bs结构程序一般会关注的通用指标如下（简）：

Web服务器指标指标：

Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数；

Avg time to last byte per terstion （mstes）：平均每秒业务脚本的迭代次数，有人会把这两者混淆；

Successful Rounds：成功的请求；

Failed Rounds ：失败的请求；

Successful Hits ：成功的点击次数；

Failed Hits ：失败的点击次数；

Hits Per Second ：每秒点击次数；

Successful Hits Per Second ：每秒成功的点击次数；

Failed Hits Per Second ：每秒失败的点击次数；

Attempted Connections ：尝试链接数；

CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：

User 0 Connections ：用户连接数，也就是数据库的连接数量；

Number of deadlocks：数据库死锁；

Buffer Cache hit ：数据库Cache的命中情况

当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。

我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型：

c/s

client/Server 客户端/服务器架构

基于客户端/服务器的三层架构

基于客户端/服务器的分布式架构

b/s

基于浏览器/Web服务器的三层架构

基于中间件应用服务器的三层架构l

基于Web服务器和中间件的多层架构

四、步骤

在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

由于工程和项目的不同，所选用的度量，评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下

1． 制定目标和分析系统

2． 选择测试度量的方法

3． 学习的相关技术和工具

4． 制定评估标准

5． 设计测试用例

6． 运行测试用例

7． 分析测试结果

制定目标和分析系统

每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。

目标：

1． 确定客户需求和期望

2． 实际业务需求

3． 系统需求

系统组成

系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。

系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构，需要掌握 http协议，java，html等技术。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。

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

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

选择测试度量的方法

经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软件度量上，收集系统相关的数据。

度量的相关方面：

• 制定规范

• 制定相关流程，角色，职责

• 制定改进策略

• 制定结果对比标准

学习的相关技术和工具

性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过winsock,http等协议记录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议，cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。

制定评估标准：

任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。

通常性能测试有四种模型技术可用于评估：

• 线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

• 分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来

• 模仿：模仿实际用户的使用方法测试你的系统

• 基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比

设计测试用例：

设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。

运行测试用例：

通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。

分析测试结果：

运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。

五、原则

1）情况许可时，应使用几种测试工具或手段分别独立进行测试，并将结果相互印证，避免单一工具或测试手段自身缺陷影响结果的准确性；

2）对于不同的系统，性能关注点是有所区别的，应该具体问题具体分析；

3）查找瓶颈的过程应由易到难逐步排查：

服务器硬件瓶颈及网络瓶颈（局域网环境下可以不考虑网络因素）

应用服务器及中间件操作系统瓶颈（数据库、WEB服务器等参数配置）

应用业务瓶颈（SQL语句、数据库设计、业务逻辑、算法、数据等）

4）性能调优过程中不宜对系统的各种参数进行随意的改动，应该以用户配置手册中相关参数设置为基础，逐步根据实际现场环境进行优化，一次只对某个领域进行性能调优（例如对CPU的使用情况进行分析），并且每次只改动一个设置，避免相关因素互相干扰；

5）调优过程中应仔细进行记录，保留每一步的操作内容及结果，以便比较分析；

6）性能调优是一个经验性的工作，需要多思考、分析、交流和积累；

7）了解“有限的资源，无限的需求”；

8）尽可能在开始前明确调优工作的终止标准。

#