51Testing软件测试论坛

标题: 软件测试用例设计难在哪里？ [打印本页]

作者: 阿蛮的开心姐 时间: 2018-3-26 15:21
标题: 软件测试用例设计难在哪里？
试用例设计是测试过程中非常重要的一个活动，不管是文档化的设计输出，还是只是存在于他们脑海中的测试
思想，其质量都会直接影响测试执行的质量。

【java学习资料免费分享微信：tangniu520666，备注“4”】

尽管每个测试人员都掌握了不少的测试用例设计技术与方法，例如：等价类划分、状态转换测试等，但是如何
将它们应用到具体的测试对象测试中去，很多测试人员都会感觉有些力不从心，甚至有无从下手的感觉。

下面是针对某个功能模块的一个简单的需求描述：该基本功能是为了创建某个条目，它的基本需求如下：

假如dataBit0 = 0，并且cBPDU或者pBPDU的值不为1，那么创建请求会被拒绝。假如dataBit0 = 0，并且cBP
DU = 1或者pBPDU = 1，在满足下面条件下可以创建成功：

（1）其他的bit不能为1；

（2）TD的取值必须是Guranteed；

（3）VLANpop的取值必须是disabled；

假如你得到这样的一个需求描述，你准备如何来设计该功能模块的测试用例？通常来说，测试人员拿到需求
规格说明之后，会根据其中定义的需求条目设计测试用例，类似于如下过程。
[attach]112316[/attach]
针对上面的需求描述，根据图1直接设计测试用例，会不会觉得有些迷茫呢？即使测试人员设计了多个测试用
例，覆盖了每条测试需求，是不是也会觉得评估测试覆盖率比较困难？

实际上，需求规格说明通常是针对开发人员而写的，并不一定直接适合测试的要求。因此，假如测试人员希
望能够更好的进行测试用例设计，需要将需求规格说明转化成为测试人员可以方便使用的语言很重要，即在
需求规格说明和设计测试用例之间增加一个桥梁：模型。在建立模型的过程中，测试人员不仅需要学习需求
规格说明，同时也需要了解各种测试设计技术与方法，并能将两者数量的结合起来。图2是增加了“模型”概
念的测试用例设计过程。

[attach]112317[/attach]
还是以上面的需求描述为例，我通过学习该需求之后，发现它可能可以与决策表技术结合起来。因此，我将
上述需求翻译为适合决策表技术的各种条件与输出，并

根据它们的不同组合得到不同的结果。图3是我针对上述需求描述，基于决策表技术得到的初始决策表，然
后可以基于此进行决策表优化，直至得到概要和详细的测

试用例列表。

[attach]112318[/attach]
根据图2的过程得到的图3的结果，是否觉得整个测试设计过程更加清楚，而且更加容易进行测试覆盖率等方面
的评估？注意：这里只是根据需求描述得到的一些测试用例，并没有考虑其他方面的测试用例，例如非功能测
试用例等。

需求规格说明对测试人员很重要，测试设计技术与方法也很重要，但更重要的是测试人员如何能够将两者有效
的结合起来，并在此基础之上建立适合测试设计和评

估的“模型”。而这通常是测试用例设计的难点所在，同时也是体现测试人员技术含量的地方。下面是测试人员
在建立模型过程中可以参考的一些方向：

1、基于黑盒测试技术，例如：决策表模型、状态转换模型、正交矩阵模型等；

2、基于测试类型，例如：质量特性模型、缺陷分类模型等；

3、基于全局因素的全局因素模型；

4、基于功能交互的功能交互模型；

测试设计过程中建立有效的“模型”，测试人员设计测试用例相对会比较容易，并且可以很好的提高测试覆盖率，
从而帮助提升产品质量。另一方面，通过建立模型，也可以帮助测试人员有效的评审测试对象功能的描述，例
如可以发现需求中定义不清楚、遗漏等方面的问题。

作者: zsl1212 时间: 2018-4-10 16:52

谢谢楼主分享

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)