设计测试用例的步骤

一。因果图法设计测试用例的步骤:
1.分析软件规格说明描述中哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件), 并给每个原因和结果赋予一个标识符。
2.分析软件规格说明描述中的语义,找出原因与结果之间, 原因与原因之间对应的关系,根据这些关系画出因果图。
3.标明约束条件:由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现,为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件。
4.把因果图转换为判定表。
5.把判定表的每一列拿出来作为依据设计测试用例。

二。场景法设计测试用例的步骤:
1.根据规格说明描述出程序的基本流及各项备选流
2.根据基本流和各项备选流生成不同的场景
3.对每一个场景生成相应的测试用例,可以采用矩阵或决策表来确定和管理测试用例
4.复审生成的测试用例,去掉多余或等价的测试用例,然后来确定实际测试数据。

三。基本路径法设计测试用例的步骤:
1.画出程序的控制流图
2.计算程序的圈复杂度
3.导出测试用例

备注:分支覆盖的最少用例数:通常等于程序中的判定语句的数目加1,即分支数。如:有3个if语句,共4个分支。

时间: 2024-10-29 00:53:48

设计测试用例的步骤的相关文章

因果图设计测试用例的步骤

上一篇文章(http://www.bcbxhome.com/bcbx/forum.php?mod=viewthread&tid=26#lastpost)我们解决了“What is it”的问题,下面让我们来讨论“How to do”的问题.使用因果图设计测试用例一般包括下面几个步骤: 1.1.1.     分析需求 阅读需求文档,如果User Case很复杂,尽量将它分解成若干个简单的部分.这样做的好处是,不必在一次处理过程中考虑所有的原因.没有固定的流程说明究竟分解到何种程度才算简单,需要测试

【转】黑盒设计测试用例方法

1. 等价类法 定义: 是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 划分等价类:  等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的,并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试,因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件就可以用少量代表性的测试数据取得较好的测试结果.等价

基本路径法设计测试用例

基本路径法是白盒测试中使用最为广泛的方法.以下将介绍一下基本路径法如何使用. 基本路径法设计测试用例的步骤基本如下 1.由程序的源代码作为基础导出控制流图 2.计算控制流图的环路复杂度 3.确定基本路径 4.根据基本路径设计测试用例 接下来我举个例子 1 Int IsLeap(int year) 2 { 3 if (year % 4 == 0) 4 { 5 if (year % 100 == 0) 6 { 7 if ( year % 400 == 0) 8 leap = 1; 9 else 10

使用正交表法设计测试用例

1.案例:字符属性设置程序需求:窗体中有多个控件(字体.字符样式.颜色.字号),每个控件有多个取值 字体:仿宋.楷体.华文彩云字符样式:粗体.斜体.下划线颜色:红色.绿色.蓝色字号:20号.30号.40号 使用步骤:1.根据需求形成因子状态表----->因子:控件名称 状态:每个控件对应的取值2.确定所采用的正交表3.将正交表中的字母用文字代替4.一行就是一条测试用例 2.案例:对某人进行查询假设查询某个人时有三个查询条件(查询条件仅考虑填写和不填写两种情况): 根据" 姓名"

测试设计学习-关于使用PICT设计测试用例步骤说明

PICT介绍: PICT全称Pairwise Independent Combinatorial Testing(成对独立组合测试) PICT产生测试用例和测试配置.你可以通过使用PICT产生的测试,比手工设计的测试更加有效,并且只需要手工设计测试用例的一小部分时间. PICT可以有效地按照两两测试的原理,进行测试用例设计.在使用PICT时,需要输入与测试用例相关的所有参数,以达到全面覆盖的效果 Eg: Type: Single, Span, Stripe, Mirror, RAID-5 Siz

设计测试用例的四条原则

今天是2011年的第一天,2010年就这样匆匆忙忙,紧紧张张地过去了.这一年里来来去去,变化最大的就是很多一起工作了多年的同事离开了,很多都去了"更给力”的地方,呵呵!公司里来来往往是很正常的,想想我最近一次换到“更给力”的地方,那都是5年前了.总之,现在的地方还是挺给力的,好好工作,争取2011年有更大的进步,呱唧呱唧! 测试用例设计的最基本要求:覆盖住所要测试的功能.这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解.明确测试范围(特别是要

【tool】设计测试用例的四条原则

测试用例设计的最基本要求:覆盖住所要测试的功能.这是再基本不过的要求了,但别看只是简单的一句话,要能够达到切实覆盖全面,需要对被测试产品功能的全面了解.明确测试范围(特别是要明确哪些是不需要测试的).具备基本的测试技术(如:等价类划分等)等.那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?答案:在理论上是,但在实际工程中还远远不是.之所以理论和实际会有这样的差别,是因为在理论上不要考虑 测试用例设计的最基本要求:覆盖住所要测试的功能.这是再基本不过的要求了,但别看只是简单的一

【转】场景法设计测试用例

转自:http://blog.sina.com.cn/s/blog_4aa1f1570100acvb.html (一)场景法原理 现在的软件几乎都是用事件触发来控制流程的.象GUI软件.游戏等.事件触发时的情景并形成了场景,而同一事件不同的触发顺序和处理结果就形成了事件流.这种在软件设计方面的思想可以引入到软件测试中,可以生动地 描绘出事件触发时的情景,有利于设计测试用例,同时使测试用例更容易理解和执行. 在测试一个软件的时候,在场景法中,测试流程是软件功能按照正确的事件流实现的一条正确流程,那

分层设计测试用例

设计好测试用例对测试执行和测试管理都大有裨益.对测试执行的好处不言而喻,拿着一个好的测试用例,即便是一个测试菜鸟做测试执行也能保证用例对应功能得到覆盖.对测试管理而言,也非常有帮助,测试用例设计架构清晰,就能保证测试计划制定.测试任务分配能够更加准确.对自动化测试实施更加有好处.如果测试用例设计不清晰,不同的人按照同样的用例设计出的自动化测试脚本差异就会比较大. 有些项目的测试用例,会随着软件版本的不断变更规模不断增大.在设计测试用例之初就依据某个标准把测试用例划分成不同的模块,这样之后测试用例