[如何做好回归测试.docVIP

回归测试 文件类型：技术总结 文件编号： 版 本：V1.0 共 6 页 (包括封面) 目录 目录 2 一.文档写作目的 2 二.环境拓扑结构图 3 三.回归测试定义 3 四.回归测试的重点 4 五. 如何做好回归测试 5 一.文档写作目的 回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。如何快速，目标明确且保证尽可能全面的进行回归测试是每个测试人员想做到的。 参考了一些专业的介绍回归测试的文档，有些较复杂，理解不简单。本文结合一些网上高手的文档和自己的工作体会简要做一下介绍，主要围绕网关类的项目如何进行回归测试做一下简要的介绍，希望能在回归测试的阶段对大家有些帮助。 二.回归测试定义 根据百度百科的介绍：回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。 从百科的介绍我们可以得出几个结论： 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个重点，关联功能，这需要我们根据关联涉及相应的用例，以保证新加功能可用的情况下不影响已有的功能，否则就可能会有顾此失彼的可