• 性能测试之思


    最近工作之余,对以往的性能测试相关知识做了整理和复盘,发现了很多之前没认真思考过的小细节,整理出来,以供参考。。。

     

    1、如何理解性能指标?

    在性能测试中,涉及的性能指标有很多,强行记忆理解可能是一件很吃力的事情。对性能指标进行分层划分,这样有助于记忆和理解。

    在体育运动中,我们都知道提倡“更高、更快、更强”,其实对于系统的性能,我们也可以这么理解,大概分层如下:

    分层 说明
    更高 资源:CPU%、Memery%、I/O
    更快 速度:TPS、RT/ART
    更强 容量、PV、Hit

     

    2、层层分析性能瓶颈

    软件应用是一个很复杂的东西,影响性能表现的因素更多,直接影响OR间接影响,在分析过程中都是需要注意的。下面是一些比较常用的分析方法:

    ①、分层梳理

    梳理层次 举例说明
    业务梳理 业务配比、依赖关系角度
    数据梳理 真实数据统计准确性、测试数据失效过期、数据污染
    架构梳理 缓存、集群、负载均衡、分布式、微服务、异步通信、网关
    参数梳理 最大连接数、最大线程数、JVM内存分配、timeout、异常/失败重试次数
    场景梳理 异常场景、容量场景、基准场景、并发场景、稳定性场景、多节点场景、容灾恢复场景

    ②、模块梳理

    组成模块 举例说明
    负载机 高并发下,负载机可能成为限制性能提升的瓶颈
    网络 高吞吐量下,网络带宽的不足会成为性能提升的瓶颈
    中间件 缓存策略、代理分发策略、服务通信策略
    服务器 CPU、Memory
    数据库 索引、锁、分库分表、视图、实例等
    操作系统 文件I/O、buffer、cached等

    3、性能测试的方法论

    ①、性能测试场景一定要基于真实环境来模拟;

    ②、性能测试场景一定要基于具体清晰的指标来构建;

    ③、场景建模是分析的结果,性能需求分析是场景建模的前提;

    ④、开展性能测试之前,要设定统一的目标、分析方法、条理分明的流程以及高度的团队协作和任务分配;

    ⑤、性能测试,执行监控分析是核心;

    4、什么时候需要关联

    ①、服务端value动态返回;

    ②、数据在后续执行中需要引用;

    ③、业务场景有前后依赖关系;

    5、如何理解ThinkTime?

    ①、要不要添加ThinkTime?

    ②、什么时候用到ThinkTime?

    ③、用ThinkTime会有什么效果?

    ④、ThinkTime是否匹配真实业务场景?

    ⑤、ThinkTime是否会影响到服务器资源?

    6、你真的了解测试目的么?

    ①、在什么环境/条件下执行测试?(硬件配置、软件版本/参数、测试环境)

    ②、被测试的系统业务场景是什么?是否要剔除不必要的业务?

    ③、如果保证数据的真实性、有效性?如何避免数据污染带来的影响?

    ④、测试策略真的符合预期的目的么?

    ⑤、系统的性能表现真的符合实际的生产场景么?如何量化?

    以上就是一些最近思考整理的问题,仅供参考,后续如有新的思考点,会更新,就酱。。。

     

  • 相关阅读:
    .NET Core 使用Dapper 操作MySQL
    .NET Core HtmlAgilityPack HTML解析利器
    ASP.NET Core 开发-缓存(Caching)
    .NET Core 调用WCF 服务
    ASP.NET Core 开发-Logging 使用NLog 写日志文件
    Qt动态生成界面并通过拉姆达获取其返回值
    Qt启动C++线程并在线程中修改界面
    Vector求最大值最小值
    C/C++取消结构体字节对齐
    Matlab定时器
  • 原文地址:https://www.cnblogs.com/imyalost/p/9912382.html
Copyright © 2020-2023  润新知