自动化测试

‍ 在做web项目的 自动化 端到端 测试 时主要使用的是 Selenium ? WebDriver 来驱动浏览器。 Selenium WebDriver 的优点是支持的语言多，支持的浏览器多。主流的浏览器Chrome、Firefox、IE等都支持，手机上的浏览器Android、IPhone等也支持，甚至还支持PhantomJS(由于PhantomJS跑 测试 时并不需要渲染元素，所以执行速度快)。 使用 WebDriver 遇到的那些坑 webdriver 实用干货 但是我在使用 Selenium WebDriver 时，遇到了很多坑。这些问题，有的是因为 Selenium WebDriver 与浏览器不同版本之间兼容性的问题，有的是 Selenium WebDriver 本身的bug，当然也不乏自己对 Selenium WebDriver 某些 功能 理解不透彻。我花时间总结了一下，分享给大家，希望大家以后遇到问题可以避过这些坑，少走弯路。另外也总结了一些使用 WebDriver 的比较好的实践，也一并分享给大家。 WebDriver 每次启动一个Firefox的实例时，会生成一个匿名的profile，并不会使用当前Firefox的profile。这点一定要注意。比如如果访问被 测试 的web服务需要通过代理，你想直接设置Firefox的代理是行不通的，因为 WebDriver

1，软件测试方法： 1 ） 黑盒测试 和 白盒测试 、灰盒测试； 2 ）静态测试和动态测试； 3 ）人工测试和自动化测试。 2，软件测试的极端情况 任何软件产品都可以使用以下的两种方法之一进行测试： 1）已知产品的 需求规格 ，但 不知道其内部实现 ，可以进行 测试证明每个需求是否实现 。 2）已知产品的 内部实现过程 ，可以通过测试证明 1每种内部操作是否符合设计规格 的要求，所又内部成分是否已经检查。 计算例子：1.参照SRS直接计算器的加法，这就是黑盒测试。 2.参照LLD根据加法主函数的伪函数或者流程图测试主函数的结构，就是白盒测试。 3，什么白盒测试 白盒测试是依据被测软件分析程序内部构造，并根据内部构造设计用例，来对内部控制流程进行测试，可完全不顾程序整体功能实现情况。 白盒测试时基于程序结构的逻辑驱动测试。 白盒测试又可以称为玻璃盒测试、透明测试、开放盒测试、结构化测试、逻辑驱动测试。 4，为什么要进行白盒测试 白盒测试一般在 测试前期进行 ，通过达到一定的 逻辑覆盖率指标 ，使得软件内部逻辑控制结构上的问题基本得到消除。 白盒测试能 保证内部逻辑结构 达到一定的覆盖程度，能够 给予软件代码质量的保证 白盒测试发现问题后 解决问题成本较低 关心内部实现逻辑问题基本得到消除 5，白盒测试常用的技术： 静态分析和动态分析 1、 静态分析： 控制流分析、数据流分析

　　TDD是现在很流行的一种软件开发实践。此文一作个人体会总结，二作给对TDD有兴趣的但是还不是很熟悉的同学一个分享。 　　对TDD本文从三个方面加以说明：What, Why, How. 　　首先说明什么是TDD。全称是测试驱动开发。从字面可以看出其中包含两层含义。我们把实现产品功能的代码称为产品代码，第一层含义就是编写的代码需要有测试。这些测试也是以代码的形式存在，称为测试代码。因此很容易通过这些测试代码对产品代码进行自动化测试。这些测试可以分为：单元测试，集成测试，功能测试。这些不同种类的测试具体是做什么的会在How的段落加以说明。TDD的第二层含义就是“驱动”二字，也就是说先写测试代码，然后再编写产品代码让测试代码通过。 　　关于Why，同样从上面提到的两层进行解释。如果没有自动化测试，那么只能使用手工测试。编写自动化测试需要一定的代价，肯定要比手工测试付出更多的工作。但是一旦测试编写出来就可以被反复的使用，把测试人员从繁重而重复的手工测试中解放出来，从而能让他们更多的把精力放在用户体验和探索性测试上。如果产品代码有完备的测试覆盖，那么开发人员就可以放心的去添加新功能，而不用担心自己不知不觉引入的bug或者破坏了之前的功能，因为你可以通过运行一遍之前所有的测试来得到快速的反馈，从而趁热打铁，对代码行进及时修改。那么为什么要测试先行呢

自动化测试 分层的自动化测试 传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。 单元测试关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；那么集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。 为什么要画成一个金字塔形，则不是长方形 或倒三角形呢？ 这是为了表示不同阶段所投入自动化测试的比例。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果你妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。 既然UI层的自动化测试这么劳民伤财，那我们只做单元测试与接口测试好了。NO! 因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该更多的精力放在UI层。那么也正是因为测试人员在UI层投入大量的精力，所以，我们有必要通过自动化的方式帮助我们“部分解放”重复的劳动。 在自动化测试中最怕的是变化，因为变化的直接结果就是导致测试用例的运行失败，那么就需要对自动化脚本进行维护；如何控制失败，降低维护成本对自化的成败至关重要。反过来讲

　　前两个月，Boss说要搞自动化测试，这里说明一下，之前公司测试都是测试人员手动点来点去（个人觉得这样确实比较蛋疼，手点麻了也测不出太多的BUG，还要反复操作相同的步骤，这也有些太难为我们公司搞测试的两个小妹妹了。） 　　开始决定是用 selenium工具，决定了就开始干起来，安装Eclipse，JDK，配置环境变量.......！这里说一下，本公司测试人员没有太多开发经验，所以这些都是在开发人员协助下完成的，风风火火前前后后差不多搞了一个星期，就在我们觉得可以用的时候，发现问题一大推，测试人员对工具不熟悉，测试用例不太会编写，最主要的是程序一直不稳定，这个时候真心觉得太TM坑爹了，搞了这么长时间竟然不能用。由于本公司两位测试人员开始不知道有C#版本的，就用JAVA版本的来部署，结果CTO建议改用C#版本，所有又从新来过。 　 　　在决定换版本之前，我们开了一个研讨会，讨论接下来这个事到底该怎么搞，避免再做无用功。会议 上，公司的屌丝都积极发言，并且就在会议上，我们简单部署了一下测试环境，（本公司的单元测试之前已经实现自动化，用Nunit+CruiseControl，在CruiseControl上面可以很直观看到单元测试的运行结果，有错误会自动提示，现在我们想做的就是把系统测试也部署到CruiseControl上面，）录制了一个测试用例，然后把录制生成的代码Copy到测试类里面

CI: 持续集成（CONTINUOUS INTEGRATION） 在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。 持续集成（CI）是一种软件开发实践，开发人员经常在其中进行代码更改并将其添加到中央存储库中，然后再运行自动化测试。CI是软件发布过程的集成阶段，它取决于自动化和持续集成。主要目标是发现错误并迅速解决问题，以提高软件质量并缩短产品上市时间。 在持续集成中，开发人员一天要专注于较小的提交。开发人员将代码从存储库中拉出，然后再将其推送到构建服务器，构建服务器将在其中运行各种测试以验证代码提交。 CD:(1) 持续交付（CONTINUOUS DELIVERY） 持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。 通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。 但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。 持续交付是一种软件开发实践

自动化测试模型是自动化测试架构的基础，自动化测试的发展也经历的不同的阶段，不断有新的模型 （概念）被提出，了解和使用这些自动化模型将帮助我们构建一个灵活可维护性的自动化架构。 4.1.1 线性测试 通过录制或编写脚本，一个脚本完成一个场景（一组完整功能操作） ，通过对脚本的回放来进行自动 化测试。这是早期进行自动化测试的一种形式；我们在上一章中练习使用 webdriver API 所编写的脚本 也是这种形式。 测试脚本一 from selenium import webdriver import time driver = webdriver.Firefox() driver.get( "http://wwww.xxx.com" ) driver.find_element_by_id( "tbUserName" ).send_keys( "username" ) driver.find_element_by_id( "tbPassword" ).send_keys( "123456" ) driver.find_element_by_id( "btnLogin" ).click() # 执行具体用例操作 ...... driver.quit () 测试脚本二 from selenium import webdriver import time 博客园 --- 虫师 http:/

Python语言有一个特点就是不特别强势，可是它能够使用都非常的多范畴，并且效率高的可怕，Python的使用范畴非常多，现在国内越来越多的人学习Python，从最开始遇到IP被封导致没法正常爬取的爬虫工作，我们可以使用来解决，到现在Python还有什么发展方向呢？ 1、Python web全栈工程师 我们都知道，全栈工程师不管在哪个语言中都是人才中的人才，Java全栈工程师的薪资在30K左右，而Python web全栈工程师则会高出20K，所以若是你能力足够，首选就是Python web全栈工程师。 2、Python自动化测试 只要是和自动化有关系的，Python这门语言都可以发挥出巨大的优势，目前做自动化测试的大部分 工作者都需要学习Python帮助提高测试效率，作自动化测试的人都明白，会不会Python是两回事。 3、大数据 我们现在是真正的大数据时代，而Python这门语言在大数据上比Java更加有效率，大数据虽然难学，但是Python可以更好地和大数据对接。 4、数据分析、爬虫 做数据分析的现在也是需要学习Python的，Python可以更快的提升对数据抓取的精准程度和速度，这对于做数据分析的人来说再好不过了，若是你还在用表格的阶段，可以尝试提升一下自己了。 5、自动化运维 根据了解，现在好像没有太多的运维工作者不需求Python，只要还有一点上进心的，想着未来今后的发展

本文是转载“虫师”的文章http://www.cnblogs.com/fnng/p/3653793.html 因为我感觉这篇文章写的很好，但是没有收藏功能，所以在自己的博客转载 希望“虫师”老师能够谅解！在此感谢“虫师”老师的分享！！！！！！！ 什么是自动化测？ 　　做测试好几年了，真正学习和实践自动化测试一年，自我感觉这一个年中收获许多。一直想动笔写一篇文章分享自动化测试实践中的一些经验。终于决定花点时间来做这件事儿。 　　首先理清自动化测试的概念，广义上来讲，自动化包括一切通过工具（程序）的方式来代替或辅助手工测试的行为都可以看做自动化，包括性能测试工具（loadrunner、jmeter）,或自己所写的一段程序，用于生成1到100个测试数据。狭义上来讲，通工具记录或编写脚本的方式模拟手工测试的过程，通过回放或运行脚本来执行测试用例，从而代替人工对系统的功能进行验证。 　　当然，我们更普遍的认识把“自动化测试”看做“ 基于产品或项目UI层的自动化测试”。 分层的自动化测试 　　这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。 　　相信测试同学对上面的金字塔并不陌生，这不就是对产品开发不同阶段所对应的测试么！我们需要规范的来做 单元测试同样需要相应的单元测试框架，如java的Junit

　　如果在你的理解中自动化测试就是在eclipse里面讲webdriver的包引入，然后写一些测试脚本，这就是你所说的自动化测试，其实这个还不能算是真正的自动化测试，你见过每次需要运行的时候还需要打开eclipse然后去选择运行文件吗？没有吧！应为那样真的是很low的！下面说一下经理的两种自动化测试：一、将脚本写好，放在服务器，通过定时任务去执行，这个是针对每天或者一些时间段需要执行的任务去做的，但是运用比较少，之前是用来定时检查线上所有的接口开发的一套系统。二、就是本文讲的。 　　进入正文，先说一下我们的思想： 　　　　1、使用eclipse 加上webdriver 把我们的脚本写好。 　　　　2、所有的脚本不可能放在同一个文件夹里面，有的需要执行多次，但是有的只需要一次，这个我们通过testng去实现，在我们的testng框架里面这个能够轻松实现，所以我们就将脚本中加如了testng。 　　　　3、testng虽然能够将脚本很好的规划好，但是他不能够自动运行，我们必须每次打开运行，比较麻烦，所以我们就想到了我们经常用到构建项目的jenkins，所以我们就需要在现在的框架上引入jenkins。 　　　　4、引入后，如何将他们结合下面来仔细说说 一、需要的工具、包 　　1、eclipse 这里必须把环境变量什么的都配置好。　 　　2、selenium 的jar包 　　3