《测试用例的书写方式与测试模板大全》由会员分享，可在线阅读，更多相关《测试用例的书写方式与测试模板大全（31页珍藏版）》请在金锄头文库上搜索。
1、测试用例的书写方式及测试模板大全 一个优秀的测试用例，应该包含以下信息： 1 ） 软件或项目的名称 2 ） 软件或项目的版本（部版本号） 3 ） 功能模块名 4 ） 测试用例的简单描述，即该用例执行的目的或方法 5 ） 测试用例的参考信息（便于跟踪和参考） 6 ） 本测试用例与其他测试用例间的依赖关系 7 ） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库的访问权限 8 ） 用例的编号（ ID ），如可以是 软件名称简写 - 功能块简写 -NO. 。 9 ） 步骤号、操作步骤描述、测试数据描述 10 ）预期结果（这是最重要的）和实际结果（如果有 BUG 管理工具，这条可以省略） 1
2、1 ）开发人员（必须有）和测试人员（可有可无） 12 ）测试执行日期 例如以下这个模板： 项目 / 软件 技术出口合同网络申领系统 程序版本 1.0.25 功能模块名 Login 编制人 xxx 用例编号 - TC-TEP_Login_1 编制时间 2010.10.12 相关的用例 无 功能特性 用户身份验证 测试目的 验证是否输入合法的信息，允许合法登陆，阻止非法登陆 预置条件 无 特殊规程说明 如数据库访问权限 参考信息 需求说明中关于 “ 登陆 ” 的说明 测试数据 用户名 =yiyh 密码 =1 操作步骤 操作描述 数 据 期望结果 实际结果 实际结果 测试状态 1 输入用户名称，按
3、“ 登陆 ” 按钮。 用户名 =yiyh ，密码为空 显示警告信息 “ 请输入用户名和密码！ ” 2 输入密码，按 “ 登陆 ” 按钮。 用户名为空，密码 =1 显示警告信息 “ 请输入用户名和密码！ ” -测试人员 开发人员 项目负责人 =需求测试用例=客户需求列表需求说明书开发人员系统说明书-功能列表测试人员功能点测试列表1注册功能1用户可以自动注册（对比发现问题）= 接口测试用例接口 A 的函数原型 输入 / 动作 期望的输出 / 相应 实际情况 典型值 边界值 异常值 接口 B 的函数原型 输入 / 动作 期望的输出 / 相应 实际情况 典型值 边界值 异常值 = 路径测试的检查用例=
4、检查项 结论 数据类型问题 （）变量的数据类型有错误吗？ （）存在不同数据类型的赋值吗？ （）存在不同数据类型的比较吗？ 变量值问题 （）变量的初始化或缺省值有错误吗？ （）变量发生上溢或下溢吗？ （）变量的精度不够吗？ 逻辑判断问题 （）由于精度原因导致比较无效吗？ （）表达式中的优先级有误吗？ （）逻辑判断结果颠倒吗？ 循环问题 （）循环终止条件不正确吗？ （）无常终止（死循环）吗？ （）错误地修改循环变量吗？ （）存在误差累积吗？ 存问题 （）存没有被正确地初始化却被使用吗？ （）存被释放后却继续被使用吗？ （）存泄漏吗？ （）存越界吗？ （）出现野指针吗？ 文件 I/O 问题 （）对不
5、存在的或者错误的文件进行操作吗？ （）文件以不正确的方式打开吗？ （）文件结束判断不正确吗？ （）没有正确地关闭文件吗？ 错误处理问题 （）忘记进行错误处理吗？ （）错误处理程序块一直没有机会被运行？ （）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。 （）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。 =功能测试用例=功能 A 描述 用例目的 前提条件 输入 / 动作 期望的输出 / 相应 实际情况 示例：典型值 示例：边界值 示例：异常值 功能 B 描述 用例目的 前提条件 输入 / 动作 期望的输出 / 相应 实际情况 =健壮性测试- 容
6、错能力 / 恢复能力测试用例=异常输入 / 动作 容错能力 / 恢复能力 造成的危害、损失 示例：错误的数据类型 示例：定义域外的值 示例：错误的操作顺序 示例：异常中断通信 示例：异常关闭某个功能 示例：负荷超出了极限 =性能测试用例=性能 A 描述 用例目的 前提条件 输入数据 期望的性能（平均值） 实际性能（平均值） 性能 B 描述 用例目的 前提条件 输入数据 期望的性能（平均值） 实际性能（平均值） =界面测试用例界面检查表=检查项 测试人员的类别及其评价 窗口切换、移动、改变大小时正常吗？ 各种界面元素的文字正确吗？（如标题、提示等） 各种界面元素的状态正确吗？（如有效、无效、选中
7、等状态） 各种界面元素支持键盘操作吗？ 各种界面元素支持鼠标操作吗？ 对话框中的缺省焦点正确吗？ 数据项能正确回显吗？ 对于常用的功能，用户能否不必阅读手册就能使用？ 执行有风险的操作时，有“确认”、“放弃”等提示吗？ 操作顺序合理吗？ 有联机帮助吗？ 各种界面元素的布局合理吗？美观吗？ 各种界面元素的颜色协调吗？ 各种界面元素的形状美观吗？ 字体美观吗？ 图标直观吗？ =信息安全测试用例=假想目标 A 前提条件 非法入侵手段 是否实现目标 代价利益分析 假想目标 B 前提条件 非法入侵手段 是否实现目标 代价利益分析 =压力测试用例=极限名称 A 例如“最大并发用户数量” 前提条件 输入 /
8、 动作 输出 / 响应 是否能正常运行 例如 10 个用户并发操作 例如 20 个用户并发操作 极限名称 B 前提条件 输入 / 动作 输出 / 响应 是否能正常运行 =可靠性测试用例=任务 A 描述 连续运行时间 故障发生的时刻 故障描述 统计分析 任务 A 无故障运行的平均时间间隔 （ CPU 小时） 任务 A 无故障运行的最小时间间隔 （ CPU 小时） 任务 A 无故障运行的最大时间间隔 （ CPU 小时） 任务 B 描述 连续运行时间 故障发生的时刻 故障描述 统计分析 任务 B 无故障运行的平均时间间隔 （ CPU 小时） 任务 B 无故障运行的最小时间间隔 （ CPU 小时） 任
9、务 B 无故障运行的最大时间间隔 （ CPU 小时） = 安装 / 反安装测试用例=配置说明 安装选项 描述是否正常 使用难易程度 全部 部分 升级 其它 反安装选项 描述是否正常 使用难易程度 测试的基本原则在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组测试原则： 1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。 2 、应该在测试工作真正开始前的较长时间就进行测试计划。测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所有测试应该
10、在任何代码被产生前就进行计划和设计。 3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 很可能起源于程序模块中的 20 。当然，问题在于如何孤立这些有疑点的模块并进行彻底的测试。 4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在整个系统中寻找错误。 5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的
11、。 6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现. 测试的基本原则1应当把“尽早和不断的测试”作为开发者的座右铭2程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。 3设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。 4一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。 5对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。 6制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间完成一个高水平的测试。 7回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。
