常见的测试用例设计方法都有哪些

2024-05-18 04:22

1. 常见的测试用例设计方法都有哪些

1. 等价类划分
常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
详细的描述一个测试活动完整的过程。1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功

常见的测试用例设计方法都有哪些

2. 测试用例设计方法有哪些?

1、等价类划分
为每个输入划分等价类,得到等价类表,为每个等价类规定一个唯一编号。设计一个测试用例,使其尽可能多的覆盖所有尚未覆盖的有效等价类。重复这一步骤,使得有效等价类均被测试用例所覆盖设计一个测试用例,使其只覆盖一个无效等价类。重复这一步骤使得所有无效等价类均被覆盖。
2、边界值分析
从测试规格中分析得到输入参数类型,对于输入等价类划分方法进行等价类的划分,运用域测试分析方法确定域范围的边界(上点、离点与内点)。如果存在多个输入域,则需要运用因果图、判定表方法这些输入域边界值的组合情况进行进一步分析,选择这些上点、离点与内点或者这些点的组合形成测试项。
3、判定表
判定表是分析和表达多种输入条件下系统执行不同动作的工具,它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。
列出所有的条件桩和动作桩,填入条件桩、条件项和动作桩、动作项,化简,合并相似规则,将每条规则转化为用例。



基本格式
1、用例编号
测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则:PROJECT1-ST-001,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。

2、测试标题
对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”。

3、重要级别
定义测试用例的优先级别,可以笼统的分为四个不同的等级。

4、输入限制
提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。

5、操作步骤
提供测试执行过程的步骤。对于复杂的测试用例,测试用例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。

6、预期结果
提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。

3. 测试用例设计方法有哪些?

可以采用软件测试常用的基该方法:等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基该方法来设计完整的测试用例,并最终实现暴露隐藏的缺陷,全凭测试设计人员的丰富经验和精心设计。
编写测试用例文档应有文档模板,须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。 软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位,形成一个测试用例文档,但并不是绝对的。
测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息:版本号、模块名称、用例编号、用例名称、用例级别、预知条件、验证步骤、期望结果(含判断标准)、测试结果、测试时间、测试人员等。

扩展资料
测试用例设计一般遵循以下原则:
(1)正确性。输入用户实际数据以验证系统是否满足需求规格说明书的要求;测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能,并且正常。
(2)全面性。覆盖所有的需求功能项;设计的用例除对测试点本身的测试外,还需考虑用户实际使用的情况、与其他部分关联使用的情况、非正常情况(不合理、非法、越界以及极限输入数据)操作和环境设置等。
(3)连贯性。用例组织有条理、主次分明,尤其体现在业务测试用例上;用例执行粒度尽量保持每个用例都有测点,不能同时覆盖很多功能点,否则执行起来牵连太大,所以每个用例间保持连贯性很重要。
(4)可判定性。测试执行结果的正确性是可判定的,每一个测试用例都有相应的期望结果
(5)可操作性。测试用例中要写清楚测试的操作步骤,以及与不同的操作步骤相对应的测试结果。

测试用例设计方法有哪些?

4. 常见的测试用例设计方法都有哪些

一、等价类划分法
所谓「等价」,就是具有相同属性或者方法的集合,这个集合中某个个体所表现的特征与其他个体完全一致。
由此可知,等价类划分就是将所有可能的输入数据,划分成若干个等价类,然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类,分为有效等价类和无效等价类。
例如,规定的用户名长度区间为4~8个字,那么它的有效等价类是用户名长度在[4,8],无效等价类为用户名长度大于8位,或用户名长度小于4位。
二、边界值
测试经验告诉我们,在测试有时会涉及到大量的数据,遍历所有数据会使测试效率低下,如果是手工执行,更加难以覆盖所有数据。这时更有效率的做法是,先划分等价类,再从等价类中选择部分参数测试,边界值是等价类所有可选参数中最容易出问题的地方,所以我们一般会选择边界值作为测试的重点,边界值法的应用步骤如下:
1.先根据等价类法划分有效等价类和无效等价类,确定上点、离点及内点。上点是边界上的点,离点是离上点最近的点,内点则是边界有效范围内的任意一点。同样以用户名长度为4~8位为例,4和8为上点,3和9为离点,6则为内点。
2.设计一个新的测试用例,使其尽可能地覆盖所有尚未覆盖的有效等价类,直到所有有效等价类完全覆盖。
3.设计一个新的测试用例,使其仅覆盖一个无效等价类,直到所有无效等价类都被覆盖。
三、判定表法
判定表又称策略表、决策表,能表示输入条件的组合,以及与每一输入组合对应的动作组合。判定表法适合逻辑判断比较复杂的场景,通过穷举条件获得结果,对结果再进行优化合并,具体又明确地表达复杂地逻辑关系和多种条件组合情况。
判定表主要由条件桩和动作桩两部分组成。条件桩是功能要满足地所有条件,动作桩则是所有可能的操作以及产生的结果。
判定表能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。其缺点是判定表的建立过程较烦杂,当条件过多时,需要分析的逻辑组合呈2的倍数增长。测试工程师可根据实际情况与等价类划分法、边界值法结合使用。
四、正交试验法
正交试验法是研究多因素、多水平组合的一种实验法,它是利用正交表来对实验进行设计,通过少数的实验替代全面实验。正交表中所有参与试验的、影响试验结果的条件成为因子,影响试验因子的取值或输入的成为水平。
在设计测试用例时,采用正交试验法能够有效地、合理地减少测试的工作量与和成本。正交试验的一般流程包括以下几个步骤:
1)分析测试需求,获取因子和水平
2)根据因子和水平选择合适的正交表
3)替换正交表中的因子和水平,获取试验次数
4)根据经验或者其他因素补充试验次数
5)细化输出获得测试用例
以上是一些常见的测试用例设计方法,希望能够解答你的问题。

5. 如何设计测试用例

  当自己接受到一个设计测试用例的任务时,如何对一个庞大的模块进行设计测试用例呢?这时候测试用例的划分就显的尤为重要。
  我总结的测试用例的划分有三种:
  1)按照功能划分
  2)按照路径(业务流程)划分
  3)按照功能和路径(业务流程)划分
  目前我用的方法是第三种。第一种按照功能划分,优点是最简捷,但其缺点是:对于复杂操作的程序模块,其各功能的实施是相互影响,紧密相关,环环相扣的。如果没有严密的逻辑分析,很容易产生遗漏。第二种纯粹按照路径划分也容易造成对功能点的遗漏。所以我基本都是大方向用功能块的划分来走,然后再结合上路径(业务流程)的划分方法。

如何设计测试用例

6. 常见的测试用例设计方法都有哪些

1. 等价类划分
常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3. 错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结。还有, 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.
5. 正交表分析法
有时候,可能因为大量的参数的组合而引起测试用例数量上的激增,同时,这些测试用例并没有明显的优先级上的差距,而测试人员又无法完成这么多数量的测试,就可以通过正交表来进行缩减一些用例,从而达到尽量少的用例覆盖尽量大的范围的可能性。
6. 场景分析方法
指根据用户场景来模拟用户的操作步骤,这个比较类似因果图,但是可能执行的深度和可行性更好。
白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
详细的描述一个测试活动完整的过程。1. 项目经理通过和客户的交流,完成需求文档,由开发人员和测试人员共同完成需求文档的评审,评审的内容包括:需求描述不清楚的地方和可能有明显冲突或者无法实现的功

7. 常见的测试用例设计方法都有哪些

 1. 等价类划分 如下图所示



 2. 边界值:应选取正好等于、刚刚大于、刚刚小于边界值作为测试数据
3. 错误推测法:进行错误的操作,验证程序是否对出错的场 景和情况有应对能力。4. 因果图法/判定表法:适合于检查程序输入条件的各种组合情况。5. 场景法:场景描述的业务流程              基本流:主要是功能的正常操作流程              分支流:需要程序做非法判断处理

常见的测试用例设计方法都有哪些

8. 常见的测试用例设计方法都有哪些

基于业务逻辑的测试
基于用户操作的测试
探索性测试
原因:当前产品除了质量外,发布速度也很重要,如果按照这样的方式设计用例,一般来说比较浪费时间,而且还要去除冗余(除非做成自动化)。对于这样的用例发展的bug很多是用户不会遇到的,或者用户遇到了也觉得关系不大的(想下你自己使用一个软件碰到一个问题你怎么处理)。
从笔者做测试7年来看,没有去刻意的在用例设计里面用过这些东西,也不建议你用,特别是在当前敏捷的方式下(纯属个人观点)
最新文章
热门文章
推荐阅读