软件研发模式
早在70年代，美国NASA开展阿波罗登月计划，大型软件研发项目就开始开展了，那个时候的软件交付周期长达数年，经过严密评审的需求计划，以及开发设计文档，以及各类技术规范书，形形色色的文档，长达几千页到上万页，软件进入测试阶段之后，需要经历三到五轮甚至更多的测试才能交付到客户手中。
这种研发模式早期被称为“瀑布研发模式”，到了201x年，仍然有一些 ToB 的项目是采取这种长线作战的方式。
严格来说，瀑布研发模式没有消失，但是，随着 web 和移动应用的兴起，人们逐渐发现了长线作战的瀑布模式很难适应日新月异的互联网世界。
瀑布模式的缺陷
互联网世界的用户是一个庞大又差别甚大的群体，有别于企业客户，只需征服少数几个掌握权力的高管，就可以用定义清晰的开发文档启动一个长达数年的项目，Web的用户是一个复杂的群体，有时候连他们自己都不了解自己。设想，如果某产品人员声称他某一时刻掌握了用户所有的特征，使得他可以写出一定能够赢得市场的策划案，那将是灾难性的，这种自负通常只是为了赢得短期的信任。
如今，这种事先确定的一切的做法几乎绝迹，正是因为人们在过早下结论这个错误上付出了太多的代价。
90年代，XXX 在做黄了一个叫做的项目的时候，痛定思痛开始反思总结，最终在2000年左右在自己的博客上提出了敏捷开发的思想。
这些思想可以看做是一个软件开发的方法论，或者称之为理念。
它被命名为“敏捷开发”，正是因为某某认为XX项目最大的失败是没有及时发布版本去试探市场的反应，以及太少的集成积累了大量的bug，严重托缓了研发的进程。
敏捷开发
持续集成
将程序员生产的代码提交到仓库，启动编译，会发现新代码与旧代码的是否融合，并且测试人员马上可以验证新特性。
这种集成编译构建能够提早发现系统问题的方法在90年代就被发现。
既然集成可以提前发现问题，提前发现问题又是一件好事，那么为什么不多多益善呢？
于是最早的用脚本写就的集成脚本就诞生了，它们是一个定时触发，或者满足特定条件被触发的脚本程序。这可能是最早的持续集成。
什么是持续集成
DevOps 的由来
测试人员如何开展持续集成
从上面的简介我们发现，持续集成的核心，就是自动化测试——注意自动化测试和测试自动化二者的区别——自动化测试的健壮性和可靠性很大程度决定了研发迭代的速率。
研发效能的度量，一般会使用一个Leadtime的东西来衡量。
效能本是一个物理概念。用在研发中，它指的是一个需求从被提出到最终交付的时间。
研发的流程大致如下：
需求阶段——产品提出需求，定义事情，给出产品的特性描述，并和研发人员进行勾兑，删去不可行的部分，修复一些逻辑漏洞等等。在需求阶段，软件的缺陷就开始诞生。
编码阶段——需求经过最终定义以后，投入研发阶段。这个阶段会产生大量的软件缺陷，这些缺陷有一部分是编译器发现，在编译阶段被工具找出，有一部分是程序员写的单元测试拦截，有一部分是自己CR自己的代码发现；一个具有良好质量意识的程序员会在编码阶段将多数bug截留在自己的领地内，流到下一阶段的bug只占很少的部分。
测试阶段——研发人员将开发的特性流转到测试人员，测试人员根据产品的需求定义和开发的技术设计文档作为测试输入进行测试，当然也包括一些公共的约定——比如，系统不能崩溃，用户界面不能出现一些程序员才能看懂的提示和乱码，程序不可以内存无限增大，不能占用过多的操作系统的资源等等，这些都是不言自明的。
发布阶段——测试完成后，团建交付到客户手中，这个过程统称为发布阶段。一般互联网产品的发布阶段可以看成是一个质量右移的过程。换言之，测试阶段结束之后，质量保障活动并没有结束。在发布阶段，核心的指导思想就是，默认产品可能出现任何纰漏，但是任何纰漏都能得到最快的修补——当然我们希望发布阶段的错误不是太多，否则就是前面的几个阶段没有做好。
整个过程的耗时包括流转停顿的时间的总和就是一个需求的leadtime。
leadtime越短说明研发效能越高。
研发效能的双环模型
为了得到更好的leadtime， 人们发现必须在产品研发的各个环节有一个快速流转的机制，每个阶段都有可能产生bug，每个阶段都会发现bug，持续集成的理念是，通过工具和文化等方式，尽快将软件的缺陷发现并报告。因此有些步骤的自动化成了必须要做的环节。
- 持续的构建和可验证的产品包
- 单元测试在每次合并主干时被执行
- 历史的自动化用例在每个变更集成到主干时得到执行
看似很简单的几个步骤，想要做到顺滑，流畅，却不是那么容易。其中最艰难的部分无疑就是两个部分的自动化
- 单元测试
- 集成测试
关于单元测试在国内的争论由来已久，在湾区早已是工人的工程师文化，而在中国软件界仍然有许多不同的声音
大致分成三派
支持
反对
折中对待
笔者认为，没有单元测试，持续集成实际上没有灵魂，只是一条自动编译自动部署的流水线——这也是大多数中小企业的持续集成现状。
集成测试自动化
这部分就更为艰难。
实践中常见的窘境——集成测试连自己人都怀疑，一出错测试人员第一时间想到的是，是不是环境又挂了，自己的框架不稳定，或者是用例写的不对。
出现这种窘境的原因通常有几方面的原因：
测试人员经验不足，由于早期测试人员缺少正规的训练机制，大多数人都是一边做一边成长，对于用例的鉴赏没有太多历史沉淀，导致很多人不知道什么样的用例是好的用例，因此很容易写出维护麻烦的用例。
有的人试图用自动化用例取代人工，流行在测试圈的一种理念认为——自动化的目标是为了节省人工，提升测试效率。——这么看是对的，但放在持续集成里，又不那么对——如果用节省测试人力的观念去看自动化测试，不免就容易早就前述那种自动化用例失去公信力的窘境。
一方面，为了省力，测试恨不得将测试活动中的每一步都翻译成脚本，不遗漏每个验证点，这样的结果是，用例永远跟不上代码的变更。这种滞后性，必然带来开发对错误用例的漠视。
另一方面，复杂的长流程用例将用例的不稳定性逐步放大，越来越多的自动化测试人员卷入这场用例维护的泥淖中。
随着项目成熟期到来，自动化还是没有在持续集成中展现价值，项目经理就会怀疑自动化测试的价值，最后不得不削弱自动化测试的投入，同时对持续集成的认知可能就停在，自动构建和部署上了。
单元测试的困境，我认为多少和集成测试面临的问题是基本一致的——那就是，人们很难写出易于维护的用例。
如果编写可以用于持续集成的用例，这是一个很大的问题。
网友评论