业务应用的自动化测试与 CI/CD：从容且可预测的发布

每位用过定制应用的企业主都熟悉这种焦虑：开发团队刚刚加了一个小功能，第二天没人动过的另一个部分却突然坏了。销售报表的数字变了，付款按钮点不动了，或者通知不再发送。修复随之而来，但信任一点点被侵蚀。

原因几乎总是一样的。软件是由相互依赖的部分组成的网络，对一个部分的改动可能在无人察觉的情况下影响另一个部分。每次变更后都手工测试，既耗时又容易遗漏，而且随着应用变大越来越不可能做到。

自动化测试和持续集成与交付（通常缩写为 CI/CD）正是应对之道。本文用通俗的语言解释这些概念，说明究竟测试什么，健康的交付流程是什么样子，以及非技术出身的企业主如何判断供应商或内部团队是否正确地实施了这些做法。

摘要

• 自动化测试一遍又一遍地执行相同的检查，不会疲倦也不会遗忘
• CI/CD 在每次变更时、到达用户之前运行这些检查
• 不是所有东西都需要测试，优先测试对业务最关键的流程
• 逐步发布和回滚的能力降低发布风险
• 用简单的指标衡量，不要把覆盖率数字当作目标

要解决的问题

没有自动化测试，质量取决于人的记忆和细致。即使是经验丰富的开发者，也无法记住一个已有多年历史的应用中所有的关联。手工测试人员可以检查主要流程，但无法在每次小改动后重复数百个场景。

结果是团队变得不敢改动任何东西。小修复被推迟，新功能因极度谨慎而进展缓慢，发布排得很稀疏，因为每次发布都让人觉得有风险。讽刺的是，稀少而庞大的发布比频繁而细小的发布更危险。

自动化测试扭转了这种局面。有了可靠的安全网，团队敢于修改、整理和添加。速度提升是因为信心提升，而不是因为大家工作得更仓促。

什么是自动化测试

自动化测试是用来检查其他代码的代码。例如，一个测试把三件商品放进购物车，应用折扣码，然后确认显示的总额符合预期。这样的测试可以在几秒或几分钟内运行成千上万次，结果始终一致。

测试通常按范围分组。了解这些分组，有助于你判断团队的测试策略是否合理，还是有所偏颇。

单元测试

单元测试孤立地检查小段逻辑，例如税额公式、折扣计算或运费确定规则。运行快、维护便宜，因此适合复杂且经常变化的业务规则。

集成测试

集成测试检查多个部分是否能正确协同工作，例如应用与数据库通信，或订单系统调用支付服务。许多真正的问题就藏在这里，因为错误往往出现在各部分的衔接处。

端到端测试

端到端测试模仿真实用户的行为：打开页面、填写表单、点击按钮并检查结果。它们更慢也更脆弱，因此只应用于最重要的流程，如注册、购买和付款。

用简单的话说，什么是 CI/CD

持续集成意味着每次代码变更都频繁地合并到主代码库中，每次合并都会触发一系列自动检查：构建应用、运行测试，以及检查编码风格和常见的安全问题。如果有什么失败，开发者几分钟内就会知道，而不是几周后。

持续交付或部署把这个想法延伸到发布阶段。所有检查通过后，应用可以用每次都相同的自动步骤发送到测试环境，或直接发给用户。不再有只有一个人知道、靠手工完成的发布流程。

对业务的好处是实在的。发布变得无聊，这是好的意义上的无聊：频繁、细小且可预测。出现问题时，因为改动小，原因容易追查，回滚也能迅速完成。

健康的交付流程

1. 01开发者在单独的分支上处理变更，而不是直接改主代码
2. 02变更在合并之前提交给同事评审
3. 03自动化测试运行，必须通过后才允许合并
4. 04应用被构建并发送到与生产环境相似的测试环境
5. 05如果变更有风险，则进行额外检查或审批
6. 06向生产环境的发布自动、逐步地进行，并可快速回滚
7. 07监控在发布后确认应用健康，出现症状时通知团队

并非每个团队都需要从第一天起就实施全部。小企业可以从两件事开始：对最重要流程的自动化测试，以及一条每次都以同样方式构建和发布应用的命令。

最值得先测试什么

一种常见的诱惑是追逐高覆盖率，即被测试触及的代码百分比。这个数字容易计算，却不能保证质量。大量不检查重要内容的测试，只会带来虚假的安全感。

更有用的方法是问：哪个部分坏了损失最大？从那里开始。对网店来说，通常是支付流程、价格和折扣计算、库存扣减以及确认邮件的发送。对 ERP 来说，则是库存估值、自动分录和访问权限。

• 涉及金额的计算：价格、折扣、税费、运费和四舍五入
• 产生收入的流程：注册、结账、付款和计费
• 访问权限规则：谁可以查看和修改什么
• 与关键外部方的集成，如支付和物流
• 以前发生过的缺陷：每发现一个缺陷，就添加一个测试，避免重演

最后一个习惯非常有价值。没有测试就修复的缺陷，总有一天会卷土重来。随测试一起修复的缺陷则成为永久的保护，久而久之，测试集合反映了你产品的真实经历。

测试环境与安全的数据

有意义的测试需要一个与生产环境相似却又独立于它的环境。测试应用应使用测试数据库和第三方服务的测试版本，这样错误就不会向真实顾客发送邮件或扣除真实余额。

要小心数据。在没有保护的情况下把真实顾客数据复制到测试环境，会带来隐私风险。使用专门制作的样例数据，或经过脱敏的真实数据。除了更安全，人造数据还让团队可以有意制造在生产中很少出现的边界情况。

也要确保访问密钥和服务密码等机密不写在代码里，也不随意存放在自动化流程中。把它们存放在专门设计的地方，限制访问并保留审计记录。

逐步发布与回滚能力

无论测试多么出色，总有些东西只有在现实世界中才会被发现。因此发布策略与测试同样重要。逐步发布技术先把新版本发送给一小部分用户，监控结果，如果安全再扩大范围。

功能开关允许一个功能在关闭状态下就发送到生产环境，然后为特定群体开启，或在出问题时立即关闭，无需重新发布。这把发送代码的技术决定与启用功能的业务决定区分开来。

同样重要的是快速且经过演练地回到上一个版本的能力。问问团队：如果今天的发布出了问题，多久能恢复到健康状态，这是否曾经尝试过？从未演练过的回滚流程，往往在需要的时候失灵。

非功能测试：速度、安全与兼容性

功能正确的应用，如果缓慢、易受攻击，或在某些设备上显示错乱，仍会让人失望。其中一些检查可以在同一个流程中自动化。

• 页面速度和体积上限检查，避免性能悄悄下降
• 对应用所用第三方库的漏洞扫描
• 对重要页面的基本无障碍检查
• 在几种屏幕尺寸和顾客最常用的浏览器上进行显示测试
• 大型活动或旺季之前做简单的负载测试

并非每次变更都要做全部。有些可以安排为每日一次，或在大型发布之前进行。重要的是有结构化的检查，而不是寄希望于一切安好。

代码评审是补充

自动化测试回答已知的行为是否仍然正确。同事的代码评审回答另一些问题：方法是否合理，下一个人是否容易理解，以及是否存在作者没想到的风险。二者相辅相成，与在生产环境中修复问题相比，成本都很低。

评审还传播知识。当每次变更都有两个人看过，就不会有应用的哪一部分只有一个人懂。这对业务很重要，因为对单个开发者的依赖是一种风险，常常要等到那个人休假或离职时才会被感受到。

现实的成本与收益

自动化测试需要前期投入：编写测试、搭建环境和构建发布流程的时间。对于新功能，工作会显得略慢一些。这笔成本是真实的，应该与团队或供应商坦率讨论，而不是隐瞒。

收益会随时间显现：更少的生产故障、更快的修复、更频繁的发布，以及不害怕修改旧代码的团队。对于将使用多年的应用，这项投入几乎总能收回。对于短期原型，较轻量的做法是合理的。

关键在于比例。并非每个部分都需要同样严格的测试。对高价值且经常变化的部分更认真地保护，并接受简单且很少变化的部分可以测得更轻一些。

手工测试仍有一席之地

自动化并不取代人。判断一个流程是否令人困惑、文字是否清楚、设计是否舒适，仍然需要人的眼睛。有针对性地进行的手工测试，例如在大型发布之前，是对自动化测试的补充。

业务用户的验收测试同样不可替代。只有每天运营的人，才能判断所构建的功能是否真正解决了问题。自动化把他们从检查例行事项中解放出来，让他们专注于有意义的判断。

企业主如何判断这种实践是否健康

你不需要读代码来判断。向供应商或内部团队提几个简单的问题，就能得到很多信息。

• 应用多久发布一次，从变更完成到触达用户需要多长时间？
• 在变更被允许合并之前，会自动发生什么？
• 如果发布出了问题，多久能回退，上次演练是什么时候？
• 他们如何确保支付流程和金额计算不会出错？
• 测试环境中的机密和顾客数据如何受到保护？
• 发现缺陷时会怎么做，才能避免重演？

具体且可衡量的回答表明实践成熟。含糊的回答，比如我们总是小心地测试，则表明质量取决于个人的细心，而不是流程。

常见错误

• 追求高覆盖率，却没有确保测试检查的是重要内容
• 放任经常无故失败的测试，导致团队忽略全部测试
• 在还没有像样的测试基础之前就搭建复杂的发布流程
• 业务规则变化时不更新测试
• 把机密保存在代码里或许多人可访问的文件中
• 把自动化测试当作代码评审和监控的替代品

本周就能开始的第一步

1. 01列出坏了损失最大的五个流程，从付款到主要报表
2. 02请团队在开发新功能之前，先为这些流程编写自动化测试
3. 03确保有一条命令或一个按钮，以同样的方式构建并发布应用
4. 04在测试环境中演练一次发布回滚流程
5. 05确立习惯：每修复一个缺陷，都必须附带相应的测试

结语

自动化测试和 CI/CD 并不是大型科技公司的奢侈品。对依赖应用的企业来说，这些做法能让必要的变更不致变成令人畏惧的风险。成果是更频繁、更平静、更可预测的发布。

从简单做起：保护最重要的流程，使发布自动化，并养成从每个问题中学习的习惯。久而久之，信任自己安全网的团队会行动得更快，并以更少的意外为顾客带来新的价值。