1.什么是负载测试？什么是性能测试？
性能测试是在预期用户或是大用户量情况下度量系统的可靠性(reliability) 和响应
(responsiveness)。
性能测试同时也用来确认系统性能是否满足用户需求，一般通过负载产生软件包(load generation software package) 模拟应用的真实使用情况。
性能测试包含三种类型的测试
2.性能测试包含了哪些测试（至少举出3种）
1：负载测试(Load Test) – 模拟真实环境下的用户活动，被度量的值包括吞吐量
(Throughput)、稳定性(stability)和应用的响应(responsiveness)。
2.压力测试(Stress Test) – 用来检测应用在扩展情况下的临界点(breaking point)。举例来说，向服务器尽可能快地发送大量交易数据就是对应用的一种压力测试。这种测试不仅对检测系统的最大承受压力能力，而且也能够检测每个时间度量单位内系统能够处理的最大请求数。
3.可靠性测试(Reliability Test) – 检测应用在预期负载下能够持续一定性能水平的时间。这种测试在预期时间内把恒定的负载施加于应用上。
3.简述性能测试的步骤
（1） 测试需求分析
（2） 测试方案制定
（3）设计测试用例
（4） 测试环境，工具，数据准备
（5） 测试脚本的录制，编写与调试
(6) 性能测试场景的制定
（7） 测试执行
（8） 性能测试结果分析和定位问题
（9） 性能测试报告及评估报告
4.简述使用Loadrunner的步骤
5.什么时候可以开始执行性能测试？
测试环境，工具，数据准备
6.LoadRunner由哪些部件组成？
7.你使用LoadRunner的哪个部件来录制脚本？
8.LoadRunner的哪个部件可以模拟多用户并发下回放脚本？
9.什么是集合点？设置集合点有什么意义?Loadrunner中设置集合点的函数是哪个?
Vuser 以便恰好在同一时刻执行任务。通过创建集合点，可以配置多个 Vuser 同
时执行操作。当某个 Vuser 到达该集合点时，将进行等待，直到参与该集合的全
部 Vuser 都到达。指定数量的 Vuser 均到达后，释放所有这些 Vuser。
可通过将集合点插入到 Vuser 脚本来指定会合位置。在 Vuser 执行脚本并遇到集
合点时，脚本将暂停执行， Vuser 将等待 Controller 或控制台的允许以继续执
行。Vuser 从集合释放后，将执行脚本中的下一个任务。
集合点函数可以帮助我们生成有效可控的并发操作。虽然在Controller中多用户负载的Vuser是一起开始运行脚本的，但是由于计算机的串行处理机制，脚本的运行随着时间的推移，并不能完全达到同步。这个时候需要手工的方式让用户在同一时间点上进行操作来测试系统并发处理的能力，而集合点函数就能实现这个功能。集合点只需要在脚本中插入lr_rendezvous()函数即可。打开Insert菜单下的Rendezvous选项，如图3.167所示。
在弹出的对话框中输入集合点名称run，确定后即可得到对应的脚本：
lr_rendezvous("run");
10.什么是场景？场景的重要性有哪些?如何设置场景?
11.请解释一下如何录制web脚本？
12.为什么要创建参数?如何创建参数?
13.什么是关联？请解释一下自动关联和手动关联的不同。
lr关联:手工关联和自动关联
简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。
VuGen提供二种方式帮助您找出需要做关联（correlation）的值：
自动关联
手动关联
一手工关联
lr8.0之前的实现原理是:在客户端和服务端之间设置一个proxy,拦截client和server之间的数据,产生脚本,当然是根据所选定的协议和端口.正因为如此,写在脚本中的,我们模拟客户端对服务端的通信数据是死的,有些情况下会失效,所以需要关联.
所以说,关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。举个例子,有些服务器和客户端对话的流程是这样的,首先,客户端首先发送一个消息,服务端分配一个sessionid,以后,每次客户端发送消息时,都需要带上这个sessionid.
关联可以讲是一个特殊的参数化,只是数据来源不同,普通的参数化数据来源于文件\数据库等,关联的数据来源于服务器动态产生.
要对付这种服务器，我们必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到Session ID的部分，这样就可以成功骗过服务器.
关联（correlation）函数
关联（correlation）会用到下列的函数：
web_reg_save_param：这是最新版，也是最常用来做关联（correlation）的函数。
语法：
web_reg_save_param ( “Parameter Name” , < list of Attributes >, LAST );
web_create_html_param、web_create_html_param_ex：这二个函数主要是保留作为向前兼容的目的的。建议使用web_reg_save_param函数。
手动关联的执行过程大致如下：
使用相同的业务流程与数据，录制二份脚本
使用WinDiff工具协助找出需要关联的数据
使用web_reg_save_param函数手动建立关联
将脚本中有用到关联的数据，以参数取代
检查脚本哪些地方的错误是因为关联引起的,run time setting中设置data returned by server
确定哪些数据需要关联
找出动态数据的左右边界值和出现位置
脚本中添加web_reg_save_param函数
在脚本中参数化脚本中的动态值
校检动态数据
找位置
检查脚本哪些地方的错误是因为关联引起的,run time setting中设置data returned by server,运行,肯定出错,查看出错函数,如request form. was not fount错误信息,有可能是因为关联引起的.找到这个函数,我的一次实践是在web_submit_data()函数.
因为这个sessionid是不同的,所以我们使用相同的操作和数据录制两个脚本,使用tools中的compair with user,比较两个不同的脚本,注意,这个工具是按照action来比较的,同时注意：请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间.保存的文件名太长或者有中文的情况下,会出错.
找出所有不同的地方,再做分析.
使用web_reg_save_param函数手动建立关联
web_reg_save_param要放在提交数据的函数之前,是最近的位置.
在树形图的server中找到web_reg_save_param中要用到的边界
web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串，来辨识要撷取的动态数据的，所以我们还需要找出动态数据的边界字符串。这里要注意的是"要用\做转义字符.
将脚本中有用到关联的数据，以参数取代
当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的（hard-coded）资料。
将
“Name=userSession”, “Value=123456879”, ENDITEM,
换成
“Name=userSession”, “Value={UserSession}”, ENDITEM,
语法
intweb_reg_save_param(const char *ParamName, <list of Attributes>, LAST);
参数说明
ParamName:存放动态数据的参数名称
list of Attributes:其它属性，包含Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert,以及SaveLen。属性值不分大小写，例如Search=all。以下将详细说明每个属性值的意义:
Notfound:指定当找不到要找的动态数据时该怎么处置。
Notfound=error:当找不到动态数据时，发出一个错误讯息。假如没设定此属性，此为LoadRunner的默认值。
Notfound=warning:当找不到动态数据时，不发出错误讯息，只发出警告，脚本也会继续执行下去不会中断。在对脚本除错时，可以使用此属性值。
LB:动态数据的左边界字符串。此属性质是必须要有的，而且区分大小写。
RB:动态数据的右边界字符串。此属性质是必须要有的，而且区分大小写。
RelFrameID:相对于URL而言，欲搜寻的网页的Frame。此属性质可以是All或是数字，而且可有可无。
Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分，不搜寻header)、Noresource(只搜寻body部分，不搜寻header与resource)或是All(搜寻全部范围，此为默认值)。此属性质可有可无。
ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无，默认值是1。假如值为All，则所有找到符合的数据会储存在数组中。
SaveOffset:当找到符合的动态数据时，从第几个字符开始才开始储存到参数中。此属性质不可为负数，其默认值为0。
Convert:可能的值有二种:
HTML_TO_URL:将HTML-encoded数据转成URL-encoded数据格式
HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式
SaveLen:从offect开始算起，到指定的长度内的字符串，才储存到参数中。此参数可有可无，默认值是-1，表示储存到结尾整个字符串。
14.你如何找出哪里需要关联？请给一些你所在项目的实例。
15.你在哪里设置自动关联选项？
16.哪个函数是用来截取虚拟用户脚本中的动态值？（手工管联）
17.你在VUGen中何时选择关闭日志？何时选择标准和扩展日志？
18.你如何调试LoadRunner脚本？
1、设置断点
其实和很多开发工具一样，LR中也能设置断点，具体菜单在：Insert － Toggle BreakPoint；
设置完断点后，当调试执行该脚本时，即会在该处停留，其后的步骤可以使用单步执行等。LR比较笨的是，断点是和行数绑定的，而不是和脚本。我经常在脚本的前面增加代码后，导致断点失位。我用的版本是8.0，不知道现在的新版本有没有改进这些问题。
2、增加Log
一种办法就是手工打Log；
我比较喜欢这样，但只是在需要调试参数的时候使用；在某一行写上类似于lr_log_message("getvalue:ParamVUID_Nbr %s", lr_eval_string("{ParamVUID_Nbr}"))这样，就可以了。执行到这一步骤时，会在日志中打出该参数的值，如getvalue:ParamVUID_Nbr 001001。
另一个办法就是在RunTimeSetting中设置ExecuteLog了。
分别有三种ExecuteLog。
ParameterSubStitution：日志中显示每行脚本中执行时的参数；
DataReturnByServer：日志中显示从服务端返回的值，这招在手工关联时非常管用；大家在手工关联需要动态获取服务端返回值的时候肯定都会去ViewTree的吧？但是有时候Tree不显示，告诉你：无法显示XML。这时候想要知道服务端究竟回给了哪些数据就可以使用这个ExecuteLog了。不过我现在也很懒，很少有耐心去打印这个日志，当我想知道服务端回给了哪些值的时候，我就直接去脚本目录查看data目录下的文件～～汗啊
AdvancedTrace：日志中显示每行脚本中执行的函数以及参数；这个我用的时候觉得没啥意思。
3、被测系统日志
有时候这样做需要有开发人员的协助；在VUGenerator模拟执行的过程中被测系统也可以在关键步骤中打印日志，这样可以更好的协助测试人员调试脚本。
19你在LR中如何编写自定义函数？请给出一些你在以前进行的项目中编写的函数。
20.在运行设置下你能更改那些设置？
21.你在不同的环境下如何设置迭代？
22.你如何在负载测试模式下执行功能测试？
23.什么是逐步递增？你如何来设置？
24.以线程方式运行的虚拟用户有哪些优点？
25.当你需要在出错时停止执行脚本，你怎么做？
26.响应时间和吞吐量之间的关系是什么？
27.说明一下如何在LR中配置系统计数器？
28.你如何识别性能瓶颈？
29.如果web服务器、数据库以及网络都正常，问题会出在哪里？
30.如何发现web服务器的相关问题？
31.如何发现数据库的相关问题？
32.解释所有web录制配置？
33.解释一下覆盖图和关联图的区别？
34.你如何设计负载？标准是什么？
35.Vuser_init中包括什么内容？
36. Vuser_end中包括什么内容？
37.什么是think time？think_time有什么用？
38.标准日志和扩展日志的区别是什么？
39.什么是吞吐量？
40.场景设置有哪几种方法？
验证测试是用于验证在特定的场景、时间、压力、环境和操作方式下系统能够正常的运行，服务器、应用系统和网络环境等软硬件设施还能否良好的支撑这些情况下用户的使用。验证性测试主要针对有明确的压力目标和预期结果，验证系统在这种压力下的各方面反映能够达到预期结果。
主要分以下几种：
压力测试：已知系统高峰期使用人数，验证各事务在最大并发数（通过高峰期人数换算）下事务响应时间能够达到客户要求。系统各性能指标在这种压力下是否还在正常数值之内。系统是否会因这样的压力导致不良反应（如：宕机、应用异常中止等）。
Ramp Up 增量设计：如并发用户为75人，系统注册用户为1500人，以5％－7％作为并发用户参考值。一般以每15s加载5人的方式进行增压设计，该数值主要参考测试加压机性能，建议Run几次。以事务通过率与错误率衡量实际加载方式。
Ramp Up增量设计目标： 寻找已增量方式加压系统性能瓶颈位置，抓住出现的性能拐点时机，一般常用参考Hits点击率与吞吐量、CPU、内存使用情况综合判断。模拟高峰期使用人数，如早晨的登录，下班后的退出，工资发送时的消息系统等。
另一种极限模拟方式，可视为在峰值压力情况下同时点击事务操作的系统极限操作指标。加压方式不变，在各脚本事务点中设置同集合点名称（如：lr_rendzvous("same");）在场景设计中，使用事务点集合策略。以同时达到集合点百分率为标准，同时释放所有正在Run的Vuser。
稳定性测试：已知系统高峰期使用人数、各事务操作频率等。设计综合测试场景，测试时将每个场景按照一定人数比率一起运行，模拟用户使用数年的情况。并监控在测试中，系统各性能指标在这种压力下是否能保持正常数值。事务响应时间是否会出现波动或随测试时间增涨而增加。系统是否会在测试期间内发生如宕机、应用中止等异常情况。
根据上述测试中，各事务条件下出现性能拐点的位置，已确定稳定性测试并发用户人数。仍然根据实际测试服务器（加压机、应用服务器、数据服务器三方性能），估算最终并发用户人数。
场景设计思想：从稳定性测试场景的设计意义，应分多种情况考虑：
针对同一个场景为例，以下以公文附件上传为例简要分析场景设计思想：
1）场景一：已压力测试环境下性能拐点的并发用户为设计测试场景，目的验证极限压力情况下测试服务器各性能指标。
2）场景二：根据压力测试环境中CPU、内存等指标选取服务器所能承受最大压力的50%来确定并发用户数。
测试方法：采用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechedule-勾选Initalize all Vusers before Run
容错性测试：通过模拟一些非正常情况（如：服务器突然断电、网络时断时续、服务器硬盘空间不足等），验证系统在发生这些情况时是否能够有自动处理机制以保障系统的正常运行或恢复运行措施。如有HA（自动容灾系统），还可以专门针对这些自动保护系统进行另外的测试。验证其能否有效触发保护措施。
问题排除性测试：通过原有案例或经验判断，针对系统中曾经发生问题或怀疑存在隐患的模块进行验证测试。验证这些模块是否还会发生同样的性能问题。如：上传附件模块的内存泄露问题、地址本模块优化、开启Tivoli性能监控对OA系统性能的影响等等。
测评测试是用于获取系统的关键性能指标点，而进行的相关测试。主要是针对预先没有明确的预期测试结果，而是要通过测试获取在特定压力场景下的性能指标（如：事务响应时间、最大并发用户数等）。
评测事务交易时间：为获取某事务在特定压力下的响应时间而进行的测试活动。通过模拟已知客户高峰期的各压力值或预期所能承受的压力值，获取事务在这种压力下的响应时间。
评测事务最大并发用户数：为获取某事务在特定系统环境下所能承受的最大并发用户数而进行的测试活动。通过模拟真实环境或直接采用真实环境，评测在这种环境下事务所能承受的最大并发用户数。判定标准阈值需预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。
评测系统最大并发用户数：为获取整个系统所能够承受的最大并发用户数而进行的的测试活动。通过预先分析项目各主要模块的使用比率和频率，定义各事务在综合场景中所占的比率，以比率方式分配各事务并发用户数。模拟真实环境或直接采用真实环境，评测在这种环
境下系统所能承受的最大并发用户数。判定标准阀值预先定义（如响应时间，CPU占用率，内存占用率，已出现点击率峰值，已出现吞吐量峰值等）。取值标准以木桶法则为准（并发数最小的事务为整个系统的并发数）。
评测不同数据库数据量对性能的影响：针对不同数据库数据量的测试，将测试结果进行对比，分析发现数据库中各表的数据量对事务性能的影响。得以预先判断系统长时间运行后，或某些模块客户要求数据量较大时可能存在的隐患。
问题定位测试在通过以上测试或用户实际操作已经发现系统中的性能问题或怀疑已存在性能问题。需通过响应的测试场景重现问题或定义问题。如有可能，可以直接找出引起性能问题所在的代码或模块。
该类测试主要还是通过测试出问题的脚本场景，并可以增加发现和检测的工具，如开启Tivoli性能监控、开启HeapDump输出、Linux资源监控命令等。并在场景运行过程中辅以手工测试。
,,支持一下
