当前位置:文档之家› 测试用例设计练习

测试用例设计练习

测试用例设计练习
测试用例设计练习

一、等价类划分法

例子1:

现在有一个档案管理系统,容许用户通过输入年月对档案文件进行检索,系统对查询条件年月的输入限定为1990年1月-2049年12月,并规定,日期由6位数字组成,前4位表示年,后2位表示月。

1,根据需求进行分析,找出有哪些输入条件

年份:【1990,2049】

月份:【01,12】

字符长度:6位

字符类型:数字

2,画出等价类

输入条件有效等价类边界值分析无效等价类

年份【1990,2049】(1)上点:1990,2049(12)

离点:1989,2050

内点:2016 <1990 (2)>2049 (3)

月份【01,12】(4)上点:01,12(13)

离点:00,13

内点:11 <01 (5)>12 (6)

字符长度6位(7)上点:6

离点:5,7

内点:6 <6 (8)>6 (9)

字符类型数字(10)非数字(11)3,为每个等价类规定一个唯一编号(如上图)

4,转换成测试用例

转换测试用例的原则:

A,设计一个测试用例尽可能多的覆盖多个有效等价类;

B,设计一个测试用例必须对应覆盖一个无效等价类。

有效等价类用例:

用例1:201611 (1)(4)(7)(10)

无效等价类用例:

用例2:198911 (2)

用例3:205011 (3)

用例4:201600 (5)

用例5:201613 (6)

用例6:20161 (8)

用例7:2016113 (9)

用例8:20161a/abcedf (11)

根据边界值分析法分析后补充测试用例

用例9:199001 (12)

用例10:204912 (13)

5,转成正式格式用例(用例写作的8大要素)

用例编号D1223232_ST_Search_Date_001

项目搜索功能

标题输入正确的日期格式成功搜索

重要级别高

预置条件系统运行正常

输入日期:201611

操作步骤1,在查询条件中输入日期

2,点击搜索按纽

预期结果1,显示该日期范围内所有档案文件

编写人张三

编写时间2016-11-10

用例类型功能用例

例子2:(学生练习-参考例子)

万年历查询软件,要求用户输入以年月日表示的日期,然后系统会换算出该日期的农历表示法及相关黄历信息。假设日期限定在1990年1月1日~2049年12月31日,并规定日期由8位数字字符组成,前4位表示年,中间2位表示月,最后2位表示日期。其中4,6,9,11月只有30天,平年的2月份只有28天,闰年的2月份有29天。

备注:闰年指能被4或400整除,且不能被100整除的年份,如:2008,2016

1,根据需求进行分析,找出有哪些输入条件

年份:【1990,2049】

月份:【01,12】

字符长度:8位

字符类型:数字

日期:

4,6,9,11月:【01,30】

1,3,5,7,8,10,12月:【01,31】

平年的2月份:【01,28】

闰年的2月份:【01,29】

2,画出等价类

输入条件有效等价类无效等价类

年份【1990,2049】(1)<1990 (2)

>2049 (3)

月份【01,12】(4)<01 (5)

>12 (6)

字符长度8位(7)<8 (8)

>8 (9)

字符类型数字(10)非数字(11)

4,6,9,11月【01,30】(12)<01 (13)

>30 (14)

1,3,5,7,8,10,12月【01,31】(15)<01 (16)

>31 (17)

平年的2月份【01,28】(18)<01 (19)

>28 (20)闰年的2月份【01,29】(21)<01 (22)

>29 (23)3,为每个等价类规定一个唯一编号(如上图)

4,转换成测试用例

转换测试用例的原则:

A,设计一个测试用例尽可能多的覆盖多个有效等价类;

B,设计一个测试用例必须对应覆盖一个无效等价类。

有效等价类用例:

用例1:20161130 (1)(4)(7)(10)(12)

无效等价类用例:

用例2:19891110 (2)

用例3:20501110 (3)

用例4:201600 (5)

用例5:201613 (6)

用例6:20161 (8)

用例7:2016113 (9)

用例8:20161a/abcedf (11)

5,转成正式格式用例(用例写作的8大要素)

例子3(输入项):

注册163邮箱,要求注册的邮箱名字符长度为6-18位,字符由字母、数字、下划线组成,且以字母开头。密码字符长度为6-16位,区分大小写。有验证码验证

输入域输入条件有效等价类无效等价类

邮件地址字符长度【6,18】<6

>18

字符类型全字母

字母开头+数字

字母开头+下划线

字母开头+字母、数字

字母开头+字母、下划线

字母开头+数字、下划线

字母开头+字母、数字、下划

线非字母开头

字母开头+非数字、字母、下划线的其它字符

是否必填填写不填

是否被注册未被注册已注册

是否有保留字段有保留无保留密码字符长度【6,16】<6

>16

字符类型英文字母;

数字;

特殊字符;

英文字母、数字、特殊字

符三种组合;非英文字母、数字、特殊字符三种以外的字符

是否必填填写不填

确认密码是否一致一致不一致

是否必填填写不填

手机号码字符长度11位<11

>11

字符类型纯数字非数字

国家编号选择显示正确选择显示错误验证码是否一致一致不一致

(1,完全一致)

(2,不区分大小写)

切换能切换不能切换

免费免费不免费

免费获取

验证码

获取收到短信收不到短信

是否一致一致不一致

短信验证

同意条款是否勾选勾选不勾选

转成测试用例

有效等价类

用例1:

邮件地址:chenzhijian

密码:zhijian

确认密码:同密码一致

手机号码:

验证码:同右边图片中完全一致

免费获取验证码:点击获取

输入短信验证码:收到的短信验证码(6位数字)

同意条款:勾选

用例2:

邮件地址: chenzhijian123

密码:123456

确认密码:同密码一致

验证码:不区分大小写

免费获取验证码:点击获取

输入短信验证码:收到的短信验证码(6位数字)

同意条款:勾选

用例3:

邮件地址: chenzhijian_

密码: @#$%^^!&

确认密码:同密码一致

验证码:同右边图片中完全一致

免费获取验证码:点击获取

输入短信验证码:收到的短信验证码(6位数字)

同意条款:勾选

用例4:

邮件地址: chenzhijian_123

密码: zhijian12%&

确认密码:同密码一致

验证码:不区分大小写

免费获取验证码:点击获取

输入短信验证码:收到的短信验证码(6位数字)

同意条款:勾选

用例5:

邮件地址:chenzhijian/chenzhijian123/chenzhijian_/chenzhijian_123/…

密码:zhijian/123456/@#$%^^!&/zhijian12%&

确认密码:同密码一致

验证码:同右边图片中完全一致/不区分大小写

免费获取验证码:点击获取

输入短信验证码:收到的短信验证码(6位数字)

同意条款:勾选

无效等价类

例子4(下拉框):

例子5:(课后练习)

二、边值分析法

例子1:

输入条件有效等价类手续费(元) 边界值分析无效等价类

存入金额M 【1000,10000】M*0.5% 上点:1000,10000

离点:900,10100

内点:5000 (10000,50000】50 上点:10000,50000

离点:10100,50100

内点:20000

设计测试用例

用例1:存入的金额数字有900、1000、5000、10000、10100、20000、50000、50100

例子3:

输入条件有效等价类边界值分析无效等价类

单笔提取金额【50,2000】上点:

离点:

内点:

每天取款次数【1,3】

每天取款总额【50,5000】

提款的增量50

的整数倍

【1,40】

输入条件有效等价类边界值分析无效等价类

第一次提取金额【50,2000】上点:

离点:

内点:

每天取款次数【1,3】

每天取款总额【50,5000】

提款的增量50

的整数倍

【1,40】

例子4:转账

例子5:等价类边界值综合练习

常见边界值缺陷:

日期测试:10月31日,月加1变为11月31日,而11月是没有31日的,这个时候日项显示就不正常了。1月30日, 对日项加1时,日直接变为01了,即变成了1月01日

无法进入待机模式:修改系统时间,当系统时间小于当前时间时,不能进入待机模式淘宝网便民服务之话费充值

越界造成死机:

1、将呼吸测量模式设置成手动测量;

2、调整上下虚线的位置,将上下虚线的位置均调节到最下方或都调节到最上方,直到不可调节为止;

3、将增益为1倍调节为5倍增益;

4、退出呼吸设置菜单再次进入呼吸设置菜单后出现死机;

5、重起后每次进入呼吸菜单都会死机,除非重新恢复缺省配置。

三、判定表法

例子1:手机如果欠费或者停机则不能主被叫

例子2:手机接入wifi或打开3G,对是否可以使用网络的情况进行设计测试用例

1,根据需求进行分析,找出条件桩、动作桩、条件项、动作项

条件桩条件项

接入wifi 接入/未接入1/0

打开3G 打开/未打开1/0

动作桩动作项

可以使用网络(未知)

不可以使用网络

2,列出判定表

规则的个数:2*2=4个

条件桩 1 2 3 4

接入wifi 1 1 0 0

打开3G 1 0 1 0

动作桩

可以使用网络Y Y Y

不可以使用网络Y

3,画简合并

条件桩 1 2 3

接入wifi 1 0 0

打开3G X 1 0

动作桩

可以使用网络Y Y

不可以使用网络Y

4,转测试用例

最终化简合并后得到的列,一列即为一条用例(如上共3条)

用例1: 1 X -> 可以使用网络

用例2:0 1 -> 可以使用网络

用例3:0 0 -> 不可以使用网络

例子3:修改Notes账户密码,要求如下,首先输入正确的原始密码;输入两次一致的新密码;并且新密码要具有一定的复杂度(8-15位;包含大写字母;小写字母;数字;其它字符)

[判定表法]

1,根据需求进行分析,找出条件桩、动作桩、条件项、动作项

条件桩条件项

原始密码正确/不正确1/0

新密码复杂/不复杂1/0

确认密码一致/不一致1/0

动作桩 动作项 修改成功 (未知) 修改失败 5, 列出判定表

规则的个数:2*2*2=8个

条件桩 1 2 3 4 5 6 7 8

原始密码 1 1 1 1 0 0 0 0 新密码 1 1 0

1 1 0 0 确认密码 1

1

1

动作桩

修改成功 Y

修改失败 Y Y Y Y Y Y Y

6, 画简合并

条件桩 1 2 3 4

原始密码 1 1 1 0 新密码 1 1 0 X 确认密码 1

X

X

动作桩

修改成功 Y

修改失败

Y Y Y

7, 转测试用例

最终化简合并后得到的列,一列即为一条用例(如上共4条) 用例1: 1 1 1 -> 修改成功 用例2: 1 1 0 -> 修改失败 用例3: 1 0 X -> 修改失败 用例4: 0 X X -> 修改失败 例子4:电影票优惠

1,根据需求进行分析,找出条件桩、动作桩、条件项、动作项 条件桩 条件项 刷华夏信用卡 刷/不刷 1/0 周三下午 是/不是 1/0 情侣 是/不是 1/0 动作桩 动作项 8折优惠 (未知) 7折优惠 女生免票

? 1.电影票购票门票50元/张

? 2.刷华夏信用卡享受8折优惠 ? 3.周三下午看电影享受7折优惠 ? 4.情侣看电影,女生免票 ? 符合情况4不享受额外优惠 ? 符合情况2和3享受折上折

折上折

原价

2,列出判定表

规则的个数:2*2*2=8个

条件桩 1 2 3 4 5 6 7 8

刷华夏

11110000

信用卡

周三下

11001100

情侣10101010

动作桩

8折Y

7折Y

Y Y Y Y

女生免

折上折Y

原价Y

3,化简合并

条件桩 1 2 3 4 5

刷华夏

X1100

信用卡

周三下

X1010

情侣10000

动作桩

8折Y

7折Y

Y

女生免

折上折Y

原价Y

4,转成测试用例

例子5:有一个需求描述如下:“.....对已运行10年以上的机器,或功率大于50马力且维修记录不全的机器,给予全面维修处理,对其它机器只进行一般维修处理”

1,根据需求进行分析,找出条件桩、动作桩、条件项、动作项

条件桩条件项

10年以上是/不是1/0

大于50马力是/不是1/0

维修记录不全是/不是1/0

动作桩动作项

全面维修(未知)

一般维修

2,列出判定表

规则的个数:2*2*2=8个

条件桩 1 2 3 4 5 6 7 8

10年以

11110000上

大于50

11001100马力

维修记

10101010录不全

动作桩

Y Y Y Y Y

全面维

Y Y Y 一般维

3、化简合并

条件桩 1 2 3 4

10年以

1000

大于50

X110

马力

维修记

X10X

录不全

动作桩

Y Y

全面维

Y Y

一般维

例子6:修改文件

如想对文件进行修改,需要遵守以下规则:

输入的第一列字符必须是A或B,

第二列字符必须是一个数字,

如果第一列字符不正确,则给出信息L;

如果第二列字符不正确,则给出信息M;

如果两列字符输入正确,则修改文件

例子5:判断三角形(作业)

四、因果图法

例子1:(用因果图法实现)

如想对文件进行修改,需要遵守以下规则:

输入的第一列字符必须是A或B,

第二列字符必须是一个数字,

如果第一列字符不正确,则给出信息L;

如果第二列字符不正确,则给出信息M;

如果两列字符输入正确,则修改文件

第二种方法

1,根据需求进行分析,找出原因和结果

原因(输入条件)结果(输出结果)

第一列字符必须是A L

第一列字符必须是B M

第二列字符必须是一个数字修改文件

2,画出因果图

3、把因果图转成判定表

计算规则个数:2^N(N为原因的个数)=2^3=8

条件桩 1 2 3 4 5 6 7 8

A 1 1 1 1 0 0 0 0

B 1 1 0 0 1 1 0 0

数字 1 0 1 0 1 0 1 0

动作桩

L

M

修改文

因为条件中第一列字符一次只能输入A或B,所以当它们同时存在时不符合要求,需删除(如上图)条件桩12 3 4 5 6

A 1 1 0 0 0 0

B 0 0 1 1 0 0

数字 1 0 1 0 1 0

动作桩

L YY

M YYY

YY

修改文

补充如下计算动作项的方法(加入中间节点,再用与或关系进行计算)

条件桩12 3 4 5 6

A 1 1 0 0 0 0

B 0 0 1 1 0 0

数字 1 0 1 0 1 0

11 1 1 1 1 0 0

动作桩

L 0 0 0 0 1 1

M 0 1 0 1 0 1

1 0 1 0 0 0

修改文

4、化简合并

经过分析,如上6条没有相似规则的列,不需要合并

5、转成测试用例

用例1:A4 –> 修改文件

用例2:Aa –> M

用例3:B5 –> 修改文件

用例4:Ba –> M

用例5:C1 –> L

用例6:CD –> L,M

综上共得到6条用例

5、转正式格式用例(8大要素)

第一种方法

1,根据需求进行分析,找出原因和结果

原因(输入条件)结果(输出结果)

第一列字符必须是A或B L

第二列字符必须是一个数字M

修改文件

2,画出因果图

3、把因果图转成判定表

计算规则个数:2^N(N为原因的个数)=2^2=4

条件桩 1 2 3 4

1 1 0 0

第一列字符必须

是A或B

1 0 1 0

第二列字符必须

是一个数字

动作桩

L Y Y

M Y Y

修改文件Y

4、转成测试用例

用例1:A4 –> 修改文件(1)

B5 –> 修改文件(2)

用例2:Aa –> M (3)

Ba –> M (4)

用例3:C1 –> L (5)

用例4:CD –> L,M (6)

综上共得到6条用例

5、转正式格式用例(8大要素)

例子2:(用因果图法实现)

有一个处理单价为5角钱的饮料的自动售货机软件测试用例的设计。

其规格说明如下:

若投入5角钱或1元钱的硬币,押下〖橙汁〗或〖啤酒〗的按钮,则相应的饮料就送出来。当售货机没有零钱找,则一个显示〖零钱找完〗的红灯是亮的,这时在投入1元硬币并押下按钮后,饮料不送出来而且1元硬币也退出来;若有零钱找,则显示〖零钱找完〗的红灯不会亮,在送出饮料的同时退还5角硬币。1,根据需求进行分析,找出原因和结果

原因(输入条件)结果(输出结果)

5角钱送出〖橙汁〗

1元钱送出〖啤酒〗

押下〖橙汁〗红灯是亮

押下〖啤酒〗饮料不送出来而且1元硬币也退

没有零钱找红灯不会亮

有零钱找在送出饮料的同时退还5角

进行优化

原因(输入条件)结果(输出结果)

5角钱送出〖橙汁〗

1元钱送出〖啤酒〗

押下〖橙汁〗红灯是亮

押下〖啤酒〗1元硬币也退

有零钱找退还5角

为了更好画出因果图,调整原因和结果的顺序

原因(输入条件)结果(输出结果)

有零钱找红灯是亮

1元钱1元硬币也退

5角钱退还5角

押下〖橙汁〗送出〖啤酒〗

押下〖啤酒〗送出〖橙汁〗

2,画出因果图

3、把因果图转成判定表

规则个数为:2^5=32

例子3:(学生课堂练习)

支付宝个人认证中,分为两部分:个人身份认证和银行卡认证。这两者都通过后,则认为认证成功。

个人身份认证需要提交个人基本信息及身份证复印件。

银行卡认证需完成提现认证和充值认证。

提现认证的流程是:用户提交正确的银行帐号——>支付宝给用户的银行卡中随机打款——>用户确认金额,认证成功。

充值认证的流程是:用户提交正确的银行帐号——>充值——>充值完成——>网银反馈,认证成功。

为了简便起见,我们假设个人信息提交和身份证件提交成功后,身份认证则成功,忽略人工审核过程。

画出因果图

五、状态迁移法

例子1:

根据电梯在实际生活中可能会出现的各种状态,画出状态迁移图

(首层、上升状态、下降状态、空闲状态、维修状态、顶层、超载、故障)

例子2:某打印机的打印功能如下:

打印机初始处于就绪的状态下,可以接收打印的任务,进入打印状态,开始打印;

在打印的过程中,如果打印机出现故障,打印机将处于故障状态,等待修复故障;

故障修复后,打印机会恢复打印状态,继续打印原来的文档;

在打印的过程中,如果纸张用完,打印机将暂停打印,处于缺纸状态,当放入打印纸后,打印机会自动检测,恢复打印状态,继续开始打印;

打印任务完成,打印机恢复就绪状态。

1、根据需求进行划分,找出状态和状态之间的触发条件

状态:就绪状态、打印状态、故障状态、缺纸状态

触发条件:接收任务、出现故障、修复故障、纸张用完、放入纸张、打印完成

2、画状态迁移图

3、列出状态-事件表

前一状态触发条件后一状态现像

就绪状态接收任务打印状态打印指示灯亮

打印状态出现故障故障状态故障灯亮

打印状态纸张用完缺纸状态缺纸指示灯亮

打印状态打印完成就绪状态就绪指示灯亮

故障状态修复故障打印状态打印指示灯亮

缺纸状态

放入纸张 打印状态 打印指示灯亮

4、 画出状态转换树

根据广度优先原则,从一个根开始,依次找它的子结点,一直找到最终的叶子结点 5、 推导出测试路径

从根结点开始找到最终的叶子结点,即为一条路径,一条路径即为一条用例 路径1:就绪状态->打印状态->故障状态->打印状态 路径2:就绪状态->打印状态->缺纸状态->打印状态 路径3:就绪状态->打印状态->就绪状态 6、 转成正式的用例格式

用例编号 Printer_ST_Print_fault_001 项目 打印功能

标题 打印过程出现故障恢复到打印状态测试 重要级别 高

预置条件 打印机初始置为就绪状态 输入 1,Word 文档

操作步骤

1, 点击Word 文档打印

2, 打印过程中让打印机出现故障(断电或卡纸) 3, 修复故障

预期结果 1,故障修复完成,恢复打印功能 编写人 张三 编写时间 2016-11-10 用例类型

功能用例

例子3:(课堂练习)

列出状态-事件表

前一状态 触发条件

后一状态 现像

播放 暂停 播放 后退 播放 前进 暂停 播放

暂停 后退 暂停 前进 后退 暂停 后退

前进

后退

播放 前进

播放 前进 后退 前进

暂停

画出状态转换树

推导出测试路径(共9条) 路径1:播放->暂停->播放 。。。

路径9:播放->前进 ->暂停 例子4:(课堂作业)

暂停

播放

后退 前进

问题单的一生

测试人员提交新问题单,测试经理审核问题单,如果不是问题则作为非问题关闭,如果重复则作为重复问题关闭,否则置为打开状态。

开发人员分析打开状态的问题单,如果接受则进行修改。否则应与测试人员协商,在问题单提交人同意的情况下可退回给测试人员作为非问题关闭。

对于开发人员拒绝修改但测试人员无法认同的情况,该问题单需提交CCB评审,根据评审结果,如果确认要修改则进入修改状态,如果不是问题则作为非问题关闭,如果是问题但暂时无法解决则挂起,挂起的问题单到达指定修改期限时会再次进入打开状态。

修改后的问题单需由测试人员进行回归测试,如果回归通过则关闭问题单,如果回归不通过则重新进入打开状态。

画出状态迁移图,确定测试路径

六、流程分析法

例子1:ATM机取款流程

1、画出业务流程图

2、设置功能路径优先级

3、确定测试路径

路径1:(1)(2)(3)(4)(5)

路径2:(1)(6)

路径3:(1)(2)(7)(3)(4)(5)

路径4:(1)(2)(8)

路径5:(1)(2)(3)(9)(3)(4)(5)

路径6:(1)(2)(3)(10)(3)(4)(5)

路径7:(1)(2)(3)(11)(3)(4)(5)

路径8:(1)(2)(3)(12)(3)(4)(5)

路径9:(1)(2)(7)(2)(3)(9)(3)(10)(3)(11)(3)(12)(3)(4)(5)

4、选取测试数据

5、构造测试用例

路径1:(1)(2)(3)(4)(5)

测试用例编号ATM_ST_Qukuan_Normal_001

测试项目取款功能

测试标题所有字段输入合法成功取款

重要级别高

预置条件1、银行卡有效和账户上金额足够

输入1、密码:123456

2、取款金额:1000元

操作步骤1、插入银行卡

2、输入密码

3、输入取款金额

4、确认金额

5、取钱退卡

预期结果1、登录成功

2、页面跳转到zhangsan的邮箱界面

例子2:QQ安装过程(课堂练习)

4、画出业务流程图

2、设置功能路径优先级

3、确定测试路径

4、选取测试数据

5、构造测试用例

例子3:画出淘宝购物功能的业务流程图

提示:从搜索功能开始直到生成定单

七、正交实验法

例子1:

假设一个WEB站点,该站点有大量的服务器和操作系统,并且有许多具有各种插件的浏览器浏览:

WEB浏览器:Netscape6.2、IE6.0、opera4.0

插件:无、Realplayer、Mediaplayer

应用服务器:IIS、Apache、Netscape Enterprise

操作系统: Windows2K、Windows NT、Linux

全排列组合数:3*3*3*3=81种

1,根据需求找出因子和各自的状态,构造因子-状态表

状态\ 因子WEB浏览器插件应用服务器操作系统

状态1 Netscape6.2无IIS Windows2K

状态2 IE6.0Realplayer Apache Windows NT

Linux

状态3 opera4.0Mediaplayer Netscape

Enterprise

2,套用正交表

根据如上1中的因子-状态表,可以确定4因子3状态,则正好可以套用4因子-3状态的正交表

状态\ 因

123 4

1 1 1 1 1

2 1 2 2 2

3 1 3 3 3

4 2 1 2 3

5 2 2 3 1

6 2 3 1 2

7 3 1 3 2

8 3 2 1 3

9 3 3 2 1 再进行替换

状态\ 因子WEB浏览

插件应用服务

操作系统

1 Netscape

6.2无IIS Windows2

K

2 Netscape

6.2Realplay

er

Apache Windows

NT

3 Netscape

6.2Mediapla

yer

Netscape

Enterpri

se

Linux

4 IE6.0无Apache Linux

5 IE6.0Realplay

er Netscape

Enterpri

se

Windows2

K

6 IE6.0Mediapla

yer IIS Windows

NT

7 opera4.0无Netscape

Enterpri

se Windows NT

8 opera4.0Realplay

er

IIS Linux

9 opera4.0Mediapla

yer Apache Windows2

K

3,转成测试用例

如上表中共得到9个组合,即9条用例,一行的组合即为一条用例

用例1:Netscape6.2 ,无,IIS,Windows2K ;(这四种情况进行组合)用例2:Netscape6.2,Realplayer,Apache,Windows NT

用例3:。。。。

。。

用例9:

4,转成正式格式用例

例子2:

某数据库查询语言依规格说明书得到如下的因子―状态表

因子状态 A

查询类别

B

查询方式

C

元胞类别

D

打印方式

1 功能简单门终端显示

2 结构组合功能块图形显示

3 逻辑符号条件行式打印

(可用3因子2状态,4因子3状态两种方法)

第二种方法3因子2状态

1,构造因子-状态表(用简写表示)

状态\ 因子 A B C D

1 A1 B1 C1 D1

2 A2 B2 C2 D2

3 A3 B3 D3

根据对需求中各因子的权值的计算,认为D因子和A因子中的A3状态不重要,即需要删减D因子和A因子中的状态A3,如下表

状态\ 因子 A B C

1 A1 B1 C1

2 A2 B2 C2

3 B3

经过删减后,B因子中存在3个状态,故需要把其中2个状态合为一个节点21,才可以靠拢最接近的3因子2状态正交表

故需要通过用逻辑命令去组合其中的2个状态

布尔图

合并后得到如下表

状态\ 因子 A B C

1 A1 B1 C1

2 A2 21 C2

3、套用正交表

根据如上表可以套用3因子2状态正交表,如下

状态\ 因子 1 2 3

1 1 1 1

2 1 2 2

3 2 1 2

4 2 2 1

再进行替换,得到如下正交表

状态\ 因子 A B C

1 A1 B1 C1

2 A1 21 C2

3 A2 B1 C2

4 A2 21 C1

再进行拆分,需要把之前合并成的中间节点21拆出来,得到如下表

状态\ 因子 A B C

1 A1 B1 C1

2 A1 B2 C2

3 A1 B3 C2

4 A2 B1 C2

5 A2 B2 C1

6 A2 B3 C1

4、转成测试用例

如上表中共得到6条用例

用例1:A1 B1 C1

用例2:A1 B2 C2

用例1:A1 B1 C1

用例1:A1 B1 C1

用例1:A1 B1 C1

用例1:A1 B1 C1

5、转成正式用例格式

第一种方法4因子3状态

2,构造因子-状态表(用简写表示)

状态\ 因子 A B C D

1 A1 B1 C1 D1

2 A2 B2 C2 D2

3 A3 B3 D3

因为C 因子中缺少一个状态,为了能正常套用4因子-3状态正交表,故需要虚构一个状态C3来补充状态\ 因子 A B C D

1 A1 B1 C1 D1

2 A2 B2 C2 D2

3 A3 B3 C3 D3

3,套用正交表

根据如上构造因子-状态表可以套用4因子-3状态正交表

状态\ 因

123 4

1 1 1 1 1

2 1 2 2 2

3 1 3 3 3

4 2 1 2 3

5 2 2 3 1

6 2 3 1 2

7 3 1 3 2

8 3 2 1 3

9 3 3 2 1

再进行替换

A B C D

状态\ 因

1 A1 B1 C1 D1

2 A1 B2 C2 D2

3 A1 B3 C3 D3

4 A2 B1 C2 D3

5 A2 B2 C3 D1

6 A2 B3 C1 D2

7 A3 B1 C3 D2

8 A3 B2 C1 D3

9 A3 B3 C2 D1

因为状态C3是虚拟过来的,所以需要用C因子中已有的状态C1或C2来替换,如下表状态\ 因

A B C D

1 A1 B1 C1 D1

2 A1 B2 C2 D2

3 A1 B3 C1 D3

4 A2 B1 C2 D3

5 A2 B2 C2 D1

6 A2 B3 C1 D2

7 A3 B1 C2 D2

8 A3 B2 C1 D3

9 A3 B3 C2 D1

4,转测试用例

如上表中共得到9种组合,即9条用例

用例1:A1 B1 C1 D1

用例2:A1 B2 C2 D2

用例3:A1 B3 C1 D3

用例4:A2 B1 C2 D3

用例5:A1 B1 C1 D1

用例6:A1 B1 C1 D1

用例7:A1 B1 C1 D1

用例8:A1 B1 C1 D1

用例9:A1 B1 C1 D1

5,转正式用例格式

例子3:测试PPT的打印功能

因子状态A

打印范围

B

打印内容

C

打印颜色/灰度

D

打印效果

1 全部幻灯片颜色幻灯片加框

2 当前幻灯片讲义灰度幻灯片不加框

3 给定范围备注页黑白

4 大纲视图

1,根据需求找出因子和各自的状态,构造因子-状态表(简写)

因子状态A

打印范围

B

打印内容

C

打印颜色/灰度

D

打印效果

1 A1 B1 C1 D1

2 A2 B2 C2 D2

3 A3 B3 C3

4 B4

为了靠拢最接近的4因子3状态正交表,因为B因子中有4个状态需要合并为21,D因子中缺少1个状态,故需要虚拟一个D3

因子状态A

打印范围

B

打印内容

C

打印颜色/灰度

D

打印效果

1 A1 B1 C1 D1

2 A2 B2 C2 D2

3 A3 21 C3 D3

2,套用正交表

根据如上1中的因子-状态表,可以确定4因子3状态,则正好可以套用4因子-3状态的正交表状态\ 因

123 4

1 A1 B1 C1 D1

2 A1 B2 C2 D2

3 A1 B3 C3 D1

4 A1 B4 C3 D2

5 A2 B1 C2 D1

6 A2 B2 C3 D1

7 A2 B3 C1 D2

8 A2 B4 C1 D2

黑盒测试用例设计案例

黑盒测试用例设计案例 【例1】假设现有以下的三角形分类程序。该程序的功能是,读入代表三角形边长的3个整数,判定它们能否组成三角形。如果能够,则输出三角形是等边、等腰或任意三角形的分类信息。图9.11显示了该程序的流程图和程序图。为以上的三角形分类程序设计一组测试用例。 【解】 第一步:确定测试策略。在本例中,对被测程序的功能有明确的要求,即:

(1)判断能否组成三角形; (2)识别等边三角形; (3)识别等腰三角形; (4)识别任意三角形。因此可首先用黑盒法设计测试用例,然后用白盒法验证其完整性,必要时再进行补充。 第二步:根据本例的实际情况,在黑盒法中首先可用等价分类法划分输入的等价类,然后用边界值分析法和猜错法作补充。 等价分类法: 有效等价类 输入3个正整数: (1)3数相等 (2)3数中有2个数相等,比如AB相等 (3)3数中有2个数相等,比如BC相等 (4)3数中有2个数相等,比如AC相等 (5)3数均不相等 (6)2数之和不大于第3数,比如最大数是A

(7)2数之和不大于第3数,比如最大数是B (8)2数之和不大于第3数,比如最大数是C 无效等价类: (9)含有零数据 (10)含有负整数 (11)少于3个整数 (12)含有非整数 (13)含有非数字符 边界值法: (14)2数之和等于第3数 猜错法: (15)输入3个零 (16)输入3个负数 第三步:提出一组初步的测试用例,如下表所示:

第四步:用白盒法验证第三步产生的测试用例的充分性。结果表明,上表中的前8个测试用例,已能满足对被测程序图的完全覆盖,不需要再补充其他的测试用例。

软件测试用例模板

软件测试用例模板

用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门信息部 用例作者 完成日期2015-5-27 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 版本/状态作者参与者起止日期备注 V1.1 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI (图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现

功能是否一致。 用例标识LinkWorks_ WorkEvaluate _02 项目 名称 https://www.doczj.com/doc/2b7004505.html, 开发人员模块 名称 WorkEvaluate 用例作者参考 信息 工作考核系统界面设计 (2005_03_28).vsd 测试类型设计 日期 2006-9- 27 测试 人员 测试方法黑盒测试 日期 用例描述前置条件 编号权 限 ( 并 列 测试项测 试 类 别 描述/输入/操 作 期望结果真 实 结 果 备 注

关系) 000 01 无列 表 页 面 导航栏导 航 测 试 浏览\点击导 航连接 详细正确 导航页面 所在位置 000 02 添加删 除修改 按钮 添加修改删 除按钮是否 可用 不可用 000 03 接受、 汇报按 钮 1)不是自 己负责的 数据未考 核之前能 否接受\汇 报 不能 2)属于自 己负责的 未接受之 前时候是 否可以接 受 能

系统测试用例设计方法

系统测试用例设计方法 --------------王永安

目录 一、测试用例格式以及写作要点 (3) 二、系统测试用例设计方法 (4) 1、等价类划分法 (5) 2、边界值分析法 (6) 3、判定表法 (7) 4、因果图法 (9) 5、状态迁移图法 (15) 6、流程分析法 (20) 7、正交试验法 (35) 8、错误推测法 (42)

一、测试用例格式以及写作要点 测试用例编号 测试用例编号是由字母和数字组合而成的,用例的编号应该具有唯一性,易识别性。比如可以采用统一的约定,产品编号—ST—系统测试项名—系统测试子项名—编号。这样看到编号就可以知道是做的什么测试,测试的对象是什么。也方便维护。 测试项目 你现在这个测试用例所测的项目名,可以是测试用例所属的大类,被测需求,被测的模块,或者是被测的单元。例如:计算器加法功能。 测试标题 测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复,因为每个测试用例的测试点是不一样的。例如:手机在没有SIM 卡的情况下,拨打119。 重要级别 重要级别分为高中底三等: 高:保证系统基本功能、重要特性、实际使用频率比较高的用例; 中:重要程度介于高和底之间的测试用例; 底:实际使用频率不高、对系统业务功能影响不大的模块或功能的测试用例。 注:一般情况下,重要级别为高的测试用例,一个测试子项里有且尽有一个,大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试,如果重要级别为高的太多,则就失去了预测试的实际意义。 预置条件 就是执行当前测试用例的前提条件,如果不满足这些条件,则无法进行测试。 输入 测试用例执行时,需要输入的外部信息。例如某一个文件,数据记录等。

测试用例设计思路举例(参考)

ECShop2.7.2用例设计思路举例 说明 用例设计方法的运用非常灵活,没有绝对的套路可言,以下用例设计思路仅供参考。 操作流程举例 参考文档: ?ECShop_2.7.2_简易操作手册V1.0, ?B2C商城ECShop需求规格说明书_2.7.2V1.0 设计思路: 根据操作手册,理清业务逻辑前后关系,再结合SRS文档确定具体的流程细节和分支流程。可以通过画流程的方式梳理流程(流程分析法),下面是部分主流程的案例: ?正向订单流程_余额付款 1)前台页面浏览商品->加入购物车->结算中心->余额付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货->发货 3)前台页面确认收货END ?正向订单流程_货到付款 1)前台页面浏览商品->加入购物车->结算中心->货到付款 2)后台管理中心订单查询->配货->生成发货单->确认生成发货单->去发货 ?逆向订单流程 1)前台页面确认收货->后台管理中心退货->填写退货信息点确定按钮->确认退货 ?商品添加流程_新商品 1)后台管理中心商品管理->新建商品类型/新建商品分类/新建商品品牌->添加新商品(通用信息,详细描述,其他信息,商品属性,商品相册,关联商品,配件,关联 文章) 考虑完所有流程后,再补充考虑部分异常情况,例如:流程中的先后顺序发生变化,或者跳过某个步骤后,系统能否完成后续流程作业。(有些流程是不可能调换顺序或跳过的) Q:流程分析法在设计测试用例的时候会经过很多页面,操作很多字段,这些页面和字段该如何取值呢? A:流程分析法一般考虑页面或字段的有效取值(一般取等价类中最不容易出错的值),测试过程中不关注页面输入域的各种取值情况,特别是错误取值的情况。目的是为了确保流程是可用的。 Q:流程分析法既然不能证明某个页面或字段没有问题,那用此法有何意义呢,为何不直接考虑验证每个页面和模块的各种有效和无效的取值?

白盒与黑盒测试的测试用例设计(20210110002601)

第 5 章白盒与黑盒测试的测试用例设计 5.1 覆盖率的概念 覆盖率是用来度量测试完整性的一个手段逻辑覆盖和功能覆盖 覆盖率=(至少被执行一次的item 数)/item 总数 5.2 白盒测试的测试用例设计 5.2.1 逻辑覆盖逻辑覆盖是以程序内部的逻辑结构为基础的测试用例设计技术,属白盒测试。为了衡量测试的覆盖程度,需要建立一些作为测试彻底度的定量衡量标准。目前常用的覆盖标准是:语句覆盖;判定覆盖;条件覆盖;判定/ 条件覆盖;条件组合覆盖;路径覆盖 一、语句覆盖语句覆盖就是设计若干个测试用例,运行所测的程序,使得每一可执行语句至少执行一次。 二、判定覆盖判定覆盖就是设计若干个测试用例,使程序中的每个判断至少出现一次“真值”和一次“假值”,即程序中的每个分支都至少执行一次。 三、条件覆盖条件覆盖是指利用若干个测试用例,使被测试的程序中,对应每个判断中每个条件的所有可能情况均至少执行一次。 四、判定/ 条件覆盖 判定/ 条件覆盖就是设计足够多的测试用例,使得程序中每个判断条件的所有可能的结果至少取到一次,又使每次判断的每个分支至少通过一次。 五、条件组合覆盖 解决上述问题的新标准是条件组合覆盖。条件组合覆盖就是设计足够多的测试用例,使得每个判断的所有可能的条件取值组合至少执行一次。 六、逻辑覆盖举例 [例1]试用逻辑覆盖测试法为采用冒泡排序(bubble sorting )法进行数据排序的C 程序设

计测试用例。 本例是一个对k 个整数进行升序排序的C 程序,采用的算法是冒泡排序。基 本步骤是: (1)从数组中取出第2 个元素; (2)如果新取出的元素大于等于其前邻元素,则转向第(4)步; (3)如果新取出的元素小于其前邻元素,则与其前邻元素交换位置; (4)将新元素与新的前邻元素比较,若仍小于新的前邻元素,则重复第(3)步; (5)取下一个元素。如果数组中元素已取完则结束排序,否则转向第(2)步。 下面将给出本例的C程序。图2则是排序部分的流程图。 main() { int a[11],i,j,k,temp; scanf(“%d”,k); printf(“input numbers: n”); for(i=1;i<=k;i++) scanf(“ %d”,&a[i]);

软件测试用例文档模板(带实例)

软件测试用例模板(带实例) 工程管理系统案例研究项目功能测试用例 编号:Project_MA_Login_1 编号:Project_MA_Interface_3 项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Login 编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Login_1编制时间 2005-2-22 相关用例Project_MA_Main_1 、Project_MA_Interface_1 、Project_MA_Priority_1 功能特性系统的初始窗体,并进行用户的合法性验证。 测试目的验证是否输入合法的信息,阻止非法登陆,以保证系统的安全特性预置条件数据库中存储了一些用户信息特殊规程说明 (区分大小写) 参考信息需求说明中关于“登录”的说明测试数据用户名= administrators 密码= 1001(数据库表中有相应的信息)操作步骤 操作描述 数据期望结果 实际结果 测试状态(P/F ) 1 选择用户名称,按“提交”按钮。用 户 名 = administrators ,密码为空显示警告信息“帐号 或密码不能为空!” (符合) P 2 选择用户名称,输入错误密码,按 “提交”按钮。用 户 名 为 administrators ,密码=123 显示警告信息 “帐号 或密码不错误!” (符合) P 3 选择用户名称 ,输入密码,按“提交”按钮。 用 户 名 = administrators ,密码 为=1001 进入系统” (符合) P 测试人员 彭贝贝、李绍霞、 唐姣凤 开发人员杨丽娟负责人李虎(手写)

项目/软件工程管理系统案例研究项目程序版本 1.0.0 功能模块Interface编制人李虎、彭贝贝、唐姣凤用例编号Project_MA_Interface_3编制时间2005 – 2– 21 相关用例Project_MA_Interface_1、Project_MA_Interface_2、Project_MA_Priority_1、Project_MA_DBACCESS_1 功能特性维护界面添加操作 测试目的检查维护窗体界面与设计的符合性。 预置条件能够登录进入到系统特殊规程说明(无) 参考信息系统概要设计说明和详细设计说明 测试数据 操作步骤操作描述数据期望结果实际结果测试状态(P/F)1 …………… 2 3 4 5 6 7 8 9 10 11 12 测试人员彭贝贝、李绍霞、 唐姣凤开发人员杨丽娟负责人李虎(手写)

白盒测试用例设计方法

1白盒测试用例设计方法 1.1白盒测试简介 白盒测试又称结构测试、逻辑驱动测试或基于程序的测试,一般多发生在单元测试阶段。白盒测试方法主要包括逻辑覆盖法,基本路径法,程序插装等。 这里重点介绍一下常用的基本路径法,对于逻辑覆盖简单介绍一下覆盖准则。 1.2基本路径法 在程序控制流图的基础上,通过分析控制构造的环路复杂性,导出独立路径集合,从而设计测试用例,设计出的测试用例要保证在测试中程序的每一个可执行语句至少执行一次。 在介绍基本路径测试方法(又称独立路径测试)之前,先介绍流图符号: 图1 如图1所示,每一个圆,称为流图的节点,代表一个或多个语句,流程图中的处理方框序列和菱形决策框可映射为一个节点,流图中的箭头,称为边或连接,代表控制流,类似于流程图中的箭头。一条边必须终止于一个节点,即使该节点并不代表任何语句,例如,图2中两个处理方框交汇处是一个节点,边和节点限定的范围称为区域。 图2

任何过程设计表示法都可被翻译成流图,下面显示了一段流程图以及相应的流图。 注意,程序设计中遇到复合条件时(逻辑or, and, nor 等),生成的流图变得更为复杂,如(c)流图所示。此时必须为语句IF a OR b 中的每一个a 和b 创建一个独立的节点。

(c)流图 独立路径是指程序中至少引进一个新的处理语句集合,采用流图的术语,即独立路径必须至少包含一条在定义路径之前不曾用到的边。例如图(b)中所示流图的一个独立路径集合为: 路径1:1-11 路径2:1-2-3-4-5-10-1-11 路径3:1-2-3-6-8-9-10-1-11 路径4:1-2-3-6-7-9-10-1-11 上面定义的路径1,2,3 和4 包含了(b)流图的一个基本集,如果能将测试设计为强迫运行这些路径,那么程序中的每一条语句将至少被执行一次,每一个条件执行时都将分别取true 和false(分支覆盖)。应该注意到基本集并不唯一,实际上,给定的过程设计可派生出任意数量的不同基本集。如何才能知道需要寻找多少条路径呢?可以通过如下三种方法之一来计算独立路径的上界: 1. V=E-N+2,E 是流图中边的数量,N 是流图节点数量。 2. V=P+1,P 是流图中判定节点的数量 3. V=R,R 是流图中区域的数量 例如,(b)流图可以采用上述任意一种算法来计算独立路径的数量 1. V=11 条边-9 个节点+2=4 2. V=3 个判定节点+1=4 3. 流图有4 个区域,所以V=4 由此为了覆盖所有程序语句,必须设计至少4 个测试用例使程序运行于这4 条路径。 在采用基本路径测试方法中,获取测试用例可参考以下方式:

[方案]编写软件测试用例文档的例子

[方案]编写软件测试用例文档的例子TestCase_LinkWorks_WorkEvaluate 用例编号 LinkWorks 项目名称 WorkEvaluate模块模块名称 研发中心-质量管理部项目承担部门 用例作者 2005-5-27 完成日期 质量管理部本文档使用部门 评审负责人 审核日期 批准日期 注:本文档由测试组提交~审核由测试组负责人签字~由项目负责人批准。 历史版本: 版本/状态作者参与者起止日期备注 V1.1 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 项目名称用例标识 LinkWorks_ WorkEvaluate_02 MIIP 陈谦模块名称开发人员 WorkEvaluate 参考信息工作考核系统界面设计(2005_03_28).vsd 用例作者

设计日期测试人员高珍珍测试类型 2014-8-25 黑盒测试日期测试方法 用例描述 前置条件 编号权限测试项测试描述/输入/操作期望结果真实备注 (并列类别结果 关系) 无列导航栏导航浏览\点击导航连接详细正确导航页面所 00001 表测试在位置 页添加删除修添加修改删除按钮是否不可用 00002 面改按钮可用 接受、汇报按1) 不是自己负责的数据不能 钮未考核之前能否接受 \汇报 2) 属于自己负责的未接能 受之前时候是否可以 接受 00003 3) 属于自己负责的数据能 接受后但未考核能否 可以汇报 4) 接受后的数据没有汇不能 报但考核了,是否仍 可以汇报 考核审核按这俩按钮是否可用这两按钮为置灰,不 00004 钮可用 二级联动下功能下拉列表选择 1)默认为“本月由我

测试用例设计练习

一、等价类划分法 例子1: 现在有一个档案管理系统,容许用户通过输入年月对档案文件进行检索,系统对查询条件年月的输入限定为1990年1月-2049年12月,并规定,日期由6位数字组成,前4位表示年,后2位表示月。 1,根据需求进行分析,找出有哪些输入条件 年份:【1990,2049】 月份:【01,12】 字符长度:6位 字符类型:数字 2,画出等价类 输入条件有效等价类边界值分析无效等价类 年份【1990,2049】(1)上点:1990,2049(12) 离点:1989,2050 内点:2016 <1990 (2)>2049 (3) 月份【01,12】(4)上点:01,12(13) 离点:00,13 内点:11 <01 (5)>12 (6) 字符长度6位(7)上点:6 离点:5,7 内点:6 <6 (8)>6 (9) 字符类型数字(10)非数字(11)3,为每个等价类规定一个唯一编号(如上图) 4,转换成测试用例 转换测试用例的原则: A,设计一个测试用例尽可能多的覆盖多个有效等价类; B,设计一个测试用例必须对应覆盖一个无效等价类。 有效等价类用例: 用例1:201611 (1)(4)(7)(10) 无效等价类用例: 用例2:198911 (2) 用例3:205011 (3) 用例4:201600 (5) 用例5:201613 (6) 用例6:20161 (8) 用例7:2016113 (9) 用例8:20161a/abcedf (11) 根据边界值分析法分析后补充测试用例 用例9:199001 (12) 用例10:204912 (13) 5,转成正式格式用例(用例写作的8大要素) 用例编号D1223232_ST_Search_Date_001 项目搜索功能 标题输入正确的日期格式成功搜索

软件测试用例实例(非常详细)

1、兼容性测试 在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。测试目的 配置说明操作系统系统软件外设应用软件结果 服务器Window2000(S) WindowXp Window2000(P) Window2003 用例编号TestCase_LinkWorks_WorkEvaluate 项目名称LinkWorks 模块名称WorkEvaluate模块 项目承担部门研发中心-质量管理部 用例作者 完成日期2005-5-27 本文档使用部门质量管理部 评审负责人 审核日期 批准日期 注:本文档由测试组提交,审核由测试组负责人签字,由项目负责人批准。历史版本: 版本/状态作者参与者起止日期备注 V1.1 1.1. 疲劳强度测试用例 强度测试也是性能测试是的一种,实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。 测试目的

测试说明 前提条件连续运行8小时,设置添加10用户并发 测试需求输入/动作输出/响应是否正常运行 功能1 2小时 4小时 6小时 8小时 功能1 2小时 4小时 6小时 8小时 一、功能测试用例 此功能测试用例对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务 规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则 的实施是否恰当。主要测试技术方法为用户通过GUI(图形用户界面)与应用程序交互,对 交互的输出或接受进行分析,以此来核实需求功能与实现功能是否一致。 用例标识LinkWorks_ WorkEvaluate_02 项目名称https://www.doczj.com/doc/2b7004505.html, 开发人员模块名称WorkEvaluate 用例作者参考信息工作考核系统界面设计(2005_03_28).vsd 测试类型设计日期2006-9-27 测试人员 测试方法黑盒测试日期 用例描述 前置条件 编号权限 (并列 关系)测试项测试 类别 描述/输入/操作期望结果真实 结果 备注 00001 无列 表 页 面 导航栏导航 测试 浏览\点击导航连接详细正确导航页面所 在位置 00002 添加删除修 改按钮 添加修改删除按钮是否 可用 不可用 00003 接受、汇报按 钮 1)不是自己负责的数据 未考核之前能否接受 \汇报 不能 2)属于自己负责的未接 受之前时候是否可以 接受 能

测试用例的设计步骤

系统测试之功能测试:测试用例的设计步骤 ——从登陆开始说起 一个完整的software testing life cycle包括诸多内容,本文仅从测试用例的编写开始,聊聊测试用例编写的一般步骤,以使编写的测试用例最大程度上满足完备的要求,而又不产生重复而冗余的负担。 测试用例的来源是产品需求,如果足够幸运,我们应当有一份不错的可依赖的Use Case文档,但大部分情况下,Use Case恐怕是不存在,能有一份不错的PRD文档和原型设计图已经是不错的待遇了,如果可能的话,最好还能够有HLD文档,这些已经足够我们开始写详细的测试用例文档(我相信在这之前无法产出详细的测试用例文档①)。也许LLD文档产生之后或者产品的第一个版本发布之后,我们会不断的更新已有的测试用例,但那将是不断的迭代过程,暂不做讨论。 首先让我们先从理论上了解测试用例编写的一般步骤②: 1、确定测试套件(Test Suite):测试套件是功能上的划分,是相似测试场景的组合,而非技术划分。如果技术设计中各模块耦合度较高(强烈推荐解耦,哪怕复制粘贴代码),可能功能上不相干的模块由于代码重用的原因会在bug fix时互相引致错误,实际上回归测试即是为了避免这种情况。但是我们在做功能测试划分模块时,还是要从用户的角度出发,按照用户场景划分测试的“模块”。值得庆幸的是,相似或相关的功能总是倾向于在同一组页面出现,按钮和输入框、选择菜单等内容并不是随机组合的一堆零件。 2、针对每一个测试套件,确定一个或多个基本流程(basic flow)和可选流程(alternative flow),即测试场景(Test Scenario):可以借助scenario matrix来清晰地对可能出现的场景进行排列组合。值得注意的是,一方面Use Case或PRD文档中的描述很有可能并没有完整的写尽所有的场景,测试人员尽可能地挖掘测试场景,既有可能是出于测试本身的需要,也可能是基于开发团队的工作;另一方面,在复杂系统中,测试场景不可能覆盖所有可能的场景,这便需要测试人员采用一定的测试策略③,对SUT (System under Testing)进行“足够(adequate)”的测试,而不是完全的测试。 3、针对每一个测试场景,确定一到多个测试用例(Test Case):仍然可以借助matrix来清晰地规划测试用例,每一个测试用例都有其对应的预置条件④、输入和期望结果。测试用例分为Positive Test Ca se和Negative Test Case两种,分别用来测试产品是否完成应当完成的工作和不执行不应当完成的操作。更详尽地说,测试用例一般包括以下列column:用例编号/测试场景/用例描述/需求对应/用例分类(Positi ve/Negative)/用例类型/用例级别/是否自动化/预置条件/测试步骤/测试数据/预期结果/实际结果/备注/ 4、增加测试数据(Test Data)完成测试用例:测试数据是测试用例中很重要的内容,一个用例可能对应多套测试数据,测试工程师根据某种测试技术⑤,将尽可能的设计较少的测试数据完成“足够”的测试。 任何规范、流程都是为了让工作更加可靠,对于项目工程,天外飞仙灵机一动应当放在合适的位置,而不应当成为规范和流程的反例存在⑥。 现在让我们开始从登陆(PC端网页,如果是PC客户端比如QQ或手机客户端则又不同)开始说起。 不打开任何网站的登陆框,想象一下登陆框的样子。 然后对照一下本文最后的附图,一个优秀的登陆框除了基本的用户名/密码输入框、登陆按钮之外、(不考虑注册、找回密码、第三方登陆、登陆版本、帮助),包含的内容有:输入框文字提示/免登陆选项/输入

如何设计和执行测试用例

如何设计和执行测试用例测试需求收集完毕后,开始测试设计。 测试用例是什么?测试用例就是一个文档,描述输入、动作、或者时间和一个期望的结果,其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题: 测试用例的基本格式: 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果,下面逐一介绍。 用例编号:测试用例的编号有一定的规则,比如系统测试用例的编号这样定义规则: PROJECT1-ST-001 ,命名规则是项目名称+测试阶段类型(系统测试阶段)+编号。定义测试用例编号,便于查找测试用例,便于测试用例的跟踪。 测试标题:对测试用例的描述,测试用例标题应该清楚表达测试用例的用途。比如“测试用户登录时输入错误密码时,软件的响应情况”。 重要级别:定义测试用例的优先级别,可以笼统的分为“高”和“低”两个级别。一般来说,如果软件需求的优先级为“高”,那么针对该需求的测试用例优先级也为“高” ;反之亦然, 测试输入:提供测试执行中的各种输入条件。根据需求中的输入条件,确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性,如果软件需求中没有很好的定义需求的输入,那么测试用例设计中会遇到很大的障碍。 操作步骤:提供测试执行过程的步骤。对于复杂的测试用例,测试用

例的输入需要分为几个步骤完成,这部分内容在操作步骤中详细列出。 预期结果:提供测试执行的预期结果,预期结果应该根据软件需求中的输出得出。如果在实际测试过程中,得到的实际测试结果与预期结果不符,那么测试不通过;反之则测试通过。 软件测试用例的设计主要从上述 6 个域考虑,结合相应的软件需求文档,在掌握一定测试用例设计方法的基础上,可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍,白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍。 一般来说,每个软件公司的项目可以分为固定的几大类。可以按业务类型划分,比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等;可以按软件结构来划分,比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例,会有很大的借鉴意义。如果,公司中有同类别的软件系统,千万别忘记把相关的测试用例拿来参考。如果,系统非常接近,甚至经过对测试用例简单修改就可以应用到当前被测试的软件。“拿来主义”可以极大的开阔测试用例设计思路,也可以节省大量的测试用例设计时间。 加强测试用例的评审: 测试用例设计完毕后,最好能够增加评审过程。 同行评审是 CMM3 级的一个 KPA ,如果因为公司没有通过 CMM3 级,就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审,提交评审意见,然后根据评审意见更新测试用例。如果认真操作这个环节,测试用例中的很多问题都会暴露出来,比如用例设计错

用户名密码测试用例编写方法

用户名密码测试用例编 写方法 标准化管理处编码[BBX968T-XBB8968-NNJ668-MM9N]

别小看了这个用户名密码这么简单的输入框。可测试的内容还是很多的,并且引发的问题也有很多种类。下面就说一说他的测试方法。? 一、用户注册 只从用户名和密码角度写了几个要考虑的测试点,如果需求中明确规定了安全问题,Email,出生日期,地址,性别等等一系列的格式和字符要求,那就都要写用例测了~ 以等价类划分和边界值法来分析 1.填写符合要求的数据注册:用户名字和密码都为最大长度(边界值分析,取上点) 2.填写符合要求的数据注册:用户名字和密码都为最小长度(边界值分析,取上点) 3.填写符合要求的数据注册:用户名字和密码都是非最大和最小长度的数据(边界值分析,取内点)

4.必填项分别为空注册 5.用户名长度大于要求注册1位(边界值分析,取离点) 6.用户名长度小于要求注册1位(边界值分析,取离点) 7.密码长度大于要求注册1位(边界值分析,取离点) 8.密码长度小于要求注册1位(边界值分析,取离点) 9.用户名是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了,如含有空格,#等,看需求是否允许吧~) 10.密码是不符合要求的字符注册(这个可以划分几个无效的等价类,一般写一两个就行了) 11.两次输入密码不一致(如果注册时候要输入两次密码,那么这个是必须的)

12.重新注册存在的用户 13.改变存在的用户的用户名和密码的大小写,来注册。(有的需求是区分大小写,有的不区分) 14.看是否支持tap和enter键等;密码是否可以复制粘贴;密码是否以* 之类的加秘符号显示 备注:边界值的上点、内点和离点大家应该都知道吧,呵呵,这里我就不细说了~~ 二、修改密码 当然具体情况具体分析哈~不能一概而论~ 实际测试中可能只用到其中几条而已,比如银行卡密码的修改,就不用考虑英文和非法字符,更不用考虑那些TAP之类的快捷键。而有的需要根据需求具体分析了,比如连续出错多少次出现的提示,和一些软件修改密码要求一定时间内有一定的修改次数限制等等。

典型测试用例案例讲解

案例一:三角形判断功能测试 输入三条边,判断能否组成三角形,能组成三角形,继续判断能组成等腰三角形?等边三角形?还是直角三角形? 案例二:用户修改个人信息 要求:电话:11位长数字串 密码:18位以内的字符串(包含18位长) 用户登陆后可以修改个人信息,包含:电话号码、密码。 点击“修改用户信息”控件,系统显示所有用户个人信息: 其中用户名和工号不可修改,不能进行输入。密码分旧密码、新密码、验证新密码, 若需修改密码,系统验证旧密码正确,两个新密码相同,则更新密码,旧密码即失效,其他修改项也生效,并提示“用户信息修改成功”; 若旧密码不正确(旧密码是否正确),则提示“用户密码错”,系统将不修改个人信息;若两个新密码不同(两个新密码是否相同),则提示“新密码与验证新密码不同”,系统将不修改个人信息。 若只修改密码外其他信息(是否修改密码),则不需输入两个新密码,系统只验证旧密码正确,就成功更改个人信息,并提示“用户信息修改成功”;如果系统验证旧密码输入不正确,则提示“用户密码错”。

案例三:读书选择 1、如果觉得疲倦并且对书的内容感兴趣,同时书中的内容让你糊涂的话,回到本章重读 2、如果觉得疲倦并且对书的内容感兴趣,同时书中的内容不让你糊涂,继续读下去 3、如果觉得疲倦并且对书中的内容不感兴趣,同时书中的内容不让你糊涂,停止阅读,请休息 4、如果觉得疲倦并且对书的内容不感兴趣,并且书中的内容让你糊涂,请停止阅读,休息 5、不疲倦,对书的内容感兴趣,书中的内容不糊涂,继续读下去 6、不疲倦,不感兴趣,书中内容不糊涂,跳到下一章去读 7、不疲倦、不感兴趣、且糊涂跳到下一章去读 8、不疲倦、感兴趣,且糊涂回到本章重读 案例四:PPT打印功能测试 PowerPoint软件打印功能描述如下: 打印范围分:全部、当前幻灯片、给定范围共三种情况; 打印内容分:幻灯片、讲义、备注页、大纲视图共四种方式; 打印颜色/灰度分: 颜色、灰度、黑白共三种设置; 打印效果分:幻灯片加框和幻灯片不加框两种方式。 请利用如下正交表设计用例。 下面正交表共四个因子,其中每个因子三状态:

测试用例八大设计方法和实例

测试用例设计方法 1等价类划分 1.1 理论知识 等价类划分是一种典型的黑盒测试方法。这一方法完全不考虑程序的内部结构,只依据程序的规格说明来设计测试用例。 等价类是指某个输入域的子集合。在该子集合中,各个输入数据对于揭示程序中的错误都是等效的。 等价类合理地假设:某个等价类的代表值,与该等价类的其他值,对于测试来说是等价的。 因此,可以把全部的输入数据划分成若干的等价类,在每一个等价类中取一个数据来进行测试。这样就能以较少的具有代表性的数据进行测试,而取得较好的测试效果。 等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分(子集),然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法. 1) 分类: 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类. 有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能. 无效等价类:与有效等价类的定义恰巧相反. 设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性. 2)划分等价类的方法: 下面给出六条确定等价类的原则: ①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类. ②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效

最新系统测试用例模板说课讲解

XX项目 系统测试用例说明书

目录 1引言 (3) 1.1编写目的 (3) 1.2背景 (3) 1.3定义 (3) 1.4参考资料 (3) 2功能测试用例 (4) 2.3管理员测试用例 (4) 2.3.1 被测特性 (4) 2.3.2 A1.1添加用户测试用例 (4) 测试需求 (4) A1.1.1 (5)

1引言 1.1编写目的 本文档为(在此指出软件名称)的系统测试活动提供范围、方法、资源和进度方面的指导。预期的读者范围包括: ●项目经理 ●测试人员 ●用户 1.2背景 说明: (1)测试计划所从属的软件系统的名称; (2)该开发项目的历史,列出用户和执行此项目测试的计算中心,说明在开始执行本测试计划之前必须完成的各项工作。 1.3定义 1.4参考资料

2功能测试用例 2.3管理员测试用例 2.3.1 被测特性 管理员用户(Admin)的被测功能特性如下表所示。 2.3.2 A1.1添加用户测试用例 测试需求 测试需求如下表所示。

注意: 测试添加用户后的初始密码是否正确。(应通过登录系统功能来检验)(见交叉功能测试) 测试用例如A1.1.1到A1.1.15所示。 A1.1.1 (后续用例略) 人教版新课标英语必修二单词Unit 1 △cultural adj. 文化的 △relic n. 遗物;遗迹;纪念物 rare adj. 稀罕的;稀有的;珍贵的

valuable adj. 贵重的;有价值的 survive vi. 幸免;幸存;生还 vase n. 花瓶;瓶 dynasty n. 朝代;王朝 △Taj Mahal 泰姬陵 △ivory n. 象牙 △dragon n. 龙 △amber n. 琥珀;琥珀色 in search of 寻找 △Frederick William I 腓特烈·威廉一世(普鲁士国王)△Prussia n. (史)普鲁士(位于北欧) amaze vt. 使吃惊;惊讶 amazing adj. 令人吃惊的 select vt. 挑选;选择 honey n. 蜜;蜂蜜 design n. 设计;图案;构思vt. 设计;计划;构思fancy adj. 奇特的;异样的vt. 想象;设想;爱好

测试用例设计技术之----因果图

测试用例设计技术之----因果图 上次讲了因果图法的基本原理,这种方法是有因必有果,正是由于多个原因的不同组合,使得结果也不尽相同。由于组合情况很多,才用因果图法能大大简化测试用例的数量。 我们来看一个例子: 有一个饮料自动售货机(处理单价为5角钱)的控制处理软件,它的软件规格说明如下: 若投入5角钱的硬币,按下“橙汁”或“啤酒”的按钮,则相应的饮料就送出来。若投入1元钱的硬币,同样也是按“橙汁”或“啤酒”的按钮,则自动售货机在送出相应饮料的同时退回5角钱的硬币。 怎么分析这种具有一定实际意义的情况呢? 按照因果图的说法,我们先分析一下,把原因与结果先找出来: 原因是输入条件,在自动售货机里,硬币的投入、按钮的按下,都是输入,这样的话就有以下几个原因: (1)投入5角硬币 (2)投入1元硬币 (3)按下“橙汁”按钮 (4)按下“啤酒”按钮 结果有哪些呢? (1)送出“橙汁”饮料 (2)送出“啤酒”饮料 (3)找5角硬币 按照因果关系,把因果图的雏形画出来: 再加上因果图的约束关系,那么图形就成为以下:

根据最终的因果图生成判定表: 最后把测试用例写出来: 用例编号用例说明输入数据预期结果SHJ-001 (1)投入硬币 (2)按下按钮1元 点击“橙汁”按钮退还5角硬币 送出“橙汁”饮料 SHJ-002 (1)投入硬币 (2)按下按钮1元 点击“啤酒”按钮退还5角硬币 送出“啤酒”饮料 SHJ-003 (1)投入硬币1元给出提示信息SHJ-004 (1)投入硬币

(2)按下按钮5角 点击“橙汁”按钮送出“橙汁”饮料 SHJ-005 (1)投入硬币 (2)按下按钮5角 点击“啤酒”按钮送出“啤酒”饮料 SHJ-006 (1)投入硬币5角给出提示信息 SHJ-007 (1)按下按钮“橙汁”按钮给出提示信息SHJ-008 (1)按下按钮“啤酒”按钮给出提示信息

白盒测试用例设计方法

1.白盒测试用例设计方法 1.1. 白盒测试概述 由于逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。由于我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的情况下被执行。由于代码中的笔误是随机且无法杜绝的,因此我们要进行白盒测试。 白盒测试又称结构测试,透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法,盒子指的是被测试的软件,白盒指的是盒子是可视的,你清楚盒子部的东西以及里面是如何运作的。 1.白盒的测试用例需要做到 ?保证一个模块中的所有独立路径至少被使用一次; ?对所有逻辑值均需测试true 和false; ?在上下边界及可操作围运行所有循环; ?检查部数据结构以确保其有效性。 2.白盒测试的目的 通过检查软件部的逻辑结构,对软件中的逻辑路径进行覆盖测试;在程序不同地方设立检查点,检查程序的状态,以确定实际运行状态与预期状态是否一致。 3.白盒测试的特点 依据软件设计说明书进行测试、对程序部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。 4.白盒测试的实施步骤 1)测试计划阶段:根据需求说明书,制定测试进度。 2)测试设计阶段:依据程序设计说明书,按照一定规化的方法进行软件结构划分和设计测试用例。 3)测试执行阶段:输入测试用例,得到测试结果。 4)测试总结阶段:对比测试的结果和代码的预期结果,分析错误原因,找到并解决错误。 5.白盒测试的方法

总体上分为静态方法和动态方法两大类。 ?静态分析:是一种不通过执行程序而进行测试的技术。静态分析的关键功能是检查软件的表示和描述是否一致,没有冲突或者没有歧义。 ?动态分析:主要特点是当软件系统在模拟的或真实的环境中执行之前、之中和之后, 对软件系统行为的分析。动态分析包含了程序在受控的环 境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状 态下是正确还是不正确。在动态分析技术中,最重要的技术是路径和分支 测试。下面要介绍的六种覆盖测试方法属于动态分析方法。 6.白盒测试的优缺点 ?优点:迫使测试人员去仔细思考软件的实现;可以检测代码中的每条分支和路径;揭示隐藏在代码中的错误;对代码的测试比较彻底; 最优化 ?缺点:费用昂贵;无法检测代码中遗漏的路径和数据敏感性错误; 不验证规格的正确性。 1.2. 白盒测试基本技术 1.2.1.控制流图 1.2.1.1.定义 程序流程图是软件开发过程中进行详细设计时,表示模块部逻辑的一个常用的、也非常有效的图示法。程序流程图详细地反映了程序部控制流的处理和转移过程,它一般是进行模块编码的参考依据。在程序流程图中,通常拥有很多种图示元素,例如,“矩形框”表示一个计算处理过程,而“菱形框”表示一个判断条件等。通常测试人员为某个程序模块做白盒测试过程中,在做与路径相关的各种分析的时候,这些非常细节的信息往往是不太重要。因此,为了更清晰突出地显示出程序的控制结构,反映控制流的转移过程,一种简化了的程序流程图便出现了,就是程序的控制流图。在控制流图中一般只有两种简单的图示符号:节点和控制流。

测试用例实例

测试用例实例 1、一个好的用例的表述要点,即用例中应当包含的信息 一个优秀的测试用例,应该包含以下信息: 1)?软件或项目的名称 2)?软件或项目的版本(内部版本号) 3)?功能模块名 4)?测试用例的简单描述,即该用例执行的目的或方法 5)?测试用例的参考信息(便于跟踪和参考) 6)?本测试用例与其他测试用例间的依赖关系 7)?本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限 8)?用例的编号(ID),如可以是软件名称简写-功能块简写-NO.。 9)?步骤号、操作步骤描述、测试数据描述 10) 预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略) 11)开发人员(必须有)和测试人员(可有可无) 12)测试执行日期 2、实例 该测试案例是以一个B/S结构的登录功能点位被测对象,该测试用例为黑盒测试用例。假设用户使用的浏览器为 SP4。 功能描述如下: 1.用户在地址栏输入相应地址,要求显示登录界面; 2.输入用户名和密码,登录,系统自动校验,并给出相应提示信息; 3.如果用户名或者密码任一信息未输入,登录后系统给出相应提示信息; 4.连续3次未通过验证时,自动关闭IE。 表4-1登录界面测试用例

自动取款机取款用例规约和测试用例 取款用例说明: 此用例完成用户利用自动取款机取款的全部流程,分为以下流程:插卡,输入密码,选择金额,取款,取卡等操作。 事件流: 该用例在用户插卡之后启动 1. 系统提示用户插卡; 2. 提示客户输入密码信息; 3. 密码输入完毕后,客户选择“确认”,向系统提交信息; 4. 系统验证客户输入的密码信息,确认正确后,进入选择系统主界面; 5. 用户选择取款选项; 6. 系统进入取款金额界面并提示用户输入金额; 7. 系统验证可以取款并输出钱款; 8. 系统提示用户取卡,操作完成。 基本流: 用户取款。 备选流: 1.用户密码错误 2.取款金额不符合要求。 前置条件: 用户必须插入正确的银行卡才能开始执行用例。 后置条件: 如果系统确认用户信息正确,成功登陆,则系统启动主界面,等待用户发送消息,进行查询和取款等操作。

相关主题
文本预览
相关文档 最新文档