2014软件测试系列思考.docVIP

软件测试思考系列[1]：往持续交付的方向努力 测试应该朝什么方向努力，怎样做才能避免陷入泥潭？产品不稳定的原因，粗略看上去，似乎是因为测试时间不够，测试不充分导致的，但是深入进去探讨会发现没有那么简单。这一篇文章就是探讨测试应该朝着什么目标去努力，而我在这半年的实践中选择的是持续交付的方向，下面就介绍介绍持续交付。 　　首先，如果测试不能从产品周期的一开始就参与进去，后期等产品快发布前再测试，会面临很大的问题。工作量大不谈，如果发现了BUG，开发的修复时间也不够了，更不要说可能产生严重的架构问题，或者功能和需求不符问题。 　　其次，现在很多软件公司所面临的问题，就是“铁路警察，各管一段”的问题，推诿职责，测试并不是银弹，不能解决全部问题，所以很大程度上需要责任共担。但这个东西是说起来容易做起来难的一件事情，当一个问题，你无法快速定位导致它的真正原因的时候，就无从谈起问责。想要做到快速定位，将定位问题原因的难度降低，一个很重要的原因是快速反馈，功能越早的被测试，问题就越容易被发现，也越容易被修复。做到这一点，主要就是靠持续集成，而持续集成就是持续交付的主要组成部分，原来听的比较多的也是“持续交付”，而持续交付的提出，更多的是为了解决所谓的“最后一公里”的问题，因为很多的BUG或者问题，需要延迟到用户真实的生产环境中去才能发现。很多做法，比如Alpha应用等等，都是往这个方面做得努力，就是不但要尽早的得到产品，还要尽早的部署。 　　再三，上面一篇文章中提到的反馈影响图，也要求反馈的循环速度越快，换个意思表达，也就是持续的得到反馈，而只有真正集成或者交付后，才能得到有用的反馈。持续交付的概念，我最早是从InfoQ上的一篇演讲学习到的，在这之前其实我只了解过持续集成。这个演讲(包括视频和PPT)的题目是让持续交付成为可能，不仅探讨了概念，还通过真实案例分享，与听众一起回顾某产品团队如何从传统开发走向持续交付。讨论在产品交付中如何应用DevOps原则（协作、自动化、度量和信息共享），达到快速且可靠地发布高质量的软件，同时描述过程中遇到的难题及解决方案，并进一步探讨持续交付的意义。很幸运看到这个演讲，开启了我的持续交付实践之路，在这里要感谢作者，带给我很多灵感和指导方向。(当时立马将这个演讲分享给团队成员，附带一句：“看了这个视频并且理解了的家伙，不谢我绝对没人性”)关于持续交付，还有一本不得不介绍的好书，《持续交付》，配置管理，部署流水线等十分有用的概念，都是从这本书获得的，强烈推荐。 　　持续交付是什么样的？ 　　软件的发布过程必须是可重复、可信赖的 　　把几乎所有的环节都做成自动化 　　把所有的内容都纳入版本控制 　　让痛苦提前，并不断练习 　　内建质量 　　“完成”就意味着“已发布” 　　所有人对交付负责 　　持续改进，需要耐心 　　持续集成借鉴了敏捷思想，打破了用户、开发和测试之间的隔阂，实现了团队的协作。而最近出现的DevOps则借鉴了敏捷思想，将敏捷原则应用于运维领域，使交付团队与运维团队建立起更紧密的合作关系。所以这里如果只介绍持续交付，而不介绍敏捷思想就过意不去了。 2001年2月11日到13日，17位软件开发领域的领军人物聚集在美国犹他州的滑雪胜地雪鸟（Snowbird）雪场。经过两天的讨论，“敏捷”（Agile）这个词为全体聚会者所接受，用以概括一套全新的软件开发价值观。这套价值观，通过一份简明扼要的《敏捷宣言》，传递给世界，宣告了敏捷开发运动的开始。 　　敏捷软件开发宣言 　　我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观： 　　个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 　　也就是说，尽管右项有其价值，我们更重视左项的价值。 软件测试思考系列[2]：提交测试 　对于开发活动来说，代码提交是一个很重要的事件，代码变更被提交到版本控制服务器后（成为一次revision），意味着该变更的影响范围从该开发人员自己推广到了更广阔的范围： 　　其他开发人员将可以通过update代码将该变更合并到自己的变更中去，影响到其他开发人员的修改； 　　测试人员将可以从版本控制服务器上通过构建并得到结果，对合并该变更后的产品进行测试； 　　其他的试用，需求验收人员都可以看到该变更的变化和影响，如果在开发环境中看，则太麻烦了，对于不懂技术的人来说门槛太高。 　　因为持续集成意味着“完成”即“以发布”，所以这次提交的变更很有可能会影响到最终使用这个产品的用户。 测试中有一个非常重要的经济学原则：产品问题或者BUG被发现的越早，其被修复的成本就越低。所以说，提交测试是一个非常重要和有价值的阶段，如果不能被充分利用起来那就太浪费了