如何做好回归测试

回归测试 文件类型：技术总结 文件编号： 版 本：V1.0 共 6 页 (包括封面) 目录目录 目录2 一.文档写作目的.2 二.环境拓扑结构图.3 三.回归测试定义.3 四.回归测试的重点.4 五. 如何做好回归测试.5 回归测试 第 3 页 一一.文档写作目文档写作目的的 回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有 很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。如何快速， 目标明确且保证尽可能全面的进行回归测试是每个测试人员想做到的。 参考了一些专业的介绍回归测试的文档，有些较复杂，理解不简单。本文 结合一些网上高手的文档和自己的工作体会简要做一下介绍，主要围绕网关类 的项目如何进行回归测试做一下简要的介绍，希望能在回归测试的阶段对大家 有些帮助。 二.回归测试定义回归测试定义 根据百度百科的介绍：回归测试是指修改了旧代码后，重新进行测试以确 认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低 系统测试、维护升级等阶段的成本。 从百科的介绍我们可以得出几个结论： 1）：回归测试是在已经经历过第一轮系统测试甚至于几轮的系统测试后进 行的。 2）：回归测试除了测试已有的功能外，还要考虑是否有新加功能。 3）：某种程度上，自动化测试或许可以降低成本。之所以说某种程度上和 或许，这是有前提的。自动化测试对测试用例要求较高，并非所有的项目都适 合自动化测试。 三三.回归测试的重点回归测试的重点 回归测试用例的选择相比系统测试更为复杂，因为回归测试相比系统测试 一般时间较短，而且已经经历过了系统测试，有些模块已经可以保证没有问题 了。这样，就需要测试人员对测试用例进行合理的选择。测试人员通常有两种 作法。一种是，把相关的或是所有的模块的测试用例都选出来执行一遍；另一 种是，仅针对被 Fixed 的 APAR/Defect 进行检验，测试用例很少或是开发新 的针对这个 Fixed 的测试用例。这两种方法都存在不足。第一种方法在测试时 间有限的情况下，去执行所有的测试用例，会测试到很多无需再测试的测试用 例，从而导致测试资源的浪费；第二种是很难确保 APAR/Defect 改动后，被 测系统没有受到关联影响，很难保证测试质量。 由于 Bug Fix 或者功能更新后，在新版本发布之前，我们要确保所作改动 不会对已有的功能模块产生负面的影响。用所有的测试用例作回归测试， 存在 着人力与时间成本过高的问题；依靠人的经验去挑选回归测试用例，存在着挑 选不准确或对程序改动测试覆盖不全的问题。 其实可以大概总结回归测试的重点：BUG 修改，关联功能，新增加，修改 功能，上一轮测试 BUG 多的功能。下面我将结合行业网关的测试详细介绍一 下每个重点需要关注的地方。 1）：bug 修改 这个重点比较好把握，所谓的 bug 修改就是说在前几轮测试中测出的问题， 这个在我们的 bugbase 或者 QC 上面都有记录，进行回归测试时，我们可以根 据 QC 上提交的 bug 进行验证，这同时也要求测试人员在记录 bug 时要尽量的 详细明确。 对 bug 修改进行的回归测试是最简单，最重要的。同时也是现在项目中使 用的回归测试方法。 2）：关联功能 涉及到关联功能，就需要测试人员对代码的结构有所了解。要熟悉系统的 业务流程。对于该 bug（或新增功能）的业务需求以及关联模块要很清楚，可 以尽快进入测试状态并保证测试的质量。同时要求开发人员在修改 bug 状态的 时候，要注明修改了哪个模块的哪些函数，这些信息有助于懂代码的测试人员 去分析判断该 bug 是否真的修复好并对系统产生哪些影响。 所有的测试用例都会有一个函数调用的路径。我们把这些调用路径一一记 下来。对于新版本所作的改动，所有与之相关的上层调用的测试用例都能够准 确地选出来，这样我们就能用这些准确的测试用例来覆盖这次改动所产生的影 响。毫不相关的测试用例则不会被选出来。从而用较小的成本完成这次改动所 需要的回归测试，既省时省力又保证较高的测试质量。比如说，网关代码中修 改某个功能可能会涉及到重传模块，过期模块，恢复模块。这样，我们就需要 在回归测试中，对这一个接口的重传功能，过期功能，消息恢复功能进行系统 的测试，只有这样，才能保证修改的这个接口不会影响其它功能。 3）：新增加功能 所谓的新增加功能是在系统测试过程中没有的功能点，这可能是客户的需 求增加或者是开发人员对需求的理解遗漏等等，这部分新加的代码有可能是独 立的也有可能是影响已有代码的，因此需要测试人员根据实际情况增加用例。 如果是独立功能的话就增加独立的测试用例，如果影响已有代码就要在测试新 功能的基础上考虑对已有功能的哪些部分照成影响了，这又涉及到了第 2 个重 点，关联功能，这需要我们根据关联涉及相应的用例，以保证新加功能可用的 情况下不影响已有的功能，否则就可能会有顾此失彼的可能，甚至会出现捡了 芝麻丢了西瓜的现象发生。 4）：修改功能 修改功能的原因可能有多种，需求变更或者开发人员理解需求有误等等都 有可能照成要对功能进行修改。修改功能和新增功能比较相似，如果修改的功 能是独立的，这种回归比较简单，只需要根据功能进行系统的测试就可以了， 但是这种情况往往概率较小，更多的情况是修改某一个功能点会涉及到很多关 联模块，这样就需要对关联模块进行测试。 5）：上一轮 bug 较多的地方 系统测试出来的 bug 较多的地方就是所谓的“高危模块” ，也就是上线风险 较大的模块，这个模块的 bug 多就代表着这个模块的代码不够完善，回归测试 中这也是重点，需要我们测试人员针对这块“高危模块”涉及更多的用例进行 bug 的挖掘。 回归测试 第 5 页 四四. 如何做好回归测试如何做好回归测试 下面是搜索的一些关于如何做好回归测试的方法。总结在一起，希望对测 试人员有所帮助。 1）变换测试人员 回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试 效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者 完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自 动测试脚本，做一些探索性的或 ad hoc 测试。还可以在不影响测试目标的情况 下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于 激励测试者又能揭示新的错误。 2）使用自动化测试 在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同 的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工 完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归