性能测试中的并发用户数、交易响应时间、TPS每秒交易_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
性能测试中的并发用户数、交易响应时间、TPS每秒交易
阅读已结束，如果下载本文需要使用
想免费下载本文？
你可能喜欢性能测试用户模型
每天15篇文章
不仅获得谋生技能
更可以追随信仰
性能测试用户模型
在性能测试过程中，很重要的一个部分就是评估待测系统在一定压力下的性能表现。比如系统上线后，真实的性能到底如何？两年后系统的使用用户增加后，性能又如何？这些都是性能测试中，项目相关人最关心的问题。
所谓的性能表现，说的更直观一些，其实就是用户体验。用户不会在乎系统的处理能力是多少、吞吐量是多少，他们能够感受到的只是系统能否处理他们的请求、处理的速度有多快。
这里提到的一个关键词是“一定压力”，这个压力指的是系统在预期的线上场景中所承受的压力。只有准确的定义和模拟预期的压力，才有可能获取到实际场景中真实有价值的用户感受，而不是那些只存在理论意义的数据指标。
压力是由用户产生的，那么如何准确的定义和模拟用户的行为，也就成了问题的关键。
以往的性能测试中，用户的具体行为是由性能测试人员敲定的。性能测试以外的人员，大概只能了解性能测试会模拟多少个用户，针对哪些模块或者功能做测试，更进一步的还会明确虚拟用户的工作量和所需的时间。这些内容一般也就是性能测试方案中所描述的测试场景。
但这些信息仍然无法准确的对压力进行描述。比如同是100个虚拟用户，每个人需要在1小时内完成一定量的工作，如果这些用户在时间分布上是一个接一个的使用系统，那么对服务器来说，可能就和单个用户没有区别。再比如同是100个用户在线，每个人间隔30秒操作一次和间隔60秒操作一次，压力可能就会相差一倍。而这些直接影响到测试结果和有效性的细节，测试执行人以外的人员一般无法了解，有时恐怕性能测试人员自己都不明确，完全靠制作脚本过程中发挥，导致测试过程比较随意，测试结果的有效性也大打折扣。
有可能对测试结果产生影响的因素主要包括：活跃用户数量、用户活跃时间、用户操作频率（思考时间）、用户操作路径、系统访问量随时间分布、各页面访问量（工作量）分布等等。对这些因素考虑的越准确，测试的结果才会越有效。
本文正是试图对上述内容进行标准化的描述，制定一种规范的分析方法。通过此方法，让测试人员更准确的设计测试场景，让其他人员有机会了解到具体的测试过程，并且能对其进行监督和检查。最终达到“不同测试人员应该测出相同的测试结果”这一目的，也就是获得准确有效的性能测试结果。
本方法无法取代数据分析，而是应该作为其的一个应用，可以直观有效的对用户行为以及系统的压力做出描述，测试人员、开发人员、管理者和业务人员等所有项目相关人都会从其中受益。
虚拟用户（Vuser）
性能测试中模拟的用户，用户的行为由测试脚本定义。
在线用户（或活跃用户）
一个时间段内，与服务器保持交互的用户，也称为活跃用户。需与论坛或者QQ上常见的“在线人数”定义区分，该类系统的在线用户不一定是活跃用户，在线只是一种状态。但在业务类系统中，一般只考虑活跃用户，可认为与在线用户通用。
相对并发用户
类似活跃用户，表示单位时间段内与服务器保持交互的用户，这些用户在理论上有同一时刻（即绝对并发）进行操作的可能（对这种可能性的度量称为并发度）。相对并发的说法主要是为了区分绝对并发，尽量避免使用“并发”这个容易引起歧义的术语。
绝对并发用户
同一时间点（严格的说是足够短的时间段内）与服务器进行交互的用户，一般通过测试工具提供的并发控制（如LR的集合点）实现。
在一个时间点上，可能与服务端进行交互的用户的数量，它表达的是“绝对并发”的一种可能性。
用户每个操作后的暂停时间，或者叫操作之间的间隔时间，此时间内是不对服务器产生压力的。
用户与服务器进行交互的持续时间。
此分析方法依赖于以下基础数据，基础数据的详尽程度将直接决定此模型的有效性和准确性：
1、系统的访问量随时间分布关系。可以直观的观察到使用压力是如何分布在一天（一段时间）之间的，通过此数据来构建性能测试场景。
用户的活跃时间（与系统进行交互的时间）。用户的活跃时间是进行系统并发度估算的基础。比如已知系统的使用压力集中在4个小时内（平均分布），此期间访问量为100，用户的平均活跃时间是30分钟，那么并发度估算为100/(4h/30min)≈12.5。
2、用户操作路径。完成一个典型业务可以通过哪些途径？更有效提高测试覆盖率。
3、系统的访问分布。哪些页面是用户经常访问的，用以选取性能测试将覆盖的功能点。也可以通过此数据来对用户的工作量进行估算，这是确定系统压力很重要的一项信息。
4、页面停留时间（请求间隔时间）。属于测试的细节，可以使脚本更加真实的模拟用户操作。
注：此类数据可能需要专门采集才能获取。性能数据的采集参见另一文档《性能数据采集分析系统.docx》。
压力的度量
1、TPS：每秒钟（关键）事务数。
2、并发度：单位时间段（一般为用户活跃时间）内，理论上有可能发生绝对并发的用户数。
3、活跃用户数：一段时间内与系统进行交互的用户数量。
4、单位时间工作量：比如一小时或一分钟内完成的工作量。
用户的行为主要分为两部分来考虑，一是针对一类特定角色的用户，二是针对整个用户群体。通过一组图形来描述用户的行为、操作路径以及系统各部分的使用率，此种方法称之为用户模型（或者系统使用模型）。
用户模型表示的是系统的使用场景，更准确的说是一个特定时间段的系统使用情况。操作路径是用户模型的核心，通过用户模型，每个人都可以轻易的理解系统是如何被使用的。
基本图形：
数量或百分比
同步点（集合点）
选择或数据
扩展图形：
随机顺序访问
应用示例：
下面以一个在线书店为例，假设我们已经得知以下信息：
1、有4种类型的用户：新用户、已注册用户、供应商、管理员。
2、所有的用户都从主页开始。
3、新用户和已注册用户可以做如下操作：
1）通过标题、作者、关键字搜索图书
2）添加到购物车
4、新用户可以注册成为会员。
5、会员可以登录、修改帐户信息、下订单、查看订单状态
6、管理员和供应商必须从主页登录，然后进入管理页面。
7、管理员可以添加新书、查看订单状态、更改订单状态、取消订单
8、供应商可以查看库存和销售的统计报表。
首先为每个类型的用户分别绘制模型图。根据已知数据来制定用户的操作路径、操作比例。
解释：假设有100个新用户，其中33个会进行多次搜索，有5个用户会因为没有找到相关书目而退出系统。其他的95个用户都可以找到所需书目并将其放入购物车中，这时会有20个用户没有创建账号直接退出，其他的75个用户都选择了创建账号。之后有45个用户成功提交了订单，另外30个只是保存了订单。最后有60个用户是通过直接关闭浏览器退出系统的，选择注销的只有15个。
解释：100个会员，有一半是进行买书流程的，还有一半是进入账号进行信息维护和查看订单状态。
解释：管理员操作都需要从登录管理页面开始，操作最多的是查看订单状态（50％），其中有一半的订单需要修改，增加书目和取消订单都占25％。
解释：供应商也需要从管理员页面登录。供应商用户只能进行查看报表操作，可以选择多种不同类型的报表进行统计，平均每个用户需要查看3种报表。
确定了各个用户角色的模型后，再根据各用户所占的比例，合并成整体用户群的使用模型。
解释：从整体考虑，新用户占20％，会员70％，管理员4％，供应商6％。不同类型的用户通过不同颜色来标识，所有的用户都需要从主页开始访问系统。此模型反应了系统的整体使用情况，也即测试场景需要模拟的压力。而测试场景中具体要执行的测试脚本，则主要根据各类型用户各自的用户模型来开发。
在绘制出模型图后仍然需要不断的同技术人员、业务人员沟通讨论，找出模型中不合理或者遗漏之处，并逐步完善，直到共同确认。甚至是测试结束后，也需要根据系统实际运行环境来不断调整，为后续的测试提供更准确的模型。
但只依靠模型图仍然不能有效的对压力进行描述，可以发现前文提到的种种基础数据信息目前还未得到使用，如用户操作的间隔时间、页面上需要输入的数据等等。没有模型，这些数据是缺少实用意义的；没有数据，模型图也无法得到应用。
基础数据分析
以下图表均取自互联网，本文是在“已经获取所需数据”的前提下，讲解性能测试的一些设计思路。至于如何才能取得这些数据，将在后续的文章中说明。
系统访问量分布
由系统的日访问量分布图，可知系统的访问压力集中在哪个时间段内。系统的压力是在一天中平均分布的，还是集中在某几个更小的时间段内。根据此信息，我们对测试场景的时间进行设计，如从分布图中明显看出每天的大部分访问量集中在9：00～11：00和14：00～16：00两个时段，那么就可以设计2小时内完成一半访问量的测试场景。
用户的平均活跃时间
用户活跃时间，是指用户一次使用系统的时长，可用来指导测试脚本的设计，即每个虚拟用户脚本应该在多长时间内执行完。
由系统访问量分布和用户活跃时间两个数据，可以对系统使用的并发度进行估算。比如已知系统在2个小时内有200访问量，且分布接近于平均，用户的平均活跃时间为30分钟，那么此时间段的并发度应为：200*30/120=50。这里并发度50传递的信息是，在一个用户活跃周期内，总共会有50个用户与服务端进行交互（即相对并发）。也就是说任意时间点，最大的绝对并发可能性是50，当然实际可能远低于此，可以根据业务特点再乘以相应比例进行估算。
在性能测试时，可以依据此数据设计系统高峰期压力的测试场景。比如我们已知，系统压力最大时，单位时间段内活跃用户有100人（并发度100），那么这种压力场景，就可以以用户平均活跃时间为测试时间段，启动100个虚拟用户并在该时间段内完成各自的工作量。
页面停留时间
即请求之间的间隔（思考）时间，如在编辑页面上停留多久才会点提交按钮。如果无此数据，性能测试脚本只有运行时长是有数据（活跃时间）支撑的，脚本中的各请求之间的思考时间，只能通过常规判断和猜测，由性能测试人员自己掌控。收集到此数据后，性能测试脚本会更加符合真实用户的操作习惯，更加接近真实用户。
热点模块（页面）
分析系统各模块或页面的访问频率，可以用来检查性能测试是否设计了足够的覆盖、是否遗漏的用户频繁使用的功能，并据此对用户模型进行完善。
此外，此数据可用来分析各模块或功能所涉及到的工作量，如每天平均完成多少次提交操作、多少次统计操作。这对于确定系统的使用压力有很大的作用。
最后，综合所有数据，为特定测试场景制订出成如下表格：
100用户负载场景
模拟系统使用高峰期时，在2小时左右有100用户的访问
场景加载策略
每4.5分钟加载5个虚拟用户。因为要在2小时内完成100用户的访问，而每个用户的运行时间在30分钟左右，那么在1小时30分钟时就最后一批用户就要开始访问系统，即90分钟内加载100个用户。
虚拟用户数
见XX用户模型
虚拟用户运行时间
平均思考时间
场景并发度
虚拟用户数*(虚拟用户运行时间/场景时长)
平均8s，最小5s，最大20s
如果失败，重试一次，依然失败就中止。
每虚拟用户使用不同的账号
可以说，用户模型表达的是，系统运行中的压力是如何分布的。
而场景数据表达的是，要给系统施加多大的压力。
只有结合用户模型和场景数据两部分，才能构造出一个确定的负载场景。
如果到这里都已经做好，并且经过了技术负责人和业务负责人的确认，那么接下来要做的就是按照设计来实现测试脚本了。
更多课程...&&&
更多咨询...&&&
希望我们的资料可以帮助你学习，也欢迎投稿&提建议给我
频道编辑：winner
邮&&&&&&&件：winner@
&&京ICP备号&&京公海网安备号性能分析名词解释——LoadRunner_LoadRunner_领测软件测试网
性能分析名词解释——LoadRunner
发表于：来源：作者：点击数：
性能 分析名词解释—— LoadRunner 作者: 未知 来源: 网络 转载 Transactions（用户事务分析） 用户事务分析是站在用户角度进行的基础 性能分析 。 1、Transation Sunmmary（事务综述） 对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的
分析名词解释——
作者: 未知&&& 来源: 转载
Transactions（用户事务分析）　　用户事务分析是站在用户角度进行的基础。1、Transation Sunmmary（事务综述）　　对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。2、Average Transaciton Response Time（事务平均响应时间）　　“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。　　例：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。3、Transactions per Second（每秒通过事务数/TPS）　　“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。　　将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。　　例：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是开始出现瓶颈。4、Total Transactions per Second（每秒通过事务总数）　　“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。5、Transaction Performance Sunmmary（事务性能摘要）　　“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。　　重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。6、Transaction Response Time Under Load（事务响应时间与负载）　　“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在　　用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。7、Transaction Response Time(Percentile)（事务响应时间(百分比)）　　“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。8、Transaction Response Time(Distribution)（事务响应时间(分布)）　　“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。　　Web Resources（Web资源分析）　　Web资源分析是从服务器入手对Web服务器的性能分析。1、Hits per Second（每秒点击次数）　　“每秒点击次数”，即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。　　通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。2、Throughput（吞吐率）　　“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其单位是字节，表示虚拟用在任何给定的每一秒从服务器获得的数据量。　　可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。　　“吞吐率”图和“点击率”图的区别：　　“吞吐率”图，是每秒服务器处理的HTTP申请数。　　“点击率”图，是客户端每秒从服务器获得的总数据量。3、HTTP Status Code Summary（HTTP状态代码概要）　　“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数，该图按照代码分组。HTTP状态代码表示HTTP请求的状态。4、HTTP Responses per Second（每秒HTTP响应数）　　“每秒HTTP响应数”是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。5、Pages Downloader per Second（每秒页面数）　　“每秒下载页面数”显示场景或会话步骤运行的每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。　　和吞吐量图一样，每秒下载页面数图标是Vuser在给定的任一秒内从服务器接收到的数据量。但是吞吐量考虑的各个资源极其大小（例，每个GIF文件的大小、每个网页的大小）。而每秒下载页面数只考虑页面数。　　注：要查看每秒下载页数图，必须在R-T-S那里设置“每秒页面数(仅HTML模式)”。6、Retries per Second（每秒重试次数）　　“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。　　在下列情况将重试服务器连接：　　A、初始连接未经授权　　B、要求代理服务器身份验证　　C、服务器关闭了初始连接　　D、初始连接无法连接到服务器　　E、服务器最初无法解析负载生成器的IP地址7、Retries Summary（重试次数概要）　　“重试次数概要”显示场景或会话步骤运行过程中服务器尝试的连接次数，它按照重试原因分组。将此图与每秒重试次数图一起使用可以确定场景或会话步骤运行过程中服务器在哪个时间点进行了重试。8、Connections（连接数）　　“连接数”显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。　　借助此图，可以知道何时需要添加其他连接。　　例：当连接数到达稳定状态而事务响应时间迅速增大时，添加连接可以使性能得到极大提高（事务响应时间将降低）。9、Connections Per Second（每秒连接数）　　“每秒连接数”显示方案在运行过程中每秒建立的TCP/IP连接数。　　理想情况下，很多HTTP请求都应该使用同一连接，而不是每个请求都新打开一个连接。通过每秒连接数图可以看出服务器的处理情况，就表明服务器的性能在逐渐下降。10、SSLs Per Second（每秒SSL连接数）　　“每秒SSL连接数”显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。当对服务器打开TCP/IP连接后，浏览器将打开SSL连接。　　Web Page Breakdown（网页元素细分）　　“网页元素细分”主要用来评估页面内容是否影响事务的响应时间，通过它可以深入地分析网站上那些下载很慢的图形或中断的连接等有问题的元素。1、Web Page Breakdown（页面分解总图）　　“页面分解”显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。　　“页面分解”图可以按下面四种方式进行进一步细分：1)、Download Time Breaddown（下载时间细分）　　“下载时间细分”图显示网页中不同元素的下载时间，同时还可按照下载过程把时间进行分解，用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。2)、Component Breakdown(Over Time)（组件细分(随时间变化)）　　“组件细分”图显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些元素在测试过程中下载时间不稳定。该图特别适用于需要在客户端下载控件较多的页面，通过分析控件的响应时间，很容易就能发现那些控件不稳定或者比较耗时。
原文转自：
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）查看: 4049|回复: 7
LoadRunner是否能模拟TPS对网站进行压力测试
该用户从未签到
想模拟2万人在15分钟内访问页面的情况，但实际没有那么多负载机实现这个模型，现在就想通过TPS来模拟2万人访问页面。
因为单个用户访问一次页面产生了1个Transaction，那2万个用户就是20000个Transaction，要在15分钟内完成20000个Transaction的话，换算成TPS就是22，用LoadRunner以22TPS来对服务器加压，这样就能模拟出2万人在15分钟内访问页面，想请教一下这样设想是否正确？
正确的话，LoadRunner是否能够直接设置TPS来做压力测试，我知道LoadRunner可以创建目标场景，设置TPS为22作为目标，但是这个TPS貌似也是通过不断的增加用户来达到的，在目前条件下无法达到22TPS，有没有其他办法可以做到？
不正确的话，那应该如何来模拟这个场景？？？
该用户从未签到
这个是负载不够吧，负载生成器不够。用多台LR一起测试。LR有这个功能的。
新人回答，不知道能不能帮上忙
该用户从未签到
回复 2# 的帖子
就是因为负载不够所以想换别的方式实现
TA的每日心情无聊 20:16签到天数: 31 天连续签到: 1 天[LV.5]测试团长
楼主的方法，基本上来说是OK的，但在测试时还得考虑访问压力的时间分配，取一个峰值来进行加压
另外，如果因硬件资源的限制无法模拟真实情况，可考虑，资源减半，压力减半的方式
该用户从未签到
回复 4# 的帖子
了解，会试一下的
该用户从未签到
原帖由 z3z3z3z3 于
15:05 发表
想模拟2万人在15分钟内访问页面的情况，但实际没有那么多负载机实现这个模型，现在就想通过TPS来模拟2万人访问页面。
因为单个用户访问一次页面产生了1个Transaction，那2万个用户就是20000个Transaction，要在15分 ...
我觉得不能单纯的这样算，Web页面访问和做一般的交易不一样，一般交易比如银行的存款交易做完一笔就是一笔，15分钟完成几笔能用交易量算出服务器端的TPS，但2万人访问页面可不是点完一次就不再点了。
如果lz想要测试的是一天内的峰值，那么这2万人是不是都对服务器产生了压力，产生压力的用户有多少是流量页面，有都少是提交请求，都需要分析。个人认为Web的性能尽量从前端考虑测试策略。
TA的每日心情无聊 20:16签到天数: 31 天连续签到: 1 天[LV.5]测试团长
主要还是从实际业务着手，访问量有了，还得看压力分布
该用户从未签到
LZ的这种想法应该是无法实现的
因为LR中的面向目标也是靠增加并发用户数实现的
你要设置一个最大用户数
一般来说初始运行50用户
如果打不到目标就再加50
直到达到目标或者达到最大用户数
当已经到达最大用户数却达不到目标时
场景就会失败
所以你这个想法是无法实现的
除非你能保持充足的负载生成器
而你的前提就是 负载机不足
[ 本帖最后由 放任无奈 于
22:40 编辑 ]
站长推荐 /2
赏金公告：悬赏任务已，小伙伴们赶紧行动起来，赚取，去获取奖励吧!
了解自己的心里圈，学习不同的内容，让自己由内而外强大起来！
Powered by查看: 7342|回复: 12
怎样测试最大虚拟用户数和并发数?
该用户从未签到
在loadrunner8.0中，如何测试最大用户数和最大并发数是多少呢？哪位高手详细指点说明下如何测试呢？
[ 本帖最后由 cuixiaoyan1020 于
09:55 编辑 ]
该用户从未签到
说实话，我也一直纳闷呢，我不知道我测试的结果是否正确，我怕测试场景设计不合理，于是测这些地方时用的目标设置。
以下是我的疑问，希望高手解答一下：
什么情况下才是最大用户数和最大并发数：加压系统瘫时吗？遇到某个瓶颈时？
该用户从未签到
最大虚拟用户数有两个概念
1.最佳最大虚拟用户
2.用户能接受的最大虚拟用户数
3.系统最大虚拟用户数
最大并发一般比较好得到
该用户从未签到
给你举个例子吧
如果一个系统有200人使用，最高峰时有100人在线，在这100人中只有50人不断的从客户端向服务器端发送请求。
那么200人，就是系统的总用户数；100人就是系统的同时在线用户数；这50人才是并发用户数。
对于并发用户数的计算：可通过C=(N*L)/T得到。N:平均用户访问数，L:用户从登陆系统到退出的时间段的时间长度；T:考察的时间段长度。
或者可以粗略的估算一下：C=N/10。
最大并发用户数：C(max)=r*C ，r：一般为2——3
该用户从未签到
借这个帖子讨论一个问题
测试得来的最大值和实际运营后说能承载的最大值有没有差距？
这里可以忽略 实际运营时前后台负载数据获取的不准确。
TA的每日心情开心 09:36签到天数: 1 天连续签到: 1 天[LV.1]测试小兵
要知道系统最大并发数，总要有个参考吧？如系统的响应时间(5秒以下，5-10秒，10秒以上)
此时，做出系统响应时间和用户数量的曲线，找到响应时间为5秒时的用户数，就是最佳用户数，然后找到响应时间为10秒时的用户数，即最大用户数。
当然，除了这两项外，还要结合系统资源图来看
该用户从未签到
我的感觉是性能测试 是所有自动化测试中最最不靠谱的测试
原因很简单 无法准确衡量系统上线后的负载是否和测试所要求达到的负载之间到底匹配度几何。
换句话说 这里有多少公司能够提供用LR性能测试后 实际系统上线运行时负载的衡量。
不知道实行性能测试公司的这些领导怎么想的，难道你们的开发都是猪吗？
[ 本帖最后由 shanxi 于
13:04 编辑 ]
TA的每日心情无聊 20:16签到天数: 31 天连续签到: 1 天[LV.5]测试团长
回复 7# 的帖子
匹配度有多少，这个就关系到你做的测试到底模拟是否与线上的实际情况接近了
该用户从未签到
原帖由 msnshow 于
21:51 发表
匹配度有多少，这个就关系到你做的测试到底模拟是否与线上的实际情况接近了
这块有两大问题：
1.性能测试模拟工具是否准确
2.运维时你的监控数据是否能够正确得到。
看你的答复，似乎是以上两大问题都解决了， 那么 贵公司测试数据 和 实际数据 接近度有多少呢？&&贵公司做到了把不靠谱的性能测试做成靠谱的了？
在这里我希望楼上的回复是以实际工作中的内容为依据，而不是忽悠人的那些书本理论知识。
[ 本帖最后由 shanxi 于
11:16 编辑 ]
该用户从未签到
回复 9# 的帖子
严重同意，特别是中小型公司没有白盒测试人员，开发的连单元测试都不做，最后所有的问题直接堆到测试人员这，没法儿！
[ 本帖最后由 bobdog520 于
08:23 编辑 ]
该用户从未签到
回复 10# 的帖子
其实我就觉得这个容量规划　和　最大值问题　根本没什么用
也就是报告里面列举一下　　
教入行的或新手　来计算这个数字　有什么实际意义？
没看到能把控这个数字的案例啊！
该用户从未签到
有点公司就要这个没有的值啊，那也没办法啊，来点实际的，直接说公式！
该用户从未签到
站长推荐 /2
赏金公告：悬赏任务已，小伙伴们赶紧行动起来，赚取，去获取奖励吧!
了解自己的心里圈，学习不同的内容，让自己由内而外强大起来！
Powered by