软件测试用例的重用

发表于:2010-07-05来源:作者:点击数: 标签:软件测试重用
软件 测试用例 的重用 软件测试 跟测试工程师打交道最多的可能就是测试用例了,先设计出一些测试用例,然后这些测试用例要经过评审,之后要执行这些测试用例,完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用

        软件测试用例的重用   软件测试

  跟测试工程师打交道最多的可能就是测试用例了,先设计出一些测试用例,然后这些测试用例要经过评审,之后要执行这些测试用例,完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢?很多人可能第一时间想到了一些测试管理工具能帮上忙,例如Quality Center,Test Link;又或者是一些保存测试用例的工具,例如Word,Excel。

  不过这些东西真的能帮助我们重用测试用例么?我想未必。测试用例的重用,应该是测试用例里面的设计思想的重用,而不是具体某个测试用例的,因为对于功能测试的测试用例来说,大多数的测试用例都跟某个具体的被测应用有想到大的关联性,例如要测试一个博客编辑器,对于MySpace的博客编辑器和 facebook的博客编辑器来说,它们的主要功能是相似的,都有发表博客,编辑博客,修改博客等……但是由于这是两个不同公司的产品,他们的具体功能或者UI是完全不一样的,所以拿到的两套测试用例,也应该是不一样的。如果分别提取出测试用例的核心思想(就是那些可以重用的部分),应该能看到很多的共同点,或许会有这么一条共同的用例思想。

  1. 打开博客编辑器

  2. 点击插入视频的按钮

  3. 粘贴视频代码

  4. 点击保存,发布

  期望结果是该视频能正确显示在博客上。

  这条用例可以提取为“验证博客编辑器能够插入视频”,至于实现的细节,可能两家的处理不一样,可能前者用 标签,后者用标签。回到实际的测试用例,前者可能要求将博客编辑器切换到HTML编辑模式下,要看到 ….的代码,另外一个就是要检查有….< /embed>的代码。其实测试用例是测试工程师之间的很好的沟通交流工具。通常在一些研讨会上,有人抛出一个问题“对于日期输入框大家会怎么进行测试”,大家接着七嘴八舌地进行讨论,这样的讨论结果就是大家都知道了一些,又好像不知道一些。如果这时候有人拿出自己的测试用例,那么会不会更加一目了然,更加有系统性?

  举个例子

  CRUD模式(创建,获取,更新,删除)

  1. 选择并确定出一条记录或者一个字段

  2. 产生一个随机的等价类item

  3. 检查这个新产生的item是没有存在的

  4. 添加一个新的item

  5. 读取并且验证这个item的正确性

  6. 修改该item并且验证item确是已经被修改

  7. 删除该item并且验证item缺少已经删除

  以上测试用例可以应用于不同的场景,例如MySpace中的一个帐号,也可以是一条歌单,还可以是一篇博客。这种类型的用例才是可重用的,而不是发布一篇博客,修改博客,删除博客……测试用例的重用,也就是测试用例的精华部分,其设计思想,而不是一些存在QC,TD中的 01010100101001。

原文转自:http://www.ltesting.net