51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 3921|回复: 13
打印 上一主题 下一主题

[讨论] 怎么样的测试用例才是好的用例?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-2-23 11:38:09 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
怎么样的测试用例才是好的用例?


一个好的测试用例在什么方面能体现 出它的好呢?
这方面的东西还请大家多多发言,特别是有大量测试经验的朋友,大家一起讨论,希望大家都能够提高

谢谢
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

14#
 楼主| 发表于 2006-3-2 12:48:06 | 只看该作者

怎么没有人回帖了?

rzhch_002  小姐 

你的是什么意思?
难道就只是这里看看

没有什么要说的嘛

还是大家聊的不够你来评价?
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2006-2-26 08:58:20 | 只看该作者
天空不留我的痕迹,但我一飞过。
                                                          ------------泰戈尔
回复 支持 反对

使用道具 举报

该用户从未签到

12#
 楼主| 发表于 2006-2-25 14:21:42 | 只看该作者

再加一点

原帖由 ouyu 于 2006-2-25 11:07 发表
象楼主说的引进了新的功能,这是需求引起变化 ,你可以考虑 更新用例,来找出BUG,不过新的用例可能推翻
以前旧的用例,如果BUG太多了还可以考虑测试挂起了 .



新的功能肯定要有新的测试用例了,也可能要推翻以前的用例了,


在这里你所说的测试挂起是指的什么东西挂起?说的具体点,我有点不明白,是不是说要把测试停了?还是有其它的意思呢?
我比较笨,不要在意
呵呵
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2006-2-25 11:07:08 | 只看该作者
象楼主说的引进了新的功能,这是需求引起变化 ,你可以考虑 更新用例,来找出BUG,不过新的用例可能推翻
以前旧的用例,如果BUG太多了还可以考虑测试挂起了 .
回复 支持 反对

使用道具 举报

该用户从未签到

10#
 楼主| 发表于 2006-2-25 10:11:19 | 只看该作者

是的

这是我引用别人的话
我也忘记了在那里看到的

但是我觉得这个不重要
只要能给我们的讨论带来启发就可以了

另外,这个话题是好的测试用例

希望大家多多发言
共同提高
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2006-2-24 17:10:58 | 只看该作者
你的启示,我怎么觉得好像那里看到过.
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-2-24 14:29:11 | 只看该作者
测试人员也是人不是神,我们的工作就是在有限的时间内,设计出好的测试用例,用最少的时间找出软件的问题所在!
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-2-24 13:53:35 | 只看该作者
不能揭示错误的用例也不能称之为不好

JUST LIKE:不能发现软件所有错误的测试员也可以是好测试员
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-2-23 21:28:08 | 只看该作者
一个好的测试用例
从理论上来回答:好的测试用例是发现迄今为止未发现的错误的测试用例

就像sopper说的: 输入项和输出项的逻辑关系来确定一个bug的原因所在

所以好的测试用例也可以片面地理解成为 好的输入项

当然,好的测试用例还可以从以下方面来考虑:
用例ID号:你如何来编写ID号,使得大家更加明确直观的看懂这个测试用例的作用,所处阶段等
用例标题:同样的,如何才能更加简洁明了地描述这个用例设计
重要级别:如何来确定这个用例的重要级别,让大家可以对该用例有一个更加明确的定位
………………
总之,一个好的测试用例我觉得是应该从多方面来共同体现的
回复 支持 反对

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2006-2-23 17:12:03 | 只看该作者

给一点启示

一次针对公司的新的软件功能进行测试的时候,像往常一样 “ 随手 “ 测试出了几个 Bug ,然后 “ 仔细 “ 的填写了 Bug 单(这个 Bug 的现象已经出现了很多次了)。

这时候测试经理走过来,重新复查了一下填写的 Bug 。他在重现我的 bug 的过程中,简化了我的输入变化, bug 神奇的又出现了,同样的现象,他关闭软件重新变化输入,扩展出 10 几个变化后,软件不动了,内存不断上升。终于他找到了产生软件的 Bug 的原因
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2006-2-23 17:08:43 | 只看该作者

具体点

能不能说的具体点呢
比如:
一个测试用例里,根据两个输入项和输出项的逻辑关系来确定一个bug的原因所在
…………
回复 支持 反对

使用道具 举报

  • TA的每日心情
    无聊
    2018-8-7 14:54
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    3#
    发表于 2006-2-23 14:08:35 | 只看该作者
    写的清晰,能让测试执行人员执行起来方便,并且一个测试用例中的测试数据做到包含尽可能多的测试点!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    2#
    发表于 2006-2-23 12:55:02 | 只看该作者
    能够发现目前为止没有发现的错误的case.
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-23 07:44 , Processed in 0.076415 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表