测试用例资料.docx

测试用例资料.docx功能性测试用例
测试的来源，即测试的需求
测试用例的主要来源有：
1） 需求说明”及相关文档
2） 相关的设计说明（概要设计，详细设计等）
3） 与开发组交流对需求理解的记录（可以是开发人员的一个解释）
4）已经基本成型的UI （可以有针对性地补充一些用例）
简而言之，所有你能得到的项目文档，都尽量拿到。从所得到的资料中，分解出若干小 的“功能点”，理解“功能点”，编写相应的测试用例。
用例的组织方式
不同的公司有不同的做法，原则上，只要方便管理和跟踪，怎么组织都可以的。
用例可以按大的功能块组织，如查询功能模块的用例，可以组织在一起，打印模块的测试用例， 可以另外组织在一起。
在没有专门的测试用例管理工具的情况下，用例执行后会产生2种状态：“通过”、“失 败”——这样加上'‘未执行”的用例的状态，共3种状态。
即从“未执行”用例中执行一个用例后，该用例状态应为“失败”或“通 过”。将同一状 态的用例组织在一起。
至于用例文件格式， （如果有专门的测试用例管理工具另当别论）。
用例与其他材料的关联方式，即如何解决用例跟踪的问题
测试用例面临的比较大的风险有：需求的变更、设计的修改、需求的错误和遗漏等等。
由于用例的主要来源是需求和设计的说明，所以对用例的跟踪其实就是对需求和设计的跟踪，需 求和设计的变更势必引起测试用例的变更。
如前所说，将分解的功能点编号，与相应的用例联系起来。例如，你可以列一个表格，列出各 个（编号的）功能点和测试用例间的关联关系。
这样，当需求和设计发生变化时，你只需要跟踪“功能点”是否变化，是否增加了新的功能点。
一个好的用例的表述要点，即用例中应当包含的信息
一个优秀的测试用例，应该包含以下信息：
1） 软件或项目的名称
2） 软件或项目的版本（内部版本号）
3） 功能模块名
4） 测试用例的简单描述，即该用例执行的目的或方法
5） 测试用例的参考信息（便于跟踪和参考）
6） 本测试用例与其他测试用例间的依赖关系
7） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限
8） 用例的编号（ID）,如可以是软件名称简写-功能块简写-NO.。
9） 步骤号、操作步骤描述、测试数据描述
10） 预期结果（这是最重要的）和实际结果（如果右BUG管理工具，这条可以省略）
11） 开发人员（必须右）和测试人员（可右可无）
12） 测试执行日期
给出一个测试用例的例子该范例已经包含一个测试用例的模板。
项目/ 软件
技术出口合同网络申
领系统（企业端）
程序版本

功能 模块 名
Login
编制人
XXX
用例 编号・
TC-TEP 丄 ogin_l
编制时可

相关 的用 例
无
功能 特性
用户身份验证
测试
目的
验证是否输入合法的 信息，允许合法登陆, 阻止非法登陆
预苴 条件
无
特殊规程说
明
如数据库 访间权限
参考 信息
需求说明中关于“登 陆”的说明
测试 数据
用户名=yig密码=1
操作
步骤
操作描述
期望结果
预期实际结 结果果
测 试 状 态
垮入田户空的 用户名 显示警告信息•乍 鑑密黔用户名和密
输入密码，按“登用户名为 陆”按钮. 空，密码=1
输入用户名和密用户名 码，按“登陆”按=yiyh,密 钮. 码=2
显示警告信息“请 输入用户名和密 码！”
输入用户名和密用户名 显示警告信息“请
码援“登陆对安
£D
Tllo
=xxx,密码输入用户名和密 =1 码！"
输入用户名和密用户名 显示警告信息“谙 码，技“登陆”援=xxx，密码输入用户名和密 钮. =2 码！”
输入用户名和密用户名=显示警告信息“请 码 按“登陆”扌妥空，密码=输入用户名和密 钮. 空 码！”
输入用户名和密用户名
码按“登陆”按=yiyh,密进入系统页面. 钮. 码=[
髀芻嘗,聲系统维护页
=admin
输入用户名和密用户名 显示警告信息“请 码 按“登陆”按=yiyh：密码输入用户名和密 钮. =1 码
10
输入用户名和密用户名 显示警告信息“谙 码按“登陆”按=yiyh,密输入用户名和密 钮. 码=1- 码！”
11
输入用户名和密用户名
码，按“重置对妥=yiyh,密清空输入信息
测试 人员
千发人员
备注：本用例未考虑“企业代码”的