测试|性能测试相关理论
测试|性能测试相关理论（了解）
文章目录
- 测试|性能测试相关理论（了解）
-
- 1.什么是性能测试
-
- 生活中遇到的软件性能问题：
- 性能测试定义：
- 性能测试和功能测试有什么区别：
- 性能好坏的评价指标
- 影响一个软件性能因素有哪些
- 2.为什么要做性能测试（了解）
- 3.性能测试的常见术语及性能测试衡量指标☆☆☆☆☆
-
- 并发用户数
- 响应时间/平均响应时间（RT /ART）
- 事务响应时间&每秒事务通过数
- 点击率&吞吐量&资源利用率
- 思考时间
- 4.性能测试分类☆☆☆（会区分即可）
-
- 1.基准性能测试
- 2.负载性能测试
- 3.压力性能测试
- 4.可靠性测试
- 5.性能测试执行流程
- 6.如何确定性能测试的需求（了解）
1.什么是性能测试
生活中遇到的软件性能问题：
软件崩了eg.淘宝崩了，抖音崩了【服务器崩了】
性能测试定义：
测试人员借助性能测试工具，模拟系统在不同场景下，对应的性能指标是否达到预期。
性能测试和功能测试有什么区别：
对于一个产品，我们一般考虑它的功能，界面，易用，兼容，性能，安全，网络，中断几个维度，其中功能和界面相关我们一般使用手工测试，也可以使用自动化测试，而性能测试一般是使用工具完成。
自动化测试（UI自动化测试，接口自动化，单元自动化）一般都是指功能的自动化测试。
- 功能测试依靠人工执行，而性能测试依靠工具完成；
- 功能测试不管在什么场景下，只要能够正常运行即可，而性能测试需要软件在一些极端的情况下也能够正常运行
性能好坏的评价指标
- 系统/事务的平均响应时间
- 事务处理效率TPS（transaction per second）
- 吞吐率
- 每秒点击次数
- 服务器资源占用情况，内存和CPU使用率
- 软硬件配置是否合适
DAU：day active user，日活跃用户数
12306（并发量太大）：减少并发数，软件算法优化，服务器升级
影响一个软件性能因素有哪些
- 硬件：服务器CPU利用率，CPU核心数，内存，磁盘操作频率，
- 软件：算法，编程语言
- 用户：用户数量，用户使用时长，用户访问频率
2.为什么要做性能测试（了解）
- 系统正常工作的情况下最大容量
- 发现系统的性能瓶颈，内存泄漏等问题
- 帮助运维部门能更好的规划硬件配置
- 验证系统性能指标是否达到要求
- 应用程序是否能满足系统要求的各种性能指标
- 应用程序是否能处理预期的用户负载并有盈余能力
- 应用程序是否能处理业务所需要的事务数量
- 在预期和非预期用户负载下，应用程序是否稳定
- 是否能确保用户在真正使用软件时获得舒服的体验
3.性能测试的常见术语及性能测试衡量指标☆☆☆☆☆
性能测试工作实质上是利用工具去模拟大量用户操作来验证系统能够承受的负载情况，找出潜在的性能问题分析并解决；找出系统性能变化趋势，为后续的扩展做准备 。
并发用户数
并发用户数&在线用户数&系统用户数区别：
系统用户数：即系统注册用户数。可以是活跃用户也可以是僵尸用户数
在线用户数：成功登录系统的用户数
并发用户数:大量用户访问系统，区分业务层面和后端服务器层间
业务层面的并发用户数：指的是同时向服务器发送请求的用户数量。
后端服务器层面的并发用户数：指的是同时向服务器发送请求的请求数量一般来说，一个业务的完成可能会向服务器发送好几个请求
并发用户数即大量用户同时访问系统。并发用户对系统造成压力。
响应时间/平均响应时间（RT /ART）
rt:response time art:average response time
1.用户响应时间（前端性能评估）
N1+A1+N2+A2+A3+N3+N4
即应用系统从发起请求开始，到客户端接收完所有字节数据，并渲染前端页面所耗费的时间
2.请求响应时间（服务器端性能评估）
A1+N2+A2+A3+N3
即web服务器，应用服务器，数据库服务器等各种服务器之间通信和处理请求的时间。
3.影响软件响应时间因素
- 数据库性能
- 网络带宽
- 服务器处理性能
- 软件算法
- 用户设备
事务响应时间&每秒事务通过数
358定律：
每秒事务通过数：每秒系统能够处理的事务数
点击率&吞吐量&资源利用率
点击率：Hit Per Second ，用户每秒向web服务器提交的HTTP请求数点击率越大，服务器压力越大。（不是点击量）
注：这里的点击不是鼠标的一次点击，一次点击可能有多次HTTP请求。
吞吐量：Throughput ，用户一次请求和服务器之间的数据交互量（network size）
资源利用率：cpu、内存、硬盘、网络等不同系统资源的使用情况。
思考时间
思考时间：用户在进行操作时，每个请求之间的间隔时间
4.性能测试分类☆☆☆（会区分即可）
以下为常见性能测试
1.基准性能测试
即让系统在正常情况下运行，观察软件性能指标。
应用场景：软件刚上线时进行性能摸底
2.负载性能测试
即验证软件在一定压力情况下运行，观察性能指标是否出现了拐点
3.压力性能测试
即系统处于饱和情况下，观察系统性能指标。
往往会把系统搞崩溃。
4.可靠性测试
验证系统在一个持续时间段内运行，观察系统各项性能指标是否正常。（4个9,5个9）
（通常会使用工具）在一定压力下。
持续1天—>持续运行1周—>持续运行1个月—>一个季度—>1年
若崩溃了，会不会影响后边的业务。
5.性能测试执行流程
功能测试执行流程：需求分析–>测试计划–>测试设计–>测试执行–>测试评估（测试报告）–>上线
性能测试执行流程：需求分析–>测试计划–>选择一款性能测试工具–>性能测试脚本编写–>产出一个性能测试报告
性能测试中出现了不符合预期的情况，不叫它bug，叫性能瓶颈
性能测试中，出现性能瓶颈，开发修复的过程，叫优化
性能测试是在功能测试完全通过的前提下进行的。
6.如何确定性能测试的需求（了解）
1.关键性能指标分析
需要明确而量化的性能指标，只有这样才具备可测试性，可验证性。
一组清晰定义的预期性能指标量，是性能测试的基本要素。
如果是一个全新的应用系统，无法确定具体的性能指标怎么办？
（1）可以通过“基时准测试”，获取性能指标数据 （2）从业务，用户体验，竞品的的性能指标信息来定义性能指标的数据 。
2.关键业务分析
如果在某一些业务功能上不出现性能问题，那么系统就不会出现性能问题，而
这些业务功能就是系统性能测试的关键业务所在。 根据帕雷托法则（pareto Principle)，系统中各个功能的使用频率是不相同的，有20%的功能是常用的
功能，用户80%以上的时间都在使用这些功能，这些功能就是性能测试当中我们测试人员需要关注的。
所以，要确定性能测试的关键业务要从业务功能的使用频率，功能的计算量和资源的消耗程度来决定，确定好关键业务之后，我们在进行性能测试的时候只要对关键的业务进行测试用例的设计，系统的性能测试脚本就会基于这些关键的业务进行开发 。