测试用例编写规范_V10

1、软件功能测试用例编写规范v1-0修改历史日期版本作者修改内容更改请求号2016-1-6v1.0何曙林初稿目 录1 从需求到用例11需求分析11.2 业务分析11.3 用例设计12 常用的较验22字段长度较验22.2 字符类型较验22.3 其它较验23 常用功能的设计53新增/添加53.2 修改/更新53.3 删除63.4 查询/搜索63.5 上传文件64 测试用例模板64.1 测试用例文档命名规则64.2 测试用例模板内容定义71从需求到用例1.1需求分析测试需求分析是进行测试用例编写的前提。测试人员根据软件功能需求、软件需求规格说明进行测试需求分析，找出明显的和隐含 的需求。有些需求无法从需

2、求文档中获得，可借助概要设计文档或者详细设计文档，或直接 从最终的软件产品上获得。最终依据这些信息整理并编写出测试需求。测试用例设计是将测试需求细化的过程。1.2业务分析测试人员根据需求分析以及对业务的了解，整理编写出业务分析并绘制业务流程。 业务分析时使用业务分析模板。1.3用例设计测试用例设计是将测试需求和业务分析细化的过程。测试川例编耳规范2常用的较验2.1字段长度较验2.1.1字段长度取上边界值2.1.2字段长度取上边界值+12.1.3字段长度収上边界值12.1.4字段长度取下边界值2.1.5字段氏度取下边界值+12.1.6字段长度取下边界值12.2字符类型较验2.2.1在应该输入指定

3、类型的内容地地方输入其他类型的内容，看系统是否检杳字符类型,会否报错。2.2.2数值型字段取上边界俏2.2.3数值型字段取卜边界值2.2.4数值型字段山只上边界值减12.2.5数值型字段取上边界值加12.2.6数值型字段取下边界值加12.2.7数值型字段収下边界俏减12.2.8在数值型字段输入域中输入全角数字2.2.9在数值型字段输入域中输入半角数字2.2.10在数值型字段输入域屮输入全角字母2.2.11在数值型字段输入域小输入半角字母2212在数值型字段输入域中输入全角特殊符号2.2.13在数值型字段输入域中输入半角特殊符号2214字符型字段中禁用或限用符号的检查2.2.15日期型字段输入格

4、式的检查2.3其它较验2.3.1页面链接检查：每一个链接是否都有对应的页而，并且页而z间切换正确。 厦门至恒天地信息技术冇公司2.3.2 按钮功能是否正确：如新增、修改、删除、保存等功能是否正确。2.3.3 标点符号检查：输入内容包括各种标点符号，特别是空格、各种引号、回车键。看 系统处理是否正确。2.3.4 小文字符处理：在可以输入中文的系统输入小文，看会否出现乱码或出错。2.3.5 多次使用“后退”键：在有“后退”的地方，后退，回到原來页而，重复多次后退, 看是否出错。2.3.6 输入信息位置：在光标停留的地方输入信息时，光标和所输入的信息是否会跳到其 他地方。2.3.7 快捷键检查：是否

5、支持常用快捷键，如ctrl+cctrl+v等，对一些不允许输入信息的 字段，如从下拉列表中选择、选h期对快捷方式是否也做了限制。2.3.8 四不键检查：在输入结束后直接按回车键，看系统处理如何。2.4权限校验2.4.1 权限菜单校验：什么角色能展示什么样的菜单2.4.2 权限功能校验：什么样的角色可操作什么样的功能，例子1： a角色可新增，b角色只可查看不能新增，c只能删除例了 2： a角色可取款10w （含）以下金额，取款10w以上需要b角色授权，取款100w以上需要c角色授权，取款1000w以上系统将提示'此金额需要提前x天预约'2.5必输项校验2.5.1校验不能为空：必须

6、输入，不输入系统将给出合理友好的提示还需耍校验字段名是否正确，必输项和非必输项正确实现备注：如一个页面冇儿十个以上的必输项，也必须分开写对应的单独的用例。测试人员经常因为麻烦用一条用例覆盖所有的必输项，这样做会存在较大的风险。2.6输入规则校验2.6.1 校验输入规则是否正确：验证需求描述的输入规则可正确实现例如：效验证件号码字段只可输入阿拉们数字，姓名字段是可输入中文，金额字段只可输入正整数2.7业务逻辑效验2.7.1 业务逻辑约束：效验业务逻辑是否正确约束例如：活期存款计息方式为积数计息法定期存款为余额法，贷款不同的还款方式2.8业务流程验证2.8.1 业务短流程验证：需求中没有写的，需耍

7、口己挖掘隐性流程，例如网银，1.注册签 约转账查询退出2. 新增查询修改查询删除查询3. t日存款t+1()日取款每日计提结息当日冲销计提每月21日结息t+6()日取款-t+90日销户2.8.2 业务长流程验证：需求屮有流程图，有详细描述的，需要设计最少的案例去覆盖全 量的场景2.9界面要素检查2.9.1 界面要素检杳：页面跳转正确，各项显示正确，无错别字，只读项不可编辑例如：测试步骤：'查询收款人名册'界面要素检查预期结果：1 查询条件：收款账号输入框、收款方户名-文本框2. 杳询结果单选帕选择后关闭此页面、收款方账号文本、收款方户名文本、收款方开户行文本、转账类型文本3.

8、按钮：【关闭】、【査询】功能实现布局合理、各项显示正确、无错别字3常用功能的设计新增/添加3字段长度较验（详细内容参见“2.1字段长度较验”）3.1.2 字段类型较验（详细内容参见“2.2字符类型较验”）3.1.3 必输项较验3.1.4 冋填按钮所带冋的信息是否完整、正确3.1.5 新增页面内字段间存在的逻辑关系较验，如到期口期=开始口期+期限3.1.6 其他模块或业务屮的设置对该页而字段的影响3.1.7 对于新增主键值重复的记录，系统是否有较验3.1.8 重名较验：需要命名且名字应该唯一的信息输入重复内容，看系统是否有处理，重 名包括是否区分大小写，以及在输入内容前后加入空格，系统是否作出疋

9、确处理。3.1.9 重复捉交表单：一条已经成功提交的记录，“后退”后再捉交，看系统是否作了处理。3.1.10输入信息位置：注意在光标停留的地方输入信息时，光标和所输入的信息会否跳到 别的地方。3.1.11回车键检查：在输入结束后直接按回车键，看系统如何处理。3.1.12対新增记录的查看及内容是否匸确的较验。3.1.13相关性检查：增加-项内容会不会对其他项产牛:影响，如果有影响，这些影响是否 都正确。3.2修改/更新321 修改约束：对于修改操作有前置条件或状态约束的，检查系统是否都正确处理，是 否报错。3.2.2 带出信息的完整性：修改时先查看所填写的信息是否全部带出，带出信息和填定的 是否

10、一致。323 修改和新增/添加较验是否一致：检查添加和修改信息的要求是否一致，如新增要求 是必输项，修改也应该必输；新增规定为整型，修改也必须为整型。3.2.4 检查修改重名：修改时把不能重名的项改为已存在的内容，看系统是否作了正确处 理。3.3删除3.3.1删除约束：对于删除操作有前置条件或状态约束的，检杳系统是否都正确处理，是 否报错。3.3.2多个删除：在一些可以一次删除多个信息的地方，不选择任何信息，按“删除”，看 系统如何处理，会否出错；然后选样一个和多个信息，进行删除，看是否正确处理。3.4查询/搜索341默认条件查询，看结果是否正确3.4.2“空”条件查询，看结果是否止确3.4.

11、3单一条件查询，看结果是否正确3.4.4两个条件的组合查询，看结果是否正确3.4.5两个以上条件的组合杏询，看结果是否正确3.4.6模糊查询，看结果是否止确3.4.7查询系统存在和不存在的内容，看结果是否止确，看提示是否合理3.4.8在杳询域屮输入法合理和不合理的条件，看系统是否正确处理。3.4.9查询结果排序：如果可以对查询结果小的某些字段排序，是否标识出了可排序的字 段，并检杏排序功能是否实现。3.5上传文件3.5.1上传文件类型的检杳3.5.2能同时上传的文件数量3.5.3一次能上传的文件最大字节数3.5.4相同文件的重复上传：看系统是否有处理。3.5.5重名但内容不同的文件：看系统是否

12、冇处理。4测试用例模板测试用例编写使用统一的测试用例模板。见测试用例模板.x1s （该模板基于ctp）。4.1测试用例文档命名规则v系统名称一模块一子模块测试用例一设计人_设计h期测试用例模板内容定义421主题目录> 填写测试用例所在的目录。> 每一用例都要包含根目录和各级子目录。> 根目录一般以项目名称定义，各级子目录一般以模块及各级子模块定义。> 各级冃录z间以“”隔开，没有空格，例如：个贷系统客户管理个人客户悖理。4.2.2 测试用例名称> 填写测试用例名称，且名称唯一、准确。>采用统一编号规则：用例功能点所在当前模块一功能名称一编号。其中用例功能点所 在当询模块名或子模块，尽量保证可与其它名称区分，如确实相同可在前而加一级 父模块，以下划线隔开；编号是3位数字，以子模块为单位从001开始依次累加计 数，如：个人客户管理一新增_00