软件测试系列思考.docVIP

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