持续集成与测试自动化, CI, CD

CI, CD AND CD

CI很容易理解，就是持续集成。但是CD既可以指代码持续交付，也可理解为代码持续部署。CI和CD之间有很多相似的部分，但是也有很大的区别。

持续集成 (CONTINUOUS INTEGRATION)

在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。

持续交付 (CONTINUOUS DELIVERY)

持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。

通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。

但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。

持续部署 (CONTINUOUS DEPLOYMENT)

如果我们想更加深入一步的话，就是持续部署了。通过这个方式，任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预 (没有一键部署按钮) ，只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

持续部署是一个很优秀的方式，可以加速与客户的反馈循环，但是会给团队带来压力，因为不再有“发布日”了。开发人员可以专注于构建软件，他们看到他们的修改在他们完成工作后几分钟就上线了。基本上，当开发人员在主分支中合并一个提交时，这个分支将被构建、测试，如果一切顺利，则部署到生产环境中。

我从毕业到现在, 曾在大小不同的三个公司就职: 有民营的、有外资的、也有上市公司。 但以前大多都是做项目，从事软件开发工作，绝大部分公司对测试都不重视，即使有也没有成规模， 更谈不上建立测试体系。总之，重开发轻测试的管理思想在中国延续了几十年、并且还要继续，看看他们给测试工程师开的低工资和老师在课堂上讲到测试时一笔带过就知道测试被中国的老板所忽略。

最近两年,我从事CRM软件产品的测试、项目管理工作。 由于公司对软件的质量要求特别高， 这必然引起了大家对测试工作的重视，不但要求有强大的测试团队，该团队必须具备在业务方面、测试技能方面的专业水平， 而且在软件开发过程方面经常由于测试而作持续不断地调整。

幸运的是，随着软件开发技术和工具的提高，软件工程和软件过程实践的推广， 软件测试日益得到重视和专业化。 我从事测试工作期间，一直研究CMM、测试理论、自动化测试工具，并建立了一套完整的测试体系。

在此并不介绍整个测试体系，而是介绍测试方面最值得探讨的部分: 持续集成与测试自动化。目的是与大家共同进步。当然已经有很多关于持续集成和自动化测试方面的介绍,但我要介绍的不只是持续集成,也不只是自动化测试,而是测试如何的自动化.

二、测试自动化

自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软件质量的目的。自动化测试的目的在于发现老缺陷。而手工测试的目的在于发现新缺陷。

测试自动化涉及到测试流程、测试体系、自动化化编译、持续集成、自动发布测试系统以及自动化测试等方面整合。也就是说要让测试能够自动化，不仅是技术、工具的问题，更是一个公司和组织的文化问题。首先公司从资金、管理上支持您，其次要有专门的测试团队去建立适合自动化测试的测试流程、测试体系；其次就是把原代码从受控库中取出、编译、集成、发布可运行系统、进行自动化的单元测试和自动化的功能测试的过程。

(一) 、自动化测试的好处

  1. 对新版本执行回归测试－－测试每个特征

对于产品型的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试， 从而可以让测试达到测试每个特征的目的。

  1. 更多更频繁的测试－－沉闷、耗时

我们的产品向市场的发布周期是3个月，也就是我们的开发周期只有短短的3个月，而在测试期间是每天/每2天都要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，人工测试是非常的耗时和繁琐，这样必然会使测试效率低下。

  1. 替代手工测试的困难－－300个用户有些非功能性方面的测试: 压力测试、并发测试、大数据量测试、崩溃性测试，用人来测试是不可能达到的。 在没有引入自动化测试工具之前，为了测试并发，研发中心的一、两百号人在研发经理的口令: 1－、2－、3！， 大家同时按下同一个按钮。回想起这中情景也蛮有意思的。

  2. 具有一致性和可重复性

由于每次自动化测试运行的脚本是相同的, 所以每次执行的测试具有一致性, 人是很难做到的. 由于自动化测试的一致性，很容易发现被测软件的任何改变。

  1. 更好的利用资源－－周未/晚上

理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了开发和测试之间的等待.

  1. 解决测试与开发之间的矛盾

通常在开发的末期,进入集成测试阶段, 由于每发布一个版本的初期,测试系统的错误比较少,这时开发人员有等待测试人员测试出错误的时间. 事实上在叠代周期很短的开发模式中，存在更多的矛盾， 但自动化测试可以解决其中的主要矛盾。

  1. 增加软件信任度

总之，自动化测试的好处和收益是很明显的，但也只有顺利事实了自动化测试才能从中获得它的益处。

(二)、 自动化测试－－ 误区、限制自动化化测试好处很多，但也有很多的局限，也正因为很多老板对自动化测试的期望太高，所以有很多执行自动化测试失败的例子。

  1. 期望自动化测试能取代手工测试

不能期望自动化测试来取代手工测试， 测试主要还是要靠人工的。

  1. 期望自动测试发现大量新缺陷

同样不能期望自动化测试去发现更多新的缺陷， 事实证明新缺陷越多，自动化测试失败的几率就越大。发现更多的新缺陷应该是手工测试的主要目的。测试专家James Bach总结得 85%的缺陷靠手工发现，而自动化测试只能发现15％的缺陷。

其实我认为自动化测试能够很好的发现老缺陷。

  1. 工具本身不具有想象力

工具毕竟是工具，出现一些需要思考、体验、界面美观方面的测试，自动化测试工具无能为力。

  1. 技术问题、组织问题、脚本维护

自动化测试的推行，有很多阻力，比如组织是否重视， 是否成立这样的测试团队，是否有这样的技术水平，对于测试脚本的维护工作量也挺大的，是否值得维护等等问题都必须考虑。

(三)、 不适合自动化测试情况

自动化测试不是适合所有的公司、所有的项目。

  1. 定制型项目 (一次性的)

为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行环境也是客户特别要求的，即公司在这方面的测试积累就少，这样的项目不适合作自动化化测试。

  1. 项目周期很短的项目

项目周期很短，测试周期很短，就不值得花精力去投资自动化测试，好不容易建立起的测试脚本，不能得到重复的利用是不现实的。

  1. 业务规则复杂的对象

业务规则复杂的对象，有很多的逻辑关系、运算关系，工具就很难测试。

  1. 美观、声音、易用性测试

人的感观方面的: 界面的美观、声音的体验、易用性的测试，也只有人来测试

  1. 测试很少运行: 一个月只运行一次

测试很少运行，对自动化测试就是一种浪费。自动化测试就是让它不厌其烦的、反反复复的运行才有效率。

  1. 软件不稳定

软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定，没有界面性严重错误和中断错误才能开始自动化测试。

  1. 涉及物理交互

工具很难完成与物理设备的交互，比如刷卡的测试等。

(四)、什么样的情况适合自动化测试自动化测试之所以能在很多大公司实施起来，就是有它适合自动化测试的特点和高的投资回报率。

  1. 产品型项目

产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担， 同时可以把新加入的功能的测试也慢慢地加入到自动化测试当中。

  1. 增量式开发、持续集成项目

由于这种开发模式是频繁的发布新版本进行测试，也就需要自动化测试来频繁的测试，以便把人从中解脱出来测试新的功能。

  1. 能够自动编译、自动发布的系统

要能够完全实现自动化测试，必须能够具有自动化编译，自动化发布系统进行测试的功能。 当然，不能达到这个要求也可以在手工干预下进行自动化测试。

  1. 回归测试

回归测试试自动化测试的强项，它能够很好的确保你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。

  1. 多次重复、机械性动作

自动化测试最喜欢测试: 多次重复、机械性动作，这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。

  1. 需要频繁运行测试 在一个项目中需要频繁的运行测试，测试周期按天算，就能最大限度的利用测试脚本，提高工作效率。

  2. 将烦琐的任务转化为自动化测试

三、持续集成及其自动化编译

“持续集成 (Continuous Integration) “的概念来自于XP (极限编程) 的一个实践, 我们的开发模式是建立在CMM的基础之上,引入了某些XP的概念，所以我们的思想是取各方面的精华来适合自己。

持续集成是指能够自动的集成已经提交(Check-in)的代码，直至发布到测试服务器供测试的整个过程。

  1. 实现自动化日构建需要做以下几部分的工作:

  2. 将所有的源代码保存在单一的开发服务器，让所有人都能从这里获取最新的源代码 (需要用配置管理工具存放源代码: 如VSS/CVS/ClearCase) 。

  3. 使创建过程完全自动化，让任何人都可以只输入一条命令就完成系统的创建。

  4. 使测试完全自动化，让任何人都可以只输入一条命令就运行一套完整的系统测试。

  5. 确保所有人都可以得到最新、最好的可执行文件。

  6. 自动化编译: 为了能够提供自动化测试，所以所有的代码必须能够实现自动化编译。其实很多在做持续集成的公司都实现了改功能: 如java程序�%8E6��续改进，软件项目的持续集成与测试自动化的发展是必然的，其作用也将越来越明显。不同的技术和开发环境对测试如何自动化有不同的要求，还有很多值得研究的地方。

https://zhuanlan.zhihu.com/p/31097868 http://blog.csdn.net/baggioan/article/details/4577602