用例中的组合

dj02304

我在写一个控制器的用例，控制器中的主要功能按键有：主页、返回、静音、音量+、音量-、播放、选时、快进、快退、暂停、停止。

现在，我要设计他们的组合，一次操作需要按键1次到3至4次，那么，这样的组合究竟有多少种？我已经算晕了，目前写出了607个，不知道还少多少？谁帮我统计一下啊。。。

当然，要是肯帮我直接设计出来，小弟更是不胜感激。
本人邮箱地址： dj02304@163.com

谢谢～～～

Leon

有必要这样做么？
如果你一定要这样做，那么所有数量＝P(1,11)+[P(2,11)+P(1,11)]+[P(3,11)+P(1,11)+C(1,11)*C(1,10)*P(3,3)/P(2,2)]+[P(4,11)+P(1,11)+C(1,11)*C(1,10)*P(4,4)/P(2,2)+C(1,11)*C(1,10)*P(4,4)/P(3,3)]就OK了，其中P(n,m)表示从M个元素中取出N个元素的所有排列数,C(n,m)B表示从 M个元素中取出N个元素的所有组合数。
满足你了，自己慢慢算去吧～～

dj02304

哦，没有必要这么做啊，那么应该如何做才好呢？给个建议，我这几天因为这真是头都大了

rockday

功力不够
帮你顶下把

slide

简单的遍历肯定不是一个好的办法。
首先先分类吧：
1、主页、返回、
2、静音、音量+、音量-、
3、播放、选时、快进、快退、暂停、停止。

确认各个类之间不会相互影响，进行解耦，
然后，测试每一类的功能组合，只有最后一个稍微复杂一些。

eryue15

ding

Mia

原帖由 slide 于 2006-4-25 23:25 发表
简单的遍历肯定不是一个好的办法。
首先先分类吧：
1、主页、返回、
2、静音、音量+、音量-、
3、播放、选时、快进、快退、暂停、停止。

确认各个类之间不会相互影响，进行解耦，
然后，测试每一类的功能 ...

很有道理：）

dj02304

分类是个好办法，但是不能因为各个类不相互影响就不组合在一起了，因为程序会怎样谁都不清楚，没准按一个快进，再按一个静音就出问题了呢？只是个例子，最终如何，就需要再考虑了～

Mia

楼上说得很有道理。 我在测试中也遇到过这样得问题。
疑问：测试中有必要把遍历所有都写下来么。好像我做过得测试都不需要这样得。

李文

建议看看正交表方面的东西

slide

原帖由 dj02304 于 2006-4-27 13:42 发表
分类是个好办法，但是不能因为各个类不相互影响就不组合在一起了，因为程序会怎样谁都不清楚，没准按一个快进，再按一个静音就出问题了呢？只是个例子，最终如何，就需要再考虑了～

这就是开发质量对于测试的影响了，如果整体设计优秀，模块划分的好，可以解除耦合状态的话，测试相对于会简单很多，对于解耦可以通过审查设计和简单验证来保证。但如果开发无法保证，所有功能都搅在一起，那么所有组合都要遍历，测试工作量会呈几何级数上升，直到不可测试。
就像你在测试这个模块的时候，不会想到去验证这个界面下的操作对于其他界面可能有的影响，你已经认为它们是无关的，但真的无关吗？你要不要验证一下试试？呵呵。

dj02304

无奈无奈，就算是开发保证不会有问题，绝对不相关，也要验证的呦

那么，怎么才能更好的解决这样的问题呢？

天生我才

那么我们如何在开发中，即让模块很好的解决耦合问题，又让模块之间保持应有的联系呢？是否需要前期细致的、并有大局观的设计呢？

dengwang

这种情况在我们的工作中也遇到过。我想这时应该考虑到时间，如果时间足够的话，是可以考虑对核心模块进行耦合状态的测试。但想全部遍例， 恐怕是不可能的事情。

组合测试

可以考虑使用组合测试的方法啊。
《软件测试的艺术》中有介绍的

davids

是的，我有同感！
就是感觉会有很多功能上的组合，而且这些组合又都是很有可能会用到的，但将这些功能都组合起来，用例的数量确实太大了！
对于这样的问题，光分类应该不是一个很好的解决办法啊！
还有不有其他更好的方法啊？