测试用例之性能测试用例

发表于:2007-5-14 13:06

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:陈绍英    来源:csdn

3用例管理

测试用例的管理我们可以借鉴开发过程中对程序的管理方法,我们可以把测试用例看成程序——测试工程师编写的程序,这个程序也要经过“设计”、“开发”、“测试”、“版本管理”、“发布”、“维护”等一系列操作,然后按照管理软件程序的方法来管理测试用例。

用例管理主要包含评审、修改、执行用例、用例版本维护、用例升级方面的内容。

3.1  用例评审

测试用例评审是测试用例不可缺少的一个环节,这是对“测试部门开发出的产品”进行的“测试”。基本思路是对测试准备阶段的成果进行分期评审,依次评审系统/验收测试用例、集成测试用例、单元测试用例。

评审用例在比较正规的公司更容易实施,要求相应的软件开发团队必须在实际工作中对测试给予足够的重视,才可以把这项工作做好,否则只是走走形式。有效的用例评审通常由下面两种形式组成:

测试部门外部评审——主要是由开发部、项目实施部、甚至销售人员参加的评审,目的主要是查找测试工程师编写的用例是否缺少内容。建议采用非正式评审的形式进行,因为我们很难把开发人员组织在一起,一般来说他们的开发进度压力很大,能够抽出时间看文档已经是“很给面子了”。当然不统一进行评审会耽误工程的进度,所以在实际工作中如果时间紧迫,可以提前启动测试实施工作,待评审完成后进行用例的修改工作。通常测试工作进行一段时间评审就会结束,这个时候测试执行人员可以在工作中对测试用例的内容进行动态的调整,再次执行被修改过的部分用例(如果能够采用正式评审,效果肯定会更好。)。

外部评审主要工作方式是用文档直接记录评审结果,测试人员根据评审结果对用例进行升级修改。

测试部门内部评审——部门内部同行对测试策略的评审,评审的核心内容是测试策略和用例编制思路是否正确,以此来保证测试用例的有效性。可以组织正式的评审,由用例的设计人员进行讲解,然后大家共同评审;也可以把文档发给部门的同事进行评审。内部评审有些象开发人员在单元测试中的交叉测试。

内部评审的主要工作方式是项目会议,大家可以进行激烈的讨论,共同探讨用例编写、交流经验,这样用例的编写水平才能提高,同时可以进行一些创新。

评审方式中的外部评审最为重要。因为开发人员很容易发现用例中遗漏了什么内容,同时还可以发现错误的用例——因为存在对需求理解的偏差。用例外部评审可以理解为开发人员在查找测试人员编写的“程序”缺陷。

通常情况下先执行内部评审,然后执行外部评审。很多时候,内部评审会被忽略,建议要进行内部评审。这样至少有两个好处:集思广益和提高测试小组输出文档的质量。

3.2  管理方案

国内大多数IT公司在测试用例的发展经历了以下几个阶段:

Ø         无用例而执行测试:测试的初级阶段,完全手工测试,测试执行工程中没有测试用例作为执行依据,可能会按照需求进行测试;

Ø         有用例而不使用用例执行测试:已经编写测试用例,但是受各种环境的影响,例如需求变动频繁、编写的用例过于简单等,测试用例编写后在实际工作中不能使用;

Ø         按照部分用例执行测试:随着用例编写水平的提高,部分测试用例可以在测试中发挥作用;

Ø         完全按照用例执行测试:组织建立了规范的项目管理过程,对测试用例进行规范的管理,执行测试用例以用例为准则来执行测试。

完全按照测试用例执行测试是一个公司测试水平的体现,测试用例管理成为这一阶段的主要内容。测试用例管理的核心内容是版本管理。如果测试用例是采用文字编辑软件例如word编写,建议采用工具(例如Visual SourceSafe)对用例进行控制。可以参照图2进行。

 

 

 2 测试用例管理示意图

1、  编写用例:测试工程师根据需求分析、概要设计、详细设计等文档编写测试用例。

2、  用例评审:3.1小结说明了用例的评审。原则上用例像程序一样,要经过多次的修改才可以通过,而实际工作中只进行一到两次。

3、  用例修改:评审结束后,需要根据评审意见进行修改,修改后通常不再进行评审。建议在时间和人力资源比较充裕的情况下,对用例的评审要像测试开发部门的产品一样,经过反复的评审和修改,然后正式投入使用,因为每次评审可能都有新的发现。

4、  使用用例:在执行任务时,从版本控制库取出用例,执行时建议直接在用例上记录测试结果。这样做会带来两个好处:首先是下次测试时可以看见上次测试的结果记录,可以起一个提醒的作用;其次可以一次性的把发现的缺陷输入到缺陷跟踪数据库中,在输入时可以进行综合统计,避免输入重复的缺陷。每次使用后送入版本控制库中,进行版本的管理。

5、  用例升级/维护:随着软件产品的不断修改、升级,对应的用例也需要升级和维护。针对同一个项目,可以根据需求的变更不断进行维护;如果是产品,用例的维护则更加重要,要达到用例和产品的版本一一对应。

测试用例的管理还可以采用专门的测试软件例如TestDirector等来进行管理,测试工具通常会具备上面的功能。如果有条件,建议采用集成华的测试工具,这样更容易对测试执行全程进行监控,可以把测试需求、测试用例、缺陷管理统一起来,大大提高测试效率。

在测试用例管理规范化并成为测试的执行准则后,管理测试用例带来的巨大好处开始逐渐显现出来,测试用例成为评估测试和改进测试工作的主要依据,可以给工具带来巨大的方便。例如可以通过测试用例的执行情况来统计分析执行结果,编写测试报告,判断软件测试是否完成,通过统计测试覆盖率、测试合格率、重要测试对象的合格率是多少来完成对软件质量的评估;尤其是新员工到岗后,可以更容易介入工作。

总之,不管是性能测试还是其它测试都要本着“一切从实际出发”的原则,根据不同产品的特性进行用例编写,最后按照要求完成测试,达到提高产品质量的目的。在测试用例的编写过程中,尤其要记得“创新”,如果长期依靠某一测试用例编写模式、采用某些固定的模板,测试用例编写工作肯定会停滞在某一层次上不再发展,一定要跟着测试对象的不断变化来调整策略,在具体的工作中改进和提高,才能“开发”出优秀的测试用例!

33/3<123
《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • lele218
    2007-7-26 10:10:27

    呵呵

  • 51test123
    2007-7-25 17:59:32

    rubbish
    waste my time

  • cl1216
    2007-6-15 23:35:52

    BUG

  • ztralj
    2007-6-11 20:41:40

    就是啊,版主啊,说的是测试用例,结果是这个。
    况且你的V模型不对应哦。单元测试对应的是详细设计,集成测试对应的是概要设计,系统测试对应的是需求分析与系统,验收测试对应的是用户需求。

  • 可乐冰
    2007-5-29 13:11:38

    标题与内容严重不符!

  • sunxy5291
    2007-5-28 09:25:53

    牛头不对马嘴!!!

  • icetea_plh
    2007-5-17 11:06:42

    谢谢,不错

  • lilyss
    2007-5-14 20:54:58

    有心了,谢谢。

  • codanl
    2007-5-14 17:18:08

    说的太好了

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号