【tool】软件测试用例优先级与三轮测试的结合

软件测试用例优先级与三轮测试的结合测试用例设计

测试用例优先级、三轮测试,已经在我们测试团队推广开。那么我们要如何运用起测试用例优先级,可否与三轮测试相结合?简单谈下我的实践。

  冒烟测试用例、流程性测试用例、校验性测试用例。在编写测试用例时,我们会对每条测试用例设置优先级。完成测试用例后,搭建实验室,创建测试用例集合。测试用例实验室,首先创建3个一级文件夹,即按照3轮测试。我们每一轮的测试,目标是不同的,而每一轮都需要执行测试用例,我们如何将执行测试用例与三轮测试结合起来呢?

  首先我们通过优先级筛选,摘出所有P1级的测试用例,即冒烟用例。冒烟测试用例的通过率,是我们启动3轮测试的前提。

  然后搭建第一个文件夹:第一轮测试。大家知道,在测试前期,我们最先关注的、开发最希望先处理的,肯定是流程上的bug,那么我们就可以先来执行流程性的测试用例。那么我们创建第一轮测试这个文件夹后,下一级文件就可以分为流程性测试用例集和校验性测试用例集。通过P1级测试用例+P2级测试用例的筛选,我们可以筛选出全部的流程性测试用例,再按照原测试目录结构,在流程性测试用例中,搭建同样的目录结构,把P1+P2的测试用例导入到相应位置。此时,第一轮测试用例的流程性测试用例集便搭建好了。在第一轮测试中,P1级是否需要独立出来呢?不需要的,因为第一轮启动的前提就是P1级测试用例通过。 P1+P2一起执行,是为了把流程更连贯的串起来。

  下一步,就是搭建第一轮测试用例验证性测试用例集,方法与流程性测试用例集类似,筛选出P3集测试用例,导入到验证性测试用例集相应目录中即可。

  总结下第一轮测试用例集的实现目标:最先执行流程性测试用例,最先发现流程上的bug,并且完全覆盖了所有功能点。

  下一步就是第二轮测试用例集,在第二轮测试中,我们的目标是尽多的发现、验证bug,是版本达到基本稳定。由于我们在第一轮测试中,已经覆盖了流程和校验的bug,我们再次执行测试用例,就是来确认下是否引起了其他相关bug。此时,我们可以先跑下主流程确认版本可测试,然后按照功能模块测试便可。创建2 个文件夹:主流程测试用例集、非主流程测试用例集。主流程测试用例集,即为P1级测试用例;非主流程测试用例集,即为P2+P3级测试用例。P1级测试用例为主流程正确性测试用例,通常不会很多,可根据情况来定目录结构。非主流乘测试用例集同样保持和测试计划中的目录结构相同。

  总结下第二轮测试用例集的实现目标:最先执行主流程测试用例,保证版本可测。然后覆盖全部测试点,按照模块执行测试用例,便于联想到该模块一些非测试用例设计中会考虑到的情况。

  最后一步就是第三轮测试用例集了。第三轮测试,版本基本已稳定,主要目的是回归。回归测试用例,我们首先也是保证主要功能通过,即:P1级测试用例。我们第一个文件夹:主流程测试用例集,即为P1级测试用例。然后是保证流程通过,第二个文件夹:流程性测试用例集,即:P2级测试用例。对于校验性测试用例,个人感觉受其他影响较小,在第一轮测试、第二轮测试中均已验证,基本出现问题的概率较低。此外,由于通常项目时间后期时间非常紧,可以考虑第三轮测试中不执行验证性测试用例。

  总结下第三轮测试用例集的实现目标:在时间紧迫的情况下,尽快全面覆盖流程性测试用例的回归,保证流程正常。

时间: 2024-07-29 08:49:25

【tool】软件测试用例优先级与三轮测试的结合的相关文章

【tool】软件测试用例优先级与兼容性测试的结合

我们在做兼容性测试时,往往没有一套固定的思路,哪些需要做兼容性测试,兼容性测试做到什么程度,通常是由测试同学在执行测试时自己控制的.测试的同学经验深浅不同,做兼容性测试也就会有较大区别.我们可否将兼容性测试形成一套规范呢?又怎样将测试用例的执行与兼容性测试关联在一起呢? 首先,需要明确需要对那些浏览器进行兼容性测试.可以监控现在线上实际用户使用浏览器的情况,汇总统计百分比比重.不同的业务,对浏览器的支持会有所区别.比如交易线,我们一些控件会针对部分浏览器进行支持,通常兼容性测试的重点是这些支持的

【tool】软件测试用例的复审

软件测试用例的复审   软件测试 对测试用例的评审,就显得非常重要.测试用例设计完之后,要经过非正式和正式的复审和评审.在测试用例审查.评审过程中,主要检查下列内容: 测试用例设计的整体思路是否清晰,是否清楚系统的结构和逻辑从而使测试用例的结构或层次清晰,测试的优先级或先后次序是否合理; 测试用例设计的有效性,测试的重点是否突出,即是否抓住修改较大的地方.程序或系统的薄弱环节等; 测试用例的覆盖面,有没有考虑到产品使用中一些特别场景(scenario).考虑到一些边界和接口的地方; 测试用例的描

【tool】软件测试用例管理工具比较

软件测试用例管理工具比较 工具名 综述 优点 缺点 备注 TestManager Rational测试解决方案中推荐的测试用例管理工具. 1. 功能强大. 2. 文件夹形式的管理,可以对测试用例无限分级. 3. 可以和Rational的测试工具robot.functional相结合. 4. 有测试用例执行的功能,但必须先生成对应的手工或自动化脚本. 1. 本地化支持不好.汉字显示太小. 2. 测试用例很多时不太稳定.有时会造成测试用例的丢失. 3. 必须安装客户端才可使用.和开发人员交流不方便.

软件测试用例知识点梳理

一.概念 怎样以最少的人力.资源投入,在最短的时间内完成测试,去发现软件系统的缺陷(bug),保证软件的优良品质,是软件公司探索和追求的目标. ▲测试用例是测试工作的指导,是软件测试的必须遵守的准则,更是软件测试质量稳定的根本保障 ▲测试用例是指为实施测试而向被测试系统提供的输入数据,操作或者各种环境设置以及期望结果的一个特定集合. 简单来说------测试用例就是解决要测什么,怎么测和如何衡量的问题 二.测试用例的属性: 1.用例ID(编号) 2.用例名称() 3.测试目的 4.测试级别 5.

软件测试用例设计 0620

入职基础培训课程系列 软件测试概述 软件测试用例设计 软件测试缺陷管理 软件系统测试 培训目标:1 明确测试用例在软件中的重要性 2 掌握测试用例设计的基本思路 3 了解并熟悉测试用例的要素和编写方法 课程内容: 1基本定义 要素和作用概念 2测试用例设计过程 3测试用例设计思路实例分析 用户登录:性能测试 安全性测试 文档测试 功能测试 界面测试 兼容性测试 什么是用例:用例是输入输出对,输出描述的是对输入数据的预期结果 用例是一组操作序列与数据的集合,这个集合通常具有业务或操作上的意义,一般

【tool】测试用例实践

测试用例无疑在测试过程中起着举足轻重的作用,好的测试用例让测试人员在测试执行过程中心情愉悦,测试效率高,能发现更多的问题. 好的测试用例一般有如下几个特点:清晰.简洁.完整.适用性.针对性以及以维护性.总结了我们公司的测试用例状况,存在以下一些问题: 1.全case测试用例太过详细.冗余,测试起来费时费神,而且发现不了什么问题,测试用例在清晰简洁性方面存在问题,这还体现在交叉测试上,冲突事件太多,实际上很多都是等价的冲突,有限的时间,没必要逐一确认: 2.同项目多个平台升级(客户升级)版本重复使

【tool】软件测试中获取负面测试的技术

一个测试用例用于证明该需求已经满足,通常称作正面测试用例: ·另一个测试用例反映某个无法接受.反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例. 1.负面测试的目的负面测试在BS7925-1中的英国标准定义是采用Beizer的定义,其定义负面测试为“旨在说明 软件不能工作的测试”(原文:Testing aimed at showing software does not work).它可以带出一系列补充性的和竞争性的目的.•发现导致重大失效.崩溃.破

测试用例设计——如何提高测试覆盖率

前言 说到测试用例的设计,我想每个有过测试经历的测试工程师都会认为很简单,不就是:按需求或概要设计,得到软件功能划分图,然后据此按每个功能,采用等价类划分.临界值.因果图等方法来设计用例就行了. 但事实上撇开测试数据的设计不谈,仅就测试项来说,我们发现,对同一个项目,有经验的测试人员,在写用例或测试时总会有更多的测试考虑点,从而发现更多 的问题:而有些测试人员测试用例的撰写却只有那么三板斧,表面看好象已经把页面所有信息的测试都考虑到了,实际上却还是遗漏了大量测试覆盖点,导致其测试 出来的程序总是

软件测试用例方法

黑盒测试用例设计方法包括等价类划分法.边界值分析法.错误推测法.场景法等 1.等价类划分法 是指某个输入域的子集合.在该子集合中,所有的输入数据对于揭露软件中的错误都是等效的.分为有效等价类和无效等价类. 等价类划分法用例设计原则: 1)划分有效及无效等价类,为每一个等价类规定一个唯一的编号. 2)设计一个新的测试用例数据,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止. 3)设计一个新的测试用例数据,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,知道