软件系统变更与测试实践指南

### 软件系统变更与测试实践指南 #### 1. 构建简单高效的系统 一个精心设计的系统，其关键在于简单性。只构建你所需要的部分，这样就能更轻松地确保所构建的内容是正确的。当重组代码能明显增加价值时，比如让当前的工作变得更简单、更安全，那就进行重组。一旦发现“破窗”（即系统中的小问题），及时修复。 #### 2. 管理技术债务 技术债务是指我们在系统中留下未修复的问题。就像大多数金融债务一样，系统会为技术债务收取“利息”。具体表现形式多样： - 可能需要持续进行手动变通操作，以维持系统的运行。 - 在进行本可通过更简洁架构轻松完成的更改时，需要额外花费时间。 - 用户可能会遇到服务不可靠或难以使用的情况。 软件工艺很大程度上在于避免技术债务。养成一旦发现问题和缺陷就立即修复的习惯，最好是在问题产生时就解决，而不是陷入“现在这样就够了”的不良思维模式。 不过，将技术债务作为描述实施不佳系统的隐喻存在争议。有人认为这暗示了一种像借钱创业那样经过深思熟虑、负责任的决策。但实际上存在不同类型的债务，糟糕地实现某个功能就如同用发薪日贷款去度假，极有可能让你陷入“破产”的风险。Martin Fowler提出了技术债务象限，区分了有意与无意的技术债务，以及鲁莽与谨慎的技术债务。 #### 3. 管理重大基础设施变更 推荐的工程实践是一次只进行小的更改。但在交付大型且可能具有破坏性的变更时，这可能具有挑战性。例如，完全替换像用户目录服务这样的关键基础设施，可能需要数周甚至数月才能让新服务正常运行并通过测试。如果将旧服务替换为尚未正常工作的新服务，会给用户和我们自身带来严重问题。 以敏捷方式交付复杂工作的关键是将其分解为小的更改。每个更改都应具有潜在的用途，即使还未准备好用于生产环境，至少也要能让某人尝试并看到效果。可以从功能的角度来思考，比如将任务定义为“确保服务器上sshd不可用时能收到通知”，而非“实现ssh的监控检查”。对于大型项目，团队可以根据功能来定义进度。 以下是逐步构建生产系统重大变更的一些技术： - **进行小的、无干扰的更改**：逐步替换旧功能。例如，逐步实现自动化服务器配置，选择服务器的一个元素编写清单（或配方、剧本等）来管理它，随着时间推移，逐步添加更多配置元素。 - **对用户隐藏更改**：以替换用户目录服务为例，可以开始构建新服务并部署到生产环境，但同时保留旧服务运行。有选择地测试依赖该服务的服务，定义使用新用户目录的服务器角色，并在生产环境中创建一些不用于关键服务但可用于测试的服务器。选择一些候选服务首先迁移到新目录，比如基础设施团队使用但最终用户不使用的服务。 重要的是，要确保任何需要一段时间才能实施的更改在开发过程中持续进行测试。 #### 4. 测试基础设施变更 测试的目的是帮助我们快速完成工作。然而，在许多组织中，测试却被视为减缓工作进度的因素。这通常是因为将质量保证（QA）视为与构建软件或管理基础设施工作分离的功能，而不是将其融入到正在进行的工作中。 自动化一个有缺陷的测试过程并不能使其变得更好，但自动化测试确实能让团队更容易真正掌控所构建内容的质量。团队可以持续测试正在进行的工作，从而对工作的可靠性充满信心。这种信心能够实现可持续、快速的工作节奏，而这在存在未发现和未解决问题的系统中是无法实现的。 不同团队在测试方面有不同的表现： - **部分QA团队**：难以使用工具来自动化测试阶段，无法编写足够的测试脚本来覆盖系统的各个方面。现有的测试很脆弱，每一轮新的测试都需要花费大量时间来修复和更新测试脚本。他们原本希望自动化测试工具能让工作更快捷、轻松，但结果却增加了工作量，很多时候测试人员不得不依靠手动测试列表来维持工作。 - **部分团队**：将自动化测试嵌入到正常的开发和维护过程中，自动化测试作为持续集成（CI）和持续交付（CD）管道的一部分，全天持续运行。测试不再被视为一个单独团队的领域，而是编写代码和维护基础设施人员的责任。但即使是这些团队也会遇到困难，