SWTBOK测试实践系列(8) -- 测试用例设计难在哪里?
2014-09-11 13:38
260 查看
测试用例设计是测试过程中非常重要的一个活动,不管是文档化的设计输出,还是只是存在于他们脑海中的测试思想,其质量都会直接影响测试执行的质量。
尽管每个测试人员都掌握了不少的测试用例设计技术与方法,例如:等价类划分、状态转换测试等,但是如何将它们应用到具体的测试对象测试中去,很多测试人员都会感觉有些力不从心,甚至有无从下手的感觉。
下面是针对某个功能模块的一个简单的需求描述:该基本功能是为了创建某个条目,它的基本需求如下:
假如你得到这样的一个需求描述,你准备如何来设计该功能模块的测试用例?通常来说,测试人员拿到需求规格说明之后,会根据其中定义的需求条目设计测试用例,类似于如下过程。
图1 通常的测试用例设计
针对上面的需求描述,根据图1直接设计测试用例,会不会觉得有些迷茫呢?即使测试人员设计了多个测试用例,覆盖了每条测试需求,是不是也会觉得评估测试覆盖率比较困难?
实际上,需求规格说明通常是针对开发人员而写的,并不一定直接适合测试的要求。因此,假如测试人员希望能够更好的进行测试用例设计,需要将需求规格说明转化成为测试人员可以方便使用的语言很重要,即在需求规格说明和设计测试用例之间增加一个桥梁:模型。在建立模型的过程中,测试人员不仅需要学习需求规格说明,同时也需要了解各种测试设计技术与方法,并能将两者数量的结合起来。图2是增加了“模型”概念的测试用例设计过程。
图2 改进的测试用例设计
还是以上面的需求描述为例,我通过学习该需求之后,发现它可能可以与决策表技术结合起来。因此,我将上述需求翻译为适合决策表技术的各种条件与输出,并根据它们的不同组合得到不同的结果。图3是我针对上述需求描述,基于决策表技术得到的初始决策表,然后可以基于此进行决策表优化,直至得到概要和详细的测试用例列表。
图3 初始决策表
根据图2的过程得到的图3的结果,是否觉得整个测试设计过程更加清楚,而且更加容易进行测试覆盖率等方面的评估?注意:这里只是根据需求描述得到的一些测试用例,并没有考虑其他方面的测试用例,例如非功能测试用例等。
需求规格说明对测试人员很重要,测试设计技术与方法也很重要,但更重要的是测试人员如何能够将两者有效的结合起来,并在此基础之上建立适合测试设计和评估的“模型”。而这通常是测试用例设计的难点所在,同时也是体现测试人员技术含量的地方。下面是测试人员在建立模型过程中可以参考的一些方向:
- 基于黑盒测试技术,例如:决策表模型、状态转换模型、正交矩阵模型等;
- 基于测试类型,例如:质量特性模型、缺陷分类模型等;
- 基于全局因素的全局因素模型;
- 基于功能交互的功能交互模型;
测试设计过程中建立有效的“模型”,测试人员设计测试用例相对会比较容易,并且可以很好的提高测试覆盖率,从而帮助提升产品质量。另一方面,通过建立模型,也可以帮助测试人员有效的评审测试对象功能的描述,例如可以发现需求中定义不清楚、遗漏等方面的问题。
尽管每个测试人员都掌握了不少的测试用例设计技术与方法,例如:等价类划分、状态转换测试等,但是如何将它们应用到具体的测试对象测试中去,很多测试人员都会感觉有些力不从心,甚至有无从下手的感觉。
下面是针对某个功能模块的一个简单的需求描述:该基本功能是为了创建某个条目,它的基本需求如下:
假如dataBit0 = 0, 并且cBPDU或者pBPDU的值不为1,那么创建请求会被拒绝。假如dataBit0 = 0, 并且cBPDU = 1或者pBPDU = 1,在满足下面条件下可以创建成功: (1)其他的bit不能为1; (2)TD的取值必须是Guranteed; (3)VLANpop的取值必须是disabled; |
图1 通常的测试用例设计
针对上面的需求描述,根据图1直接设计测试用例,会不会觉得有些迷茫呢?即使测试人员设计了多个测试用例,覆盖了每条测试需求,是不是也会觉得评估测试覆盖率比较困难?
实际上,需求规格说明通常是针对开发人员而写的,并不一定直接适合测试的要求。因此,假如测试人员希望能够更好的进行测试用例设计,需要将需求规格说明转化成为测试人员可以方便使用的语言很重要,即在需求规格说明和设计测试用例之间增加一个桥梁:模型。在建立模型的过程中,测试人员不仅需要学习需求规格说明,同时也需要了解各种测试设计技术与方法,并能将两者数量的结合起来。图2是增加了“模型”概念的测试用例设计过程。
图2 改进的测试用例设计
还是以上面的需求描述为例,我通过学习该需求之后,发现它可能可以与决策表技术结合起来。因此,我将上述需求翻译为适合决策表技术的各种条件与输出,并根据它们的不同组合得到不同的结果。图3是我针对上述需求描述,基于决策表技术得到的初始决策表,然后可以基于此进行决策表优化,直至得到概要和详细的测试用例列表。
图3 初始决策表
根据图2的过程得到的图3的结果,是否觉得整个测试设计过程更加清楚,而且更加容易进行测试覆盖率等方面的评估?注意:这里只是根据需求描述得到的一些测试用例,并没有考虑其他方面的测试用例,例如非功能测试用例等。
需求规格说明对测试人员很重要,测试设计技术与方法也很重要,但更重要的是测试人员如何能够将两者有效的结合起来,并在此基础之上建立适合测试设计和评估的“模型”。而这通常是测试用例设计的难点所在,同时也是体现测试人员技术含量的地方。下面是测试人员在建立模型过程中可以参考的一些方向:
- 基于黑盒测试技术,例如:决策表模型、状态转换模型、正交矩阵模型等;
- 基于测试类型,例如:质量特性模型、缺陷分类模型等;
- 基于全局因素的全局因素模型;
- 基于功能交互的功能交互模型;
测试设计过程中建立有效的“模型”,测试人员设计测试用例相对会比较容易,并且可以很好的提高测试覆盖率,从而帮助提升产品质量。另一方面,通过建立模型,也可以帮助测试人员有效的评审测试对象功能的描述,例如可以发现需求中定义不清楚、遗漏等方面的问题。
相关文章推荐
- SWTBOK测试实践系列(7) -- 测试用例设计的参考输入有哪些?
- SWTBOK测试实践系列(3) -- 既然计划永远赶不上变化,我们还要测试计划干嘛?
- SWTBOK测试实践系列(9) -- 设计的测试用例是否越详细越好?
- SWTBOK测试实践系列(5) -- 项目中使用手动和自动化的策略
- SWTBOK测试实践系列(2) --你会把开发人员提交测试的版本打回去吗?
- SWTBOK测试实践系列(1) -- 测试在项目前期的评审投入划算吗?
- SWTBOK测试实践系列(6) -- 开发人员为什么不做静态分析?
- SWTBOK测试实践系列(4) -- 软件测试技术的黑白之道
- ISTQB AL-TA/TTA连载系列20:基于风险的测试,它的风险在哪里?
- 完美测试:软件测试系列最佳实践
- SWTBOK測试实践系列(1) -- 測试在项眼下期的评审投入划算吗?
- 51Testing系列丛书:互联网单元测试及实践
- ELK实践系列-测试环境环境搭建
- 自动化测试开发实践系列(一)个人对测试、质量、竞争的理解
- SWTBOK測试实践系列(5) -- 项目中使用手动和自己主动化的策略
- ISTQB AL-TA/TTA连载系列22:脚本化测试不一定是一个好的测试实践
- 应用Selenium + NUNIT对动态WEB测试自动化(自动化测试开发实践系列)
- 软件测试实践系列之三、四已经完成
- SWTBOK測试实践系列(4) -- 软件測试技术的黑白之道
- 完美测试-软件测试系列最佳实践[电子工业出版社].pdf