性能测试面试
http://pan.baidu.com/share/link?shareid=353540&uk=2636256858
Q1：什么是负载测试？什么是性能测试？
A1：负载测试是通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载量的测试，例如，访问一个页面的响应时间规定不超过1秒，负载测试就是测试在响应时间为1秒时，系统所能承受的最大并发访问用户的数量。
性能测试：指在一定的约束条件下（指定的软件、硬件、网络环境等），确定系统所能承受的最大负载压力。
Q2.性能测试包含了哪些测试（至少举出3种）
A2：性能测试包含负载测试、压力测试、大数据量测试、疲劳强度测试等。
Q3.简述性能测试的步骤
Q4.简述使用Loadrunner的步骤
A4：制定性能测试计划—>开发测试脚本—>设计测试场景—>执行测试场景—>监控测试场景—>分析测试结果
Q5.什么时候可以开始执行性能测试？
A5：功能测试通过；一般需要进行性能测试的系统，都是用户量比较大、业务使用比较频繁、比较重要的功能模块。
Q6.LoadRunner由哪些部件组成？
A6：主要有三部分组成：
Q7.你使用LoadRunner的哪个部件来录制脚本？
A7：使用Virtual User Generator录制测试脚本
Q8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？
A8：LoadRunner的Controller组件。
Q9.什么是集合点？设置集合点有什么意义？Loadrunner中设置集合点的函数是哪个？
A9：在性能测试过程中，需要模拟大量用户在同一时刻，访问系统并同时操作某一任务，可以通过配置集合点来实现，多个用户同时进行某操作；
集合点可以在服务器上创建密集的用户负载，使LoadRunner能够测试服务器在负载状态下的性能。
设置集合点函数：lr_rendezvous("Meeting")； // Meeting是集合点名称
Q10.什么是场景？场景的重要性有哪些？如何设置场景？
A10：场景用于模拟用户实际业务操作；
LoadRunner中场景有手工场景和面向目标的场景。
设置场景：选择场景类型、设置运行时设置、模拟用户数、加减压方式、持续时间，配置负载生成器。
Q11.请解释一下如何录制web脚本？
A11：利用Virtual User Generator录制测试脚本，录制步骤：
1、选择合适的协议
2、设置录制选项
3、开始录制
Q12.为什么要创建参数？如何创建参数？
A12：LoadRunner在录制脚本的时候，只是忠实的记录了所有从客户端发送到服务器的数据，而在进行性能测试的时候，为了更接近真实的模拟现实应用，对于某些信息需要每次提交不同的数据，或者使用多个不同的值进行循环输入。这时，在LoadRunner中就可以进行参数化设置，以使用多个不同的值提交应用请求。
【参数化】：使用指定数据源中的值来替换脚本录制生成的语句中的参数。
【参数化好处】
● 减少脚本的大小
● 提供使用不同的值执行脚本的能力，更加真实的模拟现实应用。
【参数化步骤】
● 用参数替换Vuser脚本中的常量值
● 为参数设置属性和数据源
Q13.什么是关联？请解释一下自动关联和手动关联的不同。
A13：【关联的定义】简单的说：就是把脚本中某些写死（固定）的数据，转变成动态的数据，或者说将前面语句的结果数据保存下来，然后在后面的语句提交请求时使用这些数据。
【需要关联的前提条件】：
客户端需要从服务器端返回数据中获取部分数据，并将这些部分数据处理后作为自己下一次请求的一部分发出。
【自动关联与手工关联的不同】：自动关联是在脚本录制过程中，VuGen会根据已经制定好的规则，自动找出需要关联的值或脚本录制完成后，执行脚本一次，通过Correlation Studio自动找出需要关联的数据，并建立关联；而手动关联是需要录制两份相同业务流程的脚本，输入的数据要相同，利用WinDiff工具，找出两份脚本之间不同之处，也就是需要关联的数据，再通过web_reg_save_param函数手动建立关联，将脚本中用到关联的数据参数化。
Q14.你如何找出哪里需要关联？请给一些你所在项目的实例。
A14：
1、录制两份相同业务流程的脚本，输入的数据要相同
2、利用BeyondComparePortable工具，找出两份脚本之间不同之处，也就是需要关联的数据
3、通过web_reg_save_param函数手动建立关联，将脚本中用到关联的数据参数化。
示例：
通过录制两份脚本，进行对比，可知jsessionid、sap-ext-sid、sap-wd-cltwndid、sap-wd-tstamp需要进行关联。
Q15.你在哪里设置自动关联选项？
A15：录制选项中进行设置，如下图所示：
Q16.哪个函数是用来截取虚拟用户脚本中的动态值？（手工关联）
A16：Web_reg_save_param函数主要根据需要做关联的动态数据前面和后面的固定字符串来识别、提取动态数据，所以在做关联时，需要找出动态数据的左、右边界字符串。
1.函数原型：
int web_reg_save_param (const char *ParamName, <List of Attributes>, LAST);
2.参数说明：
ParamNam：存放动态数据的参数名称
List of Attributes：其它属性，包含Notfound、LB、RB、RelFrameID、Search、ORD、SaveOffset、Convert、SaveLen。
● Notfound：指当找不到要找的动态数据时，怎么处理。
● Notfound=error，当找不到动态数据时，发出一个错误信息，为LoadRunner的默认值。
● Notfound=warning，当找不到动态数据时，不发出错误信息，只发出警告，脚本会继续执行下去不会中断。
● LB:动态数据的左边界字符串，该参数为必选参数，并区分大小写。
● RB:动态数据的右边界字符串，该参数为必选参数，并区分大小写。
● ORD:指提取第几次出现的左边界的数据，该参数为可选参数，默认值是1。假如值为All,则查找所有符合条件的数据并把这些数据存储在数组中。
● Search：搜寻的范围。可以是Headers（只搜寻Headers）、Body（只搜寻Body部分，不搜寻Headers）、Noresources（只搜寻Body部分，不搜寻Header与Resource）或是All（搜寻全部范围，此为默认值），该参数为可选参数。
● RelFrameID：相对于URL而言，欲搜寻的网页的Frame，此属性可以是All或是具体的数字，该参数为可选参数。
● SaveOffset：当找到符合的动态数据时，从第几个字符开始才存储到参数中，该参数为可选参数，此属性值不可为负数，其默认值是0.
● Convert：可能的值有两种:
● HTML_TO_URL:将HTML-encoded数据转成URL-encoded数据格式。
● HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式。
● SaveLen：从Offset开始算起，到指定长度内的字符串，才储存到参数中，该参数为可选参数，默认值为-1，表示储存到结尾整个字符串。
Q17.你在VUGen中何时选择关闭日志？何时选择标准和扩展日志？
A17：在测试场景执行时，关闭日志，因为日志信息过多，也会影响性能测试结果；在调试测试脚本时，可以选择标准或扩展日志，用于输出调试信息。
可以在运行时设置中，进行日志设置，如下图所示：
Q18.你如何调试LoadRunner脚本？
A18： 通常采用以下方法调试LoadRunner测试脚本
● 断点
【方法】在脚本的任意一行上按右键菜单或F9增加断点。
● 单步跟踪
【方法】通过菜单命令VUser—>Run Step by Step或F10，可以控制脚本以语句为单位执行。
● 日志输出
【方法】通过日志输出函数lr_message、lr_log_message、lr_output_message输出。
● 对话框输出
综上，在实际测试工作中，基本上使用前三种方法，对话框输出基本上没用过。
Q19、你在LR中如何编写自定义函数？请给出一些你在以前进行的项目中编写的函数。
A19：在编写用户自定义函数之前，需要首先为函数创建外部库（DLL）文件，将这些库文件放在bin目录下，一旦库文件已经被添加并且将用户自定义函数作为参数，函数应该为以下格式：__declspec (dllexport) char* (char*， char*)
Q20.在运行设置下你能更改那些设置？
A20：可以修改Run Logic、pacing、Log、Think Time等，见下图；可以测试实际需要，修改相关选项。
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服务器硬件资源使用情况等。
Q31.如何发现数据库的相关问题？
A31：可以通过数据库监控器和数据资源图发现数据库相关的问题，例如在运行Controller之前，可以指定需要度量的资源，之后可以根据监控的数据，分析数据库相关的问题。
Q32.解释所有web录制配置？
A32：选择录制协议、设置录制选项、选择浏览器、选择存放路径、开始录制。
Q33.解释一下覆盖图和关联图的区别？
A33：覆盖图：合并两个图的内容，使用同一个X轴，合并图左Y轴显示当前图的值，合并图右Y轴显示被合并图的值。
关联图：当前活动图的Y轴变为合并图的X轴，被合并图的Y轴变成合并图的Y轴。
Q34.你如何设计负载？标准是什么？
A34：负载测试计划多少用户数量、使用什么类型的机器、以及在什么环境下进行。主要基于两个重要的文档，任务分布图和事务信息，任务分布图告诉我们在负载时间段内，某一个事务使用的用户数，高峰使用率及低峰使用率均来自该文档；
事务信息告诉我们事务名及优先级，在设计场景时可以参考。
Q35.Vuser_init中包括什么内容？
A35：Vuser_init中包含在脚本执行过程中只需执行一次的脚本。一般来说，所有需要初始化的都可以放在vuser_init里面，比如登录。
Q36. Vuser_end中包括什么内容？
A36：vuser_end中一般包含退出的过程，比如退出系统，主要在脚本执行完成或停止时运行，在设置了迭代次数时，vuser_end和vuser_int均只执行一次。
Q37.什么是think time？think_time有什么用？
A37：思考时间：用户在各步骤之间停下来进行思考的时间，由于用户基于其经验水平和目标而与应用程序进行交互操作，因此技术水平更高的用户工作起来可能会比新用户要快。
通过启用思考时间，可以使 Vuser在负载测试期间更准确地模拟其对应的真实世界用户。
Q38.标准日志和扩展日志的区别是什么？
A38：标准日志：脚本执行过程中，将函数集及信息发送到日志文件中
扩展日志：可以将详细的脚本执行信息输出到日志文件中，可以选择以下三种扩展日志信息：
● 参数替换：脚本运行过程中，可以将参数及当前参数值输出到日志文件中
● 服务器返回的数据：将服务器返回给客户端的数据输出到日志文件中
● 高级跟踪：所有的虚拟用户信息和函数调用输出到日志文件中
Q39.解释以下函数及他们的不同之处。
A39：lr_debug_message：发送调试信息到输出窗口或业务监控日志文件中
lr_output_message：发送日志信息到输出窗口或业务监控日志文件中
lr_error_message：发送错误信息到输出窗口或业务监控日志文件中
lrd_stmt：赋予一个SQL语句用于处理
lrd_fetch：获取结果集中的下一行数据
Q40.什么是吞吐量？
A40：客户端每秒从服务器接收到的数据，或系统服务器每秒能处理通过的交易数。一般随着虚拟用户数的增加，吞吐量也增加，说明网络带宽比较充足，反之，吐过随着虚拟用户数的增加，吞吐量比较平稳，呈直线状态，则说明网络带宽成为瓶颈，限制了数据传输。
Q41.场景设置有哪几种方法？
A41：面向目标的场景设置和手动场景
Q42.在进行性能测试的时候，我们需要知道一些有效的性能指标，下面我们来列出一些主要的性能指标：
A42：
一是，通用指标（指Web应用服务器、数据库服务器必需测试项）：
*ProcessorTime：指服务器CPU占用率，一般平均达到70%时，服务就接近饱和；
*Memory Available Mbyte：可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；
*Physicsdisk Time ：物理磁盘读写时间情况。
二是，Web服务器指标：
*Avg Rps：平均每秒钟响应次数＝总请求时间/秒数；
*Avg time to last byte per terstion（mstes）：平均每秒业务角本的迭代次数；*Successful Rounds：成功的请求；
*Failed Rounds：失败的请求；
*Successful Hits：成功的点击次数；
*Failed Hits：失败的点击次数；
*Hits Per Second：每秒点击次数；
*Successful Hits Per Second：每秒成功的点击次数；
*Failed Hits Per Second：每秒失败的点击次数；
*Attempted Connections：尝试链接数。
三是，数据库服务器指标：
*User 0 Connections ：用户连接数，也就是数据库的连接数量；
*Number of deadlocks：数据库死锁；
*Butter Cache hit：数据库Cache的命中情况。
web性能测试中，如何获得dns解析时间？
lr的help文档中提到了 ms_dns_* 的函数
