自动化扫盲

单元测试

关注代码的实现逻辑

例如：一个if 分支或一个for循环的实现；

集成、接口测试

关注的一是个函数、类（方法）所提供的接口是否可靠。

例如：定义一个add()函数用于计算两个参数的结果并返回，那么我需要调用add()并传参，并比较返回值是否两个参数相加。

接口测试也可以是url的形式进行传递。

例如，我们通过get方式向服务器发送请求，那么我们发送的内容做为URL的一部分传递到服务器端。

UI层的自动化测试

例如：不断重复的对一个表单提交，结果查询等功能进行测试

   UI层的自动化测试工具

比较主流的是QTP，Robot Framework、watir、selenium 等

什么项目适合做自动化测试？

1.软件需求变动不频繁

需求变动频繁使得自动化测试脚本维护成本高

2.项目周期长

自动化测试需求的确定、自动化测试框架的设计、测试脚本的编写与调试均需要相当长的时间来完成

3.自动化测试脚本可重复使用

自动化测试脚本的重复使用要从三个方面来考量：

     1.所测试的项目之间是否具有很大的差异性（如C/S系统和B/S系统的差异）；

     2.所选择的测试工具是否适应这种差异；

     3.测试人员是否有能力开发出适应这种差异的自动化测试框架。

选择什么工具进行自动化测试

桌面程序（B/S架构）的工具有：QTP、 AutoRunner

推荐qtp：QTP在UI自动化测试领域占到了一半的试用率。所以，足以说明QTP在自动化领域强大，易用

web应用（C/S架构）的工具有：QTP、AutoRunner、Robot Framework、watir、selenium

推荐selenium：selenium 对B/S应用支持很好，它支持多语言的开发，真正的使用selenium 需要掌握selenium工具+学习一门语言。

增加竞争力：掌握了工具+使用所学的语言去做更多的事情。

selenium 是支持java、python、ruby、php、C#、JavaScript 。

　　从语言易学性来讲，首选ruby ，python

　　从语言应用广度来讲，首选java、C#、php、

　　从语言相关测试技术成度（及 资料）来讲：ruby ,python ,java

• selenium IDE(支持web自动化测试)
  • 完成界面元素定位
  • 窗口跳转
  • 结果比较
• 特点
  • 支持多款浏览器
  • 支持多种语言
  • 支持多种操作系统
  • 开源免费
• 由多个工具组成
  • Selenium IDE
    • 构建脚本，可录制
    • 可用来快速熟悉Selenium命令
    • 实际使用不多
  • Selenium RC
    • ClientLibraries
      • 编写测试脚本
      • 控制SeleniumServer的库
    • SeleniumServer（控制浏览器行为）
      • Launcher（用于启动浏览器 ，把Selenium Core加载到浏览器页面当中，并把浏览器的代理设置为HttpProxy。）
      • Http Proxy
      • Core（使用seleniumserver嵌入浏览器页面，是一堆JavaScript函数集合，通过这些函数实现用程序操作浏览器）
  • Selenium WebDriver（selenium2.0加入）
    • selenium 2.0 = selenium 1.0 + WebDriver    WebDriver 是selenium RC 的替代品
  • Selenium Grid
    • • Grid通过利用现有的计算机基础设施，能加快Web-app的功能测试。利用Grid，可以很方便地同时在多台机器上和异构环境中并行运行多个测试事例。其特点为：

        · 并行执行

        · 通过一个主机统一控制用例在不同环境、不同浏览器下运行。

        · 灵活添加变动测试机

selenium学习路线

1、配置测试环境，针对所学习语言，来配置相应的selenium 测试环境。同样的语义在不同的语言下会有不同的写法（语法）。

2、熟悉webdriver API ，API就是selenium 所定义一方法，用于定位，操作页面上的各种元素。

　　先学习元素的定位，selenium 提供了id、name、class name、 tag name、link text、partial link text、 xpath、css、等定位方法。xpath和css 功能强大语法稍微复杂，在这其间你可能还需要了解更多的前端知识。xml ,javascript 等。

　　定位元素的目的是为了操作元素，接就要学习各种元素有操作，输入框，下拉框，按钮点击，文件上传、下载，分页，对话框，警告框...等等。

　　经过一段时间的学习，你可以游刃有余的模拟手工测试来操作页面上的各种元素了。接着你需要做的就是把这些“用例”组织起来，统一来跑。

　　那么你需要做的就是学习并使用单元测试框架，单元测试框架本身就解决了用例的组织与运行。

　　当你写了一些“测试用例” 之后，你会发现用例中有大量重复的操作，能不能写到一个单独的文件中，需要的时候调用这些操作？当然可以，运用你的编程能力来实现这一点将非常简单。然后，你又发现每个用例中都有一些数据，这些数据也是一样的，但如果变化了修改起来非常麻烦，你也可以把他写到一个单独的文件中进行读取。

　　接着你又遇到了新的疑问，我写的脚本（用例）都是流水式的，我怎么知道用例运行失败还是成功。那么就需要在脚本中加一些验证与断言。

　　接着你又有了更多的想法，单元测试框架的log太简陋了，能不能生成一张漂亮的测试报告出来。我能不能定时的来跑这个脚本。能不能把每一次跑脚本的测试结果直接发到我的邮箱。能不能......

　　为解决这些问题，你不得不学习更多的编程技术，然后你的“测试结构”会功能越来越强大，越来越灵活。产生了一定的通用性和移植性。一个有模有样的自动化测试框架诞生了。

 　　假如，有一天你不再做UI的自动化测试了，你会发现你去做单元测试 或接口测试基本没什么难度。开发个测试工具之类的也不在话下