《大型IT系统性能测试入门经典》学习笔记01——性能测试兵法篇(一)

1 性能测试基础

1. 1软件性能测试简介

1. 技能掌握:LR、Jmeter性能测试工具使用
2. 具备一定的程序开发能力
3. 掌握主流数据库的使用和基础调优方法
4. 掌握linux操作系统的使用和基础调优方法
5. 掌握应用服务器的使用和基础调优方法
6. 综合分析与定位系统性能问题的能力
7. 掌握制定合适的性能测试策略以及性能测试方案

1.2 性能测试典型术语:

并发用户

    两种情况:
    一种是严格意义上的并发,即所有的用户在同一时刻做同一件事情或者操作,这种操作一般是指做同一类型的业务,操作的不是同一记录。特例:即所有用户进行完全一样的操作。
    另一种并发是广义范围的并发。这种并发与前一种并发的区别是尽管多个用户对系统发出了请求或者进行了操作,但是这些请求或者操作既可以是相同的,也可以是不同的。
    性能测试过程中,一般先进行严格意义上的并发测试,即在使用高频功能模块中。严格意义上的并发测试都是和功能测试关联起来。

用户并发数量

    误区:一种观点是把并发用户数量理解为使用系统的全部用户的数量。还有一种把在线用户数量理解为并发用户数量。
    用户并发数量的正确理解是在同一时刻与服务器进行交互的在线用户数量。这些用户的最大特征是和服务器发生了交互。经验公式为:使用系统的用户数量X(5%-10%)

请求响应时间

    客户端发起请求到得到响应的整个过程的时间。请求响应时间通常被称为:TTLB, Time to Last Byte.

事务响应时间

    事务可能是由一系列请求组成,事务的响应时间主要是针对用户而言,属于宏观上的概念。主要为了向用户说明业务响应时间而提出的。

吞吐量

    一次性能测试过程中,网络上传输的数据流量的总和。吞吐量/传输时间,就是吞吐率。

吞吐率(Throughput)

    通常用来指单位时间内网络上传输的数据流量,特定条件下也可以用来指单位时间内处理的客户端请求数量。吞吐率可以用“字节数/秒” “请求数/秒” “页面数/秒”来衡量。从业务角度,也可以用“业务数/小时或天” “访问量/天”

TPS(Transaction Per Second)

    每秒钟系统能够处理的交易或者事务的数量。

点击率(Hit Per Second)

    每秒钟用户向服务器提交的HTTP请求数,这里的点击不是指鼠标的一次“单击”,因为在一次”单击“操作中,客户端可能向服务器发出多个HTTP请求。

资源利用率

    资源利用率是指对不同系统资源的使用程度,主要针对Web服务器、操作系统、数据库服务器、网络等。

1.3 软件性能测试种类

压力测试

    对系统不断施加压力的测试,是通过确定一个系统的瓶颈或者不能接受用户请求的性能点,来获得系统能提供的最大服务级别的测试。 目标:为了发现在什么条件下应用程序的性能会变得不可接受,发现应用程序性能下降的拐点。

负载测试

    通过在被测系统上不断增加压力,直到性能指标达到极限。

强度测试

    测试系统在异常情况下的处理能力,对评估系统的稳定性、健壮性、扩展性均具有重要的意义。

大数据量测试

    一种是针对某些系统的新建记录、统计查询等业务进行的运行时大数据量测试,一种是历史大数据量测试,测试存量数据达到一定量级下的性能。

并发测试

    主要用来测试多用户同时访问同一系统/同一模块/同一业务功能/同一数据记录时是否存在性能问题,几乎所有的性能测试都会涉及并发测试

可靠性测试

    测试系统在一定压力下长时间运行后是否稳定可靠,例如:使CPU保持70%——90%利用率的压力,连续对系统加压7X24小时的测试

配置测试

    通过测试找到系统各项资源的最优分配原则,其测试结果是系统生产环境参数配置的重要依据。

狭义性能测试

    主要用来描述常规的性能测试,通过模拟生产运行时的使用场景和业务压力来测试系统的性能是否满足生产性能要求。

1.4 常见性能测试误区

  1. 提高硬件配置就可以提高性能了,因此性能测试不重要
  2. 性能测试在所有其他测试完成后,测试一下看看就可以了
  3. 性能测试独立于功能测试
  4. 性能测试就是并发测试
  5. 在开发环境下进行一下性能测试就可以了
  6. 系统存在瓶颈,不可以使用
  7. 不切实际的性能指标

1.5系统性能调整基础

所谓性能调整是为了改变系统特性而对系统软件或者硬件进行的修改,性能调整不是测试人员的职责。性能测试工程师的主要任务是发现并定位性能问题。

确定问题

    应用程序代码
    数据库配置
    操作系统配置
    硬件设置
    网络

确定原因

    问题的影响是什么,是响应时间还是业务吞吐量,或者是其他问题
    是大多数用户还是少数用户遇到了问题,如果是少数用户,这几个用户与其他用户的操作有什么不同?
    系统资源监控的结果是否正常:CPU的使用是否到了极限?I/O情况如何?
    问题是否集中在某一类模块中?
    是客户端还是服务器出现了问题?
    系统硬件配置是否够用?
    是否实际负载超过了系统的负载能力?
    是否未对系统进行优化?

确认调整目标和解决方案

    确认调整目标的作用是明确何时停止调整系统,否则工作将永无尽头。

测试解决方案

    实施解决方案后,就要对方案进行测试。使用以前的测试场景来进行测试,验证系统是否解决了性能问题。

分析调整结果

    分析调整结果,如果没有解决问题,则要重复前面的工作。
    系统调整是否达到或者超出了预定目标?
    系统是整体性能得到了改善,还是牺牲部分性能来解决问题?
    调整是否可以结束了?


评论(0 ) 点赞(16)


暂未登录,请登录之后发表评论。 QQ