发布新日志

  • loadrunner-ip欺骗经验总结

    本来就很乖 发布于 2011-04-22 15:04:15

     

    1、本地的IP不能设置为“自动获取”,必须指定一个静态IP;
    原因:如果设置为“自动获取”,在运行IP Wizard时会弹出错误提示;
       提示信息为:IP向导不支持启用DHCP的网卡。您的卡启用了DHCP或者配置了无效设置。请与系统管

    理员联系。

    2、添加IP欺骗使用的IP后,会有提示框提示保存IP列表,确定,取消等按钮;建议保存IP列表后再确定

    完成;
    原因:保存IP列表后,下次使用时,可以直接导入IP列表;也可以直接修改保存的IP列表文件,再导入;

    3、添加IP欺骗,和释放IP,都要重启机器后才会生效;
    原因:重启后,网络配置才会生效;

    4、在controller中使用ip欺骗的注意事项;
    (1)勾选“场景”->“启用IP欺骗器”;
    (2)勾选“工具”->“专家模式”;
    (3)“场景”->“选项”->“常规”->“多个IP地址模式”;
    这个选项一定要与当前场景的模式相匹配,也就是说使用本地虚拟IP测试时需要选中线程方式,使用负载

    生成器使用虚拟IP测试时需要选中进程方式

    5、设置IP欺骗后,验证其是否生效;
    有两种方法查看:
    (1)可用如下代码段来查看:
    char *ip = lr_get_vuser_ip();
    if (ip)
         lr_output_message("The IP address is %s", ip);
    else
         lr_output_message("IP spoofing disabled");
    注意:如果把上面这一段加入代码中间,第一句要修改下:

    char *ip;(这句放在函数起始部位,对变量ip进行声明)
    ip=lr_get_vuser_ip();(这个和后面的if-else语句一起放在要输出的地方)

    另:这个在generator中是不生效的,所以在回放代码时看到的都是"IP spoofing disabled",在

    contorller中设置了启用IP欺骗,日志中就可以看到;

    (2)controller的运行页,运行完场景后,在通过、失败的虚拟用户处,右键可显示VUser日志;
    弹出的提示框头几行就有显示当前使用的IP;

    6、使用IP欺骗过程中,会有出现下述问题:
    启用IP欺骗后,运行1个虚拟用户的场景都失败;不启用IP欺骗后,运行场景通过;
    原因:查看失败的虚拟用户,使用的IP地址(查看方法可使用第5点中的方法),在服务器端通过ping等命

    令查看网络是否互通;
    如果服务器ping不通虚拟IP,说明网络设置有问题,检查网络设置;

  • loadrunner中并发数与迭代的区别

    Alice_花 发布于 2012-08-18 18:21:38

    网友问题:
    例如在LR里,我要测100个用户同时并发登陆所用时间,那我是不是在录制脚本后,需要参数化“用户名”,“密码”以及在那个记事本里构造100个真实的用户名和密码? 然后运行Controller,设置用户数为100?那么这里的迭代次数该怎么设啊,设成1和设成10有什么区别啊?我老是搞不清测试并发用户,“迭代”和“并发用户数”(就是controller里设的虚拟用户数)的区别。
     
     
    ZEE的回答:
    用比喻的方式来回一下:

    四车道的马路,如果只有四辆车并排走过就是并发;
                     如果四辆车排成一纵队走过就是迭代;
                     如果有100辆车排成25行依次走过就是并发加迭代。
    在以上说法中,只有并排的车是我们设置的用户数。
     
     
    以下内容是转载的,只做记录一下:
     
    通过用lr做负载压力测试过程发现,如果设定不同的action迭代次数,每次得出的结果是不同的,曲线的表现形式也是不同的。这点就使我们会感觉困惑,为什么要设置action的迭代次数?以及对于不同的应用系统应该怎样设置迭代次数呢?

    首先你要理解性能测试是在干什么?

    性能测试是模拟系统一段时间内真实的压力情况,以考察系统的性能。

    再看怎么模拟系统真实的压力情况?比如在半个小时内,用户都在进行登录操作,且平均分布在这半个小时内。我们要做的是什么?模拟这半个小时用户的行为。怎么模拟?估算出同时操作的人数,并用LoadRunner不断的发送登录请求,这就是我们为什么要迭代。

    至于迭代次数,只要能够模拟出真实情况,多少次都无所谓,不过10次8次估计是模拟不出来。迭代次数至少要保证压力达到一个稳定值后再运行一段时间,这样我们得到的数据才是有效的。所以我们除非是特别要求,一般不用迭代次数,而是用运行时间。

    1,迭代和并发,是完全不同的概念。没有什么关系。

    比如,一个用户迭代十次,还是一个用户的压力。

    10个用户执行一次,就是10个用户的压力。10个用户迭代10次,还是10个用户的压力。但他们都和参数化的数据有关系(也要看参数化是如何设置的,以及系统如何判断提交值的)。

    2,你要是想知道,LR是如何实现迭代和并发:

    说一个比较容易理解的层面:迭代就是不停的反复调用同一脚本,反复执行,注意,对1个用户执行10次来说,只会分配一块内存。10个用户执行一次,是调用同一脚本10次,会分配10块内存。LR调用脚本,编译后,运行,按脚本发送数据。

    比如:web_url这样的函数,执行就会发HTTP request。

    如果你还想知道更细节的进程和函数的实现,只能侧面验证(具体方法看各人的能力和擅长),因为我们都不是LR的开发者。

    3,太显然的问题了,参数化时选择每次出现唯一,只要参数够用就OK,不够用,就设置相应的规则。

    action在场景运行中iteration只对其起作用,对vuser_init和vuser_end都不起作用,action是一个可以被重复使用的最小单位其实你可以将所有脚本录制到一个action里,只是不方便管理罢了。

    举个最简单的例子,像lr自带的例子——订票系统,你如果把所有脚本都录制到一个action里,那回放的时候,每个用户登录就只能买一张票,而如果想一个用户买多张票的话,这样就行不通了。那你就要设多个action,并把登录和结束各录制在一个action里,把买票录到一个action中,这样,将买票的action迭代多次,而用户登录和结束只运行一次,这不就模拟了现实中的情况了吗?

    其实LoadRunner 是以客户端的角度来定义“响应时间”的,当客户端请求发出去后, LoadRunner 就开始计算响应时间,一直到它收到服务器端的响应。这个时候问题就产生了:如果此时的服务器端的排队队列已满,服务器资源正处于忙碌的状态,那么该请求会驻留在服务器的线程中,换句话说,这个新产生的请求并不会对服务器端产生真正的负载,但很遗憾的是,该请求的计时器已经启动了,因此我们很容易就可以预见到,这个请求的响应时间会变得很长,甚至可能长到使得该请求由于超时而失败。等到测试结束后,我们查看一下结果,就会发现这样一个很不幸的现象:事务平均响应时间很长,最小响应时间与最大响应时间的差距很大,而这个时候的平均响应时间,其实也就失去了它应有的意义。也就是说,由于客户端发送的请求太快而导致影响了实际的测量结果,设置步长则可以缓解这一情况,这样,应该试试设置pacing,再运行看看情况。

  • (转)谈测试工程师的职业“晋升”之路

    saiqi5092 发布于 2015-07-08 13:41:18

     在一般人眼里,“晋升”就意味着加官进爵,步入管理层了。其实对于一般的工程师而言,晋升至少包含三个层面的含义:升值、升级、升职---“三升”。

       谈到三升,有些人容易联想到医学里的“三高”-高血糖、高血脂、高血压。“三高”人群是个很危险的人群,很容易因为疾病恶化引发健康问题;即使只有一高,对健康的潜在影响也是不容忽视的。和“三高”相反,“三升”对工程师而言却是极其有益的,只要能注意使用正确的工作方法、主观上稍加努力,实现“一升”还是比较容易的。如果谁能实现“三升”,对他而言这是非常值得荣耀的事,这意味着他在职业上取得了耀目的成绩。
     
       那我们就看看,作为测试人如何取得“晋升”,迈向成功的职业人生?
     
       开始阅读下面内容之前先建议你做下这问卷,看看现在的你“升”到哪个阶段了?
     
       一、升值。
       升值的含义就是使自己的个人价值得以提升,以至于能够更好地服务社会,提升收入。升值就意味着自己“值钱了”,别人对自己越来越重视了,奖金也越来越多了。对于一般的上班族而言,升值是相对比较容易的,只要能在自己的岗位上认真、敬业地履行自己的职责,虚心向周围人学习,很快就会使自己的价值得到提升了。作为测试工程师,要使自己能够“升值”,必须要能全力投入工作,执行好测试用例,尽快熟悉被测试对象的行业知识,同时处理好和同事上级的关系。另外,自己不仅要钻研业务知识,还要多学习一些软技能方面的知识,比如沟通技巧、演讲技巧、情绪和压力的控制、时间的管理等。
     
       二、升级。
       升级的含义就是自己的工作级别得到了提升,不但工作熟练水平达到了一定高度,对本岗位的宏观认识也有了相当提升,甚至可以带领一个小团队完成某个项目。“升级”对于测试人而言是个重要的里程碑,意味着自己职业生涯得到了升华,自己的价值得到了广泛认可,并且能够利用自己的工作圈去影响身边的人。要能实现升级,作为个人必须要作更多的努力,不仅仅只是熬年头、攒资历,摆老资格、耍老油条的年代已经过去了,能力才是得到别人认可的“硬通货”。所以,作为有了一定工作经历的人,时刻要注意为自己充电,抓住一切培训机会,公司不能提供的自己也要创造。比如,英语技能要过关,在和外籍员工一起工作时要能顺利交流;沟通技能要强,说话要有逻辑,有条理,能够有效说服他人;业务知识要精要广,数据库操作系统、网络、SDH,SONET,PACKET这些业务知识要能精通一二,还能兼通其他,都能说出个子丑寅卯。
     
       三、升职
       这是很多人梦寐以求的美事,这意味着从此华丽转身步入了管理岗位。管理岗是个复杂的岗位,虽然再也不需要去跑用例、写用例,但对于整个大团队,知能善用、平衡人际、激励团队、实施项目样样都不能少,弄得不好就是顾此失彼、按下葫芦浮起瓢,整个部门一盘散沙、人员流动频繁。所以,要想升职,除了要做好平时的工作以外,还要多注意人际关系的培养,特别是跟高层的交流、沟通,同时要主动寻找公司有关管理方面的培训资源;如果没有足够资源,还可以主动向一些培训机构寻求培训服务,往往会有意想不到的收获。
     
       打个不太恰当的比喻,职场就如爬楼梯比赛,有人爬到3楼就直喘气,而有人一口气爬到6楼还镇静自如。其中的差别就是爬到六楼的人通过锻炼和控制饮食保持了好的体质;而只能怕到3楼的人,除了身体疾病外,恐怕跟平时贪睡、少动、贪食、拖沓有着更为直接的关系。所以要想有所成就,必须现在就行动起来.
  • 14年职场感悟:看看资深软件测试工程师怎样炼成的?

    Alan_Wu 发布于 2013-12-09 14:37:55

    说来这是件让人笑话的事,工作十余年,用了整整6年光阴才找到自己的职业方向:测试。用一句话概括这6年就是“没头的苍蝇四处乱撞”,没目标的日子就是可怕:害怕没工作、没房子、没老婆、没未来。

      我毕业于一所重点大学,但毕竟是个师范大学,又不是响当当的计算机、电子专业,再说学习成绩也只中等,所以求职之路并那么顺利,并不像一般人那样直接去电信、移动、外资企业。倒是快毕业时签了一家大型国有家电企业,但去上了半年班后还是失望离开了。

      进军上海。

      那时候IT业还是方兴未艾,所以找工作似乎也没那么难,只是找个响当当名牌企业不那么容易。于是去应聘做硬件开发,熬了一年多被老板踢出门了。事实上从来也没设计出一个PCB板子出来,在里面也就是跟着软件开发的调一调路由器。一个月2千多块混日子。

      日子还得过,后来没办法又去了一家美资小公司做技术支持,就那么几台交换机,干了2年多又去了一家外地驻上海办事处,总共就5个人。一年后倒闭了,再次失业。

      转眼间6年过去了,老婆无着落,房子没希望。生活黯淡无光。

      投简历、失望,投简历、再失望........终于有一天,一家小有名气的设备制造商给了我一个offer,给了我一个测试职位,也开始了8年之长的测试自旅,期间虽然换过公司,但在通信设备上的测试经验和职业素养,已经今非昔比。8年,对于很多从事测试的朋友来讲这是个非常长的时间,对于那些信奉“测试就是吃青春饭”的人来讲这是很不可思议的件事情。现在虽然已近不惑之年,但对测试工作的投入依然不减当年,在通信行业的知识积累也相当深厚。

      这里谈谈从事测试职业的一些感受(以通信行业系统测试为例):

      一、测试行业并非是“青春饭”。只要你愿意,你可以干到40岁,甚至50岁。因为,测试职业,特别是系统测试需要宽泛的行业知识和丰富的测试经验。而这些都是需要在工作中不停磨练和积累的。

      二、测试工作需要强调协作和配合。测试工作不像开发,本身并不能生产产品,只能为产品把质量关,所以测试工作需要和多部门配合典型的有开发部,系统部。开发部里面还会有硬件开发部,软件开发部;软件开发部还有负责系统的,驱动的,应用软件的,网管的。所以必须要了解产品的系统结构,才能和这些职能部门很好配合;

      三、测试工作和开发工作一样重要,少了一样产品都不能发布出去,否则无异于自杀。但是测试工作一般是在开发完成交付的基础上进行的。在日常工作中,测试人员要排除自卑思想,敢于向开发表明观点,指出错误。当然知识足够才能底气足,所以平时要注意知识的学习。

      四、要注意沟通技能培养。和他人陈述观点时,要有条理性,逻辑性,既要尊重别人又要敢于提出异议。和各个部门和角色的沟通方法也不尽一样,平时要多注意学习和练习;

      五、测试工作需要不断学习和积累。因为测试既需要丰富测试知识,又需要宽泛、系统的专业知识,而不需要像开发那样只需要精通于某一小块(事实上资深的开发人员知识面也很广),所以平时要注意学习和提升。可以学习的对象有公司文档(系统设计、说明书等)、专业书籍,实际设备。同时,也需要多向开发人员学习,多探讨问题。

      六、要注意职业生涯的规划。这恐怕是很多人关注的,但也是比较棘手的事,有个明确的职业规划可以少走很多弯路,不像我起初那样几乎就是混日子。个人认为测试工程师如果收入较好的话可以继续深入发展,成为资深、高级测试工程师。如果对测试有厌倦感,喜欢一些新鲜尝试的话可以去市场、销售,甚至是一些测试无关的岗位做些尝试,不要把自己限制得太死。职业的测试培训师也是一个好的方向,如果你善于演讲,富有耐心,这也是不错的选择。今后的出路完全靠自己把握,但前提是对自己的能力和个性要有了解,同时有个合适的职业规划。

      .............

    版权声明:本文出自 Carl_Lew 的51Testing软件测试博客:http://www.51testing.com/?182680

    原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。 
  • 关于测试人员的职业发展

    cocayang 发布于 2015-09-17 14:32:43

    近期由于项目组人手不够,需要招聘一些测试人员。本周及上周陆陆续续面试了十多个应征者,工作年限在2年~9年之间,但无一满意。期间,种种感叹,回想起去年面试六十余人仅有3人满足要求,如有鲠在喉,还是吐槽一下。如有不对请大家也狂喷我。

    我的要求高么?

    我的要求其实是:有还算不错的沟通能力,熟悉常见软件开发流程,有一定的需求分析、用例设计能力,会基本的linux和sql操作能力。有一些代码能力会加分。这是长期与现实妥协的结果。如果人还算机灵,其实我很愿意花时间来培养他们。

    面试结果

    令人惋惜的是,一个合适的人真的很难找。更令人惋惜的是,我看到好多入行很多年的同行,能力并没有跟随工作年限一同增长,有些做了五六年的人有时候给人感觉竟然还不如一个入行一两年的年轻人。最令人遗憾的是,大部分同学竟然没有一个明确的职业发展思路,即使有,也没有经过深入一些的思考,而是人云亦云。

    面试的一些细节:  

    因为从事的工作是业务密集型的,有的业务逻辑非常复杂,我们特意准备了一份不错的需求(考虑到应试者没有行业背景,给出了详尽的专业说明和例子),并根据这份需求出了几道用例设计的题。只有不到四分之一的应试者给出了让人相对满意的答案。我们内部评估这份需求的时候,认为只要有过一两年的用例设计经验,应该能答的不错。

    我一般会根据简历问一些问题,看看简历的真实性。也会问一些基础的测试知识,查看应试者的专业素质。

    常见的问题:

    说说你常用的测试方法? 百分之九十的人只能答出等价类和边界值。只有少数人可以讲出其它测试用例设计方法,但深入问,从没有一个人能有令人满意的回答.

    给一个非常简单的小例子,例如登陆操作,让应试者回答如何使用等价类方法设计用例。但让人吃惊的是仍然只有不到五分之一能够给出比较满意的答案。

    陈述一个缺陷的生命周期(你们是怎么管理bug的?)有一多半人能够说出常见流程,但深入问一些问题:如缺陷如何同版本、测试轮次等结合起来,一些特殊情况如何处理等,很多人就懵了,而这些基本上都是工作中常用的。

    你做的最长的一个项目是什么?在这期间你遇到了什么问题让你最头疼?你如何解决它?十个人里大约只有一人能给出还算不错的答案(能够识别出问题,提出它带来 的不利影响是什么,并能够给出一定的解决方案就算是不错的答案了)。

    你感兴趣的测试工作是什么,你想在哪方面有所发展?十个人里有4个会说是自动化测试,3个会说性能测试,2个会说是管理,一个会说是白盒测试。并希望提供相应培训。只有极少数人能够说出具体的思路和技术项。

    如果继续追问:你说的是性能测试吧?你有过这方面的学习么?一半会说看过一些网站上的技术文章,一半会说看过loadrunner的书。如果继续追问,是哪本书?是哪类文章?有哪些具体的知识点能讲一下么?90%答不上来。

    问:你有看过哪一本测试书籍?哪些技术博客?哪些网站?50%的人会说看过QTP的书(QTP的真正使用率已经快赶上诺基亚的使用率了,国内主流自动化的书竟然还是这个!),并且没有真正在工作中使用过,然后就没有别的了。有少一半人最近几年一本技术书籍也没有看过。

    如果有管理经验的应试者,我会问一些测试过程管理相关的问题,如给一个最简单的题:如果测试时间不够如何?十个人中只会有两三个提到排定优先级和测试裁剪,大部分人的回答竟然是加班也一定要搞完。

    我想说的:

     1.为了你的前途,请多明确一些个人能力思路吧。你五年后,十年后是个什么样子?有没有一个明确的想法?有没有你五年后想达到的某个人的程度?如果这些思路不清楚,请多看看外面的世界,看看一些测试做得非常好的人是如何工作的,他们掌握了什么能力?学习他们,追赶他们并尝试超越他们。最好认识他们,可以侃侃大山,志同道合抱团前进很好。另外目标别定太抽象,一定要是可以分解,可以检查的。

    2.多读一些测试书籍,测试的书并不是只有QTP!看看微软测试专家史亮推荐的书单,这些都是不错的好书:http://www.cnblogs.com/liangshi/archive/2011/03/07/1973525.html 有些书能够帮助你把测试知识框架搭建起来,比照一下你还缺点啥?

    3.多读一些其它书籍,不限于技术书籍。如果想读的书有利于工作,推荐一些如何做思辨思维的书。《思考的艺术》《六顶思考帽》《你的灯亮着么》 《学会提问》是我喜欢的4本书。它们会教你怎么独立思考,养成提问的习惯,而提问的习惯是我们现在的测试人员最缺乏的一件事情。人们往往拿了被测物就开始忙着写用例,忙着测试。而不是先探索它、研究它。当然IT技术也要掌握,如果你的IT技能能够赶上开发,你发现你做测试的思路会非常的宽广:)

    4.把书籍中的东西跟你的工作对比,把好的东西引入工作(这点是检验书本质量的好方法,也是促进你思考,促进你能力提高的好方法。

    5.关注大牛们的技术博客。国内写好测试博客的人不是很多(很多人其实很有水平,但是不喜欢写blog),但是国外有很多,有人整理了一个list也推荐给大家:http://ssnlove2008.blog.163.com/blog/static/3788942020093284842381/。

    6.搞定你所在行业的领域知识:如常见IT技术,常见业务知识,这些知识掌握的越深,你的价值越高。测试技术是内功,但是你能直接为企业带来价值的最大之处是你对被测物熟悉程度,也就是你的领域知识!!!

    7.没有方向?从你的工作入手,比如,你遇到的最大的难题是什么?我怎么解决它?我需要掌握什么样的技术解决他?我要推动什么样的组织改变来解决它?别人怎么解决它?有没有更好的方法?使用后我改进了那些?google一下别人有没有同样的问题?尝试作对比,如果觉得他做得好,尝试联系那个人讨论一下。看看对方的进展。尝试把活儿干得特别漂亮。你能解决10个中等问题以后,你的能力会有大幅度提高。

    8.尝试做笔记。最好是在线的,推荐印象笔记和有道云笔记。

    9.坚持。

    10.保证身体健康,岁月会给你带来别人的信任感(当然能力要随着岁数增长)。

    能做到这里面的一半,两年后你就能在专业上有高分通过我的面试:)当然肯定你也不见得会看得上我们的offer了。

    11.对于没想好就跳槽,换行业的同学说:你再想想!你的很大价值是与你企业、行业绑定的。如:做了5年保险业务,你的领域知识至少值5w每年,换领域就没了。你在一家公司证明了你自己,到新公司要重新证明你一遍,有的时候外部环境、机遇等会让证明过程很痛苦,成本很高。

    另外的吐槽:

    野蛮生长没有经过系统训练的同学非常多。这其实有很多因素,分析起来觉得有以下几点:

    1.大学或者职业教育没有非常好的课程体系(有些培训机构还行,但是也需要提高),其实测试技能需要系统训练和长时间磨练才能有根本的增长,我们的职业教育或者再教育体系其实还是有很大空白的。

    2.说句实话,大家的读书氛围不够浓厚。大家不喜欢看书。而读书是再教育成本最低,又非常有效的途径。相比于程序员,测试同学喜欢读技术书籍的比率明显的低,这是一个让人悲伤的事实。真希望这种现象能够改变。

    3.很多人是不喜欢coding才转测试,或者是因为IT产业普遍薪水高才来做测试。不是真正热爱这份工作,不热爱其实做不好,因为兴趣是最好的老师。

    4.很多人认为测试门槛低,young talent 不愿意干,测试吸引人才有点儿困难(我初入行的时候也有这种想法,也是当时被强拉来做测试的,当时想做的是coding和数据DBA相关工作并已经有了一些积累,(我没说我是啥人才啊))。说实话测试的入门门槛的确有一点点低,但是做好测试的门槛确是相当的高,随着系统越来越复杂,测试逐渐会比开发还难做,更有挑战性,我这么说你信么?

    5.专业化社区还没有形成规模,测试人员没有能有效交流的平台。这是跟美国和欧洲的一个挺大的差距。他们的社区做得挺好的,我们也有了一些很好的起步。如一些热衷测试公益的同学,一些不错的会议,一些不错的线下活动,但还需要大大的发扬光大。

    真心希望测试行业的整体水平能够逐渐提高起来。

  • 软件性能测试10大误区

    蛊魅 发布于 2015-07-06 17:52:11

    曾经我们帮助客户进行软件性能测试的时候,客户不解的问,不是必须通过功能测试后才可以测试性能吗?可能有很多人会存在这样的疑问,在这里,我们的多位专家根据多年经验总结出性能测试的10大误区,希望能给大家带来帮助。

    误区1:应用程序必须通过功能测试后才可以测试性能。

    应该尽早的进行性能测试。性能测试可以发生在各个测试阶段中,即使是在单元层,一个单独模块的性能也可以使用白盒测试来进行评估,然而,只有当整个系统的所有成分都集成到一起后,才能检查一个系统的真正性能。

    性能测试从早开始,完成一个小模块,对小模块的接口进行性能测试,一般耗费资源很少,但可以防止问题在项目最后出现,花费很大的精力去修改。

    而有些资料中提到的:在系统代码开发和功能测试完成之后,进行性能测试的说法,是为了检查系统整体性能的做法。一般经常出现在验收性能测试中。

    误区2:软件性能测试要向功能测试一样,覆盖到所有功能。

    性 能测试的主要目的是为了系统调优。不可能对所有的系统功能都进行性能测试。在测试设计时需要结合当时的实际系统,先分析软件可能存在的瓶颈,此时可依据 80/20原则分析:对系统资源的利用、数据大量传输、数据转换、用户使用频率、逻辑复杂度等进行分析,选择要执行的功能和场景,再依次制定性能测试的方 案。

    误区3:系统吞吐率随着并发量增加而增加。

    随着并发量的增加吞吐率并不是线性增长 的。并发量从小逐渐增大,开始阶段吞吐率随着并发量的增加线性变化;当并发量达到某一值时,系统处理能力趋于饱和(也可能某一硬件条件达到临界值),此时 再逐渐增大并发,会有一些请求处于等待状态,所以响应时间变慢,吞吐率趋于稳定;当并发量达到系统的最大处理能力后,再增加并发,系统处理能力会下降,吞 吐率也会下降,最终可能发生宕机。

    误区4:客户给出性能指标,我们一定要想法设法达到。

    根 据用户提供的指标进行可行性分析,分析这些指标在理想状态下是否可以达到。比如有这么一个要求:有一台服务器,希望能承载10000个用户每秒 200kb的传输。从CPU、Disk、网卡等方面分析都是很难达到的,也是很难测试的。需要和客户商讨增加硬件配置或者通过其他途径来解决。

    误区5:压力测试、负载测试、容量测试等这些不同类型的测试一个一个分开来执行。

    现实场景是复杂的,测试也需要尽可能的模拟负载的场景。在一个整体的系统性能测试场景中,应该包括各个类型的测试。而需要检查某一个方面的指标或分析某个性能问题时,尽量保证场景简单、单一、容易模拟。

    误区6:做性能测试主要就是性能测试工具的使用。

    我做不好性能测试,是因为对测试工具不熟悉;测试工具可以自动生成我所需要的报表;依靠性能测试工具就能准确定位系统瓶颈;

    测试工具在测试中只能起到辅助性作用。而测试方案、测试场景的分析、问题的定位这才是性能测试的关键。不要期望测试工具能够生成你想要的东西(报表、瓶颈分析),工具只是尽可能多的提供我们分析的依据。

    误区7:在线用户数就是并发用户数。并发用户数高意味着PV(页面浏览量)大。

    并发用户数*用户访问页面数=PV

    误区8:提高一下硬件配置就可以提高性能了,因此性能测试不重要。

    随 着软件规模的扩大,提高硬件配置只是解决性能问题的一个基本手段。因为如果软件自身存在性能问题,再多的资源可能也不够用,例如:内存泄露问题,随着时间 的增加,内存终究会被耗尽,最后导致系统崩溃;数据库连接等配置信息、数据库死锁是和硬件很难挂钩的;算法逻辑问题导致程序缓慢。即使要提高配置,也要首 先用性能测试的方式得出哪些硬件可能存在瓶颈。

    误区9:性能测试独立于功能测试

    一方面,整体性能测试的场景设计要求的系统功能非常熟悉;另一方面,功能测试可以发现性能问题,性能测试也能发现功能问题。很多性能问题时由于软件自身功能缺陷引起的。如果应用系统功能不完善或者代码运行效率低下,通常会带来一些性能问题。功能测试可能会发现这些问题。

    误区10:随便找个环境下进行一下性能测试就可以了。

    做性能问题分析可以在类生产环境上进行,配置可以有些差别,但是,整体性性能测试、验收性性能测试要尽量在用户生产环境下进行。

  • 存储性能中,iops和带宽的理解(转)

    yixuan6007 发布于 2015-09-06 08:35:23

    说起存储产品的评价,性能永远是第一重要的问题。关于性能的各种指标实在五花八门:带宽(Bandwidth)、IOPS、顺序(Sequential)读写、随机(Random)读写、持续吞吐(Sustained Throughput)、突发处理能力(Burst I/O)等等看似甚为专业的名词充斥着解决方案和技术分析报告。

    1、带宽与I/O性能(俗称iops)
        这是两个衡量存储设备性能最基本的概念,明确的区分两者也是对存储产品性能了解的第一步。如 果我们把存储设备比做一间会议室,被存取的数据就是前来参加会议或从会议中离开的人,那么带宽性能就是指这间会议室大门的宽度,大门越宽,可以同时进出的 人也就越多,而I/O性能是指房门开合的频繁程度,迎来一批前来参加会议的人,就需要打开一次大门,送走一批人也是一样,哪怕这“一批人”其实只是一个 人。由此可见,当我们考察会议室的门设计得是否合理时,必须结合会议本身的性质。
      
        对纪律严明的会议来说,与会者轻易不会凌乱的进出会场,人们在会议开始时统一进入,结束时再统一离开。对这种情况,门的宽度就十分重要,而是否易于开合则 显得不那么关键,反正这扇门在整个会议中只需要开合两次而已。相反的,对于联欢性质的聚会而言,门设计得太宽除了显得气派之外,并没有什么实际的意义,但 是门开合的频率却很重要,因为会有客人频繁的进进出出。
      
        对应到存储设备上,道理也是一样。大文件持续传输型的应用需要的是充分的带宽性能,而小文件随即读写的应用则要求足够的I/O能力那么多 大的文件算“大文件”呢?一般而言,超过1MB大小的文件就可以算做“大文件”了。如果您的应用系统处理的资料中,最小的文件也有4~5MB甚至几十 MB,就需要重点考察存储系统的带宽性能了。如果您的应用是数据&库形式,或是电子邮件系统,系统中有大量KB级大小的文件,那么就可以忽略掉产品介绍中 xxx MB/s的字样,重点关心xxx IOPS就可以了。
      
        2、影响性能的因素
      
        当然,仅看产品彩页中的简单数字还是远远不够的。存储设备的标称指数只是其最最理想情况下的表现,而实际应用中,存储设备表现出的处理能力往往与其标称指数相去甚远。为了反映更多的细节,会议室的比喻不足以说明问题。所以我们前面的例子再改进一下,把存储设备看作一栋有很多房间的大厦。人们从门口进入大厦,先来到大堂,经过走廊,最后到达房间。人们进大厦的方式也分为两种:一种是所有人按房间号码顺序排好队,一起进入大厦,我们称之为“顺序进入”;另一种是他们无规律的自由进入,我们称为“随即进入”。
      
        显而易见,“顺序进入”的效率要大大高于“随即进入”。这就说明,一般情况下,顺序读写的性能要远高于随即读写的性能。还有一个结论也不难得出,一个宽敞 的大堂更有利于偶然性较大的“随机进入”,而对“顺序进入”的人群而言,经过大堂基本属于浪费时间。存储设备中的“大堂”就是高速缓存。
    也就是说,大容量高速缓存可以提高随机读写性能,而对顺序读写的性能改进则不明显。
      
        还记得前面讨论的带宽和I/O的差别吗?带宽考察的是单位时间进入大厦的人数,而I/O关心的是单位时间进出大厦的批次。从次可见,如果走廊没有任何变 化,那么大堂只要不是太小,就不会影响带宽性能。相对的,对I/O性能而言,大堂显然是越大越好。总之,影响带宽的因素主要是前端控制器(大门)和后端磁 盘通道(走廊)的带宽;而影响I/O的因素主要是控制器(大门)处理能力和高速缓存(大堂)容量。
      
        当然,前面的讨论都基于一个假设前提:磁盘(房间)足够多。如若只配置寥寥几个磁盘,它们就会成为整个系统的性能瓶颈。任凭其他配置如何奢华,也于事无补。那么,“足够多”又是多少呢?对光纤通道存储设备来说,每个光纤通道上的磁盘数量达到50~60个的时候性能达到最佳。所以一般中高端存储设备都把每 通道50~60个磁盘设计为扩展极限,而不是光纤通道技术规定的126个。

    IOPS和带宽对存储性能指标的影响【转】
     
    图1. 磁盘数量影响光纤环路性能

    这样设计存储产品,可以让系统的性能随着容量的增加而增长。但是同时,用户必须明白,在容量没有配置到最大值的时候,性能就无法达到厂商所宣称的指标。一 些厂商还声明其产品的性能可以随着容量的增长而线性增长,按这样讲,当你的存储设备只配置了最大容量的一半时,你得到的性能也只有系统最佳性能的一半。
      
        3、性能曲线
      
        这里所说的“最佳性能”就是厂商所宣称的指数吗?很遗憾,答案是不一定,一般都不是,而且可能会相差很远!我已经听到有人在叫“天啊!那厂商公布的数字到底有什么意义啊。”别急,看到下面两个图示就清楚了。

    IOPS和带宽对存储性能指标的影响【转】
    图2. IOPS性能曲线示例

     

    IOPS和带宽对存储性能指标的影响【转】
    图3. 带宽性能示例

    这两个图示是典型的存储设备性能实测曲线,所有曲线来自同一个存储设备的同一个配置。不同产品在纵向指标上表现各异,但曲线的形状都大体相同。从图上可以 看出,用户环境中存储设备的性能表现严重依赖数据块的大小。以顺序读取操作为例,如果应用产生的数据块大小在8KB左右,那么带宽性能和I/O性能最多也 只能达到峰值性能的一半左右。如果希望得到更好的I/O性能,就需要尽量将数据块调整得更小。但不幸的是,如果希望带宽性能更好,就需要想办法把数据块设置得更大。看来,带宽与I/O性能是鱼与熊掌,难以兼得啦。

    不过没关系,如我们前面提到的,幸好大多数用户其实只需要其中一种性能。要么是大文件类型的应用,需要带宽性能;抑或是小文件类型应用,需要I/O能力。 需要带宽的用户相对容易得到满足。从图3可以看出,只要数据块大于128KB,顺序读的性能就基本可以达到系统饱和值。对顺序写,饱和数据块略大一些,但 256KB也不算难以达到的尺寸。

    得到最佳的I/O性能似乎就没那么容易了。从图2的曲线来看,I/O性能并没有一个饱和状态,这就要求数据块无穷尽的尽量小。然而所有应用都不可能支持无 穷小的数据块。实际上,大多数的数据¥库应用产生的数据块都在2KB或4KB左右。在这个尺度上,应用得到的性能距离最高性能还有至少20~30%的空间。
      
        4、持续和突发
      
        回到我们那个关于大厦的例子。如果大厦临时发生紧急情况,比如火灾,人们争先恐后的蜂拥在门口,景象一定是一片混乱。在实际应用中,存储系统也可能遭遇类 似的情况,一时间大量数据同时被访问,造成系统严重堵塞。这就像存储系统内的交通高峰,往往需要类似交通管制的手段才能提高系统效率。一些厂商会宣称他们 的产品在这种情况下的“交通管制”能力有多强,以致可以从容应付大规模的突发访问。诸如“全交换结构”、“直接矩阵结构”等技术均属此类。究其本质,这些 “交通管制”都是在大堂(高速缓存)的设计上做文 章,将原本一个公共大堂的结构变成若干独立大堂的结构。以此来避免火灾发生时,所有人都拥挤到一个大堂 里。
      
        这样设计的确可在访问突然爆发时缓解系统压力,但是需要注意,这样设计的大厦内部一定布满了各种指示牌和路标,对任何一个进入大厦的人而言,进入房间的过程都将变得更复杂。其结果就是,非突发状态下,系统的持续读写能力往往还不如同等计算能力的简单结构存储。
      
        5、其他影响
      
        除了前面所谈到诸多方面外,还有很多因素都会影响到存储设备在实际运行中的性能。例如RAID级别的设置、磁盘类型甚至型号批次的匹配、缓存的镜像、 SCSI指令队列深度的设置,这些方面都与性 能结果直接相关。而且,为了能够得到最好的性能指数,几乎所有的厂商在测&试自己产品性能的时候都会采用无冗余 的RAID0、选用15k rpm的高速磁盘、将写缓存镜像保护关闭或者干脆关闭写缓存、将指令队列深度设置为最大。如此配置方式相信不是每个用户都可以接受的。
      
        另外,所有存储设备在运行快照或远程镜像等附加功能之后,性能都会明显下降,有些情况甚至会下降60%之多。如果用户的应用恰巧需要这些附加功能,就需要在选用存储设备之前认真的实地测量一下真实性能。免得满怀希望的买回家,使用起来却失望至极。
      
        结论和建议
      
        想要知道梨子的滋味,最好的办法就是亲自尝一尝。对存储设备,这个道理尤其重要。只有在用户需要的配置方式下,在实际的应用系统中,实实在在的运行之后,用户才能真正清楚的感知存储设备的真实性能表现。纸上谈兵只怕会使用户在各种数据中迷失方向,难以做出正确结论。

  • 技术学习-TCP/IP

    Haven_w_j 发布于 2014-04-02 13:37:17

    了解到今后的项目是 接入网类的,涉及到网络,TCP/IP协议应该是基础了,想这几天对该协议有所学习和了解。
    第一天,TCP/IP基本概念
    1、为什么要存在TCP/IP?
       为了让计算机互相合作,需要联网;为了让运用不同语言的计算机合作,需要TCP/IP。
    2、关于TCP/IP,需要了解哪些专业术语?
       互联网地址(IP地址)
       IP地址是网络号+主机号的组合。 目前IPv4的标准,我们通常使用B类地址。
       域名系统
       是一个分布的数据库,它提供将主机名(网址)转换为IP地址的服务。
       RFC
       RFC就是TCP/IP的标准文档。我们需要学习其中的十几条协议即可。
       端口号(port)
       是用在TCP/UDP上的一个逻辑号码,不是真实的硬件端口。比如说将某个端口封掉,其实只是在IP层过滤掉了它的IP包。
       应用编程接口
       常用的编程接口 socket TLI 等
    3、TCP/IP协议分层是怎样的?
       应用层 里面有http,ftp,等等我们熟悉的协议
       传输层 著名的TCP和UDP协议就在这个层次
       网络层 IP协议就在这里,它负责对数据加上IP地址和其他的数据(后面会讲到)以确定传输的目标
       数据链路层 这个层次为待传送的数据加入一个以太网协议头,并进行CRC编码,为最后的数据传输做准备
       硬件层 负责网络的传输,这个层次的定义包括网线的制式,网卡的定义等等(这些我们就不用关心了,我们也不做网卡),所以有些书并不把这个层次放在tcp/ip协议族里面,因为它几乎和tcp/ip协议的编写者没有任何的关系
       发送协议的主机从上自下将数据按照协议封装,而接收数据的主机则按照协议从得到的数据包解开,最后拿到需要的数据。这种结构非常有栈的味道,所以某些文章也把tcp/ip协议族称为tcp/ip协议栈。
     
  • 接口测试方法

    agatha1113 发布于 2013-06-05 17:08:48

    其实无论用那种测试方法,接口测试的原理是通过测试程序模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端,客户端接收应答报文这一个过程。

      方法一、用LoadRunner实现接口测试

      大家都知道LoadRunner是一种性能测试工具,但它也可以用在我们做接口测试的时候。开发人员开发出来的接口,提供给测试人员详细的接口使用说明书,该说明书最基本的要求如下:

      接口测试地址:/SNS/Publish

      请求报文参数说明:

    参数名称

    参数描述

    字符类型

    字符值

    SNSID

    社区ID

    String

    6

    UserID

    用户ID

    String

    10

    CommentsTypeID

    评论类型ID

    String

    2

    CommentsID

    评论ID

    String

    10

    AuthorID

    作者ID

    String

    10

    CommentsContent

    评论内容

    String

    50

      请求报文格式:

    <?xml version="1.0" encoding="ISO-8859-1"?>
    < Publish >
      <SNSID>123</SNSID>
      <UserID>456</ UserID >
      <CommentsTypeID>2</ CommentsTypeID >
      <CommentsID>123</CommentsID>
      <AuthorID>456</AuthorID>
      <CommentsContent>Don't forget the meeting!</CommentsContent >
    </Publish>

      应答报文的参数接口说明:

    参数名称

    参数描述

    字符类型

    字符值

    UserID

    用户ID

    String

    10

    CommentsTypeID

    评论类型ID

    String

    2

    CommentsID

    评论ID

    String

    10

    CommentsContent

    评论内容

    String

    50

    StatusCode

    返回值

    Int

    0代表pass,0代表fail

    StatusText

    返回信息描述

    String

     

    <?xml version="1.0" encoding="ISO-8859-1"?>
    < Publish >
      <UserID>456</ UserID >
      <CommentsTypeID>2</ CommentsTypeID >
      <CommentsID>123</CommentsID>
      <CommentsContent>Don't forget the meeting!</CommentsContent >
      <StatusCode>0</StatusCode>
      <StatusText>发送成功一条评论</StatusText>
    </Publish>

      有了上述的说明书之后,测试人员可以根据文档的描述在LoadRunner书写相应的接口测试脚本。

     LoadRunner中涉及到向服务器发送请求的API方法包括:web_url(),web_submit_form(),web_submit_data(),web_custom_request()。下面介绍两种我常用的方法:

      方法一:使用web_submit_data()

    web_submit_data("insert",
          "Action=http://116.211.23.123/SNS/Publish.htm ",
          "Method=POST",      
    "Referer=http://116.211.23.123/SNS/Publish.htm ",
           "Mode=HTML",
          ITEMDATA,
          "Name= SNSID ","Value=6601",ENDITEM,
          "Name= UserID ","Value=123",ENDITEM,
          "Name= CommentsTypeID ","Value=1",ENDITEM,
          "Name= CommentsID ","Value=456",ENDITEM,
           "Name= AuthorID","Value=789",ENDITEM,
           "Name= CommentsContent ","Value=Just for testing",ENDITEM,
                   LAST);

      方法二:使用web_custom_request()

    char str[1000];
    strcpy(str,"SNSID=7999&UserID=1&CommentsTypeID=1&CommentsID=1&AuthorID=1&CommentsContent=1");
    web_custom_request("Publish",
                      "Url= http://116.211.23.123/SNS/Publish.htm",
                      "Method=POST",
                      "Referer=http://116.211.23.123/SNS/Publish.htm ",
                      "Mode=HTTP",
                      str,
                      LAST);

      这也是一种写法,可以跟web_submit_data互换。这种写法更利于拼接参数。

      方法一适合一些xml结构的根元素下的子元素同处于根元素下面,且子元素数目较少的情况下,如果xml结构比较复杂,比如说根元素下面有多级子元素,或者xml树结构分叉较多的时候,我们可以先把xml拼接成一个字符串然后通过web_custom_request()向服务器发送请求。

      我们在做接口功能测试的时候会很注意接口的应答报文的信息,这时候我们可以通过LoadRunner的日志信息查看或者可以通过web_reg_find()或者web_find()这样的API函数来统计接口的运行结果,推荐使用web_reg_find(),web_reg_find()和web_find()区别请大家百度一下,详细信息太多,在这里不便叙述。

      因为web_reg_find()是注册型函数,所以应该放在web_submit_data()或者web_custom_request()的前面。

      如:

    web_reg_find("Text=<StatusCode>0</StatusCode>",//应答报文里边的信息
    "SaveCount= StatusCodeCount", //统计查询字段的信息,如果找到值为1,如果未找到值为0
    LAST);

      在脚本的最后我们可以对查询字段的信息进行统计

    // Check result
    if (atoi(lr_eval_string("{StatusCodeCount }")) > 0){ //判断如果Welcome字符串出现次//数大于0
    lr_output_message("Send out the comment successfully."); }//在日志中输出Send out //the comment successfully
     
    else{ //如果出现次数小于等于
     
    lr_error_message("Send out the comment unsuccessfully."); //在日志中输出Send out //the comment successfully
    return(0);
    }

      总结:用LoadRunner做接口测试无法做到把接口参数和程序分理,接口的参数可以通过参数化的方法来实现对同一个参数多个数据的测试。参数化后的测试数据保存在此脚本的保存位置下。

      方法二、通过Java + Fitnesse实现接口功能测试

      什么是Fitnesse?

      FitNesse是一套软件开发协作工具 FitNesse是帮助大家加强软件开发过程中的协作的工具。能够让客户、测试人员和开发人员了解软件要做成什么样,帮助建议软件最终是否达到了设计初衷。

      FitNesse是一套软件测试工具 从另外一个角度看,FitNesse是一个轻量级的、开源的框架,能够帮助开发团队方便的定义验收测试(Acceptance Tests),通过在web页面上简单的输出和预计输出的表格就可实现,并且可以运行这些测试以确定是否通过。

      FitNesse是wiki可以很方便的创建和编辑页面 FitNesse是一个web服务器不用过多的安装配置,很方便使用。

      我习惯使用Eclipse集成开发工具写测试代码,用fitnesse准备接口的测试数据,由此实现接口的测试数据和测试程序的分离。

      关于Fitnesse的使用大家可以参考官方网址。Fitnesse的四种常见表格是:

      ColumnFixture,ActionFixture,Decision Table,ScriptTable。在工作中ColumnFixture用的最多。

      下面的程序使用的是ColumnFixture表格。

    // Java fixtures
    package info.fitnesse.fixturegallery;
    import fit.ColumnFixture;
    public class PublishTest extends ColumnFixture {
      
      //通过url向服务器发送请求的程序段省略
       public StringSNSID; //对应列名|first part|
       public StringUserID; //对应列名|second part|
       private StringCommentsTypeID;
       private StringAuthorID;
    private StringCommentsContent;
    private StringUserID;
     
    //对参数的set和get方法省略
    }
     
    ColumnFixture表格里边的测试数据是:
    //省略设置表格的存储位置信息

      总结:上述两种方法都是对接口做功能测试的方法,使用LoadRunner做接口测试的时候可以不用让开发人员提供测试人员相应的UI测试页面,直接调用接口做测试,但是测试程序和数据的依赖性太强;使用Fitnesse做接口测试的时候可以实现测试程序和数据的分离,只用点击Fitnesse界面的Test按钮就可以实现测试,测试消耗时间比使用LoadRunner做接口测试少。

      以上纯属个人见解,敬请拍砖!

  • 接口测试方法

    jasonzhao058 发布于 2010-11-18 21:38:29

    对于接口测试,首先测试人员要懂代码,你只需要知道接口的作用是什么就可以了(有文档更好,但大部分都没有);其次,自己去读开发的代码;然后,根据该接口功能及代码写测试用例;
    用例设计:
    1:写一个程序去调用该接口,看是否能够达到该接口所定义的功能
    2:根据该接口参数,构造不同的用例,测试接口在参数合法及非法情况下能否达到预期效果
    3:根据该接口中的逻辑,设计不同条件的用例,测试该接口实现代码的逻辑
    4:进行容错及健壮性测试
    5:静态检测代码,看是否有内存泄露、或永远走不到的分支、代码规范及逻辑是否合理。
    6:对于一些接口,需要进行多线程测试
  • LR 接口测试(Windows socket方式)

    BBnight 发布于 2012-04-28 09:40:49

    1.在 data.ws 中定义发送报文(报文内容、报文长度)、接收报文长度
      ;WSRData 2 1

      //发送报文
      send  buf1 100
       "00479000<psam>;422006402831111151043130290701;<telno>0000"
      //接收报文
      recv buf2 100
     
      -1
     
    2.创建socket连接,并发送、接收报文
      lrs_startup(257);
      //设置socket连接创建超时时间
      lrs_set_accept_timeout(20,20000);
      //创建一条PC和接口服务的socket连接
      lrs_create_socket("socket0", "TCP", "LocalHost=12405", "Backlog=5",  LrsLastArg);
      lrs_accept_connection("socket0", "socket1");

      lrs_send("socket1", "buf1", LrsLastArg);
      lrs_receive("socket1", "buf2", LrsLastArg);
     
    3.接口测试中常用的函数
      char *recvbuf1;
      int recvlen1=0;
     
      lrs_create_socket("socket0", "TCP", "LocalHost=12405", "Backlog=5",  LrsLastArg);
      lrs_accept_connection("socket0", "socket1");

      lrs_send("socket1", "buf1", LrsLastArg);
      lrs_receive("socket1", "buf2", LrsLastArg);
     
      lrs_get_last_received_buffer("socket1",&recvbuf1,&recvlen1);
     
      if (recvlen1 == 100)
      {
         lr_output_message("正确接收报文");
      }
     
  • 2013双十一和双十二总结

    zhenshan2013 发布于 2013-12-29 11:17:38Top 3

       入职无线已经2年多了,很感激,感恩给过我机会的领导,同事,朋友,2年多,3次双十一,前两次因各种原因,没现场参与,今年全面参与,体会到了激动,澎湃,奇迹的时刻,在我的职业生涯中刻骨铭心.
      双十一过后,作为产品的测试人员,我更加愿意从职业的角度来看本身工作的不足和后续改进的地方,下面我从如下几个方面来说说
      一:主客测试
      双十一可以说是对平时产品,开发,测试工作的检验,此次项目参与人员多,有些方面平时工作中没有考虑到,正好趁这个机会,总结测试主客户端需要考虑的范围:
     淘宝主客=外部插件(服务)+ UI前端 +业务 +技术(h5,native)
      1.功能,主要包括业务,无线业务并不复杂,但是android客户端碎片太多,同一功能不同系统版本出现问题,低端版本2.X之类问题多,高版本Nexus硬件加速问题也多;dalvik模式和art模块支持;
      2.安全,后台系统问题多,如:xss之类,活动接口被拦截刷,redirct重定向没过滤,没白名单外挂可以hook,主客本身的bug很难发现,主要是接口方面,平时安全测试主要从:接口,源代码阅读,log,代理方面进行,从细节方面着手,业务安全,分享链接是否可点击,有没有信息泄漏.
      3.性能,图片大小,此次代码集成到主客户端,出现http多次请求,CDN上图片没压缩(q90,q70),以及图片尺寸过大,搜索list图片尺寸80*80合适,以及集成外部插件,插件内部app图片出现类似问题.
      4.埋点,BI埋点,主要是运营方面跟踪数据,由埋点引起crash的也不少,这块数据测试需要关注,而且BI埋点要提前准备,如果是活动,红包之类的审批就更加需要提前,否则到上线时间点,测试压力和项目风险大。
    5.系统之间关联,看请求来区分哪个关联系统引起的问题(第三方工具识别链接来分析是什么原因引起的.)
    6.电量,流量,其中对主客的电量,流量测试都需要跟竞品做对比测试,主要是定场景.目前的策略是:
        1030版本5个场景(home键静默,退出,)1128前
        1128版本中
        1128后与1128前对比:(后续写一篇个人总结的流量,电量测试的文章).
    7.主客用到的传感器,帧FPS(动画),测试如下:adb shell dumpsys batteryinfo,adb shell dumpsysgfxinfo;有些功能没用到传感器,GPS,但是业务场景中打开了,需要关闭,否则耗费电量.
    8.主客启动的时候,初始化是否有多次请求,以及集成的SDK初始化是否有多次请求,
    9.客户端扫描,h5活动banner是否唤起客户端,浏览器打开是否进入下载页面,跳转,cookie之类以及h5和sdk
    10.不同版本的os,硬件设置不同,客户端的加载功能回归等
    11.sdk方面:此次双11版本,SDK表现稳定,但是双12发布版本合并前期,安全黑匣子SDK升级以及分享SDK代码被修改都导致了灰度版本重新打包,引起业务层面相关人员的无奈,因为SDK是底层的基础性产品,相关升级
    涉及到的业务方太多,这个需要评估影响,又长经验了.
       测试工具:PowerTutor耗电量,wireshare流量,网卡代理监控请求,以及IOS测试工具套件.
         总结: 细心,考虑全面,实践技术手段
    二: 大项目管理方式(双十一1030版本,双十二项目1128版本)
       双十一以及这次的双十二,主客户端需要集成的项目大大小小有20几个,投入的测试人员和开发也几百号人,最终产生的缺陷7000多个,对于此类项目是怎样开展才能达到目标的了,个人总结如下:
        1.目标明确,上线时间明确,行动统一;
        2.把握几个点,如:提测前,提测后(环境,bug提交,每日情况跟进),上线前,上线后回归,演练安排.提测前,从需求一开始就有总体测试负责人跟进,例如excel跟进格式:项目名字 测试人员 状态 备注这段时间请PD讲解需求;提测后,每日进度,风险,质量情况跟进,bug日清,主要解决比如资源,协调等问题.
        3.上线前几天(根据具体情况),bug优先级更换(p1,p2不能发版本),座一起统一回归;
        4.上线后一份总的报告,包括:缺陷趋势,测试类型(安全,性能等)
       总结:大项目化成小项目,统一,风险跟进
    三: 小项目管理方式(专享价,可信设备)
      和兄弟测试团队合作的项目,我曾经对共建项目做过类似的总结,其实,业务方面来说,无线端的根基在
    PC端,但是PC端对客户端项目不了解,因此链路太长,出问题的地方又多,个人认为从如下几点开展
    就可以确保项目成功:
         1. 指定一个测试PM,抓需求变更,抓bug,进度,每日测试报告,胆大心细;
         2. 共赢态度,分工明确,必须TC评审,覆盖全面;
         3. 项目组或者测试内部每天一次进度,风险评估会;
         4. 客户端测试需要评估风险,如果PC对后期客户端不了解,无线风险需要客户端测试把控;
         5. 该走的流程必须走,如:设备借用,测试内部验收流程
         6. 上线之前开一次评估会
      以上几点对任何业务类型的项目都适用,具体情况具体分析.
    总结:态度,团队原则
    四: SDK项目
       SDK测试工作除了兼顾内部的功能点测试,还需要包括:集成到主客测试,集成文档.基础服务方可以按照android sdk发布,开源的方式来发布.
       总结: SDK测试,发布需要兼顾Android不同版本.
    五: 双十一后职业感触
       眼界决定一个人的选择,从毕业到现在,一路不平坦,没有抓到重点,这几年一直在很努力,也大大小小实现了一些目标,但是还是没达到想要的高度,深度,造成这种困境的根本原因:没有遵从自己的内心,视眼太小,工作性质.现在想来,我失去了很多改变命运的机会,以前的很多努力都在工作中没找到落脚点,说真的,测试领域需要坚持的东西很多,找准一个点,做深入,然后在扩展,虽然已经30了,一直有创业的冲动,好想好想做点自己的事,所以我对测试新人或者刚毕业同学的建议是:一定要做好职业规划,不忘初心,拼命努力,创造价值,成就别人,要做就要做别人做不到的事情.





     


  • 华为boss力荐公司高层看的一篇文章,很长很经典

    张亚洲 发布于 2013-12-03 18:37:24


           今天是 22 岁的最后一天。几个月前,我从沃顿商学院毕业,用文凭上“最高荣誉毕业”的标签安抚了已经年过半百的老妈,然后转头辞去了毕业后的第一份工作,跟一家很受 尊敬的公司、还有 150 万的年薪道了别,回到了上海,加入了“刚毕业就失业”俱乐部,开始了一天三顿盒饭的新生活,中间许多精彩剧情暂时略过。  我肯定不是第一个做过这样事的 人,也肯定不会是最后一个。所以在说自己的一些有趣故事前,我想借用大家(包括 30 岁甚至 40 岁以上的朋友)的一点时间和一点平和的心态,和大家分享过去一年以来一直没说的一些话。所以前两部说的是对于一些一直困扰着我们的关键词的理解和体会。他 们是:欲望、外界、标签、天才、时间、经历、人生目标、后悔、和现实。
    这可能会是一篇科普文,也可能会是一篇长篇小说,但我不想这篇文章变成一篇励志文,大家都审美疲劳了。所以我想忽略阳春白雪,尽管信息量很大,但是至少说 一些实实在在的经验和故事,说一些效果立竿见影的观点,再说说活捉林志玲什么的,总之让大家多看一点就多获得一点实际的价值。

     第一部:那些最容易被理解错误的事

      关于欲望 
    这些是我们内心里和人生理想一样真实的东西:学历、工作、房、车、财富、以及爱。我们每个人都愿意为了这些欲望去付出,无论付出的是汗水、鲜血、还是身体 健康、又或是其它你懂的。尽管我们付出的方式可能不被社会主流认同、可能没那么具有有戏剧性,但你和我、北大图书馆里的学生和网吧中奋斗的少年、职场杜拉 拉和夜场里跳舞的小姐、韩寒和芙蓉凤姐(韩少躺着也中枪-_-),我们谁没有为了一个目标连续熬夜奋斗过呢?我们谁没有为了得到一样东西而撕心裂肺地付出 过呢?谁没有过那种拼命得快受不了的感觉呢?所以我们最不缺励志的故事,因为我们每个人都是付出领域的专家。
    真正的问题是,当我们跑得越快,越是无法考虑我们是否在朝着正确的方向奔跑。
    北野武讲过一个很有趣的故事。他说他没出名之前想有一天有了钱,一定要开跑车,吃高档餐厅,跟女人们睡觉。而真正功成名就的时候,他发现开保时捷的感觉并 没有那么好,因为“看不到自己开保时捷的样子”。结果他就让朋友开,自己打个出租车,在后面跟着,还对出租司机说:看,那是我的车。
    我想说,过去几年里我认识的、深交的、共事过的所有人,包括身边一批又一批二十出头收入一百多万的金融朋友、三十岁左右收入几百万的前辈朋友、以及简历金碧辉煌得已经不在乎收入的大 BOSS、以及我自己的经历告诉我两件事:


    一,顶级学校的文凭、顶级公司的工作、顶级的收入、顶级的房、顶级的车、顶级的声望,这些都无法满足人类。
    二,无论是通过爸妈,通过运气,还是通过奋斗得到这些顶级的东西,人类都不会得到更多的幸福感。


    接着北野武的故事说下去。想象一下:你今天骑在一辆助动车上,一个小山村来的年轻人经过,说你的车好帅,你不会有任何的满足感。十几年的奋斗后,你坐在一 辆你今天都叫不出型号的保时捷的驾驶位上,一个路人经过,说你的车好帅,相信我,你也不会有任何的满足感。你不在乎他,就像你今天不在说你助动车帅的人。 你的视角在变。每当我们考虑许多年后能够取得的成就,我们总是习惯站在今天的角度去衡量幸福感和满足感。你今天的视角只是错觉,却让你相信自己的目标是正 确的。这是我们最容易跑错方向的时候。


    人类的需求是很奇特的。我们吃第一个面包的时候的幸福感,和我们吃第一千个面包的时候的幸福感,是差不多的,前者甚至比后者还多一些。同样的感觉适用于我 们赚到的第一笔一万元和第一笔一千万元,第一辆十万的车和第一辆一千万的车,第一个女孩和第十个女人,第一个男生和第十个男人。“生理需求、安全需求、归 属与爱的需求、尊重的需求和自我实现的需求”-在著名的马斯洛五大需求中,你从任意一个细分需求里获得的幸福感只能有那么多。


    我们清楚地知道快感和幸福感的不同,我们也知道欲望和需求是两个东西(你从来没有听说过“马斯洛五大欲望”对不对?),但是我们的不幸福却是因为不小心把 快感当成了幸福感,把欲望当成了需求,而这就是因为我们常站在现在的视角去想象未来的感受。事实是,就好像我们不需要很多的面包一样,我们不需要很多的财 富,不需要很多的爱。因为他们很难给你带来更多快乐。当然,我们也不需要去拔高理想和自由的重要性。你可以尝试着停下来思考一下,这五种需求是否真的有高 低之分,思考一下,是否连最贫穷最饥饿的人们,都一直在生活中同时追求着这五个高低层次的需求。你会发现其实这五种需求一样真实,离你一样近,也一样远。 然后你需要找到一个可以同时实现这五种需求的平衡点。这个平衡点就是只属于你的奔跑方向。这篇文章会实实在在地帮你找到这个方向。但在这之前,我们先谈一 些别的。
      关于外界 
    外界带给我们生活最大的影响是嫉妒和比较。
    我们一直高估了嫉妒。举个例子,没有人嫉妒雷帝 Gaga。雷帝 Gaga 应该要比我们都更有名、更有钱、坐更好的车、住更大的房子,比我们更随心所欲,而且也比我们更有才华。但你不嫉妒她,对么?我们没有人嫉妒雷帝 Gaga-因为她实在是太雷了。她奇怪得让我们完全不能把我们自己跟她联系在一起,所以我们在名利和才华面前没有自卑,也没有嫉妒,更没有仇恨。反而,我 们会去思考,觉得她挺有趣的,挺发人深省的,不是么?


    所以当你见到好事情发生在了那个他或者那个她身上,嫉妒的小火苗在你心中扑哧扑哧的时候,不如把 TA 当成那个很奇怪的雷帝 Gaga 吧。因为这样的时候,我们就会懂得抛开个人的杂念,去真正思考别人的亮点。


    至于比较(Social Comparison),我们可以选择努力向那个绩点4.0的同学看齐,努力向那个年薪几十万的旧识看齐,努力向那个不断得到提拔的同事看齐。或者,我们 也可以选择看看外面更大的世界,那些和我们一样年轻的人们。看上去像是有 30 岁阅历的阿呆 Adele,19岁时出了张白金专辑《19》,21岁时出了全销量 1200 万张的专辑《21》,拿了两座格莱美。她出生于 1988 年。眼神和心态似乎已经像中年人那样淡定的杜兰特和德里克罗斯,两个毫无疑问的超级球星,他们也出生于 1988 年。如果你喜欢实用一点的,那么 iPhone 上用户量最大的个人开发第三方浏览器猛犸浏览器的开发者,是一个 1992 年出生的北京少年。如果你的视线中有一个世界舞台,那么你会看到上面的人物已经越来越接近你的年龄。


    我们不需要去看齐,我们只需要去“看”。去看到这个世界除了你现在正处在的那个若干平米的封闭空间以外,还有许多许多精彩的事正在发生。当你发现这个世界 的深度和广度,你就会发现你跟你身边的那些“同类人”根本没什么好比的。这个世界太大了。你不是你自己的标杆,别人也不是。谁都不是你的标杆,这是一个没 有标杆的时代。


    我们要做的是试着不去嫉妒,不去比较,更不要批判,但要试着去观察、去倾听,然后去思考、去沉淀、去让所有外界的信息在你大脑里经历一个长时间的处理过 程。在你的大脑还没有沉淀出你自己对一件事的观点前,不要发表观点,不要给出你的定论。我们可以不断在大脑中质疑我们所看到的、听到的,我们可以不断挑战 自己的想法、挑战任何理所当然的存在,只要我们保证我们的大脑一直在思考,独立地思考。要记得,你和世界上所有人都不一样。
      关于标签 
    “牛逼”是过去几年里笔者听到的比较多的一个形容词。当我们喜欢的人称赞我们的时候,我们总是P颠P颠的。在这里为自己开脱一下,觉得这挺好,说明活得挺真实。


    但笔者想用一个很好的朋友(自己来认领)去年当着我面描述我听的原话,来翻译一下这个已经被用得和“帅哥”“美女”一样烂俗的词。她说,“你想太多了(这 是她一贯的开场白)。你只是有很多很牛的标签-上海中学、沃顿商学院、最高荣誉、黑石的全职 Offer、百万年薪。至于你本身么,牛不牛就说不清楚了。”


    这个故事告诉我们:一、“牛”和“帅哥”“美女”一样,是一种打招呼的方式,二、“牛”的从来都是那些标签,那些改变了金融产业的企业,那些通过培养人才 改变了世界的学校,那些定义了时尚的品牌。虽然我无意改变大家打招呼的方式,但对于还没奔到三的人类来说,“高档”“精英”“牛逼”其实不如“做得不错” 或者“挺有意思的”来得更实在。当然,等奔到了三,我们就更不想用这些词了。


    如果你曾经或者将来获得了任何标签,不管是高盛中金麦肯锡,还是北大清华常春藤,又或是 Gucci Prada Armani,有两件事值得思考一下。


    第一件事用来提醒自己:撕去这些标签,我们或许还未能为 500 强的客户们创造等同于我们年薪的价值,我们或许还未能用知识改变世界,我们或许还未能把那件衣服穿出五位数价格的范儿。


    第二件事用来看清自己:这的确是一个人人都用标签来识别对方的社会,但是我们要记住我们的价值和我们身上的标签没有半毛钱关系。成功不是你有什么标签,而 是你用这些标签做了什么。(是的,文章开头的“沃顿商学院”“150万”“最高荣誉毕业”这些个标签让一部分人把这篇文章看到了现在,但无论如何, 对于心理上被冒犯到了的人,在此致以诚恳的歉意)。


    总之,把标签用在正确的地方,创造一些价值,虽然不是大到改变世界,也至少带来一些存在的意义。就不展开来说了。


    关于天才 
    不要去考虑什么天赋异禀,一切都来自经历和渴望。特别是这些年,当我认识了一些全中国、甚至全美国最“天才”的年轻人以后,才发现哪有什么天才,如果把他 们的经历一个个说出来,大家肯定觉得完全就是一群苦逼啊。但这些苦逼有一个共同点,他们很清楚的知道自己究竟需要什么,并且很嗨地追求着。

     第二部:那些最重要的事

      关于时间 
    时间是唯一的货币。你所拥有的财富很重要,因为你可以用它用来换很多东西。你所拥有的时间远远更重要,因为你可以用时间来换这世界上的任何东西,包括财 富,包括成就感,包括幸福感,包括其他那些我们都清楚的、比财富更让我们的生命有价值的东西。是的,每个人拿时间换每样东西的汇率都不同,有些人可以用很 少的时间换到很多的财富,有些人需要用很多的时间换到很少的幸福。但是事实是,只要你愿意花时间,你可以换到任何东西。所以你要想清楚,你到底要用时间来 换取这世上无限可能中的哪些。打开你的视野,你会发现有太多经历和体验可以让你去换取。但你的时间银行里每天只存了 24 个小时。你可能以为你还有一辈子的时间去做一些你想做的事,但事实是,没有人可以保证明天上帝是否会往你的银行里存另一个 24 小时。所以,你要想清楚。


      关于经历 
    如果你今天能从这篇文章中带走任何一样东西,我希望会是接下来关于经历的这一段。
    经历的英文叫什么?如果你曾经玩过角色扮演类游戏(RPG),你会知道有一个概念叫 EXP,全称叫 Experience,这就是经历的英文。人生就是一场巨大的 RPG,你扮演你自己。你唯一升级的方法,就是不断地积累 EXP。
    我们都了解那些故事,我们都懂那些道理,看了那么多励志贴,我们甚至都快知道为什么乔布斯会成为乔布斯。但只有经历才能让我们真正把那些道理变成意识。那些改变我们一生的道理,都是不是别人教会的。
    所以即使你有最完美的理论,你都没有把握说服那些还没有开上保时捷的人们,让他们懂得保时捷不是他们想要的,也没有把握去说服那些还没有在投行工作过的孩 子,让他们懂得去放弃投行(更何况,对于那些热爱金融的孩子来说,你的劝诫极有可能是错的)。所以哪怕这篇文章非常努力地想要往实用的方向靠拢,可能你看 完以后还是没有任何领悟。这一切就像你无法说服还没有吃过很多很多面包的人们,让他们懂得吃一千个面包是要反胃的。
    在人生的每个阶段,只有我们已经拥有的那些经历,决定了我们下一步会做什么。所以很多时候,你只要记得一件事,那就是: 去体验不同的经历。去爱,去恨,去在热恋中没心没肺地笑,去在失恋后声嘶力竭地哭,去翘课,去打架,去拼了命的读书,去让自己真的领悟那些道理。你所尝试 的事,你所认识的人,都是你经历的一部分。他们帮助你去理解你一只知道但是不曾真正理解的事,他们帮助你去看到一直存在着但是你不曾看到的世界。
    但是,你的人生很短,你的时间货币只有那么多。所以除了乔布斯已经告诉你的“不要生活在别人的世界里”你还要记得,永远不要重复一样的经历,因为你不会从 第二次一样的经历中收获到更多,更因为这个庞大的世界有太多有趣的人等待着我们去认识、太多截然不同的经历等待着我们去体验。
    这篇文章也会实实在在地帮助你探索不同的经历。你只要记住,如果你每个星期都在做着差不多的事情,那么一年以后你还是一年前的你,只是老了一岁。如果你愿 意每个星期、或者每个月都去尝试一种新的体验,或者认识一个来自完全不同背景的朋友,那么一年后你和一年前一样年轻,只是比别人多活了一年,多了一年的阅 历和对世界的认知。
      

    关于是否会为了去经历、去追随感情和理想而后悔 
    我们一定会后悔。但我们不会为了作出追随感情、或者追随理想的决定而后悔。事实是,如果我们有努力追寻、不愿放弃的梦想、如果我们有深爱的、不想伤害的 人,那么在这条道路上,我们必然会为我们曾经做过的某些事而后悔。当我们离理想和真爱越是近,我们越是容易后悔。就好像晚了一分钟错过飞机的人会比晚了一 个小时错过飞机的人更后悔懊恼-因为我们会清楚地看到如果自己不曾犯下某些错误,如果我们再多那么一点点的坚持,就或许已经实现了理想。所以后悔其实是一 个信号,它告诉我们,离目标已经很近了。更重要的是,我们活着不是为了追求什么瞎扯的“无悔的生活”,我们不用为那些后悔而伤心痛苦。因为在我们选择的这 条道路上,后悔不是告诉我们曾经做错了,而是告诉我们怎样可以做得更好。
      关于如何找到人生目标 
    兑现承诺的时候到了。我想用一种最简单、直接、有成效方法来解决那些励志文章和成功故事的一个通病:就是他们一直鼓励我们“做我们想做的事”,但从来不告 诉年轻迷茫的我们怎么去找到“我们想做的事”(以至于误导了很多朋友以为那就是“我想一觉睡到国庆节”或者“我想做个吃货”之类的意思)。
    我要说的这个方法在我认识的许多人身上成功过,但它不是我想出来的。知名博客写手 Steve Pavlina 在它的博客中对这个方法有很详细的描述,但似乎也不是 Steve Pavlina 自己想出来的。网上也有不少中文翻译版本,有可能你曾经看到过,但那些翻译都有失偏颇,以至于让读者很难理解精髓。所以在这里把原文重新编辑,结合以上的 经验分享,再用比较适合中国人的陈述方式分享给大家。如果你愿意尝试,愿意按照要求去做,或许我们可以用接下来的不到 500 个字,帮助你在 20 分钟到 1 个小时内找到你的人生目标。
      我们开始吧 
    (1) 先在你忙碌的生活中找出一个小时的完全空闲的时间。关掉手机,关掉电脑,关上房门,保证这一个小时没有任何打扰。这一小时只属于你,和你要找到人生理想这 件事。你要记住,这可能是你人生最重要的一个小时。你的生命可能在这一个小时候变得不同。如果一个小时的时间货币只能用来换一样东西,那么就是找到你的人 生目标绝对是最值得的。
    (2) 准备几张大的白纸,和一支笔。
    (3) 在第一张白纸上的最上方中央,写下一句话:“你这辈子活着是为了什么?”
    (4) 是的,接下来你要做的,就是回答这个问题。把你脑中闪过的第一个想法马上写在第一行。任何想法都可以,而且可以只是几个字。比如说:“赚很多钱。”
    (5) 不断地重复第 4 步。直到你哭出来为止。
    是的,就是这么简单。尽管这个方法看上去很傻,但是它很有效。如果你想要找到人生目标,你就必须先剔除脑中所有那些“伪装的答案”。你通常需要 15-20分钟的时间和过程去剔除那些覆盖在表面上的那些受到外界观念、主流思维影响而得出的答案。所有的这些伪装的答案都来自于你的大脑、你的思维、和 你的回忆,但真正的答案出现时,你会感觉到它来自你的内心最深处。
    对于从来没有考虑过这类问题的人来说,可能会需要比较长的时间(一个小时或者更多)才能把脑子里面的那些杂物剔除掉。在你写到 50-100条的时候,你可能会想放弃,或者找个借口去做别的事。因为你可能觉得这个方法没有任何效果,你的答案很杂乱,你也完全没有想哭的感觉。这很正 常。不要放弃,坚持想和写下去,这个抵触的感觉会慢慢地过去的。记住,你坚持下去的决定会将这一个小时变成你人生最重要的一个小时。
    当你写到第 100 个或者第 200 个答案的时候,你可能突然会有一阵内心情感上的涌动,但还不至于让你哭出来。这说明那还不是最终的答案。但是把这些答案圈起来,在你接下来的写的过程中你 可以回顾这些答案,帮助你找到最终的答案,因为那可能会是几个答案的排列组合。 但无论如何,最终的答案一定会让你流泪,让你情感上崩溃。
    此外,如果你一开始不相信人这辈子活着有什么目的,你也可以写下“1. 活着不为了什么。” 没关系,只要你愿意坚持想和坚持写下去,你也会找到让你哭出来的答案。
    作为你的参考,Steve Pavlina 在做这个练习的时候,花了 25 分钟在第 106 步找到了他的最终答案。而那些让他有一阵情感涌动的答案分别出现在在第 17,39,53步。他将这些抽出这些答案重新排列,最后在第 100 步到第 106 步答案得到了升华。想要放弃的感觉出现在第 55 到 60 步(想站起来做点其他事情,感觉极度没有耐心等等)。写到第 80 步的时候,他休息了 2 分钟,闭上眼,放松大脑,然后重新整理自己的思绪。这么做很有效果,在那 2 分钟的休息后,他的思路和答案变得更加清楚。
    如果你一定要拿笔者来做参考,那么答案是我当时比较无知,还不知道这个系统的方法,所以我用了四个月的摸索和迷茫,撞了很多墙,才找到了最终的答案(在第二章个人故事里会提到)。但经过笔者核实,这个方法科学有效,只因为它提炼出了关键的原理。
    无论你愿意用什么方法,你最终的答案一定会是一句比较长的句子,或者几句句子的组合。这个答案在外人看来一定非常的空洞,就像是我前面所说的那种 “谁都知道,但是只有少数人真正理解的大道理”。但是这几句空洞的句子会对你有非常丰富而且有意义的含义-因为这是你自己用了至少一个小时的时间和精力去 整理你过去所有的经历,去思考,去判断,去剔除,去整合,去沉淀,最终领悟出来的。如果你认真看完了从文章开始到这里为止所有的分析,你就会理解为什么这 个方法是非常有效的。
      关于为什么要有个人生目标(以及它和活捉林志玲的关系) 
    这是个好问题。所有人的终极目标其实都一样,就是用有限的人生货币去换最多的幸福感(这个幸福感可以来自内在的、外在的、和世界上任何人和物)。但大部分 人都觉得这是件很困难、而且不知道如何下手的事。最大的问题其实就是,如何最大化人生幸福感是一个几万行的方程式,当中你要做出数亿个选择,而我们却指望 用逻辑去解决它。你也知道,逻辑是多么不靠铺的一个东西。很多时候,你往往觉得你已经把脑子想炸了,但还是做不出一个选择,这是大脑逻辑功能达到处理极限 的问题,它只能解决绕五个弯的问题,面对绕一百个弯的问题它弱得和奔 2 一样;又有的时候,你的逻辑很容易被你的欲望给废掉了,这个情况最常出现在早上起床的时候-“我该起床么?”“Hmmm…睡着挺舒服的,不起了。”-你以 为你用逻辑完美地解决了问题,其实你只是让欲望解决了问题,然后用逻辑完美地说服了自己。所以我们经常在过了一段时间后,突然发现,我们的欲望挂着“逻 辑”的羊头“解决”了所有问题,但是自己却空虚得没有任何幸福感。我们不想这样,所以我们需要把你的大脑处理每一个选择的过程变得非常简单正确。
    确立一个人生目标为什么可以解决这个问题?很简单,人生目标把你那个不知道是什么火星进制的大脑逻辑简化成了二进制。假设你的人生目标是“活捉林志玲” (当然,这只是一个不可能发生的例子,千万不要有人因为写到这个目标哭了出来),那么你每天早上的起床的时候的过程就是:“我该起床么?”“Hmmm…继 续睡下去能帮助我活捉林志玲么?”“很明显不能。起床!”
    这就是你听过很多励志演讲者会说:“究竟是什么让那些幸福快乐的人每天一大早醒来想也不想得就冲下床去做他们要做的事情?”-是林志玲。噢不,是他们的人 生目标。其他事情也一样:“我要吃饭么?”“不吃饭我能活捉林志玲么?””不能,所以我要吃饭。”“我要去夜店么?”“去夜店能帮我活捉林志玲么?”“不 能,锻炼好身体一定可以。所以我还是用去夜店的时间货币去换强健的体格和咏春拳吧。”你会发现你不用再去依赖不靠谱的复杂逻辑,做任何决定都很简单而且正 确。当然,你的人生目标会“活捉林志玲”看上去高尚、空洞很多,它也一定会涵括你对自己、对身边亲人好友、对世界的考量。但记住无论如何,你那外人看似空 洞的目标曾让你哭出来,所以它对你来说一定有极为丰富的含义。
    最后,你可能会问:“我怎么能确定一直按照人生目标做出选择,我一定能最大化幸福感呢?” (其实这个问题看上去不怎么需要解释的)那是因为你的人生目标是你自己剔除了你欲望带来的杂七杂八的“伪装的需求”,经过沉淀以后得出的你内心最深处最想 要的东西,它是你真正的需求。跟随着它你会在短期获得应该获得的快感,更会在长期得到你需要的幸福感。
      关于现实和人生目标 
    我想给所有已经、即将、或者希望找到人生理想的人,和大家分享两个很平凡的故事,作为结束。
    我想讲的第一个故事来自我大学最重要的两个导师之一。他是沃顿的一个明星教授,麻省理工本科,哈佛法学院毕业,五十多岁,教了十七年谈判学的课程。尽管他的课作业量很大,但每一年他的课都已几乎满分的学生评分位列沃顿所有课程的前三甲。
    在我大学毕业前,我约他在费城附近的一个小镇吃了顿午饭。他跟我讲他年轻时候的故事的时候,我问他,他这辈子做出过得最让他后悔的决定是什么?
    他说,他从小一直很想当老师,特别是小学老师。当他二十多岁从麻省理工毕业的时候,他有一个很好的机会,去家里附近的一家他很喜欢的小学做老师。但即使在 美国,小学老师也几乎是待遇很低、不受尊重的一个职业。而同时,他拿到了哈佛法学院的 Offer。最后他去了哈佛法学院,而这就是他这辈子做出过最让他后悔的决定。他后悔,不仅仅因为他后来发现哈佛法学院是那么的无聊而且勾心斗角,更因为 他当时为了一个被社会所尊重、所仰慕的选择,放弃了一个被社会遗弃、看不起的选择。
    他说他很幸运,一直那么喜欢当老师,在从法学院毕业许多年的颠沛流离以后,终于如愿以偿成为了一个老师。当我和一些人说起这个故事的时候,他们的第一反应 就是,这不是乱说么?如果不是去了哈佛,他可能现在还只是个小学老师,根本不可能成为沃顿教授啊。我想,现实和理想的意义对于每一个人都是不同的, 我们只需要理解并不是所有人都觉得成为成为名校的教授是比普通学校的小学老师更伟大、更幸福的成就。
    第二个故事开头,我想问一个问题:你有没有考虑过我们每天上校内上微薄,看到很多人分享各种励志、免俗、追求梦想的文章,但他们最后究竟做什么去了?你可 能以为他们马上回归现实去了。但其实他们很多时候,是怀揣着那些道理,继续去做他们知道怎么做的事情。这就有了第二个故事。
    每一个二十岁左右的年轻人都像一台高速运行的电脑。一代比一代运转地更快。我们从懂事开始就有别人告诉我们要运行各种程序,上幼儿园,上小学,上初中,上 高中,上大学,工作,等等等。我们停不下来。关键是,我们很难运行自己想要运行的程序,因为过去二十年里面我们运行的所有程序都是别人编好以给我们的-我 们自己不会编程序。
    如果有一天,有一台电脑突然下了决心,要运行自己的程序,他就必须先停下来。这时,他会看着周围所有的电脑依然在高速运行着,甚至嘲笑他怎么不动了,然后 把他远远地甩在后面。而他,需要慢慢地开始学习自己编程,这个过程很漫长,很痛苦,因为从来没有人教过他。这就是为什么世界上只有少数人在运行自己的程 序。
    说这两个故事不是为了励志,而只是为了告诉大家如果今天或者明天你找到了人生目标,将会发生一些什么:一、即使你内心已经明确地知道你想要什么,依然会有 一些更为社会认同的东西来诱惑你,要永远记得坚持。二、如果你坚持了,你一定会经历一个学习自己写程序的过程,这个过程会是痛苦并漫长的。总有一天我们会 愿意去面对这个过程。好消息是,我们都还年轻。所以不如趁着现在还有那些热情和勇气,去撞一撞那些墙,用最少的代价。

     第三部:过去一年里的个人故事,给所有十年来认识的、和喜欢听故事的朋友们

      辞职前的故事 
    我从去年暑假结束,拿到回黑石的 offer 后,就开始了寻找自己人生目标的旅程。2010年的九月到 12 月,我过得挺糟糕的。因为我每天起来都在想我接下来这辈子要干什么。我可以很清楚地看到如果我接受了那个 offer,我未来两年的前景。我们办公室里有一个韩国人 Jay,我实习的时候是他做分析师的第三年。每年的反馈中,他都是黑石他那一届全球所有分析师里最强的那一个。我没有怀疑自己能够成为这届最好的分析师, 但同时,我也可以很清楚地看到,J 是我能成为的极限。但仔细想想,J也不过只是那样,像永动机一样地在办公室努力工作,像尊贵的孩子一样在夜店潇洒地玩耍。J是最出色的,但也是黑石所能创 造的最出色的。
    后来我想到了环境的局限性,想到了密集网络。我在上中的时候,我这届最好的学生去了北大和清华。而在沃顿时,最好的学生去了高盛直投、贝恩资本、凯雷、 KKR、Jane Street 等买方。我想到我们是不是已经成为模式化思维的牺牲品(victims of stereotypes)。 我们的社交圈里都是与我们同类的人,我们互相交流、竞争、鼓励、启发,处于所谓的密集网络。我们自以为我们充分见识了整个世界,但其实我们只是在重复肯定 同一类信息。所以如果你是“最出色的”那一个,那么你极有可能就是所有和你同类的人当中最出色那一个。但这也就是你的极限。而有另外一群人,他们只是想和 别人有点不一样,他们想去外面看看,去见识见识这个世界究竟有多大,他们想要找到自己独特的生活。对于这些人来说,天空才是极限。说实在的,所有当年选择 DIY 出国的朋友们,如果今天你有幸拿到了让那些当年去北大、清华的那些同学羡慕的 Offer (再次向躺着也中枪的北大、清华同学致以崇高的歉意),如果你有了比同龄人更多的见识,那绝对不一定是因为你比他们更出色,很大程度上是因为在那个出国还 没有像今天一样流行的年代,你没有被那个上北大、上清华的模式化思维所套住。所以老天很弄人,因为所有一直在追求“出色”和“卓越”的人最后都在他们最坚 信的标准上“输”给了那些只是想过自己独特生活的人。
    当然,2010年末的时候,我只是确定了自己是被老天玩弄的人哪。但幸好我还有一年时间,我决定一定要要找到一个属于自己的生活目标,然后坚定地走下去。 一开始,我和很多人一样,觉得人生的终极目标就是要多走走,去见识这个世界,活出自我。但后来我发现这个目标其实只是说着好听,但是其实不能给人带来持续 的动力,然后我就很伤心。再然后,我好不容易想出了一个有点与众不同的目标,就是“做个有意思的人”(Be an interesting person)。因为对我来说,这是我当时能给另一个人的最高评价。但后来我又想了想,这个目标用管理学的标准来说,就是太不具体太不精确所以很难提供持 续动力。然后我就更伤心了。所以从九月到十二月的四个月里,每天起来就因为找不到人生目标而痛苦。因为自己跟自己的内心对话太多,经常一不小心就错乱了。 当时也没有人告诉我什么 20 分钟就可以找到人生目标的这种好事。于是我就上了很多奇奇怪怪的课,和各种奇奇怪怪的人交流,希望从他们的经历中获得一些启发。那段时间我过得真的很彷徨 也很烦躁,好在我坚持了下来。我谈判课上的教授成为了我很重要的一个导师-尽管他从来没有一对一给予我任何指导。但就像我前面提到的,那些改变我们人生的 道理,都不会是别人教会的。进入到十二月以后,我的目标慢慢找到了我。
    四个月里经过无数内心挣扎之后沉淀下来的思想最终被我总结成了两句很简单、看似和“做个有意思的人”一样不具体、但对我而言包含了丰富含义的话:
    ”To grow and to help others grow. To live and to help others live.”
    ”成长,并帮助别人成长。体验和经历生活,并帮助别人体验和经历生活。”
    这两句话就成了我的人生目标。它能让我感动得哭,也能让我感动得笑。最重要的是,尽管这两句话在外人看来可能莫名其妙,但我发现这两句话解释了过去二十多 年里自己做的许多事情背后的原因,其中包括了我为什么从小一直都不好好读书,为什么选择出国,为什么一直逃课,为什么在 2009 年和一群朋友一起创建了 BIMP 这样一个神奇的项目,等等等等。
      关于辞职的决定 
    在确定了人生目标以后,我的思路和视野都变得清晰了很多。我很快找到了我想要做的事。和身边许多的朋友一样,创业也曾经是我大脑中的考虑过的一个想法。但 我一直想不到任何我愿意用我几乎所有的时间货币去换的一个创业项目。但在确定了人生目标的今年一月份,我几乎没有花什么时间就确定了一个项目的大方向,这 个商业项目的创意像是奔着我而来的。然后再通过不断的完善从一个不成熟的产品渐渐变成一个成熟的产品,一个真正可以持久给所有人带来价值的产品。
    所以,可能和许多我很尊敬的朋友不同,我的出发点并不是“慈善”和“义务服务”,“创业”也从来都不是我的目标(一个学了四年金融的人怎么可能一直心存 “创业”这个目标呢),我的目标就是实现“成长,并帮助别人成长。体验和经历生活,并帮助别人体验和经历生活。” 简单的说,我的内心并没有一个声音告诉我“你一定要创业、你一定要创业”,只是碰巧创造一个商业化的项目是实现这个目标最好的方式,而创立一个商业项目这 件事碰巧叫做创业。
    而另一方面,在黑石工作可以帮助我“成长”和“经历”,但是我觉得在黑石的一个暑假实习里,我用 20% 的时间经历了接下来的两年里可能会经历的 80% 的体验,对我来说已经很值得了。我也一定会“成长”,但是未必会比创业成长得更快、更深刻、更理想、更多样化(比如说我就没有办法做我一直很想做的美工设 计工作了!)。最重要的是,我意识到在黑石我基本上不能实现我人生目标的另外 50%-“帮助别人成长。帮助别人体验和经历生活”。所以结果就是, “是否辞去毕业后的第一份工作,直接成为无业游民”这么重大的一个选择,被我用人生目标给瞬间解决了。有多瞬间呢?我后来发现了个有趣的巧合。
    四年前,我曾经尝试着去写一篇回忆录,来回忆出国两年多的旅程,然后这篇回忆录不幸地才写到出国的第一年就没有后来了。尽管写回忆录是一件有点折磨人的事 情,但读回忆录绝对是件超开心的事。当中我写到过六年前我决定放弃轻松进北大清华的机会,毅然决定出国念高中,因为上海中学不支持孩子们申请国外大学。原 文如下:
    “北大清华这种学校我肯定不去!”我当时的有两个很简单也很清晰的想法:一,I deserve the best in the world,二,也是更重要的想法,我想,就算最终在美国毁了,我至少做了一个帅到五体投地的决定,我鄙视了北大清华。更离奇的是,从那以后的两年至今, 我几乎从来没有为这个决定后悔过,也不觉得这有什么好想的。仿佛这道选择题是在侮辱我的智商而不是测试我的智商一样。无论如何,两年后的现在,我相信,这 个帅到五体投地的决定,是我一生至今最正确的决定。”
    这个故事告诉我们:人是不会变的。把上文中的北大清华换成黑石,就是我的大脑在半秒中以内做出辞职这个决定的思考流程。可见大脑在考虑一些人生大事上是不怎么需要运作的,让心去运作就足够了,而你的人生目标就是你的心。
    如果说这六年里,相比上面这段话我又多了什么领悟,那就是(1)一个人生目标(2)人生没有任何决定是错误的,因为你永远无法知道另外一个选择是否是正确的。
      撞上的许多堵墙 
    Randy Pausch 在他著名的“最后的演讲”中提到过一个很实在的观点。他说,在我们追寻理想的道路上,我们一定会撞上很多墙,但是这些墙不是为了阻挡我们,它们只是为了阻 挡那些没有那么渴望理想的人们。这些墙是为了给我们一个机会,去证明我们究竟有多想要得到那些东西。
    我撞上的第一堵墙,就是我没有如我所愿地一毕业就辞职。考虑到团队开发的进度,个人诚信问题方面带来的压力,家庭的压力,以及很多直接辞职可能带来的负面 因素,我最终还是回去工作了四个月才得以正式辞职,其中包括一个月的培训。很长一段时间里,大老板都不允许我告诉任何人我辞职的事情,但大老板自己却没有 做好保密工作,以至于同事们最终都知道了我一个小小的分析师要辞职。但我又被规定不能公开,所以在我座位附近的办公室气氛很糟糕,上班感觉度日如年。当中 还穿插了许多压力山大的故事,比如我遇上了公司最高管理层一年一度的 3v1 谈话,在一个阳光明媚的下午被三个在华尔街响当当的名字各种拷问,因为我光荣成为了公司历史上第一个干都没怎么干就宣布不干了的分析师(从小到大,坏孩子 光荣榜上真是永远有我的名字)。又比如曾经跟我关系很好的一个 VP 整整四个星期把坐在整个办公室出入口的我当空气。但是无论当时多煎熬,现在想来都是非常独特的人生经历。
    其实我很感谢和尊敬黑石,不仅因为我仍然是个热爱金融的家伙,更因为每一个我接触过的同事的做事风格都对我的个人风格产生了一定程度的影响。从情感的层面 上,我最感激的是负责团队人事的韩国 VP,在我辞职的过程中帮我做了许多疏通的工作。在我离开的前两天的晚上,他说了一句我印象很深的话。他说,“Denny,你知道,作为你的上司,这次我 面对着一个选择,是照顾公司的利益还是你一个年轻人的利益。我选择了后者。我希望你以后不用面临这样的选择。但如果你有一天遇上了,我希望你可以跟我做一 样的决定。”
    我离开的那一天,我的同事和几个以前一起共事过的朋友给我发来了道别邮件。让我很高兴的是,他们在祝福中都用了同一句话“You are very brave”(“你很勇敢”)。之所以高兴,是因为无论今后的道路如何艰难,至少在旅程的起点我实现了奥巴马用来形容乔布斯一生的第一个形容词。对于一个 活在当下的傻子来说,这已经足够了。
    现在我在上海的家中,和我非常喜欢而且非常有创造力的人们一起工作。虽说生活条件很普通(以银行家的标准来说的话简直是糟糕透了),虽说工作强度和时间依 然和在黑石的时候差不多(以银行家的标准来看的话处于中上水平),但回到上海后的这段日子确确实实是我人生中自我学习曲线上升最快的一段日子。所以顺便说 一个建议,当那些备受尊敬的金融机构告诉你为什么要选择他们的时候,特别是关于学习曲线的那些理由,不要那么快就为之屈服。他们不仅有可能(虽然也仅仅是 可能)在推销给你一些你并不需要的东西,并且他们永远不会带你看清楚这个世界上全部的可能性。你要跳出“密集网络”,自己去看清楚。这个建议出自依然热爱 金融的笔者。
    我一年的故事就这么讲完了。如果回顾总结过去一年的人生,那么最好的形容就是从一年前我确定了人生目标的那天起,一切就开始失控。但我想在这个回顾的最 后,和所有已经确定了自己人生前进方向的朋友,分享这一年最大的感想:你的理想就像一辆车,如果你觉得这辆车的一切都在你的控制之中,那么可能说明你开得 还不够快 (Your dream is like your car. If you are in full control of it, you are not driving it fast enough)。
      关于感谢 
    感谢所有支持你、欣赏你、否定你、看低你的人。
    我一直说,永远不要忘记你从哪里来,要到哪里去。我不是一出生就上了好到可以改变我的学校,一直到六年前,我都不算是个好学生,学生生涯当过的最高的职位 是小队长,期中期末考试好像从来没有进过班级前三,有一年甚至还是全校倒数 10%,更不知道自己要什么。感谢自己不知为什么突然一根筋地开始愿意好好努力,自从那以后就知道实现梦想就靠坚持付出,没有别的秘诀。后来我出国,看到 了一个很大很大的世界,在一路的坚持中,遇上了许许多多带给我灵感的人, 他们用他们的经历影响和改变了我。这就是为什么我一直告诉自己不要忘记你从哪里来,这也是为什么我想继续传播我受到的影响,可能是作为一种感谢。

       今年上半年还在上创业课的时候,我一边要照顾自己的项目的开发,另一边又创业课项目团队中的其他四个成员眼看即将毕业,完全不作任何事情。我的教授 Gelburd,一个前创业家,也是我在沃顿的第二个导师,他并没有因为我一个人担纲整个项目的开发和准备而减轻对我们团队的项目的要求,但是他给了我很 多鼓励。期末演示日的那天,我在一天有三个期末演讲的情况下,被迫一个人完成了 80% 的项目演示。没有什么奇迹,我们的质量肯定不是最好的。但在我毕业的前几天,我收到了这门课的成绩。Gelburd 给了我A+。他写了一封感谢信给他,他回复我说,每一年上这个课的学生中,真正去创业的不出三个,I think you will be come very successful。

    来源于:小强博客http://xqtesting.blog.51cto.com/4626073/900743
  • 软件测试BUG等级权重分配新说

    bob123654 发布于 2012-03-31 09:10:00

    随着测试行业的发展,测试队伍的不断壮大,测试规范也变得越来越完善

      周五下午开周例会,大家讨论一个了确定一个很有意思的问题,那就是Bug的权重分配问题。

      几年前,公司对于测试人员的工作评估主要是依据该测试人员发现bug数目

      而现在,我们将bug分为了若干等级,分别为致命,严重,一般,提示,建议等等,并将这些等级分别附一个权重,最后的测试人员的工作评估是按照最后的权重值来计算的。

     Bug等级

     权重

     致命

     3

     严重

     2

     一般

     1

     提示

     0.5

     建议

     0.25

      例如,我发现了2个致命的bug,4个提示的bug,3个建议的bug,最后的成绩=2*3+0*2+0*1+4*0.5+3*0.25=8.75

      这种方法的评估显然比起第一种方法要科学了许多,因为发现了致命的bug能给公司挽回的损失要多很多,也在一定的程度上鼓励测试人员多去发现致命的bug

      其实目前很多公司都在采取这种评估方式,但是,会后我也在思考,有没有更好的方法来评估测试人员的工作呢?

      我想是有的,试想,如果我们将这权重倒过来分配给这些等级的bug会如何?化成表格则是这样

    bug等级  权重
     致命  0.25
     严重  0.5
     一般  1
     提示  2
     建议  3

      我们都知道,bug等级的评定在一定程度上也是根据bug发现的难易程度来确定的。这种根据bug发现的难易程度来分配权重的方式可能会更加贴近我们的实际工作。对于致命的bug,一般是会阻塞接下来的测试的进行,测试人员一定会给与跟踪直至其被解决。而对于建议的bug,需要测试人员花更多的时间去思考,是一种更加积极的工作态度,更是一种客户导向观念深入到骨髓的体现,这样级别的bug,公司应该要鼓励测试人员去挖出来,才能使产品越做越好。

      也许我想这样的评估方式也需要基于一定的前提,那就是该公司的产品已经做的比较成熟了,如果对于某产品,还停留在实现基本功能的情况下,当然第二种方式会更加符合。

  • 也谈测试用例的粒度

    windshl 发布于 2010-08-16 11:47:56

    前两天在51Testing上看到来自Taobao QA Team的一个辩论议题:测试用例的粒度是粗点好还是细点好?这真的是一个很棒的议题,在平时的工作中我也会遇到这个问题。但是,到底是粗点好呢还是细点好呢?个人认为,这并没有一个标准的答案,粗和细本身就是相对的。从管理者的角度,当然是希望测试用例越细越好,但是从实际执行者的角度,在实际项目执行过程中,很多时候只能在粗和细中做出取舍和平衡。下面,我也谈谈自己的一点拙见吧。
    1.看项目Schedule:在项目时间紧张的情况下,往往留给测试人员的时间很有限,测试工作的重点就是多测试,早发现问题,这时候我认为测试用例的粒度是可以放粗一些的,但是“粗”不代表随意,虽然可以放“粗”一些,但是要能明确测试要点,分清主次。而在项目时间宽裕的情况下,我还是希望能尽量将测试用例写细一些,因为在写测试用例的同时,也能加深对产品的理解。此外,测试用例的粒度写的细,也能为后期的测试执行提供很大的帮助,为后期确定测试退出提供一定的数据支撑。
    2.看项目人员情况:在项目实施过程中,测试用例通常是由具有较丰富测试经验的人来负责并主导编写的。对于测试新人,测试用例往往对新人更快更好的理解产品并完成测试任务提供了非常大的帮助。因此,对于测试新人,希望测试用例粒度细点是可以理解并认可的。而对于测试老鸟,很多时候他们既是测试用例的编写者,同时也是测试用例的执行者,他们往往会有这样一种认知:既然测试用例都是我来执行,我为什么要写的那么细呢?我自己知道不就可以了吗?编写测试用例只是从流程上保证项目质量的手段之一,只要我能将把好质量关,又何必苛求于测试用例的粗细?重要的是测试的思想,而不是测试用例的粗细,测试用例粒度写的太细会占用太多的时间,我为什么不把时间投入到如何提高测试效率等更有价值的事情上去?测试新人有测试新人的道理,而测试老鸟的认知也有其道理,因此,在一个项目组中,如果测试新人所占比例较大,对测试用例的粒度要求还是要尽可能细些,这样可以帮助新人更好的适应项目角色,而对测试老鸟来说,一起教总比一个个教来得更有效率。
    3.看客户需求:有些客户,在验收产品的时候,会要求一并提供测试用例以及其执行情况,这种情况下,无论项目Schedule是否紧张,都需要按照客户的要求来完成,因为这也是一项需求。
    4.看项目本身是否具有延续性:随着产品的多元化,产品的升级换代速度是很快的,换个UI,换个组织架构,或者重新包装一下就是一个新的产品。这种情况下,总会有些功能模块是一致的,测试用例也是可以复用的。因此,对于一些具有延续性的项目,个人还是认为测试用例的粒度可以尽量细一些,这样有利于知识的传承。而对于那些一次性的项目,测试用例粒度稍微粗些也没关系,只要不影响项目质量就好。
    总的来说,个人认为测试用例的粒度并没有特定的标准,要依据项目实际情况而定。测试用例粒度当然是越细越好,但这仅是理想上的,实际上可操作性还是一个大大的问号。在实际执行中,要依据项目的实际情况和公司的相关制度而定,适用的才是最好的,毕竟项目的质量好坏才是最终的目标,如果因为纠结于过程而影响到最终的结果恐怕就不好了,过程是为了服务于结果,可不要陷入为了过程而过程的怪圈。
  • 测试经理的好帮手-测试任务单跟踪表

    liaoxj 发布于 2010-12-14 10:26:30

    测试任务单填写说明和要求:

    1.每个测试小组一份,每周一个sheet页,
    2.每周根据右键移动或复制工作表,并选中建立副本属性。
    3.每天早上测试组长和小组成员确认每天工作计划,以及计划工作量。
    4.每天下班标识完成状态,实际工作量,以及增加计划外的工作。
    5.每周五下午1:00之前测试组长完成下周计划的编写。
    6.计划状态,工作类型,完成状态,任务名称,实际工作量必填。
    7.完成状态标识未完成,需编写备注说明,说明未完成原因。
    8.任务名称中需标识项目名称,如:BSHRP5.0:药房系统住院发药部分单元测试
    9.任务名称需编写清晰明了,要求达到可验证,不能太笼统。
    10.项目例会和部门例会如果每周定义的,计划状态也请标识计划内。
    11.如果计划内的工作由于各种原因没有执行,实际工作量请标识0。

  • 网络丢包排除法

    JoAndPanDa 发布于 2010-02-24 17:57:57

    转自:http://zhidao.baidu.com/question/7368874
    网络中可能出现的故障多种多样,往往解决一个复杂的网络故障需要广泛的网络知识与丰富的工作经验。这也是为什么一个成熟的网络管理机构制订有一整套完备的故障管理日志记录机制,同时人们也率先把专家系统和人工智能技术引进到网络故障管理中来的原因。另一方面,由于网络故障的多样性和复杂性,网络故陈分类方法也不尽相同。我们可以根据网络故障的性质把故障分为物理故障与逻辑故障,也可以根据网络故障的对象把故障分为线路故障、路由器故障和主机故障。

    我们首先介绍按:照网络故障不同性质而划分的物理故障与逻辑故障。

    1.物理故障

    物理故障,是指设备或线路损坏、插头松动、线路受到严重电磁干扰等情况。比如说,网络中某条线路突然中断,这时网络管理人员从监控界面上发现该线路流量突然掉下来或系统弹出报警界面,这时首先用ping检查线路在网络管理中心这端的端口是否连通,如果不连通,则检查端口插头是否松动,如果松动则插紧,再用ping检查,如果连通如故障解决。这时须把故障的特征及其解决步骤详细记录下来。也有可能是线路远离网络管理中心的那端插头松动,则需要通知对方进行解决。另一种常见的物理故障就是网络插头误接。这种情况经常是没有搞清网络插头规范或没有弄清网络拓扑规划的情况下导致的。比如说网络插头都有一些规范,只有搞清网线中每根线的颜色和意义,才能做出符合规范的插头,否则就会导致网络连接出错。另一种情况,比如两个路由器直接连接,这时应该让一台路由器的出口连接另一路由器的入口,而这台路由器的入口连接另一路由器的出口才行,这时制作的网线就应该满足这一特性,否则也会导致网络误解。不过像这种网络连接故障显得很隐蔽,要诊断这种故障没有什么特别好的工具,只有依靠经验丰富的网络管理人员了。

    2. 逻辑故障

    逻辑故障中的一种常见情况就是配置错误,就是指因为网络设备的配置原因而导致的网络异常或故障。配置错误可能是路由器端口参数设定有误,或路由器路由配置错误以致于路由循环或找不到远端地址,或者是网络掩码设置错误等。比如,同样是网络中某条线路故障,发现该线路没有流量,但又可以Ping通线路两端的端口,这时很可能就是路由配置错误导致循环了。诊断该故障可以用traceroute工具,可以发现在traceroute的结果中某一段之后,两个IP地址循环出现。这时,一般就是线路远端把端口路由又指向了线路的近端,导致IP包在该线路上来回反复传递。这时需要更改远端路由器端口配置,把路由设置为正确配置,就能恢复线路了。当然处理该故障的所有动作都要记录在日志中。逻辑故障中另一类故障就是一些重要进程或端口关闭,以及系统的负载过高。比如,路由器的SNMP进程意外关闭或死掉,这时网络管理系统将不能从路由器中采集到任何数据,因此网络管理系统失去了对该路由器的控制。还有,也是线路中断,没有流量,这时用ping发现线路近端的端口ping不通,这时检查发现该端口处于down的状态,就是说该端口已经给关闭了,因此导致故障。这时只需重新启动该端口,就可以恢复线路的连通了。另一种常见情况是路由器的负载过高,表现为路由器CPU温度太高、CPU利用率太高,以及内存余量太小等,虽然这种故障不能直接影响网络的连通,但却影响到网络提供服务的质量,而且也容易导致硬件设备的损害。

    网络故障根据故、障的不同对象也可划分为:线路故障、路由器故障和主机故障。

    1.线路故障

    线路故障最常见的情况就是线路不通,诊断这种故障可用ping检查线路远端的路由器端口是否还能响应,或检测该线路上的流量是否还存在。一旦发现远端路由器端口不通,或该线路没有流量,则该线路可能出现了故障。这时有几种处理方法。首先是ping线路两端路由器端口,检查两端的端口是否关闭了。如果其中一端端口没有响应则可能是路由器端口故障。如果是近端端口关闭,则可检查端口插头是否松动,路由器端口是否处于down的状态;如果是远端端口关闭,则要通知线路对方进行检查。进行这些故障处理之后,线路往往就通畅了。如果线路仍然不通,一种可能就得通知线路的提供商检查线路本身的情况,看是否线路中间被切断,等等;另一种可能就是路由器配置出错,比如路由循环了。就是远端端口路由又指向了线路的近端,这样线路远端连接的网络用户就不通了,这种故障可以用traceroute来诊断。解决路由循环的方法就是重新配置路由器端口的静态路由或动态路由。

    2.路由器故障

    事实上,线路故障中很多情况都涉及到路由器,因此也可以把一些线路故障归结为路由器故障。但线路涉及到两端的路由器,因此在考虑线路故障是要涉及到多个路由器。厢有些路由器故障仅仅涉及到它本身,这些故障比较典型的就是路由器CPU温度过高、CPU利用率过高和路由器内存余量太小。其中最危险的是路由器CPU温度过高,因为这可能导致路由器烧毁。而路由器CPU利用率过高和路由器内存余量太小都将直接影响到网络服务的质量,比如路由器上丢包率就会随内存余量的下降而上升。检测这种类型的故障,需要利用MIB变量浏览器这种工具,从路由器MIB变量中读出有关的数据,通常情况下网络管理系统有专门的管理进程不断地检测路由器的关键数据,并及时给出报警。而解决这种故障,只有对路由器进行升级、扩内存等,或者重新规划网络的拓扑结构。另一种路由器故障就是自身的配置错误。比如配置的协议类型不对,配置的端口不对等。这种故障比较少见,但没有什么特别的发现方法,排除故障就与网络管理人员的经验有关了。

    3.主机故障

    主机故障常见的现象就是主机的配置不当。比如,主机配置的IP地址与其他主机冲突,或IP地址根本就不,在子网范围内,这将导致该主机不能连通。还有一些服务的设置故障。比如E-Mail服务器设置不当导致不能收发E-Mail,或者域名服务器设置不当将导致不能解析域名。主机故障的另一种可能是主机安全故障。比如,主机没有控制其上的finger,rpc,rlogin等多余服务。而恶意攻击者可以通过这些多余进程的正常服务或bug攻击该主机,甚至得到该主机的超级用户权限等。另外,还有一些主机的其他故障,比如不当共享本机硬盘等,将导致恶意攻击者非法利用该主机的资源。发现主机故障是一件困难的事情,特别是别人恶意的攻击。一般可以通过监视主机的流量、或扫描主机端口和服务来防止可能的漏洞。当发现主机受到攻击之后,应立即分析可能的漏洞,并加以预防,同时通知网络管理人员注意。


    四、 网络管理工具

    目前网络管理的工具很多,但很多网络管理工具都集成到网络管理系统中,单独的网络管理工具不多。但仍然存在一些简单、实用的网络管理工具,这些工具包括:连通性测试程序(ping)、路由跟踪程序(traceroute)和MIB变量浏览器。

    1.连通性测试程序

    连通性测试程序就是ping,是一种员常见的网络工具。用这种工具可以测试端到端的连通性,即检查源端到目的端网络是否通畅。ping的原理很简单,就是从源端向目的端发出一定数量的网络包,然后从目的端返回这些包的响应,如果在一定的时间内收到响应,则程序返回从包发出到收到的时间间隔,这样根据时间间隔就可以统计网络的延迟。如果网络包的响应在一定时间间隔内没有收到,则程序认为包丢失,返回请求超时的结果。这样如果让ping一次发一定数量的包,然后检查收到相应的包的数量,则可统计出端到端网络的丢包率,而丢包率是检验网络质量的重要参数。

    在广域网中,线路一般是网络的重要对象,因此监测线路的通断,统计线路的延迟与丢包率是发现网络故障、检查网络质量的重要手段。而网络中线路两端一般是路由器的两个端口,所以通常的监测手段就是登录到线路一端的路由器端口上ping线路另一端路由器的端口地址,从而掌握该线路的通断情况和网络延迟等参数。同时,由于登录是可以远程进行的,所以即使网络管理者在北京,如果他有足够的权限,他甚至能监测广州到上海线路的情况。

    ping这种工具有一个局限性,它一般一次只能检测一端到另二端的连通性,而不能一次检测一端到多端的连通性。因此ping有一种衍生工具就是fping,fping与ping基本类似,唯一的差别就是fping一次可以ping多个IP地址,比如C类的整个网段地址等。网络管理员经常发现有人依次扫描本网的大量IP地址,其实就是fping做到的。

    2.路由跟踪程序

    路由跟踪程序就是traceroute,在WIN95中是tracert命令。由于ping工具存在一些固有的缺陷,比如从网络的一台主机ping另一台主机,我们可以知道端到端之间的通断和延迟,但这个端到端之间可能有多条网络线路组成,中间经过多个路由器。用ping检查端到端的连通情况,如果不通则无法知道是网络中哪一条线路不通,即使端到端通畅也无法了解线路中四条线路延迟大,哪条线路质量不好,因此这就需要traceroute工具了。traceroute在某种方面与ping类似,它也是向目的端发出一些网络包,返回这些包的响应结果,如果有响应也返回响应的延迟。但traceroute与ping的员大区别在于traceroute是把端到端的线路按线路所经过的路由器分成多段,然后以每段返回响应与延迟。如果端到端不通,则用该工具可以检查到哪个路由器之前都能正常鸡应,到哪个路由器就不能响应了,这样就很容易知道如果线路出现故障,则故障源可能出在哪里。另一方面,如果在线路中某个路由器的路由配置不当,导致路由循环,用traceroute工具可以方便地发现问题。即traceroute一端到另一端时,发现到某一路由器之后,出现的下一个路由器正是上一个路由器,结果出现循环,两个路由器返回的结果中间来回交替出现,这时往往是那个路由器的路由配置指向了前一个路由器导致路由循环了。

    3.MIB变量浏览器

    MIB变量浏览器是另一种重要的网络管理工具。在SNMP中,MIB变量包含了路由器的几乎所有重要参数,对路由器进行管理很大程度上是利用MIB变量来实现的。比如,路由器的路由表、路由器的端口流量数据、路由器中的计费数据、路由器CPU的温度、负载以及路由器的内存余量等,所有这些数据都是从路由器的MIB变量中采集到的。虽然对MIB变量的定时采集与分析大部分都是程序进行的,但一种图形界面下的MIB变量浏览器也是需要的。一般MIB变量浏览器,都按照MIB变量的树形命名结构进行设计, 这样就可以自顶向下,根据所要浏览的MIB变量的类别逐步找到该变量,而无需记住该变量复杂的名字。网络管理人员可以利用MIB变量韧览器取出路由器当前的配置信息、 性能参数以及统计数据等,对网络情况进行监视。


  • 使用mtr测试网络丢包率和平均延时的脚本实例

    msnshow 发布于 2012-02-26 16:44:30

    mtr(a network diagnostic tool)是一个神奇的指令,能按要求对路由中所有节点进行批量测试。简单敲一个“mtr qq.com”将会有意外收获!

    当需要进行产品级的网络测试时,可在服务器上运行一段时间的mtr测试形成报告。如下脚本:

    #!/bin/bash
    # 测试网络丢包率和平均延时,注意变量clr和cdt的赋值,不同版本的mtr对应的字段位置不同
    # 脚本在CentOS 6.2 Linux 2.6.32-220.el6.x86_64 mtr v0.75 上测试通过
    urllist="
    www.qq.com
    www.kingsoft.com
    www.xunlei.com
    www.taobao.com
    www.163.com
    www.sina.com.cn
    www.weibo.com
    www.sohu.com
    www.china.com
    www.renren.com
    www.baidu.com
    www.g.cn
    8.8.8.8
    www.cctv.com
    www.youku.com
    www.tudou.com
    cn.yahoo.com
    www.1tpan.com
    www.115.com
    www.12306.com
    "
    urlarr=($urllist)
    date

    for ((i=0; i<${#urlarr[@]}; i++))
    do
    echo -n ${urlarr[$i]}',,'
    done
    echo
    for ((j=0; i< 10000; j++))
    do
    for ((i=0; i<${#urlarr[@]}; i++))
    do
    mtr -r -n ${urlarr[$i]} | sed 's/%//g' | awk 'BEGIN{
    lossrate=0;
    delaytime=0;
    }{
    if(NR!=1 && $1!="???"){
    clr=$3;
    cdt=$6;
    (clr<100.0&&lossrate<clr)?(lossrate=clr):true;
    delaytime<cdt?(delaytime=cdt):true;
    }
    }END{
    printf("%s,%s,",lossrate,delaytime);
    }'
    done
    echo
    done

    脚本的执行效果图如下:

    脚本会对网址列表进行1万次遍历,打印每次的丢包率和平均延时时间。网址可以随意添加,生成csv文件用Excel处理生成图表。希望对你也有用!

  • 如何测试延时,抖动,丢包率

    cutebeckyex 发布于 2010-02-03 15:46:40

    如何测试:延时,抖动,丢包率?

    dos下,有两个简单的dos命令可以让你知道用户本地与服务器之间的网络状况。

    选择“运行”,键入cmd回车,就可以进入dos窗口。

    dos下输入ping,

    如:ping 60.***.252.126 -t 就会得到下面的结果:

     

    (0203 下午1330-1350 趣聊 60.***.252.162服务器

    网络延时ping命令测试结果)

     

     

    Reply from 60.***.252.126: bytes=32 time=3ms TTL=122

    Reply from 60.***.252.126: bytes=32 time=5ms TTL=122

    Reply from 60.***.252.126: bytes=32 time=4ms TTL=122

    Reply from 60.***.252.126: bytes=32 time=3ms TTL=122

    Reply from 60.***.252.126: bytes=32 time=4ms TTL=122

     

    Ping statistics for 60.***.252.126:

        Packets: Sent = 499, Received = 477, Lost = 22 (4% loss),

    Approximate round trip times in milli-seconds:

        Minimum = 3ms, Maximum = 18ms, Average = 4ms

    Control-C

    ^C

    C:\Documents and Settings\Administrator>^A

     

    这里面, Lost = 22 (4% loss)是丢包率。

     

    Minimum = 3ms,延时最小值是3ms,

    Maximum = 18ms, 延时最大值是18ms,

    Average = 4ms,延时平均值是4ms.

    抖动是-1+14ms

     

    根据经验,这三个指标中,任何一个超标,都可以安装用户端,否则音频质量没有保障;

    丢包率:小于8%

    延时:小于200ms

    抖动:正负不大于40ms

     

    dos命令下输入第二种命令tracert,这个命令能够掌握用户端到目的端网络路由的总体情况,

    如:

    根据这个显示结果,我们知道从客户端到目的端网络总共7跳,也就是经过了6个路由器转发,用户端到每个路由器的延时也标明在每一跳中。因此,我们就能够知道,从用户端到目的端,哪个环节延时大,延时大的地方带宽窄,网络拥挤。

     

    只有使用上面这两个命令,正确测试 网络到服务器之间的参数,控制在许可范围,用户使用趣聊客户端在音频和视频效果中才可以得到保障。但是,减小延时,需要提高贷款,这涉及到运营商大网和宽带租用费等多问题,减小延时不是一件简单的事情。所以,用户在选择提供宽带接入的运营商时,是需要慎重选择的。这是觉得你的趣聊效果最关键的因素。

  • ping命令测试网络丢包率

    cutebeckyex 发布于 2010-02-03 13:49:50

    ping命令的参数如下:

    当需要对指定IP地址进行链路丢包率测试时,要使用的参数是[-n count -l size]
    -n count 是发送由 count 指定数量的 ECHO 报文,默认值为 4
    -l size  是发送由 size  指定大小的 ECHO 报文,默认值为 32byte
     
    例: ping -n 4 -l 300 10.1.1.1
    发送4次大小为 300byte 报文到IP地址为:10.1.1.1
    根据得出的结果来判断网络链路的丢包率

531/3123>
staunch0442

staunch0442

从事软件测试工作已经一年多了,发现越来越喜欢软件测试这个工作了...

数据统计

  • 访问量: 24648
  • 日志数: 34
  • 书签数: 1
  • 建立时间: 2008-07-11
  • 更新时间: 2016-06-30

RSS订阅

Open Toolbar