讲课归来
关于重新安装LoadRunner的文档
In case that all the above steps fail, the only recourse left would be to try to uninstall LoadRunner. It is possible that either a previous version of LoadRunner was on the machine before the current installation or that the installation did not go properly although the installation did not give any errors. It is recommended that a full uninstall be done in this case. The following steps are for a full uninstall:
HTTP协议基础知识
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行,一个或者多个头域,一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头,请求头,响应头和实体头四个部分。每个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。
下面简要介绍一下HTTP协议的请求头和应答头,这将有助于你进一步了解某些测试工具录制脚本的原理,便于编辑性能测试脚本。请求头和应答头都将用实例来说明。 查看全文
WebLogic 的Load Balance的工作原理
CLUSTER概要
一、 Cluster的概念及优势
Weblogic支持集群技术,即让一组Server指向同一域名一起工作从而提供一个更强大、更可靠的应用平台。对于客户端而言,无论Cluster中有几个Server在工作,看上去都是一个。集群技术有两个最明显的特色:
(1)可伸缩性:Cluster对加入其中的Server在性能上没有限制,为了提高性能,当客户端的请求大幅增加时,可以动态地向Cluster中添加Server。并且,配置Cluster当一台机器的资源没有被完全利用时,可以在同一机器上启动多个Server,但要求每一个Server使用不同的IP,而不能用同一IP的不同端口。
(2)高可用性:由于在Cluster中同一service在多个Server上同时存放或放在一个共享文件系统中,因此相同的请求可以有多个Server提供,并且Server间还可以复制状态信息。这样,当其中某一Server宕机或无法响应请求时,其它的Server会立即接管它的任务,从而把应用和客户端完全隔离开来。
查看全文
破解图片验证码限制的一般思路(摘录于月光博克)
验证码分为如下几类:数字型、字符型、符号型、综合型。
一般验证码属于数字型的,不过有的图片中生成了不少彩色和黑白的噪音点(指验证图片上的斑点)。那么我们应该怎么去识别呢?传统的验证码识别方式很简单,由于数字的位置是固定的,所以我们只需要提取每一幅数字的图片(没有噪音点的)然后把每一个特殊数字独有的象素位置记录下来,然后在网络上提取需要破解的特征码,祛除噪音点,对其位置和记录位置进行比对,那就是么就能确定相应的数字了。
总结一下传统的就是:
1.先分析验证码,前景颜色是否不定
2.然后把验证码的宽度/验证码文字个数,比如一验证码下载后宽度为60,有4个数字,那么就60/4=15,然后保存每个字,如果只有数字保存0-9数字到位图文件,如果英文那更麻烦点,0-9,A-Z都要保存到位图,位图的前景色都不变,保持一种颜色,背景随便你改不改
3.如果前景要变则将文字统一为同种颜色,每个数字0-9的点阵都有个公共点,取该公共点颜色然后把前景全部统一成一种颜色,比如白色{255,255,255},位图的结构是BGR,而不是RGB
4.然后进行比较,如果验证码的一点为白色,第2步保存的位图同一点也是白色,那么频率增加1
5.最后频率最高的就是验证码了!
接下来要做的就是做个post程序了,这个太简单了,代码你就自己写吧!不过也要做到如下细节:做成多线程程序进行发贴,不然程序会失去响应的。最好是可以导入大量的代理IP的,然后就是发贴的内容最后加上几个随机字符,这样可以防止重复贴的过滤!最重要的,只是做测试,发贴量不要太多、不要乱发广告贴!
其实上述方法已经不是只是对验证码进行识别了,完全可以用到现实生活中去,比如说手写体识别、车牌识别等等,但是现实生活中我们还要进行更多的加工,比如说圆形检测,多边形检测等等。所以说从网络安全技术中,也有很多东西能造福社会,还等待我们继续创造!
浅谈V模型和W模型
V模型:
V模型是最具有代表意义的测试模型 。
V模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系 。
从左到右,描述了基本的开发过程和测试行为,非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系 。
箭头代表了时间方向,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。
W模型:
V模型存在一定的局限性,它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段,主要是针对程序进行测试寻找错误,而需求分析阶段的隐藏的问题一直到后期的验收测试才被发现。
在V模型中增加软件各开发阶段应同步进行的测试,被演化为一种W模型。
开发是“V”,测试也是与此相重叠的“V”。
W模型体现了“尽早地和不断地进行软件测试”的原则
相比于V模型,W模型更科学。W模型可以说是前者自然而然的发展,它强调:测试伴随着整个软件开发周期,而且测试的对象不仅仅是程序,需求、功能和设计同样要测试。
测试与开发是同步进行的,从而有利于尽早地发现问题。以需求为例,需求分析一完成,我们就可以对需求进行测试,而不是等到最后才进行针对需求的验收测试。
测试不仅仅是评定软件的质量,测试还可以尽可能早地找出缺陷所在,从而帮助改进项目内部的质量。
vmstat 参数详解
r-->在运行队列中等待的进程数
b-->在等待io的进程数
w-->可以进入运行队列但被替换的进程
memoy
swap-->现时可用的交换内存(k表示)
free-->空闲的内存(k表示)
pages
re--》回收的页面
mf--》非严重错误的页面
pi--》进入页面数(k表示)
po--》出页面数(k表示)
fr--》空余的页面数(k表示)
de--》提前读入的页面中的未命中数
sr--》通过时钟算法扫描的页面
disk 显示每秒的磁盘操作。 s表示scsi盘,0表示盘号
fault 显示每秒的中断数
in--》设备中断
sy--》系统中断
cy--》cpu交换
cpu 表示cpu的使用状态
cs--》用户进程使用的时间
sy--》系统进程使用的时间
id--》cpu空闲的时间
我的第一个QTP脚本
我以Mercury Tours作为我的第一个QTP脚本试验,主要想完成如下功能:
1。动态的将本地的参数文件读入到QTP的DataTable
2.判断参数文件中哪个用户是正确的,正确将进入下个页面,否则循环所有参数,直到退出
3。随机的订一张飞机票
4。随机的删除一张票
技术要点:
1。如何动态的创建DataTable Sheet
2.如何将文件内容读入到QTP中
3。如何在不同的ACtion传递参数
4。如何判断函数返回值
5。如何动态创建一个对象(因为在删除票号时,脚本中没有这个对象的)
6。如何判断一个子对象是否存在
尚未完成的功能:如何从TD中自动将文件取到本地,作为参数文件
http://blog.itpub.net/resource/7412/8214
关于google的webservice测试脚本
最近和一个朋友聊起google wevservice测试的问题,我做了一个小的google webservice脚本,大家有兴趣的可以看看!
LR版本必须在8.0FP1或以上
下载文件后必须把自己的CD_KEY加到CD_KEY,dat文件中,并修改.wsdl的文件路径,然后就可以运行了!
http://blog.itpub.net/resource/7412/8037
让你的IP地址,1秒钟变化一次!
经过试用发现,自己的ip是1秒钟变化一次,哈哈,用显示ip的网站测试,我一会在英国,一会儿在加拿大,真是好用啊!!
安装注意:安装后不要急于测试,先关闭所有的浏览器,然后重新打开。如果还没有效果,那么重新启动,保证见效。
注册码:123-114-115-107-054
Steganos Internet Anonym Pro 6
下載地址:http://www.steganos.com/software/siapro6int.exe
关于怎么在LR中模拟下载的动作!并能真实地保存文件
当B/S程序在进行下载动作时,弹出对话框这个动作是client的行为,所以LR无法录制下来!我在这个程序里模拟这个动作!并保存下载文件的内容!
我这个脚本写的比较简单!大家可以在上面扩充!比如生成动态的文件名等等!
这个脚本是拿我上载到51testing上的一个脚本为例子的!
大家下载下来修改一下cookie里面的内容就可以执行了!
http://blog.itpub.net/resource/7412/7900
警惕某些服务器厂商在 TPCC 性能指标上搞猫腻 (来自与http://blog.joycode.com/moslem)
先说我了解的一个真实案例:某单位要建立一个系统,设计容量是 2008 年要达到 1500 万客户的规模,在花费巨资(将近 100 M $)建设起此系统后,运行只有几个月,客户量也只达到几十万,厂商就说此系统容量不够,要花数 M $ 要扩容,并声称不是拍脑袋是,按 TPCC 计算的结果 ...
以前只大致了解 TPCC 指标的一些情况,平常也就看看 By Performace 和 By Price/Performace 的 Top 10 列表,了解一下各厂商的实力和产品的情况,这次对 TPCC 进行了一下深入了解,发现了一些容易被厂商搞猫腻的地方。
TPCC 简单的来说,就是事务处理性能委员会 TPC 组织针对联机数据库应用系统(OLTP)制定的一个综合性能考评指标,它模拟了一个批发 商的货物管理环境,有标准的数据库结构(Schema),可以很容易的扩展,在此系统中,主要有五类交易:
1. 新订单(New-Order)
2. 支付(Payment ) 43%(最小比例)
3. 订单查询(Order-Status) 4%(最小比例)
4. 交付(Delivery) 4%(最小比例)
5. 库存查询(Stock-Level) 4%(最小比例)
因为 TPCC 指标值主要是衡量“新订单”交易的数量,所以厂商都会趋向于增加新订单交易的数量,这样并不满足实际的应用场景,所以 TPCC 的规范中指定了后四种交易数量的最小比例,这样意味着 “新订单” 的数量最多只能占到45%(这个 45% 不知出于什么原因,在很多 TPCC 的指标介绍中并没有提及)。
这就说明了:如果一台机器有 1000 tpm (Transactions per Minute),那么它实际上处理的交易(请求)为 1000/45% = 2222 ,而实际上大多数厂商在面对用户估算应用系统需要多少个 TPCC 的服务器的时候,是计算所有交易量的,这样带来的评估结果是用户至少买比实际需要大一倍性能容量的机器,获得利益的谁呢?当然是服务器厂商,越高 TPCC 值的机器,价格越高,性价比也一般要偏小。
此外,服务器厂商还容易在以下方面愚弄客户:
1、交易复杂度(用户的一个交易约等于多少个 TPCC 的标准交易),某国际著名的服务器厂商建议此值取 10 - 20 ,这个值也忒大了点, 在 TPCC 的场景,交易也不是很简单的,和实际的应用交易差别并不是很大。
2、按一些峰值指标来计算性能,实际上,这些峰值只是在极少数情况下出现,所以在计算时,应乘以 80% 的系数。
3、预留容量,很多厂商建议预留容量,甚至达到一半,这有点过份,在实际容量要求增高的时候,可以通过服务器的横向扩展来纵向扩展来满足应用要求,何必为未来五年的要求,要在眼下一下子要做全部的硬件投资呢? 何况硬件的价格在不断下降呢。
现在回头来看刚开始的案例,除了说他们愚弄客户,贪得无厌之外,还有什么可说的呢?
BTW:在了解 TPCC 的同时,我整理了一个 TPCC 介绍的 ppt ,其中包含了一个自己总结的估算应用系统所需 TPCC 的公式,这里无法增加附件,有意者可以留言索取(2005.12.31 前)。