- 2
- 0
- 约3.18千字
- 约 8页
- 2019-08-12 发布于江苏
- 举报
案例1试用例的设计与编写
表1 用例设计表(Table of Case Design)
用例编号 测试用例名称
软件名称
XXXX系统
模块名称
设 计 者
创建日期
设计状态
用例类型
手工
版本号
1.0
审 阅 人
审阅日期
权 重
用例描述
对测试用例进行描述,内容包括但不限于以下内容
测试内容描述
测试环境
性能要求
界面规格
特别提示、注意事项
目 的
测试用例目的描述
前提条件
执行该用例有无前提条件?如有,则列出前提条件
覆盖需求
这里填写所覆盖的所有需求编号
执行状态
Pass / Fail
关联缺陷
这里填写所有关联缺陷的编号
变更记录
变更字段
新的值
变更人
变更日期
数据列表:
数据字段1
测试步骤
输入数据字段n
…….
预期结果
测试结果
用例编号
填写测试步骤或测试输入等(可以包含更进一步的步骤)
数据
填写执行该步骤或输入应该产生的结果
上表为在单位工作时实际项目的用例表格,在实际的用例编写过程中,需要丰富的经验,今在国内,多数的项目还是以用例覆盖缺陷的形式来发现软件中潜在的问题,如金融系统,管理系统等等。只有少数的游戏测试采用随机测试的方式。所以在用例的设计过程中,需要考虑尽可能多的测试技术以达到最大的缺陷覆盖比例。此表的实例请见下面表2。
测试用例与执行
测试用例主要是用例设计者根据业务设计师的业务需求,对业务进行用例设计,保证用例所验证的功能为业务设计师的意图。并通过合理测试方法的搭配,覆盖隐藏在程序中的缺陷。
本节将以上节的需求为基础,融入测试方法,对用户登录的需求进行用例编写。
表2 用户登陆用例设计 (User Login’s Case Design)[10]
1.1 用户登陆
软件名称
电子商务系统
功功能模块名
用户登录Login
设 计 者
xx
创建日期
2007-3-8
设计状态
完毕
用例类型
手工
版本号
1.0.2010.10.23
审 阅 人
Kitty
审阅日期
2007-3-
权重(优先级)
中
功能特性 :用户身份验证
用例描述
用户登录
Iexplorer 浏览器
10秒内登录成功
测试目的
验证用户登录功能的正确性,允许合法登录,阻止非法登录
前提条件
后台预设了一组用户名,密码,(zz,123456)即存在一已注册的用户。
测试环境
硬件环境:服务器端:DELL(CPU:P4, RAM 2G)
客户端:DELL(CPU:P4, RAM 2G)
软件环境:服务器端:操作系统-windows2000;数据库-SQL;web服务器-IIS
客户端:操作系统-windows-XP;浏览器:IE7.0
覆盖需求
SRS1.1.1(需求规格说明书中关于“登录”
执行状态
Step 3 Fail
关联缺陷
0308_Bug#1
变更记录
变更字段
新的值
变更人
变更日期
数据列表:
数据字段编号
测试步骤
输入数据
预期结果
测试结果
用户名
密码
Login-001
1输入正确用户名密码
2按“登录”按钮
3. 按“退出”按钮
zz
123456
登录到用户界面,页面固定位置显示 “欢迎zz光临本网站”,退出至首页
Login-002
输入未注册的用户名,
输入正确的密码
按“登录”按钮。
xx
123456
系统提示,“没有这名会员的信息”
Login-003
输入正确用户名,
输入非法的密码
按“登录”按钮。
qq
654321
系统提示,“没有这名会员的信息”
Login-004
Login-005
用例实例分析
上述表格是根据SRS1.1(需求规格说明书)的需求而设计的测试用例,根据上节对与用户登录名及密码的限制,在测试用例步骤中应考虑到相应的有效等价类与无效等价类(黑盒测试方法-边界值分析)。
如涉及到字符限制,还应考虑到等价类划分的测试方法。
除次以外,一些经验丰富的测试人员可以根据错误推测法在用例中设计相应的用例。
用例的执行
如表2 所示,最后的执行状态显示为步骤3失败,说明程序中有与需求不符的缺陷,这样就需要在测试的过程中提交相应的缺陷报告,这些职责都应由测试员来执行。
******************************************************************************
案例2 测试设计
当一份测试需求制定好以后,Designer就开始了Design Test Case,当然,这些制定出来的Test Case必须要覆盖到测试需求,Test Case并不是独立存在的。测试设计中黑盒测试设计有这么几种方法:等价类划分,边界值分析,错误推测法,因果图法。在我参与的项目中Designer需要将他们Design出来的Tes
原创力文档

文档评论(0)