下载掌阅APP，畅读海量书库
立即打开
在Neal Ford、Rebecca Parsons和Patrick Kua合著的《演进式架构》 [1] 一书中，将适应度函数定义为“用于总结预期设计的解决方案与实现设定目标接近程度的目标函数”。这样的函数通常会输出一个离散值，这个值就是你试图实现或改进的指标。要知道是否达到了目标，就需要一个测试或验证机制来度量所需的指标。理想情况下，你会希望这是自动化的，但这并不是适应度函数的需求。
我喜欢使用适应度函数来创建目标指标这个概念，因为它们非常灵活。你还可以使用适应度函数来描述和集成典型的指标（例如代码覆盖率或圈复杂度
这类代码结构指标），但它们的开放性允许你根据你的系统和上下文来定制架构指标。
图2-1说明了适应度函数和目标指标之间的关系。适应度函数定义目标指标并描述相关的上下文，我称之为适应度函数上下文。这可能包括影响测试的环境、定义和限制的附加信息；我将把这些信息分成若干类别，并在后文进行更详细的描述。
图2-1：适应度函数概念图
架构测试会产生目标指标。通常，此类测试还会直接验证所创建的指标是否高于（或低于）某个阈值。一般情况下，这些测试是作为持续集成（Continuous Integration，CI）工作流程的一部分自动执行的。有些测试设置可以在没有特定触发器的情况下持续运行和验证。我使用架构测试和架构验证这些术语来明确区分它们与功能测试。例如，功能测试可能会检查系统能否正确地创建一个新用户，而架构测试可能会检查系统是否能够创建10个用户，同时实现架构或质量目标。比如在本场景中，架构测试创建了一个指标，用于度量创建这10个用户的速度，并验证是否在10毫秒内完成。
适应度函数、其上下文以及实际目标指标之间是强关联的。我们在设计时就定义了这三者。架构测试是随后创建的，并不是适应度函数及其指标定义的一部分。
如果架构测试是自动化的（我强烈建议这样做），那么在实施测试之后，指标就会自动创建。在实施测试时，你可能需要更改系统或架构中的某些内容，评估新的工具和框架，并在“工程”方面发挥创造力。这些工作都要在确定目标和指标后进行。如何以及何时定义适应度函数和实施架构测试将在2.7节介绍。
简而言之，适应度函数相当于你对“好”的定义。接下来让我们看一些例子。
假设在某个系统中，我们必须将单元测试覆盖率
保持在90%以上，自动化集成测试的目标是代码行覆盖率超过50%，让我们看看如何将这两个目标描述为带有此上下文的适应度函数（示例2-1和示例2-2）。
示例2-1：适应度函数——单元测试
单元测试覆盖率＞0.9；
在每一次CI构建中执行；
当低于目标覆盖率时失败
示例2-2：适应度函数——集成测试
集成测试覆盖率＞0.5；
在每一次夜间（nightly）集成测试构建时运行；
当低于目标覆盖率时失败
从这些简单的示例中可以看出，适应度函数定义了要达到的目标指标（测试覆盖率），与指标相关的上下文（要执行的测试类型和执行时间），以及自动验证指标所需的其他上下文信息。
实际的实现（如示例2-1所述，在测试执行过程中度量代码覆盖范围；或如示例2-2所述，建立特定的测试环境，执行测试并验证结果）是架构测试实施的一部分。
假设你正在测试的系统使用REST/JSON API与第三方系统集成，如果该API缓慢或无响应，你自己的系统的稳定性和性能将会下降，因此你需要验证你的系统能否正确处理此类事件并按预期执行。此类适应度函数将会如示例2-3所示。
示例2-3：适应度函数——网络延迟的集成测试
集成测试错误率=0%（在调用第三方API网络延迟为10秒时）；
在每一次夜间（nightly）集成测试构建时运行；当集成测试失败时，该适应度函数也失败
在这个例子中，适应度函数的部分可能不像前两个例子那样明显。在执行集成测试时，在给定的上下文中模拟系统调用第三方API时遭遇10秒的网络延迟，此时要满足的指标是0%测试错误（无错误）。
实际测试实施是负责设置测试环境，模拟第三方API调用的10秒网络延迟，每晚执行集成测试构建，然后在集成测试出现任何错误时失败。
示例2-3的一个变体是，在网络延迟为10秒的情况下，将相同的上下文与一个额外的指标（如系统的总体吞吐量）相结合，从而测试某种备用机制是否正常工作（如示例2-4）。
示例2-4：适应度函数——示例2-3的变体
集成测试错误率=0%（在第三方API调用的网络延迟为10秒时）；
在每一次夜间（nightly）集成测试构建时运行；当集成测试失败时，该适应度函数也失败；
当测试执行时间＞10分钟时失败（在没有网络延迟下的标准执行时间低于5分钟）
针对这一变化，我添加了一个额外的指标，也就是还需要满足另一个特定的性能指标。再次使用10秒的网络延迟这个上下文，我们要验证系统的备用机制是否有效，并且整个系统仍然在某个时间范围（总执行时间不超过标准时间的2倍）内正确执行。