在重构或重新设计时验证你的代码

　　一切都是为了改变。

　　“当源代码被修改时，我有哪些选择来维护我现有的测试？” 这是我在与客户交谈时遇到的一个非常常见的问题。

　　我的一些对话者指出他们必须重构他们的软件，其他一些人会谈论重新设计的努力。

　　首先，我注意到这两个与软件更改相关的概念在人们的头脑中并不总是很清楚，有时会在错误的环境中使用。这些概念对您来说可能非常清楚，但如果不是，这里有一些提示可以帮助您理解差异。

　　重新设计和重构软件有什么区别？

　　这些概念之间的主要区别在于：重新设计意味着您修改软件以改变它的功能，而重构则是努力修改它的工作方式。

　　出于多种原因进行重新设计工作。例如，由于硬件更改，软件需要在不同的 CPU 上运行或必须处理新的外围设备，因此需要修改或扩展代码以解决这些物理修改并提供新功能。当软件需要与新的或更新的 3 rd方库交互时，也可能发生重新设计，这些库提供了有益于您的应用程序的新服务。您可能会找到许多其他重新设计的原因，但在大多数情况下，在此上下文中执行的软件更改会影响一般行为或修改后的应用程序提供的功能。

　　与重新设计相反，重构是努力优化代码的内部实现，以提高其可维护性并降低其总体运营成本。和许多人一样，我相信 Martin Fowler 在他的“重构书”中写了软件重构的最佳定义之一：

　　“对软件的内部结构进行了更改，使其更易于理解且修改成本更低，而不会改变其可观察到的行为。”

　　鉴于此定义，重构通常由开发人员在以下情况下执行：

　　需要将技术债务控制在可容忍的水平，即低于从头开始重新构建整个代码看起来更经济的线以下。

　　降低复杂性和内部依赖，使软件更模块化、更容易扩展、对开发团队中的新人更易读和更易管理等。

　　确保随着时间的推移，原始设计保持可理解和清晰，并保留其预期功能。..。..

　　鉴于我们现在对重新设计与重构工作有了更清晰的了解，

　　哪些情况需要重新验证您的软件？

　　好吧，软件测试的本质是它们主要检查代码是否符合其目的。换句话说，他们根据应用程序的功能需求验证组成系统的每个软件单元的行为是否符合预期。话虽如此，如果您尝试重新设计代码，则必须对其进行测试以确保新功能已根据新引入的要求进行验证，同时确保这些新扩展不会在您现有的通过测试中引入回归。

　　您可能会争辩说，重构工作只会影响软件内部结构，因此不一定会影响代码接口和根据应用程序需求交付的一般服务。是的，但是…… 像任何其他开发活动一样，重构是引入新错误的一种非常简单的方法，因此您必须重新测试您的软件。维护一组完整且详尽的通过测试将确保您的重构不会导致代码中的回归错误未被检测到。确实，每当您进行小的更改时，您都应该重新执行现有的测试作为安全网，以检查您没有修改预期的行为。经过一系列增量更改后，您将以安全的方式达到最初目标的重构状态。

　　大多数组织希望通过在源代码更改时更新这些测试来保留先前测试投资的价值。但这会导致高昂的测试维护成本。该解决方案并不像仅仅识别受代码更改影响的受影响测试的子集以重新运行（有时称为测试影响分析或基于更改的测试）那么简单。测试维护的昂贵部分是开发人员花费在识别依赖关系和更新相应测试以确保它们与修改后的软件同步的工作。

　　那么适当的测试自动化如何降低这些测试维护成本呢？

　　1） 通过 对代码变更和测试依赖的初步分析：

　　· 了解正在测试的代码的更改（通过保留上次测试时的代码信息并将其与更改的代码进行比较）

　　· 识别哪些测试受到代码更改的影响

　　· 在单个视图中识别影响测试的所有代码更改

　　· 识别可能影响现有测试实现的代码覆盖率的代码更改

　　2） 通过为开发人员提供自动测试更新的指导选择，以便重新同步源代码和测试：

　　• 对于每个代码更改，建议对测试脚本和用例进行适当的更新

　　• 自动重构测试脚本以节省时间和成本

　　3） 对于主要影响软件内部结构的代码更改，自动生成安全网或通过测试的基线，以便：

　　• 在回归测试或持续集成期间查明故障

　　• 识别可测试性问题，例如无法访问的代码

　　作为专业的软件供应商，QA Systems 敏锐地意识到在软件修改的情况下控制测试维护成本的重要性。为了解决这个问题，我们开发了作为我们的测试解决方案 Cantata的一部分，一个代码更改分析和管理功能以及一个AutoTest生成框架，它们是在您的软件项目的整个生命周期中自动化单元和集成测试维护的独特技术。当您需要管理测试时，重新设计或重构您的软件不再是（烦人的）问题！

　　审核编辑：郭婷