项目管理系统开发软件性能测试规范.docx

项目管理系统开发软件性能测试规范.docx

《项目管理系统开发软件性能测试规范.docx》由会员分享，可在线阅读，更多相关《项目管理系统开发软件性能测试规范.docx（8页珍藏版）》请在冰豆网上搜索。

项目管理系统开发软件性能测试规范

软件性能测试规范

修订记录

版本号

修订人

修订日期

修订类型

修订说明

审核人

批准人

批准日期

修订类型包含：

新增、修改、删除。

1前言

1.1编写目的

本文档旨在统一对软件性能测试的认识，规范软件性能测试的测试流程和方法，为开展软件性能测试提供支持。

1.2适用对象

此文档可作为软件测试人员开展软件性能测试的规范和指导，也可以作为项目经理、测试经理等制定软件性能测试规范的参考。

1.3适用范围

此文档用于软件产品开发过程中的软件性能测试环节。

2性能需求分析

2.1性能需求获取

1.功能规格说明书

2.系统设计文档

3.运营计划

4.用户行为分析记录

2.2性能关键点选取

主要从以下4个维度进行选取：

1.业务分析

确定被测性能点是否属于关键业务的性能点或先分析出关键业务以间接获取该业务的性能点。

2.统计分析

若系统访问行为存在日志分析记录，则直接获取日访问量高的作为性能点；否则根据第三方日志分析工具间接获取。

1）IIS日志分析工具：

LogParser2.2+LogParserLizardGUI

2）Tomcat日志分析工具：

AWStatsv7.3

3）Nginx日志分析工具：

GoAccessv0.9

若IIS或Tomcat等应用服务器使用Nginx进行负载，则日志访问量要以负载为准，避免在Nginx设置缓存（即未进行透传）而导致统计不正确。

3.技术分析

1）逻辑实现复杂度高的性能点（如判断分支过多或涉及CPU/IO密集型运算等）

2）对系统（内存、CPU、磁盘IO）及网络IO等硬件资源耗用高的性能点

4.运营分析

由于运营推广活动导致日访问突增高的性能点。

若运营计划调整，则需重新分析。

2.3测试方法

2.3.1性能测试分类

1.基准测试（BenchmarkTesting）

基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试，目的在于量化响应时间、吞吐率的指标，便于后续比对。

方法是做多组不同场景的测试，观察结果，抽取出几个关键数据做好记彔，用于以后进行性能对比和评价。

2.性能测试（PerformanceTesting）

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

特点：

1）主要目的是验证系统是否具有系统宣称的能力

2）需要事先了解被测系统的典型场景，并具有确定的性能目标

3）要求在已确定的环境下运行

3.负载测试（LoadTesting）

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

特点：

1）主要目的是找到系统处理能力的极限

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

3）一般用来了解系统的性能容量，或是配合性能调优使用

4.压力测试（StressTesting）

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

特点：

1）主要目的是检查系统处于压力情况下应用的表现

2）一般通过模拟负载等方法，使得系统的资源使用达到较高水平

3）一般用于测试系统的稳定性

5.配置测试（ConfigurationTesting）

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

特点：

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

2）一般在对系统性能状况有初步了解后进行

3）一般用于性能调优和规划能力

6.并发测试（ConcurrencyTesting）

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

特点：

1）主要目的是发现系统中可能隐藏的并发访问时的问题

2）主要关注系统可能存在的并发问题，例如系统中的内存泄露、线程锁和

资源争用方面的问题

3）可在开发的各个阶段使用，需要相关的测试工具的配合和支持

7.可靠性测试（ReliabilityTesting）

通过给系统加载一定的业务压力（例如资源在70%~90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。

特点：

1）主要目的是验证系统是否支持长期稳定的运行

2）需要在压力下持续一段时间的运行

3）需要关注系统的运行状况

8.失效恢复测试（FailoverTesting）

针对有冗余备份和负载均衡的系统设计的，可以用来检验系统局部发生故障时，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。

特点：

1）主要目的是验证在局部故障情况下，系统能否继续使用

2）还需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案

3）一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试

2.3.2性能测试目的

概况来说，可分为4个方面：

1.能力验证

在系统测试或验收测试时，我们需要评估系统的能力，衡量系统的性能指标。

系统的能力可以是容纳的并发用户数，也可能是系统的吞吐率；系统的性能指标可以是响应时间，也可以选择CPU、内存、磁盘、网络的使用情况。

特点：

1）要求在已确定的环境下进行

2）需要根据典型场景设计测试方案和用例

一般采用的方法是：

性能测试、压力测试、可靠性测试、失效恢复测试

2.能力规划

评估某系统能否支持未来一段时间内的用户增长或是应该如何调整系统配置，使得系统能够满足增长的用户数的需要。

特点：

1）属于一种探索性的测试

2）可被用来了解系统的性能以及获得扩展性能的方法，例如系统扩容规划系统容量可以是用户容量，也可能是数据容量，或者是系统的吞吐量（系统的处理能力）。

对于集群服务我们更多的是用吞吐率作为容量。

方法是先对各子系统、组件进行性能测试，找出它们之间的最优配比，然后再通过各环节的水平扩展，计算出整体的扩容机器配比。

一般采用的方法是：

负载测试、压力测试、配置测试

3.性能调优

为了更好的发挥系统的潜能，定位系统的瓶颈，有针对性的进行系统优化。

方法是在进行系统调优时，我们需要做好基准测试，用以对比性能数据的变

化，并反复调整系统软硬件的设置，以使系统发挥最优性能。

当然在进行系统优化时，我们会选取关键的指标进行优化，可能要牺牲其他的性能指标。

如目标是优化响应时间，我们可能选取的策略是以空间换时间，以牺牲内存或扩大缓存为代价，还需要我们在各个性能指标中找到平衡点。

一般对系统的调整包括以下3个方面：

1）硬件环境的调整

2）系统设置的调整

3）应用级别的调整

一般采用的方法是：

基准测试、负载测试、压力测试、配置测试和失效恢复测试

4.发现缺陷

和其他测试一样，性能测试也可以发现缺陷。

特别是严格并发访问时是否存在资源争夺导致的响应时间过慢，或大量用户访问时是否导致程序崩溃。

方法是设置集合点，实现严格并发用户访问；或者设置超大规模用户突发访问等这样的性能测试用例进行测试。

一般采用的方法是：

并发测试。

2.4测试工具

综合系统设计、工具成本、测试团队的技能来考虑，选择合适的测试工具，最起码应该满足以下几点：

支持对web（这里以web系统为例）系统的性能测试，支持http和https

协议；工具运行在Windows平台上；支持对webserver、前端、数据库的性能

计数器进行监控。

2.5测试指标

2.5.1常见性能指标介绍

1.响应时间

响应时间即从应用系统发出请求开始，到客户端接收到最后一个字节数据为止所消耗的时间。

响应时间按软件的特点再可以细分，如对于一个C/S软件的响应时间可以细分为网络传输时间、应用服务器处理时间、数据库服务器处理时间。

另外客户端自身也存在着解析时间、界面绘制呈现时间等。

响应时间主要站在客户端角度来看的一个性能指标，它是用户最关心、并且容易感知到的一个性能指标。

2.吞吐率

吞吐率指单位时间内系统处理用户的请求数，从业务角度看，吞吐率可以用每秒请求数、每秒事务数、每秒页面数、每秒查询数等单位来衡量。

从网络角度看，吞吐率也可以用每秒字节数来衡量。

吞吐率主要站在服务端的角度来看的一个性能指标，它可以衡量整个系统的处理能力。

对于集群或者云平台来说，吞吐率指标反映的是服务器集群对外整体能够承受的压力，该指标比用户数更容易对比。

备注：

吞吐量=吞吐率*时间

3.用户数

对于服务器集群或者云平台，几乎都是多用户系统，系统能提供给多少用户

正常使用，也是一个非常重要的度量指标。

我们把这些用户按照使用系统的时机不同，做如下区分：

系统用户数（SystemUsers）：

指系统能够存储的用户量

在线用户数（OnlineUsers）：

指用户通过身份确认后，处于能正常使用状态的用户个数

并发用户数（ConcurrentUsers）：

指在某个时间范围内，同时正在使用系统的用户个数

严格并发用户数（StrictlythenumberofconcurrentUsers）：

指同一时刻都操作某个业务的用户数

在性能测试过程中，我们要去模拟实际用户来发请求。

但是为了给服务器产生更大的压力，我们模拟的用户操作和实际的用户操作存在一定的差异（比如模拟的用户请求比实际用户的请求更频繁），而且这种模拟的用户数和实际的用户数也难以相互换算。

所以在度量服务器集群能力时，吞吐率指标比用户数指标更实用。

2.5.2常见性能指标量值参考

1.响应时间

在一般情况下，弱交互类接口平均响应时间不超过1秒，强交互类接口平均

响应时间不超过200毫秒。

2.成功率

在一般情况下，接口响应成功率需达到99.99%以上。

3.系统资源

若为最佳负载，则系统CPU及内存使用率建议区间[50%，80%]，否则建议不超过50%。

4.处理能力

立项申请书明确要求：

在XX压力下（并发数）TPS需达到XX或接口系统可支撑XX万实时在线访问。

5.稳定性

在实际系统运行压力情况下，可稳定运行N*24（一般N>=7）小时。

在高于实际系统运行压力1倍的情况下，可稳定运行12小时。

6.特性指标

例：

Java类应用FullGC次数<=1次/天。

2.6测试结果分析

性能测试的指标可分为产品指标和资源指标两类。

对测试人员而言，性能测试的需求来自于用户、开发、运维的三方面。

用户和开发关注的是与业务需求相关的产品指标，运维人员关注的是与硬件消耗相关的资源指标。

1.从用户角度关注的指标

用户关注的是单次业务相关的体验效果，譬如一次操作的响应快慢、一次请求是否成功、一次连接是否失败等，反映单次业务相关的指标包括：

a.成功率b.失败率c.响应时间

2.从开发角度关注的指标

开发人员更关注的是系统层面的指标。

1）容量：

系统能够承载的最大用户访问量是多少?

系统最大的业务处理量是

多少?

2）稳定性:

系统是否支持7*24小时（一周）的业务访问？

3.从运维角度关注的指标

运维人员更关注的是硬件资源的消耗情况。