51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 14060|回复: 34
打印 上一主题 下一主题

[讨论] 测试的“粒度”

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-5-22 15:03:02 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
在写测试用例的时候,几个测试人员在一起,或是主管自己,根据测试对象,凭借经验,来规定设计测试用例的“粒度”,比如:点击一个按钮的动作算是一个测试用例,但是点击一个按钮,之后我们向文本框中添加数值,然后按回车,这也算是一个测试用例,但是他们的粒度不同。
       请大家讨论自己对于设计测试用例“粒度”的理解-------
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2006-5-22 15:37:04 | 只看该作者

我觉得应该有从功能出发

在我看来测试粒度应该由功能来决定吧,或者说得由具体的测试要求来说吧,如果说测试的软件的控件、按钮等等的正确性的话,那么每一个操作都应该算一个用例。如果说要求是测试软件的工作流程、工作功能,那么应该把粒度设定得更大些,大到每一个用例是针对一个功能。
我是个新手,说得不对的请大家指教
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2006-5-22 16:56:37 | 只看该作者
一方面应该要设计用例前有约定 ,另一方面可以把一些通用按键功能设计成公共用例。既详细又不会忘记测试
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2006-5-22 22:27:38 | 只看该作者
楼上的想法很好啊
通用的控件功能 应该设计成公用的用例
这样就不会混淆了
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2006-5-23 11:48:52 | 只看该作者
原帖由 天生我才 于 2006-5-22 15:03 发表
在写测试用例的时候,几个测试人员在一起,或是主管自己,根据测试对象,凭借经验,来规定设计测试用例的“粒度”,比如:点击一个按钮的动作算是一个测试用例,但是点击一个按钮,之后我们向文本框中添加数值,然 ...


点击一个按钮的动作不是测试用例,测试用例的目的是发现问题,动作怎么能发现问题? 动作只是步骤。
所以:测试用例---检查这个按钮;   步骤-----点击这个按钮。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-5-23 12:47:38 | 只看该作者
测试用例的颗粒度是一件很麻烦的事情。

从执行的角度来看,
最小颗粒应该是对应一个不可拆分的功能点(可以包括多个步骤和检查点)。这样,才能保证执行用例时能够和功能进行一一对应,不会出现故障的误报或者错报。

从管理的角度来看,
可以设计不同的用例颗粒层次,高层的用例可以由低层的用例组合形成,类似于函数定义,一个高级函数可以调用多个低级函数。但如何确立架构和如何进行合理的等级划分是比较需要功夫的。

先完成最小颗粒测试用例的积累,在此基础上,通过用例的组合,实现高层次的用例架构。
回复 支持 反对

使用道具 举报

该用户从未签到

7#
 楼主| 发表于 2006-5-23 12:52:22 | 只看该作者
楼上说的对 是我写的不清楚
回复 支持 反对

使用道具 举报

该用户从未签到

8#
 楼主| 发表于 2006-5-23 13:02:35 | 只看该作者
slide〉你刚刚讲的用例颗粒层次 我不是很理解 请结合例子描述讲解 谢谢
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2006-5-23 18:01:25 | 只看该作者
颗粒度的层次对于可以自动执行的用例来说更有意义。
先写最底层的脚本,然后再组合底层脚本形成高一级的脚本,然后再高一级,如此不断积累。
就和写程序是一样的。

对于手动执行的用例来说,可能划分层次的意义不是很大,因为毕竟还是要一个个的手工执行,但毕竟 组织结构会比从前清楚了。

我前面强调的“最小颗粒应该是对应一个不可拆分的功能点”可能更符合你的问题。注意对应的是需求,而且不可再拆分。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2006-6-30 18:16:11 | 只看该作者
个人感觉粒度应该和项目有关,和具体的功能点有关。
粒度过粗可能会遗漏部分bug,并且也会给其它执行该用例的人造成麻烦;粒度过细工作量太大,并且如果需求变动的话可能会引起大批量的修改case。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    11#
    发表于 2006-7-3 15:33:59 | 只看该作者
    严重同意Slide。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2006-7-4 18:32:20 | 只看该作者
    重要功能颗粒密集度高
    通用功能可以试用通用测试粒度,密集度应该可以大致界定。
    一般功能密集度可能会根据项目或是时间来确定。
    特殊功能同样密集度高

    总之还是在一个恒定标准上小范围变化。
    这个恒定标准,目前大多数公司是拿功能来界定的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2006-7-13 11:31:28 | 只看该作者
    呵呵,又看到slide的回复。
    说的很有道理呀。我也正在被这个粒度的问题难住,slide的回答很有帮助,谢谢啦
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2006-7-22 12:51:32 | 只看该作者
    关于这个问题,有兴趣的可以参考偶以前的一篇文章。

    http://jackei.cnblogs.com/archive/2005/03/03/112201.html
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-1-8 14:41:58 | 只看该作者
    颗粒度的大小从根本上来说取决与两点
    1.所要测试模快对该系统的整体影响.看其重要性.个人认为,假如你非要为了一个字体的样式而写了一大长串的测试用例,(当然一个字体的样式也写不出太多.在这只是举个例),那么这个颗粒度就县的毫无意义了.另一个例,如设计一个会员的权限问题.在这个地方如果测试过程中的颗粒度很大.那么一旦程序发布之后.就会发现,啊,原来还有那么多的地方被忽略掉了.
    2.颗粒度的大小还取决与客户对产品的要求.如果客户跟你说这个地方你必须仔仔细细的测试.那么我们在写测试用例的时候.这个颗粒度一定要小了.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-1-8 17:44:27 | 只看该作者
    刚刚看到这个帖子标题时,还不清楚何所谓“粒度”,看大家讨论的这么热烈,让我也明白了一点点,原来一直困扰我的就是“粒度”啊,呵呵。这个粒度还真是个麻烦事啊!
    楼上说得我也觉得挺有道理啊。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-1-10 10:40:12 | 只看该作者
    原帖由 Mia 于 2006-5-23 11:48 发表


    点击一个按钮的动作不是测试用例,测试用例的目的是发现问题,动作怎么能发现问题? 动作只是步骤。
    所以:测试用例---检查这个按钮;   步骤-----点击这个按钮。

    我觉得点击按钮就是为了检查点击按钮以后能否进行预期的操作,这一点是会有问题出现的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-1-10 10:55:11 | 只看该作者
    呵呵,我看了这个帖子后发下呢了,就是因为写用例前,粒度的标准没考虑好,才导致后来越写越觉得用例很乱sdlkfj5
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2007-6-22 19:41:15 | 只看该作者
    我是测试新手,谢谢帮助,现在急着充电 sdlkfj3
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-6-28 16:08:58 | 只看该作者
    有点收获
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-9 05:55 , Processed in 0.080407 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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