BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

你在过度测试你的软件吗?

| 作者 谢丽 关注 9 他的粉丝 发布于 2015年7月17日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

发布候选测试需要花费很长时间,这是许多敏捷团队都面临的一个最大的挑战。但据JavaWorld报道,许多公司都通过持续交付模型消除或极大地减少了发布候选测试,而且它们有一些共性:

  • 使用测试工具:有许多测试工具可以执行软件,贯穿软件的基本流程。因此,选择恰当的自动化检查工具非常关键,而其目标是降低风险,快速执行,减少手工维护的工作量。
  • 将工具钩连到构建系统:等待构建完成再手工执行检查会浪费大量的时间,而在每次构建时自动检查可以消除这种浪费,最好是有一个自动化的检出/构建/部署/测试/推广管道。
  • 从根本上消除回归错误:利用减少发布候选测试节省出的时间改进开发实践。
  • 开发可单独部署的组件:借助组件,每个变更都是相互隔离的。变更影响范围小,降低了部署风险,使得部署或回滚过程更可控。
  • 根据风险划分测试/部署策略:不同的功能可能需要不同的测试策略或过程,高风险、发布频率低的变更可能需要更严格的测试过程。Zappos(Amazon的一个部门)很久之前就采用了这种方式
  • 持续监控生产环境:缺陷代码在生产环境中存在的时间越长造成的损害越大。如果团队可以快速发现并修复缺陷,那么风险将大大降低。
  • 自动部署和回滚:通过几次点击就可以实现部署或回顾。
  • 配置标识:程序员在编码时将新特性封装在一个if()语句中,然后就可以通过将配置标识设置为“On”或“Off”来启用或关闭特性。感兴趣的读者可以阅读下这篇文章
  • 增量滚动发布:将配置标识与不同的用户关联,就可以实现为不同的客户提供不同的功能。感兴趣的读者可以看下微软的做法

当然,并不是在任何情况下都可以消除发布候选测试。在某些情况下,需要在测试时间和发布风险之间进行权衡。也就是说,要根据风险制定灵活的发布候选测试策略。

对于JavaWorld的报道,有网友提出了不同的意见。Steve Naidamast认为:

这个消除或减少应用程序的建议跟实际的测试过程一样复杂,甚至更复杂……此外,由于能力的不足或工具的缺陷……,会引入新的问题……

而网友Chris Riley则认为该报道具有误导性:

第一,它没有建议我们减少测试,而只是将测试移到了管道中的不同位置。第二,持续交付并不适合所有人……这看上去是个不错的理想,但可能会误导R&D主管在没有备用计划的情况下错误地削减了QA职位。


感谢徐川对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ@丁晓昀),微信(微信号:InfoQChina)关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入InfoQ读者交流群InfoQ好读者)。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT