持续集成用于改进研发测试流程的初探
持续集成提出到现在已经有好几年的时间了，随着测试工作的进行，慢慢的也开始思考如何更改的提高测试质量和效率，慢慢的..........
持续集成提出到现在已经有好几年的时间了，随着测试工作的进行，慢慢的也开始思考如何更改的提高测试质量和效率，慢慢的深入了解持续集成。本文以一个例子介绍了应用持续集成理念改进研发测试流程的方案，虽然做的不够深入，权当抛砖引玉，希望大家对持续集成不仅仅停留在概念的层面上，能真正应用到测试工作中。
一：持续集成的十大特性
1 只维护一个源码仓库
源码仓库中存储的不仅仅是代码，测试脚本，配置文件，数据库Schema，安装脚本，还有第三方的库，所有这些build时需要的文件都应该放在源码仓库里
2 自动化 build
一个基本原则是任何人都应该能从一个干净的计算机上 check out 源代码，然后敲入一条命令，就可以得到能在这台机器上运行的系统。
3 让你的build自行测试
build中最好包含自动测试用例，这些测试用例可以检查大部分代码并找出 bug。
4 每人每天都要向mainline提交代码
提交代码越晚，可能的冲突就越多，每天提交代码，查找冲突错误的地方就越少，改起来也越快。
5 每次提交都应在集成计算机上重新构建 mainline
保证mainline总处于健康的状态，每次提交代码都要重新构建，跑用例，保证正确性。
6 保持快速 build
控制build时间在10分钟内，如果现实中很长的话，可考虑分阶段build。
7 在模拟生产环境中进行测试
保证测试环境和生成环境的一致性。
8 让每个人都能轻易获 得最新的可执行文件
项目中的每个人都应该能拿到最新的可执行文件并运行。
9 每个人都能看到进度
可以用显而易见的方式提示当前的进度和状态，比如红绿灯。
10 自动化部署
各个环境中的部署可自动化执行，并考虑能自动回滚。
二：背景和存在的问题
（1）开发和测试共用一套环境，共用一套环境经常会互相干扰，比如测试正在测着，忽然开发提交代码进行自测了，环境搞挂了，测试只能耐心的等着环境恢复后，才能继续进行测试。测试的阶段无形中被切割成很多段，严重的时候直接影响测试的效率。
（2）另外trunk测试阶段，测试的代码并非完全是要上线的代码。Trunk中存在很多开发中，或者进度不一样的项目代码，代码耦合非常严重。待代码合并到online后，才能完整的上线的代码，把很多风险推迟到最后才发现，导致风险可能不可控。
（3）Trunk合并代码到online的过程，需要人工进行diff，和代码和拷贝，错提、漏提现象严重，导致online需要全量回归用例，重复工作比较多，测试的效率和质量直接受到影响。
（4）分支存在时间过长，待合回主干后，又需要回归期间已经上过线的代码，测试的重复性工作变得很多，测试自动化少的话，效率会很低，而且容易出现遗漏的问题。
（5）测试和上线依赖手工，也导致测试效率低，上线容易出现问题。
三：改进的方案
从第一部分的持续集成介绍中，我们了解到应该有统一源码仓库，最好能达到持续构建，持续部署，和持续发布。如何做才能实现这些呢？做到这些又能给我们的测试工作带来哪些好处呢？下面从开发，测试和上线三个方面进行详细阐述。
3.1 开发
3.1.1 存在的问题
测试过的代码并非要上线的代码，QA需要多次重复性测试保证上线代码的质量。提测质量低下，开发的自测无法保证。通过上面例子流程的介绍，可以看到这种开发模式（trunk开发，trunk/online测试，online上线），会导致我们测试过程中代码耦合严重，纯上线代码的测试推迟到online环境进行。另外，开发提交代码的质量无从保证。
3.1.2 改进
开发模式变更
有没有一种可替代的开发模式，使开发和测试的合作更方便呢？我们想到主干开发，主干测试，分支上线。
主干开发，主干测试的话，这样分支带来的问题就能避免了。但是多个项目同时在主干上，上线时如何仅展示需要的功能呢？我们想到开发。Google等其他大公司都有提出过功能开关的概念，如下图所示，即在开发一个新功能的时候，引入一个布尔值的配置项，当该配置项为假时，应用程序的外部行为和没有引入该功能之前就保持一致；而当该配置项为真时，应用程序才展现出新开发的功能。
通过git/svn的分支机制拉出分支上线，就能保证online上部署的代码和trunk测试过的代码是完全一样的，再通过开关配置，就能使online时仅关注环境不一致的问题即可，不需要全量回归trunk测试过的功能。Online测试时间就能降低，测试的效率也就相应提高了。
（2）强制合并
如果分支上有问题修复，如何保证修复的代码能合并到trunk主干上面呢？有个小技巧，可以通过工具，使分支的代码只能从主干合并，而不能本地直接提交，这样就能保证任何的bugfix都能先提交到主干，再合并到分支，避免代码未提交主干的问题发生。
本地构建：
开发模式的改变使我们的测试流程变得简单起来，不需要额外关注一些不必要的问题。下一步来看下需要关注如何提高开发的提测质量，这里介绍一种本地构建的方法。
本地构建，即开发在提交代码到svn前，先在本地进行的一系列的测试。
本地构建之后，如何才能获取到构建的结果呢？如下图所示，当开发check in之前，先提交任务到本地构建的服务器上，本地构建服务器会加载开发的代码，并运行本地构建，运行完毕，存储结果到DB，并返回构建id给开发。开发check in时提交构建id到svn服务器，svn服务器配置的勾子程序会从db中检查该次构建的结果，如果符合提交条件，才能正确提交代码，否则就提交不成功。
当然本地构建如果时间太长，也会影响开发的效率，一般本地构建的任务只运行一些静态代码检查，核心功能的检查等用例，不做全部用例的检查。
3.2.1 存在的问题
无隔离的环境，导致测试进度受开发的影响；自动化测试少导致测试效率低下。环境问题是影响测试和开发效率的一个主要问题，如何更快正确的隔离环境也成为当务之急。另外，手工测试多，测试的质量和效率也很难提升，如何找到一种有效的自动化测试方案，以便提高人工测试的整体效率。
3.2.2 改进
一键部署隔离环境：
目前一些持续集成的服务器都可以做到对代码的监控，也可以方便的实现一键式的环境部署，比如jenkins，docker等。持续集成服务器监听svn服务器代码的变动，有变动后，就拉取代码到本地，编译，更新代码配置文件，和开关配置，然后部署到机器上。如果机器充裕，甚至可以实现人手一套环境，保证相互之间互不干扰。
如下图所示，持续集成服务器监听svn代码变动，有变动后，就自动部署代码到测试环境中，并自动执行测试用例。测试用例执行通过后，人工再进入进行检查，如果有问题，通过反馈系统反馈错误结果给对应的人。测试完成后，同样的过程适用于online环境（准上线）的部署。这样就能将代码变更，一键部署和自动化用例统一到一起，完成部分流程的执行。
为了提高测试的效率，我们在各个阶段均开展了自动化测试。根据项目模块的特点，将测试分为单元测试，接口级测试，集成测试和系统级测试。单元测试主要在本地构建的时候，由开发执行。接口级测试由开发和测试共同来维护，RD开发完毕后，通过接口测试平台执行用例，检查对历史功能的影响，通过后，再提交给测试。同时RD在开发进行中，会补充测试用例，QA测试过程中，也会补充测试用例，并和开发维护同一套用例。集成测试和系统级用例由QA维护，主要涉及到业务功能的测试。
各层级的用例对应流程中的不同阶段，如下图，本地构建时运行开发的单测用例，不通过，开发就不能提交代码到svn；下一步再执行接口级用例，这部分出现问题，测试会做一层筛查，确认有问题，再提交给开发修复。最后执行系统和集成测试用例，这部分用例还用于提测后核心功能检查，检查通过后，再进入人工测试阶段。
存在的问题
手工上线问题多
改进
现在一些团队的OP已经实现了代码的一键式分发上线。全量或者增量的将待上线的代码抓取到中心机上，然后一键式分发到各个生成机器上。这里重点说一些配置上线的问题。这里考虑平台化配置上线，开发将要上线的配置在平台中配置好，提交给qa 审核，审核通过后，OP通过平台一键式将配置分发到生成环境中。这样就能避免配置文件上错或者漏上的问题了，也能避免手动上线配置文件造成的失误性问题。
四：总结
Qtest测试之道
关注 Qtest之道
微信扫一扫关注公众号
