持续集成

一持续集成

1.1引言

      持续集成的价值是什么？对于开发和测试人员又意味着什么呢？

1.2概念

      “持续集成”一词来源与极限编程（Extreme Programming）,作为它的12个实践原则之一出现。

      ThoughtWorks首席科学家、软件开发领域大事Martin Fowler对持续集成是这样定义的：持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味置顶每天可能发生多次集成。每次集成都是通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大的减少集成的问题，让团队能够更快的开发内聚的软件。

      从上面的定义可以看出，一个典型的持续集成周期包括以下几个步骤：

1版本控制服务器上有最新的代码

2持续集成服务器从版本控制服务器下载最新的代码

3等代码完全更新以后，调用自动化编译脚本，进行代码编译

4运行所有的自动化测试（单元测试、接口测试、系统级别的UI自动化测试等）

5将结果写入报告文件中，反馈给团队成员

6如果构建失败，必须尽快修改确保下次构建成功

7产生可执行的软件版本，提供给测试人员进行测试

持续集成框架是由代码提交活定时来触发的（项目级别的持续集成可以由开发每次代码提交触发，而产品级别的持续集成可以由定时来触发），每次提交到版本控制服务器上的代码都要经过自动化构建，确保每次的代码变更都不会导致持续集成失败。

1.3目的和价值

      持续集成的目的不是减少build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用得更加顺畅。

      在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。

      而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。

      持续集成的价值有：

1易于定位错误。某一次集成失败了，说明新加的代码或修改的代码引起了错误，很容易就可以知道谁负责的代码出了问题，可以直接找相关人员来进行讨论，分析。

2及早在项目里取得系统级成果。每次集成产生的版本都是一个可用的版本。

3改善对进度的控制。每次持续集成报告中可以体现目前项目进度，哪部分需求已实现，哪些还没实现。

4改善客户关系。可以非常明确的给演示项目进度（理由如上）

5更加充分地测试系统中的各个单元。每日构建和测试相结合带来的好处

6能在更短的时间里构建整个系统

7有助于项目的开发数据的收集

8与其他工具结合的持续代码质量改进。如与checkstyle，PMD、Findbugs等

9与测试工具或框架结合的持续测试。如LoadRunner等

10便于code review。每个build与前一个build之间有什么改动，针对这些改动可以有效的实现code review

1.4持续集成流程图

      持续集成（Continuous Integration，CI）是一个长期而又敏捷的过程，在核心的CI可以分为两大类，一类是产品级别的持续集成，产品级别的持续集成在发布日做到日构建。另一类也就是本文需重要描述的项目级别的持续集成。项目级别CI贯穿整个项目周期，从项目的FRD到发布后的跟进。下图是项目级别的持续集成的流程图，主要介绍项目使用CI的流程。

      CI的介入是从立项的时候开始，前期是沟通和方案的定制，然后就是具体策略的执行，这里需要说明一下，CI不是独立存在的个体，他会与测试范围界定、缺陷分析等紧紧结合。

      当拿到一个项目时，应该怎么做，在流程图中已经说明了一切，首先是要做项目评估，如果项目适合做CI，然后就可以和项目组沟通，达成一直需指定方案计划和资源评估方案，最后进行具体方案的实施。

      图中节点说明：

项目评估：

      当我们参与一个项目的时候，需要评估下该项目是否适合做项目级别的持续集成，不是什么项目都可以做持续集成的。

      根据业界的经验，如何项目周期短，迭代次数少，这类的项目就不适合做持续集成，但还是要根据项目的特点进行评估。

沟通：

      这是非常重要的一点，只有团队达成一致，才能将CI持续下去，我们在达成一直的基础上做约定和计划，如果在沟通的过程中无法达成一致，那么个人建议不要进行CI，当然也要去分析为什么没有达成一致。

计划约定与资源评估：

      在沟通达成一致的基础上做出计划约定和资源评估。

持续集成实施：

      在沟通、计划、约定的基础上我们就可以运用工具和策略对起进行实施，具体的工具和实施在后面的章节会做说明。

2持续集成方案与策略

      在前面介绍了项目级别持续集成的流程，四个节点（项目评估、沟通、计划与方案定制、持续集成实施）都非常的重要，项目评估、沟通、计划与方案定制属于前期的过程，也是基础。本章重点介绍持续集成实施中持续集成的方案与策略、量化标准以及数据的采集。

2.1持续集成策略

      持续集成的实施肯定缺少不了策略，但我们应该使用什么样的集成策略呢？如下图所示：

      持续集成的策略是采用技术手段为CI提供技术依据，做一个好的持续的项目最核心的是良好的单元测试编码，集成测试编码、系统测试编码、web ui层自动化等不同level的自动化能力，安装核心系统目前的情况来讲，有些条件并不成熟。但我们可以反其道而行之，以项目持续集成为基础，来推动某些条件（如单元测试、代码规范）的良性循环，形成量的积累，使得持续集成条件逐步走上正轨。

2.2单元测试集成

      单元测试是持续集成中非常重要的组成部分。目前我们软件质量部产品线的单元测试可以说是几乎处于无的状态。

目的与价值

      单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码是否正确。通常而言，一个单元测试是用于判断某个特定条件或场景下某个函数的行为是否按照预期结果进行。

      单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成（TDD），也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。持续集成中集成单元测试，每次迭代提交都保证单元测试的质量，那么产品的质量在一定程度上都得以保证。

      所以单元测试在持续集成过程中是测试件中非常重要的组成部分。不可缺少，这也是CI过程要单元测试集成的目的和意义。

2.3单元测试策略

      集成测试项目中对单元测试策略采用如下：

1参与单元测试case设计

      开发人员或测试人员进行单元测试编码，测试设计人员参与case设计，因为我们设计case的角度和开发人员是不一样的，测试人员的设计会更加全面。

2单元测试case的review

      要进行单元测试case的review，如果发现不合适的case则要进行修订。以保证单元测试的质量。

3单元测试的用例评审（单元测试完成阶段）

      与项目组成员或资深人员一起参与单元测试用例的评审，对不合适的用例需进行修改。

在持续集成过程中，如果发现单元测试的failed趋势上升或failed达到某一标准时，需和开发人员沟通并修订bug，从而保证每次迭代产品的质量。

2.4适用范围和阶段

      单元测试适合在开发人员进行单元测试编码阶段，一旦单元测试编码完成，上述单元测试的测试都可以适用，贯穿于整个项目周期。

2.5工具

      既然有持续集成，那我们就需要用到一些持续集成的工具和平台去分析每次的构建结果，在持续集成平台（hudson）中集成了单元测试覆盖率统计工具。参考后续内容。

2.6量化指标

      使用单元测试策略中我们会采集到一些数据指标，

3接口测试集成

      接口测试类似于单元测试，是分层自动化的重要组成部分，介于黑盒测试与白盒测试之间，在了解系统设计与接口定义对前提下，就可以在适当的时候运用mock来进行接口测试。

3.1目的与价值

      接口测试是质量的保证和效能的提升，所谓质量保证，就是深入到代码的底层，可以对接口进行直接的参数注入，查看其返回结果，让我们知道底层到底发生了什么。所谓效能的提升，就是程序的速度远比手工的速度快，几分钟就可以跑完上百个用例。

      接口测试不但可以提高测试效率，也不需要投入过多的精力去熟悉代码逻辑，而且可以借助单元测试技术实现持续集成和每日构建。

3.2接口测试策略

      本文采用的接口测试主要是对系统提供的服务接口进行所有接口的覆盖和集成，在覆盖的过程中进行以业务为导向的codeReview。在持续集成运行的过程中发现bug，需与开发人员沟通后修订bug，从而保证产品的质量。起测试方案如下：

1新增的接口进行case覆盖和集成

2修改的接口进行case覆盖和集成

3保证已有接口的正确

3.3适用范围和阶段

      接口测试和单元测试一样，贯穿整个项目的周期。

1需求了解阶段：了解项目中接口的功能，接口的输入输出参数及返回值，根据项目的情况决定是否做接口测试

2设计阶段：了解接口的实现，并与开发沟通确定接口以怎么样的形式进行暴露，从少先队哪一层暴露。

3编码阶段：脚本编写、数据准备、调试

4测试阶段：

      -接口参数完成和提交测试前，主要个工作就是：运行接口测试脚本进行测试，根据测试的结果与开发逐一过用例，以确定是代码问题还是数据问题，直至所有的case均跑通。

      -测试阶段和分支回归阶段，利用集成测试平台完成该接口的测试和部分的分支回归工作，检查测试结果

      -发布回归，利用持续集成平台检查测试结果

5发布会：

      -接口参数若有变化应及时维护脚本和数据

      -持续集成保证底层的质量

3.4工具

      接口测试涉及的工具主要是接口测试的开发和持续集成平台。

      开发工具例如eclipse

      持续集成测试平台hudson的配置和运行

4 UI测试集成

4.1目的和价值

      UI自动化测试是通过直接操作指定的浏览器，对浏览器中的页面对象、元素进行操作，完全模拟手工测试过程。项目中运行UI自动化测试的一个目的就是期望能利用自动化替代手工测试提升测试效率，通常在分支回归阶段使用，减少回归投入时间；另一个目的是为了产品级UI自动化测试做基础建设。产品级UI自动化测试在每日发布的回归测试中使用，不仅能扩大回归范围，而且能帮我杜绝重要故障，保证产品重要业务流程的正确性。

2 UI测试集成策略

      集成测试项目中对UI测试的策略采用如下：

1可行性分析及需求提取：测试负责人评估项目是否适合UI自动化覆盖，并确认UI自动化覆盖范围。

2计划安排：测试负责人平台自动化脚本开发工作量，并且在测试计划中加入