组合场景的性能测试模型（测试场景分析）

本篇文章给大家谈谈组合场景的性能测试模型，以及测试场景分析对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享组合场景的性能测试模型的知识，其中也会对测试场景分析进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、jmeter混合场景性能测试
• 2、性能测试包括哪些方面
• 3、性能测试场景
• 4、性能测试基础概念1
• 5、性能测试常用哪些测试用例设计方法
• 6、性能测试方法及目标（转载）

jmeter混合场景性能测试

性能测试设计混合场景，一般有几种方式

分别是：1：每个场景设置一个线程组；2：使用if控制器；3：使用吞吐量控制器。

不同的方式实现机制不一样，个人觉得“使用吞吐量控制器”比较方便

场景设置：混合访问百度首页和cnblogs首页，按比例实现100个用户的并发压测，比例为：4:1

以下讲解下具体的方法

方法1：每个场景设置一个线程组

设置两个单独的线程组，线程组一请求百度首页（并发线程数设置80个），线程组二请求cnblogs（并发线程数设置20个）。

添加监听器-聚合报告，运行后查看报告，我们可以看到百度请求样本数80个，cnblogs请求样本数20个，这两个请求的比例为4:1

方法2：使用if控制器

步骤1：新建线程组，线程组下新建两个if控制器

步骤2：分别在两个if控制器下添加http请求

步骤3：在线程组下新建一个：随机变量，设置随机范围0-100，后续通过随机变量在if控制器中配置条件

步骤4：if控制器1取到变量，设置${num}20执行百度请求，if控制器2取到变量，设置${num}<20执行cnblogs请求

步骤5：设置线程数为100，添加聚合报告查看执行结果，由于我们使用的是随机变量，所以得出的结果无法达到100%相等，但可以从样本数中看出，两个请求的样本比大概为4:1

方法3：使用吞吐量控制器

步骤1：添加吞吐量控制器1

步骤2：在控制器下添加http请求，访问百度首页

步骤3：再添加一个吞吐量控制器2

步骤4：该控制器下添加http请求，访问cnblogs

步骤5：设置线程数量100个，设置吞吐量控制器1-吞吐量80，设置吞吐量控制器2-吞吐量20（注：吞吐量设置选Total Executions以个数计算，选percent Executions则以百分比来算的，设置80即总线程数的80%）

步骤6：线程组下添加监听器查看结果

运行结果后，我们可以看到访问baidu的http请求执行了80次，访问cnblogs的http请求执行了20次

性能测试包括哪些方面

性能测试包括负载测试和压力测试。
性能测试是通过自动化组合场景的性能测试模型的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面组合场景的性能测试模型：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

性能测试场景

提到性能测试，常会提到压力测试、负载测试、稳定性测试、配置测试等等，但说到其各自组合场景的性能测试模型的定义，实在是晦涩难懂。但若将性能测试，看作是在不同的场景下执行系统，获取系统的性能指标，再对数据进行监控分析的过程，就比较好理解组合场景的性能测试模型了。
性能测试场景可以分为四类。

RT

线程

从上面的图可以得到以下判断组合场景的性能测试模型：

4.重复以上步骤测试每一个业务，得到结果表格

Q组合场景的性能测试模型：业务目标TPS和响应时间怎么定？
A：方法一：找同行业对比数据。方法二：到生产环境看用户使用情况并统计信息

Q：怎么得到业务比例？
A：根据生产环境的请求统计信息

Q：测试时为什么要逐步增压？
A：保证在测试过程中资源分配的合理性，可以看到整体的变化过程，例如递增过程中会不会出现系统动荡，便于分析性能瓶颈。

混合场景下，业务的TPS并没有达到预期，此处应进行分析调优。

确定场景的运行时间长度的加压数
运行时长取决于系统上线后的运维周期。例如指标是稳定运行一周，支持100万业务量。之前容量TPS能达到168，所以时长应该是10000000/168=6250秒=1.8小时。

Q：为什么用最大容量TPS跑稳定性？
A：有的观点是用最大TPS的80%去跑稳定性。跑稳定性的目的就是看系统会不会因为长时间处理业务而引发潜在瓶颈。只要系统正常处理，资源没有出问题也没有报错，就可以用最大TPS去跑。

性能测试基础概念1

性能测试针对系统的性能指标，建立性能测试模型，制定性能测试方案，制定监控策略，在场景条件之下执行性能场景，分析判断性能瓶颈并调优，最终得出性能结果来评估系统的性能指标是否满足既定值
步骤：

在线用户数、并发用户数、压力线程数、TPS的关系如下：

1.单个用户的TPS计算：通过日志，拉取一个用户的操作记录，记录下来一个事务的操作时间。例如：1个用户，100秒内，完成了一个完整流程，有4个操作（查询商品、填写信息、支付、订单详情），调用了20个接口。
用户级TPS：1 1/100=0.01TPS。 (1个用户) （1个完成业务）/100s
操作级： 1 4/100=0.04 TPS. (1个用户) （4个操作）/100s
接口级： 1 20/100=0.2TPS (1个用户) （20个接口）/100s

2.多用户的TPS。从生产拉取1天的用户量，记算下平均完成的时间（这会有一个问题就是很多用户没有真实走完一个完整业务，所以这个TPS计算是要注意？为了方便仅做假设每个用户是在100秒内完成）假如有一100万的用户，在1天内完成业务
用户级TPS：1000000 1 1/24/60/60=11.57TPS。 1000000 (1个用户) （1个完成业务）/24小时/60分钟/60秒
操作级： 1000000 1 4/24/60/60=46.29 TPS. 1000000* (1个用户) （4个操作）/24小时/60分钟/60秒
接口级： 1000000 1 20/24/60/60=231.48TPS 1000000 (1个用户)*（20个接口）/24小时/60分钟/60秒

3.峰值时的TPS。 1000人，在1分钟内完成业务
用户级TPS：1000 1 1/60=16.67TPS。 1000 (1个用户) （1个完成业务）/60秒
操作级： 1000 1 4/60=66.67 TPS. 1000* (1个用户) （4个操作）/60秒
接口级： 1000 1 20/60=333.33TPS 1000 (1个用户)*（20个接口）/60秒

4,怎么计算并发用户数和TPS之间的关系。
假如在jmeter中，完成一个完整的流程5秒钟。
用户级TPS：1 1/5=0.2TPS。 (1个用户) （1个完成业务）/5s
操作级： 1 4/5=0.8 TPS. (1个用户) （4个操作）/5s
接口级： 1 20/5=4 TPS (1个用户) （20个接口）/5s

5,无停顿（并发用户）相当于多少有停顿的用户（在线用户）
0.2/0.01=20. 即无停顿TPS/有停顿TPS。
并发度=1/20*100% =5%

6.压力线程数
a)100万在1天内：1000000的在线TPS/并发TPS=11.57/0.2=57.85
b)1000在1分钟内： 1000的峰值TPS/并发TPS=16.67/0.2=83.35

7.并发用户数的计算
并发用户数=在线用户数×有停顿时间的单线程TPS/无停顿时间的单线程TPS

8.并发度：并发度=并发用户/在线用户×100%（取值要在同一时间段）

1.抽取业务模型，可以通过日志系统或埋点等手段获取。
2.业务模型的作用：一是评估线上的性能；二是为后面的容量测试做准备

也可称之为混合容量性能场景，即将所有业务根据比例加到一个场景中，在数据、软硬件环境、监控等的配合之下，分析瓶颈并调优的过程。
1，业务指标

2，对各业务进行基准性能场景测试，对各业务基线测试，并优化以满足业务性能指标
3，抽取线上业务模型
4，根据业务模型，编写执行脚本，进行容量测试

核心就是时长。在长时间的运行之下，观察系统的性能表现，分析瓶颈并调优的过程

1，根据实际的业务需求设置。如我们每周一个发布周期，平均2个月所有的业务线会发布一次（即服务器重启）。那么我们的稳定性测试的策略应该是以最大TPS，执行7~30天。不可少于7天。但可以多于30天。
2,为什么以容量测试的最大TPS？ 如果容量测试下来的最大TPS不能稳定执行，其容量测试的结果又什么意义？

性能测试常用哪些测试用例设计方法

1. 等价类划分
常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题
详细的描述一个测试活动完整的过程。1. 项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功

性能测试方法及目标（转载）

基准测试是基于一定规模的数据量上进行单业务或按实际用户操作同比例组合业务的测试，目的在于量化响应时间、吞吐率的指标，便于后续比对。
方法是做多组不同场景的测试，观察结果，抽取出几个关键数据做好记彔，用于以后进行性能对比和评价。

通过模拟生产运行的业务压力量和使用场景组合，测试系统的性能是否满足生产性能要求。
特点：
（1） 主要目的是验证系统是否具有系统宣称的能力。
（2） 需要事先了解被测系统的典型场景，并具有确定的性能目标。
（3） 要求在已确定的环境下运行。

通过在被测系统上不断增加压力，直到性能指标，例如“响应时间”超过预定指标或者某种资源使用已经达到饱和状态。
特点：
（1） 主要目的是找到系统处理能力的极限。
（2） 需要在给定的测试环境下进行，通常也需要考虑被测系统的业务压力量和典型场景，使得测试结果具有业务上的意义。
（3） 一般用来了解系统的性能容量，或是配合性能调优使用。

测试系统在一定饱和状态下，例如CPU、内存等在饱和使用情况下，系统能够处理的会话能力，以及系统是否会出现错误。
特点：
（1） 主要目的是检查系统处于压力情况下是应用的表现。
（2） 一般通过模拟负载等方法，使得系统的资源使用达到较高水平。
（3） 一般用于测试系统的稳定性。

通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响的程度，从而找到系统各项资源的最优分配原则。
特点：
（1） 主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行得调优操作。
（2） 一般在对系统性能状况有初步了解后进行。
（3） 一般用于性能调优和规划能力。

通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。
特点：
（1） 主要目的是发现系统中可能隐藏的并发访问时的问题。
（2） 主要关注系统可能存在的并发问题，例如系统中的内存泄露、线程锁和资源争用方面的问题。
（3） 可在在开发的各个阶段使用，需要相关的测试工具的配合和支持。

通过给系统加载一定的业务压力（例如资源在70%~90%的使用率）的情况下，让应用持续运行一段时间，测试系统在这种条件下是否能稳定运行。
特点：
（1） 主要目的是验证系统是否支持长期稳定的运行。
（2） 需要在压力下持续一段时间的运行。
（3） 需要关注系统的运行状况。

针对有冗余备份和负载均衡的系统设计的，可以用来检验如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。
特点：
（1） 主要目的是验证在局部故障情况下，系统能否继续使用。
（2） 还需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。
（3） 一般来说，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。 关于组合场景的性能测试模型和测试场景分析的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 组合场景的性能测试模型的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于测试场景分析、组合场景的性能测试模型的信息别忘了在本站进行查找喔。