zoukankan      html  css  js  c++  java
  • 性能测试需求重点分析

    性能需求指标描述分析
    性能测试需求的描述是需要有一定的规范的,否则提取到的需求就是无效需求。性能测试需求满足一下要求:
    1.准确:如系统必须在不超过10秒的时间内完成200个用户的登录,再比如50个并发查询报告的响应时间最大不超过3秒

    2.一致:开发工程师,用户和性能测试工程师对有关术语的理解要一致,如并发用户数,在线用户,注册用户。例如,系统支持300用户并发操作,系统的在线用户为3500,系统的注册用户是120万

    3.特定:性能测试的需求一定是有条件的,不同逻辑复杂程度,不同数据量传输下的性能肯定是不一致的,一个单笔往数据库进行5000个插入(insert)操作的功能与一个单笔只往数据库进行10个插入操作的性能要求肯定是不一样的

    性能需求来源分析方法
    一,开发过程相关文档
    这是性能测试需求的基本来源,项目开发计划书、需求规格说明书、设计说明书、测试计划等文档都可能涉及性能测试的要求。通过收集这些资料,可以找到初步的性能需求。

    通常我们把需求文档作为性能测试需求的主要来源,但这只是基本的来源而已,因为产品人员、需求人员一般都不懂软件性能,所以提出的性能测试需求也往往不准确,需要性能测试人员进行专业的引导,这也是性能测试人员的价值所在

    二,相似项目性能需求
    公司的其他产品或以往项目会累积出一些数据,一些公司对外公布的数据也可以作为性能测试需求的参考源。比如要做微博项目,那么可以参考新浪微博披露的官方数据
    性能测试完全可以从这种其他类似项目的数据中提取出一些性能测试需求点作为自己公司项目的性能测试参考数据

    三,业界公认标准

    如响应时间,根据服务器的不同和项目的具体情况可有以下两类标准

    A类严格标准 B类宽松标准
    2秒以内,用户感觉良好 8秒以内,用户可接受
    2~5秒,用户觉得可以接受 8~16秒,50%用户选择离开
    5~10秒,用户会觉得烦躁,会无法接受,从而导致频繁地刷新页面 32秒后,90%用户离开
    超过10秒,用户完全无法忍受,直接离开  

    四,用户使用模型
    性能测试要通过一系列场景的执行来完成,分析用户的使用模型是获取性能测试需求的有效手段,即定义系统的典型使用方式,考虑哪些用户使用系统的哪些典型业务,在什么时间段有多少用户进行了什么功能的操作。
    因此需要性能测试人员和最终使用的用户很好地沟通,最好能够考察用户的应用情况。

    五,80/20原则
    80/20原理就是系统在每个工作日有80%的业务是在20%的时间内集中完成,或者系统80%的用户会在20%的时间内集中进行应用操作

    举例:某系统每年业务量集中在8个月内完成,每个月平均有20个工作日,每个工作日8小时,按照80/20原则,即每天80%的业务在1.6小时完成。
    去年全年处理业务约100万笔,其中15%的业务处理中,每笔业务需对应用服务器提交7次请求;
    其中70%的业务处理中,每笔业务需对应用服务器提交5次请求;
    其余15%的业务处理中,每笔业务需对应用服务器提交3次请求。

    根据以往统计结果,每年的业务增量为15%,考虑到今后3年业务发展的需要,测试需按现有业务量的两倍计算请求数。
    每年总的请求数为: (100x15%×7+100x70%x5+100× 15%x3)x2=1000万次/年。每天请求数为: 1000/ (20x8) =6.25万次/天,每秒请求数为: (62500x80%) / (8x20% ×3600) =9.68次/秒,即服务器处理请求的能力应达到9次/秒。从而确定系统的TPS为9

    六,业务分时图
    业务分时图是以一种直观的方式展示性能测试需求,描述一些交易任务在24小时内的交易情况,重点关注并发用户的数量和典型的业务操作

     

    七,系统日志
    现在日志分析是越来越重要的性能测试需求获取手段,大型公司,越来越重视日志分析。数据挖掘中很重要的一点就是对日志进行分析,然后分析用户使用行为。
    通过分析日志,可以帮助性能测试人员快速获取系统性能参数,如并发量、响应时间、业务分布情况等,日志分析也能用于帮助性能测试人员进行性能预警和容量规划工作

    性能需求确定
    由于FLYUN项目是进行优化,属于性能升级改造类型的项目,所以我们首先进行的是日志分析的活动。
    通过对线上日志的分析总结,我们得到了如下的图表

    初步获取了并发量,还不够,因为性能测试需求要么是单位并发下测试系统的响应时间是否满足一定水平值,要么是单位响应时间内测试系统的最大并发量是否满足一定的指标值,或者是测试系统在单位时间内的TPS情况
    因此,在获取性能测试的并发量后,还要获取系统的响应时间,从而形成初步的性能测试目标。

    我们取的响应时间同样从系统的线上日志中进行分析获取,这是因为从日志分析中获取到的平均响应时间满足系统当前使用用户的性能需求
    对线上日志分析得到的网页访问的平均响应时间是3827.8ms,登陆响应时间平均为1772.9ms

    通过上面的分析,我们可以得到初步的性能需求如下:
    1,登录:要求最少支持19并发,响应时间2s内
    2,数据库单条写操作:要求最少支持41并发,响应时间2s内
    3·数据库批量写操作:要求最少支持9并发,响应时间5s内
    4·数据库读操作:要求最少支持65并发,响应时间4s内
    5·整体1s内最大并发用户为117,对应混合场景,按比例分配用户

    公司业务在发展,用户数增多, pv增加,并发量也要随之增加,最终的需求如下:
    1.登录:要求支持60并发,响应时间2s内
    2,数据库单条写操作:要求最少支持120并发,响应时间2s内
    3,数据库批量写操作:要求最少支持20并发,响应时间5s内
    4·数据库读操作:要求最少支持190并发,响应时间4s内

  • 相关阅读:
    repeater 结合checkbox批量删除
    (转)用JS判断ckeditor3.6版本编辑器内容为空的方法
    把数据库中的null作为条件查询应该用is
    注意 reader["yjID"] == DBNull.Value而不是null
    (转)第三方登录(QQ登录)开发流程详解
    (转)TortoiseSVN使用简介
    dropdownlist 二级联动
    关于服务器防火墙和discuz论坛的问题
    (转)Discuz!NT图文安装教程
    maven 基础
  • 原文地址:https://www.cnblogs.com/lvchengda/p/12728841.html
Copyright © 2011-2022 走看看