正交试验设计测试用例遇到的问题

stonemary

看了使用正交试验设计法设计测试用例以后，我也试着使用这样的方法来设计用例，但是，在设计的过程中，遇到了一些问题，希望大家指点：
因素：书名，编号
水平数：已经存在的值、 不存在的值、空格、乱码、空、模糊值。
取正交表：L25（56）（因素数为6，水平数为5、行数为25）。
这个正交表的因素是不是和我要使用的因素数相差太远了，是不是会走很多不需要走的路。那么，应该怎么样的优化一下呢？
本来例子上的水平数只有两个，但是，我认为这样好像还有一些问题不能发现，比如，我就遇到过填写空格以后，还提取记录出来了，并且报脚本错误的情况。所以，我把水平数增加了很多。

jackei

楼主联系 zension 吧，国内我见过的最早专门研究 测试用例+正交试验设计的高手了。

可以用 zension 在论坛内搜索一下，他也有文章说这个的。

stonemary

thank you very much~
我正是看了zension的PPT，尝试这使用这样的方法来做。

jackei

呵呵，别急，我把他请来看他有没有时间帮你解决问题 ^_^

zension

下午jackei在MSN把网址发给我时，一直没有抽出时间来回，抱歉!

楼主仁兄提到的几个问题，我提出个人的见解，不正确之处还望继续讨论!

第一：关于对这个例子的优化的问题：
就单拿这个例子来说，是没有办法来优化的，从数理统计的角度来说，数学上的问题是没有办法再简化正交表，这些表是数学家通过证明和推导出来的，已有的方法我们有时间可以研究，都是一些成熟的方法，不过，咱们可以完全使用已经建立的正交表，这样更节省时间些

第二：已选定因素数和水平数之后，就可以在已有的正交表中进行查找，并进行套用而已；但对于如何选取因素数和水平数，这就是一个测试角度的问题， 测试的侧重点的问题，以及测试的时间及系统的特殊性问题

针对因素数的选取，这涉及到系统的特殊性问题，测试侧重点的问题，比如针对安全性比较高的系统(飞机导航系统、银行系统)，他们对安全性要求比较严格，这个时候必须把所有的各种情况到，否则造成的后果是灾难性的，而这个时候可能正交表就不适用了。正交表是选取有代表性的用例进行测试，一般情况下会出现的缺陷都会在这个有代表性的用例是被捕捉到，但并非保证全部所有的情况，所以针对安全性比较高的系统，也希望把每种能够测试的情况都测试一下，而此时测试的时间和成本可能要放到次要的位置了

但对于一般性系统，如果有一些出错但并不会造成什么严重的后果，这样的系统测试时要把它与测试的时间、市场的动向及测试的人员资本和客户群的类型相结合，还有与这个功能与系统的使用的频率有关；当然从测试的角度来讲，是尽是找到第一个能够找到的缺陷，但从公司管理层的方面考虑，必须要考虑到时间和资金；但这两个方面要取一个平衡点，所以测试时最好也要把握这一点，在资金和时间允许的范围内能够测试多少就要测试多少，在允许的范围内尽量的详细一点。所以针对因素数是可以取舍掉一些取舍比较小的因素，当然在选择因素的水平数时也可以这样做一些取舍，在允许的范围内把所有的水平数都考虑进去，并对它进行测试；

所以针对您举的例子中，原来水平数是两个，后来把它变为六个，但你看一下在时间和资金、及使用的频率的情况下对它进行取舍

第三：有些情况下是不能套用正交表的，所以并非每种情况下都可以适用的，像这个情况，如果每个因素选择两个水平数的话，乘起来才四种，所以用正交表就不太合适了，所以针对比较复杂的情况使用正交表是最合适的

用多了之后就会发现，它可以用在更大的方面，也就是可以对整个系统用正交表进行分类，然后在这个分类下进行设计测试用例，当然这个难度很大，而且一般情况下老板也不会要求这样做，除非在时间比较紧迫、资本比较紧张时需要缩减测试时间时才被允许这样做，所以正交表运用到测试用例的设计中时需要更多的技巧

记得上学的时候老师说过一句话，在提到数理统计这门课时，说，数理统计其实是一门艺术，是建议在数学上面的艺术，数学理论都是一样的，但如何运用得好就是一门艺术了，所以运用正交表也差不多。

测试方面+公司管理方面=设计出比较适用的测试用例，我个人认为是这样，也是我的体会，不知道你认为呢？

关于正交表的如何运用，咱们以后慢慢的共同探讨

stonemary

非常感谢zension，也很感谢jackei的帮忙。
在设计用例这一方面，我始终都是有困惑的，现在，我建议公司尽早的把项目资料给测试人员，我希望的是测试和开发并行。在开发的同时，尽早的理解项目，如果资料较为全面，就可以开始设计用例。但是，设计用例时候也没有使用到具体的设计用例的方法，最多就是边界值法和等价类法。这个是最基本要考虑的。在其他的时候，设计用例都是凭着经验和逻辑思维，认为这个地方需要有几个测试点，就针对这些测试点写测试用例。这样的写法，会让人有点凭空猜测的感觉，所以，我希望能让测试用例设计的有理有据，至少能够建立在理论的基础之上。
关于测试的时候也需要考虑到公司的管理层的理念，我非常的赞同这一点。不过，我还是希望尽量的找出多的错误，再根据用户的喜好、管理层的决定等来定义BUG的优先级，决定是否一些BUG是无关痛痒的。