测试用例编写规范

上传人:g**** 文档编号:43780564 上传时间:2018-06-07 格式:DOCX 页数:4 大小:76.14KB
返回 下载 相关 举报
测试用例编写规范_第1页
第1页 / 共4页
测试用例编写规范_第2页
第2页 / 共4页
测试用例编写规范_第3页
第3页 / 共4页
测试用例编写规范_第4页
第4页 / 共4页
亲,该文档总共4页,全部预览完了,如果喜欢就下载吧!
资源描述

《测试用例编写规范》由会员分享,可在线阅读,更多相关《测试用例编写规范(4页珍藏版)》请在金锄头文库上搜索。

1、测试用例编写规范1测试用例编写规范测试用例编写规范本规范主为测试人员的测试用例指导,明确用例编写粒度,提高测试用例的一致性、可执行性及可读性。提高测试用例覆盖度,降低漏测率。编写测试用例前请阅读测试用例编写规范,用例的编写必需符合本规范。用例编用例编号与命名号与命名规范规范1. 测试用例包含内容为:用例编号、测试需求名称、功能点、需求描述、重要程度、操作步骤、预期结果。2. 用例编号规则:用例所属模块的全名称简拼+4 位流水号,流水号后两位以 10 为递增,以预留后期用例修改时的扩展用例编号,一个功能点对应一个用例编号。如员工管理下的 A 功能点和 B 功能点:添加员工_用户名,列表。3.测试

2、需求名称模块名称_页面名称,如:系统管理_员工管理。4. 功能点名称为功能点_特征项,如添加员工下页面里的用户名选择功能点:添加员工_用户名。样例:测试用例编写规范2用例文档内容用例文档内容测试用例编号:。测试需求名称:必填,需遵循用例命名规范。测试需求描述:非必填,对页面的业务需求及规约进行简述。严重等级:必填,用例的严重等级为用例执行的优先级,在编写用例时根据测试用例等级定义对功能点填写严重等级,用例评审时对严重等级进行确认,在首轮测试及测试进度许可情况下,所有等级的用例必需执行,在非首轮测试且测试进度紧张的情况下,高优先级的用例必需全部执行。前提条件:进行该功能测试需设置的前提条件(如系

3、统权限配置或前、后台配置,登陆情况描述)。测试步骤:测试的操作步骤,场景用例必需填写,功能用例该步骤可省略。描述:测试用例的输入条件,在编写用例时,一个单元格编写一个输入条件。预期结果:对应每一个输入条件,描述系统功能应达到的输出结果,在多个输入条件为相同的预期结果时,合并预期结果单元格。执行人:在执行该用例后,填写执行该用例的测试工程师。执行结果:根据用例进行测试后,根据用例的执行结果,或用例通过则选择pass,不通过选择 Failed,因其他原因未能执行的用例,选择 no run。测试用例编写规范3测试用例等级定义测试用例等级定义用例重要程度分为高、中、低三类,划分遵循以下原则: 高:该等

4、级的用例与系统的主要任务、基本功能以及待开发的功能有关。如果这些关键用例和类缺失,系统将无法完成主要任务。中:该等级的用例与系统功能的支持有关,比如统计数据编译、报告生成、监督和功能测试等。如果它们缺失,系统仍然可以(在一段时间内)完成基本任务,但服务质量有所下降。低:这些用例着重“舒适性”,“体验性”方面的功能,与系统主要任务无关,但有助于系统的使用。用例编写规则用例编写规则用例编写遵循如下规则:1.先按产品规格说明书或者需求原型进行模块划分,再对功能进行单项覆盖,之后再结合应用场景进行组合设计;2.需涵盖了产品规格说明书上的每个功能点,单个用例步骤或检查点中不再存在分支3.需涵盖了产品规格

5、说明书上的每条业务规则说明4.需涵盖了输入条件中各种有意义的组合5.需覆盖了业务操作的基本操作和异常操作6.需推敲重要表单字段的数据合法性检查7.需推敲了其他的测试类型(对某个功能很重要,但未在产品规格说明书中提及的,如安全测试、性能指标测试和故障恢复等方面)8.需推敲了对其他模块对该功能的影响9.操作说明字段是否准确地描述了对应场景的测试输入的特征(不同数据,操作,配置等)10. 用例需涵盖了测试设计中定义的所有场景11. 操作步骤的描述,需清晰、易懂,并具有可操作性12. 需使用部门统一的测试用例模板13. 文字、语法需准确,计划、样式需统一测试用例编写规范414. 用例编号需统一、规范1

6、5. 用例名称需简洁、明了16. 描述与预期结一一对应,每一个描述对应一个预期结果,如果多个输入对应同一个预期结果时,多个输入分单元格编写,预期结果可整合并到同一个单元格。用例走查与评审原则用例走查与评审原则1.单个模块或子系统的测试用例编写完成后:先自检,从功能覆盖、场景衍生、条件组合等多角度进行补充,在通过自己审查之后再提交给测试组其他人员进行交叉检查;2.测试组内部进行交叉检查时,要记录各自所发现的文档异常,提交给撰写人进行确认与修正。3.测试组内部通过走查之后方可提交项目组同行评审,同行评审规则为:A.至少提前一天发出评审邀请与待评审的用例文档; B.明确同行评审参与人员为:产品,开发人员,项目经理,测试组成员;C.测试用例撰写人先讲解设计架构与思路,稍候逐一回答文档异常中的问题,明确是否修改,回答会议人员所提出来的各种问题;D.评审会议结束之后,撰写人要根据会议决议对测试用例进行修改,根据评审结果决定是否需要再次评审;E.评审过程中发现有重大功能遗漏且遗漏数量较多,则评审不通过,需待用例文档更新后重新进行评审。4.测试执行过程中,测试用例需要进行日常维护工作,并定时把更新内容上传,以便项目测试团队共享。

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 其它办公文档

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号