软件测试开发学习之旅----性能测试
Posted 赵jc
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试开发学习之旅----性能测试相关的知识，希望对你有一定的参考价值。
性能测试
性能测试基础
WHY： 为什么要进行性能测试
WHAT: 关注的性能测试内容
WHO: 哪些人员关注性能
WHERE: 性能测试的关注领域
WHEN: 何时进行性能测试
WHY：（为什么测试）
-
应用程序是否能够很快的响应用户的要求？
-
应用程序是否能处理预期的用户负载并有盈余能力？
-
应用程序是否能处理业务所需要的事务数量？
-
在预期和非预期的用户负载下，应用程序是否稳定？
-
是否能确保用户在真正使用软件时获得舒服的体验？
WHAT：（关注什么）
- 并发用户数/吞吐量平均响应时间
- 服务器资源占用情况可靠性、可扩展性
- 发现引起系统问题的原因,关注采用何种技术提高系统性能软、硬件配置是否合适（容量规划/硬件选型）
WHO：（谁关注）
- 开发人员
- 系统管理人员（操作系统、网络、服务器等等）
- 用户
- 业务人员
- 测试人员
WHERE:(关注领域)
- 能力验证
性能测试中最简单也是最常用的一个应用领域，主要关心的是“在给定的条件下，系统能否具有预期的表现”。
- 规划能力
规划能力领域与能力验证领域有些不同，其主要关心的是“应该如何才能使系统具有我们要求的性能能力”或 是“在某种可能发生的条件下，系统具有如何的性能能力
- 性能调优
主要应用于对系统性能进行调优。一般来说，性能调优活动会和其他领域的活动交杂在一起。是一种在开发 阶段和测试阶段都可能会涉及到的性能测试应用领域。
- 发现缺陷
主要该应用领域的主要目的是通过性能测试的手段来发现系统中存在的缺陷
WHEN：（何时测试）
- 功能测试中后期
概念和术语介绍
- 并发数
系统用户数：简单地说就是该系统的注册用户数。例如，BestTest论坛里存在6666个注册用户，他们可以是活跃 的，也可以是僵尸的。
- 响应时间（Reponse Time）
又叫请求响应时间：TTLB（time to last byte）对请求作出响应所需要的时间
网络传输（请求）时间+服务器处理（一层或多层）时间+网络传输（响应）时间。
- 事务响应时间（Transaction Reponse Time）
事务是指一组密切相关的操作组合。例如一次登录可能包含了多次HTTP请求，如：判断用户是否存在？密码是否正确？是否已登录？登录？等多个HTTP请求。
该数值对用户的意义更直观
- 每秒事务通过数（Transaction Per Second）
TPS 是指每秒系统能够处理的事务数。它是衡量系统处理能力的重要指标。
当压力加大时，TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈了。如果环境没有发生大的变化，对于同一系统会存在一个最大处理事务能力，它并不随着并发用户的增减而改变。
- 点击率（Hit Per Second）
每秒点击数代表用户每秒向Web 服务器提交的HTTP请求数。点击率越大，服务器压力越大。这里的点击并不是鼠标的一次点击，一次点击可能有多次HTTP请求。
- 吞吐量（Throughput）
单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力，一般来说用请求数/秒或是页面数/秒 来衡量，从业务的角度，也可以用访问人数/天或是处理的业务数/小时来衡量，从网络的角度来说，也可以用字节 数/天来衡量。
- 思考时间（Think Time）
思考时间就是用户进行操作时，每个请求或者操作之间的间隔时间，是为了更加真实地模拟用户的操作场景。 资源利用率
不同系统资源的使用情况。CPU,Memory，磁盘，网络。
性能测试模型
- 曲线拐点模型
- 地铁模型
性能测试分类介绍
基准测试
有基础的标准，这样能通过对比发现系统的不同点与变化。应用于以下场景：
- 可以在制定的标准下通过基准测试建立一个性能基准，这样以后当系统的环境、参数发生变化之后，再进行一 次相同标准下的测试，即可看出变化对性能的影响。
- 系统进行基准测试可以在较早的阶段发现性能问题。
- 某系统从来没有进行过任何性能测试，需要对该系统做一次性能评估作为后续开发调优的参考。
性能测试
是通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能能否满足生产系统要求。Performance Testing是一种常见的测试方法，就是在特定的运行条件下验证系统的能力情况。该测试是一种正常的测试，主要是测试系统正常使用时是否满足要求。
负载测试（Load Testing）
负载测试是在被测系统上不断增加压力，直到各项指标达到饱和，例如“响应时间”超过预定指标或者某种资源使用 已经达到饱和状态。这种测试方法可以找到系统的处理极限，为系统调优提供数据。
压力测试（StressTesting）
压力测试是测试系统在一定饱和状态下，例如cpu、内存等在饱和使用状态下，系统能够处理的会话能力，以及系 统能否会出现错误。压力测试与负载测试有些类似，经常把负载测试描述成压力测试的一种场景-例如增加用户数 对系统进行压力测试。压力测试的目的是为了揭露高负载下的问题，例如资源竞争、同步问题、内存泄漏等。
并发测试（Concurrency Testing）
并发测试是通过模拟用户的并发访问，测试多用户并发访问同一个应用，同一个模块或者数据记录时是否存在死锁 或者其他性能问题。
配置测试（ConfigurationTesting）
配置测试方法是通过被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到各项资 源的最优分配原则
例如在测试执行时更换、扩充硬件设备，调整网络环境、调整应用服务器和数据库服务器的参数设置，比较每次测 试结果，从而确定各个因素对系统性能的影响。
可靠性测试（Reliability Testing）
可靠性测试是通过给系统加载一定的业务压力（例如资源在70%-90%的使用率）的情况下，让应用系统持续运行一段时间，测试系统在这种条件下是否能够稳定运行。
失效恢复测试（Failover Testing）
- 失效恢复测试方法是针对有备份和负载均衡的系统设计的，这种测试方法可以用来检验如果系统局部发生故障， 用户能否继续使用系统，以及如果这种情况发生，用户将受到多大程度的影响。
- 一般的关键业务系统都会采用热备份或是负载均衡的方式来实现。这种业务系统一般要求有一台或几台服务器出 现问题，应用系统仍然可以正常执行业务。该方法就是在测试中模拟设备故障，验证预期的恢复技术是否可以正常 发挥作用
- 不是所有的系统都需要进行这种类型的测试，尤其是并没有明确给出系统需要持续运行指标的系统
性能测试实施与管理
性能测试前期准备
测试工具引入
测试方案
测试设计与开发
测试执行与管理
测试分析与调优
测试报告
性能测试前期准备
- 系统基础功能验证
确保当前需要进行测试的应用系统具备了进行性能测试的条件确保当前进行性能测试的应用系统版本已经稳定；必须保证性能测试之前至少进行了一轮的系统功能覆盖测试，且性能测试选取的业务功能正常。
- 组建测试团队
确定团队内角色的构成，以及确定人员的技能
- 测试工具需求确认
根据被测系统的了解，评估性能测试工具所应具备的功能
测试工具引入
- 工具选择
选择适合项目的性能测试工具，商业工具或者是自行开发的工具，Loadrunner，jmeter
- 工具应用技能培训
为项目组的相关参与者进行测试工具的应用技能培训，以使参与者能够具备测试需要的技能
- 确定工具应用过程
确定测试工具在测试中的具体应用范围，并不是“工具无所不能”，哪些工作使用工具完成，哪些无法使用工具完成
性能测试方案
- 1、调研测试需求
- 2、测试策略和测试资源需求
- 3、性能测试计划
性能测试设计与开发
- 1.测试环境设计
- 2.测试场景设计（测试用例）
- 3.脚本开发
- 4.脚本和辅助工具开发
性能测试执行与管理
- 1.建立测试环境
- 2.部署测试脚本和测试场景
- 3.执行测试和记录结果
性能测试分析与调优
测试结果分析是最难的部分。是一个灵活的过程，每次性能测试结果的分析都需要测试分析人员具有相当程度的对 软件性能、软件架构和各种性能测试指标的了解，性能测试分析需要借助各种图表。
通用方法之一就是“拐点分析的”方法。关注性能表现上的“拐点”，获得“拐点”附近使用情况，定位处系统的性能瓶颈。
性能测试报告
- 测试目标
指标要求:本次测试预期达到的性能要求。 (TPS,ART，交易成功率，并发数等）
- 测试概要描述
系统结构测试时间
测试地点和测试人员
工具和环境测试过程简介
- 测试结果和数据
- 测试结论
测试遗留问题
建议
测试结论限制
以上是关于软件测试开发学习之旅----性能测试的主要内容，如果未能解决你的问题，请参考以下文章