都说明骚易躲，暗贱难防，93年的小鲜肉都已毕业走上职场，永远18岁的你，是不是还在贱人360°夹击下举步为艰？ 年轻人！

贱人们每日打卡花式表演，加班花式表演，认真工作？抱歉，他们其实是演员。眼看小人得志，贱人横行，辛苦做事的“走地鸡”们哀鸿遍野，为了地球和平，人类安宁，齐姐姐只好带着水兵月的责任心，代表月亮传授绝学，望众生早日KO贱人，“出任CEO, 走上人生巅峰”！

点炮王

你说红色美，他就说红色妖；你说西瓜好吃，他就说西瓜含糖量高；点炮王与生俱来的优越感堪比金三胖，三句话会有一个炮点，五句话必有一个意见。在提案会议上，你说一个提议，他分秒驳回。无论你说的是中文还是法语，他早已用看穿一切的眼神蔑视众生，仿佛维基百科都装在他小脑仁里。

KO心法：

点炮王对全世界都意见，实际就是存在感缺失，这种患者不是富二代就是负二代。要是王思聪，你就玛丽苏他，总有一天霸道总裁爱上我。要是犀利哥，你就于谦他，捧哏会吗？哦，咦，嗯，啊。继而忽闪着大眼睛说：“我不太明白您的意思呢，要不，您来？

情绪娘娘

三月伤春，十月悲秋，出门遇狗咬，停车被贴条，还配合着天气预报发圈文“阴天，在不开灯的房间”。情绪娘娘每天的内心都几乎是崩溃的。没交涉两句，无由来的怒气撒你一脸，一起工作就好似行走宫廷深深，时刻提防对方暴走，项目进度跟随她内分泌周期而决定。

KO心法：

稳住对方情绪，快速结束战斗才是主要矛盾 。熊孩子一哭，你就塞他一块糖。So，一见面就随便找个由头夸她：“哎呦您这鞋子真好看！最近又瘦了啊，气色红润万人迷啊？呵呵哈哈哈哈哈，您看这个项目我们如此处理了吧….”。

口号侠

这是一出场便自带新闻联播背景音乐的侠，头顶圣骑士光环的侠。无论什么会议，他一定要醍醐灌顶：“市场大好，领导体恤，人民勤劳，在党和国家的关怀下，我们必须完成任务！”（此处有掌声）。

然后，就没有然后了。对，口号侠从不干活！NEVER！

KO心法：

口号侠基本是皇亲国戚，活不干但意见要发，事儿不做但功劳要拿。他发言你就鼓掌,他喊话你就叫好。用捧角儿的心捧着他，邮件封封CC他，会议场场邀约他，每每交谈，眼神中充满“崇拜”，大型汇报必提“口号侠”。妥了，坐等口号侠变历史人物吧。

事儿妈

打听隐私散播传闻，是她人生的一剂**，只要八卦在手，必定春风满面，跟她聊五分钟就能知道，大刘家喝的奶粉是澳洲还兰州的，小美的手镯是第几个备胎送的，以及老王小学同学的外甥女儿的男友他数学老师其实是CEO的小姨子！

KO心法：

职业归职业，生活归生活，谁也不想昨夜刚泡妞被拒，今天就在早会被提起，明星都要请人打理公众形象，更别提普通人的你。遇到事儿妈，请闭嘴，请闭嘴，请闭嘴，重要的事情说三遍！不讨论，不传播，不插话，远离娱乐圈，早日得道修仙。

唐三藏

三藏带队精兵强将，还有实现和平的梦想。三藏说起话来没逻辑没套路，自从看了驰骋的C罗，他就爱上了科比。三藏爱叨逼叨，却一直叨不到点上。一秒不差的说两小时，基本可以概括为“你好，我好，大家好”。三藏自知没有旷世奇才，只能用紧箍咒管理统治，无论他说的是啥，你必须听下去……

KO心法：

能发邮件尽量不发信息，能发信息尽量不发语音，能发语音尽量不打电话，能打电话尽量不面对面。实在要面对面，请脑海自动Replay 年度大剧《小时代4》。总而言之，躲远点，对自己负责，对家庭负责，对生命负责。

挖掘机队长

挖掘机技术哪家强？他绝对胜过蓝翔。挖掘机队长面带微笑，没有一丝顾虑的出现，鼓舞人心又勇敢无畏。 短短几周，业绩涨停翻番，队长封侯拜相。直到他拍拍屁股把工作交接给你的那天，你才发现在光鲜亮丽之下，无数大坑等着后来者填平。

KO心法：

前面的贱人都只是添堵，挖掘机队长会让你真丢饭碗。他爱讲大话，你就写好会议纪要。他爱拍胸脯，你就做好推进表。记住，谁污染来谁治理。问他细节、问时间推进，跟他权责分明，所以口头协商变成文档，签字画押才有效！

假菩萨

他笑脸呵呵从不发飙，手上佛珠是蜜蜡的，桌上茶具是汝窑的。你以为遇上了高人？图样！你跟他谈工作，他跟你谈哲学，你跟他谈管理，他跟你谈梦想。你申请涨薪，他跟你讲格局决定未来，你申请升职，他告诉做人要胸怀天下。只要不落到实质上，他什么都可以谈！

KO心法:

请移步各大招聘网站。嗯，深藏功与名！

讲真，职场不是战场，巧妙的处理才是KO关键，红遍网络的“职场卸膊操”，每一句，你一定会听到，会用到。拿走不谢！

本内容为企业面试关于自动化测试的考题，大家可以自己思考下如何作答，欢迎把答案留言到本文下方哦。

问题1：请详细阐述接口测试和UI测试在测试活动中是如何协同测试的？

问题2：在手工接口测试或者自动化接口测试的过程中，上下游接口有数据依赖如何处理？

问题3：依赖于第三方数据的接口如何进⾏测试？

问题4：接口测试中依赖登录状态的接口如何测试？

2.3 共性问题

2.31 虚拟客户脚本“Run-time Setting”中的线程和进程运行方式的区别？

　如果选择“Run Vuser as a process”，则场景运行时会为每一个虚拟用户创建一个进程；选择“Run Vuser as a thread”则将每个虚拟用户作为一个线程来运行，在任务管理器中只看到一个mmdrv.exe，这种方式的运行效率更高，能造成更大的压力，时默认选 项。

另外，如果启用了IP欺骗功能，则先在Controller中选中Tools菜单下的“Expert Mode”，然后将Tools菜单下的“Options>General”标签页中的IP地址分配方式也设置为与Vuser运行方式一致，同为线程或进程方式。

2.32 thinktime与pacing的设置对脚本及场景的影响

在我测试的过程中在稳定性测试场景中有一次我对场景中的一个脚本取消了pacing设置，结果导致VU退出，出现了内存冲突的错误。

在我们测试中BancsLink_C63601_C63603_短信功能定制和删除、 BancsLink_C60422_C60423_活期与定期批次转出关联、BancsLink_C67050_C67000_修改客户信息提示等交易，不加thinktime时也会报错。

首先我们要明确设置他们的意义。

Pacing是通过设置两次迭代之间的间隔时间，来调整各个action之间的步调。从定义上来看，它是和iteration绑定在一起的。Pacing的设置可以调节系统压力的大小，影响系统处理事务的能力。在场景运行中pacing的设置是很重要的。

Think time是通过设置思考时间，来模拟真实用户在操作过程中的等待时间。从定义上来看，它是在iteration内部的某个action中各个步骤的间隔时间，主要目的在于模拟真实用户操作情况，在测试中使虚拟用户对业务的操作更接近实际。

示例：假设用户进行一次操作会消耗5秒钟的时间，即完成整个迭代需要5秒钟。如果用户不停顿，继续第二次重复操作，则同样耗费约5秒左右的时间。但是真实世 界中肯定是有停顿的。一个真正的用户，做完一系列操作后，会间隔一段时间。假定用户停顿了5秒，再第二次重复操作，则一共耗费10秒钟时间。映射到 loadrunner中，就需要在一次iteration中，设置一个thinktime = 1秒，然后在两个iteration之间，设置一个pacing为5秒。

2.33 在运行场景中两个vu并发时交易出现错误，在脚本中没有出现这种情况。

查看日志发现两vu所使用的参数值是一样的，所以在接收报文时VU不能对应的找到自己的接收报文。

解决办法

1、在场景中修改VU家在策略，有一次全部加载改为逐步加载。

2、改变取参策略，把数据分块，然后分到固定的VU。

2.34 题描述Deleted the current transaction ... since response time is not accurate

出现这个问题时TPS大幅下降，VU并没有掉。这个问题不多遇见，在调试稳定性测试场景中遇到几次。一般出现在压力机器上发生ping值为负数时，可以重新启动pc机或者打补丁，如果还不行把场景另存.

2.35 日志缓存过小：to Log cache is too small to contain the message.

由于场景中Auto Log cache默认设置为1k，但是遇到报文较长的交易时自动日志缓存的容量就太小了我们就得手动修改。

2.36 运行中掉VU。

1、出现Action.c(35): Error : save param parameter is invalid. Error code : 9005. Error -- memory violation : Exception ACCESS_VIOLATION received.

内存冲突的问题很普遍，有些程序设置之间的冲突也会导致这个错误，就脚本里来讲，HTTP录制的脚本里面关联错误会导致内存冲突；在socket协议的脚本里判断成功时我们一般采用字母、数字与存储在缓冲区里的报文做匹配，但是我们存在缓冲区里面的报文是二进制格式的，所以在场景中也会造成内存冲突，最后掉VU。可能一个很小的问题就会引起内存冲突。

2、内存资源不足：脚本中的事务执行后没有释放buffer，最好在每个事务结束后就释放buffer。

3、压力过大：压力过大导致本地存储收回报文的存储空间不足，写不了日志也会掉VU

4、参数取值不正确也可能导致掉VU

5、系统自身原因。

总体来说，解决方法就是调整脚本、分成多台压力机进行测试。

2.37 为什么Windows系统中的CPU、内存等资源仍然充足，但是模拟的用户数量却上不去?

在Windows计算机的标准设置下，操作系统的默认限制只能使用几百个Vuser，这个限制与CPU或内存无关，主要是操作系统本身规定了默认的最大线程数所导致。要想突破Windows这个限制，须修改Windows注册表。以Windows XP Professional为例。

　　(1)打开注册表后，进入注册表项HKEY_LOCAL_MACHINE中的下列关键字：System\CurrentControlSet\Control\Session Manager\SubSystems。

　　(2)找到Windows关键字，Windows关键字如下所示：

　　%SystemRoot%\system32\csrss.exe bjectDirectory=\Windows

　　SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1

　　ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2

　　ProfileControl=Off MaxRequestThreads=16

　　SharedSection=1024,3072,512关键字的格式为xxxx,yyyy,zzz。其中，xxxx定义了系统范围堆的最大值(以KB为单位)，yyyy定义每个桌面堆得大小。

　　(3)将yyyy的设置从3072更改为8192(即8MB)，增加SharedSection参数值。

　　通过对注册表的更改，系统将允许运行更多的线程，因而可以在计算机上运行更多的Vuser。这意味着能够模拟的最大并发用户数量将不受Windows操作系统的限制，而只受硬件和内部可伸缩性限制的约束。

2.38 问题描述open many files

问题一般都在压力较大的时候出现，由于服务器或者应用中间件本身对于打开的文件数有最大值限制造成，解决办法：

1、修改操作系统的文件数限制，aix下面修改limits下的nofiles限制条件，增大或者设置为没有限制，尽量对涉及到的服务器都作修改。

2、方法一解决不了情况下再去查看应用服务器weblogic的commonEnv.sh文件，修改其中的nofiles文件max-nofiles数增大，应该就可以通过了，具体就是查找到nofiles方法，修改其中else条件的执行体，把文件打开数调大。修改前记住备份此文件，防止修改出错。

3、linux上可以通过ulimit –HSn 4096来修改文件打开数限制，也可以通过ulimit -a 来查看。

4、linux上可以通过lsof -p pid | wc -l 来查看进程打开的句柄数。

2.38 LoadRunner与服务器连接时遇到的问题

（1）ERROR:sck connect Aborted

这种错误一般是软件造成连接中断。由于软件错误，造成一个已经建立的连接被取消，比如LoadRunner自身的bug，在发报文时多位。典型情况下，这意味着连接是由于协议或超时错误而被取消的。

（2）ERROR：Failed to connect to server

这个问题一般是客户端链接到服务失败，原因有两个客户端连接限制（也就是压力负载机器），一个网络延迟严重，解决办法：

　　1、 修改负载机器的tcpdelaytime注册表键值，将其改小改小；

　　2、 检查网络延迟情况，看问题出在什么环节；

　　为了减少这种情况，最好测试中有个干净的网络环境，每个负载机器的压力测试用户数不易过大，尽量平均每台负载器的用户数，这样以上问题出现的概率就会减小。

（3）ERROR:has shut down the connection prematurely

分为以下三种情况：

1.应用访问死掉

　　 小用户时：程序上的问题或数据库的问题 ，应该查看一下sql执行效率和JAV的垃圾回收情况，具体定位问题。

　　 2.应用服务没有死

　　 应用服务参数设置问题

　　例如：

　　在许多客户端连接Weblogic应用服务大部分被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％。　　Java连接池的大小设置，或JVM的设置等

　　3. 数据库的连接

　　在应用服务的性能参数可能太小了

　　数据库启动的最大连接数（跟硬件的内存有关）

(4)ERROR: connection refused.

这种情况比较复杂，需要检查几个地方，不同的操作系统也会有不同的操作方式。

1．首先检查是不是连接weblogic服务大部分被拒绝，监控weblogic的连接等待情况，可能与上面的一样需要增加AcceptBacklog，如果没有解决问题，还要增加增加连接池，调整线程数，（连接池数*Statement Cache Size）的值应该小于数据库连接数的最大值。

2．查看服务器的操作系统中是否对连接数做了限制，AIX下可以直接编辑limit文件，修改连接数、端口数的限制以及tcp连接等待时间的间隔大小。若是windows系统，则要修改其注册表，修改TcpTimeWaitDelay（默认值30s）和MaxUserPort（可以调到小于最大值）项，键值在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Tcpip\Parameters\。因为当负载生成器的性能很好时，发数据包特别快，服务器响应也很快，从而导致负载生成器的端口在没有timeout之前就占满了。端口没有可用的时候就会出现错误，。执行netstat-na命令，可以查看端口。如果调整了TCP的timeout，情况会好点，在端口还没有占满前就有释放的了。

1.2 socket脚本开发问题

1.21 接收报文为空

一般来说socket接收报文为空主要因为发送报文不正确而出现接收为空。解决办法也很简单，检查参数化是否有问题或者重截报文。

参数化的一般原则是：

1、参数化文件尽可能少，因为参数是放在内存中的，占用了内存的资源；

　　2、参数化文件与脚本分离；

　　3、参数文件的路径应该以相对路径来取；

　　4、一些时候为了使参数更具有真实性，参数应该从数据库中来获得；

　　5、参数类型的选择；

　　6、参数的数据一般要由业务决定；

1.22 运行脚本时出现跳参

在执行建立账户时出现跳过参数导致交易失败的问题。可能是Thinktime设置过小导致的，时间延长后还是存在，只是减少了许多。

1.23 出现运行脚本错误，会出现如下提示，另存脚本也报错。

这种情况可能是在移植脚本时数据丢失，另一种原因是在上次打开或脚本执行时系统里面有了该脚本的死进程。

解决办法：首先查看脚本的各个部分是否正确，最好点一下程序编译检查错误，如果没有错误，新建脚本把里面的东西拷贝过去。也可以先看看系统是否有死进程结束掉或者重启机器。

1.24 有些脚本在lr中运行一段时间会被卡死

A、报文接收长短不一致。如：60480客户查询交易，以前总是迭代到二百次左右时会被卡死，经查看是接收报文长度不一样造成的，后来用LR自带的EndMark函数进行截取接收报文中的有效信息，就可以解决这个问题。

B、数据量过大造成脚本卡死。由于LoadRuuner自带的Bug，所以在脚本运行时间较长、数据量大时会出现ERROR错误，程序无法终止，点击一下error脚本迭代一次，造成效率大幅下降。后来只能结束进程。原脚本也因为有些进程死掉不能再运行。然后另存新脚本才能继续运行。

1.25 对run-time setting 设置失败

打开run-time setting会弹出Failed to load run logic file

点击确定会出现run-time setting设置窗口，对其设置之后会提示设置保存失败。

此问题出现的原因是配置loadrunner加载运行时设置的default文件丢失。把其脚本的default文件拷贝过来一个放在脚本里目即可。

1.26 使用IP欺骗出现的问题

问题描述：The IP wizard does not support DHCP-enabled network cards.

　　Your cards are either DHCP-enabled or configured with invalid settings.Please contact your system administrator.

解决办法：首先，本地的IP设置不能为“自动获取”，必须指定一个静态IP。其次，所添加的IP只能是局域网内的网段只能添加192段，127段，10段IP地址

1 录制脚本问题

1.1 HTTP 脚本问题

1.11 LoadRunner录制脚本时为什么不弹出IE浏览器?

1．一台主机上安装多个浏览器时，LoadRunner录制脚本经常遇到不能打开浏览器的情况，可以用下面的方法来解决。

启动浏览器，打开Internet选项对话框，切换到高级标签，去掉“启用第三方浏览器扩展(需要重启动)”的勾选，然后再次运行VuGen即可解决问题

　　提示：通常安装Firefox等浏览器后，都会勾选上面得选项，导致不能正常录制。因此建议运行LoadRunner得主机上保持一个干净的测试环境。

2．在系统中安装了多个浏览器需在“program to record”中指定需要启动的浏览器的可执行文件。

3．览器的版本应与loadrunner的版本一致。

LR 8--------àIE6

LR9---------àIE7

LR11--------àIE8

4．操作系统有关

windows server 在有数据执行保护，应将vugen.exe加入不受系统的保护项。

1.12 录制脚本为空

LR录制是客户端与服务器的数据交互，只有在有交互的时候才可以录制到脚本。

　　A、(1) 交互方式若是通过客户端的server进行交互，则在script中选择最后一个track processes created as COM local servers ，把script里的最后一个选项选上就好了。

（2）若是非客户端与服务器的交互操作，在页面上点前进或后退，如果页面是从缓存中取出来的，那么也就没有和服务器数据交互，所以也录制的为空脚本。 在windows注册表中禁用缓存就好了.

（3）协议选择错误，b/s不一定走http协议，还可能是https（hypertext transfer protocol over secure socket layer）协议。

B、选择internet选项里的连接里的局域网设置的代理不能选，因为LR在录制的时候会动态选择。

C、网页里的恶意代码，检测的时候响应LR录制脚本[用工具检测恶意代码，然后卸载恶意代码，例如：Ad_Aweare] ，这个可能性不大。

D、防病毒软件和防火墙，在录制时暂时关闭。

E、 因为LR自身原因报错或者有些脚本不能录制下来，录制时最好选用view script，此时会报错，但能录下脚本，是因为LR无法解析，可以手工修改，而view tree 就直接停止了。

1.13 录制Web脚本时，生成的脚本中存在乱码该如何解决?

第一步：

录制脚本前，打开录制选项配置对话框Record-Options，进入到Advanced标签，先勾选“Support charset”，然后选择中支持UTF-8。再次录制，就不会出现中文乱码问题了。

第二步：服务器响应报文中显示乱码

若是录制的脚本在切换到Server Response中，所有的中文全部变成乱码，如“勌缞仫訆”。

原因是服务器端没有把响应的编码设置为gb2312，在IIS中找到Web.Config文件，在<system.web>….</system.web>节加入<globalization requestEncoding="gb2312" responseEncoding="gb2312" fileEncoding="gb2312"/>后再次录制脚本，乱码变中文。

还有另一种情况：是录制的脚本里有乱码,但是不影响回放，测试中需要对其进行参数化，我们可以通过字符串编码转换的函数lr_convert_string_encoding( const char *sourceString, const char *fromEncoding, const char *toEncoding, const char *paramName)进行转换：

lr_convert_string_encoding(lr_eval_string("{name}"),LR_ENC_SYSTEM_LOCALE,LR_ENC_UTF8,"str");

strcpy(tmp,lr_eval_string("{str}"));

第三步：回放过程中，LR的快照中显示乱码

解决方案：

在Run-time settings下Browser Emulation中点击change。。按钮

在User-Agent对话框中更改Browser的类型和版本。

1.14 ERROR：not found the correlation Parameter。Memorry violation…

1.关联错误，检查关联的内容是否正确，左右边界取值是否准确很多时候，在关联的左右边界中是不分大小写的。

2.关联较多时如果左右边界不唯一，会出现左右边界分不清的情况，参数值也会取不到。

解决办法有两种：一、左右边界可以取长点直到可以唯一标识关联参数时；二、如果需要的关联很多，可以利用ORD控制（ord用来确定第几次出现的值，是要关联的值 ,默认值为1，就是第一次出现的值为关联的值，而设置成ALL则表示关联全部存在于左右边界的值，ord=all时可以使用参数数组）。在9.x的版本中提供了三个关于Ord的主要函数：

lr_paramarr_len

lr_paramarr_idx

lr_paramarr_random

1.15 关联报错：Action.c(20): Error -26377: No match found for the requested parameter "xxxxxx". Check whether the requested boundaries exist in the response data. Also, if the data you want to save exceeds 1024 bytes, use web_set_max_html_param_len to increase the parameter size [MsgId: MERR-26377]

这个问题是因为存放参数的缓冲区大小默认为1024个字节，也就是1k，比较小。应该根据需要进行调整。

解决方法：

web_set_max_html_param_len()函数可以自定义关联返回值存放的参数的最大长度，且一定要写在关联函数前面.

1.16 问题描Error-27257: Pendingweb_reg_save_param/ reg_find/create_html_param[_ex] request(s) detected and reset at the end ofiteration number 1

解决方法：web_reg_save_param位置放错了，应该放到请求页面前面。且在插入文本检查点时，正确写入 web_reg_find的参数值，通常TextPfx和TextSfx中会包含特殊字符如：双引号，等特殊字符，需要进行转义（用斜杠）例如：

web_reg_find("Search=Body",

"SaveCount=Welcome",

"TextPfx=欢迎<a class="drop" id="viewpro" nMouseOver="showMenu(this.id)">",

"TextSfx=</a>",

LAST);

1.17 为什么脚本中添加了检查方法Web-find，但是脚本回放时却没有执行?

由于检查点功能会耗费一定的资源，因此LoadRunner默认关闭了对文本及图像的检查。要想开启检查功能，必须修改运行时的配置Run-time Setting。

　　进入“Run-time Setting”对话框，依次进入“Internet Protocol→Preferences”，勾选Checks下的“Enable Image and text check”选项即可。

　　检查执行结果时推荐使用web_reg_find方法。

1.18 一些Web虚拟用户脚本录制后立刻回放没有任何问题，但是当设置迭代次数大于1时，如果进行回放则只能成功迭代一次。为什么从第二次迭代开始发生错误?

这种现象多是由于在“Run-time Setting”的“Browse Emulation”的设置中，勾选了“Simulate a new user on each iteration”及其下面的选项“Clear cache on each iteration”这两个选项的含义是每次迭代时模拟一个新的用户及每次迭代时清除缓存。

由于脚本迭代时，init和end只能执行一次，如果每次都模拟一个新的用户并清除缓存，则用户登录信息将一并删除，迭代式可能会出现问题。

1.19 LoadRunner请求无法找到：在录制Web协议脚本回放脚本的过程中，会出现请求无法找到的现象，而导致脚本运行停止。

错误现象：Action.c(41): Error -27979: Requested form. not found [MsgId: MERR-27979]

Action.c(41): web_submit_form. highest severity level was “ERROR”,0 body bytes, 0 header bytes [MsgId: MMSG-27178]”这时在tree view中看不到此组件的相关URL。

错误分析：所选择的录制脚本模式不正确，通常情况下，基于浏览器的Web应用会使用“HTML-based script”模式来录制脚本；而没有基于浏览器的Web应用、Web应用中包含了与服务器进行交互的Java Applet、基于浏览器的应用中包含了向服务器进行通信的JavaScript/VBScript代码、使用HTTPS安全协议，这时则使用“URL-based script”模式进行录制。

解决办法：打开录制选项配置对话框进行设置，在“Recording Options”的“Internet Protocol”选项里的“Recording”中选择“Recording Level”为“HTML-based script”，单击“HTML Advanced”，选择“Script. Type”为“A script. containing explicit”。然后再选择使用“URL-based script”模式来录制脚本。

注： HTML-based 方式和URL-based 方式的区别

HTML-based 方式对每个页面录制形成一条语句，对LoadRunner来说，在该模式下，访问一个页面，首先会与服务器之间建立一个连接获取页面的内容，然后从页面中分解得到其他的元素（component），然后建立几个连接分别获取相应的元素。

URL-based 方式将每条客户端发出的请求录制成一条语句，对LoadRunner来说，在该模式下，一条语句只建立一个到服务器的连接，LoadRunner提供了web_concurrent_start和web_concurrent_end函数模拟HTML-based的工作方式。

如何决定选择何种录制方式？

1、如果应用是WEB应用，首选是HTML-based方式；

2、如果应用是使用HTTP协议的非WEB应用，首选是URL-based方式；

3、如果WEB应用中使用了java applet程序，且applet程序与服务器之间存在通讯，选用URL-based方式；

4、如果WEB应用中使用的javascript、vbscript脚本与服务器之间存在通讯（调用了服务端组件），选用URL-based方式。

1.20 在录制一个应用的过程中，需要进行查询操作，若查询的返回结果过多，引起后续的脚本无法继续录制。

这是由于loadrunner所能处理的数据条目小于返回的数据条目，导致了loadrunner不能处理返回的值。可以通过修改vugen.ini文件中的CmdSize=xxxxxxx的值，使得loadrunner所能处理的数据条目大于查询返回的数据条目。

在湿货|大数据测试之hadoop单机环境搭建(超级详细版)这个基础上，我们来运行一个官网的MapReduce demo程序来看看效果和处理过程。

大致步骤如下：

新建一个文件test.txt，内容为

Hello Hadoop

Hello xiaoqiang

Hello testingbang

Hello http://xqtesting.sxl.cn

将test.txt上传到hdfs的根目录

/usr/lib/hadoop/hadoop-2.7.4/bin/hdfs dfs -put /root/install/test.txt /

然后浏览器访问可以看到刚才上传的文件，如下图

运行官方的一个wordcount程序来统计字符数量，命令如下：

/usr/lib/hadoop/hadoop-2.7.4/bin/hadoop jar /usr/lib/hadoop/hadoop-2.7.4/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.4.jar wordcount hdfs://localhost:9000/test.txt hdfs://localhost:9000/out

解释下这个命令，大致意思是用hadoop执行一个叫hadoop-mapreduce-examples-2.7.4.jar的wordcount 方法，其中输入参数为hdfs上根目录的test.txt 文件，而输出路径为hdfs跟目录下的out目录

PS：我这里没有把hadoop配置成环境变量，所以命令很长，你可以配置下，这样命令就会短很多了，至于怎么配置，自己悟~

执行过程如下：

执行完成之后再次刷新浏览器可以看到out目录和结果了

点击part-r-00000，在弹出的页面点击download

这时候下载会出现404，我们只需要在URL里的localhost改为你服务器的ip地址就可以下载了。下载之后用编辑器打开，内容如下：

PS：你也可以用命令查看，如下图

到这里，我们既完成了hadoop环境的搭建，也完成一次MapReduce的执行。其实也算是对hadoop功能的测试。如果你都成功了，那么恭喜你！如果你没有成功，那么也恭喜你，因为你发现了自己的不足！

最后，大家请多多转发本文，每一步都是小编自己做的，耗费了很多脑细胞~转发才是对小编的最大支持哦

引子

部门里难免都会要求大家去写日报，其实这个是繁琐的工作，以前一直都是邮件或者excel，觉得查看和统计不方便。无意中网上看到了一款开源的日报系统，部署一下试试，这里就记录下步骤。

部署步骤

1、基本的linux和apache环境

2、安装nodejs

    a、官网下载

    b、解压之后进入bin目录

    c、./node -v 可以看到版本

    d、设置全局，命令如下：

    ln -s /opt/node-v6.10.3-linux-x64/bin/node /usr/local/bin/node

    ln -s /opt/node-v6.10.3-linux-x64/bin/npm /usr/local/bin/npm

3、安装redis

    a、官网下载、解压、进入目录

    b、make && make install

    c、redis-server 运行

4、部署日报系统

    a、把dailyReport放到/opt/apache2/htdocs下

    dailyReport下载地址：https://github.com/WalterShe/dailyreport/zipball/master

    b、进入该目录运行：npm install

    c、vi config.js，修改app的端口为8888

    d、运行nohup node app.js &，之后看到输出'Express server listening on port '8888' 则表示服务器启动成功。

    如果想让它在后台永久运行则需要这样做：

     npm install -g forever

    forever start /opt/apache2/htdocs/dailyReport/app.js

    e、浏览器地址栏输入http://你的域名/install,会看到设置默认管理员账户成功页面，按照提示进入网站登陆界面，

    输入管理员账户名 adminn,密码1234567则可以登陆成功

    f、手机版访问地址是：http://你的域名/m

之前发布过一篇关于ETL的文章，无奈被人说太简单。。。。唉，小编也是刚接触啊，自然不能那么高深，所以只是对学习的过程做了记录转换为文章分享给大家，如果对你有帮助，不要吝啬点赞+转发，如果对你没有帮助，那就请转身离开。。。。或者你写一篇更详细的给我，我申请红包给你（邪恶的笑~）

好啦，回归正题，这次作为补充在详细介绍下。ETL是什么？其实ta指的是一个过程，就是大数据中对数据处理的过程（抓取>转换>装载），并不是一个技术！

小编也是慢慢的学习大数据测试的知识，一直有个问题也困扰着我，就是怎么能判定数据的正确性？是，可以有多种手段去判定，但没办法保证100%的正确吧？（明白的朋友可以告诉我哈~）

反正，总而言之ETL测试的核心就是要保证数据的正确性、一致性，其他都是浮云~

常见的ETL测试方法（主要就是对数据处理中的各个关键点进行验证）

那么，怎么测试呢？莫急，看~

1、数据量。这个应该不用多说，你从源头拿来多少，存到目标表里又是多少，是否一致，是否正确

2、转换。主要是对数据格式的合法性进行验证。参考点为：

• 源中的时间、数值、字符等数据的处理，是否符合数据仓库规则，是否进行统一的转换

• 是否有超出维表或者业务值域的范围

• 是否捕获字段空值，或者需要对空值进行替换为其他含义值的处理

• 主键是否唯一

• 特殊符号或者乱码符号的处理规则

• 脏数据的处理

3、抽样。在转换完成之后要对转换之后的关键字段验证，还有源表和目标表的映射是否正确

4、加载。这块比较麻烦，有全量加载（先清空再插入）和增量加载（目标表仅更新源表变化的数据）。选择哪种方式要看实际的系统是怎么设计的，没有标准。实际应用中，增量加载用的比较多，下面我们就说说ta。

触发增量加载的方式（此处内容部分来自于网络的收集，自己做了下总结）

触发器方式

在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中的数据发生变化，相应的触发器就会将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。

优点：数据抽取的性能高，ETL 加载规则简单，速度快，不需要修改业务系统表结构，可以实现数据的递增加载。

缺点：要求业务表建立触发器，对业务系统有一定的影响，容易对源数据库有倾入。

时间戳方式

在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。当进行数据抽取时，通过比较上次抽取时间与时间戳字段的值来决定抽取哪些数据。

有的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新时间戳字段。

优点：同触发器方式一样。

缺点：时间戳维护需要由业务系统完成，对业务系统也有很大的倾入性（加入额外的时间戳字段），特别是对不支持时间戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作；另外，无法捕获对时间戳以前数据的delete和update 操作，在数据准确性上受到了一定的限制。

全表删除插入方式

这个就比较好理解了，每次ETL 操作均删除目标表数据，由ETL 全新加载数据。

优点：ETL 加载规则简单，速度快。

缺点：不可以实现数据的递增加载

全表比对的方式

ETL 工具事先为要抽取的表建立一个结构类似的临时表，该临时表记录源表主键以及根据所有字段的数据计算出来，每次进行数据抽取时，对源表和临时表进行的比对，如有不同，进行Update 操作，如目标表没有存在该主键值，表示该记录还没有，即进行Insert 操作。

优点：对已有系统表结构不产生影响，不需要修改业务操作程序，所有抽取规则由ETL完成，管理维护统一，可以实现数据的递增加载，没有风险。

缺点：ETL 比对较复杂，设计较为复杂，速度较慢。与触发器和时间戳方式中的主动通知不同，全表比对方式是被动的进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，全表比对方式的准确性较差。

PS：说了这么多，可能会有朋友问那用什么进行ETL测试啊！答案：手工或ETL测试工具Informatica（后续有机会我们会介绍该工具如何使用，如果有朋友很熟悉了，也欢迎投稿给我们哈，有红包奖励哦！）或Hivetest