51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 4502|回复: 9
打印 上一主题 下一主题

[讨论] 一个判定表的疑问

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-8-8 18:42:01 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
郑人杰老师的书中讲到判定表的设计方法,
”在实际使用判定表时,常常先把它化简。化简工作是以合并相似规则为目标的“。并且举了例子,但不明白化简的标准是什么,如果同时有几多个条件可以化简时,怎么选择?
如图:
第4列、第8列可以化简
第6列、第8列可以化简
为什么选择了后者?

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

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

使用道具 举报

该用户从未签到

2#
发表于 2006-8-8 20:00:00 | 只看该作者
第四列哪有化简?
从表中应是1-2列,5-6列,7-8列合并。

化简要根据具体情况决定,一般是把类似的项合并成一项,把逻辑上不可能成立的项删除。
回复 支持 反对

使用道具 举报

该用户从未签到

3#
 楼主| 发表于 2006-8-9 09:51:21 | 只看该作者
谢谢楼上的
图上合并的应该是1-2列,5-7列,6-8列(根据下面的图可以看得出)。

即使按你说的 :从表中应是1-2列,5-6列,7-8列合并。
那为什么不合并1-3列,而合并1-2列啊?而实际1-3列合并也未尝不可。(1-3列合并:如果大于50马力,并且运行超过10年,则不管是不是有维修记录,都要优先进行维修。)

不管合并的是哪一组,这个合并有什么标准吗?
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2006-8-9 10:06:19 | 只看该作者
这要根据具体情况决定,从两张图上我无法判断哪两个合并不影响到测试效果。
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2006-8-9 13:21:24 | 只看该作者
比较重要的是剔除掉不可能出现的逻辑组合。

对于逻辑进行的化简,其实主要是为了看起来更方便、描述起来更简单,并没有实际更多的作用,凡是被合并了的项,设计具体用例实现的时候,还是需要再拆分开的。

当然,具体到实际的例子,测试用例采用和开发实际逻辑一致的划分模式会比较好,可能更容易进行测试用例的取舍,也就是说,如果你按照表的描述的逻辑和程序里面的if else判断一致的话,会有一些好处。

例如:某个条件下,软件判定A是无关项目,就不考虑它的状态了,对应判断表中“-”的项目。进行一次测试之后,如果能够确认判断逻辑没有问题,以后的测试用例可以简化或者省略,用某个状态来代替“-”,而不是要用所有状态来代替“-”,使验证工作更容易。

所以,怎么合并都是对的,也都是有道理的,但采用哪个,要看实际的情况了。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
 楼主| 发表于 2006-8-9 17:17:10 | 只看该作者
多谢null2、slide两位。
不过还要问 slide一下,你上面所说的 “凡是被合并了的项,设计具体用例实现的时候,还是需要再拆分开的。”
如果不合并,出现的列会很多,不只是看起来、描述起来不方便,也不可能完全设计那么多用例。既然合并,就是按合并后的列进行设计用例(去掉关系不大,或不可能出现的列),为什么还要说设计用例时还要是拆分开的?这样合并不是没有意义了吗,难道仅仅为了看起来更方便?

能不能再解释一下。多谢了
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-8-10 13:25:15 | 只看该作者
我的意思就是说:化简后得到的“-”项目,表示任何状态都是可以的,但到实际用例中,任何状态又是一个什么状态呢,还是要分解成为具体的状态ABC,否则怎么来执行呢。

个人看法,合并过程对于开发还是有些意义的,通过合并可以减少判断的条件,简化程序的逻辑。但对于黑盒测试来说,合并意义不是很大。要满足覆盖率的要求,就要所有组合都验证到。

但对于灰盒测试来说,如果了解了开发的处理逻辑,把“-”代表的ABC作为同一个等价类,就可以减少组合的种类了,这种情况下,不会影响到你的分支覆盖率。也就是前面提到的,用某个状态来代替“-”,而不是要用所有状态来代替“-”。但ABC之所以能成为一个等价类,要通过你程序开发的逻辑来保证,而不是随便分的,如果开发换了一种划分方式,这时候,测试的逻辑和开发的逻辑不一样了,原来的等价类就无效了,原来简化的测试用例,可能覆盖不了所有的逻辑分支,从逻辑上来看就不完备了。

也是看到问题才想到的,有点说不清楚的感觉,不明白就再讨论吧,呵呵。
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-8-10 19:03:51 | 只看该作者

学问学问就是要提出疑问,其实还可以进一步合并!

楼主提的对,有疑问时对的
还可以进一步合并,
是否注意:如果运行超过10年,则不管其它如何,都要优先进行维修。
按我的理解 1-3-5-7可以合并。
而4,6,8 的合并选择看你愿意保留对 纪录,马力哪个条件了。此所谓实际情况而定,4-8 ,6-8都可以,选一个就是了。
最后我理解的合并后就4项。  1-3-5-7合并到下列1  2 不动 ,4-8 合并为3 ,  6 为4;


  条件   1      2      3      4
  马力   -      Y       -      N
  纪录   -      Y      N      Y
10年    Y     N      N      N
结果
  优先   X     X
  其他                   X      X

你们以为如何?

欢迎提出意见!
回复 支持 反对

使用道具 举报

该用户从未签到

9#
 楼主| 发表于 2006-8-11 12:00:46 | 只看该作者
多谢slide,基本已经明白,不过理论的东西要在实际中应用起来,还是要多实践的
lxm合并的也很有道理,不过这里没有环境,不太清楚以哪个标准为基础最好。不过对我来说,已经搞清楚了,多谢
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2006-9-18 15:33:23 | 只看该作者
郑老师的杰作还没拜读过
个人觉得作为测试来说,能详细的尽量不要简化,往往BUG就出现在这些简化的地方
当然,在时间不够充足的情况下可采用这种方法,以保证基本的准确
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-4-29 00:49 , Processed in 0.072394 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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