发布候选测试需要花费很长时间，这是许多敏捷团队都面临的一个最大的挑战。但据 JavaWorld报道，许多公司都通过持续交付模型消除或极大地减少了发布候选测试，而且它们有一些共性：
- 使用测试工具：有许多测试工具可以执行软件，贯穿软件的基本流程。因此，选择恰当的自动化检查工具非常关键，而其目标是降低风险，快速执行，减少手工维护的工作量。
- 将工具钩连到构建系统：等待构建完成再手工执行检查会浪费大量的时间，而在每次构建时自动检查可以消除这种浪费，最好是有一个自动化的检出 / 构建 / 部署 / 测试 / 推广管道。
- 从根本上消除回归错误：利用减少发布候选测试节省出的时间改进开发实践。
- 开发可单独部署的组件：借助组件，每个变更都是相互隔离的。变更影响范围小，降低了部署风险，使得部署或回滚过程更可控。
- 根据风险划分测试 / 部署策略：不同的功能可能需要不同的测试策略或过程，高风险、发布频率低的变更可能需要更严格的测试过程。 Zappos（Amazon 的一个部门）很久之前就采用了这种方式。
- 持续监控生产环境：缺陷代码在生产环境中存在的时间越长造成的损害越大。如果团队可以快速发现并修复缺陷，那么风险将大大降低。
- 自动部署和回滚：通过几次点击就可以实现部署或回顾。
- 配置标识：程序员在编码时将新特性封装在一个
if()语句中，然后就可以通过将配置标识设置为“On”或“Off”来启用或关闭特性。感兴趣的读者可以阅读下这篇文章。 - 增量滚动发布：将配置标识与不同的用户关联，就可以实现为不同的客户提供不同的功能。感兴趣的读者可以看下微软的做法。
当然，并不是在任何情况下都可以消除发布候选测试。在某些情况下，需要在测试时间和发布风险之间进行权衡。也就是说，要根据风险制定灵活的发布候选测试策略。
对于 JavaWorld 的报道，有网友提出了不同的意见。Steve Naidamast 认为：
这个消除或减少应用程序的建议跟实际的测试过程一样复杂，甚至更复杂……此外，由于能力的不足或工具的缺陷……，会引入新的问题……
而网友 Chris Riley 则认为该报道具有误导性：
第一，它没有建议我们减少测试，而只是将测试移到了管道中的不同位置。第二，持续交付并不适合所有人……这看上去是个不错的理想，但可能会误导 R&D 主管在没有备用计划的情况下错误地削减了 QA 职位。
感谢徐川对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入 InfoQ 读者交流群
）。
暂无签名
最新发布
Quora 文本语境演进分析
2015-12-21
使用 API 网关构建微服务
2015-07-21
Oracle 专家谈 MySQL Cluster 如何支持 200M 的 QPS
2015-07-02
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
Vue 中的 TypeScript 支持
Kotlin/WebAssembly 的探索之路
降本增效下 Kafka 的稳定性实践
评论