测试用例管理规范

测试用例标准定义

用例级别

表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果,而是对应用例的基本程度。测试用例分为四级:

  • 基本:该类用例涉及系统基本功能及业务,用于版本提交时作为“版本通过准则”,即“冒烟测试”。该级别的测试用例在每一轮版本测试中都必须执行。如存在不通过的项目时可考虑重新提交版本,该级别用例的数量应受到限制,一般约为30%~40%

  • 重要:该类用例涉及一些功能交互相关、个种应用场景、使用频率较高的正常功能测试用例。在非回归的测试版本中基本上都需要进行验证,以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是够进行测试。一般约为30%~40%

  • 一般:该类用例仅影响某单项功能的某一细节方面。例如某业务的登记和使用正常,但和另一个新业务发生不应有的冲突。有关性能、极限等方面的测试可归入该级用例。有关用户界面的基本规范等方面的测试可归入该级用例。一般约为10%

  • 生僻:该类用例对应较生僻的预置条件和数据设置。有关用户界面的优化等方面的测试可归入4级用例,一般约为0%~5%。

测试用例编写规范

测试用例颗粒度

  • 验证一个功能点一条测试用例,没有重复、冗余的测试用例

  • 验证同一个功能点,一种逻辑一条测试用例

  • 验证逻辑性的测试用例,需要做数据库校验

测试用例思路

  • 按照功能模块划分,并且按照主流程用例的顺序编写,一个页面的用例编写顺序是从上往下,从左到右,方便执行,比如有一个功能包含:新增、编辑、查询、删除、导出,那么编写顺序为新增、编辑、查询、导出、删除。

功能测试用例字段定义

【功能模块】例如订单查询

【功能点】:在功能模块基础上列出功能点,比如查询、新增等等

【用例名称】:标题需简洁明了,描述以验证功能目的为主。好的用例标题是别人看完你这个用例标题后就知道你这个用例是测什么的。但并不是标题越详细越好。既然是标题,就要言简意赅,能多简洁就多简洁,但简洁的同时又要能体现你的测试目的。用例的标题最好不要超过15个字。一般可以遵循这样的公式:主体(可省略) + 动词 + 名词 + 结果(即谁做了什么有什么影响) + 逻辑条件。要注意:我们写的每一个用例对应的就是要测试的一个点。其实每个点都是用户的一种操作行为。如验证【查询】功能正常_根据名称

【测试描述】:如果在条件相同,并且没有特殊操作的情况下没有必要重复编写用例。

【测试步骤】:步骤中,如果是涉及到功能模块的描述,使用【】格式定义,如【订单管理】

【前置条件】:执行本用例前,被测试对象所需具备的预置数据,所处状态或入口条件等要求

【用例级别】:表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果,而是对应用例的基本程度。测试用例分为四级别:基本、重要、一般、生僻

【执行方式】:分为手工和自动化。自动化即是通过自动化测试工具实现

【业务发起端】:测试用例从哪个平台发起,可从下拉列表中选择。下拉列表内容可维护。

【预期结果】:

1、原则上每一个用例必须要有预期结果,结果不能为空 2、结果中只能包含结果,不能有步骤 3、一个结果有多个检查点时,确保检查点完整:     3.1)结果含须要验证的全部结果输出,如页面检查、存储检查、消息检查等     3.2)结果涉及页面,需明确页面提示结果、数据变化;     3.3)结果涉及存储:需明确关键值变化、数据库具体的表和关键字字段值变化     3.4)结果涉及消息:需明确关键查看内容     3.5)结果对应不一样输入数据有差异时需分别对应描述清晰

【实际结果】:记录用例最终测试执行结果,仅根据列表选择:通过、不通过。

接口测试用例字段定义

【功能模块】例如订单查询

【功能点】:在功能模块基础上列出功能点,比如查询、新增等等

【用例名称】:标题需简洁明了,描述以验证功能目的为主。好的用例标题是别人看完你这个用例标题后就知道你这个用例是测什么的。但并不是标题越详细越好。既然是标题,就要言简意赅,能多简洁就多简洁,但简洁的同时又要能体现你的测试目的。用例的标题最好不要超过15个字。一般可以遵循这样的公式:主体(可省略) + 动词 + 名词 + 结果(即谁做了什么有什么影响) + 逻辑条件。要注意:我们写的每一个用例对应的就是要测试的一个点。其实每个点都是用户的一种操作行为。如验证【查询】功能正常_根据名称

【测试描述】:如果在条件相同,并且没有特殊操作的情况下没有必要重复编写用例。

【接口URL】:接口URL地址,用相对路径。

【请求头】:接口请求头。

【请求参数】:接口请求参数。

【前置条件】:执行本用例前,被测试对象所需具备的预置数据,所处状态或入口条件等要求

【用例级别】:表明该用例的重要程度。用例的重要性并不对应用例可能造成的后果,而是对应用例的基本程度。测试用例分为四级别:基本、重要、一般、生僻

【执行方式】:分为手工和自动化。自动化即是通过自动化测试工具实现

【业务发起端】:测试用例从哪个平台发起,可从下拉列表中选择。下拉列表内容可维护。

【预期结果】:接口预期返回值。

【实际结果】:记录用例最终测试执行结果,仅根据列表选择:通过、不通过。

  • 20
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在软件测试中,为测试用例命名是一项重要的任务,它可以帮助团队成员更好地理解和识别每个测试用例的目的和内容。以下是一些常见的软件测试用例命名规范: 1. 清晰和具体:测试用例的名称应该清晰明确,能够准确描述被测试的功能或场景。避免使用模糊或含糊不清的术语,以免导致误解或混淆。 2. 使用关键词:在测试用例名称中使用关键词可以帮助快速理解其目的和内容。关键词可以是功能、模块、需求、特定的操作等。例如,如果测试登录功能,可以在用例名称中包含关键词"登录"。 3. 使用动宾结构:采用动宾结构可以使测试用例名称更加规范和易读。动词描述操作,宾语描述被操作的对象。例如,"点击提交按钮"、"验证错误提示信息"等。 4. 一致性:保持测试用例命名的一致性有助于组织和管理测试用例。使用相同的命名规范,使得团队成员能够更容易地寻找、理解和比较不同的测试用例。 5. 使用编号或序号:为测试用例添加编号或序号可以帮助标识和排序。使用数字编号或序号,可以根据需要对测试用例进行排序或跟踪。 6. 避免冗长和复杂:尽量避免过长或复杂的测试用例名称。简洁明了的名称更易于记忆和理解。如果需要更详细的描述,可以在用例的描述或注释中进行补充。 7. 注重可搜索性:考虑到测试用例的搜索和过滤,确保用例名称具有一定的可搜索性。使用常见的关键词或标签,以便于在测试管理工具中进行快速检索。 最重要的是,根据团队的需求和约定制定适合自己项目的测试用例命名规范。这样可以确保测试用例名称的一致性和可读性,提高测试效率和管理质量。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值