-
LR测试积累[原创]
mmhao_54 发布于 2008-02-29 16:01:33
正在积累中……
一、hits per second/throughput的由来
1、每秒点击率是客户端向服务器发送的请求数，也就是说如果客户端进入了软件系统的界面，那么该界面上的所有图片和控件都会分别作为一次点击数。
2、吞吐量是服务器发送给客户端的数据量，而不包括客户端发送给服务器的请求等。
二、迭代方式
1、 Iteration Number
Iteration Number用当前的迭代数目替换参数。
2、 Random Number
Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
3、 Unique Number
Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。三、迭代中使用关联参数化方法
注：一定要在参数的文本文档中有回车符
1、 建立一个参数A后，欲使另一参数B与之关联，在参数表中的select next row设置为the same line as A
2、 如图设置
图1
四、标准偏差值STD
标准偏差(Std Dev,Standard Deviation) - 统计学名词。
一种量度数据分布的分散程度之标准，用以衡量数据值偏离算术平均值的程度。标准偏差越小，这些值偏离平均值就越少，反之亦然。标准偏差的大小可通过标准偏差与平均值的倍率关系来衡量。
标准偏差公式：S = Sqr(∑(xn-x拨)^2 /(n-1))
公式中∑代表总和，x拨代表x的算术平均值，^2代表二次方，Sqr代表平方根。
例：有一组数字分别是200、50、100、200，求它们的标准偏差。
x拨 = (200+50+100+200)/4 = 550/4 = 137.5
S^2 = [(200-137.5)^2+(50-137.5)^2+(100-137.5)^2+(200-137.5)^2]/(4-1) =[62.5^2+(-87.5)^2+(-37.5)^2+62.5^2]/3 =[3906.25+7656.25+1406.25+3906.25]/3 = 16875/3 = 5625
标准偏差 S = Sqr(5625) = 75该值用于衡量LR的曲线图中所选取的若干点的值之间的偏差大小，如果超过一定标准，则说明软件过于不稳定。
五、SAP/SDP
SAP (Session Announcement Protocol ):：会话通告协议。RFC2974，主要的作用就是告诉接收者，要多播一些什么内容。没有定义描述的格式
SDP：（Session Descrīption Protocol）：会话描述协议。 规定了格式，就是对会话的必要信息如何编码，不过不包括传输机制和协商参数。 SDP语法，采用文字，而不是ASN.1。一个SDP会话描述以会话级信息 和 媒体级信息开始，如果出现一个，另外一个接着后面出现。
六、合并图和关联图
将两个图联系起来，就会看到一个图的数据会对另一个图的数据产生影响。这称为将两
个图关联。例如，您可以将正在运行的 Vuser 图和平均事务响应时间图相关联，来了解
大量的 Vuser 对事务的平均响应时间产生的影响。
1 在图树中单击“正在运行的 Vuser”，查看正在运行的 Vuser 图。
2 右键单击正在运行的 Vuser 图并选择“合并图”。
3 在“选择要合并的图”列表中，选择“平均事务响应时间”。
4 在“选择合并类型”区域中，选择“关联”，然后单击“确定”
七、录制脚本方法
1、Sniffer方法：利用以太网的广播特性。嗅探器。但要求客户机与服务器在同一网段。
2、Proxy方法（代理）：客户端发送到Vugen,再由Vugen发送给服务器。在客户端与服务器之间增加了LR。
八、客户端永远是发送请求，而服务器处理
LR录制的record log里面与工具charles以及实际网页文件的大小都是一致的。
九、录制模式HTTP/URL
Html-based scrīpt(browser/context sensitive)把隶属于一个页面的数据放在一个模块中。
URL(http/analog)真实记录C/S之间全部过程。
2种方式的使用：WEB或B/S结构控件过多的flash等，应使用HTML方式。可以浓缩。可读性好。实质上是一样的。
HTML记录的是web_submit_form
URL是web_submit_data,且支持控件。
十、常见错误
1、录制的脚本为空/录制出错/无法打开首页等：
空：协议选择错误/非B/S操作/打开页面时页面从缓存取出的，也是无法录制下来的/
使用代理/IE使用选项/有恶意代码（检测使用工具：AD-AWARD）/bofu防火墙或防病毒软件
录制出错：出错时使用CODE VIEW，即使出错也能把代码记录下来，而使用TREE VIEW则会停止记录
打开空网页：VUGEN有问题/LR安装路径BIN下Registe_vugen.bat(重新注册一次可能修复)
2、脚本出错
十一、协议选择
LR8中单协议HTTP，在IE中设置一个7777localhost端口，C与B之间都由7777连接，采集所有信息；多协议中单选HTTP协议，指定端口的影射
判断协议工具：PROCESSSPY(正在使用的.DLL分析使用的协议)
十二、关联
是服务器到客户端的数据,函数web_reg_save_param(“param name”,<list of attributes>*,last)
“param name”是参数名，list of attributes分为三部分：“LB=”“RB=”“ORD=”,分别指左边界、右边界和符合条件的第一个，最后一个可以写ORD=ALL，意为全部取出来。而LAST没有，写LB/RB时，写入引号需要转义符。
十三、思考时间
没有：压力会大一些
有：压力会小一些但会比较符合实际等待时间
十四、.net内存分析
1、堆栈——放的是局部变量、方法参数、返回值和其他临时值
2、托管堆——0级、1级、2级，用于分配托管对象的区域，也是垃圾回收器区域
3、非托管堆——用于运行时数据结构、方法表、microsoft中间语言（MSIL）、JITed代码
垃圾回收器只是回收了托管堆的内存，堆栈是自动释放的，非托管堆由非托管堆内代码自动控制，而托管堆也有可能内存泄露
.net常用性能测试指标：
1、Process/Private bytes一个进程所独占的内存是多少，无法跟其他进程共享
2、.net CLR Memory/#Bytes in All Heaps托管堆内总使用内存数
3、.net CLR LocksAnd Threads/# of current logical Threads，在.net运行过程中所使用的线程，注意：线程里面所使用的内存是在堆栈里面分出来的
举例：
a)1不让其增长，2没变，可能是非托管堆性能有问题，因为整个内存增加，而托管堆内存的没有变的
b)3增长，1增长，线程泄露，导致内存泄露
c)
堆栈内存泄露（StackOverflowException）
可能引起堆栈内存泄露的原因：
1、栈资源并且从不返回的方法调用
2、线程泄露
每分配一次堆栈后没有回收回来，就是线程泄露,严重会出现StackOverflowException异常
最新的桌面机与服务器版的WINDOWS堆栈大小为1MB
3、托管堆的内存泄露
大对像的内存碎片——如果在栈中申请有9千个字节，它不会放在堆栈中，而是在堆中。.net不会做压缩处理，不断地申请回收，可能会出现内存碎片问题导致泄露
不必要的根引用
中年危机
使用工具CLEprofiler.exe,不断申请回收大字节进行监控
十五、LR解密
Lr_decrypt,把加密函数进行解密
Action()
{
Char *str=”abc”
Char *str1;
lr_load_dll(“encode1.dll”)// 加载动态连接库,encode1.dll是.dll文件名
str1=(char *)crypt_encrypt(str)//调用接口将字符变量str放到.dll文件中去,crypt_encrypt //Dll文件发布了一个接口
lr_output_message(“encrypted=%s”,str1);
lr_out_message(“%s world”,lr_decrypt(str1); //解密
加密的话需要用外部的加密方法，使用LR自带工具或自己编写.DLL文件。
十六、写入错误的用户名和密码不出错
加检查点
要insert的地方右键addstep/ web_reg_find/增加search test/
文件。
-
如何对业务功能测试（摘）
luoqiwuhui0163 发布于 2008-02-28 18:43:25
如何对业务功能测试
2008-02-22 16:55:02 / 个人分类：测试技术
UI28
业务功能测试
系统初始化状态测试
1． 系统初始化分为两种，初次使用本系统时各界面的初始化和再次使用本系统时各界面的初始化。主要测试各菜单和功能按扭的缺省状态（变灰与激活）是否合理；各种控件的缺省值是否正确。
2．对于母子表的界面，注意母子表是否能同步显示，显示的明细记录是否正确。
UI29
新增：
l 操作逻辑是否合理（包括业务数据输入的先后顺序）。比如应先定位树节点，再按新增按钮；
l 按下新增按钮后，各功能按钮和菜单状态变化是否正确；界面的编辑框是否刷新（注意合理的保留值不应刷新）；光标定位是否合理。
l 能否输入合法的数据；能否正常地调出参照框，并导入所需的数据（包括下拉框，参照对话框，右键菜单等）。能否正常修改或清除数据（需要注意参照框的此项要求）。
l 在没保存所编辑的记录时，进行其他操作，系统是否提示保存新增记录，对话框文本是否正确合理。
l 按保存按钮后，是否进行全面的逻辑校验（与设计文档相符），与正常的业务逻辑保持一致；提示文本是否正确合理，对话框能否正常操作（见非正常用例阶段的通用对话框测试描述）。退出对话框后光标定位是否合理。
l 能否正常保存数据。界面数据显示是否正确。菜单、其它功能按钮及控件状态变化是否合理。
l 能否查询到此记录，查询到的结果是否与输入的一致。
UI30
修改：
l 能否正常修改数据。
l 不应该修改的编辑框是否锁死。
l 在没保存所编辑的记录时，进行其他操作，系统是否提示保存新增记录，对话框文本是否正确合理。
l 按保存按钮后，是否进行全面的逻辑校验（与设计文档相符），与正常的业务逻辑保持一致；提示文本是否正确合理，对话框能否正常操作（见非正常用例阶段的通用对话框测试描述）。退出对话框后光标定位是否合理。
l 能否正常保存修改数据，界面数据显示是否正确。菜单、其它功能按钮及控件状态变化是否合理。
l 能否查询到此记录，查询到的结果是否与输入的一致。
UI31
删除：
l 删除分为记录删除和行删除两种。
l 删除操作逻辑是否合理。如先定位后删除，一次性删除多条等。
l 按删除按钮是否有提示，提示文本是否正确合理。
l 具有业务逻辑时，是否遵循逻辑删除规则，是否有提示，提示文本是否正确。
l 记录是否从界面上清除。是否显示上一条记录，菜单、功能按钮、各种编辑控件状态是否正确。
l 通过查询，验证是否正常删除。
UI32
保存
l 按保存后是否进行所有的业务逻辑校验。是否有提示，提示文本是否正确。
l 保存后，记录是否从界面上清除。是否显示上一条记录，菜单、功能按钮、各种编辑控件状态是否正确。
UI33
查找
l 输入正常的匹配值能否查询到合适的记录。
l 对于较长时间的查询是否有等待提示窗口。
l 注意条件为时间段的查询。
l 如果没有缺省条件，直接按查询按钮是否能查出所有的记录。
l 对于组合查询，应进行互相匹配验证查询。
l 注意通过双击记录带出明细的操作模式。
l 所有条件是否能单独和组合查询，列表框数据刷新是否正确。
UI34
定位
输入合理的值，光标能否定位在适当的位置。
UI35
退出
l 在新增或修改状态直接退出，系统是否提示保存，提示文本是否正确。
l 能否正常退出操作界面。
-
TD7.6中英文对照表
guobin_it 发布于 2007-12-17 12:55:48
TD7.6中英文对照表
Defect
英文
中文
备注
Defect
缺陷
Summary
概要
Detected By
被（谁）发现
Detected on Date
被发现的日期
Severity
严重程度
Assigned To
被分配给
Detected in Version
被发现的版本
Modified
修正
修正Defect的日期
Priority
优先级
Project
项目
Reproducible
可重现
Status
状态
Subject
主题
Descrīption
描述
Submit
提交
Attach
缚上
Thesaurus
辞典
R&D Comments
研发人员备注
Actual Fix Time
实际修改时间
Estimated Fix Time
估计修改时间
Planned Closing Version
计划关闭的版本
Select Filter Condition
选择过滤器条件
Available/Visible Column
可用/可见 列
Attachments
附件
Favorite
喜爱的
Requirement
需求
Estimated DevTime
估计设计和生成测试时间
Execution Status
执行状态
Template
模板
Exec Date
执行日期
Expected
期望结果
Duration
持续时间
Analysis
分析
Details
详细资料
Associated
联合
Current
当前的
-
不要总说“不可能”
luna_jia 发布于 2008-02-18 12:06:02
有一天，客户反馈了一个奇怪的问题：他们的系统上午、下午都是正常的，但是在中午的时候，数据就无法保存，总是提示“保存失败”，我们接到问题的第一个反应通常是：中午的网络或服务器出现故障导致无法保存，但事实上这个答复客户是不满意的，因为做为一个业务操作系统的网络和服务器不会总是在中午出问题，况且只是“保存失败”，查询的功能都可以使用，这说明客户端和数据库的连接是正常的。
这现象有些怪异，客户的数据库异常日志中报出“字段长度被截断”的记录，但究竟是哪个字段只会在中午被截断呢？我们反复在测试环境中模拟，都没有出现类似的现象，有些一筹莫展，以至于都怀疑是客户的电脑神经了。
但是问题一直是存在的，客户中午都不能正常做业务，情绪越来越大，于是我不得不重新配了一套新的测试环境，和客户的真实环境基本相仿。说来也怪，到中午的时候，现象真的出现了，因为是在开发环境中出现的，我们很容易跟踪到了被截断的字段，是一个时间控件。本来，如果使用数据库的日期时间类型，所有的时间字段都不会出错的。但数据库设计者为了查询的方便用了字符型，10位字符，按常理来说足够了，为什么出了长度溢出的错误呢？
后来我想起这个问题出在操作系统上，我们刚开始的测试环境用的是中文版本的Windows2000，中文操作系统默认的时间格式如“10：10：
这个问题出现后，我想起来以前读到过的一个“Impossible=I'm possible!”的小故事，这个故事印象深刻，大意是这样的：有一天美国通用汽车公司的庞帝雅克（Pontiac）部门收到一封客户抱怨信，上面是这样写的：“这是我为了同一件事第二次写信给你，我不会怪你们为什么没有回信给我，因为我也觉得这样别人会认为我疯了，但这的确是一个事实。 “我们家有一个传统的习惯，就是我们每天在吃完晚餐后，都会以冰淇淋来当我们的饭后甜点。由于冰淇淋的口味很多，所以我们家每天在饭后才投票决定要吃哪一种口味，等大家决定后我就开车去买。”“但自从最近我买了一部新的庞帝雅克后，在我去买冰淇淋的这段路程问题就发生了。“你知道吗？每当我买的冰淇淋是香草口味时，我从店里出来车子就发不动。但如果我买的是其他的口味，车子发动就顺得很。我要让你知道，我对这件事情是非常认真的，尽管这个问题听起来很猪头。“为什么这部庞帝雅克当我买了香草冰淇淋它就秀逗，而我不管什么时候买其它口味的冰淇淋，它就一尾活龙？为什么？为什么？”
事实上庞帝雅克的总经理对这封信还真的心存怀疑，但他还是派了一位工程师去查看究竟。当工程师去找这位仁兄时，很惊讶的发现这封信是出之于一位事业成功、乐观、且受了高等教育的人。
工程师安排与这位仁兄的见面时间刚好是在用完晚餐的时间，两人于是一个箭步跃上车，往冰淇淋店开去。那个晚上投票结果是香草口味，当买好香草冰淇淋回到车上后，车子又秀逗了。
这位工程师之后又依约来了三个晚上。
第一晚，巧克力冰淇淋，车子没事。
第二晚，草莓冰淇淋，车子也没事。
第三晚，香草冰淇淋，车子“秀逗”。
这位思考有逻辑的工程师，到目前还是死不相信这位仁兄的车子对香草过敏。因此，他仍然不放弃继续安排相同的行程，希望能够将这个问题解决。工程师开始记下从头到现在所发生的种种详细资料，如时间、车子使用油的种类、车子开出及开回的时间……，根据资料显示他有了一个结论，这位仁兄买香草冰淇淋所花的时间比其它口味的要少。为什么呢？
原因是出在这家冰淇淋店的内部设置的问题。因为，香草冰淇淋是所有冰淇淋口味中最畅销的口味，店家为了让顾客每次都能很快的取拿，将香草口味特别分开陈列在单独的冰柜，并将冰柜放置在店的前端；至于其它口味则放置在距离收银台较远的后端。
现在，工程师所要知道的疑问是，为什么这部车会因为从熄火到重新激活的时间较短时就会秀逗？原因很清楚，绝对不是因为香草冰淇淋的关系，工程师很快地由心中浮现出，答案应该是“蒸气锁”。因为当这位仁兄买其它口味时，由于时间较久，引擎有足够的时间散热，重新发动时就没有太大的问题。但是买香草口味时，由于花的时间较短，引擎太热以至于还无法让“蒸气锁”有足够的散热时间。
即使有些问题看起来真的是疯狂，但有时候它还是真的存在；做为一个测试者，我们每次在看待任何问题都要秉持着宽量的思考并去寻找寻解决的方法，碰到问题时模拟不出现象时不要直接就说那是不可能的，而更应投入一些真诚的努力。而我从遇到那个问题以后，再次遇到在客户反馈回问题而测试环境中无法遇到的现象时，不再以“测试没有发现”为解决的理由，而是会进一步去搭建尽量接近真实操作环境的测试环境或者去客户现场看一看，因此抓住了不少隐蔽的BUG。
