测试用例的写法与模板学习--Java免费学习网

一个优秀的测试用例,应该包含以下信息:
 
1 ) 软件或项目的名称
 
2 ) 软件或项目的版本(内部版本号)
 
3 ) 功能模块名
 
4 ) 测试用例的简单描述,即该用例执行的目的或方法
 
5 ) 测试用例的参考信息(便于跟踪和参考)
 
6 ) 本测试用例与其他测试用例间的依赖关系
 
7 ) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限
 
8 ) 用例的编号( ID ),如可以是 软件名称简写 - 功能块简写 -NO. 。
 
9 ) 步骤号、操作步骤描述、测试数据描述
 
10 )预期结果(这是最重要的)和实际结果(如果有 BUG 管理工具,这条可以省略)
 
11 )开发人员(必须有)和测试人员(可有可无)
 
12 )测试执行日期
 
例如以下这个模板:
 
项目 / 软件 
 技术出口合同网络申领系统 
 程序版本 
 1.0.25 
   
   
   
 
功能模块名 
 Login 
 编制人 
 xxx 
   
   
   
 
用例编号 - 
 TC-TEP_Login_1 
 编制时间 
 2010.10.12 
   
   
   
 
相关的用例 
 无 
   
   
   
   
   
 
功能特性 
 用户身份验证 
   
   
   
   
   
 
测试目的 
 验证是否输入合法的信息,允许合法登陆,阻止非法登陆 
   
   
   
   
   
 
预置条件 
 无 
 特殊规程说明 
 如数据库访问权限 
   
   
   
 
参考信息 
 需求说明中关于 “ 登陆 ” 的说明 
   
   
   
   
   
 
测试数据 
 用户名 =yiyh 密码 =1 
 
操作步骤 
 操作描述 
 数 据 
 期望结果 
 实际结果 
 实际结果 
 测试状态 
 

 输入用户名称,按 “ 登陆 ” 按钮。 
 用户名 =yiyh ,密码为空 
 显示警告信息 “ 请输入用户名和密码! ” 
   
   
   
 

 输入密码,按 “ 登陆 ” 按钮。 
 用户名为空,密码 =1 
 显示警告信息 “ 请输入用户名和密码! ” 
   
   
   
 
------------>>>
 
测试人员 
   
 开发人员 
   
   
 项目负责人 
   
 
 

=====需求测试用例=======
 
客户需求列表-需求说明书 开发人员-系统说明书-功能列表 测试人员--功能点测试列表 
1注册功能 1用户可以自动注册 (对比发现问题) 
     
 
===== 接口测试用例===
 
接口 A 的函数原型 
   
 
输入 / 动作 
 期望的输出 / 相应 
 实际情况 
 
典型值 … 
   
   
 
边界值 … 
   
   
 
异常值 … 
   
   
 
接口 B 的函数原型 
   
 
输入 / 动作 
 期望的输出 / 相应 
 实际情况 
 
典型值 … 
   
   
 
边界值 … 
   
   
 
异常值 … 
   
   
 
… 
   
   
 
 
==== 路径测试的检查用例====
 
检查项 
 结论 
 
数据类型问题 
(1)变量的数据类型有错误吗? 
(2)存在不同数据类型的赋值吗? 
(3)存在不同数据类型的比较吗? 
   
 
变量值问题 
(1)变量的初始化或缺省值有错误吗? 
(2)变量发生上溢或下溢吗? 
(3)变量的精度不够吗? 
   
 
逻辑判断问题 
(1)由于精度原因导致比较无效吗? 
(2)表达式中的优先级有误吗? 
(3)逻辑判断结果颠倒吗? 
   
 
循环问题 
(1)循环终止条件不正确吗? 
(2)无法正常终止(死循环)吗? 
(3)错误地修改循环变量吗? 
(4)存在误差累积吗? 
   
 
内存问题 
(1)内存没有被正确地初始化却被使用吗? 
(2)内存被释放后却继续被使用吗? 
(3)内存泄漏吗? 
(4)内存越界吗? 
(5)出现野指针吗? 
   
 
文件 I/O 问题 
(1)对不存在的或者错误的文件进行操作吗? 
(2)文件以不正确的方式打开吗? 
(3)文件结束判断不正确吗? 
(4)没有正确地关闭文件吗? 
   
 
错误处理问题 
(1)忘记进行错误处理吗? 
(2)错误处理程序块一直没有机会被运行? 
(3)错误处理程序块本身就有毛病吗?如报告的错误与实际错误不一致,处理方式不正确等等。 
(4)错误处理程序块是“马后炮”吗?如在被它被调用之前软件已经出错。 
   
 
功能性测试用例
 
    1. 测试的来源,即测试的需求
 
    测试用例的主要来源有:1) 需求说明“及相关文档2)相关的设计说明(概要设计,详细设计等)
 
    3)与开发组交流对需求理解的 记录(可以是开发人员的一个解释)
 
    4)已经基本成型的UI(可以有针对性地补充一些用例)
 
    简而言之,所有你能得到的项目文档,都尽量拿到。 从所得到的资料中,分解出若干小的“功能点”,理解“功能点”,编写相应的测试用例。
 
    2. 用例的组织方式
 
    不同的公司有不同的做法,原则上,只要方便管理和跟踪,怎么组织都可以的。
 
    用例可以按大的功能块组织,如查询功能模块的用例,可以组织在一起,打印模块的测试用例,可以另外组织在一起。
 
    在没有专门的测试用例管理工具的情况下,用例执行后会产生2种状态:“通过”、“失败”——这样加上“未 执行”的用例的状态,共3种状态。
 
    即从“未执行”用例中执行一个用例后,该用例状态应为“失败”或“通 过”。将同一状态的用例组织在一起。
 
    至于用例文件格式,可以是。DOC或。XLS(如果有专门的测试用例管理工具另当别论)。
 
    3. 用例与其他材料的关联方式,即如何解决用例跟踪的问题
 
    测试用例面临的比较大的风险有:需求的变更、设计的修改、需求的错误和遗漏等等。
 
    由于用例的主要来源是需求和设计的说明,所以对用例的跟踪其实就是对需求和设计的跟踪,需求和设计的 变更势必引起测试用例的变更。
 
    如前所说,将分解的功能点编号,与相应的用例联系起来。例如,你可以列一个表格,列出各个(编号的)功 能点和测试用例间的关联关系。
 
    这样,当需求和设计发生变化时,你只需要跟踪“功能点”是否变化,是否增加了新的功能点。
 
    4. 一个好的用例的表述要点,即用例中应当包含的信息
 
    一个优秀的测试用例,应该包含以下信息:1) 软件或项目的名称2) 软件或项目的版本(内部版本号)
 
    3) 功能模块名4) 测试用例的简单描述,即该用例执行的目的或方法5) 测试用例的参考信息(便于跟踪和参考)
 
    6) 本测试用例与其他测试用例间的依赖关系7) 本用例的前置条件,即执行本用例必须要满足的条件,如对数据库的访问权限8) 用例的编号(ID),如可以是 软件名称简写-功能块简写-NO.。
 
    9) 步骤号、操作步骤描述、测试数据描述10)预期结果(这是最重要的)和实际结果(如果有BUG管理工具,这条可以省略)
 
    11)开发人员(必须有)和测试人员(可有可无)
 
    12)测试执行日期
 
    5. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。
 
    备注:本用例未考虑“企业代码”的输入情况;测试用例并未涵盖所有的非法输入,如非法输入中可能会有 “user=*,pw=*”的组合,对回车的默认操作,空格输入,对输入上溢的处理的处理(可能会跳过身份验证) 等等。
 

    如果你有兴趣,至少可以再补充5-10条左右的输入组合(当然,如果步骤超过15步,用例的易操作 性就降低,你可以再创建一个测试用例如TC-TEP_Login_2)

文章转载自 http://www.javalearns.com/Html/?1829.html


更多Java知识学习请访问 Java免费学习网  http://www.javalearns.com


关注微信号:javalearns  ,随时随地学Java
手机赚钱网:http://javalearns.jifenqiang.com/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值