51Testing软件测试论坛
标题:
正交试验设计测试用例遇到的问题
[打印本页]
作者:
stonemary
时间:
2007-6-28 17:11
标题:
正交试验设计测试用例遇到的问题
看了使用正交试验设计法设计测试用例以后,我也试着使用这样的方法来设计用例,但是,在设计的过程中,遇到了一些问题,希望大家指点:
因素:书名,编号
水平数:已经存在的值、 不存在的值、空格、乱码、空、模糊值。
取正交表:L25(56)(因素数为6,水平数为5、行数为25)。
这个正交表的因素是不是和我要使用的因素数相差太远了,是不是会走很多不需要走的路。那么,应该怎么样的优化一下呢?
本来例子上的水平数只有两个,但是,我认为这样好像还有一些问题不能发现,比如,我就遇到过填写空格以后,还提取记录出来了,并且报脚本错误的情况。所以,我把水平数增加了很多。
作者:
jackei
时间:
2007-6-29 13:54
楼主联系 zension 吧,国内我见过的最早专门研究 测试用例+正交试验设计的高手了。
可以用 zension 在论坛内搜索一下,他也有文章说这个的。
作者:
stonemary
时间:
2007-6-29 13:57
thank you very much~
我正是看了zension的PPT,尝试这使用这样的方法来做。
作者:
jackei
时间:
2007-6-29 15:59
呵呵,别急,我把他请来看他有没有时间帮你解决问题 ^_^
作者:
zension
时间:
2007-6-30 00:24
标题:
对楼兄的关于正交表的回复
下午jackei在MSN把网址发给我时,一直没有抽出时间来回,抱歉!
楼主仁兄提到的几个问题,我提出个人的见解,不正确之处还望继续讨论!
第一:关于对这个例子的优化的问题:
就单拿这个例子来说,是没有办法来优化的,从数理统计的角度来说,数学上的问题是没有办法再简化正交表,这些表是数学家通过证明和推导出来的,已有的方法我们有时间可以研究,都是一些成熟的方法,不过,咱们可以完全使用已经建立的正交表,这样更节省时间些
第二:已选定因素数和水平数之后,就可以在已有的正交表中进行查找,并进行套用而已;但对于如何选取因素数和水平数,这就是一个测试角度的问题, 测试的侧重点的问题,以及测试的时间及系统的特殊性问题
针对因素数的选取,这涉及到系统的特殊性问题,测试侧重点的问题,比如针对安全性比较高的系统(飞机导航系统、银行系统),他们对安全性要求比较严格,这个时候必须把所有的各种情况到,否则造成的后果是灾难性的,而这个时候可能正交表就不适用了。正交表是选取有代表性的用例进行测试,一般情况下会出现的缺陷都会在这个有代表性的用例是被捕捉到,但并非保证全部所有的情况,所以针对安全性比较高的系统,也希望把每种能够测试的情况都测试一下,而此时测试的时间和成本可能要放到次要的位置了
但对于一般性系统,如果有一些出错但并不会造成什么严重的后果,这样的系统测试时要把它与测试的时间、市场的动向及测试的人员资本和客户群的类型相结合,还有与这个功能与系统的使用的频率有关;当然从测试的角度来讲,是尽是找到第一个能够找到的缺陷,但从公司管理层的方面考虑,必须要考虑到时间和资金;但这两个方面要取一个平衡点,所以测试时最好也要把握这一点,在资金和时间允许的范围内能够测试多少就要测试多少,在允许的范围内尽量的详细一点。所以针对因素数是可以取舍掉一些取舍比较小的因素,当然在选择因素的水平数时也可以这样做一些取舍,在允许的范围内把所有的水平数都考虑进去,并对它进行测试;
所以针对您举的例子中,原来水平数是两个,后来把它变为六个,但你看一下在时间和资金、及使用的频率的情况下对它进行取舍
第三:有些情况下是不能套用正交表的,所以并非每种情况下都可以适用的,像这个情况,如果每个因素选择两个水平数的话,乘起来才四种,所以用正交表就不太合适了,所以针对比较复杂的情况使用正交表是最合适的
用多了之后就会发现,它可以用在更大的方面,也就是可以对整个系统用正交表进行分类,然后在这个分类下进行设计测试用例,当然这个难度很大,而且一般情况下老板也不会要求这样做,除非在时间比较紧迫、资本比较紧张时需要缩减测试时间时才被允许这样做,所以正交表运用到测试用例的设计中时需要更多的技巧
记得上学的时候老师说过一句话,在提到数理统计这门课时,说,数理统计其实是一门艺术,是建议在数学上面的艺术,数学理论都是一样的,但如何运用得好就是一门艺术了,所以运用正交表也差不多。
测试方面+公司管理方面=设计出比较适用的测试用例,我个人认为是这样,也是我的体会,不知道你认为呢?
关于正交表的如何运用,咱们以后慢慢的共同探讨
作者:
stonemary
时间:
2007-7-2 10:59
非常感谢zension,也很感谢jackei的帮忙。
在设计用例这一方面,我始终都是有困惑的,现在,我建议公司尽早的把项目资料给测试人员,我希望的是测试和开发并行。在开发的同时,尽早的理解项目,如果资料较为全面,就可以开始设计用例。但是,设计用例时候也没有使用到具体的设计用例的方法,最多就是边界值法和等价类法。这个是最基本要考虑的。在其他的时候,设计用例都是凭着经验和逻辑思维,认为这个地方需要有几个测试点,就针对这些测试点写测试用例。这样的写法,会让人有点凭空猜测的感觉,所以,我希望能让测试用例设计的有理有据,至少能够建立在理论的基础之上。
关于测试的时候也需要考虑到公司的管理层的理念,我非常的赞同这一点。不过,我还是希望尽量的找出多的错误,再根据用户的喜好、管理层的决定等来定义BUG的优先级,决定是否一些BUG是无关痛痒的。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2