回归测试选择用例，看这里就可以了。
Posted 测试大大怪
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了回归测试选择用例，看这里就可以了。相关的知识，希望对你有一定的参考价值。
介绍
在软件生命周期中，软件经常发生变化，软件开发人员任何代码改动都会有引入故障的风险）。
为了消除或减小这种风险，在软件迭代开发模式下，回归测试扮演着重要的角色：它能够帮助测试人员验证新增的功能或故障修复后的程序是否满足期望。
目前，常见的具有代表性的回归测试策略主要有两种：
一是重试所有策略，即选择所有已有用例进行测试；
二是最小选择策略，即选取具有代表性的测试用例进行测试。
重试所有策略最大限度地扩大了测试覆盖范围，可以保证在程序修改后原来正确工作的代码不会产生新的错误。但是，随着软件功能的丰富、开发代码的增加，测试用例也随之增多。
当测试用例积累非常多时（比如成千上万条），此时一个新功能开发或故障修复完成后进行回归测试，则会对时间和资源的需求量提出巨大的要求。由于测试资源和时间的限制，如果运行全部存量测试用例和开发新的测试用例进行回归测试，显得不太可取。
最小选择策略可以缩减测试用例集的大小，测试成本较小，但是检错代码错误的能力相对于重试所有策略则削弱很多。最小选择策略的检测错误能力不够完善，但其低成本优越性，使得无数人员争相研究和推进，它已经成为回归测试中最常用的测试策略。
回归上述提及的回归测试策略不难发现，在回归测试活动中，测试用例的选择往往着重于已有测试用例的选择，对于新增功能或功能变动引起的新增测试用例并未提及，而这一部分在回归测试中也占据着重要地位。因此，在有限的时间和资源条件下，如何筛选存量测试用例和设计新增用例，快速地完成回归测试成为了大多数测试人员思考的问题。
本文旨在提出一种快速回归测试用例选择方法，帮助测试人员能够快速地完成回归测试。
该策略主要涉及两个环节：
- ·存量测试用例的筛选
- · 新增用例的设计方法
在存量测试用例筛选环节引入相关性判断，考虑测试用例与功能的相关性、测试用例执行通过率、测试用例的稳定性、测试用例的发现的故障数、测试用例的自动化率等几个方面。
在新增用例设计环节，引入探索式测试方法（包括局部探索式方法和全局探索式方法）设计新增用例。
相关工作
回归测试可被分为两类：递进型回归测试和修正型回归测试。
递进型回归测试是指对原有测试用例进行修改，以适配测试修改后的程序（如新需求引入导致的模块或功能增删）。
修正型回归测试与递进型回归测试相反，主要特点在于原有测试用例不做任何修改。修正型回归测试主要用于修正程序设计错误或缺陷修复后的测试，其目的在于验证程序严格按照测试用例的输入输出描述运行。
在软件开发周期内，递进型回归测试和修正型回归测试活动往往是一起进行的。随着软件开发的深入、功能的不断增多，测试用例数量也会不断增大。此时，在成百上千或上万条测试用例的情况下，在某个开发周期内进行递进型回归测试和修正型回归测试，存量测试用例的选择、新功能测试用例的设计和开发都会成为有限时间和资源下快速完成回归测试的瓶颈。
传统的全部运行存量测试用例进行回归测试的方法，虽然可以保证测试的高覆盖率，但是会消耗大量的时间和资源，尤其是手工用例居多的时候。鉴于此种情形，如何使用最小选择策略去除回归测试用例冗余性，获取代表性用例进行回归测试，成为了很多学者探讨的问题。
最小测试用例集的选择方法有如：基于数据挖掘技术的测试用例选择方法、基于优先级排序的测试用例选择方法、基于启发式模型的测试用例选择方法等等。这些技术为回归测试存量测试用例的选择提供了有效的指导方法，但是它们有的仅是从设计过程选择用例或从执行结果选择用例，未充分考量选取测试用例的全面性。且针对迭代周期内当新增功能或代码变更时，并未提及如何设计新增用例并将新增用例纳入回归测试范围。
本文提出的快速回归测试策略重点在于存量测试用例的选取和新增测试用例的设计环节。
考虑到回归测试类型的差异性：
针对递进型回归测试，测试用例主要为新增测试用例，新增测试用例的设计方法采用探索性测试方法；
针对修正型回归测试，测试用例包含存量测用例和新增测试用例。
在存量测试用例选择时，从用例设计过程和执行结果两个方面出发进行联合筛选。
从用例设计过程出发，考量用例与功能的相关性（直接相关、间接相关），选择相关性强的用例；
从用例执行结果出发，选择稳定性差、通过率低、故障率低和自动化率低的测试用例。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
回归测试是什么？（基线版本基线测试包代码相依性回归测试包软件操作剖面）
文章目录
回归测试
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是很有意义的。
回归测试是软件测试中的一个十分重要且成本昂贵的过程。针对如何减少回归测试成本，提高回归测试效率的研究将具有十分重要的意义。回归测试选择技术已经成为国际上研究的热点。
产生原因
在软件生命周期中的任何一个阶段, 只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时, 如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改;而开发者对错误理解的不够透彻, 也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身从而造成修改失败;修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。
同样, 在有新代码加入软件的时候, 除了新加入的代码中有可能含有错误外新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时, 还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。
回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行得更加频繁，而在极端编程方法中, 更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。
定义
- 回归测试是指重复以前的全部或部分的相同测试。
- 新加入测试的模组，可能对其他模组产生副作用，故须进行某些程度的回归测试。
- 回归测试的重心，以关键性模组为核心。
测试用例
对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。
在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。
回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。
测试用例库的维护
为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。
随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。
为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。
因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。
测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。
(1)、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。
(2)、改进不受控制的测试用例
随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。
(3)、删除冗余的测试用例
如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。
(4)、增添新的测试用例
如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。
通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。
回归测试包的选择
在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。
回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。
回归测试
选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：
(1)、再测试全部用例
选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。
(2)、基于风险选择测试
可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。
(3)、基于操作剖面选择测试
如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。
(4)、再测试修改的部分
当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。
再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。
测试过程
有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行:
- (1). 识别出软件中被修改的部分；
- (2). 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。
- (3). 依据一定的策略从T0中选择测试用例测试被修改的软件。
- (4). 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。
- (5). 用T1执行修改后的软件。
第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证 修改工作本身。
测试实践
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。
通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。
在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时，测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。
回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。
回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad-hoc（点对点）测试。还可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。
在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。
在实际工作中，可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。
以上是关于回归测试选择用例，看这里就可以了。的主要内容，如果未能解决你的问题，请参考以下文章