一个优秀的测试用例，应该包含以下信息：
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
操作步骤
操作描述
数 据
期望结果
实际结果
实际结果
测试状态
1
输入用户名称，按 “ 登陆 ” 按钮。
用户名 =yiyh ，密码为空
显示警告信息 “ 请输入用户名和密码！ ”
2
输入密码，按 “ 登陆 ” 按钮。
用户名为空，密码 =1
显示警告信息 “ 请输入用户名和密码！ ”
------------>>>
测试人员
开发人员
项目负责人
=====需求测试用例=======
客户需求列表－需求说明书 开发人员－系统说明书-功能列表 测试人员－－功能点测试列表
1注册功能 1用户可以自动注册 （对比发现问题）
===== 接口测试用例＝＝＝
接口 A 的函数原型
输入 / 动作
期望的输出 / 相应
实际情况
典型值 …
边界值 …
异常值 …
接口 B 的函数原型
输入 / 动作
期望的输出 / 相应
实际情况
典型值 …
边界值 …
异常值 …
…
==== 路径测试的检查用例====
检查项
结论
数据类型问题
（１）变量的数据类型有错误吗？
（２）存在不同数据类型的赋值吗？
（３）存在不同数据类型的比较吗？
变量值问题
（１）变量的初始化或缺省值有错误吗？
（２）变量发生上溢或下溢吗？
（３）变量的精度不够吗？
逻辑判断问题
（１）由于精度原因导致比较无效吗？
（２）表达式中的优先级有误吗？
（３）逻辑判断结果颠倒吗？
循环问题
（１）循环终止条件不正确吗？
（２）无法正常终止（死循环）吗？
（３）错误地修改循环变量吗？
（４）存在误差累积吗？
内存问题
（１）内存没有被正确地初始化却被使用吗？
（２）内存被释放后却继续被使用吗？
（３）内存泄漏吗？
（４）内存越界吗？
（５）出现野指针吗？
文件 I/O 问题
（１）对不存在的或者错误的文件进行操作吗？
（２）文件以不正确的方式打开吗？
（３）文件结束判断不正确吗？
（４）没有正确地关闭文件吗？
错误处理问题
（１）忘记进行错误处理吗？
（２）错误处理程序块一直没有机会被运行？
（３）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。
（４）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。
功能性测试用例
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）
