无忧测试QQ0625整理——功能测试用例

bobli

我只看到了部分，是不是Song的作品？还有谁来补充一下？

功能测试用例

功能A描述
　
用例目的
　
前提条件
　
输入/动作   期望的输出/相应    实际情况

示例：典型值…
　 　
示例：边界值…
　 　
示例：异常值…
　 　
功能B描述
　
用例目的
　
前提条件
　
输入/动作  期望的输出/相应    实际情况

……

[ Last edited by bobli on 2004-6-28 at 21:28 ]

[ Last edited by bobli on 2004-8-3 at 13:21 ]

jadeyu712

学了呀1

lfy123

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. 给出一个测试用例的例子该范例已经包含一个测试用例的模板。
项目/软件         技术出口合同网络申领系统 （企业端）         程序版本         1.0.25                        
功能模块名         Login         编制人 　         xxx                        
用例编号-         TC-TEP_Login_1         编制时间 　         2002.10.12                        
相关的用例         无                                        
功能特性         用户身份验证                                        
测试目的         验证是否输入合法的信息，允许合法登陆，阻止非法登陆                                        
预置条件         无         特殊规程说明         如数据库访问权限                        
参考信息         需求说明中关于“登陆”的说明                                        
测试数据         用户名=yiyh 密码=1
操作步骤         操作描述         数 据         期望结果         实际结果         实际结果         测试状态
1         输入用户名称，按“登陆”按钮。         用户名=yiyh，密码为空         显示警告信息“请输入用户名和密码！”                        
2         输入密码，按“登陆”按钮。         用户名为空，密码=1         显示警告信息“请输入用户名和密码！”                        
3         输入用户名和密码，按“登陆”按钮。         用户名=yiyh，密码=2         显示警告信息“请输入用户名和密码！”                        
4         输入用户名和密码，按“登陆”按钮。         用户名=xxx，密码=1         显示警告信息“请输入用户名和密码！”                        
5         输入用户名和密码，按“登陆”按钮。         用户名=xxx，密码=2         显示警告信息“请输入用户名和密码！”                        
6         输入用户名和密码，按“登陆”按钮。         用户名=空，密码=空         显示警告信息“请输入用户名和密码！”                        
7         输入用户名和密码，按“登陆”按钮。         用户名=yiyh，密码=1         进入系统页面。                        
8         输入用户名和密码，按“登陆”按钮。         用户名=Admin，密码=admin         进入系统维护页面。                        
9         输入用户名和密码，按“登陆”按钮。         用户名=yiyh',密码=1         显示警告信息“请输入用户名和密码！”                        
10         输入用户名和密码，按“登陆”按钮。         用户名=yiyh，密码=1'         显示警告信息“请输入用户名和密码！”                        
11         输入用户名和密码，按“重置”按钮。         用户名=yiyh，密码=1         清空输入信息                        
测试人员                 开发人员                         项目负责人        

备注：本用例未考虑“企业代码”的输入情况；测试用例并未涵盖所有的非法输入，如非法输入中可能会有
“user=*,pw=*”的组合，对回车的默认操作，空格输入，对输入上溢的处理的处理（可能会跳过身份验证） 等等。
如果你有兴趣，至少可以再补充5-10条左右的输入组合
（当然，如果步骤超过15步，用例的易操作 性就降低，你可以再创建一个测试用例如TC-TEP_Login_2）。

songfun

┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃用例编号　　│BOSS_ FS_ MARKETING_NEW_01P　　　　　　　　　　　　　 ┃
┠──────┼───────────────────────────┨
┃测试优先级　│高（还有“较高、中、较低、低”几个等级）　　　　　　　┃
┠──────┼───────────────────────────┨
┃用例摘要　　│新增营销记录　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试类型　　│功能性测试（对应还有“安全性测试”等）　　　　　　　　┃
┠──────┼───────────────────────────┨
┃用例类型　　│基本事件（对应还有“备选事件”、“异常事件”）　　　　┃
┠──────┼───────────────────────────┨
┃用例设计者　│songfun　　　　　　　　　　　　　　　　　　　　　　　 ┃
┠──────┼───────────────────────────┨
┃设计日期　　│2005-04-25　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃对应需求编号│REQ_ MARKETING_NEW_01　　　　　　　　　　　　　　　　 ┃
┠──────┼───────────────────────────┨
┃对应UI　　　│Marketing.htm　　　　　　　　　　　　　　　　　　　　 ┃
┠──────┼───────────────────────────┨
┃对应UC　　　│UC_ MARKETING_NEW_01　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃版本号　　　│Build v0.1　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃对应开发人员│Frank　　　　　　　　　　　　　　　　　　　　　　　　 ┃
┠──────┼───────────────────────────┨
┃前置条件　　│操作员登录营销管理系统　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试方法　　│等价类划分（对应还有“错误猜测法”、“边界值分析”等）┃
┠──────┼───────────────────────────┨
┃输入数据　　│用户名：51testing 性别：男 金额：10元 描述：aaaaaaa　 ┃
┠──────┼───────────────────────────┨
┃执行步骤　　│①.进入【营销下发】页面；　　　　　　　　　　　　　　 ┃
┃　　　　　　│②.点击『增加』按钮；　　　　　　　　　　　　　　　　 ┃
┃　　　　　　│③.输入相应数据；　　　　　　　　　　　　　　　　　　 ┃
┃　　　　　　│④.点击『确定』按钮；　　　　　　　　　　　　　　　　 ┃
┃　　　　　　│⑤.在后台数据库(test/test@testDB)输入查询语句验证：　 ┃
┃　　　　　　│　　select * from MarketingTab where ID='1001'　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃预期输出　　│㈠.执行步骤④后，页面弹出添加成功提示信息框；　　　　 ┃
┃　　　　　　│㈡.执行步骤⑤后查询数据库，记录确实添加成功且数据无误 ┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃实际结果　　│符合预期　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试日期　　│2005-05-01　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃结论　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

[ Last edited by songfun on 2005-4-27 at 11:36 ]

songfun

┏━━━━━━┯━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃用例编号　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试优先级　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃用例摘要　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试类型　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃用例类型　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃用例设计者　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃设计日期　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃对应需求编号│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃对应UI　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃对应UC　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃版本号　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃对应开发人员│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃前置条件　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试方法　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃输入数据　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃执行步骤　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┃　　　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃预期输出　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃实际结果　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃测试日期　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┠──────┼───────────────────────────┨
┃结论　　　　│　　　　　　　　　　　　　　　　　　　　　　　　　　　┃
┗━━━━━━┷━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

[ Last edited by songfun on 2005-4-27 at 11:35 ]

songfun

嗯？这个我改天给个具体的——为什么发在沙龙版呢？呵呵…………

[ Last edited by songfun on 2005-4-23 at 21:13 ]

flamezv

楼上的我觉得能接受，楼主的是不是复杂了点。

钟花花

功能测试用例
———————
系统版本

用例名称

用例编号

测试时间

测试人员

功能描述  //这个可不可以省略？
　
用例目的  //这个可不可以省略？
　
前提条件  //这个可不可以摆在步骤里面？
　
步骤1   预期结果    实际结果
步骤2   预期结果    实际结果

bobli

呵呵，谁来完整的写一个？

早春二月

应该加上系统环境和硬件环境

hxf

应该为每个用例加上序列号，有利于对测试用例的查找。

海的女儿

测试用例与BUG管理工具组合起来用还好，如果分开的话，个人认为用例中的“实际情况”还有必要么，我原来填的都是"实现"之类的

yesman

bobli

jody

比如说版本呀,
还有用例设计人,设计日期以备跟踪.