《全栈性能测试修炼宝典 JMeter实战》—第2章 2.2节性能测试流程-阿里云开发者社区

开发者社区> 开发与运维> 正文

《全栈性能测试修炼宝典 JMeter实战》—第2章 2.2节性能测试流程

简介: 对性能报告中的内容进行评审,确认问题、评估上线风险。有些系统虽然测试结果不理想,但基于成本及时间的考虑也会在评审会议中通过从而上线。

本节书摘来自异步社区《全栈性能测试修炼宝典 JMeter实战》一书中的第2章,第2.2节性能测试流程,作者ROAD_TESTING软件测试组 组稿 , 陈志勇 , 马利伟 , 万龙,更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.2 性能测试流程
做事情我们讲究方法,注重效益,例如生产企业会有流水线。做性能测试也一样,我们也有规范的流程,完全符合项目管理流程,图2-3所示是性能测试常规流程。


8c869ed736d90f606b063d70d83a9816cf2fac28

(1)业务学习:通过查看文档,手工操作系统来了解系统功能。

(2)需求分析:分析系统非功能需求,圈定性能测试的范围,了解系统性能指标。

(3)工作评估:工作量分解,评估工作量,计划资源投入(即需要多少人力,多少工作日来完成性能测试工作)。

(4)设计模型:圈定性能测试范围后,把业务模型映射成测试模型。

什么是测试模型呢?比如一个支付系统需要与银行的系统要进行交互(充值或者转出),由于银行不能够提供支持,我们会开发程序去代替银行系统功能(这就是挡板程序,Mock程序),保证此功能的性能测试能够开展;这个过程就是设计测试模型。

再比如,后面要讲到的实例项目Jforum论坛,根据需求我们了解到一般大家发帖或回帖前都会先登录,那么我们在开发脚本时就要把登录与发帖或回帖场景绑定在一起进行测试;这就是测试模型。通俗点说就是性能测试用例设计加性能测试实现方案,用例只关注业务,模型还需关注如何实现,是否具有可操作性,可验证性等问题最后我们还得根据不同的测试目的组合成不同的测试场景。

(5)计划编写:计划测试工作,在文档中明确列出测试范围、人力投入、持续时间、工作内容、风险评估、风险应对策略等。

(6)脚本开发:录制或者编写性能测试脚本(现在很多被测系统都是无法录制脚本的,我们需要手工开发脚本),开发测试挡板程序,开发测试程序等。有时候如果没有第三方工具可用,甚至需要开发测试程序或者工具。

(7)测试环境准备:性能测试环境准备包括服务器与负载机两部分,服务器是被测系统的运行平台(包括硬件与软件,比如应用服务器需要8Core,32G内存,中间件是Jboss7等),负载机是我们用来产生负载的机器,用来安装负载工具,运行测试脚本。

(8)测试数据准备:根据数据模型来准备被测系统的主数据与业务数据(主数据是保证业务能够运行畅通的基础,比如菜单、用户等数据;业务数据是运行业务产生的数据,比如订单;订单出库需要库存数据,库存数据也是业务数据。我们知道数据量变会引起性能的变化,在测试的时候往往要准备一些存量/历史业务数据,这些数据需要考虑数量与分布)。

(9)测试执行:测试执行是性能测试成败关键,同样脚本不同执行人员得出的结果可能差异较大。这些差异主要体现在场景设计与测试执行上。

(10)缺陷管理:对性能测试过程中发现的缺陷进行管理。

(11)性能分析:对性能测试过程中暴露出来的问题进行分析,找出原因。

(12)性能调优:性能测试工程师与开发人员一起来解决性能问题。

(13)测试报告:测试工作的重要交付件,对测试结果进行报告,主要包括常见的性能指标说明(TPS、RT、CPU Using……),发现的问题等。

性能测试主要交付件:

  • 测试计划;
  • 测试脚本;
  • 测试程序;
  • 测试报告或者阶段性测试报告。

如果性能测试执行过程比较长,换句话说性能测试过程中性能问题比较多,经过了多轮的性能调优,需要执行多次回归测试,那么在这个过程中需要提交阶段性测试报告。

(14)评审:对性能报告中的内容进行评审,确认问题、评估上线风险。有些系统虽然测试结果不理想,但基于成本及时间的考虑也会在评审会议中通过从而上线。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章