LoadRunner讲解实例讲解性能测试执行过程软件测试影响力软件测试影响力(www.icntest.com)沙漠浪2011-4-252021/5/231概述n本次讲解的目的：能够再经过少量的指导就可以直接在实际工作中使用LR进行性能测试；n演示实例：综合运维支撑系统用户工单接单的性能测试n讲解的内容：性能测试执行过程，从中讲解参数化、集合点、事务、检查点、场景设置、结果分析2021/5/232性能测试执行过程性能测试执行过程大致分为：n数据准备n录制、编辑及调试脚本n设置及调试场景n执行场景n分析结果2021/5/233一、数据准备数据准备是根据测试的需要，在执行测试之前在被测系统中加入的符合要求的数据。比如，我们在测试接单性能时，需要有待接的工单，那么这些待接的工单就是在数据准备阶段完成的。2021/5/234一、数据准备数据准备方法1.手工要加的数据量比较少的情况下可以手工在系统中加。比如加一个接单的用户2.使用LR或其他自动化测试工具在数据量比较多情况下就要使用工具（LR/QTP等），我们常用的就是LR，录制一个加数据的脚本，反复迭代运行脚本或在场景中运行脚本，数据会生成到系统里面去，这种方法也只适用于插入几千条数据2021/5/235一、数据准备3.数据直接写入数据库这种方法在插入数据时是最快的，但在准备这些插入数据的sql语句（或存储过程）时却很麻烦，因为生成一条系统中能流转的数据需要很多表关联，这个需要开发人员大力协助，最理想的是直接要开发人员提供写好了的存储过程，我们只运行，不过一般情况下由开发人员提供表信息，然后告诉你怎么做，然后自己组装sql。这种方法适用于数据量非常大的情况2021/5/236二、脚本 录制脚本n录制脚本操作步骤请参见LR的操作手册，这里说一下需要注意的地方。1.最好在脚本录制的过程中加入备注、集合点和事务2.在编辑脚本前备份一个原始脚本3.再录制一个同样操作的脚本，用于与刚才录制的脚本进行对比，查找出哪些需要参数化值4.两个用于进行对比的脚本存放的绝对路径不要太长，比如桌面，这时将无法比较2021/5/237二、脚本 插入集合点n插入集合点的目的就是控制所有用户同时并发开始执行某个动作。例：测试用户并发接单的性能，则把集合点插入到接单动作提交的前面。这时，先到的用户该集合点的用户要等后到集合点的用户，然后一起执行提交操作。2021/5/238二、脚本 插入事务n添加事务的主要目的就是要得到事务开始时间和事务结束时间之间的间隔时间，即事务响应时间；n我们把关注的某些动作定义为一个事务，在场景运行时，LR就会自动记录该事务的所花的时间；n如果场景是多用户并发，迭代多次，则LR会给出事务最大的响应时间、最小响应时间和平均响应时间，我们一般看的是平均响应时间；n一个脚本中可以加入多个事务，一个事务也放到另一个事务里面；2021/5/239二、脚本 参数化n找出需要参数化的字段1.打开一个脚本，选择另一个相同操作步骤的脚本用比较器比较2021/5/2310n在比较器中查看两个脚本不同的地方，脚本中不同的地方用黄色标识出来可能会标识出很多不同的地方，但有些地方我们可以不去管它，比如下载的图片资源，思考时间等，有些地方则是很可能要参数化的，比如某某ID或value一串类似随机字符串，根据经验初步判断哪些是需要参数化的记录下来。二、脚本 参数化2021/5/2311二、脚本 参数化n从相关开发人员那里获取得到这些值的SQL语句找开发人员要sql语句之前，我们必须清楚我们需要什么样的数据，比如：接单脚本参数化我们需要特定人待办的用户工单的recordsn字段的值一般项目经理都会告诉你谁开发哪一块，测哪块的程序，找相关的开发人员即可，并且他们也会大致告诉你这些表是做什么用的，这些信息是很有用的，以后我们可以自己改sql语句得到更适合我们测试的sql语句。2021/5/2312二、脚本 参数化n待接单参数化需要的sql语句如下：selectm.clogcode,d.recordsnfromsvr_pub_da_dispqueued,org_usero,svr_pub_da_mainqueuemwhered.mainsn=m.mainsnandd.repairoper=o.userid（表与表间的关联）andm.business=961300261A9D55CD70029C68FE8C4F4F（工单类型：用户工单）andd.processflag=ACCEPT（过程标识：接单）ando.loginname=张林（当前待办箱：张林）andclogcodeLikezl%（附加标识：准备数据时方便以后自己识别加入的特殊标识）OrderByclogcode另：svr_pub_da_dispqueue派工工单处理表，也就是子单的一些信息svr_pub_da_mainqueue工单主表，也就是主单的信息，张主单包含多张子单2021/5/2313二、脚本 参数化n参数化1.建立参数化文件*.dat，放入脚本文件夹内2.在PLSQL中根据sql语句查询出所得的数据，拷贝到参数化文件内3.在脚本中找到要参数化的字段，对其进行参数化，引用参数化文件中的数据2021/5/2314二、脚本 参数化n调试脚本，验证参数化是否正确1.在脚本编辑器中用少量的迭代次数反复运行脚本；2.在场景中用少量并发数和迭代数运行脚本。参照下面规则，如果两种验证方式都通过，则参数化成功，否则继续调试脚本。2021/5/2315二、脚本 参数化是否参数化成功规则：如果迭代运行通过，并且使用的参数化值正确，并且被测系统得到的结果和预期结果相同（工单正确流转），则参数化成功；如果迭代运行不通过，或者引用的参数化的值不是预期的值，或者被测系统中对应的工单没有正确流转，则参数化不成功，此时需要：1.根据错误提示解决问题；（比如服务器未连上）2.检查参数化值，取数据的方式设置是否正确，调整设置；（比如参数化值的数量不够）3.检查sql语句查出来的数据是否符合要求，主要是看条件限制是否足够，调整sql语句；（比如需要的是某人的待接单，但查得的是所有未归档单据）4.检查是否还有需要参数化的值，需要参数化的值再进行参数化（比如有两个字段需要参数化，但只对一个字段进行了参数化）5.运行脚本，重复上面的动作，直至参数化成功为止2021/5/2316二、脚本 检查点n为什么要加入检查点检查点是检查脚本运行后，是否真的得到了预期结果。因为曾经发现场景运行后，LR反馈事务运行成功，但其实没有真正运行成功，工单没有流转。虽然我们可以在数据库中查询工单的状态，但插入检查点后，在场景运行的过程中就可以看到事务运行是否出现了问题，比在数据库中看更加方便；另外，像测试查询的性能类的脚本，在数据库中是看不到变化的，所以插入检查点就是非常必要的了。2021/5/2317二、脚本 检查点n检查点实例（接单脚本的检查点）首先要考虑，在系统中我们手工接单的时候是怎么判断工单流转是否成功的，是看接单后工单状态是否变为了“待回单”，那么，我们就以此做为检查点。接着要在脚本中找到插入检查点的正确位置。在录制接单脚本时，已经为设置检查点做了准备，在接单完成后又在待办箱查询了一次刚才接的工单。检查点就设在查询出的工单那里。2021/5/2318二、脚本 检查点检查点实例（接单脚本的检查点）加入检查点函数：web_reg_find(Text=title=待回单,SaveCount=i,LAST);检查当前页面上是否有“Text=title=”待回单”这个字符串，把找到的次数保存在i这个变量里面，因为这个函数必须是先注册再用，所以把上面这段代码加在查询前面。在用户工单待办箱页面上可以看到，查询出一张待回单工单，页面上会有两个待回单的图标标识，意味着，i2时，才是查到一张待回单，如果i1，脚本运行也不会报错，但其实工单并没有流转到待回单。所以我们要对i值进行判断，看是否等于2if(atoi(lr_eval_string(i)=2)lr_output_message(找到2次,操作成功！);elseif(atoi(lr_eval_string(i)=1)lr_error_message(找到1次，操作没成功！);elseif。上面这段代码要加在查询后面，查询之后才能看到结果。场景运行时，如果待回单标识只找到一次，就会有错误报出来，lr_error_message实现。2021/5/2319二、脚本 检查点检查点实例（接单脚本的检查点）根据检查点函数收集到的数值，判断工单是否流转成功：在用户工单待办箱页面上可以看到，查询出一张待回单工单，页面上会有两个待回单的图标标识，意味着，i2时，才是查到一张待回单，如果i1，脚本运行也不会报错，但其实工单并没有流转到待回单。所以我们要对i值进行判断，看是否等于2if(atoi(lr_eval_string(i)=2)lr_output_message(找到2次,操作成功！);elseif(atoi(lr_eval_string(i)=1)lr_error_message(找到1次，操作没成功！);elseif。上面这段代码要加在查询后面，因为查询之后才能看到结果。场景运行过程中，如果待回单标识只找到一次，就会有错误在场景执行界面报出来，由lr_error_message实现。2021/5/2320二、脚本 检查点n调试脚本，验证检查点是否起作用至少要用一个验证反例来验证检查点是否真的有效。比如，更改验证的字符串标识为“待接单”，运行场景查询同样的待回单工单出来，看是否报错；如果不报错，说明检查点没起作用，要检查加入的检查点位置是否正确，语句是否正确，或改用其他检查方式来设检查点；如果反馈报错信息“找到1次，操作没成功！”说明检查点设置生效了，可以继续往下做。2021/5/2321二、脚本 调整脚本n在脚本调试的过程中，我们已经执行了很多次场景了，在没有正式测试之前就有可能发现系统的什么地方比较非常耗时，甚至导致运行不到我们本次测试关注的地方。在这种情况下，我们可以对那些比较耗时的代码段专门再加事务，正式测试的过程中也关注一下这个事务；如果是影响到我们后面运行的代码段，且屏蔽掉后不影响本次测试的，则先屏蔽掉该代码段，继续后面的测试，但在测试报告中告之该代码段对应的操作性能有问题。2021/5/2322二、脚本 调整脚本n实例：原来的系统，进入工单查询界面会默认刷新一次显示一页工单，然后才可输入查询条件查询。当然录制根据条件查询的脚本也是这个过程。问题是在基础数量很大的情况下，进入工单查询，默认刷新页面这个动作基本上完成不了，所以后面的根据条件来查询也就测不了。所以最后在脚本中屏蔽掉了默认刷新的代码，继续输入查询条件查询的性能测试。当然默认刷新显示不了工单列表的问题也要告之开发组。在以后发布的测试版本中，开发组针对此问题作了改进，在进入工单查询界面时，不默认刷新出工单列表，而是让用户自己输入查询条件，从而避免了上述问题。n至于如何知道某个操作对应在脚本中的代码，就是我在前面录制脚本中提到的要多写操作的备注信息，方便查找。2021/5/2323三、场景 场景分类n场景模式的选择场景分为手工场景和面向目标的场景。手工场景要达到某个测试目的需要根据场景每次运行的结果，需要使用者自己调整虚拟用户数，直到达到预期目标。面向目标场景是在场景运行前设置了目标值，LR在运行的过程中自动逐步加载虚拟用户以达到预设的目标。目前我们用的都是手工场景，面向目标的场景还没有仔细研究过，但前不久我试验了一下，手工场景和面向对象场景得出的结果差别还比较大，现在还不知道具体原因，待以后解决。2021/5/2324三、场景 场景设置n选择脚本n设置并发用户数n输入要使用资源的电脑IP或主机名，连接上nRun-timeSettings,设置迭代次数、设置每次迭代的间隔时间、设置只输出标准日志、忽略思考时间、局域网内不使用代理n设置检查点有效2021/5/2325三、场景 场景设置n设置集合点。并发用户数多的情况下，选择第一或第三项，可以让所有用户都到达集合点后才开始事务；如果使用默认的第二项，所有正在运行的用户到达集合点后，就开始运行事务了，此时可能还有用户还处在初始化阶段，没有运行，执行的并发数是没有到达预期设计的；并发数小的情况下，使用哪项都无所谓；可以适当将两个用户之间的等待时间设置大点。顺便说一下，关于这里设置的超时，是设置的前后两个虚拟用户到达集合点的间隔，不是第一个虚拟用户与最后一个虚拟用户到达集合点的时间间隔。2021/5/2326三、场景 场景设置n设置登入方式如果并发用户数较大，最好选择分批登入。如果选择一次全部登入，有可能在登入被测系统时就运行失败了，虽然在登入时候并没有设置集合点，但登入时间也是相对集中的，压力较大。2021/5/2327三、场景 场景设置n选择自动载入分析，场景运行结束后会自动载入分析结果；如果没有选择，点工具栏上的“AnalyzeResults”按钮也可以载入结果2021/5/2328三、场景 场景设置n设置结果保存路径，也可以设置自动保存结果，但一般不要选择自动覆盖结果，以免误操作覆盖掉以前有用的结果2021/5/2329三、场景 场景设置n加入需要监控主机及相关系统资源计数器将被测系统的服务器的操作系统拖入显示窗口在窗口中点右键，增加一个服务器的IP，联接上该服务器选择关注的系统资源计数器2021/5/2330三、场景 场景设置n加入oracle指标计数器将oracle拖入显示窗口2021/5/2331三、场景 场景设置连接oracle，其中servername是你本机配置的服务名，登入用户可以是system也可以是其他用户2021/5/2332三、场景 场景设置加入关注的计数器，注意选择obiect时选择第三项，否则得不到数据。至于这一项具体的内容，介绍一个网址，大家可以去看看：http:/hi.baidu.com/hawem/blog/item/ec7fc2f92bcfe55a242df23e.html这里面有一些常用统计的解释，内容较多不在此列出。2021/5/2333三、场景 场景设置比如加入physicalreads2021/5/2334三、场景 场景执行n在场景执行的过程中，可以看到执行的信息，如果发现有大量事务报错或执行时间特别长，可以终止本次执行；但要根据报错信息判断是否因为系统无法支撑本次并发数导致的，如果是，则要减少用户数后再次执行；如果不是，查找错误原因，解决错误之后再次执行。n对同一类场景，要多执行几次，找出出现次数较多的那个响应时间。n另外，在监控linux系统的性能指标时，可以用vmstat、iostat命令来获得一些信息供以后分析。2021/5/2335三、结果分析 结果摘要n分析结果摘要中包括了本次测试结果大概的信息，我们关注比较多的有：执行的场景的路径，保存结果的路径，执行了多长时间最大并发用户数事务的通过数，失败数，终止数事务的响应时间返回的http状态代码，主要看有没有错误信息（参考附件“返回http代码状态”）2021/5/2336三、结果分析 加入新图表n加入新图表，通常有操作系统相关、数据库相关、事务相关、网页细分相关2021/5/2337三、结果分析 事务分析n查看事务是否通过及响应时间在事务摘要中，看要测试的事务（比如接单事务）是否全部运行通过。如果没有全部通过，说明在场景运行的过程中出了问题，查找原因；如果全部通过接着查看下面的；如果加有检查点的事务，看检查点事务是否全部运行成功；如果没有全部通过，说明在场景运行的过程中出了问题，查找原因；如果全部通过接着查看下面的；事务执行后可以在数据库中看到相应的变化，最好查看数据库里面的记录的变化内容及数量，是否与前面的事务执行通过数一致。如果是一致的才算是场景真的执行通过了；事务全部通过了，它的平均响应时间才有意义。查看它的平均响应时间是否在我们的要求内，适当增减并发用户数再执行。2021/5/2338三、结果分析 事务分析n事务执行未通过，考虑：是否需要更改场景运行的设置（比如接受HTTP请求响应时间默认是120秒超时，如果需要可以改大一点）负载过大，服务器的系统资源（CPU、内存、磁盘等）不足以支持事务执行；这种情况下，要分析是哪种系统资源不足，然后再分析是硬件瓶颈引起的还是由程序引起的。负载不大，服务器所有资源充足，但仍有事务未运行成功。这种情况主要考虑是否是被测程序的问题。n事务响应时间过长，同上面的第二和第三点2021/5/2339三、结果分析 获取常用性能指标n目前在做性能测试的时候，如果测的是windows系统，一般就只用LR监控就可以了，在设置场景时加入windows相关的计数器；如果测试的是linux系统，则还要用linux的命令（常用的有vmstat、iostat），因为LR里面包含的linux相关的计数器比较少，所以用这些命令做为补充。2021/5/2340三、结果分析 常用指标分析nLR指标CPUUtilization(CPU利用率)一般认为，CPU连续长时间处在95（90）以上，则可能是CPU的瓶颈。“长时间”究竟定义为多长？以前我认为是5秒，因为经常说用户能忍受的响应时间是5秒，连续5秒CPU都占用95以上，那事务响应时间很有可能就在5秒以上了；后来做了几次测试之后我发觉有一点不对，如果抛开用户能够承受的事务响应时间，单单来找系统瓶颈时会发现，5秒其实是一个很短的时间。现在我认为“长时间”只是个相对数，相对于事务的执行时间。比如说，假如事务执行时间有10秒，而在事务执行的这段时间内大部分时间（8秒）CPU占用率都在95以上，那么可以说8秒的时间较长了，可能CPU资源是系统瓶颈；但如果事务执行时间是60秒，其中有连续10秒钟CPU占用在95以上，那么这10秒其实算是比较短的了，应该是其他问题导致事务运行花了60秒。2021/5/2341三、结果分析 常用指标分析nLR指标CPUUtilization(CPU利用率)在LR的分析结果中可以看到CPU的平均值，在很多情况下，CPU的平均值都不到90%，但已经可以认为CPU是系统瓶颈了。因为我们在执行场景的时间一般不会太长，所以，在场景刚开始运行时CPU的小值对平均值的影响较大，如果场景运行时迭代次数足够多，运行时间足够长则不会存在该问题。在目前的情况下，我们主要还是看事务处理过程中的CPU的利用率，而不是去看平均值，平均值、最大值、最小值，只能做为参考。CPU的占用是系统占用和用户占用之和。一般情况下，系统占用率是很小，5%可能都不到，主要用户占用多，所以平常我们先看一下是否系统占用是否正常，然后就只看CPU占用的总数就可以了。2021/5/2342三、结果分析 常用指标分析nLR指标内存相关主要看可用内存和是否频繁换页如果系统可用内存变的很小，内存可能成为系统瓶颈如果页交换频繁，将严重影响系统性能2021/5/2343三、结果分析 常用指标分析LR指标内存相关n可用内存如果是windows系统，直接在LR里面看free的值就行了，建议阀值是4M，不能小于4M。如果发现已经接近4M了，说明可用物理内存不够了。如果是linux系统，LR里面没有可用物理内存大小的参数。需借助于vmstat命令，后面详述。2021/5/2344三、结果分析 常用指标分析LR指标内存相关页交换主要看page-outrate每秒从物理内存中换出到磁盘上页交换文件的页数。这里可以看到平均值、最大最小值，如果平均值很大，说明有很多的页交换发生，内存可能不足，需要告诉开发组查找原因。至于值为多大才算大，在网上也没有找到一个确数，可能要靠经验的积累。不过如果是达到几百，页交换应该是比较频繁了。2021/5/2345三、结果分析 常用指标分析nLR指标Averageload（平均负载）在过去的1分钟内运行队列中的平均进程数量。该数值除以cpu个数（逻辑个数）小于5，则是在可接受的范围，否则说明该服务器负载过重。2021/5/2346三、结果分析 常用指标分析nLR指标Oracle相关SELECTname,valueFROMV$sysstatWHEREname=redologspacerequest;此处value的值应接近于0，否则，应增大初始化参数文件的Log_buffers的值通过查询V$sysstat表判定redolog（重做日志）文件缓冲区是否足够。实际测试过程中，只需要在场景中添加“redologspacerequest”这个计数器即可。2021/5/2347三、结果分析 常用指标分析LR指标数据库缓冲命中率：命中率=1-physicalreads/(dbblockgets+consistentgets)该值要在90以上，如果小于90，则要考虑增加databuffer（数据缓冲区）的大小2021/5/2348三、结果分析 常用指标分析n对linux系统性能的监控和分析，用LR关注的比较少，主要用的是vmstat和iostat命令。vmstat对系统的进程情况、内存使用情况、交换页和I/O块使用情况、中断以及CPU使用情况进行统计并报告相应的信息。第一个显示内容指出了计算机重启至今的平均使用情况。后面的每一行信息是按延时定期地显示系统的各部分信息。进程信息和内存信息都是即时产生的。iostat也包括了CPU的使用情况，不过它的主要特点是汇报磁盘活动的情况。如果用vmstat命令发现问题可能与磁盘相关，则再用iostat命令来进一步分析磁盘活动。2021/5/2349三、结果分析 常用指标分析nVmstat命令roottest2#vmstat1procs-memory-swap-io-system-cpurbswpdfreebuffcachesisobiboincsussyidwa对上面我们关注的指标的分析：r:进程等待队列长度，阀值是cpu个数*4,这里的cpu个数指的是逻辑cpu的个数（cat/proc/cpuinfo可以看到）。id：CPU的空闲时间。粗略的来看，反过来就是占用时间。2021/5/2350三、结果分析 常用指标分析Vmstat命令相关指标的分析n从r和id值看CPU的使用情况。如果r值长时间很大、id值长时间很小，（长时间有很多进程等待，且cpu占用长时间很大），说明CPU资源有可能不足；如果r值长时间很大，id值只是偶尔很小，（长时间有很多进程等待，但cpu大部分时间空闲），说明应该不是cpu硬件处理能力的问题，要找程序的原因；如果r值偶尔很大、id值长时间很小，（偶尔有较多的进程等待处理，但大部分不是，但cpu占用长时间很大），虽然CPU占用很厉害，但只要有进程过来基本上马上就能处理，至少目前不能说明cpu资源不足。在实际测试的过程中也可以看到这种情况，但事务响应较快。2021/5/2351三、结果分析 常用指标分析Vmstat命令相关指标的分析free:空闲的内存，单位KBbuff:被用来做为缓存的内存数，单位：KBcache：被用来做为cache的内存数，单位：KBvmstat得到的free的值与windows系统的free值不同，不是可用内存，是自由内存，就是还没有被使用过的内存；linux的内存管理机制认为，用户可用的内存freebuffcache，所以单看free值是没有意义的。经常会看到free值很小，只有23M，但实际可用物理内存要大的多。2021/5/2352三、结果分析 常用指标分析Vmstat命令相关指标的分析swpd:虚拟内存使用情况，单位：KBsi:从磁盘交换到内存的交换页数量，单位：KB/秒so:从内存交换到磁盘的交换页数量，单位：KB/秒Swpd是当前虚拟内存使用的情况，要说明的是，如果前面虚拟内存使用了500M，而后来的程序再使用小于500M的虚拟内存，swpd的值是不变的，如果大于500M时会增加到相应的数。si和so是当前时刻新产生的交换页数量，不是swpd（交换分区）里面的数量。分析时主要看so，如果so值连续一段时间有值，说明内存资源可能不足，要将物理内存中的部分页交换出来供新来的程序使用。频繁页交换影响系统性能，so值越小越好，最好为0。2021/5/2353三、结果分析 常用指标分析Vmstat命令相关指标的分析bi:发送到块设备的块数，单位：块/秒bo:从块设备接收到的块数，单位：块/秒wa:磁盘等待队列（1块1KB）Wa值长时间较大，阀值？说明硬盘资源可能不足。查看bi和bo之和是否超过硬盘本身的处理能力，如果没有超过力，说明不是硬盘硬件的性能问题；如果超过了，则要考虑优化程序减少读写，或考虑换性能更好的硬盘或使用多硬盘分摊负载。至于硬盘的处理能力，根据硬盘型号的不同而不同。但在网上也一直没有找到理想的解答，有的说一般就是5070MB/S，也可以参考一下。另外可以用iostat命令详细查看磁盘的活动情况。2021/5/2354三、结果分析 网页细分图网页细分图主要查看是网络问题还是服务器问题哪个页面、链接比较耗时2021/5/2355三、结果分析 网页细分图n如果发现事务的响应时间比较长，可以查看是网络原因造成的还是服务器原因造成的。双击事务，在右边的图中选择具体的链接，选择“TimetoFirstBufferBreakdown”(第一次缓冲时间)，可以看到该链接所花时间是在网络上还是服务器上，如果有很多时间花在网络传输上，说明网络存在问题；如果是很多时间花在服务器处理上，则要找服务器的原因。2021/5/2356三、结果分析 网页细分图n查看事务中各链接的响应时间和下载内容的大小找出耗时最多的链接。可能问题就出在该链接上找出可疑的链接。可能该链接目前耗时不大，但相对于它下载内容的大小来说就很耗时了，这可能也是隐藏的问题，可以继续试验证明自己的想法是否是对的2021/5/2357四、小结本次讲解中LR具体的操作讲的很少，主要是因为我认为在开始学习LR的时候最大的困惑不是LR具体怎么操作，而是怎么用LR来进行测试，所以重点放在了后者，讲了用LR测试的整个完整过程。LR的操作可以参考操作手册，基本上可以学会。性能测试要学习的东西其实很多，大家共同学习。2021/5/2358谢谢！2021/5/2359部分资料从网络收集整理而来，供大家参考，感谢您的关注！