基础---性能测试方案

方案中有几个关键点：测试环境，测试数据，测试模型，性能指标，压力策略，准入准出和进度风险

性能测试模型

业务模型

 

数据模型

 

 

 监控模型

 

 分析模型

 

 压力策略：

性能测试策略一般从需求设计阶段开始讨论制定，策略的内容决定着性能测试工作投入多少资源、什么时间开始实施等后继工作如何安排。制定性能测试的策略的因素：

1、预期的指标性能的因素

系统在需求分析、设计阶段和产品说明书等文档中明确的提出都性能指标，这些指标是性能测试要完成的工作。

2、独立业务性能测试的因素

独立业务主要是指软件产品的模块具有独立业务功能，在需求阶段就可以确定，要单独测试其性能。

3、业务性能组合测试的因素

应用类软件系统通常不会使所有的用户只使用一个或者几个核心业务模块，可能是对多个业务进行组合使用，对多个业务进行组合性能测试。由于组合业务测试是最能反映

用户使用系统情况，因而业务性能组合测试是测试的核心内容。

4、疲劳强度性能测试

疲劳强度测试是在系统稳定运行下模拟较大的用户数量、并长时间运行系统的测试，通过综合分析执行指标和资源监控来确定系统处理最大业务量时的性能，主要目的是为了测试系统的稳定性。

5、大数据量性能测试的因素

大数据量测试是为了测试系统的业务处理能力进行的。第一种是针对某些系统存储、传输、统计查询等业务进行大数据量的测试,主要是测试数据增多时的性能情况；

第二种是极限状态下数据测试，主要指系统数据量达到一定程度时，通过性能测试来评估系统的响应情况，测试对象是某些核心业务或者日常常用的组合业务。

6、网络性能测试的因素

网络性能测试主要是为了准确展示带宽、延迟、吞吐量、负载、瓶颈和端口的变化是如何影响用户的响应时间的。重点测试吞吐量指标，因为80%的系统性能瓶颈由吞吐量造成。

 

准入准出：

二、性能测试报告评审准入准出标准

 

1．评审内容的准备

1.1准入标准

　性能测试计划中的任务完成率=100%，包括所有开发任务、所有执行任务、所有任务

1.2准出标准

　性能测试报告经过技术测试leader审核确认

性能测试相关所有文档已经放置于可供获取的位置，包括性能测试计划、性能测试方案、性能测试场景/脚本、数据文件、性能测试报告。

1.3模版

2．评审会议的召集
2.1准入标准

2.2准出标准
　会议召集通知书已经发送给所有相关评审方，包括：被测应用系统所属项目（群）组、产品部门、技术部门、运维部门、测试部门。

性能测试报告和所有相关文档同时随会议召集通知书发送给了所有相关评审方。

2.3模版
　《性能测试报告评审会议通知书》

内容：

• 发送信息，应包括姓名、Email、座机、手机、角色、所属部门
• 项目（群）组名称
• 会议召集时间
• 会议持续时间
• 会议地点
• 参加人员和角色及部门名称
• 主持人和角色及部门名称
• 记录人和角色及部门名称
• 会议议程
• 期望达成目标
• 附件名称及简要说明
• 初审意见
  
  

 

3．评审会议
1.准入标准

• 所有与会人员准时到场（现场/或视频）
• 所有与会人员已经预先审阅了性能测试报告及相关文档
• 会议主持人已组织性能测试实施人员对各方与会人员的初审意见进行了汇总和

 

2.准出标准

• 性能测试背景评审完成
• 应具备详细的、明确的性能测试工作背景描述

 

• 性能测试需求评审完成
• 性能测试需求应明确表明本次性能测试的类型，应为性能检测测试、性能诊断测试、性能调优测试或者容量规划测试
• 性能测试需求中应具备明确的性能测试范围

 

• 性能测试目标评审完成
• 性能测试目标中应具备期望达到的明确的响应时间指标
• 性能测试目标中应具备期望达到的明确的处理能力指标
• 性能测试目标中应具备期望达到的明确的资源利用率指标
• 性能测试目标中应具备期望达到的明确的稳定性测试时间长度指标以及请求成功率指标
• 性能测试目标中应对响应时间和处理能力指标进行明确的定义

 

• 性能测试模型评审完成（注：该测试模型部分目前在计划中）
• 性能测试模型中应具备明确的测试场景名称以及使用该场景的原因说明
• 测试场景中应具备明确的虚拟用户名称、数量/百分比、思考时间（ThinkTime）、检查点、测试数据说明
• 测试场景应具备明确的测试环境说明，包括应用版本、网络架构、应用技术架构、服务器硬件设备信息、应用平台的版本和关键参数设置信息
• 测试场景应具备明确的被测应用系统基础数据信息，包括基础数据量、类型（模拟数据/生产数据）

 

• 性能测试过程评审完成
• 性能测试过程包含了性能测试规程中规定的所有不可裁减的测试任务
• 每项测试任务应具备明确的测试方法说明
• 每项测试任务应具备明确的状态（完成/未完成）
• 若某项测试任务未完成，则该项测试任务应具备明确的未完成原因以及解决方法说明

 

 

• 性能测试单项任务数据评审完成
• 每个单项任务应具备明确的测试目的
• 每个单项任务应具备明确的测试数据

 

• 性能测试结论评审完成
• 每个性能测试目标应具备至少一条结论
• 每条结论应针对一个具体的性能测试目标

 

• 性能测试缺陷评审完成
• 所有已发现缺陷都具备了明确的状态（已解决/未解决）
• 所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）

 

 

• 性能测试报告评审完成
• 若有一项评审结果为“不通过”，则此项为“不通过”

 

• 所有与会各方人员确认认可评审结果
• 若有一方人员未到场，此次评审视为无效。评审会议结束后，将会议记录与会议结论发送给缺席方人员进行离线评审。
• 获得缺席方离线评审意见后，修订评审结果，此次评审方可视为有效。

 

 

3.模版

《性能测试报告评审报告》

内容：

• 项目（群）组名称
• 会议召集时间
• 会议地点
• 与会人员、角色及部门名称
• 主持人员、角色及部门名称
• 记录人员、角色及部门名称
• 性能测试背景评审结果：通过/不通过
• 性能测试需求评审结果：通过/不通过
• 性能测试目标评审结果：通过/不通过
• 性能测试模型评审结果：通过/不通过
• 性能测试过程评审结果：通过/不通过
• 性能测试单项任务数据评审结果：通过/不通过
• 性能测试结论评审结果：通过/不通过
• 性能测试缺陷评审结果：通过/不通过
• 性能测试报告评审结果：通过/不通过
• 性能测试评审会议有效性：有效/无效
• 参与各方人员确认
  
  

 

4． 评审结果的发布

1.准入标准

• 性能测试评审会议有效性：有效
• 性能测试报告：通过

 

2.准出标准

• 性能测试评审报告已经发送给所有相关各方，应包括：ML_好房技术中心管理组; ML_平安好房项目管理部; ML_平安好房技术中心测试部信息协同; ml_平安好房技术中心测试部非功能组 ; ML_平安好房运维部系统运维团队等
• 性能测试评审报告由测试部备案上传Git、QAMP平台

 

3.模版

5．评审结果的跟踪
1.准入标准
　性能测试报告中的所有遗留缺陷都具备了明确的追踪解决方案（监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人）

2.准出标准
　所有性能测试缺陷已关闭

 

 

进度风险：

1.重要数据事前备份，事后恢复

2.测试时间选择系统空闲时间

3.给测试数据加标记

4.实时关注系统状态等

 

 

性能流程中的注意点或者内容