一个判定表的疑问

slide

比较重要的是剔除掉不可能出现的逻辑组合。

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

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

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

所以，怎么合并都是对的，也都是有道理的，但采用哪个，要看实际的情况了。

slide

我的意思就是说：化简后得到的“-”项目，表示任何状态都是可以的，但到实际用例中，任何状态又是一个什么状态呢，还是要分解成为具体的状态ABC，否则怎么来执行呢。

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

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

也是看到问题才想到的，有点说不清楚的感觉，不明白就再讨论吧，呵呵。