51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 2116|回复: 21
打印 上一主题 下一主题

求教:什么样的用例才是好的用例呢

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-1-26 15:25:29 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
请教一个问题:什么样的用例才是好的用例呢
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

22#
发表于 2007-4-1 10:15:31 | 只看该作者
我看楼上的大人们把关注点放在了测试用例的设计过程上了,而且关注的是用例集而不是单个的用例,其实楼主的意思也有些不明确?是想知道整个用例的设计过程的好坏标准还是单个用例的作用的大小呢?如果是整个设计过程,那么楼上的某些大人的想法是很不错的,当然,不能一个用例就能达到完全的覆盖,一些巧妙的用例的结合组成的用例集就可以达到很高的覆盖率!用例的设计和执行还有分析结果等一系列过程都要花费人力和物力资源的,所以,好的测试用例设计正如楼上所说的用最少的用例达到最大程度上的覆盖。当染一个好的用例(单个)我觉得就是它能独辟蹊径,发现以前从来没有发现或者类似的错误!
回复 支持 反对

使用道具 举报

该用户从未签到

21#
发表于 2007-3-24 11:00:39 | 只看该作者
一个测试用例最好关注于一个问题,尽可能多的逆向思维,因为human is crazy~
回复 支持 反对

使用道具 举报

该用户从未签到

20#
发表于 2007-3-22 12:03:32 | 只看该作者
设计测试用例,在实际测试用例设计过程中,不仅要根据需要、场合单独使用这些方法,
常常综合运用多个方法,使测试用例的设计更为有效。

1。写的清晰,能让测试执行人员执行起来方便,
并且一个测试用例中的测试数据尽量做到包含尽可能多的测试点!
2。好的测试用例是发现迄今为止未发现的错误的测试用例
3。能够全面覆盖测试需求的用例。
总之,要从多个方面来考虑.
 以上是个人的观点.不知是否正确.sdlkfj5
回复 支持 反对

使用道具 举报

该用户从未签到

19#
发表于 2007-3-21 10:16:03 | 只看该作者
我们做测试的不就是为了找到BUG吗??好的测试用例当让是为了找出BUG....
回复 支持 反对

使用道具 举报

该用户从未签到

18#
发表于 2007-3-21 09:40:48 | 只看该作者
其实在工作中,最主要的和最难的应该就是如何写好测试用例吧,个人认为通过各种方法设计出测试数据,通过分析,删减得到的部分用来作为用例的输入,尽量用少的用例来发现更多的错误吧!我觉得好用例就是为了覆盖需求而设计的,用来发现其中不满足的情况。
回复 支持 反对

使用道具 举报

该用户从未签到

17#
发表于 2007-3-18 12:49:21 | 只看该作者
A good test case is one that has a high probability to find an error.
回复 支持 反对

使用道具 举报

该用户从未签到

16#
发表于 2007-3-13 22:46:01 | 只看该作者
用例的好坏关键就在于它是否能够达到有效的覆盖率。
在实际工作的CASE的数量往往是于工作量成正比的,然而紧张的项目周期不允许我们一味的最求CASE的数量。所以说CASE不在多而在于精。
我们只要按照CASE的设计方法(等价类划分、边界值等方法)结合需求文档来设计CASE,并对需求达到一定的覆盖率。大家应该都学过:1条CASE中要尽可能多的去覆盖有效等价类。这就是控制CASE数量的一种手段,同时又保证了CASE的质量。相反如果不用方法去随意的编写CASE,当然也能覆盖需求,但CASE的数量会多出很多,测试内容也会有很多不必要的重复。
所以要写出好的CASE除了要使用方法外,也存在着很多的技巧,还需要在实际工作去操作并积累经验。

[ 本帖最后由 liangliang1108 于 2007-3-13 22:48 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

15#
发表于 2007-3-13 11:04:37 | 只看该作者
将需求覆盖全面且能发现BUG的用例
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2007-3-12 09:14:18 | 只看该作者
个人觉得,不要刻意追求用例的好坏。用例是为了什么?目的是发现软件缺陷,而如何才能更好的做到这点,并不是说发现了缺陷了就是好用例,没有发现的就不好,而是要靠用例对需求的覆盖。
如果非要说用例的好坏,那就是在用例设计中,一些意想不到的组合了,而那些往往是在你有了很多经验后,一些错误猜测的用例里面。
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2007-3-10 20:26:01 | 只看该作者
人家说的是好用例,又不是设计,
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2007-3-10 19:52:13 | 只看该作者

关于用例

最近快要考试了  忽然想起这个阶段其实就是学的怎么写用例
我觉得如果只是做好自己的本职工作的话就是用各种分类法设计用例,越全面越好,重点把握好覆盖率
如果想要有所造诣,那就要多思考了,其实在测试的过程中,功能方面所能造成的软件修改还不是最令人头疼的,在性能测试方面那基本上是要汤和药一起换的 ,所以如果能够从函数,类这方面就着手去分析以后可能导致的性能问题的话,应该就可以是个行家了
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2007-2-25 17:16:30 | 只看该作者
个人觉得,如果能用最少的用例发现比较多的bug,那应该就是好的用例。
比较全面的覆盖到需求的用例。能够比较直观的重现错误的用例。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2007-2-24 20:12:39 | 只看该作者
偶同意8楼的,好的用例不一定要发现BUG,但是关注点应该明确,针对性要强
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2007-2-24 17:13:18 | 只看该作者
覆盖需求,简洁易懂,格式规范
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2007-2-4 16:22:40 | 只看该作者
好的用例应该是:1)用例的关注点要明确,清晰;2)用例的输入和预期输出要写得详细一点(时间不是很紧的话),也许是自己来执行的,但写得明白一点,以防过了一段时间之后,自己看自己写的用例,都看不懂.
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2007-2-2 07:42:13 | 只看该作者
那如何才能做到需求100%覆盖呢?
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2007-1-30 19:15:26 | 只看该作者
个人认为不管有没有发现BUG,只要有条理清晰的思路写出来的用例就是好用例
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2007-1-29 23:25:32 | 只看该作者

回复 #1 anruie 的帖子

我认为软件测试用例只要能找到尽可能多的Bug就是好的测试用例
具体衡量标准:对于系统测试 考虑测试用例对于需求的覆盖程度
                      对于集成测试 考虑测试用例对于函数间接口 模块间接口 子系统间接口的覆盖程序
                      对于单元测试  考虑逻辑覆盖率
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2007-1-27 19:37:43 | 只看该作者
同意楼上的
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-13 04:31 , Processed in 0.079484 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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