8.5 测试与流程自动化

概述与动机

测试与流程自动化，是用可靠的、由机器执行的工作流，取代重复性的手工工程和运维工作的实践。在测试这一侧，这意味着测试自动化：持续运行的自动化测试套件，用来验证正确性、性能和安全性。在流程这一侧，它延伸到软件交付和运维周边的机制：收集合规证据、执行运维操作手册、修复已知问题，以及执行治理、安全和成本控制。统一的理念很简单：任何被重复、可预测地执行的事情，都应该被编码下来，这样它才能一致、快速地运行，而不消耗人力去反复劳作。

对大型团队而言，自动化是防止质量和管控在规模扩大时崩溃的唯一方法。手工测试跟不上数百名工程师做出的成千上万次改动的节奏，它会成为瓶颈，其覆盖率也会变得不一致、不可靠。手工运维流程同样如此：当疲惫的人在庞大的体系中、在压力之下去重启一个服务、轮换一个凭证、收集审计证据时，这些操作都会变得缓慢且容易出错。把这些工作自动化，能让结果变得可重复，也能让熟练的工程师腾出手来，专注于那些真正需要人类洞察力的、判断密集型的问题。

在企业和政府场景中，自动化也是让合规可持续的关键。受监管的组织必须持续证明各项控制措施到位、证据已被收集。靠人工来做这件事既昂贵又缓慢，还容易出现遗漏。把证据收集和控制执行自动化，能把合规从一场周期性的消防演习，变成系统的一项持续的、可验证的属性。这种”合规即代码”的方法，既降低了成本，又增强了审计人员和监管者所要求的那份保障。

关键原则

自动化那些重复的、可预测的、基于规则的工作；把人力留给需要判断力的地方。
让自动化测试快速、可靠、确定，否则它们会被无视。
让测试并行运行，并尽早介入，这样随着测试套件不断壮大，反馈依然能保持迅速。
把运维流程编码为操作手册即代码，让它们可版本化、可测试、可执行。
优先选择集成良好的自动化，而不是从外部硬套到系统上的脆弱脚本。
把合规证据的生成，变成正常工作流的自动副产品。
对高风险操作保留人工介入环节；先自动化那些安全、常规的部分。

建议

构建快速、可靠、并行的测试基础设施

一个测试套件只有在工程师信任它、并且它能快速返回反馈时，才有价值。要投资于能在众多工作节点上并行运行测试套件的测试基础设施，这样即使测试数量增长到成千上万个，总耗时依然保持低位。把测试套件构建成一个金字塔结构：大量快速的单元测试，较少的集成测试，以及少量的端到端测试。这样大多数反馈都能在几秒钟内送达。要毫不留情地消除不稳定的测试。一个间歇性失败的测试比没有测试还糟糕，因为它会训练工程师去无视失败。提供临时的、按需创建的测试环境，让集成测试和端到端测试能在真实、隔离的基础设施上运行。

让发布、合规和证据收集自动化

把自动化从测试延伸到发布和合规工作流中去。让流水线自动生成审计人员所需的各类产物：谁批准了某次改动的记录、运行并通过了哪些测试、安全扫描发现了什么，以及究竟部署了哪个版本的产物。把控制措施当作代码来对待，这样必需的检查才能被统一执行，其结果也会被记录下来。这种”合规即代码”的方法，把证据收集从审计前的一场手忙脚乱，变成了一份持续的、始终最新的记录，也让系统的合规状态在任何时刻都是可观测的。

采用 ChatOps 和操作手册即代码

把运维流程编码为纳入版本控制的、可执行的操作手册，而不是会逐渐过时的散文式文档。对于安全且被充分理解的流程，把它接入自动化，使其能够按需运行。ChatOps 把这些操作带入共享的聊天界面，这样操作人员就能在一场透明、协作、有记录的对话中触发和观察自动化操作。这让运维操作对整个团队可见，并自动生成一份”做了什么”的记录。它也降低了经验较少的工程师安全地执行流程的门槛，因为自动化已经把正确的步骤编码了进去。

谨慎地实现自动化修复

对于被充分理解、反复出现的问题，构建自动化修复机制，让它检测到某个条件后应用一个已知的修复方案，比如重启一个失败的进程、在负载下扩容、清理一个已满的磁盘，或让某个组件故障转移。从低风险、高置信度的修复开始。对任何影响范围较大的操作，都要求人工确认。自动化修复能缩短平均恢复时间，消除重复告警带来的疲劳。但它必须建立在扎实的检测能力之上，并配有安全防护措施，因为一个基于错误信号采取行动的自动化，可能会放大一场事故。记录每一次自动化操作，让操作人员保持完全的可见性，并能够随时介入。

把机器人流程自动化（RPA）放在正确的位置上

机器人流程自动化通过操控现有的用户界面和应用程序来实现任务自动化，模仿人类会执行的点击和按键操作。RPA 有其合理的用武之地，可以作为一座桥梁，用于那些不暴露任何 API、也无法通过其他方式集成的遗留系统或第三方系统。在这类场景中务实地使用它，但要了解它的局限。由 UI 驱动的自动化本质上是脆弱的：只要界面一变化，它就会失效，而且它并没有解决底层集成缺失的问题。如果有正规的 API 或集成方式可用，就优先选择它。把 RPA 当作一种战术性的权宜之计，而不是一种战略性的基础，并计划在系统现代化改造的过程中把它替换掉。

让治理、安全和成本控制自动化

把组织层面的各项控制措施编码为持续运行的自动化检查：面向基础设施护栏的策略即代码、流水线中的自动化安全扫描，以及对成本异常和闲置资源的自动检测。把治理自动化，能让控制措施变得统一且无法绕过，还能扩展到人工评审永远无法覆盖的变更量级。执行安全策略的那套方法，同样可以用来标记一笔失控的云账单，或一个缺失的必需标签。治理由此从一场周期性的人工审计，转变为一道持续运行的自动化护栏。

权衡：优点与缺点

选择	优点	缺点	最适用场景
广泛的自动化测试	反馈快速、一致；使变更成为可能	构建和维护成本；不稳定的风险	所有规模化运作的团队
合规即代码	持续的、随时可供审计的证据	需要前期工程投入来将控制措施编码化	受监管的组织
操作手册即代码 + ChatOps	可重复、可见、有记录的操作	编码和维护的工作量	有真实运维负担的团队
自动化修复	恢复更快；劳作更少	检测出错时存在风险	被充分理解的、反复出现的问题
RPA（UI 自动化）	为没有 API 的系统架起桥梁	脆弱；掩盖了集成缺口	作为遗留系统的权宜之计
自动化治理	统一、无法绕过的控制措施	策略编写和调优的工作量	规模庞大、受治理的体系

核心的权衡在于前期投入与持续劳作和风险之间的取舍。自动化的构建和维护总是要花费精力。构建得糟糕的自动化（）无论是不稳定的测试、脆弱的 RPA，还是被错误信号触发的修复（）可能比什么都不做更糟，因为它会侵蚀信任，或放大故障。这里的纪律有三重：把真正可重复、可靠的事情自动化；投入精力让这些自动化值得信赖；并在需要判断力或存在高风险的地方保留人工介入。做得好，自动化会带来多倍的回报；做得草率，它自己就会变成一项负债。

与团队讨论的问题

你们的集成测试和端到端测试，运行在真实的、临时创建的环境上，还是运行在一个人人抢着用的共享预发布环境上？ 每个拉取请求都按需创建隔离环境，能让集成测试和端到端测试在真实的基础设施上运行，而不会让各团队互相阻塞或污染共享状态。随着越来越多的团队涌入，一个共享的预发布环境会变成瓶颈，也会成为不稳定、依赖执行顺序的失败根源。要决定你们能否按需创建临时环境、成本是多少，以及哪些测试真的需要它们，哪些可以用快速的内存替代方案代替。带上数据来讨论：预发布环境的争用频率有多高、有多少失败可以追溯到共享环境的相互干扰，以及集成测试层目前的总耗时。这个答案既会影响你们测试的可靠性，也会影响金字塔上层反馈返回的速度。
运维流程是否已经被编码为操作手册即代码，并通过 ChatOps 展示出来，还是仍然以会逐渐过时的散文形式存在？ 编码化、纳入版本控制的操作手册是可测试、可执行的，通过共享聊天界面运行它们，能让每一个操作都可见，并被自动记录下来。这降低了经验较少的值班工程师安全采取行动的门槛，因为自动化已经把正确的步骤编码了进去，而不再依赖只有少数人掌握的经验。要决定哪些流程足够安全、被充分理解，值得优先接入自动化，以及如何确保人类仍然能够介入。对于一个规模庞大的体系而言，这种透明度同时也是一份关于谁在何时做了什么的审计记录。带上你们目前的操作手册，标出哪些已经过时，并找出两三个使用频率最高、最值得优先编码化的流程。
在你们的流水线中，哪些安全扫描和策略检查会阻断合并，哪些只是发出警告？ 只有当控制措施无法被绕过时，自动化治理才值得构建，因为一个只是发出警告的检查，在截止日期的压力下会像一份维基百科上的策略文档一样被无视。要逐项决定哪些检查应该阻断、哪些只是警告：一个严重漏洞或一个缺失的加密标签大概应该阻断，而一个低严重性的风格问题可能只需警告。在规模化场景下，这正是你在人工评审无法覆盖的变更量级上统一执行安全和成本护栏的方式。带上你们目前的检查清单，把每一项标记为阻断型或建议型，然后讨论误报率，因为一个噪声很大的阻断型检查会训练人们不断要求例外豁免。阻断和警告之间的这条界线，决定了你们的治理是真有牙齿，还是形同虚设。
哪些自动化修复，我们愿意让它们在没有人工事先确认的情况下自行采取行动？如果检测出错，影响范围有多大？ 自动化修复能缩短恢复时间、减少告警疲劳，但一个被错误信号触发的修复，可能把一次小小的波动变成一场彻底的停机事故，所以”什么可以无人值守地运行”是一个风险决策，而不是一个便利性决策。要权衡相互竞争的拉力：无人值守的操作最快，但风险也最高；而人工在环确认更安全，却又重新引入了你原本想要消除的延迟和劳作。带上按频率和最坏情况下影响范围排序的候选修复方案、每一种方案背后检测机制的历史误报率，以及每一次操作是否都被记录且可回滚。对于大型企业或政府体系而言，凡是涉及生产数据或面向公民的服务的任何操作，都要额外制定正式的变更授权和回滚方案，因为一个无法被审计或撤销的自动化修复，正是监管者会强制你关闭的那种东西。
我们如何为维护自动化提供资金并指定所有权，从而防止它腐化为一项负债？ 测试、操作手册、策略检查和 RPA 机器人，都会随着周边系统的变化而逐渐腐坏，而被忽视的自动化比没有自动化还糟糕：一份过时的操作手册会在危机中带来虚假的信心，一个损坏的 RPA 机器人会悄无声息地漏掉工作。这里的张力在于，维护工作与功能开发竞争同一批工程师的时间，而且它在出问题之前是隐形的，所以它总是在截止日期压力下第一个被砍掉。带上目前自动化资产的清单、不稳定测试和损坏机器人的待办积压，以及一份诚实的估算，比较目前实际花在维护上的工程师工时与预算之间的差距。在企业或政府场景中，为每一项关键自动化指定负责的所有者，并把维护工作作为一个明确的预算科目，因为当一项无人维护的控制措施悄无声息地失效时，审计人员和事故复盘都会追问谁对此负责。
对于我们用 RPA 自动化的每一个遗留系统，退役这个 RPA、转向真正集成的具体计划和触发条件是什么？ 对于不暴露任何 API 的系统来说，RPA 是一座合理的桥梁，但一座没有退出计划的桥梁，会悄悄硬化成永久性的、脆弱的基础设施，在每一次 UI 变化时都会崩溃，并固化了它原本要跨越的那道集成缺口。这里的权衡是真实的：RPA 现在能快速、廉价地交付价值，而正规的 API 集成前期成本更高，但更为持久，所以正确的纪律是把 RPA 当作一笔有期限的借款，而不是一次性的购买。带上生产环境中 RPA 机器人的清单、每个机器人依赖的系统、每个机器人出故障的频率，以及底层系统的现代化改造或集成工作是否真的有拨款、有排期。对于背负着数十年历史核心应用的企业和政府体系而言，要把每一个 RPA 机器人与一个明确命名的现代化改造里程碑绑定，因为一个悄悄变得至关重要、却没有退役日期的 RPA，正是一项技术债务，而且它所抓取的界面每变化一次，这项债务就会复利式增长。

行业视角

初创企业。 只有两三名工程师、没有时间搭建基础设施，保持一个小型、快速的测试金字塔，让它在每次改动时几分钟内跑完，并把任何不稳定的测试当作真正的缺陷，在当周就修复或删除。跳过你还用不上的重型合规工具和策略即代码，只把你使用频率最高的两三个运维修复方案编码为可以从聊天界面触发的简单脚本。把消除日常劳作的事情自动化，抵制在你真正遇到治理问题之前就搭建治理机器的冲动。

小型企业。 没有专职的测试或平台专家，依靠你们已经付费使用的工具中内置的自动化能力：CI 服务内置的测试运行器、它的扫描插件，以及托管环境，而不是自建定制的测试基础设施。围绕你们真正能够维持的维护能力来权衡购买还是自建，因为一条没人能维护的巧妙自建流水线，其结果比一个朴素的托管方案更糟。谨慎使用 RPA，只在某个供应商工具能够为一个你无法通过其他方式集成的系统架起桥梁时使用它。

企业。 在众多团队之间，目标是在人工评审无法覆盖的规模上，实现统一、无法绕过的控制措施：共享的并行测试基础设施配合临时环境、策略即代码护栏，以及从每一次流水线运行中自动生成的合规证据。把接口标准化，让各团队复用修复和操作手册工具，而不是各自重复发明脆弱的脚本，并把自动化当作一个有明确维护预算、有专人负责的产品组合来管理。要留意一个在某个团队只是发出警告的检查，不会在另一个团队被当作阻断型来处理，因为不一致的执行会削弱你正在为之付费的那份保障。

政府。 采购规则、透明度义务和持续监控的要求，让合规即代码近乎成为必需品：每一次流水线运行都应该把检查过的控制措施、执行过的扫描，以及授予的批准，记录为一份防篡改、随时可供审计的证据。优先选择开放、可移植的自动化，而不是专有锁定，这样未来的合同才能转移到另一家供应商，并让某个具体的人对任何触及面向公民服务的修复操作负责。当一个使用了数十年的系统迫使你们采用 RPA 时，要把它记录为一座有意为之的临时性桥梁，并配有公开的现代化改造计划，在每一次变更中都把治理检查维持在强制要求的安全基线之上。

示例

初创企业。 一家七人规模的初创公司维持着一个精简的测试金字塔，大部分是快速的单元测试，外加少量集成测试，全部并行运行，所以在每一个拉取请求上，整个套件在三分钟以内就能跑完。一旦某个测试开始变得不稳定，他们就把它当作真正的缺陷，在当周就修复或删除，因为对这么小的团队来说，哪怕只有一次被无视的红色构建，也会侵蚀整个套件的信任度。他们还把两个最常见的运维修复（）重启一个卡住的工作节点、清理一个已满的磁盘（）编码为可以从 Slack 触发的小脚本，这样无论谁在值班，都能安全地运行它们，而不必去呼叫写这些脚本的那位工程师。

企业。 一家大型电商公司运行着一个包含数万个测试的测试套件，并在一批工作节点上并行化，使整个套件在几分钟内就能完成。每个拉取请求都会创建临时环境，用于真实的集成测试。运维操作通过 ChatOps 进行：值班工程师从聊天界面触发编码化的操作手册，像服务过载这样的常见故障会被自动修复，操作会被记录下来以供审查。流水线自动收集安全扫描和审批证据，因此年度审计依靠的是一份始终最新的记录，而不是一场手工找证据的行动。

政府。 一家受严格持续监控要求约束的公共机构，实现了合规即代码。每一次流水线运行，都会记录检查过的控制措施、执行过的扫描，以及授予的批准，生成一份能够随时满足审计人员要求的防篡改证据。由于其中一个核心系统是一个没有 API 的、有数十年历史的应用，该机构在现代化改造推进的同时，把 RPA 当作一座有意为之的桥梁，用来自动化向该系统录入数据的工作，并明确计划在正规集成建成后退役这个 RPA。自动化治理检查会在每一次基础设施变更中执行强制要求的安全基线。

商业理由：动机、投资回报率与总拥有成本

测试与流程自动化的投资回报，体现为被夺回的工程师时间、更快更安全的交付、更快的事故恢复，以及大幅降低的合规成本。自动化测试让快速、有信心的变更成为可能，而这正是交付绩效的基础。自动化的运维和修复减少了消耗团队和预算的劳作与停机时间。合规即代码可以把一场审计，从数周的手工准备变成一次日常查询，这既是财务上的节省，也是声誉上的节省。

总拥有成本的比较，权衡的是构建和维护自动化的真实持续成本，与不自动化的成本。手工测试和运维的成本，不只是所花费的工时。它还包括漏网的缺陷、拖得过长的事故、耗费专家人手的审计，以及从事重复性劳作的工程师所承受的倦怠。对领导层来说，这个论证很直接：自动化把持续发生的运维开支和风险，转化为一次性投入加上可扩展的维护投入，并让质量和合规从偶发事件变成持续状态。有一点值得明确指出：自动化必须被维护、被信任；没有资金投入、被忽视的自动化，会腐化为一项负债。

反模式与陷阱

容忍不稳定的测试。 间歇性的失败会摧毁信任，并训练工程师去无视红色结果。
把一个坏掉的流程自动化。 把一个糟糕的工作流自动化，只会让这团乱麻更快地发生；先修复流程本身。
把 RPA 当作战略。 依赖脆弱的 UI 自动化作为永久性解决方案，会掩盖并固化集成缺口。
没有扎实检测能力的修复。 被错误信号触发的自动化修复，可能会放大一场事故。
操作手册沦为过时的散文。 存活在过时文档中的流程，会在危机中带来虚假的信心。
手工收集合规证据。 周期性的手工证据搜寻成本高昂，且会在两次审计之间留下缺口。
高风险操作没有人工介入环节。 对危险操作的完全自动化，剥夺了防止灾难所需的判断力。

成熟度模型

第 1 级，启动。 测试和运维在很大程度上是手工且被动的。覆盖率是随意的，流程存在于人们的脑子里或过时的文档中，修复在事故期间靠人工进行，合规证据是在每次审计前手忙脚乱地拼凑出来的。

第 2 级，发展。 自动化测试已经存在，但速度慢、不稳定，或运行不一致，各团队之间的实践差异很大。一些运维脚本和操作手册在局部存在，但修复仍然是手工的，治理靠周期性评审来执行，而不是靠持续检查。

第 3 级，标准化。 快速、并行、可靠的测试基础设施是全组织范围内有文档记录的标准。操作手册即代码和 ChatOps 已被普遍使用，合规证据从流水线运行中自动生成，治理控制措施作为强制执行的自动化检查，在各团队之间一致地运行。

第 4 级，管理。 自动化本身也相对于基线被衡量和控制。你追踪不稳定测试的比例、测试套件的总耗时、自动修复事故的平均恢复时间、有自动化证据支撑的控制措施占比，以及阻断型检查的误报率，并将每一项指标对照商定的目标进行管理。修复和覆盖率决策由这些数据驱动，每一次自动化操作都被记录下来，让趋势和倒退变得可见，而不是靠猜测。

第 5 级，编排。 自动化在整个组织范围内持续改进、持续整合。自动化修复配有经过验证的安全防护措施，能够处理常规事故；合规持续进行，随时可供审计；测试、运维和治理工具链会随系统变化而适应，RPA 桥梁也会随着集成走向成熟而被主动退役。人类专注于判断，机器负责处理可重复的工作，整个系统依据证据不断重新平衡。

讨论话题

哪些运维流程可以安全地完全自动化，哪些必须保留人工介入环节？
随着测试套件不断壮大，你们如何保持它的快速和不稳定测试的绝迹？
在哪些地方，RPA 对你们的遗留系统而言是一座正当的桥梁？退役它的计划是什么？
哪些控制措施可以优先从人工审计转换为持续的合规即代码？
你们如何在不冒放大事故风险的前提下，建立对自动化修复的信任？
你们如何为自动化所需的持续维护提供资金，防止它腐化为一项负债？

关键要点

把重复的、可预测的、基于规则的工作自动化；把人力留给判断力和高风险决策。
让自动化测试快速、并行、可靠，并毫不留情地消除不稳定性。
把运维操作编码为操作手册即代码，并通过 ChatOps 展示出来，以保证可见性和留下记录。
自动生成合规证据，让审计依靠的是一份持续的、最新的记录。
只把 RPA 当作一座有意为之的、临时的桥梁，用于没有 API 的系统，并计划退役它。
把治理、安全和成本控制作为持续运行的自动化检查来执行，同时让人类监督其中的高风险操作。

参考资料与延伸阅读

Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams.
Jez Humble and David Farley, Continuous Delivery.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering（参见关于消除劳作的章节）。
Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate.
NIST Special Publication 800-53 and 800-137（持续监控）。
Open Policy Agent documentation（策略即代码）。