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

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

1. 构建简单高效的系统

一个精心设计的系统，其关键在于简单性。只构建你所需要的部分，这样就能更轻松地确保所构建的内容是正确的。当重组代码能明显增加价值时，比如让当前的工作变得更简单、更安全，那就进行重组。一旦发现“破窗”（即系统中的小问题），及时修复。

2. 管理技术债务

技术债务是指我们在系统中留下未修复的问题。就像大多数金融债务一样，系统会为技术债务收取“利息”。具体表现形式多样：
- 可能需要持续进行手动变通操作，以维持系统的运行。
- 在进行本可通过更简洁架构轻松完成的更改时，需要额外花费时间。
- 用户可能会遇到服务不可靠或难以使用的情况。

软件工艺很大程度上在于避免技术债务。养成一旦发现问题和缺陷就立即修复的习惯，最好是在问题产生时就解决，而不是陷入“现在这样就够了”的不良思维模式。

不过，将技术债务作为描述实施不佳系统的隐喻存在争议。有人认为这暗示了一种像借钱创业那样经过深思熟虑、负责任的决策。但实际上存在不同类型的债务，糟糕地实现某个功能就如同用发薪日贷款去度假，极有可能让你陷入“破产”的风险。Martin Fowler提出了技术债务象限，区分了有意与无意的技术债务，以及鲁莽与谨慎的技术债务。

3. 管理重大基础设施变更

推荐的工程实践是一次只进行小的更改。但在交付大型且可能具有破坏性的变更时，这可能具有挑战性。例如，完全替换像用户目录服务这样的关键基础设施，可能需要数周甚至数月才能让新服务正常运行并通过测试。如果将旧服务替换为尚未正常工作的新服务，会给用户和我们自身带来严重问题。

以敏捷方式交付复杂工作的关键是将其分解为小的更改。每个更改都应具有潜在的用途，即使还未准备好用于生产环境，至少也要能让某人尝试并看到效果。可以从功能的角度来思考，比如将任务定义为“确保服务器上sshd不可用时能收到通知”，而非“实现ssh的监控检查”。对于大型项目，团队可以根据功能来定义进度。

以下是逐步构建生产系统重大变更的一些技术：
- 进行小的、无干扰的更改 ：逐步替换旧功能。例如，逐步实现自动化服务器配置，选择服务器的一个元素编写清单（或配方、剧本等）来管理它，随着时间推移，逐步添加更多配置元素。
- 对用户隐藏更改 ：以替换用户目录服务为例，可以开始构建新服务并部署到生产环境，但同时保留旧服务运行。有选择地测试依赖该服务的服务，定义使用新用户目录的服务器角色，并在生产环境中创建一些不用于关键服务但可用于测试的服务器。选择一些候选服务首先迁移到新目录，比如基础设施团队使用但最终用户不使用的服务。

重要的是，要确保任何需要一段时间才能实施的更改在开发过程中持续进行测试。

4. 测试基础设施变更

测试的目的是帮助我们快速完成工作。然而，在许多组织中，测试却被视为减缓工作进度的因素。这通常是因为将质量保证（QA）视为与构建软件或管理基础设施工作分离的功能，而不是将其融入到正在进行的工作中。

自动化一个有缺陷的测试过程并不能使其变得更好，但自动化测试确实能让团队更容易真正掌控所构建内容的质量。团队可以持续测试正在进行的工作，从而对工作的可靠性充满信心。这种信心能够实现可持续、快速的工作节奏，而这在存在未发现和未解决问题的系统中是无法实现的。

不同团队在测试方面有不同的表现：
- 部分QA团队 ：难以使用工具来自动化测试阶段，无法编写足够的测试脚本来覆盖系统的各个方面。现有的测试很脆弱，每一轮新的测试都需要花费大量时间来修复和更新测试脚本。他们原本希望自动化测试工具能让工作更快捷、轻松，但结果却增加了工作量，很多时候测试人员不得不依靠手动测试列表来维持工作。
- 部分团队 ：将自动化测试嵌入到正常的开发和维护过程中，自动化测试作为持续集成（CI）和持续交付（CD）管道的一部分，全天持续运行。测试不再被视为一个单独团队的领域，而是编写代码和维护基础设施人员的责任。但即使是这些团队也会遇到困难，他们希望测试能覆盖100%的代码库，但维护测试的工作占据了主导。系统的每次更改都会触发一系列需要调整的测试，以确保构建通过。测试可能会间歇性失败，原因可能是系统与不可靠的外部系统集成，或者自身系统存在非确定性的行为。
- 部分团队 ：能让自动化测试良好运行。他们偶尔会花时间改进工具的使用方式，但工具不会成为障碍。他们倾向于为不同目的使用多种不同的测试工具，有助于保持测试的平衡。他们控制测试套件的规模，使其不会变得过大。测试套件运行迅速，人们无需花费太多时间等待测试完成。进行更改时可能需要添加或更新一些测试，但这并非重大的工作量。

5. 系统管理员与测试

基础设施团队通常认为测试具有挑战性。典型的系统管理员的QA流程如下：
1. 进行更改。
2. （如果有时间）进行一些临时测试。
3. 之后密切关注一段时间。

由于很多QA人员对基础设施了解不够深入，基础设施测试往往容易被忽视。

6. 变更咨询委员会（CAB）

希望对基础设施进行更严格管理的组织通常会设立变更咨询委员会（CAB）。CAB通过开会审查变更请求来处理基础设施测试问题，这有一定的价值：
- 进行变更的人员可以与同事协商，同事可能会提供有用的经验和建议。
- 可以发现与其他变更的潜在冲突。
- 让人们了解变更情况，以便在发现问题时知道与谁沟通。

然而，CAB常常会变成一种官僚主义的程序。人们可能被迫花费时间在没有实际价值的活动上，如填写详细表格、获取橡皮图章式的签字批准等。在某些情况下，CAB可能会因为表格未填写完整而拒绝变更请求，导致需要变更的人不得不等到下一次CAB会议，这可能需要等待一周或数周。

如果CAB流程变得繁琐，人们会想办法绕过它。例如，将所有变更都变成紧急修复，或者在许多组织中，人们复制粘贴变更请求表格而不关心细节，因为他们知道签字批准的人并不了解具体情况，甚至有人会完全忽略CAB流程。

7. 改进CAB方法

重要的是考虑流程的价值，并找到最有效的方式来实现这些价值。CAB的主要目标通常包括：
- 确保对计划的变更进行审查，而不是由个人自行进行变更。
- 避免与其他正在进行的变更发生冲突。
- 让人们了解变更情况，以防其受到影响。
- 为任何支持活动进行规划，如通知用户。

以下是一些有助于实现这些目标而又不会成为瓶颈的实践：
- 在将变更应用到重要系统之前自动进行测试。
- 让两个人一起处理变更。
- 通过电子邮件列表等方式，将计划的变更通知相关技术团队的人员，以便他们可以提问和提出建议。
- 当变更提交到版本控制系统（VCS）时，向技术团队发送提交/差异消息。
- 对于系统中高度敏感的部分，在将变更应用到生产系统之前，要求进行代码审查和签字批准。

无论团队决定采用何种实践，以下原则有助于保持工作的有效性：
- 优先审查已实现和测试的变更，而非未经验证的想法 ：在将变更应用到生产环境之前，通过良好的测试和预发布系统（如变更管理管道），安全地审查已实现和测试的变更。如果有必要，实现的内容可以随时进行修复、改进或放弃。
- 增加审批人员的收益递减 ：第二双眼睛的审视非常有价值，邀请广泛的群体对想法或实现进行审查和评论是引入不同观点、经验和技能的好方法。但需要批准变更的人员越多，流程就越困难，而增加的价值却不多。
- 关注进行变更的能力，而非阻止变更的能力 ：团队应致力于快速发现问题并进行修复（平均恢复时间MTTR）。虽然强调高质量文化和有效的持续测试过程很重要，但也要确保成本与收益的平衡。快速推向市场的好处可能超过成本相对较低的风险，特别是当风险能够迅速被检测和纠正时。
- 小的变更降低风险 ：小的、渐进的变更能够展示更大的解决方案，且易于讨论和审查。小变更破坏系统的风险较小，风险评估也更简单。如果出现问题，也更容易追踪和修复，这使得更简化的变更流程更容易实施。

原则	说明
优先审查已实现和测试的变更，而非未经验证的想法	通过良好的测试和预发布系统安全审查，必要时可调整或放弃实现内容
增加审批人员的收益递减	第二双眼睛有价值，但过多审批人员使流程困难且增值不多
关注进行变更的能力，而非阻止变更的能力	团队应快速修复问题，平衡成本与收益，快速推向市场可能更重要
小的变更降低风险	小变更易于审查，风险低，出现问题易追踪修复

graph LR
    A[开始变更] --> B{是否为小变更}
    B -- 是 --> C[直接进行]
    B -- 否 --> D[分解为小变更]
    D --> E[逐个小变更测试]
    E --> F[集成测试]
    F --> G[应用到生产环境]
    C --> G

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

8. 拥有测试权

敏捷软件开发的一大成果是打破了开发者和QA之间的壁垒。开发者和测试人员共同承担质量责任，而不是将质量保证完全交给一个单独的团队。敏捷团队从编码开始就进行测试，所有验证工作在开发过程中持续进行，这样在项目结束时就几乎没有剩余的测试工作。

然而，即使在敏捷团队中，QA工程师或测试人员的角色仍存在争议。一些团队认为，由于开发者自己编写自动化测试，因此不需要单独的测试角色。但实际上，即使在高效运作的团队中，QA人员也能带来有价值的观点、专业知识和发现系统漏洞的能力。

以下是团队管理测试的一些指导原则：
- 人们应该为自己构建的内容编写测试 ：让单独的人员或团队编写自动化测试有几个负面影响。首先，交付经过测试的工作需要更长时间，代码交接会产生延迟，测试人员需要花费时间理解代码功能、编写测试，并判断测试失败的原因。如果开发者已经开始处理其他任务，这会不断打断他们的工作。如果团队中有专门编写自动化测试的人员，他们应该与开发者合作编写测试，可以在测试阶段与开发者配对工作，确保开发者在测试完成且代码正确之前不转移到其他任务。更好的做法是在开发过程中就与开发者配对，边编写代码边编写和运行测试。目标是帮助开发者能够独立编写自动化测试，专业测试人员可以继续与团队合作，审查测试代码、寻找和改进测试工具，并推广良好的实践，或者去帮助其他团队。
- 每个人都应该能够使用测试工具 ：一些自动化测试工具采用按用户收费的昂贵许可模式，这导致只有少数人能够运行测试，因为为团队中的每个人购买许可证成本太高。这会导致反馈周期变长，工程师构建好东西后交给测试人员，测试人员运行测试并报告失败，工程师必须盲目地重现和修复错误，无法自己运行失败的测试。实际上，有许多强大的测试自动化工具，有大量免费和商业支持的社区，这些工具要么免费，要么价格便宜，不会给交付过程增加负担。

9. 为可测试性定义工作

QA人员在项目中带来的最有用的帮助之一是帮助我们更清晰地定义工作。大多数系统管理员倾向于直接开始实施工作，认为自己知道需要做什么，并且可以通过构建来解决其他问题。但对于具体任务，明确预期结果、原因以及如何判断任务完成是很有帮助的。

敏捷开发中有“用户故事”的概念，这是一个小而具体的工作单元，可以根据其价值和结果进行清晰定义。常用的“故事句子”格式为：“作为一个（用户），我想要（功能），以便（价值）”。基础设施团队通常难以以这种方式定义故事，有敏捷经验的业务分析师（BA）或QA人员可以帮助学习这种定义工作的习惯和技巧。

以下是一些基础设施故事句子的好坏示例：
|类型|示例|
|----|----|
|坏|作为基础设施架构师，我想要添加nagios内存检查，以便发送警报
作为安全审计员，我想要虚拟机安全，以便系统安全|
|好|作为支持团队成员，我想要在服务器即将内存不足时收到警报，以便防止停机
作为虚拟机所有者，我想要确保我的虚拟机上只运行严格必需的进程，以减少虚拟机的攻击面|

在这些示例中，像“我想要虚拟机安全”这样宽泛、模糊的表述，通过更具体的描述可以分解为更小、可实现的工作。一个笼统的故事，如“使虚拟机安全”，可能会无限期地处于进行中状态，因为在这个标题下总是有更多的工作要做。

10. 验收标准

一个好的故事句子有助于明确工作的目标，而验收标准则提供了更详细的信息。验收标准用于验证是否达到了目标，帮助执行工作的人清楚知道预期结果，也有助于测试。

经典的验收标准格式是“给定/当/那么”格式：“给定（起始条件），当（动作或事件），那么（结束条件）”。

以下是基础设施故事验收标准的示例：
|故事|验收标准|
|----|----|
|监控服务器内存|给定任何角色的虚拟机，当CPU使用率超过95%并持续5分钟以上，那么发送监控警报|

graph LR
    A[定义用户故事] --> B[明确验收标准]
    B --> C[编写代码]
    C --> D[运行自动化测试]
    D -- 通过 --> E[部署到生产环境]
    D -- 未通过 --> C

综上所述，在软件系统的开发和维护过程中，从构建简单系统、管理技术债务、处理重大基础设施变更，到测试变更、合理安排人员角色以及清晰定义工作和验收标准，每一个环节都相互关联且至关重要。遵循上述原则和实践，能够帮助团队更高效地进行软件系统的开发和维护，提高系统的质量和可靠性，实现可持续、快速的工作节奏。