热爱测试生活

发布新日志

  • 项目管理的三个重要控制点:检查点、里程碑、基线

    2009-01-19 11:29:49

    这三个概念分别是 检查点( CheckPoint )、里程碑( Mile Stone )和基线( Base Line ),他们一起描述了在什么时候( When )对项目进行什么样控制。

      检查点

      指在规定的时间间隔内对项目进行检查,比较实际与计划之间的差异,并根据差异进行调整。可将检查点看作是一个固定 “ 采样 ” 时点,而时间间隔根据项目周期长短不同而不同,频度过小会失去意义,频度过大会增加管理成本。常见的间隔是每周一次,项目经理需要召开例会并上交周报。

      里程碑

      完成阶段性工作的标志,不同类型的项目里程碑不同。里程碑在项目管理中具有重要意义,我们用一个例子说明

      情况一你让一个程序员一周内编写一个模块,前 3 天你们可能都挺悠闲,可后 2 天就得拼命加班编程序了,而到周末时 又发现系统有错误和遗漏,必须修改和返工,于是周末又得加班了。

      情况二实际上你有另一种选择,即周一与程序员一起列出所有需求,并请业务人员评审,这时就可能发现遗漏并即 时修改;周二要求程序员完成模块设计并由你确认,如果没有大问题,周三、周四就可让程序员编程。同时自己准备测试案例,周五完成测试;一般经过需求、设计确认,如果程序员合格则不会有太大问题,周末可以休息了。 第二种方式增加了 “ 需求 ” 和 “ 设计 ” 两个里程碑,这看似增加了额外工作,但其实有很大意义首先,对一些复杂的项 目,需要逐步逼近目标,里程碑产出的中间 “ 交付物 ” 是每一步逼近的结果,也是控制的对象。如果没有里程碑,中间 想知道 “ 他们做的怎么样了 ” 是很困难的。其次,可以降低项目风险。通过早期评审可以提前发现需求和设计中的问 题,降低后期修改和返工的可能性。另外,还可根据每个阶段产出结果分期确认收入,避免血本无归。第三,一般人 在工作时都有 “ 前松后紧 ” 的习惯,而里程碑强制规定在某段时间做什么,从而合理分配工作,细化管理 “ 粒度 ” 。

      基线

      指一个(或一组)配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态。基线其实是一些 重要的里程碑,但相关交付物要通过正式评审并作为后续工作的基准和出发点。基线一旦建立后变化需要受控制。

      重要的检查点是里程碑,重要的需要客户确认的里程碑,就是基线。在我们实际的项目中,周例会是检查点的表现形式,高层的阶段汇报会是基线的表现形式。

  • 转载—新加入一个团体,如何尽快的展开测试工作?

    2009-01-16 11:28:45

    新加入一个团体,如何尽快的展开测试工作?

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      作为一名测试新人加入团队,大多数情况下,项目组成员都是一种热情欢迎的态度,并且主动提供力所能及的支持和帮助,如何快速熟悉项目业务和测试环境,尽快投入到实际工作中去,我谈谈个人的经验和一些看法,供同行参考:

      1、寻找新公司的团队元老:

      一般来说,一个新人进入新公司,都要指定一个师傅带一段时间,这也就是我们说的测试前辈。很多时候,测试前辈都是经验非常丰富的测试高人,如何您和他相处融洽,关系不错,凭他个人丰富的业务经验,给您指点迷津,也许会比你自己摸索10倍的时间效果还好。很多的测试新手,刚进入新公司时,自高自大,眼高收低,测试前辈都不愿意交,结果到了试用期转正答辩的时候,一问三不知,被迫离开公司,被炒鱿鱼。这样的例子我看到的不下于10例,很可惜丢失了很多工作机会。

      2、虚心的学习态度:

      刚到一家新公司,保持谦虚的学习态度非常必要。记得我刚毕业那年,公司招聘了一个测试主管,他有4到5年的工作经验,阅历算是不简单,也是我们心目中的牛人吧。但是那个人,除了听总监的话以外,对于我们部门的其它人来说,他简直是自高自大,目中无人,根本不把部门里的其他人放到眼里,觉得部门的人都不如他。他作为一个空降兵,老员工和新员工,对他都很冷漠,碰到什么问题,需要小组成员帮忙的时候,大家都不愿意帮助他,互相推诿,并且经理也找他谈了几次话,效果不明显,结果他呆了不到2个月,估计是自己觉得很不开心,被迫离开了公司。其实,保持低姿态,谦虚的学习态度,必不可少。

      3、阅读项目相关的文档:

      一般来说,新人一到公司,就会安排到项目中去。作为测试新手,快速阅读相关的“需求文档”、“详细设计文档”和“用户手册”特别关键。我们能够通过需求规格说明书等文档,快速熟悉系统相关的知识,获取编写测试文档的相关信息。如果项目已经编好了用户手册,您完全可以根据文档的步骤,一步一步傻瓜式的熟悉每项功能。只有掌握的这些文档的精髓,测试才会变得异常轻松呀。

      4、快速熟悉项目相关业务知识:

      刚到新公司的测试人员,如果你是跳槽到以前做过的相近行业,有丰富的经验了,那么您熟悉业务没什么大的问题。如果您换的新公司是您以前都没有接触到的行业,那你一定得努力一点,买些相关的业务知识看看非常必要。我深有体会,以前从一家“通讯公司”跳槽到做“银行系统”的公司,业务完全两样,很多业务知识都是从零开始。不过有一定的工作经验,学习起来也挺快,关键取决于个人是酷爱学习和坚强的学习毅力。

      5、尽快介入了解被测试系统:

      刚跨入一家新公司,如果被测试系统已经开发的差不多了,部分功能已经OK了。你可以部署到测试环境下,尝试从直观测试的角度去尽快了解系统,尽快结合文档熟悉起来。很多的时候,通过页面操作实际的系统比看文档效果好的多,并且印象更深刻,熟悉系统更快。新加入公司的朋友不防试一试。

      本文出自51Testing软件测试网,感谢会员zhuzx在每周一问(08-09-01)中的精彩回答。
      http://bbs.51testing.com/forum-157-1.html

      6、了解公司类似的相关产品:

      大多数的公司,都不可能在每个行业都非常强,基本上都是在某一个较小的领域很强势,公司主要就是研发强势相关业务的产品。所以说,相关的产品一般来说是很多的,如果要你测试的系统没有开发完毕,如果时间和条件允许,不妨先了解一下公司类似的产品,以便尽快熟悉起来。大多数情况下,公司很多的产品都是相通的,大部分的产品是在不同的客户要求下,修改了部分功能和界面而已。个人认为:了解类似的产品,也是测试新手快速熟悉产品的一条捷径。

      7、尽量多参加项目的各种会议:

      每个项目,特别是在项目的启动阶段,大会小会不断,很多时候项目组成员抱怨居多,都认为很浪费时间,耽误开发进度。如果作为测试新手的您这个时候加入,那太好了,多参加这样的讨论会。大部分时间都是在讨论项目的重点和关键,如果大家意见不一致,必然要对不一致的东西展开细节讨论,您肯定是收益匪浅。特别是对业务方面的讨论,您参加几次讨论,比您看10篇需求还强,并且理解也很透彻。如果您对需求有所了解,但是部分功能模块还有问题,就可以在讨论会上随时提出来,大家一起讨论,共同解决。如果有这样的机会,切勿放弃哟。

      8、阅读类似项目已有的测试用例:

      如果项目已经启动并进入了测试阶段,如果你在这个时候介入,通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。这些测试用例也是您快速上手测试的重要参考资料。如果还没有编写测试用例,你就介入了,那你就得重头开始,您可以阅读项目类似的测试用例,并结合以前项目的测试经验,根据公司相关的测试用例模板开始编写测试用例。如果在编写测试用例中碰到您不了解和很难处理的问题,您可以记入测试需求疑问表格,等部门开会时,提出来大家讨论。最好不要碰到一个问题就去问,经常打乱人家的思路,弄得别人嫌烦,那就不值了。

      9、查看缺陷数据库中旧有的缺陷:

      一般的测试缺陷跟踪系统,都是按模块来分类软件缺陷的。如果老大给你分配了测试任务,你就可以有目的的去熟悉即将测试的模块缺陷。登录系统后,对缺陷进行筛选,尝试按测试前辈的Bug描述步骤进行操作,看看是否能够重新缺陷?这种方法能够借鉴测试同行的经验,尽快发现问题,避免测试的盲目性。一来可以拓宽您的视野,避免递交类似问题的Bug或是重复的Bug,二来还可以为您快速熟悉被测试系统添砖加瓦。

      10、必须明白自己领导是谁:

      一般的员工进入公司,公司和部门领导很多,搞不清楚谁管我,碰到问题问谁?谁可以帮忙解决问题?如果真是这样那就麻烦了。部门领导臃肿的情况实在是太多了,有的公司,既有2测试经理,又有几个测试主管,还有多个项目经理和研发总监,不知道工作向谁回报,对哪个领导负责。弄得每个领导都回报,很累呀!!我的做法是:测试项目中负责领导只有一个那就是测试主管,测试主管负责安排和分配每个测试人员的工作和任务,我直接Review测试主管。如果项目中碰到有什么解决不了的问题,组内成员可以直接找我,同时我也定期加入项目参加部分测试,了解测试项目的一些进展情况,必要时还要找一些人谈心。这样,工作汇报比较简单明了,很轻松。

      11、熟悉与测试相关的管理软件的使用:

      我说的这个测试相关的软件包括缺测试需求管理软件(如TestDirector或QC)、陷跟踪管理软件(如:TestTrack Pro、TestDirector等等)、版本配置管理工具软件(CVS、VSS,还是SVN等等),具体熟悉到什么程度,那就要看您的职位了。如果您是一般的工程师,那你就只了解一般的使用就够了,如果您是测试经理,您不仅要了解一般的使用,还要更深层次的了解软件的权限和项目的配置,因为您要作为该软件的Admin,碰到问题大部分都由您搞定呀,高工资不是那么好拿的呀,哈哈!!!如果作为新入职的您,连这些都不会,那你就得加把油了,不然到了测试启动阶段,你才开始熟悉管理软件,那么你觉的能够快速展开测试吗?

      12、注意沟通技巧,把握请教良机:

      为了尽快熟悉项目,展开测试工作,沟通技巧必不可少。您作为新入职的测试人员,尽量了解每个开发人员开发的模块和每个开发人员的性格特点,寻找一些共同语言,拉近与开发人员的距离,让他们对您产生好感。只有这样,当您碰到问题的时候,他们才会鼎立的帮助您。如果您与开发人员关系不好,看了就觉的很讨厌,那他们肯定不会帮助您的,更不原意和您配合,当您提错Bug的时候,他们就会抓住这些Bug不放,有时候还要说您什么都不懂,这样你就很郁闷,肯定呆不长久的,只有走人的份了,呵呵。特别是开发人员很窝火的时候,您更要多一些理解和宽容,切勿火上浇油,您可以给他一些表扬,给他一些鼓励。他一听准开心死了,总觉得还是您们最了解我,把您当成自己人。这个时候,你再问开发人员问题,他也许态度就不一样了,他准会仔细的给你讲解,并且以后的什么事情,他也会百厌齐烦地帮助您的,因为他觉您最了解他们,无意识的把您当成了好朋友和哥们。还有的时候,开发人员有空过来测试部门逛逛,准备和您交流时,一定要把握机会,和开发人员开开玩笑和一些必要赞赏,也能够调节和开发人员的关系。总之,这一点做起来真的很难,如果做的好,那效果确实就不一样了。

      欢迎各位同行继续补充指正!!

  • 转载—对于如何衡量和提高测试效率

    2009-01-16 11:08:04

    如何衡量测试效率?

      个人认为可以从软件测试的活动中的以下指标综合考评,去评估衡量测试效率,每项指标都高,自然能够说明一些问题:

      1.发现缺陷的质量:

      同一个项目组内,我们一般运用测试管理工具TD, 按优先级和严重等级,把每个人的缺陷做成柱状图和饼图,放到一个文档中,邮件发给大家,让组内成员了解自己的工作情况和其他人的工作情况。同时也让开发人员,对每个测试人员的工作,做出评估,供绩效考核时参考。特别是发现非常隐蔽缺陷的测试人员,一定要重赏。

      2. 测试的有效性:

      一般来说,递交Bug的有效性,体现了测试员是否能够正确理解系统,并发现问题,是否能够发现有效的问题。很多时候,测试人员没有弄准确需求,或者是没搞清楚设计,一旦出现异常,就提交Bug。不是和前面的缺陷相同,重复递交相同类型的缺陷,就是递交无效的Bug,导致后来很多缺陷,都被项目评审时拒绝,既耽误了时间,效率自然不高。

      3.测试组员交叉测试,发现漏测问题数量:

      经常是这样,一个测试人员测试结束,修复了全部的缺陷。这个时候,测试的模块和测试人员交叉一下,再测试,很有可能又发现很多问题。这样我们可以对测试发现问题数量,进行统计。这样做,就迫使测试人员认真执行每一轮测试,每次测试都不敢懈怠。

      4.遗漏到客户缺陷的比例:

      一旦版本测试通过,发布给客户以后,客户要对发布的版本进行验收测试。同样会发现一些问题,我们也会对测试过程中发现的Bug分配到每个模块和具体的人。但是,如果缺陷在测试环境中不能重现,只能在实际工作环境中出现,则不属于遗漏给客户的Bug,不计入漏测统计里面。有时候,客户系统在使用中也会发现缺陷,我们同样做好记录。

      5.递交的缺陷数量:

      在同一个项目组内,每天递交的Bug数量,每周递交的Bug数量,每个版本测试结束,总共递交的Bug数量。最终测试结束,算出每个人递交有效缺陷的百分比。

      6.执行用例的数量:

      同一天,每个测试人员,执行用例的数量。但是一定要去除那些不能够测试的功能模块,或者是被阻塞的模块,这些一定要考虑到。否则大家意见就大了呢!

      7.编写测试文档的速度和质量:

      每次编写测试用例时,大家都要编写部分模块的测试用例,我们也可以通过单位时间内编写case的数量、速度和质量,来区分每个人的效率,我觉得也是一种好方法。

      8.评审发现问题的效率:

      在组织部门内部的case评审时,同一个测试文档的评审,如果提出的修改建议比较多,并且很有参考价值。这样的测试人员,效率应该比较高,得考虑考虑加薪,呵呵。

      9.测试工具使用的熟练程度:

      当然,一个测试人员,对测试工具的熟练程度越高,使用技巧越强,一般来说,测试的效率就越高。按常理来说,每个人不可能了解全部的自动化测试工具,我们只对常用的测试工具进行考核就可以了,还算人性化吧。并且后面懂得较多的同事,给组内成员集体培训,使大家迅速掌握测试工具的基本使用,这才是我们的真正目的。

      10.测试结果的分析水平:

      对自动化的测试工具来说,特别是性能测试结束之后,我们要分析部分测试结果,如果你都不熟悉测试工具的分析,何谈效率呢?所以测试结果的分析水平,也可以作为衡量测试效率的一个指标。

      如何提高测试效率?

      1.首先要有一个合理的详细的测试计划:

      没有详细的测试计划,测试部的每个成员都在那儿盲无目的测试,何谈提高测试效率?当然测试计划也不能够太细,太细了,编写测试计划同样浪费时间,做到时可而止。最好是测试任务尽量能细化到测试的功能和测试的case这个级别去监控进度,较为理想。

      2.测试尽早介入项目详细了解项目的业务需求,做好测试的前期准备:

      目前来说,可能大家都有类似的感受,接触到的大多数的项目,都是测试周期比较短,开发人员耽误了时间,为了不拖延项目进度,留给测试人员做测试的时间都非常紧张。如果项目测试的前期了解业务需求、了解产品属性和准备测试数据不充分,往往测试效率很低,测试时间变长,测试效率急剧下降。

      3.对测试项目前景充满信心,调整最佳心态,保持愉悦的工作心情

      一般来说,如果大家认为测试的项目没什么发展前景,当然测试也不会很卖命,测试效率不用说。如果某个测试人员碰到什么不顺心的事,当天的工作效率肯定比平常低。所以,要保证测试效率,测试负责人要察言观色,及时找不开心的下属谈心,了解并帮忙消除部分员工的不良情绪,让员工有更好的心情投入到测试工作中去。

      4.提高测试接受的标准,减少测试版本送测次数:

      大部分公司的开发人员都有一种惰性,一旦公司成了测试部,他们自己测试时,都不会那么认真,以为有了测试人员,就自己就解放了。很多时候都是调试编译通过,实际上开发人员没有做完整的自测,就拿到测试部进行测试。如果测试部门有严格的测试接受标准,一旦发现有重大问题,立即拒绝测试,送回开发人员修改。可以减少很多次反复测试,重复测试,明显提高了测试效率。

      5.测试负责人认真做好测试文档的评审:

      测试经理一定要认真做好测试用例的评审,尽量使用较少的测试用例,发现较多的Bug,无疑是最佳提高效率的一种方式。很多时候,经验较少的测试人员在设计测试用例的时候,写了很多的测试用例,测试时几乎没有发现缺陷。还有一种:比如说等价类的测试,只要具备代表性就可以了,如果写了很多测试用例,执行了半天,臃肿的测试用例,未发现任何问题,也很不值。这些主要是靠测试用例评审的时候,测试Leader去把握了。尽量做到在满足需求的情况下,精简测试用例数量,提高测试覆盖率。很多时候,测试人员写好用例就自己测试,根本没人评审,有些地方理解有偏差,测试点没测试到,导致发给客户版本被退回,给公司也会带来巨大经济损失。

      6.加强项目组成员的相互沟通工作和项目信息收集工作:

      测试工作是一项沟通要求比较高的工作,一般需要同项目经理、产品经理、开发人员、业务人员、客户沟通。很多时候,由于测试介入较晚,测试时间短,测试初期测试人员了解需求不及开发人员,为了迅速熟悉需求,需要项目组成员之间相互培训和沟通。

      测试人员为了利于测试工作,平时也需要主动和开发团队沟通项目的进度、项目存在的问题、项目的需求变更等等情况。与团队成员沟通得越充分、对项目的信息收集和把握得越及时、越准确,我们的测试工作才可能做得越顺利,才可能提高测试效率。

      7.积极配合开发人员工作,努力赢得开发人员的尊重和支持:

      作为测试人员,我们绝不能消极等待或一味埋怨开发人员的不理解和不重视。我们首先需要正视自己、改进自己,通过自身的不断努力让开发人员,真正体会到测试的价值。同时,也需要理解并配合开发人员的工作。只有这样,才能赢得开发人员的支持。互相配合、互相促进,项目成员之间形成良性循环,彼此感情加深了、配合默契了、工作效率和工作质量也就自然提高了。

      8.按照项目的大小不同,必要的情况下引入自动化测试工具:

      是否引入自动化的测试工具,主要取决于测试的时间长短和测试的轮次。一般来说,测试周期较长、版本升级平凡和回归测试次数较多的项目,引用测试工具可以提高测试效率。如果测试周期较短,本来测试周期只有两三个月,开发测试脚步就要花费大量时间,引入自动化测试工具,用的次数较少,结果得不丧失,劳民伤财,呵呵!

      9.测试部门内部成员的工作业绩数据化:

      具体的做法如下:每天给每个人分配的任务非常具体,并且随时关注他们的进展情况,完成百分比,不断督促他们。并且,把每个人每天的工作成果(发现缺陷的数量和工作的质量)数据化,通过邮件的形式发给组内的成员,让大家有个比较。大家都有自尊心,看到自己落后,后面就加油赶工,形成一种良好的测试氛围。每周周例会的时候,对表现突出的给予表扬,对每次都比较差的下属,单独谈心,问问具体原因。

      10.提高测试人员的专业技能和工作能力:

      由于测试技术的不断成熟和完善,许多的新技术陈出不穷,作为测试人员需要不断提高自己的专业技能和工作技能。不断的给自己充电,补充测试理论知识,让自己工作技能力去弥补专业技能的不足。这样,你的工作同样可以做到最棒,效率自然很高。一段时间过去,回过头来一看,自己确实进步不少,没有虚度光阴呀!

      只是我个人的想法,希望同行批评指正!!

    转载请保留:本文出自51Testing软件测试论坛每周一问活动,感谢会员爱吃鱼的月亮的精彩回答。

  • 完善测试工作

    2009-01-16 10:41:49

    完善测试工作

      整个工作内容主要有:

      1、改善测试流程,形成《测试流程》文档

      2、规范测试工作,形成《测试规范》文档

      看上去就只需要上面两个文档就够了,但经详细分析,发现还需要很多相关的需要文档,整理了一下主要有

      1、《测试申请与反馈表》模板

      2、《测试计划》模板

      3、《功能测试测试点》模板

      这个与测试用例差不多,但不用写得很详细,主要把容易漏掉的测试点写下来

      4、《BUG严重性等级与优先级定义》文档

      5、《BUG提交注意事项》文档

      6、《功能测试报告》模板

      7、《性能测试计划》模板

      8、《性能测试指标及相关说明》文档

      9、《性能测试报告》模板

      10、《项目测试报告》模板

      11、《项目资料存档规范》文档

  • 转载-测试执行过程及注意事项

    2009-01-15 15:43:55

    一、测试执行根据:《测试需求文档》《测试计划》《测试执行测试》《测试用例》

      二、测试执行计划

      执行计划是确保正常的实施测试活动

      包含内容:

      注意考虑:1.测试执行的轮次安排

      2.测试执行的时间安排(参考程序发布计划)

      3.测试执行的人员分配

      4.测试执行的环境要求和搭建

      三、测试执行记录

      ● 做测试执行记录原因?

      1.保证测试工作的可追溯性

      2.记录测试人员的工作情况

      3.绩效评估的重要数据

      ● 记录的内容

      1.什么人--测试执行人员

      2.在什么时候-DATE

      3.做了什么--Case ID

      4.结果如何-(Pass/fail )

      四、执行测试过程

      1.设置测试环境,确保所需的全部构件(硬件、软件、工具、数据等)都已实施并处于测试环境中

      2.将测试环境初始化,以确保所有构件都处于正确的初始状态,可以开始测试

    五、测试执行活动结束或终止

      1.正常终止:所有测试过程(或脚本)按预期方式执行至结束。

      – 如果测试正常结束,则核实测试结果

      2.异常或提前结束:测试过程(或脚本)没有按预期方式执行或没有完全执行。当测异常终止时,测试结果可能不可靠。在执行任何其他测试活动前,应确定并解决异常/ 提前终止的原因然后重新执行测试。

      – 如果测试异常终止,则恢复暂停的测试

      六、核实测试结果,真正的缺陷:

      1.通常发生在实际结果与预期结果不匹配时

      2.意外的GUI窗口(图形界面)

      3.业务流程错误

      七、测试执行准备

      1. 执行前,动员工作:阐述策略,回答问题,定义测试计划、测试范围

      2. 严格审查测试环境,包括硬件、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本

      3. 将测试用例分类进行有效整合,构造测试套件(test Suite)

      4. 所有测试用例、测试套件、测试任务和测试执行结果通过测试管理系统进行管理,使测试执行的操作、过程记录在案,能跟踪、控制和追溯,保证测试进度和质量

      5. 确保每个测试人员理解测试策略、测试目标,对测试进程进行审查,确保测试策略得到执行,可奖励手段,测试经理、组长要勇于承担风险,使测试人员有发挥、想象的空间,但同时也施加压力,提高工作效率和责任心

      八、测试执行过程

      1. 记录测试记录,用例的执行状态使pass/fail

      2. 记录缺陷报告捕获测试结果,提交给上级审查及实现人员进行修复

      3. 缺陷跟踪和管理一般由特定工具来执行,对各模块、各测试人员、整体项目等进行事实跟踪。

      4. 进行常规的缺陷审查,包括BUG的严重性、BUG的描述、BUG修正等

      5. 对每个阶段测试结果进行分析,保证阶段性的测试任务得到完整的执行并达到预定的目标

      6. 良好的沟通,测试人员之间,与项目组之间保持有效的沟通,如每周例会,可以及时发现测试中问题。

  • 转载-如何确定一个软件的测试结束点

    2009-01-15 15:37:26

    在软件消亡之前,如果没有测试的结束点,那么软件测试就永无休止,永远不可能结束。软件测试的结束点,要依据自己公司具体情况来制定,不能一概而论!个人认为测试结束点由以下几个条件决定:

      1.基于“测试阶段”的原则:

      每个软件的测试一般都要经过单元测试、集成测试、系统测试这几个阶段,我们可以分别对单元测试、集成测试和系统测试制定详细的测试结束点。每个测试阶段符合结束标准后,再进行后面一个阶段的测试。举个例子来说:单元测试,我们要求测试结束点必须满足“核心代码100%经过Code Review”、“功能覆盖率达到100%”、“代码行覆盖率不低于80%”、“不存在A、B类缺陷”、“所有发现缺陷至少60%都纳入缺陷追踪系统且各级缺陷修复率达到标准”等等标准。集成测试和系统测试的结束点都制定相关的结束标准,当然也是如此。

      2.基于“测试用例”的原则:

      测试设计人员设计测试用例,并请项目组成员参与评审,测试用例一旦评审通过,后面测试时,就可以作为测试结束的一个参考标准。比如说在测试过程中,如果发现测试用例通过率太低,可以拒绝继续测试,待开发人员修复后再继续。在功能测试用例通过率达到100%,非功能性测试用例达到95%以上,允许正常结束测试。但是使用该原则作为测试结束点时,把握好测试用例的质量,非常关键。

      3.基于“缺陷收敛趋势”的原则:

      软件测试的生命周期中随着测试时间的推移,测试发现的缺陷图线,首先成逐渐上升趋势,然后测试到一定阶段,缺陷又成下降趋势,直到发现的缺陷几乎为零或者很难发现缺陷为止。我们可以通过缺陷的趋势图线的走向,来定测试是否可以结束,这也是一个判定标准。

      4.基于“缺陷修复率”的原则:

      软件缺陷在测试生命周期中我们分成几个严重等级,它们分别是:严重错误、主要错误、次要错误、一般错误、较小错误和测试建议6种。那我们在确定测试结束点时,严重错误和主要错误的缺陷修复率必须达到100%,不允许存在功能性的错误;次要错误和一般错误的缺陷修复率必须达到85%以上,允许存在少量功能缺陷,后面版本解决;对于较小错误的缺陷修复率最好达到60%~70%以上。对于测试建议的问题,可以暂时不用修改。

      转载请注明出自51Testing软件测试论坛

      5.基于“验收测试”的原则:

      很多公司都是做项目软件,如果这种要确定测试结束点,最好测试到一定阶段,达到或接近测试部门指定的标准后,就递交用户做验收测试。如果通过用户的测试验收,就可以立即终止测试部门的测试;如果客户验收测试时,发现了部分缺陷,就可以针对性的修改缺陷后,验证通过后递交客户,相应测试也可以结束。

      6.基于“覆盖率”的原则:

      对于测试“覆盖率”的原则,个人觉的只要测试用例的“覆盖率”覆盖了客户提出全部的软件需求,包括行业隐性需求、功能需求和性能需求等等,只要测试用例执行的覆盖率达到100%,基本上测试就可以结束。如“单元测试中语句覆盖率最低不能小于80%”、“测试用例执行覆盖率应达到100%”和“测试需求覆盖率应达到100%”都可以作为结束确定点。如果你不放心,非得要看看测试用例的执行效果,检查是否有用例被漏执行的情况,可以对常用的功能进行“抽样测试 ”和“随机测试”。对于覆盖率在单元测试、集成测试和系统测试,每个阶段都不能忽略。

      7.基于“项目计划”的原则:

      大多数情况下,每个项目从开始就要编写开发和测试的Schedule,相应的在测试计划中也会对应每个里程碑,对测试进度和测试结束点做一个限制,一般来说都要和项目组成员(开发,管理,测试,市场,销售人员)达成共识,团队集体同意后制定一个标准结束点。如果项目的某个环节延迟了,测试时间就相应缩短。大多数情况下是所有规定的测试内容和回归测试都已经运行完成,就可以作为一个结束点。很多不规范的软件公司,都是把项目计划作为一个测试结束点,但是如果把它作为一个结束点,测试风险较大,软件质量很难得到保证。

      8.基于“缺陷度量”的原则:

      这个原则也许大家用的不是很多,了解比较少。我们可以对已经发现的缺陷,运用常用的缺陷分析技术和缺陷分析工具,用图表统计出来,方便查阅,分时间段对缺陷进行度量。我记得以前zhuzx在这个论坛上提出过缺陷分析技术这个问题,我不再重复讲述。我们也可以把 “测试期缺陷密度”和 “运行期缺陷密度”作为一个结束点。当然,最合适的测试结束的准则应该是“缺陷数控制在一个可以接受的范围内”。比如说:一万行代码最多允许存在多少个什么严重等级的错误,这样比较好量化,比较好实施,成为测试缺陷度量的主流。

      9.基于“质量成本”的原则:

      一个软件往往要从“质量/成本/进度”三方面取得平衡后就停止。至于这三方面哪一项占主要地位,就要看是什么软件了。比如说是:人命关天的航天航空软件, 那还是质量重要些,就算多花点钱、推迟一下进度,也要测试能保证较高质量以后才能终止测试,发布版本。如果是一般的常用软件,由于利益和市场的原因,哪怕有bug,也必须得先推出产品,没办法呀。一般来说,最主要的参考依据是:“把找到缺陷耗费的代价和这个缺陷可能导致的损失做一个均衡”。具体操作的时候,可以根据公司实际情况来定义什么样的情况下算是“测试花费的代价最划算、最合理”,同时保证公司利益最大化。如果找到bug的成本比,用户发现bug 的成本还高,也可以终止测试。

      10.基于“测试行业经验”的原则:

      很多情况下,测试行业的一些经验,也可以为我们的测试提供借鉴。比如说测试人员对行业业务的熟悉程度,测试人员的工作能力,测试的工作效率等等都会影响到整个测试计划的执行。如果一个测试团队中,每个人都没有项目行业经验数据积累,拿到一个新的项目,自然是一头雾水,不知道从何处开始,测试质量自然不会很高。因此通过测试者的经验,对确认测试执行和结束点也会起到关键性的作用。


    转载请保留:本文出自51Testing软件测试论坛每周一问活动,感谢会员爱吃鱼的月亮的精彩回答。

  • 测试工程师工作流程概论

    2009-01-13 14:59:29

    测试工程师的工作流程,与公司的整体工作流程,项目的测试要求等因素相关。本文主要讨论测试工程师的一般工作流程。

    做好测试准备

    1)
    明确测试任务的范围  

       
    测试文档通常包括测试目的、测试环境、测试方法、测试用例、测试工具等。测试工程师首先要通读文档,对整个测试要求形成整体认识,明确测试目的,以及测试要求和测试重点,明确软件测试方法和使用的测试工具。  

    2)
    明确测试时间  

       
    明确测试周期和测试时间进度。如果是多人合作完成一个软件,则要首先明确属于自己的测试内容、根据测试内容和测试周期,估算自己每日应该完成的工作量。此外由于软件测试是群体协作的测试活动,需要明确哪些测试内容要与其他测试工程师协作才能完成。  

    3)
    设置测试环境

       
    根据测试文档要求,设置测试需要的软件和硬件环境,包括操作系统,要测试的软件和其他必要的测试工具软件等。所有这些完成后,分别运行,查看是否能正确运行,保证符合测试文档要求的测试环境。  

    4)
    学习被测试软件

       
    对于不太熟悉的软件,可以通过阅读软件自身的教程和帮助文件,学习本软件的一般操作方法,也可以参照相关的书籍资料等。另外,向熟悉测试软件的其他同事请教软件使用方法,也是学习软件的一条捷径。对软件使用越熟练,测试过程越顺利,测试效果越理想。  

    5)
    确认完全理解测试任务

       
    软件测试最重要的要求就是确实明确了测试任务和要求,这包括正确理解了测试文档,确认可以按照测试进度要求,完成测试。对于测试工具要正确安装,熟练使用。如果有任何不明白之处,向软件测试负责人询问。切忌凭自己的理解和主观推测,自行其事。当然,真正测试中,往往会遇到各种新的小疑难问题,也需要及时向测试负责人请教,以保证测试顺利进行。

    执行软件测试任务  

    1)
    按照测试文档要求,逐项认真测试

       
    根据测试文档测试要求,按照测试步骤,逐项进行。通过运行软件,观察测试结果,与软件需求说明书的内容进行比较,找出软件错误。对于需要调用测试用例的测试,保证正确地调用了测试用例,注意观察和分析测试结果。某些不容易重复的错误,需要反复测试,总结重复该错误所需要的测试步骤,直到确认可以重复出现为止。  

    2)
    记录发现的错误,填写软件问题报告  

       
    为了纠正软件中的错误,测试工程师要正确记录发现的错误,将错误再现的步骤写入测试报告中,测试报告是程序测试的重要组成部分,正确书写测试报告是对测试工程师的基本要求。采用软件缺陷数据库管理测试中发现的软件缺陷,每一条错误作为数据库的一条记录,方便记录、修改、查询。  

    3)
    填写测试进度表和必要的测试内容记录表

       
    每天将测试内容写入测试进度表文档,可以使测试负责人了解测试进度,控制测试周期内测试的连续性,增强测试过程控制性,保证测试的正常进行。测试记录要准确完整,实事求是,必要时插入测试注释,解释测试中的特殊问题。测试进度表是评价测试质量和工作内容的重要凭证,对于测试后发现的测试错误和失误,可以通过检查测试记录,寻找产生错误的原因。  

    4)
    测试中发现疑难及时请教

       
    测试是一个动态的过程,可能由于自己的错误操作或者测试文档内容的错误,使得测试过程中出现自己不能解释的现象或结果,出现与测试要求不符合的情形,这时可能需要与其他测试者协商或求助,如果问题仍然不能解决,应该及时请教,听取意见和建议,必要时反复讨论直到问题全面解决。

    全面检查测试结果

    1)
    对照测试文档要求,检查测试内容是否完整  

       
    测试完成后,要对照测试文档检查测试是否全部完成,保证没有丢失测试内容。如果某些内容,由于测试环境的要求不满足,或者由于测试时间短没有进行,则要写入测试进度表文档。  

    2)
    检验书写的软件问题报告的记录,使之确切、规范

       
    正确书写测试记录是保证迅速定位软件错误,加快改正错误的必要前提。专业规范的软件记录报告是体现公司测试水平和专业实力的外在体现。认真检查书写的每条记录是否符合规范,格式、步骤、内容一一检查,必要时补充或删减。  

    上述三个阶段,相互联系紧密,其中准备是基础,测试是重点,检查是保证,应该根据测试的软件特点合理安排

     

Open Toolbar