性能测试报告评审规范

TestWhite 2018年7月20日01:46:03
评论
2483字阅读8分16秒
云小站


引言

1.1 编写目的


 本文档明确性能测试分析报告的评审行为,明确评审过程中使用的各项指标,使性能测试分析报告评审相关人员能够依据此规范检查性能测试分析报告的内容填写是否符合模版要求,检查性能测试分析报告是否正确反映了性能测试的完整过程,检查性能测试分析报告是否符合本规范中规定的质量标准。


1.2 适用范围


性能检测测试分析报告评审
性能诊断测试分析报告评审
性能调优测试分析报告评审
容量规划测试分析报告评审


1.3 预期读者


参与性能测试分析报告评审的各方面人员,包括:
测试管理部测试经理
技术测试部技术测试经理、技术测试分析师、技术测试工程师
项目(群)组项目经理、技术经理及其他相关人员
业务部门相关人员
数据中心相关人员


1.4 参考资料


《信息技术管理部测试管理办法》
《信息技术管理部性能测试规程》


2 与评审规程的关系

 在评审规程中规定性能测试分析报告的评审过程和具体活动,包括评审内容的准备、评审会议的召集、评审会议、评审结果的发布、评审结果的跟踪。

本规范为评审规程中的具体活动提供可依据的方法、判断标准以及相关模版。

3 标准与模版


3.1 活动:评审内容的准备


3.1.1准入标准


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

3.1.2准出标准


性能测试分析报告经过技术测试经理审核并签字
性能测试相关所有文档已经放置于可供获取的位置,包括性能测试计划、性能测试方案、性能测试场景/脚本、数据文件、执行日志、性能测试分析报告。


3.1.3模版


N/A
3.2 活动:评审会议的召集
3.2.1准入标准
3.2.2准出标准
会议召集通知书已经发送给所有相关评审方,包括:被测应用系统所属项目(群)组、业务部门、数据中心、测试管理部、技术测试部、业务测试部。
性能测试分析报告和所有相关文档同时随会议召集通知书发送给了所有相关评审方。


3.2.3模版


名称:《性能测试分析报告评审会议通知书》。
内容:
发送信息,应包括姓名、Email、座机、手机、角色、所属部门
项目(群)组名称
会议召集时间
会议持续时间
会议地点
参加人员和角色及部门名称
主持人和角色及部门名称
记录人和角色及部门名称
会议议程
期望达成目标
附件名称及简要说明
初审意见


3.3 活动:评审会议


3.3.1准入标准


所有与会人员准时到场(现场/或视频)
所有与会人员已经预先审阅了性能测试分析报告及相关文档
所有与会人员已经在《性能测试分析报告评审会议通知书》中填写了初审意见并发送给会议主持人
会议主持人已组织性能测试实施人员对各方与会人员的初审意见进行了汇总和分析


3.3.2准出标准


性能测试背景评审完成
o 应具备详细的、明确的性能测试工作背景描述
性能测试需求评审完成
o 性能测试需求应明确表明本次性能测试的类型,应为性能检测测试、性能诊断测试、性能调优测试或者容量规划测试
o 性能测试需求中应具备明确的性能测试范围
性能测试目标评审完成
o 性能测试目标中应具备期望达到的明确的响应时间指标
o 性能测试目标中应具备期望达到的明确的处理能力指标
o 性能测试目标中应具备期望达到的明确的资源利用率指标
o 性能测试目标中应具备期望达到的明确的稳定性测试时间长度指标以及交易成功率指标
o 性能测试目标中应对响应时间和处理能力指标进行明确的定义
性能测试模型评审完成
性能测试模型中应具备明确的测试场景名称以及使用该场景的原因说明
测试场景中应具备明确的虚拟用户名称、数量/百分比、思考时间(ThinkTime)、检查点、测试数据说明
测试场景应具备明确的测试环境说明,包括应用版本、网络架构、应用技术架构、服务器硬件设备信息、应用平台的版本和关键参数设置信息
测试场景应具备明确的被测应用系统基础数据信息,包括基础数据量、类型(模拟数据/生产数据)
性能测试过程评审完成
性能测试过程包含了性能测试规程中规定的所有不可裁减的测试任务
每项测试任务应具备明确的测试方法说明
每项测试任务应具备明确的状态(完成/未完成)
若某项测试任务未完成,则该项测试任务应具备明确的未完成原因以及解决方法说明
性能测试单项任务数据分析评审完成
每个单项任务应具备明确的测试目的
每个单项任务应具备明确的测试数据分析
性能测试结论评审完成

每个性能测试目标应具备至少一条结论
每条结论应针对一个具体的性能测试目标
性能测试缺陷评审完成
所有已发现缺陷都具备了明确的状态(已解决/未解决)
所有遗留缺陷都具备了明确的追踪解决方案(监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人)
性能测试分析报告评审完成
若有一项评审结果为不通过,则此项为不通过
所有与会各方人员签字认可评审结果
若有一方人员未到场,此次评审视为无效。评审会议结束后,将会议记录与会议结论发送给缺席方人员进行离线评审。
获得缺席方离线评审意见后,修订评审结果,此次评审方可视为有效。


3.3.3模版


名称:《性能测试分析报告评审报告》
内容:
项目(群)组名称
会议召集时间
会议地点
与会人员、角色及部门名称
主持人员、角色及部门名称
记录人员、角色及部门名称
性能测试背景评审结果:通过/不通过
性能测试需求评审结果:通过/不通过
性能测试目标评审结果:通过/不通过
性能测试模型评审结果:通过/不通过
性能测试过程评审结果:通过/不通过
性能测试单项任务数据分析评审结果:通过/不通过
性能测试结论评审结果:通过/不通过
性能测试缺陷评审结果:通过/不通过
性能测试分析报告评审结果:通过/不通过
性能测试评审会议有效性:有效/无效
参与各方人员签字
3.4 活动:评审结果的发布
3.4.1准入标准

性能测试评审会议有效性:有效
性能测试分析报告:通过
3.4.2准出标准
性能测试分析报告评审报告已经发送给所有相关各方,应包括:项目实施管理条线、业务IT管理条线、相关业务部门、数据中心、项目(群)组、测试管理部、技术测试部、业务测试部等
性能测试分析报告评审报告由技术测试部备案


3.4.3模版


N/A
3.5 活动:评审结果的跟踪
3.5.1准入标准
性能测试分析报告中的所有遗留缺陷都具备了明确的追踪解决方案(监督责任人、期望解决结果、期望解决时间、解决方法、解决责任人)

图文来源网络,如有侵权联系删除

继续阅读
  • 我们QQ群
  • QQ扫一扫
  • weinxin
  • 微信公众号
  • 公众号扫一扫
  • weinxin
TestWhite
  • 本文由 发表于 2018年7月20日01:46:03
  • 请您在转载时请务必保留本文链接:https://www.playezu.com/13888.html
DDOS攻击服务器的几种方式 压力测试

DDOS攻击服务器的几种方式

当前主要有三种流行的DDoS攻击: 1、SYN/ACK Flood攻击: 这种攻击方法是经典最有效的DDoS方法,可通杀各种系统的网络服务,主要是通过向受害主机发送大量伪造源IP和源端口的SYN或...
这是一篇关于数据库压力测试的故事 压力测试

这是一篇关于数据库压力测试的故事

大家好久不见了,这几天比较忙,没有更文,明天就中秋了,小编祝大家中秋节快乐。来看看小编带来的“故事”。 前言   最近配合某客户做了一个关于XX系统的压力测试,其实经过和客户的沟通得知...
WEB 性能测试用例设计以及总结 压力测试

WEB 性能测试用例设计以及总结

WEB 性能测试用例设计模型是设计性能测试用例的一个框架,在实际项目中,需要对其进行适当的剪裁,从而确定性能测试用例的范围和类别。剪裁的依据是性能测试策略和测试范围,在测试用例主要框架确定后,接下来就...
软件开发测试——冒烟测试 压力测试

软件开发测试——冒烟测试

你真的了解什么是冒烟测试么     何为冒烟测试?开发的同学们一听到‘测试’这个词,本能会觉得这个测试的事,不是我们的活儿。那么,何为冒烟测试。     这一术语源自硬件行业。对一个硬件或硬件...
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: