软件测试用例设计难在哪里？

阿蛮的开心姐

试用例设计是测试过程中非常重要的一个活动，不管是文档化的设计输出，还是只是存在于他们脑海中的测试
思想，其质量都会直接影响测试执行的质量。

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

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

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

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

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

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

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

假如你得到这样的一个需求描述，你准备如何来设计该功能模块的测试用例？通常来说，测试人员拿到需求
规格说明之后，会根据其中定义的需求条目设计测试用例，类似于如下过程。

针对上面的需求描述，根据图1直接设计测试用例，会不会觉得有些迷茫呢？即使测试人员设计了多个测试用
例，覆盖了每条测试需求，是不是也会觉得评估测试覆盖率比较困难？

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


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

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

试用例列表。


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

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

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

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

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

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

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

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

zsl1212

谢谢楼主分享