持续集成与测试自动化
https://www.doczj.com/doc/119322089.html,原创作者：黄良生
一、背景
我从毕业到现在, 曾在大小不同的三个公司就职: 有民营的、有外资的、也有上市公司。但以前大多都是做项目，从事软件开发工作，绝大部分公司对测试都不重视，即使有也没有成规模，更谈不上建立测试体系。总之，重开发轻测试的管理思想在中国延续了几十年、并且还要继续，看看他们给测试工程师开的低工资和老师在课堂上讲到测试时一笔带过就知道测试被中国的老板所忽略。
最近两年,我从事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进行功能测试时，则会失败。因为自动化测试工具最基本的要求是：进入条件和出口条件必须在录制与回放时完全相同。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等，这有可能使得自动化测试工具不认识，导致整个自动化测试失败，已往积累的测试脚本将全部废弃。
总之，由于商业社会对软件的质量要求越来越高，软件开发过程的持续改进，软件项目的持续集成与测试自动化的发展是必然的，其作用也将越来越明显。不同的技术和开发环境对测试如何自动化有不同的要求，还有很多值得研究的地方。
接口自动化测试方案 2018年4月9日 文档编号：（V1.0） 目录 目录 1测试需求及范围 (2) 1.1测试目的 (2) 1.2测试需求 (2) 2测试方法 (3) 3测试工具及框架拓扑图 (3) 3.1测试工具 (3) 3.2自动化测试拓扑图 (3) 4流程示例 (3) 5测试环境 (5)
2.1硬件配置 (5) 2.2软件配置 (5) 6测试思路 (6) 6.1通用测试场景 (6) 6.2逻辑场景 (7) 6.3断言检查 (7) 1测试需求及范围 1.1测试目的 随着公司项目的不断增大，接口的服务随之增多，回归的任务量越来越大，需要对接口进行定时回归测试来保证系统的稳定性。 1.在开发提交新的接口前进行冒烟测试，以保证系统是能够正常开展测试的 2.功能测试完成/bug回归完成后进行回归测试，保证bug修改完成后没有引入新的问题1.2测试需求 1、目前提供的接口多为Rest 规范的接口，需要使用JMeter进行自动化接口测试，核对接口入参及返回报文格式、内容的正确性，最终通过Jenkins持续集成生成测试报告。 2、对开发人员的需求 接口文档的规范，如：输入输出模板，输出类型是否全面 2测试方法 根据开发人员提供的接口访问地址、入参格式、请求格式，进行接口请求数据拼接，并查看返回结果及返回报文、响应时间，检查返回Json内容是否符合接口定义规范，是否符合预期的返回结果。
3测试工具及框架拓扑图 3.1测试工具 Jemeter+Jenkins 3.2自动化测试拓扑图 4流程示例 测试数据从csv或者txt文件里读取，包含入参、出参、预期结果/断言 用例通过jemter维护
导读：浅谈CI/CD 和软件测试 知其然，知其所以然。相较于DevOps而言，CI/CD是一个相对具象的概念。在IT 企业中，CI/CD的应用愈加广泛，成为推动软件研发活动的重要基础设施服务，同时推动DevOps 模式的实际落地。 什么是CI/CD 在实践CI/CD 相关内容之前，我们有必要先认识下什么是CI/CD。 一般传统或者狭义、普遍的CI/CD，是指持续集成（Continuous Integration，CI）和持续交付（Continuous Delivery，CD）。而更加广义、全面的理解，是指持续集成（Continuous Integration，CI）、持续测试（Continuous Testing，CT）、持续交付（Continuous Delivery，CD）和持续部署（Continuous Deployment，CD）四个方面。通常，一个软件开发的流水线如下图所示。 ?Design：这一阶段完成软件开发的需求分析和设计。 ?Develop：这一阶段完成软件开发的功能代码，一个最佳实践是采用测试驱动开发（TDD）的方法，测试代码和功能代码的编写同时 进行。需要注意的是，在Develop 阶段也会运行单元测试和其他 小型测试。 ?Test：这一阶段完成软件的各项大型或专项测试，比如界面测试、API 测试、性能测试和系统测试等。
?Release：这一阶段完成软件产品的发布，并交付给用户使用。 持续集成（Continuous Integration） 随着敏捷开发的发展，持续集成在软件项目活动中也日益成为主流。顾名思义，持续集成是指每日频繁地（比如一天多次）将代码集成到主干分支中。强调通过集成和测试的速度，快速给出一个集成的结果（是失败还是成功），在代码集成之前，必须先通过自动化测试验证，只要有一个测试用例失败，就不能集成。 Martin Fowler 说过，“持续集成并不能消除Bug，而是让它们非常容易被发现和改正”。这也正是持续集成的真谛所在。 敏捷开发的核心是指整个软件开发活动被划分成一系列短的迭代过程，每个迭代完成一定数量的功能，迭代周期应该尽量短。在软件开发需求已经确定的情况下，迭代应该由测试驱动开发（TDD）和集成反馈来驱动。只有这样，才能为质量持续改进奠定一个良好的基础。
一、概念引入 持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。 在敏捷开发中，有一个很重要的实践叫做持续集成。而什么是持续集成呢？简单来说，持续集成是频繁、持续的在多个团队成员的工作中进行集成，并且给与反馈。一个典型的持续集成周期包括以下几个步骤： 1.持续集成服务器不断从版本控制服务器上检查代码状态，看代码是否有 更新。 2.如果发现代码有最新的提交，那么就从版本控制服务器下载最新的代码。 3.等代码完全更新以后，调用自动化编译脚本，进行代码编译。 4.运行所有的自动化测试。 5.进行代码分析。 6.产生可执行的软件，能够提供给测试人员进行测试。 测试是持续集成流程中重要的一环，也是区别去传统的软件开发流程中的一个重要的标志。为什么要有持续集成测试呢？ 每天，程序开发人员将各自开发的代码上传到配置管理工具（如SVN、VSS）中，而配置管理工具会记录下谁在什么时间上传了什么代码文件。随后，持续集成工具会定期（可以是几个小时、半天，或者一天，由使用者自己定义）向配置管理工具询问，从上一周期到现在是否有代码上传。如果有，则下载到持续集成工具中进行集成。之后，持续集成工具会调用构建工具代码编译、自动化测试，以及执行静态代码检查。如果这几项工作执行成功，则打包复制到应用服务器（如Weblogic）上执行重新发布，并形成代码检查与测试等报告；如果执行失败，则及时通过邮件通知管理者，并记录相关日志。 配置管理工具 毫无疑问，配置管理工具对持续集成工具来说是绝顶重要的，它是所有最新代码的来源。持续集成工具会定期向配置管理工具询问代码是否有更新。只有有了更新，持续集成工具才会去完成后续的工作，否则就没有了意义。目前在Java开发项目中，最主流的无疑是Subversion（简称SVN）。SVN是对CVS的升级，它通过插件的形式被集成到开发工具中，并且提供了更加方便的上传下载操作，使开发人员最厌恶的上传下载操作变得简便。SVN的另一个巨大贡献是改变了VSS 那样的串行修改模式。众所周之，VSS的版本管理思路就是串行修改模式，即对于同一个文件只能一个人修改，其他人不能修改。这样的模式对应大规模团队开发来说无疑是非常蹩脚的。SVN改变了这种模式，同一个文件可以多人并行操作，但同时SVN又提供了强大的版本冲突处理机制，当并行操作的多人各自提交版本时，通过版本冲突处理机制可以顺利的合并版本，使最终形成统一版本。
Appium环境搭建 随着人类消费观念转变，企业巨头间的无硝烟战场从互联网转移到移动端，为了抢占移动端用户，企业们更是绞尽脑汁，想方设法提高产品质量和增强用户体验，赢得此场战役的关键是产品质量，高质量产品更能捕获用户的芳心。但高质量产品保证的根源是高质量的测试，因此测试时关键。移动应用自动化测试是一个新的领域，移动端平台多样化（Andriod、Ios、FirefoxOS）为自动化测试带来了挑战与困难，随着Appium框架的推出，移动自动化测试进入一个崭新的阶段，自动化入门容易、上手快，轻轻松松测试多个移动平台。因Appium，移动自动化测试更加容易，现在让我为大家揭开Appium神秘面纱吧。 Appium is an open source test automation framework for use with native and hybrid mobile apps. It drives iOS and Android apps using the WebDriver JSON wire protocol. 摘自http://appium.io/ 从上面那句话我们可以窥探出Appium整个轮廓。Appium是一个开源、免费的移动端自动化测试框架，可以用来测试原生和混合移动应用，同时支持测试多种平台（Ios、Android、FirefoxOS）下应用，底层是采用WebDriver JSON Wire协议去实现的。 Appium测试环境搭建步骤： ?下载、安装JDK&配置Java环境变量 ?下载、安装SDK、ADT&配置Android环境变量 ?下载、安装AppiumForWindow ?创建安卓模拟器 ?在线安装Testng、SVN、Maven等插件 ?Appium简单案例 1、下载、安装JDK&配置Java环境变量 JDK（Java Development Kit）即Java开发工具集，一堆Java开发基本工具比如Javac.exe、Jar.exe、Javadoc.exe etc.同时JDK包含了JRE（Java Runtime Environment）即Java运行环境，因此要进行使用Java编写Appium脚本，前提是安装JDK。 Java语言以前是Sun公司推出，之前可以在Sun主页中下载JDK，但现在Sun公司被Oracle收购了，因此现在想下载JDK最好去Oracle官网下载。 JDK下载地址:https://www.doczj.com/doc/119322089.html,/technetwork/java/javase/downloads/index.html 安装（略），傻瓜式安装，关键是Java_Home 配置环境变量： 1、右键我的电脑--属性--高级--环境变量 2、新建系统变量JAVA_HOME 和CLASSPATH 变量名：JAVA_HOME 变量值：C:\Program Files\Java\jdk1.7.0 变量名：CLASSPATH 变量值：.;%JAVA_HOME%\lib\dt.jar;%JAVA_HOME%\lib\tools.jar; 3.、选择“系统变量”中变量名为“Path”的环境变量，双击该变量，把JDK安装路径中bin目录的绝对路径，添加到Path变量的值中，并使用半角的分号和已有的路径进行分隔。 变量名：Path 变量值：%JAVA_HOME%\bin;%JAVA_HOME%\jre\bin; 验证配置是否成功：重新打开控制台输入：java -verison，如果显示Java版本信息表示安装成功。 2、下载、安装ADT&配置Android环境变量 ADT（Android Development Kit，即安卓开发工具包）属于SDK（Software Development Kit, 即软件开发工具包）
持续集成与测试自动化 https://www.doczj.com/doc/119322089.html,原创作者：黄良生 一、背景 我从毕业到现在, 曾在大小不同的三个公司就职: 有民营的、有外资的、也有上市公司。但以前大多都是做项目，从事软件开发工作，绝大部分公司对测试都不重视，即使有也没有成规模，更谈不上建立测试体系。总之，重开发轻测试的管理思想在中国延续了几十年、并且还要继续，看看他们给测试工程师开的低工资和老师在课堂上讲到测试时一笔带过就知道测试被中国的老板所忽略。 最近两年,我从事CRM软件产品的测试、项目管理工作。由于公司对软件的质量要求特别高，这必然引起了大家对测试工作的重视，不但要求有强大的测试团队，该团队必须具备在业务方面、测试技能方面的专业水平，而且在软件开发过程方面经常由于测试而作持续不断地调整。 幸运的是，随着软件开发技术和工具的提高，软件工程和软件过程实践的推广，软件测试日益得到重视和专业化。我从事测试工作期间，一直研究CMM、测试理论、自动化测试工具，并建立了一套完整的测试体系。 在此并不介绍整个测试体系，而是介绍测试方面最值得探讨的部分：持续集成与测试自动化。目的是与大家共同进步。当然已经有很多关于持续集成和自动化测试方面的介绍,但我要介绍的不只是持续集成,也不只是自动化测试,而是测试如何的自动化. 二、测试自动化 自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量，从而达到提高软件质量的目的。自动化测试的目的在于发现老缺陷。而手工测试的目的在于发现新缺陷。 测试自动化涉及到测试流程、测试体系、自动化化编译、持续集成、自动发布测试系统以及自动化测试等方面整合。也就是说要让测试能够自动化，不仅是技术、工具的问题，更是一个公司和组织的文化问题。首先公司从资金、管理上支持您，其次要有专门的测试团队去建立适合自动化测试的测试流程、测试体系；其次就是把原代码从受控库中取出、编译、集成、发布可运行系统、进行自动化的单元测试和自动化的功能测试的过程。 （一）、自动化测试的好处 1、对新版本执行回归测试－－测试每个特征 对于产品型的软件，每发布一个新的版本，其中大部分功能和界面都和上一个版本相似或完全相同，这部分功能特别适合于自动化测试，从而可以让测试达到测试每个特征的目的。 2、更多更频繁的测试－－沉闷、耗时 我们的产品向市场的发布周期是3个月，也就是我们的开发周期只有短短的3个月，而在测试期间是每天/每2天都要发布一个版本供测试人员测试，一个系统的功能点有几千个上万个，人工测试是非常的耗时和繁琐，这样必然会使测试效率低下。 3、替代手工测试的困难－－300个用户有些非功能性方面的测试：压力测试、并发测试、大数据量测试、崩溃性测试，用人来测试是不可能达到的。在没有引入自动化测试工具之前，为了测试并发，研发中心的一、两百号人在研发经理的口令：1－、2－、3！，大家同时按下同一个按钮。回想起这中情景也蛮有意思的。 4、具有一致性和可重复性 由于每次自动化测试运行的脚本是相同的, 所以每次执行的测试具有一致性, 人是很难做到的. 由于 自动化测试的一致性，很容易发现被测软件的任何改变。 5、更好的利用资源－－周未/晚上 理想的自动化测试能够按计划完全自动的运行, 在开发人员和测试人员不可能实行三班倒的情况下, 自动化测试可以胜任这个任务, 完全可以在周末和晚上执行测试. 这样充分的利用了公司的资源,也避免了
一0+、单项选择题 1、下列术语中，（ B ）是ISTQB术语表中缺陷(Defect)的同义词。 A、Incident B、Bug C、Mistake D、Error 2、软件测试目的可以是（B ）。 a.发现缺陷 b.确认软件能够正常运行 c.预防缺陷 d.直接提高产品的售价 e.减少整个产品开发周期时间 A、a,b B、a,b,c C、a,b,c,d D、所有选项 3、下列方式可以提高和改善测试人员和开发人员关系的是（ B ）。 A、理解项目经理工作的重要性 B、对所发现的可能的缺陷以一种中立的方式进行沟通 C、单元测试、集成测试和系统测试都由同一批测试人员来完成 D、测试人员参加代码调试 4、基本的测试过程主要由（ D ）活动组成。 a.计划和控制 b.分析和设计 c.实现和执行
d.评估出口准则和测试报告 e.测试结束活动 A、a, b 和c B、a, b, c 和d C、除e 以外所有选项 D、所有选项 5、以下关于测试原则的描述，正确的是（ B ）。 A、所有的软件测试不需要追溯到用户需求； B、完全测试是不可能的； C、测试可以显示软件潜在的缺陷； D、程序员不需要避免检查自己的程序。 6、软件测试工作应该开始于（ B ）。 A、Coding之后； B、需求分析阶段； C、概要设计阶段； D、详细设计阶段。 7、下面（C ）是一个好的测试的特点。 a.每个开发活动都有相对应的测试行为 b.每个测试级别都有其特有的测试目标 c.对于每个测试级别，需要在相应的开发活动过程中进行相应的测试分析和设计 d.软件测试的工作重点应该集中在系统测试上 A、c,d B、a,b C、a,b,c D、a,b,c,d
Windows下构建robotium+jenkins+TMTS可持续集成自动化测试 前言 TMTS是淘宝的自动化测试构架，优缺点都较为明显 优点：最主要的就是已经实现出错截屏并提供日志 缺点：比较小众化，遇到问题也无人解答 自动化测试终究是要能够持续集成才能有更大的意义的，利用 robotium+jenkins可以实现集成测试，但此时要想得到出错截屏加日志就麻烦了。 TMTS主要由三部分组成 1.TmtsFramework进行自动化用例编写 2.TmtsToolkit进行出错截屏与获取日志报告 3.hudson进行apk包的自动打包、安装，并进行用例执行 TmtsFramework编写用例其实与robotium编写用例一样都是基于instrument 的，因此想用robotium编写用例，而同时又想得到出错截屏与日志报告 就完全可以使用robotium+TmtsToolkit 因此就可以用robotium+jenkins+TmtsToolkit构建可持续集成自动化测试Windows下环境搭建 软件安装 1.安装jdk 2.安装tomcat https://www.doczj.com/doc/119322089.html,/download-70.cgi 3.安装ant https://www.doczj.com/doc/119322089.html,/bindownload.cgi 4.安装jenkins https://www.doczj.com/doc/119322089.html,/ 下载war包，放于tomcat的webapps目录下，启动tomcat将自动部署 5.安装Android SDK
https://www.doczj.com/doc/119322089.html,/sdk/index.html 搭建android开发环境，包括eclipse，ADT等 6.下载TMTS架构中的athena-1.1.jar、ddmlib.jar包 https://www.doczj.com/doc/119322089.html,/p/TMTS/src/branches/V1.1/trunk/android/AthrunTe st/ 当然最好把整个TMTS下载下来 环境变量PATH添加 \java\apache-ant-1.8.2\bin\ \java\android-sdk-windows\tools\ \java\android-sdk-windows\platform-tools\ \Java\jdk1.6.0_07\bin\ 添加ANDROID_HOME 添加JAVA_HOME 添加ANT_HOME 有什么命令找不到了就加下PATH变量 tomcat启动 运行\java\apache-tomcat-7.0.8\bin\startup.bat jenkins配置 浏览器访问 http://localhost:8080/jenkins 插件安装 Hudson Subversion Plug-in，jenkins的svn插件 Android Emulator Plugin，android模拟器插件 JUnit Attachments Plugin，junit测试报告附件插件 Email-ext plugin，邮件扩展插件。此处说明下，默认Jenkins只会发送构建失败的邮件，我们需安装此插件才能自定义不同场景 除了这些之外还可以安装其它一些插件，那样可以使得Jenkins非常强大，需要什么安装什么 构建build.xml文件，使用ant自动打apk包，构建build.xml文件及ant打包可以参考其它文章 构建任务 1.使用jenkins新建任务时，填入任务名称，选择“构建一个自由风格的软件项目”，以后新建类似任务时则可以选择“复制现有任务”
持续集成：自动化测试篇 前言 如果组件A\B\C的可靠性都为90%，是否说明了A\B\C组成的系统整体可靠性为90%？其实不是，实际结果是90% * 90% * 90%* = 73%。大部分软件系统都由几百个甚至几千个对象组成，如果包含了100个组件的线性系统，每个组件的可靠性均为99%，那么整个系统的可靠性只有37%。 如果想要构建一个在服务层面承诺到达100%或接近100%的软件系统，则必须在单个对象层面上确保可靠性。如果不能从最低层面确保并测量可靠性，就不可能在系统层面上达到要求。 这就要求我们在每当系统发生变更时测试都必须执行，并且这些测试不单单是单元测试，还应包括组件测试、系统测试等，在日常的开发过程中，反复进行多种测试无疑是枯燥乏味的，在CI系统中包含持续测试则能让你轻松解决这一烦恼。 自动化单元测试 “单元测试”是验证软件系统中所有小元素的行为，这些小元素通常都是一个类。有时单元测试和被测试的类之间一对一的关系也会被放大，因为一些测试的类耦合程度较高。 单元测试没有外部依赖关系，不会依赖于文件系统和数据库。因为编码和看到单元测试之间的时间很短，所以单元测试是一种有效的除错方法。在进行持续集成过程的单元测试时，可以利用NUnit或JUnit单元测试框架，让单元测试自动化。 真正的单元测试应该少于1秒的时间内完成。如果花费的时间较长就需要检查一下，它是否失败了，或者它实际是一个组件级测试。配置自动化测试需要一些代价，但是执行这些测试的资源代价可以忽略不计。
自动化组件测试 “组件测试”或“子系统测试”验证的是系统的各个部分，可能需要安装整个系统或某些外部依赖关系，如数据库、文件系统、网络终端等。 典型的组件测试需要底层数据库支持，甚至可能跨越架构边界，这些测试涉及更多对象，每个测试的代码覆盖率也更大，通常比单元测试需要花更长的时间，如果用到数据库可以使用DbUnit\NDbUnit实现自动化。 组件测试执行的时间比较长，可以作为次级构建的一部分来执行或定期执行。 自动化系统测试 “系统测试”允许整个软件系统，需要完整安装系统，系统测试比组件测试执行时间更长，通常涉及多个组件。 如果事先已成功执行单元测试和组件测试，则已解决一些底层问题，只需要计划定期执行这个耗时较长的测试就可以。也可以作为次级集成构建的一部分，在下班后或夜间执行。 自动化功能测试 “功能测试”也称为“验收测试”，从用户的角度测试应用程序，意味着测试将模仿用户行为，通常是自动化测试套件中执行时间最长的。 开发者测试分组 通过将测试分组，按不同的时间间隔来执行较快（如单元测试）和较慢的（如组件测试）测试，顺序可以设置为：单元测试、组建测试、系统测试、功能测试。 可以“告诉”CI系统在恰当的时候执行每一类测试，构建次数完全可管理，测试定期执行，而不是当它们需要很长时间执行时就抛弃它们。 为缺陷编写测试
1安装p y t h o n程序 下一步->下一步->Finish 2 配置环境变量
把python的安装路径添加到系统环境变量path中： Python安装成功 3 安装setuptools(直接装框架selenium的话容易出错，所以我下载了个工具辅助安装) 下载安装setuptools，解压setuptools压缩包后，用命令提示符转到安装包中所在的位置，执 行 install，进行安装 4 安装 pip（保持电脑联网） 打开cmd命令行，将目录切换到C:\Python27\Scripts下，输入命令“easy_install pip“安装pip；pip指令安装成功 5 安装 selenium（保持电脑联网） 进入所在路径（还是在C:\Python27\Scripts），运行命令行：pip install -U selenium。 成功安装selenium 注意！安装编译器有两种，eclipse或者pycharm，我推荐使用pycharm，安装pycharm的请转到单独的“安装并激活pycharm
教程.docx”文档。（下面的第6第7步是针对eclipse的安装配置） 6 安装eclipse 直接解压我的 找到文件夹下的运行即可使用（运行前请安装jdk） 安装和配置jdk请前往“WINDOWS 7 JDK 开发环境配置.doc”(这里装的是最新的jdk8，不然后面的PyDev无法正常安装) 7 安装pydev 使用eclipse添加Python解释器插件pydev。看我下面的安装截图步骤： Name：PyDev Location： OK之后等一下，正在联网查找......（大概1-2分钟） 选择PyDev，然后一路Next，进入安装路径选择界面，使用默认设置，然后 Finish。 Eclipse将下载 PyDev，可以从 Eclipse任务栏中看到下载的进度（时间比较久大约10分钟可以 去喝杯温水暖暖胃什么的） PyDev安装好后，需要重启Eclipse。 注意：安装过程可能警报 警告：你正在安装一个拥有未注册内容的软件。它的真实性和有效性（不能得到保证） 如果能确定软件的，这个可以不用管，OK继续安装 再次OK，相信此安装证书。 PyDev安装好之后，需要配置解释器。在 Eclipse 菜单栏中，选择Window > Preferences > Pydev > Python Interpreter ，在此配置 Python。首先需要添加已安装的解释器。 点击OK后跳出一个有很多复选框的窗口，最好全选，点击Ok。 到此PyDev就已经完成了配置，可以使用Eclipse开始编写Python。 在 Eclipse 菜单栏中，选择File > New >Project... Python的工程项目是这样子的;
持续集成是什么 互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称CI）。 本文简要介绍持续集成的概念和做法。 一、概念 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处主要有两个。 （1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 （2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" 与持续集成相关的，还有两个概念，分别是持续交付和持续部署。 二、持续交付 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。 三、持续部署 持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。 持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别，可以参考下图。
（图片来源） 四、流程 根据持续集成的设计，代码从提交到生产，整个过程有以下几步。 4.1 提交 流程的第一步，是开发者向代码仓库提交代码。所有后面的步骤都始于本地代码的一次提交（commit）。 4.2 测试（第一轮） 代码仓库对commit操作配置了钩子（hook），只要提交代码或者合并进主干，就会跑自动化测试。 测试有好几种。 单元测试：针对函数或模块的测试 集成测试：针对整体产品的某个功能的测试，又称功能测试 端对端测试：从用户界面直达数据库的全链路测试 第一轮至少要跑单元测试。 4.3 构建 通过第一轮测试，代码就可以合并进主干，就算可以交付了。 交付后，就先进行构建（build），再进入第二轮测试。所谓构建，指的是将源码转换为可以运行的实际代码，比如安装依赖，配置各种资源（样式表、JS脚本、图片）等等。 常用的构建工具如下。 Jenkins Travis Codeship Strider Jenkins和Strider是开源软件，Travis和Codeship对于开源项目可以免费使用。它们都会将构建和测试，在一次运行中执行完成。 4.4 测试（第二轮） 构建完成，就要进行第二轮测试。如果第一轮已经涵盖了所有测试内容，第二轮可以省略，当然，这时构建步骤也要移到第一轮测试前面。 第二轮是全面测试，单元测试和集成测试都会跑，有条件的话，也要做端对端测试。所有测
基于TestNG 与Selenium 的自动化测试设计与实施 作者：congqing2011 来源：51testing 发布于2015-12-10 何软件产品在正式发布之前都必须经过严格的测试。随着计算机技术的迅速发展，软件的结构越来越复杂，同业竞争越来越激烈。为了保证软件产 重。每次例行包发布前都需要对软件现有功能进行回归验证，确保无误以后才能发给各地现场，大家都知道电信业是个发展较快的行业，需求变更也随着耐心的减退而力不从心。为了避免这种情况，对于原有功能的自动化测试显得尤为重要。 的东西不一定适合你，我们在组合自动化测试工具时，根据自己的实际情况选择了 Selenium + TestNG + DBUnit组合，我先介绍一下这几种工具 线性脚本进行回放从而达到自动化测试的目的。其优点是简单，通过录制就可以得到所需脚本。类似于录制/回放测试工具有很多，我之所以选择Linux上的 Internet Explorer、Mozilla和 Firefox 中运行。其他测试工具都不能覆盖如此多的平台，更重要的是Selenium支持多种语言、JA
图1 本可以任意移植到多个平台，可以继承Selenium API来扩展一些我们自己的测试类，甚至可以在此基础上开发出一套属于我们自己的自动化测试平档和参考资料也相当丰富，但这些工具的局限性太大，一旦使用这些工具，你就会越来越依赖人家的东西，从而无法沉淀出自己的技术，这是我选 据驱动测试），它是Selenium IDE和Selenium RC的引擎。 行多个测试任务，极大地加快Web应用的功能测试。 um IDE录制脚本，通过Firebug辅助定位页面元素，然后通过Selenium RC来完善测试脚本。Selenium IDE是Firefox的一个插件，是可以进行依赖Firefox浏览器，如果你的程序不支持Firefox浏览器，就只能通过手工编码来完成自动化测试脚本，对于初学者来讲，如果没有这两个工具的没那么重要了。 只对JUnit比较熟悉，JUnit是 Java 语言单元测试当前的一站式解决方案。这个框架值得称赞，因为它把测试驱动的开发思想介绍给 Java开发测试已经变成一个越来越困难的任务，即 JUnit必须与其他一些补充性测试框架集成起来。而 TestNG是一个测试 Java应用程序的新框架。我选
浅谈持续集成构建在互联网软件测试项目中应用与分析the Application of Continuous & build Integration in Internet Software Testing Project and Analyzing 阿里巴巴（中国）网络技术有限公司王亮 Alibaba（Chinia）Technology Co.,Ltd. Jonas.Wong 【摘要】：本文将介绍持续集成在互联网软件项目中的应用及案例分析，主要针对互联网行业软件项目过程中的软件测试效率和质量的研究与实践；在当前Web2.0时代，笔者抓住互联网行业的软件测试特性，在软件项目的开发过程中运用持续集成构建的思想来统一规范、流程和管理，不仅提升项目在提测之前的软件版本质量，也有利于软件项目过程的效率和质量风险控制。在浅谈持续集成及工具在项目中的应用同时，也结合笔者从事互联网软件测试的工作经验，进一步阐述与总结在软件测试过程的持续集成带来的益处与不足。 笔者会先介绍当前互联网的软件测试与传统的软件测试区别与联系，然后针对互联网软件测试的特性再结合持续集成工具思想的运用，最后将比较详细的介绍Hudson持续集成构建平台在项目中的实践与分析，从而解决了在多个项目并行开发的软件项目中应该如何应用持续集成以保持项目整理开发过程的高质量和高效率问题。 【关键词】：软件测试持续集成互联网软件项目构建自动化统一代码Web2.0 ABSTARCT: A perception on constant integration application of network software testing project and analyzing, The content is mainly about constant integration application of IT software project and focus on software project testing with quality research in network line. Presently it is the time for Web 2.0, the writer grasps network feature , adopts constant integration methods unify criterion、procedure and management. Which not only enhances software version quality, but also to the benifit for software project efficiency and quality risk control. While application of constant integration and project tools, combined with writer years experience in network testing, this content will summarize advantage and shortage occuring in the constant integration procedure. Writer will show us the difference between tradition and modern methods in software testing, and software testing feature combined with the applicating on constant integration methods. Finally it is detailed introduction for Hudson constant integration adopted in projects practicing and analyzing，It solves the problems of many items application in concurrent development software testing involved how to apply constant integration to keep item procedure high quality and efficienc. KEYWORDS：software testing Constant Integration Internet software project Build Automation Uniform Code Web2.0 一、引言 在互联网信息时代，随着Internet的快速增长及Web应用的不断发展，使其快速渗透到商业、电子商务、军事、工业、教育等领域和个人生活的各个方面，对我们的生活及工作产生了深远的影响。在当今市场需求和Internet技术进步的不断推动下，Web应用日益增加，互联网的软件规模不断扩大，复杂性增加，操作易用性降低，面对互联网的用户也越来越多，因此软件的质量越来越成为人们共同关注的问题，作为保证软件质量和可靠性的重要手段，软件测试已成为互联网软件项目开发过程的重要环节。 在整个软件生命周期中每个环节都存在软件测试的活动，软件测试伴随着软件开发，以检验每一个阶段性的成果是否符合质量要求和达到预先定义的目标，尽可能早的发现问题并
1 安装python程序 下一步->下一步->Finish 2 配置环境变量
把python的安装路径添加到系统环境变量path中： Python安装成功 3 安装setuptools(直接装框架selenium的话容易出错，所以我下载了个工具辅助安装)
下载安装setuptools，解压setuptools压缩包后，用命令提示符转到安装包中setup.py所在的位置，执行setup.py install，进行安装 4 安装 pip（保持电脑联网）
打开cmd命令行，将目录切换到C:\Python27\Scripts下，输入命令“easy_install pip “安装pip； pip指令安装成功 5 安装 selenium（保持电脑联网）
进入pip.exe所在路径（还是在C:\Python27\Scripts），运行命令行：pip install -U selenium。 成功安装selenium 注意！安装编译器有两种，eclipse或者pycharm，我推荐使用pycharm，安装pycharm的请转到单独的“安装并激活
pycharm教程.docx”文档。（下面的第6第7步是针对eclipse的安装配置） 6 安装eclipse 直接解压我的eclipse-java-mars-R-win64.zip 找到文件夹下的eclipse.exe运行即可使用（运行前请安装jdk） 安装和配置jdk请前往“WINDOWS 7 JDK 开发环境配置.doc”(这里装的是最新的jdk8，不然后面的PyDev无法正常安装) 7 安装pydev 使用eclipse添加Python解释器插件pydev。看我下面的安装截图步骤：
持续集成（第二版）* Martin Fowler(英)雷镇(中) 持续集成是一种软件开发实践。在持续集成中，团队成员频繁集成他 们的工作成果，一般每人每天至少集成一次，也可以多次。每次集成 会经过自动构建（包括自动测试）的检验，以尽快发现集成错误。许 多团队发现这种方法可以显著减少集成引起的问题，并可以加快团 队合作软件开发的速度。这篇文章简要介绍了持续集成的技巧和它 最新的应用。 我还可以生动记起第一次看到大型软件工程的情景。我当时在一家大型英国电子公司的QA部门实习。我的经理带我熟悉公司环境，我们进到一间巨大的，充满了压抑感和格子间的的仓库。我被告知这个项目已经开发了好几年，现在正在集成阶段，并已经集成了好几个月。我的向导还告诉我没人知道集成要多久才能结束。从此我学到了软件开发的一个惯例：集成是一个很耗时并难以预测的过程。但是事实并非总是如此，我的ThoughWorks同事所做的项目，以及很多其它遍布世界各地的软件项目，都不会把集成当回事。任何一个开发者本地的代码和项目共享基准代码的差别仅仅只有几小时的工作而已，而且这只要几分钟的时间就可以被集成回去。任何集成错误都可以很快被发现，并被快速修复。这鲜明的差别并非源于昂贵和复杂的工具。其中的精华蕴含于一个简单的实践：使用统一的代码仓库并频繁集成（通常每天一次）。 当我向别人介绍持续集成方法时，人们通常会有两种反应：“这（在我们这儿）不管用”和“做了也不可能有什么不同”。但如果他们真的试过了，就会发现持续集成其实比听起来要简单，并且能给开发过程带来巨大的改变。因此第三种常见的反应是：“我们就是这么做的，做开发怎可能不用它呢？” *本文选自https://www.doczj.com/doc/119322089.html,/(英),https://www.doczj.com/doc/119322089.html,(中).修改日期:2010-03-17.
自动化测试ROI实践 自动化测试是一项“一旦开始，就需要持续投入”的工作，所以它一直是测试领域的一块鸡肋。不做吧，好像手工测试重复得让人有些厌倦，而且手工测试时间也缩短不了。做吧，害怕投入的比回报要多。 没实施自动化的团队有各种各样的困扰。有的说：“项目有太多的老代码需要补充自动化测试脚本，补不起！”有的说：“太紧张，如果同时还要自动化，等不起！”还有的说：“自动化测试工具太贵了！买不起！”确实，各种各样的“伤不起”使得大量的组织在“要不要自动化”这个问题上总在了解和观望，踌躇不前。 我们阅读了一些关于自动化测试ROI的文章，发现大多都是介绍各种不同的计算方法，但来自实际的分享比较少。所以，2011年当我们组织想推行自动化测试的时候，为了打消大家（尤其是管理层）对于自动化测试的投入和产出方面的疑虑，计算我们自己的自动化测试投资回报率ROI（Return on Investment）成了我们启动时就考虑的问题。本文将分为四部分介绍我们的实践方法和结果。 第一部分：业界计算自动化测试ROI的方法 简言之，ROI = 收益/投入。但收益如何计算，投入包括哪些，众说纷纭，并没有一个定论。 在Dion Johnson的“test automation ROI”中给出了三种计算自动化测试ROI的方法。第一种方法“简单ROI”着重从“钱”的方面去看。它考虑了
工具、培训、机器等各种费用，并把测试时间的投入通过单位时间的工资转化成为钱。第二种方法“效率ROI”与第一种方法不同的是从测试效率的角度，只考虑了时间投入所产生的收益，而没有考虑其它如购买工具方面的投入。这个方法比较适合测试人员计算收益。第三种方法“降低风险ROI”着重计算自动化测试与手工测试相比在降低风险方面的收益。它会假设不做某种自动化测试，相关的风险一旦成为事实所带来的损失，从而计算ROI。这个方法比较适合管理人员从整体考量自动化的收益。 那么，目前我们的团队期望自动化测试能带来哪些收益，尤其是哪些收益是目前不能奢望的？我们的经理愿意提供多少投入自动化测试呢？带着这些问题，我们开始了自己对自动化测试ROI的定义和度量。 第二部分：我们计算自动化测试ROI的方法 在度量自动化测试的收益方面，角度很多。我们选择的是从“多、快、好、省”四个方面去看。 更多 鉴于我们处于自动化测试的初级阶段，我们打算暂时先不去追求“更多”。即我们不奢望一年之内整个项目组在一个版本里做更多的工作，因为在自动化投入初期难以提高团队的生产力。我们也不奢望测试人员马上能有更多时间去做更有价值的工作（相对于一次测试的多次重复执行）。因为测试人员通过自动化测试从测试执行上节约出来的时间需要投入到自动化工具和技能的学习上去。
持续集成之“自动化部署” 在前文《依赖管理》中，我们讨论了如何在代码变得庞大，组件增多的情况下，做好外部库和内部组件依赖管理，从而提高构建效率。可以应用的实践包括：一次生成，多次复用；建立统一制品库，外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理；对架构进行调整，使一个大的代码库分成多个组件；每个组件有自己的持续集成体系；对多个组件做持续集成。然而，解决一个问题后，总会有另一个问题等在那里，需要你来解决。这次Joe的团队遇到了部署问题。 星期一早上，Alice一进办公室，就看到一脸倦意的Joe坐在椅子上，喝着咖啡。 “今天怎么来得这么早？看样子，你没睡好啊？”Alice问道。 “当然啦，昨天晚上我就来了。”Joe无精打采地回答道。 “怎么啦？” “还不是因为新版本上线出了点儿问题”，Joe说道。“看来我们要把部署这件事好好讨论一下，再这样下去，不只我要来，你们也要和我一样啦！呵呵！” 当天下午，Joe邀请了运维团队的主要负责人Tom和Steven，召开了一个关于部署问题的讨论会。 Joe说道：“先请运维部门的Tom介绍一下上周末的新版本上线过程和发现的问题吧。” Tom描述了上线部署全过程。 不可重复且不可靠、易出错的手工部署过程 1.当新版本开发测试完成后，由开发团队的成员在浏览器上登录运维平台，填写上线 申请单。申请单的内容包括新版本的上线部署步骤。 2.测试人员为了保证能够升级部署成功，首先要复制生产环境中的程序和数据到本地 的测试环境中，然后根据上线申请单中所描述的上线部署步骤进行操作，对上线步骤进行验证。 3.运维人员登录到运维平台，收到上线申请单后，确认“已收到”。 4.运维人员发现上线部署步骤有问题，生产环境的路径与上线部署步骤中描述的不一 致。于是与开发人员进行沟通，让开发人员修改上线部署步骤。 5.开发人员修改后，再次通知测试人员和运维人员查看并确认。 6.确认无误后，运维人员根据部署计划，登录到生产环境中，依照上线部署步骤，手 工操作完成。