性能测试报告模板

xxx项目 性能测试报告模板

1、概况

1.1测试背景

简要描述与测试项目相关的一些背景资料，如项目上线计划、测试需求等。

1.2测试目的

在大用户量、数据量的超负荷下，获得服务器运行时的相关数据，从而进行分析，查看xx 网站是否符合需求。

1.3测试范围

本次测试主要是对xx 网站系统的性能测试。

1.4测试指标

指标 建议值

CPU占用 服务器CPU占用率70%以内：优秀70%-85%：一般85%以上：差

内存占用 服务器内存占用率70%以内：优秀70%-85%：一般85%以上：差

事务通过率 99.5%以上：优秀98.6%-99.5%：一般98.0%-98.6%：轻微隐患97.5%及以下：严重隐患

TPS 每秒成功完成的事务请求数，反应系统处理能力。业务量越大，TPS值越大

I/O 处理业务过程中磁盘存取数据的利用率，反应磁盘的处理能力，利用率越低，磁盘处理性能越好，一般建议在80%以下

2. 测试工具及环境

2.1测试环境

描述测试环境的物理架构，可以用物理架构图来展示。

2.2基本配置

2.3测试工具

a.压测工具：

b.监控工具：

3、测试内容

3.1单场景基准测试模型

描述测试场景，比如登录、注册等。采用单用户无其他压力情况下，查看平均响应时间

3.2单场景容量测试模型

描述测试场景，比如登录、注册等。人数逐步递增，持续XXX，查看各性能指标，获得最大并发数

3.3混合场景容量测试模型

描述测试场景，可以用图表形式说明。

4、测试结果与分析

4.1单场景基准测试模型

a.测试结果数据

b.测试问题及结果分析

对测试的结果及发现的性能问题进行总结，分析。例如：

相关图表来进行性能分析

描述对测试中限制性指标的因素

对测试指标的结果与目标进行对比

4.2单场景容量测试模型

测试结果数据(给出测试指标结果数据)

测试问题及结果分析

对测试的结果及发现的性能问题进行总结，分析。例如：

合并相关图表来进行性能分析

描述对测试中限制性指标的因素

对测试指标的结果与目标进行对比

4.3混合场景压测模型

a.测试结果数据

给出测试指标结果数据及图表

b.测试问题及结果分析

对测试的结果及发现的性能问题进行总结、分析。例如：

对相关的数据和图表进行分析

描述对测试中限制性指标的因素

对测试指标的结果与预期进行对比

最后:【可能给你带来帮助的教程】

点击免费领取软件测试资料 ，也可以来我的学习基地吹吹水交流心得

这一些资料，对做【软件测试】的朋友而言应该是较为完整了，这类学习资料也陪伴我走过了最艰难的路程，希望也可以帮助到你！万事要尽早，尤其是技术行业，一定要提升技术功底。

在进行网页或应用程序后台接口开发时，一般要及时测试开发的接口能否正确接收和返回数据，对于单次测试，Postman插件是个不错的Http请求模拟工具。

但是Postman只能模拟单客户端的单次请求，而对于模拟多用户并发等性能测试，就必须借助其他的工具了，这里推荐功能强大的JMeter自动化测试工具

Apache JMeter - Apache JMeter™

Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试但后来扩展到其他测试领域。 它可以用于测试静态和动态资源例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库， FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。

下面就以上图的Restful类型的接口为例简单介绍使用Jmeter进行接口测试的方法。

获取某个具体网关设备的基本信息。

请求

方法：GET

URI：/api/gateway/<gateway_id>

参数：

在HTTP请求（http request）的头部（header）添加Userid和Token字段作为用户验证字段

响应

返回值：JSON格式的网关信息

参数：

.启动jmeter：在bin下以管理员身份运行jmeter.bat，启动jmeter

2. 创建测试计划：

默认启动jmeter时会加载一个测试技术模板，保存测试计划：修改名称为Apitest,点击保存，选择保存路径,后面的步骤，每次添加或修改了了一些选项，软件并不会自动保存到jmx文件中，所以进行测试后，如果需要保存本次测试选项，要手动到“文件”菜单中保存一下。

3. 添加线程组

右键左边树中的测试计划“Apitest”节点，“添 加”→”Threads”→”线程组”

添加成功后，“Apitest”节点下多了“线程组” 节点,当然这个线程组的名称是可以自己设定的。

4. 添加http默认请求：（用来配置公共参数,不是http请求）

右键线程组，选择“添加”→ “配置元件”→“HTTP请求默认值”，点击“HTTP请求默认值”后

添加成功后，线程组”节点下多了“HTTP请求默认值”节点

这里可以设置主机地址等一下公共参数，比如我们的例子中请求路径前面都是主机地址+index.php,就可以统一在"http请求默认值"里设置

填写默认请求名、服务器、默认请求路径，保存测试计划。

5.添加http请求信息头

这一项并不是必须的，只不过我们的例子中使用了Userid和Token放在HTTP请求头中用作用户验证

右键“Apitest”，选择“添加”→ “配置元件”→“HTTP信息头管理器”

6. 添加http请求

右键“Apitest”，选择“添加”→ “Sampler”→“HTTP请求”

添加成功后，出现新的节点“HTTP请求”，就可以填写具体的请求参数了。

填写完成，保存测试计划

7. 添加监听器：

右键线程组，选择“添加”→“监听器”→“XXXXXXXXX”

可以添加的监听器有很多种，可以添加多个监听器，这里我们添加几个常用的“图形结果”、“察看结果树”、“聚合报告”

添加成功后，“线程组”下增加了几个节点

8. 试运行

点击执行

可以查看各个“监听器”的结果

Label：每个 JMeter 的 element（例如 HTTP Request）都有一个 Name 属性，这里显示的就是 Name 属性的值

#Samples：表示你这次测试中一共发出了多少个请求，如果模拟10个用户，每个用户迭代10次，那么这里显示100

Average：平均响应时间——默认情况下是单个 Request 的平均响应时间，当使用了 Transaction Controller 时，也可以以Transaction 为单位显示平均响应时间

Median：中位数，也就是 50％ 用户的响应时间

90% Line：90％ 用户的响应时间

Note：关于 50％ 和 90％ 并发用户数的含义，请参考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小响应时间

Max：最大响应时间

Error%：本次测试中出现错误的请求的数量/请求的总数

Throughput：吞吐量——默认情况下表示每秒完成的请求数（Request per Second），当使用了 Transaction Controller 时，也可以表示类似 LoadRunner 的 Transaction per Second 数

KB/Sec：每秒从服务器端接收到的数据量，相当于LoadRunner中的Throughput/Sec

9. 修改线程组的线程数等参数，用于压力测试

点击左侧树形导航中的“线程组”

设置上面几个参数，模拟的总的请求数是：线程数*循环次数。执行一下，用“图形结果”监听器查看一下

样本数目：总共发送到服务器的请求数.

最新样本：代表时间的数字,是服务器响应最后一个请求的时间.

吞吐量：服务器每分钟处理的请求数.

平均值：总运行时间除以发送到服务器的请求数.

中间值：时间的数字,有一半的服务器响应时间低于该值而另一半高于该值.

偏离：服务器响应时间变化、离散程度测量值的大小,或者,换句话说,就是数据的分布.

评审过程的规范性：

1、评审的准入；

2、评审的准出；

3、评审这个过程的一些要求：

如哪些评审员参加？计划性如何？使用检查单？预审情况？缺陷发现情况？缺陷修复情况？总结分析情况及评审结论？

4、识别一些改进机会，记录NC

自己整理吧 下面是模板

2楼

性能测试目标中应对响应时间和处理能力指标进行明确的定义

性能测试模型评审完成

性能测试模型中应具备明确的测试场景名称以及使用该场景的原因说明

测试场景中应具备明确的虚拟用户名称、数量/百分比、思考时间（ThinkTime）、检查点、测试数据说明

测试场景应具备明确的测试环境说明，包括应用版本、网络架构、应用技术架构、服务器硬件设备信息、应用平台的版本和关键参数设置信息

测试场景应具备明确的被测应用系统基础数据信息，包括基础数据量、类型（模拟数据/生产数据）

性能测试过程评审完成

性能测试过程包含了性能测试规程中规定的所有不可裁减的测试任务

每项测试任务应具备明确的测试方法说明

每项测试任务应具备明确的状态（完成/未完成）

若某项测试任务未完成，则该项测试任务应具备明确的未完成原因以及解决方法说明

性能测试单项任务数据分析评审完成

每个单项任务应具备明确的测试目的

每个单项任务应具备明确的测试数据分析

性能测试结论评审完成

每个性能测试目标应具备至少一条结论

每条结论应针对一个具体的性能测试目标

性能测试缺陷评审完成

所有已发现缺陷都具备了明确的状态（已解决/未解决）

所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）

性能测试分析报告评审完成

若有一项评审结果为“不通过”，则此项为“不通过”

所有与会各方人员签字认可评审结果

若有一方人员未到场，此次评审视为无效。评审会议结束后，将会议记录与会议结论发送给缺席方人员进行离线评审。

获得缺席方离线评审意见后，修订评审结果，此次评审方可视为有效。

3.3.3模版

名称：《性能测试分析报告评审报告》

内容：

项目（群）组名称

会议召集时间

会议地点

与会人员、角色及部门名称

主持人员、角色及部门名称

记录人员、角色及部门名称

性能测试背景评审结果：通过/不通过

性能测试需求评审结果：通过/不通过

性能测试目标评审结果：通过/不通过

性能测试模型评审结果：通过/不通过

性能测试过程评审结果：通过/不通过

性能测试单项任务数据分析评审结果：通过/不通过

性能测试结论评审结果：通过/不通过

性能测试缺陷评审结果：通过/不通过

性能测试分析报告评审结果：通过/不通过

性能测试评审会议有效性：有效/无效

参与各方人员签字

3.4 活动：评审结果的发布

3.4.1准入标准

性能测试评审会议有效性：有效

性能测试分析报告：通过

3.4.2准出标准

性能测试分析报告评审报告已经发送给所有相关各方，应包括：项目实施管理条线、业务IT管理条线、相关业务部门、数据中心、项目（群）组、测试管理部、技术测试部、业务测试部等

性能测试分析报告评审报告由技术测试部备案

3.4.3模版

N/A

3.5 活动：评审结果的跟踪

3.5.1准入标准

性能测试分析报告中的所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）

---