字节大佬整理测试用例编写规范

目录

1.1目的

1.2使用范围

二 测试用例编写原则

2.1系统性

2.2连贯性

2.3全面性

2.4正确性

2.5符合正常业务惯例

2.6仿真性

2.7容错性（健壮性）

三 测试用例设计方法

3.1 等价类划分法：

3.2 边界值分析法：

3.3 因果图法：

3.4功能图法

3.5错误推测法

3.6 正交实验设计方法

3.7接口间测试

3.8数据库测试

3.9可理解（操作）性

3.10可移植性

四 测试用例编写规范

4.1测试用例命名规则

4.2测试用例编号规则

4.3测试用例文档书写内容

五 编写用例注意事项

5.1功能检查

5.2 面向用户的考虑

5.3数据处理

5.3.1输入数据

5.3.2数据处理

5.3.3输出结果

5.4软件流程测试

五 历史版本

5.1 版本记载

---

1.1目的

统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性。为测试执行人员更好执行测试，提高测试效率，最终提高公司整个产品的质量。

1.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 等价类划分法：

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

3.2 边界值分析法：

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

3.3 因果图法：

　　就是利用图解法分析软件输入(原因)和输出条件(结果)之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。

3.4功能图法

　　功能图是描述程序状态变化、转移的过程，因为软件运行或操作的过程可以看作是其状态不断发生变化的过程。测试用例的设计就是如何覆盖所有软件表现出来的状态，即在满足输入/输出的一组条件下，软件运行是一系列有次序的、受控制的状态变化过程。

3.5错误推测法

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

3.6 正交实验设计方法

　　主要步骤是：

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

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

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

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

(4) 加权筛选，生成因素分析表。

(5) 利用正交表构造测试数据集，正交表的每一行，就是一条测试用例。考虑交互作用不可忽略的处理因素和不可混杂的原则，有交互作用的组合优先安排。

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

3.7接口间测试

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

3.8数据库测试

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

3.9可理解（操作）性

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

3.10可移植性

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

四 测试用例编写规范

4.1测试用例命名规则

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

4.2测试用例编号规则

用例编号规则：以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长时，可进行简写。一般简拼不超过5个字母：如：

• 测试模块为“用户管理”，功能编号为“YHGL”；
• 测试模块为“行政单位管理”，功能编号为“DWGL”
• 功能编号规则直接以001、002、003…..

4.3测试用例文档书写内容

1、被测试对象的介绍

2、测试范围与目的

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

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

• 前置/操作描述：

1、前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的前提条件）。                                

2、操作：测试的操作步骤描述。     

• 功能点： 功能点描述。
• 输入数据：前期数据准备。
• 预期结果：描述输入数据后程序应该输出的结果。
• 测试结果：描述本条用例的实际测试情况，并判断实际测试结果与预期结果的差别。
• Bug编号/Bug简要描述:需要进流程的对应事物流程的编号，及简要说明
• 备注：测试过程中遇到的问题等情况说明。

五 编写用例注意事项

5.1功能检查

1 、功能是否齐全，例如：增加、删除、修改，查询条件是否合理，用户使用是否方便

2 、功能是否多余

3 、功能是否可以合并

4 、功能是否可以再细分

5 、软件流程与实际业务流程是否一致

6 、软件流程能否顺利完成

7 、各个操作之间的逻辑关系是否清晰

8 、各个流程数据传递是否正确

9 、模块功能是否与需求分析及概要设计相符

10、批量增加、批量修改，增加、修改等录入比较频繁的界面或录入数据量较多的界面，是否支持全键盘或全鼠标操作，并且使用通用的键实现数据字段的有序切换

5.2 面向用户的考虑

1 、操作方便性，如：按键次数是否最少，并不以开发实现技术限制为限制，而是以用户使用方便性和应用软件约定和通常的快捷键来实现提出合理建议

2 、易用性，面对用户的操作是否简单易学

3 、智能化考虑

4 、提示信息是否模糊不清或有误导作用。错误信息是否有用户语言风格的出错后续处理建议提示

5 、要求用户进行的操作是否多余，能否由系统替代。系统升级后，用户能否不做任何操作自动进行所有升级的数据、环境等准备工作，包括删除缓存等动作

6 、能否记忆操作的初始环境，无需用户每次都进行初始化设置

7 、是否不经确认就对系统或数据进行重大修改

8 、能否及时反映或显示用户操作结果

9 、操作是否符合用户习惯，比如：热键

10 、各种选项的可用及禁用是否及时合理

11 、某些相似的操作能否做成通用模块

5.3数据处理

5.3.1输入数据

1 、边界值

2 、大于边界值

3 、小于边界值

4 、最大个数

5 、最大个数加 1

6 、最小个数

7 、最小个数减 1

8 、空值、空表

9 、极限值

10 、 0 值

11 、负数

12 、非法字符

13 、日期、时间控制

14 、跨年度数据

15 、数据格式

 16 、数据之间的关联性、逻辑性，数据范围、格式限制是否合乎日常情理，如年龄不应为负数，身份证位数必须为15或18位且与性别严格相关联，与生日可以有区别（考虑到阴历阳历的问题）但不相同时给予提示，私人电话号码的长度且国内电话只能有数字及短横线标识区号等

5.3.2数据处理

1 、处理速度

2 、处理能力

3 、数据处理正确率

4 、计算方式及计算结果准确性，数字精度的取舍问题，汇总数据与分项数据累加的误差问题

5.3.3输出结果

1 、正确率

2 、输出格式

3 、预期结果

4 、实际结果，金额数字的可能要验证小写大写的一致性，大写可能要测试多种金额的大写，包括没有整数的情况下，没有小数的情况下，带整数和小数的情况下……

5.4软件流程测试

1 、反流程操作

2 、反逻辑操作

3 、重复操作

4 、反业务流程操作

 5 、违反流程的打乱流程的不按操作手册的乱操作

五 历史版本

5.1 版本记载

版本每次改动，需要填写版本号，修改人、相关说明等信息。

版本号：以当前项目类型+年份+月+日期来命名

版本	状态	作者	参与者	日期	备注
Ncms20110720