晴耕雨读的写意生活

庆祝51Testing软件测试网成立五周年

      
PPent死活不更新，于是去他的博客把文章给抄了过来，呵呵……

【各论坛中测试同行的经典语录摘选】

l        测试用例必须做为一个集合使用才能达到最佳效果，单个测试用例并不能说明用例设计人员的技术水准。即测试用例设计策略最大的价值体现是整体，而不是某个个体。软件测试的手段是尽早发现至今未发现的错误，究其根本还是追求最大利润的体现。软件测试配合开发、QA使软件总体质量达到可接受的范围，取得成本和质量的最大效益就是一个成功的测试。

 

l        测试必须在时间、质量和成本之间获取一个平衡点，这是测试策略和测试设计的价值体现。

l        软件是一个工程，测试用例的设计必须系统而全面。

l        是否能够学到东西不在于公司,而在于你自己.公司只能给你学习的机会,把握机会的是你自己.

l        UI的自动化，听起来很神秘，学起来很简单，真正用起来却很困难

l        UI自动化测试的难点一般是测试对象的获取、测试流程的控制和异常情况的处理。
测试用例是测试工作中最重要的元素或测试件（test ware）之一，是测试执行的基础。测试用例不仅能有效地帮助实施后继的回归测试、知识传递和测试的管理等，而且更重要的是能更快、更有效地发现缺陷，确保测试的系统性和全面性，在测试的深度和广度达到所期望的目标。也就是说，测试用例的质量就是满足测试目标的程度，体现在 “测试覆盖率和测试执行效率”两个方面。

l        测试同仁的心态很重要，质量意识也同样重要：一个不重视质量的人，无论走到那里，都不会成功！

l        测试人员应该具备的职业道德，职业素养，技术基础。技术基础知识虽然是最先具备的、必要的本能的条件，但具备一个什么样的职业道德意识，有什么样的职业素养才是能够决定你在这条路上能走多远，作出多少成绩所必须具备的。

l        就拿项目经理来说应该是个管理职位,但我们中国软件企业的项目经理,大都数做的是技术经理的事情你说的凝聚力和团队建设都是需要的，人的管理就最难的，要把不同经验、不同背景的人放在一个团队中，又要发挥每个人的积极性，保持团队人员稳定，是不容易的。

l        做leader或组长时间久了，经验就有了，没有人天生就会管理，工作经验锻炼人，培养人，所以如果你在一个管理规范的团队中工作，你就能学到管理上的技术，项目做多了，任何项目都应付自如。我很佩服职业经理人，人家就是懂管理，经验丰富。再说，我们就算不会管理，如果项目做好了，团队稳定，那起码也有管理的作用，时间长了，自然就知道如何管理团队了。

l        在公司,下属,客户之间找到利益的平衡 能够平衡的很好的人,就会管理。

l        性能测试要先弄清楚将来部署环境,开发工具,开发架构是什么,最后才弄清楚要测试什么,然后开始测试方法。

l        如何判断一个人的实际操作能力是许多HR们经常问我的问题。其实说起来很简单，只要看他做过什么、做成了什么、怎么做成的。做过什么是判断他的经验，做成什么是判断他的能力，怎么做成的是判断他的思维方式。这些都可以从简历和面谈中以及适当的背景调查中得到印证，而不是听他说将来能干成什么。

l        具备什么样的素质才是合格的软件测试工程师？软件测试的具体工作内容包括：理解用户的需求和体验，校正设计和项目计划，运用良好的测试方法和实践，撰写有效的测试计划，设计有效的测试用例，推动自动化测试，调查分析bug的根本病因，追求卓越的技术和业务能力，充分的团队合作，以及紧密地联系和关注用户和合作伙伴。

 

这几天又去51转了一圈，嘿嘿，居然发现了『大漠飞鹰』大侠的破解LoadRunner9.0的文章，飞鹰大侠的LoadRunner破解系列一直都是51的镇坛之宝啊，于是心里面又发痒了起来。终于昨天晚上忍不住，一边看米兰VS罗马，一边就吭哧吭哧的就跑到Mercury的站点，下载了最新版本的LoadRunner。
下载地址如下：http://esd.mercury.com/akdlm/trial/lr/LR9Download.exe

呵呵，今天上班的时候心里面不住的打鼓，谁叫自己得了个宝呢。终于快到中午的时候忍不住，开始准备安装9.0。OK，从Mercury站点当下来的文件是一个单Exe自解压安装包。安装是不需要任何诀窍的，直接解压缩即可。

注意事项：
1、安装目录和安装文件目录都不要带中文，否则会出现拒绝访问的错误；
2、解压时如果遇到MolizzaFireFox插件拒绝访问的问题，请停止掉系统中的一些软件服务后再尝试，我遇到这个问题时最初是进入到安全模式下进行解压的。但是安装LoadRunner时仍然遇到这个问题，而安装LoadRunner是无法唉安全模式下完成的。所以我停止了McAfee、Oracle、无线网卡等相关软件的服务后，安装成功的。
3、使用破解文件，破解完成。

不过，没觉得比LoadRunner8.1多些什么东西，看来还要多试试才能了解，可怜我的8.1版本，才使用了5个月就被替代……

很早前看过Jacki的理发店模型，有一天在51上回帖的时候就突发奇想，写了饮水机做模型，最近正好有空，于是把这个思路记下来，方便以后调用。

是由这样的一个问题引发的：
事务的最大响应时间和最小响应时间相差很大，那是什么原因？？
其实这个问题问的很简单，但不好回答，因为原因可能太多了。于是我们把问题转化一下：有什么办法可以提高事务的响应时间？

举个饮水机的例子：
屋子里面只有1个饮水机，10个用户同时去倒水，每个人倒水都要用1分钟时间；

那么第一个用户只要1分钟就完成了这个事务，但是第9个用户完成这个事务就需要9分钟。
因为大家都要排队。（这一点很象WebLogic里面的队列）

但是这桶水里面的容量总共只有9杯，倒完之后就要换水。所以第10个人等了20分钟才喝到水，因为他换水的时间比较长。（很象是JVM的垃圾收集）

这个例子里面，10个用户并发，并发同样的事务，分别需要1到20分钟。事务的最大响应时间和最小响应时间相差很大，那是什么原因呢？

可以从以下几个角度出发思考问题，发现原因所在。啥角度呢，就是问一下：有什么办法可以提高我的事务请求的时间呢？

1、增加饮水机；（类似于集群，效率提高是非常明显的）
2、增加饮水机容量；（类似于提高HeapSize了，在WebLogic中，提高HeapSize的另外一个代价就是GC的时间会变长，在GC这个时间段内，任务都是挂起的。废话，在换水的时候当然所有人只能等待了啊）
3、减少每个用户倒水的时间；（比如调整SQL语句，在历次的性能测试过程中，如果硬件条件不变的话，没有比这招更能带来效果的了）
4、减少每个用户请求的水资源；（比如优化业务逻辑，这需要测试人员对代码非常熟悉，目前能做到这点的恐怕还只有开发人员）
5、增加饮水机的出水率；（提高了单位时间内的ThroughOut，那TPS肯定是提高了）
等等；

那么这样子之后就可以回答上面的问题了：
有可能是SQL语句效率不高，有可能是业务逻辑太复杂了，也有可能是有可能是硬件条件实在太差。

当然，假如有人非要让你回答，事务的最大响应时间和最小响应时间相差很大，那是什么原因？这时候可以很大声的说，因为要排队啊。

呵呵，另外发现我们公司的食堂是一个非常有意思的性能测试环境。每天11:20起，每20分钟并发1000多号人去吃饭，共计5拨，另外食堂有10个排队窗口，可容纳1200人同时就餐。

嗯，思路还没整理好，这篇先这样，以后再来看看。

场景要求如下：100个用户，其中10个用户执行A业务逻辑、20个用户执行B业务逻辑、30个用户执行C业务逻辑、40个用户执行D业务逻辑；要求这100个用户的操作是同时并发的。

由于多业务操作，那么首先会想到录制4个脚本＋Group方式去执行这个场景，但是真的能做到吗？
每个单独的脚本中，都能控制同时执行A、或者B；但是怎么样控制ABCD同时执行呢？

所以我的办法是录制1个脚本，脚本中分别包含ABCD四个业务逻辑，分别用TrasactionA、TrasactionB、TrasactionC、TrasactionD表示。
首先确认以上操作是能够完成的，哪怕是录制4个脚本，然后手工将这四个脚本合并。

完成以上操作之后我们就有了这样的1个脚本，在这个脚本中是一个顺序执行的脚本，ABCD，如下：

Action
｛
TransactionA；
TransactionB；
TransactionC；
TransactionD；
｝

然后通过判断VUserID的方式来进行用户的分配，首先在ParameterList中新建一个VUserID类型的参数，定义为NewParam_VUserID；
那么在LoadRunner脚本中可以这样子引用到；

char ParamVUID_Nbr[24];
int ParamVUID_INT;
sprintf(ParamVUID_Nbr,"%s",lr_eval_string("{NewParam_VUserID}"));
lr_save_string(ParamVUID_Nbr,"ParamVUID_Nbr");
通过atoi函数进行字符串和数字之间的转换；
ParamVUID_INT = atoi( lr_eval_string("{ParamVUID_Nbr}"));

然后改写脚本为
Action
{
在这里加入集合点;
if (ParamVUID_INT<=10)
TransactionA；
if (((ParamVUID_INT>10)&&(ParamVUID_INT<=30))
TransactionB；
if (((ParamVUID_INT>30)&&(ParamVUID_INT<=60))
TransactionC；
if (ParamVUID_INT>60)
TransactionD；
}

OK，这下子应该可以顺利实现100个用户的按比例分发，并且让A、B、C、D并发执行了。


超级PS：前几天试验了一下，集合点是可以跨脚本的，所以这个方法基本上是又破又长了，^_^

最近在51上看到的，自己也尝试了一下，觉得挺好使的。

1、打开Loadrunner，进入VUser录制脚本界面；
2、进入Parameter List界面，New一个参数出来，参数名自定义，我在这里定义为sec；
3、Parameter Type选择为Date/Time；
4、Date/Time format选择为%Y-%m-%d %H:%M:%S.000；
5、删除前面的%Y-%m-%d %H:%M:%S，只留下.000；然后在小数点前面再加个0吧；
6、这样子，Format就变成0.000；
7、OK，回到脚本编辑界面，键盘一敲，输入：
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     lr_log_message(lr_eval_string("{sec}"));
     return 0;
8、run一下，看到结果：
     Starting action Action.
     0.698
     0.699
     0.700
     0.701
     0.702
     0.703
     0.705
     0.706
     0.707
     0.709
     Ending action Action.
9、下面就是怎么引用的问题了，^_^

产品线老总突然关注起测试部门的工作来了，他希望我们中有人能够在一个月内了解并熟悉起产品所有的模块，能够对外演示全系统。测试组把任务分析了一下，决定又找出个把人力来突击完成这个任务，结果它又落在了我的肩上～，而这个想法我却并不支持，汗啊。

说实话，这么多年的测试工作，从来还没有一个人能够全系统的熟悉我们的产品，真不知道是不是我们的失败。人员的流失再加上各模块需求变化，能做到熟悉两个模块的已经算不错了。我是唯一一个全专业做过测试的人，所以这个任务落在我的头上倒并不奇怪。

记得去年的时候我曾经建议过测试做精，让每个模块的负责人带领本模块测试工作走向新的高度，让大家能够站到基本相同的水平线上，这时候再开始做交叉测试，出现全才。但可惜，领导并不接受我的建议。

唉，有点失望。

看了IntroScope的演示录像，的确很振奋人心，于是花时间对这个工具进行了一定的研究，下面是Wily IntroScope的初级使用报告。
PS：这个工具在17testing上有下载，也有演示录像可看…

在这次性能测试过程中，有这样的一个场景：
要求数据：
交换局：2W
网元：2W
用户端口：2000W
交接箱：4W
分线盒：160W
主干＋配线线对：5000W

性能测试场景：
每用户地址可开1000门电话，即1个用户地址下挂1000个号码资源；
并发用户数从400起，每5分钟增加10个用户直到满足以下三个条件时退出：
1、总体事务错误率在统计区间内的平均值首次大于1％；
2、服务器CPU负载在统计区间内的平均值首次大于80％；
3、被测系统任一服务器主机发生操作系统重启情况；

根据以上场景，和开发人员讨论、和预测试的经验，初步判断系统可并发用户为500左右，则系统运行时间为1小时左右，每装一门电话系统运行时间为10″钟左右，think_time设定为3*3＝9″钟，迭代次数预估计为180次，也不排除更多的可能性；
则计划需要20W条基础数据，数据建立规则如下：
号码段从99000001到992000000；
用户地址从“XX街道XX小区XX号13B000001”到“XX街道XX小区XX号13B002000”；
每分线盒下挂100个资源，分线盒资源编号从000001到000200；
用户端口、线对编号后六位从000001到200000；

由于参数量比较大，所需要参数化的内容也比较多，所以经过尝试后不打算使用参数文件或者从数据库读取参数的方式；
而是使用VUserID＋IterationNumber生成参数；
参数化的过程如下：
1、在系统参数中为脚本建立ParameteType为VUser ID 和IterationNumber的参数，分别使用％3S【NewParam_VUserID】和％3D【NewParam_ItrationNbr】；
2、将两个参数叠加，形成六位数字，作为基本参数；
3、当迭代数超过200时，VUserID＋500，IterationNumber－200，重新生成六位基本参数；
4、分线盒资源参数、地址资源参数通过基本参数的换算后得到；
所使用到的函数以及方法都是比较常用的，如下：
1、sprintf：合并两个参数，并将其保存为基本参数；
sprintf(ParamVI,"%s%s",lr_eval_string("{NewParam_ItrationNbr}"),lr_eval_string("{ParamVUID_Nbr}"));
2、lr_save_string：保存参数用；
lr_save_string(ParamVI,"ParamVI");
3、atoi：字符转数字；
4、itoa：数字转字符；
5、intlength：判断字符串长度；

当这样做了之后，会发现参数化的过程也变得非常简单，简单的将需要参数化的内容替换成{ParamVI}即可，为调试脚本和数据节约了大量的时间，也为测试结果打下了比较好的基础；

PS：总的来讲过程比较简单，但想法比较有意思，所以Blog出来希望给出指导建议。

其实挺差劲的，工作到现在只接触过OS为HPUX和IBMAIX的机器，那几天听同事谈论几种操作系统的差别，谈到Linux、Solaris和FreeBSD，非常的遗憾，没有真实的接触过。

以上是题外话，我把如何在LR中监控以上服务器性能的办法Blog一下，以后如果碰到其他OS的机器，我想也都可以使用同一办法搞定的吧。

首先需要在被监控机器上打开值守程序，一般默认是不开的。

找到etc目录下inetd.conf文件，用Vi编辑器进行编辑。找到rstatd的那一行，前面有个#号，表示注释掉了，删掉这个#号后保存退出。有些人不习惯Vi的话可以FTP到本地，编辑后上传覆盖。

然后就是使用ps命令将inetd程序重启一下；Ps -ef|grep inetd，找到该inetd的进程号，将其干掉；再度执行一下inetd命令即可，不知道该命令如何执行的话，就直接引用Ps出来的命令行即可。

>ps -ef|grep inetd（显示inetd的进程）
root  254076  188552   0   Apr 24      -  0:00 /usr/sbin/inetd
root 2301994 1642496   0 15:57:18  pts/2  0:00 grep inetd

>kill 254076（杀死进程）

>/usr/sbin/inetd（重启命令，其实就是上面ps命令查询出来的）

>ps -ef|grep inetd（验证一下是否启动）

这样子就可以直接在LR中监控了，选择UnixResource，Add Measurement，输入Unix机器的IP选择监控指标即可。

至于那些指标究竟表示的什么意思，其实很好理解了啊。不过还是不要以如下解释为准，先看一下LR的帮助手册里面的定义，然后再去专业网站上仔细看看吧。
CPU：CPU利用率；
AvLoad：最近一分钟内的系统平均负载；
PageRate：磁盘与内存交换数；