用例级别和缺陷等级

测试用例级别:

  Level1 基本:
  1、该类用例设计系统基本功能,1级用例的数量应受到控制、
  2、划分依据:该用例执行的失败会导致多出重要功能无法运行的,如:表单维护中的增加功能、最平常的业务使用等。可以认为是发生概率较高的而经常这样使用的一些功能用例。
  3、该级别的测试用例在每一轮版本测试中都必须执行

  Level2 重要:
  1、2级测试用例实际系统的重要功能。2级用例数量较多。
  2、划分依据:主要包括一些功能交互相关、个种应用场景、使用频率较高的正常功能测试用例
  3、在非回归的系统测试版本中基本上都需要进行验证,以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是够进行测试。

  Level3 一般:
  1、3级测试用例设计系统的一半功能,3级用例数量也较多。
  2、划分依据:使用频率较低于2级用例。例如:数值或数组的便捷情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。
  3、在非回归的系统测试版本中不一定都进行验证,而且在系统测试的中后期并不一定需要每个版本都进行测试

  Level4 生僻:如果没有可以不适用该级别
  1、该级别用例一半非常少。
  2、划分依据:该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误,但是那些用例的处罚条件非常特殊,仍然应该被植入4级用例中。如界面规范化的测试也可归入4级用例。在实际使用中使用频率非常低、对用户可有可无的功能。
  3、在版本测试中有某些正常原因(包括:环境、人力、时间等)经过测试经理同意可以不进行测试。

  软件的缺陷等级应如何划分:

  A类——致命错误,包括以下各种错误:
  1.由于程序所引起的死机,非法退出
  2.死循环
  3.数据库发生死锁
  4.因错误操作导致的程序中断
  5.功能错误
  6.与数据库连接错误
  7.数据通讯错误

  B类——严重错误,包括以下各种错误:
  1.程序错误
  2.程序接口错误
  3.数据库的表、业务规则、缺省值未加完整性等约束条件

  C类——一般错误,包括以下各种错误:
  1.操作界面错误(包括数据窗口内列名定义、含义是否一致)
  2.打印内容、格式错误
  3.简单的输入限制未放在前台进行控制
  4.删除操作未给出提示
  5.数据库表中有过多的空字段

  D类——提示错误,包括以下各种错误:
  1.界面不规范
  2. 辅助说明描述不清楚
  3. 输入输出不规范
  4. 长操作未给用户提示
  5. 提示窗口文字未采用行业术语
  6. 可输入区域和只读区域没有明显的区分标志

版权声明:本文出自 tantan520 的51Testing软件测试博客:http://www.51testing.com/?408129

时间: 2024-11-04 09:15:07

用例级别和缺陷等级的相关文章

缺陷等级定义

B/S架构(Web)测试的缺陷等级定义: A: 致命 正常的用户操作导致浏览器崩溃或无响应 产品核心功能没有实现或无法使用:例如播放器无法播放视频.邮箱无法登录.不能收发邮件 程序实现与需求严重不符:例如一个程序改版只为了按需求增加统计功能,但程序没有统计功能或有统计输出但并非是要统计的数据 其他导致无法测试的错误:例如没有新功能入口 严重的数值计算错误:例如算法设计错误,导致计算结果错误 存在致命的安全漏洞:例如密码不匹配也可登录.密码暴露在URL串中.复制最高权限登录后的页面链接在其他进程浏

pytest文档31-allure标记用例级别severity

前言 我们在做功能测试的时候,执行完一轮测试用例,输出测试报告的时候,会有统计缺陷的数量和等级. 在做自动化测试的过程中,当你的测试用例越来越多的时候,如果执行一轮测试发现了几个测试不通过,我们也希望能快速统计出缺陷的等级. pytest结合allure框架可以对用例的等级做详细的划分. 用例等级 allure对用例的等级划分成五个等级 blocker 阻塞缺陷(功能未实现,无法下一步) critical 严重缺陷(功能点缺失) normal 一般缺陷(边界情况,格式错误) minor 次要缺陷

缺陷等级分类

High等级的分类与示例 关键数据错误 例: 统计报表中的项目数量和资金统计不正确. 巡视工作任务中,将缺陷记录中的缺陷上报生产,在缺陷登记模块中可看到3条一样的数据. 物资采购数为10,现场和仓库可分别到货10件. 所有功能在正常操作下报错(如500或404等). 例: 打开计划下达审批页面,系统报500. 点击查询按钮,系统报404. 主要功能在正常操作下没有实现. 例: 新增.保存.删除.发送.回退.撤回.导出和查询等操作不成功. 主要功能在正常操作下结果不正确. 例: 检查不通过的项目可

如何对所发现的缺陷进行严密的等级划分

对于如何划分缺陷的等级,测试资料中都有细致详细的说明,只要引经据典就能回答好该问题,而且得分为100分.可是,有多少人能背下来,只要背不下来,那就说明答案只存在于理论而不能用于实战.我们需要理解,只有理解的缺陷等级划分才是切实可行,也正是我们需要的. 在划分缺陷等级之前,我们需要先思考为什么需要进行等级划分?很遗憾,百度中我没有找到相关的答案.我的观点是缺陷的等级是用以评估该缺陷对软件使用的潜在影响,对软件质量评估的直接依据之一,测试准出的主要指标,影响修复优先级的主要参考.越是影响软件使用,越

缺陷严重等级划分

修改记录 修改人 修改时间 修改说明 备注 2014.10.22 文档创建 2016.05 缺陷严重等级分类再明细,并发起会议评审,与产品组达成一致 2018.05.16 添加 缺陷易显现难度划分 模块 致命 1.客户端.服务器死机或者不响应 2.数据库死锁 3.客户端异常退出 4.客户端无法正常连接服务器 5.实现的功能与需求完全不符 6.核心功能出现异常(导致客户业务无法进行下去) 7.脚本运行后将原有数据库中值修改错误 (影响客户使用.该情况较难发现,一旦出现,属于致命错误) 8.严重的数

需求用例分析之二:级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,下面用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了例如以下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,仅仅能选择其一,以下对其详细说明: 概要:包含多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个文件夹表"的功能,概要用例通常须要运行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主运行者努

需求用例分析之级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,以下用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了如下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,只能选择其一,下面对其具体说明: 概要:包括多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个目录表"的功能,概要用例通常需要执行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主执行者努力使工作

缺陷提交

怎么提交缺陷?测试过程中都要注意什么? 第一 缺陷截图 理由: 缺陷可能难以重现,而在你再次验证该缺陷前你并不知道这点,所以养成先对缺陷截图的习惯,这样不管啥时候,你都可以对相关人员直观的展示出现过的问题.至少别人不可以否认你说“问题压根不存在” 第二 是否重现 对于发现的缺陷,至少进行2-3次的重复验证. 理由: 1.判断缺陷是否可重现 2.确定重现缺陷需要的最简单步骤   遇到难以重现的缺陷怎么处理? a) 停止操作,开始记录 尽量回忆之前的操作步骤.操作过程,并记录下来.包括操作环境.所以

需求用例分析之业务规则

作者:张克强 作者微博:张克强-敏捷307 在雅各布森用例分析方法和科伯恩用例分析方法中其实都没有"业务规则"的属性,在科伯恩方法中有个相近的属性是约束条件.但是业界使用中常常会给用例加上这个属性,这是为什么呢?为什么两位大师没有加上,是大师们疏忽了?而为什么不少人加上了呢? 从时间和传播上很容易推断,业务规则的来源是传统的需求规格说明书.在传统的需求规格说明书中,整理提炼业务规则或称业务逻辑是其中核心的分析产物.受到传统需求规格说明书的深远影响,不少人觉得这样的业务规则是值得写的用例