性能测试面试题汇总（三）

Q19、你在LR中如何编写自定义函数？请给出一些你在以前进行的项目中编写的函数。

A19：在编写用户自定义函数之前，需要首先为函数创建外部库（DLL）文件，将这些库文件放在bin目录下，一旦库文件已经被添加并且将用户自定义函数作为参数，函数应该为以下格式：__declspec (dllexport) char* (char*， char*)

Q20.在运行设置下你能更改那些设置？

A20：可以修改Run Logic、pacing、Log、Think Time等，见下图；可以测试实际需要，修改相关选项。

pacing：每个虚拟用户脚本包括三个部分：vuser_init, Run (Actions), vuser_end. 当你运行脚本的时候你能通知，虚拟用户重复执行run部分，每一个重复做为一个iteration.   注意： vuser_init 和vuser_end 部分是不被重复的。

Think Time Settings：  虚拟用户think time仿效一个真实用户在活动中等待的时间，例如：当一个用户从服务器接受数据的时候，在响应前这个用户需要等待数秒来接受数据，这个被耽搁的时间就是think time。

Error Handling：你能指定一个虚拟用户在脚本执行期间如何处理错误，默认的，当一个虚拟用户发现一个错误的时候，它会随着下一次重复继续下去，你能使用这个设置来通知虚拟用户当发生错误的时候是否继续执行脚本。

Run Logic：迭代次数

Q21.你在不同的环境下如何设置迭代？

A21：在“运行时设置”中设置，如下图所示：

Q22.你如何在负载测试模式下执行功能测试？

A22：在负载测试模式下，可以通过同时运行数个虚拟用户，通过增加虚拟用户数，确定服务器在多大的负载量下，仍然可以正常运行，我一般进行核心功能操作，验证核心功能运行是否正常。

Q23.什么是逐步递增？你如何来设置？

A23：虚拟用户数随着负载时间逐渐增加，可以帮助确定系统响应时间减慢的准确时间点。

　　可以在“加压”选项卡中进行设置：如下图所示，将设置更改为：“每 30 秒启动 2 个 Vuser”

Q24.以线程方式运行的虚拟用户有哪些优点？

A24：以线程方式运行的虚拟用户，在默认情况下，Controller为每50个用户仅启动一个mmdrv进程，而每个用户都按线程方式来运行，这些线程用户将共享父进程的内存，这就节省了大量内存空间，从而可以在一个负载生成器上运行更多的用户。

Q25.当你需要在出错时停止执行脚本，你怎么做？

A25：取消运行设置中的“Continue on error”复选框。

　　或者使用lr_abort函数。

Q26.响应时间和吞吐量之间的关系是什么？

A26：当系统吞吐量未达到系统处理极限时，系统性能不会衰减，交易平均响应时间一般也不会递增，当系统达到吞吐量极限时，客户端交易会在请求队列中排队等待，等待的时间会记录在响应时间中，故交易平均响应时间一般会递增。

Q27.说明一下如何在LR中配置系统计数器？

A27：以windows资源监控为例，可右键点“添加度量”，输入系统IP、选择平台类型，确定即可，详细参加LR自带操作手册^_^。

　　对于监控不同类型的操作系统，需要做一些准备工作，可参见监控操作系统资源部分。

Q28.你如何识别性能瓶颈？

A28：自己的理解，瓶颈产生在以下几方面：

• 1、网络瓶颈，如带宽，流量等形成的网络环境

• 2、应用服务瓶颈，如中间件的基本配置，CACHE等

• 3、系统瓶颈，这个比较常用：应用服务器，数据库服务器以及客户机的CPU，内存，硬盘等配置

• 4、数据库瓶颈，以ORACLE为例，SYS中默认的一些参数设置

• 5、应用程序本身瓶颈，

针对网络瓶颈，现在冒似很少，不过也不是没有，首先想一下如果有网络的阻塞，断网，带宽被其他资源占用，限速等情况，应用程序或系统会是什么情况，针对WEB，无非是超时，HTTP400，500之类的错，针对一些客户端程序，可能也是超时，掉线，服务器下发的，需要服务器返回的信息获取不到还有一种更明显的情况，应该就是事务提交慢，如果封装事务的代码再不完善，一般造成的错误，无非就是数据提交不完整，或者因为网终原因+代码缺陷造成重复性提交。如此综合下来，肯定是考虑网络有瓶颈，然后考虑网络有问题时，怎样去优化，是需要优化交互的一些代码，还是接口之类的。

应用服务的瓶颈的定位，比较复杂，学习中，不过网上有很多资料可以参考的。一般像tomcat，weblogic之类的，有默认的设置，也有经过架构和维护人员进行试验调试的一些值，这些值一般可以满足程序发布的需要，不必进行太多的设置，可能我们认识的最基本的就是JAVA_OPTS的设置，maxThreads，time_out之类的参数我们做借助LR，Jemeter或webload之类的工具，执行性能测试，尤其是对应用服务造成了压力，如果应用服务有瓶颈，一般我们设置的log4j.properties，日志都会记录下来。然后根据日志，去进一步确定应用服务的问题

系统瓶颈，这个定位虽说比较复杂，但是有很多前辈的经验值参考，不作说明，相信用LR的同行，也可以从性能记数器中得出一些指标值，加上nagios，cacti，可以很明显的看出系统哪些资源够用，哪些资源明显不够用。不过，一般系统瓶颈的造成，是因为应用程序本身造成的。关于这点儿的分析和定位，就需要归入应用程序本身瓶颈分析和定位了。

现在基本所有的东东，都离不开数据库这个后台，数据库的瓶颈实在是不知道是什么概念，数据库管理员的工作，数据库管理员日常做的工作，可能就是有瓶颈定位的工作，比如：查询一下V$sys_event，V$sysstat，v$syssql之类的表，比对一下日常正常情况下的监控数据，看一下有没有异常等。其他方面，我也不是太了解。

应用程序瓶颈，这个是测试过程中最需要去关注的，需要测试人员和开发人员配合执行，然后定位，我这儿做的大都是执行性的，比如会有脚本去运行，开发人员会结合jprofiler之类的工具，去看一下堆遍历，线程剖析的情况确定哪儿有问题。大致是这样，没有实际操作过

逐步细化分析，先可以监控一些常见衡量CPU，内存，磁盘的性能指标，进行综合分析，然后根据所测系统具体情况，进行初步问题定位，然后确定更详细的监控指标来分析。

Q29.如果web服务器、数据库以及网络都正常，问题会出在哪里？

A29：问题可能出在系统本身或应用服务器、或为应用编写的代码编写中。

Q30.如何发现web服务器的相关问题？

A30：可以利用web资源监控器发现web服务器相关问题，在场景执行过程中，可以利用监控器分析web服务器吞吐量、每秒点击率、每秒HTTP响应数、每秒页面下载数，以及web服务器硬件资源使用情况等。