测试用例模板

一、定义

测试用例（ Test Case ）是指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

二、测试用例的分类

根据测试过程中具体涉及到问题类型及测试需求，可将测试用例分为如下：

• 功能性测试用例

• 界面测试用例：适用于所有测试阶段中的界面测试

• 数据处理测试用例：适用于所有测试阶段中的数据处理测试

• 操作流程测试用例：适用于所有流程性的测试

• 安装测试用例：适用于所有安装测试

三、测试用例管理

• 编写用例：测试工程师根据需求规约、概要设计、详细设计等文档编写测试用例。

• 用例评审：原则上用例象程序一样，要经过多次的修改才可以通过，实际工作中通常进行一次。

• 用例修改：评审结束后，您需要根据评审意见进行修改，修改后通常不再进行评审。

• 使用用例：执行测试用例，并记录到测试用例执行报告中。

• 用例升级 / 维护：随着软件产品不断修改、升级，对应的用例也需要升级维护。针对同一个项目，可以根据需求的变更不断进行维护；如果是产品，用例的维护更加重要，要达到用例和产品的版本一一对应。

四、测试用例的编制及使用

1 、设计测试用例

每个具体测试用例都将包括下列详细信息：编制人、审定人、编制日期、版本、用例类型、设计说明书编号、用例编号、用例名称、输入说明、期望结果（含判断标准）、环境要求、备注等。

测试用例

• “测试用例名称”可以是不涉及到具体模块的功能描述，如“日期格式”，“非空检验”等。

• “输入说明”是功能模块接受的数据或各种操作描述，如“输入非法的日期格式”等。

• “期望结果”是模块接受输入后应有的正常输出描述，如“提示用户修改”等，期望结果应与输入说明一一对应。

• 测试用例用于指导执行操作，但某些意外操作也可导致程序错误，这些操作称为非预期性操作，可以先有执行报告，再后补用例。

• 测试用例的设计应考虑通用性和简洁明了。

2 、执行测试用例

• 此报告用于记录执行上一步设计的测试用例的过程及结果。

• “步骤”应填入详细的操作，如“点增加 -> 输入日期 -> 保存”。“输入数据”填入具体数据，如“ 2002/12/12 ”。

• “期望输出”即测试用例中的“期望结果”，但描述应更具体，如“弹出提示对话框，提示用户日期格式错误”。

• “实际输出”是操作的真实结果，必须详细、清晰，便于开发人员理解。

• 如“实际输出”与“期望输出软件测试流程”不符，则结果为 F （ False ），若相符则结果为 T(True) 。

3 、用例模板

软件功能性测试用例模板
一、功能检查
1 、功能是否齐全，例如：增加、删除、修改	2 、功能是否多余
3 、功能是否可以合并	4 、功能是否可以再细分
5 、软件流程与实际业务流程是否一致	6 、软件流程能否顺利完成
7 、各个操作之间的逻辑关系是否清晰	8 、各个流程数据传递是否正确
9 、模块功能是否与需求分析及概要设计相符
二、面向用户的考虑
1 、操作方便性，如：按键次数是否最少	2 、易用性，面对用户的操作是否简单易学
3 、智能化考虑	4 、提示信息是否模糊不清或有误导作用
5 、要求用户进行的操作是否多余，能否由系统替代	6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置
7 、是否不经确认就对系统或数据进行重大修改	8 、能否及时反映或显示用户操作结果
9 、操作是否符合用户习惯，比如：热键	10 、各种选项的可用及禁用是否及时合理
11 、某些相似的操作能否做成通用模块

软件安装测试用例模板
项目名称：	项目版本号：
软件的安装 / 卸载流程能否正确顺利地进行软件的安装 / 卸载是否简单、易学、易用安装过程中的文字及提示有否错字、别字，提示信息是否完备安装过程中的各选项是否有效，合理安装完成后生成的快捷图标及菜单是否正确，路径是否有效安装文件夹的个数及所包含的内容是否正确无误码 INI 文件及配置文件是否正确生成的系统备份文件是否正确动态库及主程序的个数、内容是否正确运行程序，软件各项功能是否能正常运行，如果有修改，安装后的内容是否最新系统固定数据、数据库是否正确

附注：用例编码规则

功能 — 以字母 U 开头后跟数字编码

界面 — 以字母 I 开头后跟数字编码

数据 — 以字母 D 开头后跟数字编码

流程 — 以字母 F 开头后跟数字编码

安装 — 以字母 S 开头后跟数字编码