测试用例编写规范文档格式.docx

测试用例编写规范文档格式.docx

《测试用例编写规范文档格式.docx》由会员分享，可在线阅读，更多相关《测试用例编写规范文档格式.docx（17页珍藏版）》请在冰点文库上搜索。

系统测试：

是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的“先知者问题”。

测试分析：

对重要业务、重要流程进行测试前的分析。

业务流程测试用例：

关于产品业务、重要流程的测试用例。

2.测试用例编写原则

2.1系统性

　　1、对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；

　　2、对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系；

2.2连贯性

　　1、对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；

如果是依靠页面链接，页面链接是否正确；

　　2、对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

2.3全面性

　　1、应尽可能覆盖程序的各种路径

　　2、应尽可能覆盖系统的各个业务

　　3、应考虑存在跨年、跨月的数据

4、大量数据并发测试的准备

5、系统中各功能、业务的异常情况

2.4正确性

1、输入用户实际数据以验证系统是否满足需求规格说明书的需求。

　　2、测试用例中的测试点应保证至少覆盖需求规格说明书中的各项功能。

2.5符合正常业务惯例

　　1、测试数据应符合用户实际工作业务流程

　　2、兼顾各种业务变化的可能

　　3、要符合当前业务行业法律，法规。

2.6仿真性

　　人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。

2.7容错性（健壮性）

程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。

3.测试用例设计方法

1.等价类划分法：

将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

2.边界值分析法：

指对输入的边界条件进行分析，设计出针对边界值的测试用例。

3.因果图法：

　　就是利用图解法分析软件输入（原因）和输出条件（结果）之间的关系，以设计测试用例的方法。

因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。

4.功能图法

　　功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。

测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

5.错误推测法

推测法主要依赖经验、直觉来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，在找到缺陷后，设计出相应的测试用例。

6.正交实验设计方法

　　主要步骤是：

（1）对软件需求规格说明中的功能要求进行划分（层层分解与展开），分解成具体的、相对独立的基本功能。

（2）根据基本功能的质量需求，找出影响其功能实现的操作对象和外部因素，每个因素的取值可以看作水平，多个取值就存在多个水平。

　　（3）确定待测试软件中所有因素及其权值，这是测试用例设计的关键，确保全面、准确。

　　权值是依据各因素的影响范围、发生的频率和质量的需求来确定的。

　　（4）加权筛选，生成因素分析表。

　　（5）利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。

考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。

利用正交实验设计方法设计测试用例，可控制生成的测试用例数量，覆盖率高且测试效率高。

7.接口间测试

测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

8.数据库测试

依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

9.可理解（操作）性

理解和使用该系统的难易程度（界面友好性）。

10.可移植性

在不同操作系统及硬件配置情况下的运行性。

4.测试用例编写规范

4.1测试用例命名规则

以功能模块和业务流程进行命名。

4.2测试用例编号规则

功能编号规则：

以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长时，可进行简写。

如：

✧测试模块为“用户管理”，功能编号为“YHGL”；

✧测试模块为“增值税一般人申报业务”，功能编号为“YBRSB”

用例编号规则：

功能编号+测试子项（功能点）+编号

✧功能编号：

同上；

✧测试子项：

为本测试项的测试点，如“用户管理”的测试点“添加用户”，测试子项为“TJYH”（如果测试子项比较长时，可以进行简写）；

✧编号：

从001开始进行顺延，如001、002……

4.3测试用例书写规则

1、被测试对象的介绍

2、测试范围与目的

3、测试环境与测试辅助工具的描述

4、功能测试用例主要元素

测试要点

用例编号

用例名称

功能（业务）描述、

规则、逻辑

编号

测试要点详细

预期结果

测试结果

编写人

审核方式及审核人

备注：

✧用例编号：

✧用例名称：

指明要测试的内容，如被测模块名称、业务流程名称等。

✧功能（业务）描述、规则、逻辑：

对要进行测试的功能或业务进行简要的描述。

根据需求规格说明书、实际业务情况或其它相关文档列出本用例的规则、逻辑关系或需求点。

✧测试要点：

对某一功能的功能点或业务点进行细化，形成本功能点的测试要点。

✧预期结果：

描述输入数据后程序应该输出的结果。

✧测试结果：

描述本条用例的实际测试情况，并判断实际测试结果与预期结果是否一致。

✧备注：

记录测试过程中提交的bug编号或测试过程中遇到的问题。

✧编写人：

编写本用例的设计人员。

✧审核方式及审核人：

注明本用例由谁进行审核及审核人姓名。

详细用例编写表

功能（业务）描述、规则、逻辑

操作描述（输入/动作）

预期结果（输出）

对应有测试要点一:

…………………………………………..

前提条件\数据准备：

………………………

对应有测试要点二:

✧操作描述（输入\动作）：

描述本条测试用例的输入步骤，首先简要描述本条测试用例的测试点，再对本测试点进行详细步骤描述或输入数据设置（需要详细进行描写）。

✧预期结果（输出）：

✧前提条件\数据准备：

执行测试用例前需先要执行的操作或配置。

5、功能测试用例编写规则

编写测试用例时对测试模块的功能点划分，先对本功能点的特性、配置或需求进行简要描述后再对该功能点进行用例的编写，如：

测试用户管理，首先将用户管理划分为几个功能点，添加用户信息、修改用户信息、删除用户信息和查询用户信息。

在添加用户信息时，根据需求或实际业务情况获到用户属性信息，如：

用户ID为4位，只能为数字；

用户密码为6位字符…

YHGL

用户管理

对用户进行添加、修改、删除及修改操作

1、添加用户

2、修改用户

…….

添加用户信息：

YHGL-TJYH-001

正常添加用户信息

可以添加成功、数据库中数据正确

YHGL-TJYH-002

添加的用户ID为非数字格式，查看是否进行校验

只允许输入数字

YHGL-TJYH-003

…

修改用户信息

修改用户信息后查看数据库中的数据是否正确

数据库中信息正确

XXX

测试大纲评审\XXX

1、点击[XXX]菜单下的[]。

。

2、在弹出的“XXX”界面输入用户ID“XXXXX”

…….

1、可以添加成功。

2、数据库中可以查询到添加的信息。

添加的用户ID为非数字格式

1、….

2、…

YHGL-XGYH-001

YHGL-XGYH-002

测试用例评审\XXX

4.4测试用例编写流程

1、根据需求文档先编写测试大纲或测试要点。

2、根据测试大纲编写测试用例，细化用例详细操作步骤。

3、在本轮测试完毕后，测试人员提交测试用例更新表，对测试大纲和测试用例进行更新。

5.测试用例模板

5.1功能测试要点

5.2功能测试用例

5.3健壮性测试用例

异常输入/动作

容错能力/恢复能力

造成的危害、损失

示例：

错误的数据类型…

定义域外的值…

错误的操作顺序…

异常中断通信…

异常关闭某个功能…

负荷超出了极限…

5.4性能测试用例

性能描述

用例目的

前提条件

输入数据

期望的性能（平均值）

实际性能（平均值）

01

5.5图形用户界面测试用例

类别

特征

A类

B类

……

5.6用户界面测试的检查表

检查项

测试人员的类别及其评价

窗口切换、移动、改变大小时正常吗？

各种界面元素的文字正确吗？

（如标题、提示等）

各种界面元素的状态正确吗？

（如有效、无效、选中等状态）

各种界面元素支持键盘操作吗？

各种界面元素支持鼠标操作吗？

对话框中的缺省焦点正确吗？

数据项能正确回显吗？

对于常用的功能，用户能否不必阅读手册就能使用？

执行有风险的操作时，有“确认”、“放弃”等提示吗？

操作顺序合理吗？

有联机帮助吗？

各种界面元素的布局合理吗？

美观吗？

各种界面元素的颜色协调吗？

各种界面元素的形状美观吗？

字体美观吗？

图标直观吗？

5.7信息安全性测试用例

假想目标A

非法入侵手段

是否实现目标

代价－利益分析

假想目标B