一道测试设计问题，高手请进
假设按功能定义,某模块接受n个参数作为输入,并输出结果。 设这n个参数分别为x1 ,x2 ,· · · ,xn。 若忽略功能定义,x1 可取的全部值为X1’ ,x2 可取的全部值为X2’ ,依此类推;若按功能定义,则只能取x1 ∈ X1 ⊆ X1’,x2 ∈ X2 ⊆ X2’,· · · ,xn ∈ Xn ⊆ Xn’ 。 某开发员实现了该模块的第一个版本,该版本对数据的范围未作任何检查,经过简单的几个测试,发现输入xi ∈ Xi , （i= 1, 2, · · · , n)中的数据时,能得到正确的结果;而输入的数据xi 中存在xik ∉ Xi ,即xik ∈ Xi’\ Xi 时,出现两种情况:1) 输入数据本身虽有意义,但需求未定义,因此输出了无效数据;
2) 输入的数据本身无意义,类似使用空指针,或数学上的除以零之类的错误,结果是导致程序崩溃。
于是该开发人员将代码修改,得到第二个版本:
正确的结果 输入已经定义的数据,
输出 = 无结果输出 输入有意义,但未定义的数据,
抛出异常 输入无意义的数据。
问题
(1) 若要用穷举法将此模块做一遍黑盒测试,要100%的覆盖率,对于(1)所述三种情况各至少做多少次测试?将次数以集合的个数的表达式表示(若以|A|表示集合A中的元素的个数)。
(2) 假设此模块是有用户界面的,输入、输出是通过用户界面进行的。从第一个版本到第二个版本的改动,可测性如何?如果此模块是一个C++语言函数,可测性又如何?
(3) 如何测试此模块? 这个问题，我已纠结了一天，欢迎大家一起讨论。 如果你说的每个参数都是有限值的话，那么对于问题2来说，可以进行自动化测试，让计算机去完全遍历即可。但是测试并不等同于要完全遍历，is it neccessary? 本帖最后由 Jackc 于 2013-5-24 13:14 编辑
假设按功能定义,某模块接受n个参数作为输入,并输出结果。 设这n个参数分别为x1 ,x2 ,· · · ,xn。 若忽略 ...
jayowenhui 发表于 2013-5-22 13:30 http://bbs.51testing.com/images/common/back.gif
1. 过滤需求描述，筛选出测试目标
LZ 的文字型需求描述较为复杂，我们可以用4个测试范围的图形来重构测试目标的描述，如下：
2. 问题分析
(1) 若要用穷举法将此模块做一遍黑盒测试,要100%的覆盖率,对于(1)所述三种情况各至少做多少次测试?将次数以集合的个数的表达式表示(若以|A|表示集合A中的元素的个数)。
分析：
单从问题文字描述，“100%的覆盖率”是啥米意思，明显就是个坑？(不管这个坑，继续看问题下面的描述)
“所述三种情况各至少做多少次测试” 。
核心功能测试穷举次数 = |n|
需求功能测试穷举次数 = |n’|
异常/容错测试穷举次数 = ？？？？（答案只能是无穷大，题目中“xik ∉ Xi ,即xik ∈ Xi’\ Xi ” 这个描述是坑，xik ∈ Xi’\ Xi 只是xik ∉ Xi 的其中一种测试数据类型而已。。举一个测试实体的例子来说明这个问题：整型数字编辑框没有做INT输入限制，那么它的异常测试数据可能是“浮点数”，也可能是“文本字符串”。）
(2) 假设此模块是有用户界面的,输入、输出是通过用户界面进行的。从第一个版本到第二个版本的改动,可测性如何?如果此模块是一个C++语言函数,可测性又如何?
分析：
首先确认开发人员的修改的效果：
“抛出异常 输入无意义的数据" = 规范数据输入，修证xik ∉ Xi 的问题
然后，再看遗留的问题
"无结果输出 输入有意义,但未定义的数据"= 正常的输入，但得到的实际结果不在输出结果的需求定义范围内？（好吧，我只能理解为，题目描述中隐藏了1个条件，输出结果一开始是进行了定义的，比如定义字符串长度这一类，而最终测试实际结果，字符串长度越界了，类似这种测试实体。 但是，题目描述中没有任何关于预期结果的定义说明，只能说：坑！）
接着来看实际需要处理的问题。
“可测性如何?”
界面可测试性： 界面类型的测试目标具有特殊属性 -- UI 。所以只要测试数据部署恰当，它是可以判断出"无结果输出 输入有意义,但未定义的数据"这个测试点的正确性。实体化预期输出结果后，可以得到类似以下的测试结果描述：输出结果显示超出显示约定范围；输出结果显示为乱码。。等等
当然“抛出异常 输入无意义的数据 ”这一点在界面上也是很好检查的，就不多说了。
代码可测试性： 题目这里选了C++语言函数作为测试目标，其实根本上来说，出题者就是想让测试目标无法检测“输入参数约束”和“越界”这2个属性。所以，一般来说，C++语言函数是不能判断出“无结果输出 输入有意义,但未定义的数据”这个测试点的正确性的。不过，这个地方有一个坑，“你Y以为编译器不能检查出来越界，我们的测试脚本设计人员，就不能检查出来？检查点做一个结果输出的“越界”判定不就OK了？”（这一点，不知道出题者故意的还是无意的，反正也就是这样了）。
而对于“输入参数的约束”在代码上的测试其实也和“越界”差不多，差异就在于，输入参数约束的函数是否在测试范围内。
所以，代码可测性有两个答案：常规方式 = 无可测性； 变通变通 = 有可测性
(3) 如何测试此模块?
这部分真心不想写了，LZ可以根据以上两个问题的，自己思考一下怎么来规避风险和提升覆盖。
个人感想：针对如此蛋疼一个题目，我觉得没有必要再去讨论如何测试。真心希望此类的题目最好都能实体化，题目描述尽量多一些信息含量，这样才能达到检查测试人员测试分析的能力。
PS：第一眼看到这个题目，我第一个反应是“MyGod, 我的离散数学全都还给大学老师了” 这道题我研究了两天，也有了一个初步的答案，楼上版主的答案分析得还是挺到点的，那个模型图做得不错。 这个问题我研究了两天，已经基本有了初步的答案，楼上版主的答案基本都在点上，特被是模型图做得不错。
页:
[1]
