回归测试用例选择方法.PPT

  1. 1、本文档共18页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
回归测试用例选择方法

第八章 回 归 测 试 本章主要内容: 概述 回归测试的类型 回归测试的流程 回归测试的策略 回归测试的实践 回归测试用例的选择方法 总结 作业 一、概述 回归测试是指修改了旧代码后,重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。理论上,软件产生新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再次出现。 回归测试是测试实施过程中最为重要的环节之一,回归测试做得好与坏,直接影响到测试工作地效果。而且,回归测试的工作量占测试实施的工作量的5成以上。 二、回归测试的类型 一般回归测试 一般回归测试:适用于各个系统测试阶段中,验证前一次系统测试中失败的用例,和产品的有效性。 一般的回归测试可以再一段时间就使用一个更新了的版本(基于测试用例的测试),但是一般说来在一个回归测试中尽量保证被测试版本不变是有益的。 最终回归测试 最终回归测试:适用于产品正式发布前的创建版本,验证发布版本的有效性。 在执行最终回归测试的时候要求被测试的版本在一段时间内是固定不变的,也就是在产品发布中经常说到得“cook—time”。在这段时间里面,产品会反复的测试。某些测试用例可能要被执行几次,以确认在发布版本中不会存在用户在使用过程中会遇到BUG。所有的基于发布版本的BUG修改工作应当在最终回归测试前完成。由于它测试的版本就是用户将要使用的版本。 三、回归测试的流程 回归测试一般主要有以下流程: 1、在测试策略制定阶段,制定回归测试策略; 2、确定回归测试版本; 3、回归测试版本发布,按照回归测试策略执行回归测试; 4、回归测试通过,关闭缺陷跟踪单; 5、回归测试不通过,缺陷单返回开发人员等重新修改,再次做回归测试; 四、回归测试策略 (一)、为什么要进行回归测试? 回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时,有可能删除了将揭示回归错误的测试用例,消除了发现回归错误的机会。然而,如果采用了代码相依性分析等安全的缩减技术,就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。 (二)、概述 回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下,尽可能有效率和有效力地进行回归测试,需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。 (三)、测试用例库的维护 测试用例的维护是一个不间断的过程,通常可以将软件开发的基线作为基准,维护的主要内容包括下述几个方面: (1)、删除过时的测试用例 (2)、改进不受控制的测试用例 (3)、删除冗余的测试用例 (4)、增添新的测试用例 (四)、回归测试包的选择 选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括: (1)、再测试全部用例 (2)、基于风险选择测试 (3)、基于操作剖面选择测试 (4)、再测试修改的部分 (五)、回归测试的基本过程 回归测试可遵循下述基本过程进行: (1)、识别出软件中被修改的部分; (2)、从原基线测试用例库T中,排除所有不再适用的测试用例, 确定那些对新的软件版本依然有效的测试用例,其结果是建立一 个新的基线测试用例库T0。 (3)、依据一定的策略从T0中选择测试用例测试被修改的软件。 (4)、如果必要,生成新的测试用例集T1,用于测试T0无法充分测 试的软件部分。 (5)、用T1执行修改后的软件。   五、回归测试的实践 ?在组织回归测试时需要注意两点,首先是各测试阶段发生的修改一定要在本测试阶段内完成回归,以免将错误遗留到下一测试阶段。其次,回归测试期间应对该软件版本冻结,将回归测试发现的问题集中修改,集中回归。? ?在实际工作中,可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题,而同时也可以揭示编码在回归方面的错误。   六、回归测试用例选择方法 一般有如下必须回归的用例: 第一、新修改的功能,这个显然是重点; 第二、新修改的功能的关联功能,就是有耦合的部分,这个一般最好咨询一下开发人员; 第三、程序最有卖点或者说亮点的部分,这个地方一旦有问题,会使程序质量大打折扣;  第四、程序中最致命的部分,譬如说安全隐患,数据泄露,加密注册; 第五、程序中比较脆弱的部分,这个要咨询开发人员,一般就是他们心中最没底的地方; 第六、程序的主干功能; 第七、如果以上做完,还有时间的话,最好把用例中级别比较高的用例再执行一遍;  

文档评论(0)

laolao123 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档