持续集成与测试自动化
一、背景
我从毕业到现在， 曾在大小不同的三个公司职: 有民营的、有外资的、也有上市公司。 但以前大多都是做项目，从事软件开发工作，绝大部分公司对测试都不重视，即使有也没有成规模， 更谈不上建立测试体系。总之，重开发轻测试的管理思想在中国延续了几十年、并且还要继续，看看他们给测试工程师开的低工资和老师在课堂上讲到测试时一笔带过知道测试被中国的老板所忽略。
近两年，我从事CRM软件产品的测试、项目管理工作。 由于公司对软件的质量要求特别高， 这必然引起了大家对测试工作的重视，不但要求有强大的测试团队，该团队必须具备在业务方面、测试技能方面的专业水平， 而且在软件开发过程方面经常由于测试而作持续不断地调整。
幸运的是，随着软件开发技术和工具的提高，软件工程和软件过程实践的推广， 软件测试日益得到重视和专业化。 我从事测试工作期间，一直研究CMM、测试理论、自动化测试工具，并建立了一套完整的测试体系。
在此并不介绍整个测试体系，而是介绍测试方面值得探讨的部分：持续集成与测试自动化。目的是与大家共同进步。当然已经有很多关于持续集成和自动化测试方面的介绍，但我要介绍的不只是持续集成，也不只是自动化测试，而是测试如何的自动化.
二、测试自动化
自动化测试是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软件质量的目的。自动化测试的目的在于发现老缺陷。而手工测试的目的在于发现新缺陷。
测试自动化涉及到测试流程、测试体系、自动化化编译、持续集成、自动发布测试系统以及自动化测试等方面整合。也是说要让测试能够自动化，不仅是技术、工具的问题，更是一个公司和组织的文化问题。首先公司从资金、管理上支持您，其次要有专门的测试团队去建立适合自动化测试的测试流程、测试体系;其次是把原代码从受控库中取出、编译、集成、发布可运行系统、进行自动化的单元测试和自动化的功能测试的过程。
(一)、自动化测试的好处
1、 对新版本执行回归测试--测试每个特征
对于产品型的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试， 从而可以让测试达到测试每个特征的目的。
2、 更多更频繁的测试--沉闷、耗时
我们的产品向市场的发布周期是3个月，也是我们的开发周期只有短短的3个月，而在测试期间是每天/每2天都要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，人工测试是非常的耗时和繁琐，这样必然会使测试效率低下。
3、替代手工测试的困难--300个用户有些非功能性方面的测试：压力测试、并发测试、大数据量测试、崩溃性测试，用人来测试是不 可能达到的。 在没有引入自动化测试工具之前，为了测试并发，研发中心的一、两百号人在研发经理的口令：1-、2-、3!， 大家同时按下同一个按钮。回想起这中情景也蛮有意思的。
4、具有一致性和可重复性
由于每次自动化测试运行的脚本是相同的， 所以每次执行的测试具有一致性， 人是很难做到的. 由于自动化测试的一致性，很容易发现被测软件的任何改变。
5、更好的利用资源--周未/晚上
理想的自动化测试能够按计划完全自动的运行， 在开发人员和测试人员不可能实行三班倒的情况下， 自动化测试可以胜任这个任务， 完全可以在和晚上执行测试. 这样充分的利用了公司的资源，也避免了开发和测试之间的等待.
6、解决测试与开发之间的矛盾
通常在开发的末期，进入集成测试阶段， 由于每发布一个版本的初期，测试系统的错误比较少，这时开发人员有等待测试人员测试出错误的时间. 事实上在叠代周期很短的开发模式中，存在更多的矛盾， 但自动化测试可以解决其中的主要矛盾。
7、增加软件信任度
总之，自动化测试的好处和收益是很明显的，但也只有顺利事实了自动化测试才能从中获得它的益处。
(二)、 自动化测试-- 误区、限制自动化化测试好处很多，但也有很多的局限，也正因为很多老板对自动化测试的期望太高，所以有很多执行自动化测试失败的例子。
1、 期望自动化测试能取代手工测试
不能期望自动化测试来取代手工测试， 测试主要还是要靠人工的。
2、期望自动测试发现大量新缺陷
同样不能期望自动化测试去发现更多新的缺陷， 事实证明新缺陷越多，自动化测试失败的几率越大。发现更多的新缺陷应该是手工测试的主要目的。测试专家James Bach总结得 85%的缺陷靠手工发现，而自动化测试只能发现15%的缺陷。
其实我认为自动化测试能够很好的发现老缺陷。
3、工具本身不具有想象力
工具毕竟是工具，出现一些需要思考、体验、界面美观方面的测试，自动化测试工具无能为力。
4、技术问题、组织问题、脚本维护
自动化测试的推行，有很多阻力，比如组织是否重视， 是否成立这样的测试团队，是否有这样的技术水平，对于测试脚本的维护工作量也挺大的，是否值得维护等等问题都必须考虑。
(三)、 不适合自动化测试情况
自动化测试不是适合所有的公司、所有的项目。
1、定制型项目(一次性的)
为客户定制的项目，维护期由客户方承担的，甚至采用的开发语言、运行环境也是客户特别要求的，即公司在这方面的测试积累少，这样的项目不适合作自动化化测试。
2、项目周期很短的项目
项目周期很短，测试周期很短，不值得花精力去投资自动化测试，好不容易建立起的测试脚本，不能得到重复的利用是不现实的。
3、业务规则复杂的对象
业务规则复杂的对象，有很多的逻辑关系、运算关系，工具很难测试。
4、美观、声音、易用性测试
人的感观方面的：界面的美观、声音的体验、易用性的测试，也只有人来测试
5、测试很少运行：一个月只运行一次
测试很少运行，对自动化测试是一种浪费。自动化测试是让它不厌其烦的、反反复复的运行才有效率。
6、软件不稳定
软件不稳定，则会由于这些不稳定因素导致自动化测试失败。只有当软件达到相对的稳定，没有界面性严重错误和中断错误才能开始自动化测试。
7、涉及物理交互
工具很难完成与物理设备的交互，比如刷卡的测试等。
(四)、什么样的情况适合自动化测试自动化测试之所以能在很多大公司实施起来，是有它适合自动化测试的特点和高的投资回报率。
1、产品型项目
产品型的项目，每个项目只改进少量的功能，但每个项目必须反反复复的测试那些没有改动过的功能。这部分测试完全可以让自动化测试来承担， 同时可以把新加入的功能的测试也慢慢地加入到自动化测试当中。
2、增量式开发、持续集成项目
由于这种开发模式是频繁的发布新版本进行测试，也需要自动化测试来频繁的测试，以便把人从中解脱出来测试新的功能。
3、能够自动编译、自动发布的系统
要能够完全实现自动化测试，必须能够具有自动化编译，自动化发布系统进行测试的功能。 当然，不能达到这个要求也可以在手工干预下进行自动化测试。
4、回归测试
回归测试试自动化测试的强项，它能够很好的确保你是否引入了新的缺陷，老的缺陷是否修改过来了。在某种程度上可以把自动化测试工具叫做回归测试工具。
5、多次重复、机械性动作
自动化测试喜欢测试：多次重复、机械性动作，这样的测试对它来说从不会失败。比如要向系统输入大量的相似数据来测试压力和报表。
6、需要频繁运行测试
在一个项目中需要频繁的运行测试，测试周期按天算，能大限度的利用测试脚本，提高工作效率。
7、将烦琐的任务转化为自动化测试
三、持续集成及其自动化编译
"持续集成(Continuous Integration)"的概念来自于XP(极限编程)的一个实践， 我们的开发模式是建立在CMM的基础之上，引入了某些XP的概念，所以我们的思想是取各方面的精华来适合自己。
持续集成是指能够自动的集成已经提交(Check-in)的代码，直至发布到测试服务器供测试的整个过程。
1、实现自动化日构建需要做以下几部分的工作：
2、将所有的源代码保存在单一的开发服务器，让所有人都能从这里获取新的源代码(需要用配置管理工具存放源代码: 如VSS/CVS/ClearCase)。
3、使创建过程完全自动化，让任何人都可以只输入一条命令完成系统的创建。
4、使测试完全自动化，让任何人都可以只输入一条命令运行一套完整的系统测试。
5、确保所有人都可以得到新、好的可执行文件。
6、自动化编译： 为了能够提供自动化测试，所以所有的代码必须能够实现自动化编译。其实很多在做持续集成的公司都实现了改功能：如java程序可以采用在Ant + Junit 的基础之上添加自己的功能既可以实现持续集成―――我们把这个工具叫：日构建
但很多公司并没有实现对JSP的自动编译，对于采用jsp编写的web页面，它是编译执行语言，由于第一次执行要先编译，即第一次的速度稍慢，如果要采用自动化测试工具winrunner进行功能测试时，则会失败。因为自动化测试工具基本的要求是：
1、进入条件和出口条件必须在录制与回放时完全相同。
2、持续集成的好处：
完全可以取代人工的发布， 在J2EE中有个角色叫deployer.， 它的主要工作是经常发布新的系统供开发、测试，一般每发布一次至少要一个小时，如遇到一些问题一个上午耗费掉了， 但使用“日构建”后可以完全实现自动化，时间几乎只等于编译时间。
它完全避免了开发者们的"除虫会议"--以前开发者们经常需要开这样的会，因为某个人在工作的时候踩进了别人的领域、影响了别人的代码，而被影响的人还不知道发生了什么，于是bug出现了。
这样的bug绝大多数都可以在引入的同被发现。由于之中发生变动的部分并不多，所以可以很快找到出错的位置。
持续集成可以把发现的错误根据源代码的作者，以邮件和日志的方式分发给作者，第二天一上班的第一件事是先修改错误。
持续集成可以减少集成阶段"捉虫"消耗的时间、 频繁发布新版本的时间，从而终提高生产力和软件质量。
3、理想的持续集成的实现方法：
A)、同一个软件产品要有集中的同一台开发服务器，即所有人的新的、各自编译通过的源代码都在配置管理工具如VSS中。
B)、有一台运行主创建的机器，有计划的运行日构建， 日构建中有一个创建进程，该创建进程是在一个随时保持运行的Java类中进行的，如果没有创建任务，创建进程一直循环等待。
C)、守护进程将全部代码(包括原程序和配置文件，数据库脚本等)提取到创建机器的一个目录中。提取完成之后，守护进程会在这个目录里调用Ant脚本。
D)、Ant会接管整个创建过程，对所有源代码做一次完整的创建。Ant脚本会负责整个编译过程，并把得到的class文件放进六个jar包里，发布到EJB服务器上。
创建结束之后，创建守护进程会给所有向新一次创建归还了代码的开发者发一个e-mail，汇报创建的情况。
E)、当Ant完成了编译和发布的工作之后，创建守护进程会在EJB服务器上开始运行新的jar，同时开始运行BVT测试套件：即利用Junit进行单元测试。
单元测试完成后，日构建会把单元测试报告发给有错误的开发人员。
F)、为了利用自动化工具(WINRUNNER)进行功能测试，必须对JSP编译，利用jspc命令进行包装一层，可以自动的对所有的jsp文件进行编译， 但由于编译jsp的时间非常长(越比编译java代码时间长)，所以一般利用单独的编译服务器进行编译。 发布编译好的jsp文件进行自动化测试的成功率高(因为第一次运行jsp文件非常慢，而自动化测试忌讳运行时和录制时等待得时间不一样)。 而功能性自动化测试也需要按计划有顺序的执行，这需要TestDirector测试管理系统来调度Winrunner进行测试。
让所有的重复的繁琐的事情都完全自动化，并且要经常进行集成，让重复的测试自动化。
四、测试套件实现测试流程.
当具备持续集成和测试自动化的能力后，需要一套测试体系来支持和维护您的测试流程，确保测试过程是符合流程、标准，而且是持续改进的。
(一)、为什么需要一个流程?很多公司投入了大量的测试经费，然而还是没有收到预期的收益。这可能是因为：缺乏足够的测试计划、缺乏测试的优先次序、工作的重复、没有利用工具来配合人工测试、没有利用测试自动化工具、测试自动化运用不够或者运用的不恰当等等。所以需要有测试套件的实施流程。
(二)、 为什么需要工具?
工具能够加快测试的进度，可以把控制和管理引入整个测试过程，比如MI公司的TestDirector是一个很好使用的测试管理系统，而且是web版的。测试管理系统有很多的作用：
测试管理和报告：测试管理系统能够保证系统开发和测试流程你不的问题尽快得到解决。
审核跟踪的凭据：TestDirector存贮了所有的测试结果，全部修改被写进一个审核跟踪器里，如：时间、日期、修改人、错误授权，能够很清晰的看到把错误当皮球踢不负责人的整个过程。
提高测试覆盖率：通过自动化测试工具的数据驱动来测试功能，可以提高测试覆盖率。
(三)、测试套件--测试体系的主要目标(5W3H)
测试体系的建立是为了确保软件测试的全部活动按计划、按标准的进行，是测试人员的行动纲领和职责指导。也是有这样的一个体系、流程来指导他们的工作，培养了他们的主人翁责任感。让测试工作开展得有条不紊。
主要的内容有：测试流程，测试方针、测试规程、文档模版、质量标准、测试工具、测试技术和方法等内容。
测试体系的主要目标(5W3H)：目的是告诉与测试活动相关的人员在什么样的时间，什么样的地点，由谁来做，做什么样的事情，为什么做，如何做，怎么样才算完成，缺陷任何分析和预防等。可以简称：5W3H.
1、为什么要测试系统(Why) ?
测试新功能：每发布一个新的版本，首先要去测试它的新功能。创建回归测试的测试套件验证缺陷修改：在这个测试周期中要验证上个测试周期的缺陷修改情况。验证系统性能检测新硬件
2、如何测试系统(How)? 系统测试：检查系统总体功能
压力测试：在反复相同的操作下、或其他压力条件下，比如：低内存空间/低磁盘空间等，检测软件的反应。
安装测试：检验系统安装得是否正确，而且与已安装的软件不发生冲突。
安全测试：测试系统存取权限和授权的级别
边界测试：利用数据边界和系统边界检验程序
3、什么时候进行测试(When)? 在开发流程的哪个阶段开始测试?
在需求规格说明书一出来，或项目管理计划一出来，测试人员开始有事做：写测试计划、编写测试用例、执行测试、测试报告和缺陷分析。很多老板以为要编码结束后才开始测试工作，所以不肯有专职的测试人员，怕他们在项目前期没有事做。
前提条件和附属条件是什么?
多长时间需要进行一次测试?
交货的时间表是什么?
什么时候停止测试? 什么时候停止测试是很有学问的，很多公司多半是在没有时间、没有资金是，老板或项目经理说了停止停止。事实上根据bug预测、bug发现率与错误修正率的时间曲线来决定的。只有当这个曲线达到水平线后方才可以停止。
4、谁来实施测试(Who) ?硬件：具备什么样的服务器、客户端及其网络环境。
软件：安装什么样的软件环境适合作这些测试。
体系架构：测试的类别有很多，不同的人进行不同的测试，比如开发人员做单元测试，测试人员作功能测试、集成测试、非功能性测试，而让市场、需求人员、客户去做验收测试
数据：需要什么样的测试数据来实施这一次的测试，这些测试数据的设计。
人力资源：按测试计划的要求安排相关的人力资源。5、在哪里进行测试(Where) ?在开发服务器上测试?
开发人员可能会叫你在测试服务器上测试，事实上这样对测试效率和测试人员的情绪影响是很大的，因为开发服务器是一个极不稳定的环境。而且也没明显的测试阶段。
建立一个测试实验室 ?
对于有很多项目的公司，建立一个测试实验室是很必要的，主要用来做环境的兼容性测试，压力、性能测试，验收测试等等。
为了减轻测试者本地机器的负荷，使之在进行测试的同时可以做其他测试，远程定时执行测试的机制。6、测试什么(What) ?自动测试中应用程序的主要特点是什么?
按重要性将这些特点排序?
自动测试各部分的相对重要性?
总体质量目标是什么(可用性，功能，可靠性，性能等等)?
7、怎么样才算完成(How)?
要定义测试的完成条件和完成标准， 以便达到这些条件和标准后应该立即停止测试，否则在经济和时间上是不允许的，因为测试可以永远下去.
8、缺陷如何分析和预防(How)?
测试过后应该对测试出的错误类别，错误特点作分析和提出预防措施，以便在将来的项目中有意识的去避免，这是CMM5中说的缺陷预防.
五、自动化测试工具(WinRunner)
另外在此简单的介绍一下自动化测试工具的原理。
1、 Winrunner基本原理--录制/回放功能――录制
录制前的Add-in选择：它对不同的语言开发了不同的Add-in录制前的参数设置录制方式选择：
Context Sensitive
Analog
录制技巧
保存录制脚本和GUI
――调试
修改录制好的脚本。
添加同步点和等待时间。
添加检查点checkpiont。
修改GUI-MAP，提高可读性、可维护性 。
回放的前提条件。
执行测试方式：
验证方式：核对应用程序是否正确。
调试方式：增加新特征和功能
更新方式：用新版本应用程序中得到的运行结果更新期望结果。
分析结果。
2、 参数化数据驱动测试
特点：用相同测试脚本执行不同测试优点：提高测试覆盖率
步骤：
1).转换你的测试为数据驱动测试:datadriver
2).在数据表中增加数据
3).校正脚本使用正确的表达式
4).自定义结果信息 (tl_step)
3、 运用WinRunner的风险
产品性的软件，会有很多自己开发的组件、控件或引入新的技术如xml，htc等，这有可能使得自动化测试工具不认识，导致整个自动化测试失败，已往积累的测试脚本将全部废弃。
总之，由于商业社会对软件的质量要求越来越高，软件开发过程的持续改进，软件项目的持续集成与测试自动化的发展是必然的，其作用也将越来越明显。不同的技术和开发环境对测试如何自动化有不同的要求，还有很多值得研究的地方。
