用例设计之判定表

发表于:2018-1-10 14:34  作者:yaitza   来源:个人博客

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 软件测试技术 用例设计

  1.判定表的介绍
  在对软件进行需求分析时,市场部人员需要跟用户进行不断的沟通,这时可能会根据软件功能的期望让用户填一些调查表格,用户会根据条件选择自己期望达到的效果。如果将条件称为输入,将期望效果称为输出,这就非常接近于软件测试中的测试用例。如果由于条件的不同组合会得到不同的一些输出,那么这样的问题就适合使用判定表来进行测试用例的设计。
  1.1判定表通常由四个部分组成
  (1)、条件桩(ConditionStub):列出了问题的所有条件。除特别说明,认为列出的条件的次序无关紧要。
  (2)、动作桩(ActionStub):根据条件的组合可能导致的动作。一般排列顺序没有约束。
  (3)、条件项(ConditionEntry):由条件桩列出条件的可能取值,即条件的真和假。
  (4)、动作项(ActionEntry):列出在不同条件排列组合下可能采取的操作。
  1.2规则及规则合并
  (1)、规则:由不同的条件导致不同的动作就称为规则,一般体现在判定表中就是不同的输入得到不同的输出。在判定表中贯穿条件项和动作项的一列就是一条规则。
  (2)、化简:因为初始化判定表包括条件的所有组合,这时有些组合可能是不能实现的,有些动作可能是由一些相似的条件组成的,这时就需要按照等价类划分的原则进行化简。
  2.普通示例
  2.1判定表建立步骤
  1、分析功能说明书,确定条件、规则的个数。
  2、根据分析,列出所有的条件桩和动作桩。
  3、根据分析输入填入条件项。
  4、根据输出填入动作项,根据排列组合得到初始决策表。
  5、简化,合并相似规则(相同动作)。
  2.2判定表举例
  “对功率大于50马力的机器、维修记录不全或已运行10年以上的机器,应给予优先的维修处理……”。这里假定,“维修记录不全”和“优先维修处理”均已在别处有更严格的定义;请建立判定表。
  步骤:
  1.确定规则的个数:这里有3个条件,每个条件有两个取值,故应有222=8种规则。
  2.列出所有的条件桩和动作桩:
  3.填入条件项。
  4.填入动作桩和动作顶。这样便得到形如图的初始判定表。
  5.化简。合并相似规则后得到图。
  6.然后根据最后化简的结果,生成相应的测试用例。
  3.判定表的优缺点
  优点:把复杂的问题按各种可能的情况一一列举,简明而易于理解,也避免遗漏。
  缺点:
  不能表达重复执行的动作,如循环结构。
  判定表不能很好的伸缩。如有n个条件的判定表有2n个规则。
  4.适合使用判定表设计测试用例的条件:
  1.规格说明以判定表形式给出,或很容易转换成判定表的。
  2.条件的排列顺序不会也不影响执行哪些操作。
  3.规则的排列顺序不会也不影响执行哪些操作。
  4.每当某一规则的条件已近满足,并确定要执行的操作后,不必检验别的规则。
  5.如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道