Regression.pptVIP

第七讲： 回归测试 Lian Yu The School of Software and Microelectronics Peking University No.24 Jinyuan RD, Beijing 102600 Outline 引言 在软件开发、维护、与演进整个过程中，由于各种各样的原因，例如，改变了的功能的和非功能的需求、更新了的技术、和升级了的硬件或软件平台，使得软件系统常遭受改变。 这些改变对软件系统带来风险，因为改变传播效应（change propagations）可能会引人新的错误，有时甚至是致命的错误。回归测试是一种验证被改变系统的完整性与正确性。 什么是回归测试？ 回归测试是对之前已测试过、经过修改了的程序进行的重新测试，以保证该修改没有引入新的错误或者由于更改而发现之前未发现的错误。 回归测试通常在对被测系统（System Under Test, SUT）的第二个版本或后来版本进行测试时使用。 Outline 为什么我们需要回归测试呢？ 为了保证在软件维护时，那些未更改的代码功能不会受影响。 建立各个功能区域、信息系统持续的维护与回归测试改进之间协作关系，使回归测试成为一个每月的常规的活动； 为了使E2E测试（端到端测试）实现整个生命周期的测试。 建立一个测试框架，使得各信息系统和各功能区域用来监控和维持回归测试上的人力、时间等资源上的投入。 回归测试与一般测试有什么不同？(1/3) 测试计划的可获性：一般测试都是先拿到系统规格说明书（Specification）、系统规格说明书的一个实现和带有一些测试用例的测试计划。从一定意义上说这些测试用例都是新的，因为它们在之前从未执行过程序。但是当我们要进行回归测试时，我们面临的可能是更改了的规格说明书、修改过的程序和一个需要更新的旧的测试计划。 测试范围：一般测试过程目标是要检测整个程序的正确性，而回归测试目标是要检测被修改的相关部分正确性。 回归测试与一般测试有什么不同？(2/3) 时间分配：一般测试所需时间通常是在一个产品开发之前都被预算好的，但是回归测试所需的时间（尤其是修正性的回归测试）是不包含在在整个产品进度表和花费上的。 开发信息：在一般测试中，关于开发的知识、信息都随时可以获得。而回归测试可能会在不同的地点和时间上进行，所以我们需要保留开发信息以保证回归测试的正确进行。 回归测试与一般测试有什么不同？(3/3) 完成时间：回归测试完成所需时间通常比一般测试所需时间少，因为回归测试只需测试程序的一部分。 执行频率：一般测试是发生频率很高的一个活动。回归测试在一个系统的生命周期内往往要多次进行，一旦系统经过修改就需要进行回归测试。 回归测试过程 回归测试过程主要有这样七个步骤： 提出修改需求， 修改软件工件， 选择测试用例， 执行测试， 识别失败结果， 确认错误，和 排除错误。 提出修改需求：软件可能因为要改正一个bug而被修改，或者根据需求规格说明书或者设计说明书而被修改。 修改软件工件（software artifacts）：为了满足新的需求或者改正bugs而对软件工件进行修改。 选择测试用例：通过选择和有效性重确认过程获取正确的测试用例集，而不是要使测试用例数目最小化。有时候一些测试人员会不进行有效性重确认而直接使用所有的已有测试用例。 执行测试：这一步骤通常是要被自动化运行，因为会有大量的测试用例要执行。测试执行历史（遍历过的路径和被调用的过程、操作）都要被记录下来，这样能给将来测试做参考。 识别失败结果：如果测试结果与预期结果不一致，则有必要检查是测试用例错误，还是代码错误，或者两者都有错误。如果测试用例在早期没有进行有效性重确认，那么这时就该进行有效性重确认工作，尤其是那些已经导致失败的用例。我们在下面的段落里将进一步讨论有关重新确认测试用例的有效性过程。 识别错误：精确定位是哪个版本中的哪个组件，哪些修改导致的失败。在检查测试结果以识别失败时， 如果使用的测试用例的有效性用例在执行之前已被确认过，任何与预期结果的明显偏离都表明了软件存在一个潜在错误。 如果所使用的测试用例的有效性在之前未被确认，任何测试用例失败可能意味着要么是测试用例的不正确，要么是程序的错误，要么两者皆有。 排除错误：一旦识别了导致失败的组件，程序员就必须对这一组件进行排除错误工作。当一个错误被检测到后， 可以采取以下几种行动来改正错误： 1）改正错误后，提交一个新的程序修改卡(PMC)； 2）移去引起错误的修改卡(PMC) ，即修改错误； 3）忽略错误。 重新确认测试用例 测试用例的有效性重确认过程主要靠手工操作进行，目标是为了识别出对于更改了的软件，已经不再有效的现有测试用例。 在有效性重确认过程中，测试的输入和它的预期结