前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >黑盒测试用例设计方法二

黑盒测试用例设计方法二

作者头像
吾非同
发布2020-10-23 14:42:55
4840
发布2020-10-23 14:42:55
举报
文章被收录于专栏:吾非同

判定表

定义:分析和表述若干输入条件下,被测对象对这些输入作出相应的一种表格。在遇到复杂业务逻辑时可以用该表理清业务逻辑关系。

条件桩:需求规格说明书所定义的被测对象的所有输入。

条件项:针对条件桩所有可能的输入数据的真假值。

动作桩:针对条件,被测对象所采取的操作。

动作项:针对条件项的各种取值,被测对象响应的动作。

规则:任何一个条件组合的特定取值及其要执行的相应操作。在判定表中贯穿条件项和动作项的一列就是一条规则。

1、确定规则个数,假如有n个条件.每个条件有两个取值(0,1),故有2^n种规则。

2、列出所有的条件桩和动作桩。

3、填入条件项。

4、填入动作项,等到初始判定表。 5、简化,合并相似规则(相同动作)。

例如:

如果用户欠费或停机,则不允许用户主被叫。

简化,相同业务条件可划分为一条规则。

根据判定表可输出3条测试用例。

适合使用判定表设计测试用例的条件:

  • 规格说明以判定表形式给出,或很容易转换成判定表的。
  • 条件的排列顺序不会也不影响执行哪些操作。
  • 规则的排列顺序不会也不影响执行哪些操作。
  • 每当某一规则的条件已近满足,并确定要执行的操作后,不必检验别的规则。
  • 如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要。

错误推测法 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。   错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。

例如,在单元测试时曾列出的许多在模块中常见的错误。以前产品测试中曾经发现的错误等,这些就是经验的总结。还有输入数据和输出数据为0的情况,这些都是容易发生错误的情况。

随机测试法

随意测试,不考虑任何测试用例和需求,完全站在一个用户的角度对产品进行使用。

适用于:

所有之前设定的用例已经执行完毕。

海量的条件组合没有办法意义遍历的时候。

场景法

基本流:通过实现业务流程时,做到每一个流程都是正确的,从来达到目的流程。

备选流:通过实现业务流程时,因错误操作或者是异常操作,导致流程反复,但最终达到目的流程

  • 根据说明,描述出程序的基本流及各项备选流。
  • 根据基本流和各项备选流生成不同的场景。
  • 对每一个场景生成相应的测试用例。
  • 对生成的所有测试用例重新复审,去掉多余的测试用例,测试用例确定后,对每一个测试用例确定测试数据值。

测试大纲法/需求文档转化法

所有需求文档中所描述的文字信息,梳理每个功能模块的测试点,将每个测试点转化为用例。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2018-01-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 吾非同 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档