软件测试思考系列[1]:往持续交付的方向努力

发表于:2012-4-19 14:16

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:hackfisher    来源:51Testing软件测试网采编

分享:

  测试应该朝什么方向努力,怎样做才能避免陷入泥潭?产品不稳定的原因,粗略看上去,似乎是因为测试时间不够,测试不充分导致的,但是深入进去探讨会发现没有那么简单。这一篇文章就是探讨测试应该朝着什么目标去努力,而我在这半年的实践中选择的是持续交付的方向,下面就介绍介绍持续交付。

  首先,如果测试不能从产品周期的一开始就参与进去,后期等产品快发布前再测试,会面临很大的问题。工作量大不谈,如果发现了BUG,开发的修复时间也不够了,更不要说可能产生严重的架构问题,或者功能和需求不符问题。

  其次,现在很多软件公司所面临的问题,就是“铁路警察,各管一段”的问题,推诿职责,测试并不是银弹,不能解决全部问题,所以很大程度上需要责任共担。但这个东西是说起来容易做起来难的一件事情,当一个问题,你无法快速定位导致它的真正原因的时候,就无从谈起问责。想要做到快速定位,将定位问题原因的难度降低,一个很重要的原因是快速反馈,功能越早的被测试,问题就越容易被发现,也越容易被修复。做到这一点,主要就是靠持续集成,而持续集成就是持续交付的主要组成部分,原来听的比较多的也是“持续交付”,而持续交付的提出,更多的是为了解决所谓的“最后一公里”的问题,因为很多的BUG或者问题,需要延迟到用户真实的生产环境中去才能发现。很多做法,比如Alpha应用等等,都是往这个方面做得努力,就是不但要尽早的得到产品,还要尽早的部署。

  再三,上面一篇文章中提到的反馈影响图,也要求反馈的循环速度越快,换个意思表达,也就是持续的得到反馈,而只有真正集成或者交付后,才能得到有用的反馈。持续交付的概念,我最早是从InfoQ上的一篇演讲学习到的,在这之前其实我只了解过持续集成。这个演讲(包括视频和PPT)的题目是让持续交付成为可能,不仅探讨了概念,还通过真实案例分享,与听众一起回顾某产品团队如何从传统开发走向持续交付。讨论在产品交付中如何应用DevOps原则(协作、自动化、度量和信息共享),达到快速且可靠地发布高质量的软件,同时描述过程中遇到的难题及解决方案,并进一步探讨持续交付的意义。很幸运看到这个演讲,开启了我的持续交付实践之路,在这里要感谢作者,带给我很多灵感和指导方向。(当时立马将这个演讲分享给团队成员,附带一句:“看了这个视频并且理解了的家伙,不谢我绝对没人性”)关于持续交付,还有一本不得不介绍的好书,《持续交付》,配置管理,部署流水线等十分有用的概念,都是从这本书获得的,强烈推荐。

  持续交付是什么样的?

  软件的发布过程必须是可重复、可信赖的

  把几乎所有的环节都做成自动化

  把所有的内容都纳入版本控制

  让痛苦提前,并不断练习

  内建质量

  “完成”就意味着“已发布”

  所有人对交付负责

  持续改进,需要耐心

  持续集成借鉴了敏捷思想,打破了用户、开发和测试之间的隔阂,实现了团队的协作。而最近出现的DevOps则借鉴了敏捷思想,将敏捷原则应用于运维领域,使交付团队与运维团队建立起更紧密的合作关系。所以这里如果只介绍持续交付,而不介绍敏捷思想就过意不去了。 2001年2月11日到13日,17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟(Snowbird)雪场。经过两天的讨论,“敏捷”(Agile)这个词为全体聚会者所接受,用以概括一套全新的软件开发价值观。这套价值观,通过一份简明扼要的《敏捷宣言》,传递给世界,宣告了敏捷开发运动的开始。

  敏捷软件开发宣言

  我们一直在实践中探寻更好的软件开发方法,身体力行的同时也帮助他人。由此我们建立了如下价值观:

  个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划

  也就是说,尽管右项有其价值,我们更重视左项的价值。

相关链接:

软件测试思考系列[0]:概述

《2023软件测试行业现状调查报告》独家发布~

精彩评论

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号