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

发表于:2012-6-04 14:08

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:郑文强    来源:51Testing软件测试网采编

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

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

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

假如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的结果,是否觉得整个测试设计过程更加清楚,而且更加容易进行测试覆盖率等方面的评估?注意:这里只是根据需求描述得到的一些测试用例,并没有考虑其他方面的测试用例,例如非功能测试用例等。

  需求规格说明对测试人员很重要,测试设计技术与方法也很重要,但更重要的是测试人员如何能够将两者有效的结合起来,并在此基础之上建立适合测试设计和评估的“模型”。而这通常是测试用例设计的难点所在,同时也是体现测试人员技术含量的地方。下面是测试人员在建立模型过程中可以参考的一些方向:

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

  2、基于测试类型,例如:质量特性模型、缺陷分类模型等;

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

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

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

《2023软件测试行业现状调查报告》独家发布~

精彩评论

  • chxiang12091
    2012-7-04 10:47:07

    我怎么觉得这个需求描述有问题呢。“dataBit0 = 0, 并且cBPDU或者pBPDU的值不为1,那么创建请求会被拒绝”这句话表明,只要有一个值不为1,那么请求就被拒绝,就不会再去判断下面的条件了。必须是同时为1的时候,才能继续判断后面的条件。而后面的,却是在只要“cBPDU = 1或者pBPDU = 1”,就会继续去判断下面的条件,矛盾了。

  • bestoneli
    2012-7-02 21:04:26

    不过可以简化下,一般不会设计这么多的用例。。。

  • bestoneli
    2012-7-02 21:03:35

    系统测试自然是根据需求来了,又不是做单元测试

  • amyliu0808
    2012-6-13 16:47:55

    只可举一例而贯通,但难于穷举也,哈哈

  • alear2007
    2012-6-05 10:48:04

    有一个不明白,模型中第五个,为什么是F呢?C或者P为1时S,那并不代表同时为1的时候就是F啊

  • liujintao00
    2012-6-05 09:52:05

    不赞同作者的这种测试用例设计方法,作者例子的方法类似于穷举法,这样做一是测试用例数量庞大,二是针对性差,只反映需求逻辑而不是程序设计的逻辑。作者举例的这个需求,程序设计时可能只需要了七八个嵌套、顺序的逻辑判断就能搞定,“图三初始决策表”大部分的情况可能都是冗余的。
    我的建议是将其分为两步:
    1.对程序设计的逻辑进行评审、测试,检查程序设计的逻辑是否满足需求规格说明,有无遗漏、偏差或者需要完善的
    2.针对程序设计设计测试用例,检查程序是否正确根据程序设计实现

  • 一朵大红花
    2012-6-04 20:53:45

    可不可以再详细点啊····

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号