如何做好回归测试.doc

回归测试

文件类型：技术总结
文件编号：
版 本：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个重点，关联功能，这需要我们根据关联涉及相应的用例，以保证新加功能可用的情况下不影响已有的功能，否则就可能会有顾此失彼的可能，甚至会出现捡了芝麻丢了西瓜的现象发生。
4）：修改功能
修改功能的原因可能有多种，需求变更或者开发人员理解需求有误等等都有可能照成要对功能进行修改。修改功能和新增功能比较相似，如果修改的功能是独立的，这种回归比较简单，只需要根据功能进行系统的测试就可以了，但是这种情况往往概率较小，更多的情况是修改某一个功能点会涉及到很多关联模块，这样就需要对关联模块进行测试。
5）：上一轮bug较多的地方
系统测试出来的bug较多的地方就是所谓的“高危模块”，也就是上线风险较大的模块，这个模块的bug多就代表着这个模块的代码不够完善，回归测试中这也是重点，需要我们测试人员针对这块“高危模块”涉及更多的用例进行bug的挖掘。
四. 如何做好回归测试
下面是搜索的一些关于如何做好回归测试的方法。总结在一起，希望对测试人员有所帮助。
1）变换测试人员
回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。
2）使用自动化测试
在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求
3）对测试人员的要求
测试人员要及时与开发人员进行有效的沟通，更多地了解业务及系统，及时反馈测试情况，同时，测试人员熟悉系统开发的语言也是必要的。

回归测试 第 5页