发布新日志

  • 四月了

    2009-04-03 12:53:48

     不知不觉已经上班两个月了,第三个月也已经开始了。

       在过去的两个月中,想想也没做什么事情,项目组里报表开发完了,我就跟另一个同事开始做测试,测试留的时间比较充足,说是充足,其实是不知道该什么时候结束,因为没有人做测试的计划,项目开始开会的时候说测试最后要做交叉测试,但是具体的计划没人做,感觉是测试没怎么重视,测试用例就更不用说了,也是没有的,也没人要求我们这俩个测试做,开始测试的时候,是项目经理把测试站点发给我说你测吧,就开始测试了。

      我测试有一周的时间 ,感觉我测得那几张报表已经没有什么问题了 ,就主动地开始交叉测试了,又测了两三天的样子,项目经理说,测得差不多了,就不测试了。

      现在没什么事情了,项目马上要给客户上线了,我又开始搞我的qtp,发现qtp已经过期不能用了,卸了装,装了卸,就是不能用,破解文件在我的系统下面不起作用,真是急人啊!最后没办法重装了系统,也只能试用14天,为什么在我的系统下不能执行破解文件呢,真是郁闷,有哪位大侠指点指点呢。

      以后不管有没有人让我写测试用例,我都要坚持写,算是充实自己吧。自己要努力吧测试的流程走完,要不在这个比较轻松的公司里一直这样轻松下去,不知道以后要是跳槽,还有没有人要。

    上传以下我写的测试用例。呵呵

  • 测试报告的编写(转)

    2009-03-19 15:17:05

    测试总结和报告

            测试人员的工作通常并不像开发人员那样能直接体现出来,让大家一目了然。开发人员做的是建设性的工作,如开发了哪些功能,写了几行代码,设计了几个类,都能直观地看到,而且,通过软件能很鲜活地演示开发人员的工作成果。
            但是测试人员的工作相对隐蔽一点,测试人员做的是破坏性的工作,并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说:“你们做测试的真好,整天坐在那里”。当然,这是外行人看内行时说的话,但是给笔者的一个启示是:测试人员需要更多地表现自己,展现自己的工作成果。
            说明:由于缺陷列表太细、太大,测试用例过于专业,很多人对其不感兴趣,因此
    测试报告能很好地展示自己的工作状况,测试报告是提供给很多人看的一份文档。

            下面是一个项目的测试报告的纲要:
    1 简介
    1.1 编写目的
    1.2 项目背景
    1.3 术语和缩略词
    1.4 参考资料
    2
    目标及范围
    2.1 测试目的及标准
    2.2 测试范围
    3 测试过程
    3.1 测试内容
    3.2 测试时间
    3.3 测试环境
    3.4 测试方法及测试用例设计
    4 测试情况分析
    4.1 测试概要
    4.2 测试用例执行情况
    4.3 缺陷情况
    4.4 测试覆盖率分析
    4.5 产品质量情况分析
    5 测试总结
    5.1 测试资源消耗情况
    5.2 测试经验总结
    6 附件
    附件1 测试用例清单
    附件2 缺陷清单
    一、缺陷分类报告
            缺陷分类报告是测试报告的重要组成部分,可以再细分为:缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
    1.缺陷类型分布报告
            缺陷类型分布报告主要描述缺陷类型的分布情况,看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意,并分析缺陷为什么会集中在这种类型。例如,如果缺陷主要是界面类型的,如界面提示信息不规范、界面布局凌乱等问题,那么就要讨论是否需要制定相应的界面规范,让开发人员遵循,从而防止类似问题的出现。
    缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示,用饼图表示了几种类型的缺陷各自所占的比例。

    图  缺陷分布报告


    三、典型缺陷与Bug模式
            软件开发有设计模式,
    测试其实也有模式存在,需要测试人员进行总结和归纳。测试人员应从经常出现的Bug中学习,总结出Bug模式,用于指导测试。如果开发人员能关注这些Bug模式,还能起到预防错误的效果。
            要成为典型缺陷,必须满足以下条件:
            重复出现、经常出现;
            能代表某种类型的错误;
            能通过相对固定的测试方法或测试手段来发现这些错误。
            总结这些典型缺陷出现的现象,出现的原因,以及测试方法,就能成为一个Bug模式。

            说明:根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等,可以总结出不同的Bug模式,不同的Bug模式可能在不同的平台、语言、产品类型中才会出现。测试人员应该总结适合自己项目特点的Bug模式。

            提炼Bug模式的一般步骤如下:
            步骤1:分析缺陷报告,找出经常出现的Bug类型。
            步骤2:分析Bug的根源,找出Bug产生的深层次原因。
            步骤3:分析找到Bug的方法,总结如何才能每次都发现该类型的Bug。
            下面举一个例子来说明这个过程。
            首先,测试人员在分析缺陷报告时发现,有一类Bug经常出现,并且错误现象一致:执行某功能时提示Time Out。
            测试人员与程序员一起分析原因,发现这些错误都是在操作
    数据库时发生,发送的SQL语句被数据库长时间执行未返回,因此提示Time Out。通过进一步地分析表明,.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前的等待时间。等待命令执行的时间(以秒为单位)默认为30s,而数据库操作在较大数据量的情况下一般都超过这个时间,因此会提示超时的错误信息。
            这样就可以把这种类型的Bug归纳为“数据库操作超时Bug模式”。
            那么,如何才能找出这样的Bug呢?一般情况下,这类Bug基本上不会出现,只有数据量足够大时才会出现,因此需要设置大批数据,结合
    性能测试或压力测试来发现此类问题。也可以通过白盒的方式,查找程序在使用SqlCommand时是否合理地设置了Command TimeOut属性,这样将更有针对性地揭露上述的错误。
            至此就完成了一个Bug模式的归纳、提炼和总结,如果程序员积极地参与到该总结和分析过程中来,则可形成一个良性的反馈,当下次程序员编写相同的程序时就会避免类似的错误发生。
    四、测试中的PDCA循环
            PDCA循环是一种放之四海皆准的原则。在
    软件测试的过程中,也充斥着各种PDCA循环。PDCA循环是一个自我完善和改进的全闭环模型,如图7.34所示,对质量的不断提高和改进非常有效。

      PDCA循环模型



    软件测试技术
            在外行人看来,软件测试其实没什么技术可言,甚至有人认为测试无非是在摆弄一下软件的功能,只要懂得使用鼠标就足够了,这是对软件测试的一种误解。
    1. 
    黑盒测试白盒测试
            很多测试人员喜欢讨论黑盒测试与白盒测试的区别,也有些测试人员感觉白盒测试很神秘,很高深,自己没有足够的开发能力是不可能进行白盒测试的。
    那么什么是黑盒测试,什么是白盒测试呢?下面对此进行简单介绍。
    1.1黑盒测试
            黑盒测试是一种把软件产品当成是一个黑箱的
    测试技术,这个黑箱有入口和出口,测试过程中只需要了解黑箱的输入和输出结果,不需要了解黑箱里面具体是怎样操作的。这当然很好,因为测试人员不用费神去理解软件里面的具体构成和原理,测试人员只需要像用户一样看待软件产品就行了,如图1所示。

    图1  黑盒测试方法


            例如,银行转账系统提供给用户转账的功能,则测试人员在使用黑盒测试方法时,不需要知道转账的具体实现代码是怎样工作的,只需要把自己当成用户,模拟尽可能多的转账情况来检查这个软件系统能否按要求正常实现转账功能即可。
            如果只像用户使用和操作软件一样去测试软件黑盒测试可能存在一定的风险。例如,某个安全性要求比较高的软件系统,开发人员在设计程序时考虑到记录系统
    日志的必要性,把软件运行过程中的很多信息都记录到了客户端的系统日志中,甚至把客户端连接服务器端的数据库连接请求字符串也记录到了系统日志中,像下面的一段字符串:

    "Data Source=192.168.100.99;Initial Catalog=AccountDB;User ID=sa;PassWord=123456;

            那么按照黑盒测试的观点,这是程序内部的行为,用户不会直接操作数据库的连接行为,因此检查系统日志方面的测试是不会做的。这明显构成了一个Bug,尤其是对于安全性要求高的软件系统,因为它暴露了后台数据库账号信息。
            有人把黑盒测试比喻成中医,做黑盒测试的测试人员应该像一位老中医一样,通过“望、闻、问、切”的方法,来判断程序是否“有病”。这比单纯的操作黑箱的方式进了一步,这种比喻给测试人员一个启示,不要只是简单地看和听,还要积极地去问,积极地去发现、搜索相关的信息。应该综合应用中医看病的各种“技术”和理念来达到找出软件“病症”的目的,具体作法如下:
    &61548; “望”,观察软件的行为是否正常;
    &61548; “闻”,检查输出的结果是否正确;
    &61548; “问”,输入各种信息,结合“望”、“闻”来观察软件的响应程度;
    &61548; “切”,像中医一样给软件“把脉”,敲击一下软件的某些“关节”。

    1.2白盒测试
            如果把黑盒测试比喻成中医看病,那么白盒测试无疑就是西医看病了。测试人员采用各种仪器和设备对软件进行检测,甚至把软件摆上手术台解剖来看个究竟。白盒测试是一种以理解软件内部结构和程序运行方式为基础的软件测试技术,通常需要跟踪一个输入经过了哪些处理,这些处理方式是否正确,这个过程如图2所示。

    图2  白盒测试方法

            在很多测试人员,尤其是初级测试人员看来,白盒测试是一种只有非常了解程序代码的高级测试人员才能做的测试。熟悉代码结构和功能实现的过程当然对测试有很大的帮助,但是从黑盒测试与白盒测试的区别可以看出,有些白盒测试是不需要测试人员懂得每一行程序代码的。
            如果把软件看成一个黑箱,那么白盒测试的关键是给测试人员戴上一副X光透视眼镜,测试人员通过这副X光透视眼镜可以看清楚输入到黑箱中的数据是怎样流转的。
            一些
    测试工具就像医院的检测仪器一样,可以帮助了解程序的内部运转过程。例如,对于一个与SQLServer数据库连接的软件系统,可以简单地把程序的作用理解为:把用户输入的数据通过SQL命令请求后台数据库,数据库把请求的数据返回给程序的界面层展示给用户。可以把SQL Server自带的工具事件探查器当成是一个检查SQL数据传输的精密仪器,它可以记录软件客户端与服务器数据库之间交互的一举一动,从而让测试人员可以洞悉软件究竟做了哪些动作。
            在测试过程中,应该综合应用黑盒测试方法和白盒测试方法,按需要采用不同的技术组合。不要用黑盒测试方法和白盒测试方法来划分自己属于哪一类测试人员,一名优秀的测试人员应该懂得各种各样的测试技术和查找Bug的手段。


  • 如何写出高质量的bug单(转载)

    2009-03-19 14:45:22

    如何写出高质量的Bug

      程序员是否经常让你在Bug单上再提供一些更多的信息?当Bug单提交后,你是否经常会再花很多时间来研究如何重现这个Bug?你是否经常听到开发人员说Bug在开发环境下无法重现?问题在于Bug单的质量不高,我们应该花更多的时间在研究如何测试系统上,而不是花更多的时间在Bug单上,本文就如何写出高质量的Bug单提出了一些建议。

      为什么要写Bug单

      当我们发现Bug后,需要通知开发人员,Bug单是一种沟通的介质,它的主要目的是让开发人员能够亲眼看到这个Bug是什么,如果不提供足够详细的说明来帮助开发人员重现Bug,那么他们就没法确定问题的根源。Bug单是一种用来说明期望结果和实际结果之间的差异以及描述bug如何重现的文档。

      发现Bug后应该做什么

      · 最好是一发现并确认了bug就立即填写Bug单,而不要等到当天测试结束再和其他bug一起填,因为那时就有可能遗漏一些要点,甚至是遗漏某个bug。

      · 花点时间分析一下造成Bug的根本原因是什么,你可能会因此发现更多的Bug,最好能把你的任何有用的证据都写到Bug单上。

      · Bug单提交之前自己再读一遍,可能会有错别字或者什么写错的地方需要重写。

      下面将谈到填写Bug单时应注意的几个地方:

      摘要(概述)

      Bug单的“摘要”部分是一个Bug单带给读者的最初印象,它在浏览大量Bug时起着非常重要的作用,每个Bug单都应该有一个能够突出重点的“摘要”,就好像做广告一样。好的摘要应该控制在50~60个字符以内(一个汉字算两个字符),而且不要夹杂任何主观色彩的文字。

      措辞

      · 要据实反应情况,不要夸大或缩小Bug的影响。

      · 有时候会发现一些令人不可思议的低级Bug,但还是要尽量使用较为委婉的词语来表述,免得伤害开发人员的自尊心。

      · 描述越简单直接越好,我们不是在写论文或散文,所以不要把Bug单搞得那么复杂难懂。

      · 要考虑到目标读者,他们可能是开发人员、测试人员、管理人员或者其他人,甚至是客户,所以要让目标读者都能看得懂Bug描述。

      重现的步骤

      · 每一步以及所有步骤组合起来应该是符合逻辑的。

      · 清晰地列出所需的前置条件。

      · 描述一般性的步骤,例如,某一步骤需要用户新建一个文件并给它命名,那就不要写“新建一个名为Mike’s File的文件”,而最好写成“新建一个测试文件TestFile”。

      · 步骤应尽量详细,例如,我们要描述通过MS WORD保存一个文档,那么有两种方式,一是说得细点儿,即“从[文件]菜单里单击[保存],……”,另一种就是说得简单点,即“保存文档”,但请记住,并非所有人都知道如何从MS WORD保存文档,或者说所有人都会使用同样的方式保存文档,所以描述的时候最好还是采用第一种方式。

      · 写完之后自己用新的测试数据或者在新的系统上按照步骤亲自执行一遍,或许能够发现Bug单里有一些是遗漏的或多余的步骤。

      测试数据

      开发人员重现Bug时可能不会访问测试环境,有些Bug可能只能用一定的测试数据才能重现,所以尽量把测试数据附在Bug单上。

      屏幕截图

      屏幕截图是Bug单里非常重要的组成部分,有时一张图能胜过千言万语,但也不能养成习惯不管有用没用的图都往上贴,或者是只贴图而缺少文字描述。附图能够使开发人员结合你的描述快速地重现Bug是最理想的:

      · 所附图片的尺寸和占用空间不要太大,尽量用jpg或gif格式,而不要用bmp格式。

      · 在图中出问题的地方标注一下,更利于开发人员快速定位。

      严重级/优先级

      · 设置Bug的严重级之前,应该全面地分析Bug的影响,如果我们认为这个Bug的优先级很高,那么应该在Bug单里说明优先级高的原因。

      · 如果Bug是由于程序版本恢复到上一版而产生的,那么不管它的严重级如何,它的优先级应该置成“高”。

      日志

      如果可以的话一定要把程序报错的日志附上,这会让开发人员比较容易进行分析和调试。很多不能重现的Bug都是因为缺少日志,开发人员就会返回去找测试人员要日志信息。如果日志文件不大的话,比如十几行,那么可以直接把日志信息粘到Bug单里,如果日志很大的话,那么最好单独粘到一个文件里,如txt格式的,然后当作Bug单的附件就可以了。

    转载地址:http://www.51testing.com/?uid-130702-action-viewspace-itemid-110722
  • 日志 [2009年03月19日](转)

    2009-03-19 14:37:29

    水因地而制行,兵因敌而制胜——测试感悟(针对手动、黑盒)

    北大方正技术研究院 李守亮

    1999年6月

    编者按:这是一篇好文章,不在于他的文笔,而在于他的用"心"工作,用心总结。是他的工作经验和心路历程的记录,值得大家学习

    一直以来,总想写一写关于测试方面的文章。今天,真的接到这个题目时,却欲言又止,迟迟不能落笔。在这里,我也只将自己的实际经验介绍给大家,抛砖引玉,和大家共同探讨。

    刚开始做测试的同事会有一种感觉,认为测试实际上是在充当这个产品的第一用户。也有人认为,测试其实很简单,没有什么技术可言。

    其实,测试说易也易,因为进入门槛低;说难也难,因为测深测精不简单。黑盒测试很讲究策略,测试也是一门学问。

    初涉测试的心路历程

            对测试的认识,每个测试人员都有一个过程。我对测试的认识,在每个阶段各不相同,其中也走了不少弯路。在此,我用第三人称把自己对测试工作的认识过程写出来,希望后来的同事能从中得到启发。

    第一阶段学习+验证

    对于新来的同事,刚刚涉及测试,往往踏不下心来。感觉测试是件没完没了地事情,并且单调重复、枯燥乏味,没有激情、没有成就感。这是很正常的现象,刚进入一个新的岗位,总有一个适应过程。

    在这一阶段,新员工需要做的事情是,先学会使用所测的软件,熟悉他的每一个功能,弄清楚每一个功能的正确效果应该是什么?然后才开始尝试着去找一些肤浅的问题。这一阶段的感觉是:"测试实际上就是验证产品每个功能的有效性"。新员工这一阶段虽然不太出成绩,但却很重要,因为这是以后工作的基础。

    第二阶段与开发对立的误区

       当熟悉了所测产品的功能,并且找到测试的感觉后,就开始较深入地测试了。

    在这一阶段,新员工会逐渐发现一些严重的BUG。当看到自己发现的问题被解决后,才真正感觉到自己在参与产品的生产。渐渐地,渐渐地,就会感觉到测试其实也挺有趣。尤其是发现一些死机或特别严重的错误时,有时会兴奋上几个小时。这是他进入状态的必然过程。

    此时,他对测试的认识是:"测试,就是要找出产品的缺陷,是证明当前产品不可用的一种行为"。这一阶段非常值得注意!很多软件公司常说:"开发和测试的行为是对立和矛盾的",这实际上是测试工作的误区。

    第三阶段与开发主动配合

       随着测试经验的积累,对工作的认识也逐步深入。最后,他会发现,开发和测试之间,本质上是一个合作的过程,目标本是一致的。都是为了尽量减少发布产品中的错误,达到用户可接受的程度。于是,他会更多地站在用户角度考虑问题,测试的目的也越来越明确,工作也越来越主动。

    第四阶段责任感+验证

       当经历了产品的几个生命周期之后,从不断的需求、开发、维护、升级循环过程中,逐渐认识到,测试实际上是降低产品风险的一种行为。逐步认识到,测试介入的环节越早,风险也就越小。

    在和最终用户多次打交道,亲身体验用户的心情之后,油然而生出一种强烈的责任感,对测试的理解也随之升华为一种产品意识:测试工作和研发工作,实际上是一种荣辱与共的关系,取得的成绩和造成的失误,其荣誉和责任是同等的。此时,当他发现一个致命的错误或缺陷时,第二阶段的那种兴奋也许只会存在3秒钟。此时的他,更多考虑的是怎样帮助研发组尽快地把该问题解决掉。在这一阶段,测试工作中更注重产品的实用性和易用性。

       从学习阶段对产品的验证,到与研发的对立,到主动地和研发配合,到一种责任感使命感自发地对功能的验证,这是一个高级测试人员所必然要经历的一个心路历程。  

    测试中的几种思维方式

       测试能否出成绩?以及测试工作的优劣,与个人的素质和修养有关。

    测试工作说易也易,只要认真、负责,就能做出一些成绩。但说难也难,测试讲究很多方法和策略,要测的精,问题定位的及时准确,规律找的准确有效,那是需要下一番功夫的。在此,我把测试中常用的几种思维方式共享如下:  

    正向思维  

             在测试一个产品之前,需要做的重要事情是,熟读产品的设计文档,详细了解每个功能的正确效果。然后针对每个模块,顺着程序员的思路,逐个验证,以验证测试功能的有效性。这是以后深入测试的基础,也是做自动测试的前提。

             搞清楚每个模块是干什么的,弄清楚正确的效果,才知道什么是错误的。这是非常关键的一个环节,如果在这方面不下功夫,也就很难测试出有价值的BUG。因为,很明显的错误结果可能就在你眼前大摇大摆地经过,而你却认为这是正确的!我就曾经一度陷入这一误区,好在很快地补上了这一课。  

    逆向思维  

             关于"逆向思维",我有两种解释,一是针对开发人员。

    开发人员在调试或自测时,总爱顺着已有的思路进行。所以,在很多情况下容易忽略自己所犯的错误,例如边缘条件检查,异常处理等等。所谓当局者迷,旁观者清,是因为你可以跳出他的思维定式,从另外的角度来思考问题。所以,只要你肯动脑筋,不按他的逻辑进行检测,就一定能找出许多破绽。  

    关于"逆向思维"的第二种解释,是针对具体问题。

    当发生严重问题时,首先要保护好现场,然后努力地回忆,努力地理清思路。要善于从错误现象的最后一步往前倒推。例如死机问题,仅一个现象并不能说明问题,关键要找出它的规律。规律有时是最后一步操作导致,而有时则是前几十步操作的累加,这需要我们追忆刚才的几十步操作,并大胆怀疑其中的疑点,有目的的undo、redo。这一招叫顺藤摸瓜,抓住规律的尾巴,从最后一步开始。  

    跳跃性思维  

             我也称它为联动思维。

    有时,一个问题表现出来的现象和问题的本质会差着十万八千里,这类问题的规律也极难准确地捕捉到。处理这类问题,需要有扎实的测试基本功,并对产品非常地熟悉,才能把表面上毫不相关,却有着千丝万缕关系的孤立的两点联系起来;才能从一处错误得到启示,联想到其他模块也可能存在类似的问题......  

    关于测试技巧  

    黑盒测试,尤其是手工黑盒测试的业绩,有七成决定于个人因素。

    测试需要有高度的责任心和使命感,要有主人翁精神。任何工作只有敬业才能做出成绩,工作主动了,自然会得到回报。  

    在很多情况下,问题的现象出现了,但规律却不明显。当问题提交后,在开发那里却死活不能重现,这种情况是很尴尬和无奈的。所以,作为一个出色的测试工程师,仅仅捕获到问题的现象是远远不够的,还要找到其规律,甚至弄懂它更深层次的原因。

    遇到这类问题怎么办?很多人可能就此放弃了,因为说他是"无规律或不能重现事件"。在我看来,这种说法是错误的。我认为,一定要树立起一个观念,那就是:"任何错误的出现,都绝不是偶然的。每个错误现象背后都隐含着一个必然的规律,不管是肤浅的,还是深奥的。"而测试的目的,就是要把这个规律挖出来。因为,规律总结得越准确,对问题的定位和解决帮助就越大。  

             做好测试工作必须要做到几条:首先,要努力培养起对测试的兴趣;要培养对所测产品的感情,要像对待自己孩子一样去热爱它,呵护它。其次,要胆大并心细。要有游走于高山峡谷边缘的那种"如临深渊,如履薄冰"的胆量和谨慎。要敢于怀疑,大胆假设而小心求证。再次,要有耐心,戒骄戒躁,心要安静。  

    如果说测试有技巧的话,也仅占到三成:

             1、对待问题要锲而不舍,并善于总结经验。

             举一个案例,对于"方正飞腾(报社专用排版软件)自动勾边死机问题"规律的发现,我现在还记忆犹新。我1997年刚接触这款软件时就遇到了该问题,但问题变化无常,当时找不到一点儿规律:有时,在关键位置点一下鼠标就死,有时点100多次才死,有时怎么点都不会死。该问题整整困扰了我一年,直到有一天,我盯着屏幕发呆,发现鼠标变成了漏斗,我随便点了一下<调整>按钮,程序立刻死机。当时灵机一动,莫非跟"自动存盘"有关?判断是正确的!一年来的谜终于被解开了,而受此启发,后来遇到"非法字体窗口"、"自动翻页"、以及"删除表格"所引发的死机,不到1秒的时间,我就准确定位与自动存盘有关。  

             对于疑难问题,不妨先放他一放,过几天再去想,说不定就会有新思路冒出来,有新灵感被激发出来。对于每一个解决的疑难问题,都要认真分析它的原因,总结定位经验,并推演联想到其他模块。测试过程是一个循序渐进的过程,是一个经验积累的过程。以一年的摸索换来若干个一秒钟的思索,值!还有很多典型案例,限于篇幅,不便罗列。  

             2、善于推理,善于运用逆向思维。善于换位思考,变换角色对待问题;

             3、善于和别人共享经验,站在别人已有的思路上进一步深入,多动脑筋,多动手。

             4、简化问题规律的步骤,弄清楚问题产生的原因,总结程序员的教训,对类似问题可以触类旁通。

             5、不断地怀疑,不断地推翻怀疑。突破跳出思维定式,大胆假设,小心求证。  

    将军围猎  

    曾经在文字所和测试中心流传一句话:"软件里的bug如同海绵里的水,要想挤总会有的"。旧bug的修改往往会引发新bug的产生,所谓"按下葫芦起来瓢"。  

    如何培养测试人员的对测试工作的兴趣呢?不妨把bug比作藏匿在深山丛林中的猎物,把自己比作围猎的将军。程序中的bug变化莫测,要有将军指挥作战的气度,怎样更快更准更有效地定位它们,捕获住它们?围追堵截之中,尽显英雄本色。  

    兵法上说,水因地而制行,兵因敌而制胜。兵无常势,无恒形,能与敌变化而取制者,谓之神。仅仅通过黑盒测试,你就能知道程序员做了什么改动?怎样做的改动?还存在什么缺陷?并快速准确地把它定位出来。若能达到这种境界,让你的思维能力受到如此的锻炼和考验,难道还不会有成就感么?  

    当你全身心地投入在测试中,你会感觉到测试,实际上是一场智力游戏。所谓"气痴者技精",因为一进入状态,坐下来就会忘记时间的流逝。


  • 测试转管理(转)

    2009-03-06 16:07:45

    中层经理人不论是作为一名执行者、还是一名领导者,都必须通过别人来完成任务。要做个“服众”的经理人,应该有意识地提高以下八项能力:

    1. 领悟能力
    做任何一件事以前,一定要先弄清楚上司希望你怎么做,然后以此为目标来把握做事的方向,这一点很重要,千万不要一知半解就开始埋头苦干,到头来力没少出、活没少干,但结果是事倍功半,甚至前功尽弃。要清楚悟透一件事,胜过草率做十件事,并且会事半功倍。

    2. 计划能力
    执行任何任务都要制定计划,把各项任务按照轻、重、缓、急列出计划表,一一分配部属来承担,自己看头看尾即可。把眼光放在部门未来的发展上,不断理清明天、后天、下周、下月,甚至明年的计划上。在计划的实施及检讨时,要预先掌握关键性问题,不能因琐碎的
    工作,而影响了应该做的重要工作。要清楚做好20%的重要工作,等于创造80%的业绩。

    3. 指挥能力
    无论计划如何周到,如果不能有效地加以执行,仍然无法产生预期的效果,为了使部属有共同的方向可以执行制定的计划,适当的指挥是有必要的。
    指挥部属,首先要考量工作分配,要检测部属与工作的对应关系,也要考虑指挥的方式,语气不好或是目标不明确,都是不好的指挥。而好的指挥可以激发部属的意愿,而且能够提升其责任感与使命感。要清楚指挥的最高艺术,是部属能够自我指挥。

    4. 控制能力
    控制就是追踪考核,确保目标达到、计划落实。虽然谈到控制会令人产生不舒服的感觉,然而企业的经营有其十分现实的一面,有些事情不及时加以控制,就会给企业造成直接与间接的损失。但是,控制若是操之过急或是控制力度不足,同样会产生反作用:控制过严使部属口服心不服,控制不力则可能现场的工作纪律也难以维持。要清楚最理想的控制,就是让部属通过目标管理方式实现自我控制。

    5. 协调能力
    任何工作,如能照上述所说的要求,制定完善的计划、再下达适当的命令、采取必要的控制,工作理应顺利完成,但事实上,主管的大部分时间都必须花在协调工作上。协调不仅包括内部上下级、部门与部门之间的共识协调,也包括与外部客户、关系单位、竞争对手之间的利益协调,任何一方协调不好都会影响执行计划的完成。要清楚最好的协调关系就是实现共赢。

    6. 授权能力
    任何人的能力都是有限的,作为高级经理人不能象业务员那样事事亲历亲为,而要明确自己的职责就是培养下属共同成长,给自己机会,更要为下属的成长创造机会。孤家寡人是成就不了事业的。部属是自己的一面镜子,也是延伸自己智力和能力的载体,要赋予下属责、权、利,下属才会有做事的责任感和成就感,要清楚一个部门的人琢磨事,肯定胜过自己一个脑袋琢磨事,这样下属得到了激励,你自己又可以放开手脚做重要的事,何乐而不为。切记成就下属,就是成就自己。

    7. 判断能力
    判断对于一个经理人来说非常重要,企业经营错综复杂,常常需要主管去了解事情的来龙去脉因果关系,从而找到问题的真正症结所在,并提出解决方案。这就要求洞察先机,未雨绸缪。要清楚这样才能化危机为转机,最后变成良机。

    8. 创新能力
    创新是衡量一个人、一个企业是否有核心竞争能力的重要标志,要提高执行力,除了要具备以上这些能力外,更重要的还要时时、事事都有强烈的创新意识,这就需要不断地
    学习,而这种学习与大学里那种单纯以掌握知识为主的学习是很不一祥的,它要求大家把工作的过程本身当作一个系统的学习过程,不断地从工作中发现问题、研究问题、解决问题。解决问题的过程,也就是向创新迈进的过程。因此,我们做任何一件事都可以认真想一想,有没有创新的方法使执行的力度更大、速度更快、效果更好。要清楚创新无极限,唯有创新,才能生存。
     
     
    领导力更需提升

    一个部门经理提高完成任务执行力的过程,其实也就是提高自身对部门员工领导力的过程。因为要提高执行部门的执行力,不是光靠经理一人所能完成的,而是要靠带领部门所有员工的共同努力才能完成的。
     
    如果你是测试员或是高级测试员,有志转向管理发展,那么需要加强以下几点:

    1. 测试计划的编写(要结合测试的项目,能以此来控制和确定测试所需人员,设备及时间来管理测试时间)

    2. 要熟悉
    BUG跟踪工具及软件测试流程.(如: TD, Bugzilla, CQ等)

    3. 要熟悉
    配置管理工具. (如: CVS, VSS等)

    4. 要熟悉自动化工具.(例如:WinRunner,
    QTP, Robot, RFT, Automation等,能结合录制完的脚本编写代码)

    5. 要熟悉压力及
    性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分析出性能瓶颈)

    6. 要熟悉或精通一门语言. (例如: Java, C++)

    7. 要熟悉
    数据库.(例如: Oracle, DB2, SQLServer, MySQL)

    8. 要熟悉主流
    操作系统. (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux, Windows)

    9. 能用英文流利的和老外交流以及往来Email.

    10. 语言表达能力强,表达问题清晰明了.

    11. 沟通能力强,能和上级/开发经理很好的达成测试相关/BUG事宜.

    12. 学习技术的能力要强,能快速上手一个新的技术.

    13. 乐于与人交流.
  • qtp dictionary 问题

    2009-02-20 14:57:38

    setFileExcel ="E:\中交测试脚本\loan.xls"
    sheet_name ="loan"
    Call datatable.AddSheet(sheet_name)
    Call datatable.ImportSheet (setFileExcel,sheet_name,sheet_name)
     rows =datatable.GetSheet (sheet_name).GetRowCount
    set  valus =CreateObject("Scripting.Dictionary")
     
    For i=1 to rows
     DataTable.SetCurrentRow (1)
      For j=1 to 10
       str =datatable.Value(j,sheet_name)
             valus .Add Cstr(j),str                         
      Next
    Next

    其中加红的地方在保存的时候老是提醒又错误,但是我找不出什么错误,请帮我找找!

  • 情人节

    2009-02-14 11:31:59

       今天是情人节,正赶上周六,应该是个不错的日子,昨天就看到公司的一位同事,抱着一大束玫瑰进了公司,真是羡慕啊!可是我好像对花尤其是玫瑰花没有什么特别的喜好,对我来说在情人节收不收到玫瑰花都是无所谓的,记得去年情人节,我硬是要老公给我没了只玫瑰,手里拿着她走在路上还有些不好意思。呵呵。
       其实情人节对我来说真是无所谓了,不过还是希望有情人终成眷属。

     
  • qtp导入excel

    2009-02-13 15:49:39

    SetExcelFile="E:\logininfo.xls"
    Call datatable.AddSheet("login_check")
    Call datatable.AddSheet("transferinfo")
    Call datatable.ImportSheet(SetExcelFile,"login_check","login_check")
    Call  datatable.ImportSheet(SetExcelFile,"transferinfo","transferinfo")

    '得到某个sheet的行数
     sheetcount =DataTable.getsheet("login_check").GetRowCount
     Reporter.ReportEvent 0,"sheetnumber" ,"there are "&sheetcount&" sheets in the sheet"

  • 09年的计划

    2009-02-11 13:33:41

      上班已经有一周的时间了,公司还没有给我安排具体的工作,我还是处于游离的状态,但是我计划做测试,以前做开发了,觉得不怎么样,想学一下测试,尤其是自动化测试,从现在开始我要自己学习自动化测试。

      生活上因为有个宝宝,所以工作之余的精力要全部放到宝宝身上。

      今年一定要早公司好好干,因为好长时间在家照顾孩子,没有了工作的压力,现在特别想找回工作的激情。

      还有就是以后要坚持写博客,这样可以把子的思想,思绪好好的梳理一下,不至于工作的一团糟,忙了一年,回过头来都不知道自己在忙什么。自从上了大学就再也没怎么写过东西,即使有写的冲动,想想就懒得写了,以至于大学四年活得没有头绪。写作真的很锻炼人的思维,能使人的头脑变得清晰。

      最后真的希望自己能坚持写下去。

  • 序言

    2009-02-11 13:16:46

        

     决定做测试了,先申请个博客,记录以后的点点滴滴。

数据统计

  • 访问量: 3545
  • 日志数: 11
  • 建立时间: 2009-02-11
  • 更新时间: 2009-06-23

RSS订阅

Open Toolbar