测试用例编写规范.docx

测试用例编写规范

PAGE2

测试用例编写规范

本规范主为测试人员的测试用例指导，明确用例编写粒度，提高测试用例的一致性、可执行性及可读性。提高测试用例覆盖度，降低漏测率。

编写测试用例前请阅读《测试用例编写规范》，用例的编写必需符合本规范。

用例编号与命名规范

测试用例包含内容为：用例编号、测试需求名称、功能点、需求描述、重要程度、操作步骤、预期结果。

用例编号规则：用例所属模块的全名称简拼+4位流水号，流水号后两位以10为递增，以预留后期用例修改时的扩展用例编号，一个功能点对应一个用例编号。如员工管理下的A功能点和B功能点：添加员工_用户名，列表。

测试需求名称模块名称_页面名称，如:系统管理_员工管理。

功能点名称为功能点_特征项，如添加员工下页面里的用户名选择功能点：添加员工_用户名。

样例：

用例文档内容

测试用例编号：。

测试需求名称：必填，需遵循用例命名规范。

测试需求描述：非必填，对页面的业务需求及规约进行简述。

严重等级：必填，用例的严重等级为用例执行的优先级，在编写用例时根据测试用例等级定义对功能点填写严重等级，用例评审时对严重等级进行确认，在首轮测试及测试进度许可情况下，所有等级的用例必需执行，在非首轮测试且测试进度紧张的情况下，高优先级的用例必需全部执行。

前提条件：进行该功能测试需设置的前提条件（如系统权限配置或前、后台配置，登陆情况描述）。

测试步骤：测试的操作步骤，场景用例必需填写，功能用例该步骤可省略。

描述：测试用例的输入条件，在编写用例时，一个单元格编写一个输入条件。

预期结果：对应每一个输入条件，描述系统功能应达到的输出结果，在多个输入条件为相同的预期结果时，合并预期结果单元格。

执行人：在执行该用例后，填写执行该用例的测试工程师。

执行结果：根据用例进行测试后，根据用例的执行结果，或用例通过则选择pass，不通过选择Failed，因其他原因未能执行的用例，选择norun。

测试用例等级定义

用例重要程度分为高、中、低三类，划分遵循以下原则：

高：该等级的用例与系统的主要任务、基本功能以及待开发的功能有关。如果这些关键用例和类缺失，系统将无法完成主要任务。

中：该等级的用例与系统功能的支持有关，比如统计数据编译、报告生成、监督和功能测试等。如果它们缺失，系统仍然可以（在一段时间内）完成基本任务，但服务质量有所下降。

低：这些用例着重“舒适性”,“体验性”方面的功能，与系统主要任务无关，但有助于系统的使用。

用例编写规则

用例编写遵循如下规则：

先按产品规格说明书或者需求原型进行模块划分，再对功能进行单项覆盖，之后再结合应用场景进行组合设计；

需涵盖了产品规格说明书上的每个功能点，单个用例步骤或检查点中不再存在分支

需涵盖了产品规格说明书上的每条业务规则说明

需涵盖了输入条件中各种有意义的组合

需覆盖了业务操作的基本操作和异常操作

需推敲重要表单字段的数据合法性检查

需推敲了其他的测试类型(对某个功能很重要，但未在产品规格说明书中提及的，如安全测试、性能指标测试和故障恢复等方面)

需推敲了对其他模块对该功能的影响

操作说明字段是否准确地描述了对应场景的测试输入的特征(不同数据，操作，配置等)

用例需涵盖了测试设计中定义的所有场景

操作步骤的描述，需清晰、易懂，并具有可操作性

需使用部门统一的测试用例模板

文字、语法需准确，计划、样式需统一

用例编号需统一、规范

用例名称需简洁、明了

描述与预期结一一对应，每一个描述对应一个预期结果，如果多个输入对应同一个预期结果时，多个输入分单元格编写，预期结果可整合并到同一个单元格。

用例走查与评审原则

单个模块或子系统的测试用例编写完成后：先自检，从功能覆盖、场景衍生、条件组合等多角度进行补充，在通过自己审查之后再提交给测试组其他人员进行交叉检查；

测试组内部进行交叉检查时，要记录各自所发现的文档异常，提交给撰写人进行确认与修正。

测试组内部通过走查之后方可提交项目组同行评审，同行评审规则为：

至少提前一天发出评审邀请与待评审的用例文档；

明确同行评审参与人员为：产品，开发人员，项目经理，测试组成员；

测试用例撰写人先讲解设计架构与思路，稍候逐一回答文档异常中的问题，明确是否修改，回答会议人员所提出来的各种问题；

评审会议结束之后，撰写人要根据会议决议对测试用例进行修改，根据评审结果决定是否需要再次评审；

评审过程中发现有重大功能遗漏且遗漏数量较多，则评审不通过，需待用例文档更新后重新进行评审。

测试执行过程中，测试用例需要进行日常维护工作，并定时把更新内容上传，以便项目测试团队共享。