基于JAVA实现的WEB端UI自动化 -自动化测试简单介绍

---

专栏系列（点击解锁）	学习路线指引	知识定位
??Python全栈白皮书??	零基础入门篇	以浅显易懂的方式轻松入门，让你彻底爱上Python的魅力。
	语法进阶篇	主要围绕多线程编程、正则表达式学习、含贴近实战的项目练习 。
	自动化办公篇	实现日常办公软件的自动化操作，节省时间、提高办公效率。
	自动化测试实战篇	从实战的角度出发，先人一步，快速转型测试开发工程师。
	数据库开发实战篇	更新中
	爬虫入门与实战	更新中
	数据分析篇	更新中
	前端入门+flask 全栈篇	更新中
	django+vue全栈篇	更新中
	拓展-人工智能入门	更新中
络安全之路	踩坑篇	记录学习及演练过程中遇到的坑，便于后来居上者
	安知识扫盲篇	三天打鱼，不深入了解原理，只会让你成为脚本小子。
	vulhub靶场漏洞复现	让漏洞复现变得简单，让安全研究者更加专注于漏洞原理本身。
	shell编程篇	不涉及linux基础，最终案例会偏向于安全加固方向。 [待完结]
	WEB漏洞攻防篇	2021年9月3日停止更新，转战先知 区等安全 区及小密圈
	渗透工具使用集锦	2021年9月3日停止更新，转战先知 区等安全 区及小密圈
点点点工程师	测试神器 – Charles	软件测试数据包抓包分析神器
	测试神器 – Fiddler	一文学会 fiddle ，学不会倒立吃翔，稀得！
	测试神器 – Jmeter	不仅是性能测试神器，更可用于搭建轻量级接口自动化测试框架。
	RobotFrameWork	Python实现的自动化测试利器，该篇章仅介绍UI自动化部分。
	Java实现UI自动化	文档写于2016年，Java实现的UI自动化，仍有借鉴意义。
	MonkeyRunner	该工具目前的应用场景已不多，文档已删，为了排版好看才留着。

文章目录

• • 1 – Web自动化测试简介
  • • 1.1 自动化测试的本质
    • 1.2 自动化真的具有绝对的高效性/li>
    • 1.3 手工测试与自动化测试的比较
    • 1.4 手工测试的局限性与自动化测试的优势
    • 1.5 自动化测试介入的场景
    • 1.6 自动化测试的流程
    • 1.7 适合自动化测试的工具
  • 2 – 常用的自动化测试工具
  • • 2.1 QTP
    • 2.2 Selenium(Webdriver)
    • 2.3 UFT(Unified Functionnal Testing)
    • 2.4 RFT(IBM Rational Functionnal Tester)
    • 2.5 Monkeyrunner(手机自动化工具)
    • 2.6 Robotium(手机自动化工具)
    • 2.7 Sikuli(新型思路的自动化测试工具)
    • 2.8为什么选择Selenium(Webdriver)
  • 3 – 测试自动化和自动化测试
  • • 3.1 什么是测试自动化/li>
    • 3.2 什么是自动化测试/li>
    • 3.3 不同的工程师，工作不同
    • 3.4 自动化测试的几个准则：
    • 3.5 测试自动化的几个准则：
  • 4 – 自动化测试三个阶段
  • • 4.1 基本脚本设计阶段
    • 4.2 框架脚本设计阶段
    • 4.3 平台设计阶段
  • 5 – 自动化环境搭建准备与相关工具
  • • 关于浏览器
    • Selenium IDE(火狐浏览器上的插件)
    • Java环境
    • Eclipse/IDEA
    • WebDriver Jar包
    • 单元测试框架 Testng

基于JAVA实现的WEB端UI自动化 -自动化测试简单介绍

基于JAVA实现的WEB端UI自动化 – WebDriver基础篇 – 实现简单的浏览器操作

基于JAVA实现的WEB端UI自动化 – WebDriver基础篇 – 元素定位

基于JAVA实现的WEB端UI自动化 – WebDriver基础篇 -常见的页面元素操作

基于JAVA实现的WEB端UI自动化 – WebDriver基础篇 – iframe元素定位

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 元素定位场景分析

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 获取测试对象属性

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 获取测试对象状态

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 第三方控件类操作

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 执行JS操作

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – WebDriver的三种等待方式

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 模拟键盘操作

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 代码检查点[验证点/断言]与图像检查点

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 验证码处理

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – cookie操作

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – 关联

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – exe文件执行

基于JAVA实现的WEB端UI自动化 – WebDriver高级篇 – grid [跨浏览器远程测试-可分布式]

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – 框架设计小结

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – testng使用

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – ant使用 – 关于如何手动下载JAR包

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – ant使用 – ant安装、环境变量配置、ant实例及运行Ant Build 出现问题的解决方法

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – ant使用 – ant调用testng文件及ant 调用testng遇到的问题

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – ant使用 – ant调用email 自动发送邮件

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – ant使用 – ant发送邮件显示源码的解决方法

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – XSLT ( 告、模板框架)

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – Jenkins[定时计划执行任务]

基于JAVA实现的WEB端UI自动化 – WebDriver框架篇 – 内部框架及UI自动化测试框架思维导图

1 – Web自动化测试简介

• 软件测试领域技术不断创新
• 手工测试重复性工作量较大
• 技术革新，通过使用工具或者脚本代码让计算机帮助测试人员完成一些简单操作

1.1 自动化测试的本质

• 其本质是把手工测试转化成使用计算机、软件、程序来测试产品的过程。在设计
  测试用例并通过评审之后，由测试人员根据测试用例中描述的步骤来一步一步执 行测试代码，得到的实际结果与期望结果进行比较。

• 重复姓的测试工作在时间紧迫的情况下会有范围遗漏，为了节省人力、时间、资 源、提高测试效率，保证测试范围，引入了自动化测试概念。

1.2 自动化真的具有绝对的高效性/h3>

• 自动化并不是绝对的完全高效率。
• 在产品需求变更频繁，项目周期较短，开发人员代码不够规范的情况下，给自动化脚本的编写也带来大量的修改。甚至因为开发人员编写的代码的问题从而提升 了自动化脚本编写的难度，需要花费大量的时间去解决一些脚本编写过程中遇到 的一些未知的问题，那么这种情况下，手工测试往往要比自动化测试要更有效率。

1.3 手工测试与自动化测试的比较

• 通常情况下，测试的工作量会占据整个项目的的40%-60%的开发时间，甚至有的
  时候开发工作还没有开始，测试人员就已经介入了项目。
  测试过程中，许多的过程是重复性、非智力性、非创造性、并要求做准确细致的工作，这个时候计算机就是最适合代替人工去完成这样任务的角色。
• 自动化测试是相对手工测试而存在的，主要是通过软件测试工具、脚本等来实现的，自动化测试脚本具有良好的可操作性、可重复利用性和效率高等特点。

1.4 手工测试的局限性与自动化测试的优势

手工测试的局限性：

• 手工测试无法覆盖所有的代码路径
• 简单的功能性测试用例在每一轮的测试中都不能少，而且具有一定的机械性、重 复性，工作量较大，影响效率。
• 举例：如果有大量（几千）的用例，短时间内，手工测试往往是做不到的。

自动化测试的优势：

• 缩短软件开发测试周期，可以让产品更快的投放市场。
• 测试效率高，可以充分利用硬件测试资源
• 节省人力资源，降低测试成本
• 增强测试的稳定性和可靠性
• 提高软件测试的的准确度和精确度，从而增加软件的信任度
• 使测试工作相对比较容易，但能产生更高质量的测试结果

附：自动化测试绝不是因为厌倦了重复的测试工作，想要取代掉手工测试。相反的 是因为测试工作的需要，更准确的说是为了回归测试和系统测试的需要。

1.5 自动化测试介入的场景

那么问题来了，自动化能否取代手工测试/p>

首先，我们要考虑的是，什么样的项目适合自动化/p>

• 决定项目能否采用自动化测试，通常从以下几个方面考虑：
  • 需求的变更有计划性，且变更的频率不高
  • 项目的周期较长，硬件软件人工资源配置丰富。
  • 自动化脚本的重复使用率高
  • 开发人员代码编写的规范性

在确定了什么样的项目可以使用自动化之后，身为测试人员还要考虑在项目中， 那些部分适合自动化。

• 普遍的观点是：很多人认为自动化更适合回归测试和API测试，手工测试更 适合做验收测试和GUI测试。

• 其实正确的观点：区分手工测试和自动化测试的，实际上与API还是GUI，回归测试还是功能测试都没有关系。应该从代码是业务逻辑相关还是基础性代码这两个方面出发考虑。

  • 业务逻辑代码：对应终端用户使用的哪些功能，是实际完成工作的。

  • 基础性代码：确保业务逻辑代码运行在合适的环境中。起支撑作用而彼此之间又相对独立，并不存在业务关系。

  • 两种代码都要测试，手工测试更适合测试业务逻辑。

• 手工测试适合成为领域专家，他们可以把想当复杂的业务逻辑存在最强力的测试工具—大脑里。而且手工测试速度比较慢，测试人员就有时间可以观察分析细微的逻辑问题。速度虽然慢，但是比较容易。

• 自动化测试胜在测试底层的细节。自动化可以测试错误返回值、返回码、异常和内存使用等等。速度快但是也困难些。相对业务逻辑进行自动化测试比较困难， 风险也略大。

1.6 自动化测试的流程

需求分析>>>自动化测试规划>>>自动化测试脚本编写>>>测试执行>>>测试总结

自动化测试规划：功能>>>自动化>>>安全（渗透）>>>性能

关于”安全（渗透）”这一块的”自动化”16年在写这一份文档的时候仅仅停留在字面的概念上，随着近两年学习从事安全领域以及所做的一些漏洞挖掘之后对这一块有了很深刻的印象。比如圈内一些很厉害的白帽子师傅通过自己编写的自动化脚本以及POC、EXP然后进行全 的扫描[此时已经不仅仅是局限于某个产品端了],可以挖掘大量的高危漏洞甚至可以直接getshell。

需要说明的是 “安全（渗透）测试” 虽然也是”测试”，但与传统意义上的软件测试还是有很大区别的。就我个人的理解 “安全（渗透）测试” 是一门领域性的技能和应用场景，虽然在某些方面有些许的重叠，比如安全领域的”逻辑漏洞” 与测试人员测出的功能上的BUG 。但是其还是有本质上的区别的。

1.7 适合自动化测试的工具

• 支持脚本化语言(Scripting Language)
• 对程序界面中对象的识别能力
• 支持函数的可重用性
• 支持外部函数库
• 抽象层—将程序界面中的对象实体映射成逻辑对象
• 支持数据驱动测试(Data-Driven Test)
• 错误处理
• 调试器(Debugger)
• 源代码管理
• 支持脚本的命令行(Command Line)方式

2 – 常用的自动化测试工具

2.1 QTP

• QTP是由HP提供的侧重于功能的回归自动化测试工具；提供了好很多插件，如.NET的，Java的，SAP的，Terminal Emulator的等等，分别用于格子类型 的产品测试。默认提供Web，ActiveX和VB。【讲道理,目前我所接触的项目还没有使用该工具的前几年从朋友那里了解到 交行与东航貌似还在使用该工具，不过该工具的最新版本已经叫 “UTF” 了,下文有介绍】

• QTP 的脚本语言是VBScript，这对于测试人员来说，感觉要“舒服”的多。VBscript毕竟是一种松散的、被阉割的、普及面很广的语言。【其实就是弱类型语言】

2.2 Selenium(Webdriver)

• 价格：开源、免费
  相较于QTP而言（商业版、收费的、一个lessons大概价格100万美金左右）
  绝大多数的公司在商业版软件上更愿意选择使用Selenium完成同样工作的高级自动化测试人才，毕竟大多数的公司的最终目的还是以营利为主。【插句题外话,商业版的软件往往在 告输出上做的非常完善。】

• 应用领域：基于浏览器的Web端自动化测试，Selenium仅支持Web页面的测试工作；
  QTP不仅支持Web界面的测试工作，还支持Client方面的测试，这一点上是 Selenium的不足之处。

• 框架处理能力：
  在数据驱动方面，QTP支持很灵活，可以通过简单的设置就可以完成数据驱动的自动化脚本。
  Selenium需要编程来实现才可以。但是这点并不能说明Selenium在框架的处 理能力上就比QTP差。Selenium提供了更加开阔的框架处理能力给客户看， 用户可以根据自己的实际情况开发出更适合自己的自动化测试脚本。
  举例：在进行Web端页面测试的过程中，我们不能保证页面就是恒定不变的， 所以这个时候，在自动化测试平台中就可以有一个页面层，页面变化了，只 需要通过修改页面层的代码（元素定位）来适应，而不需要去修改在页面之 后的测试用例代码。这样就可以简化我们的代码的工作量。

• 用户仿真：
  Selenium在浏览器后台执行，它通过修改HTML的DOM（文档对象模型）来 执行操作，实际上是通过JavaScript来控制的。执行时窗口可以最小化，可以 在同一个机器执行多个测试Case。
  QTP是完全模拟终端用户，独占屏幕，同一时间只能开启一个独占的实例。
  在并发性上来讲，Selenium更好一些。

• UI组件支持：
  Selenium支持主要的组件，但是某些特殊事件、方法和对象属性支持不够
  QTP提供了良好的支持，通过收费的插件，提供了对各种组件的支持。

• 对象识别：
  QTP所见即所得，用SPY插件、对象库的方式获取
  Selenium提供的是各种对象识别接口来识别

• 支持的平台：
  Selenium支持多种语言，可以跨平台。
  QTP只使用于windows。

• 脚本创建：
  QTP视乎更容易一些
  Selenium略难，需要一定的代码知识能力

2.3 UFT(Unified Functionnal Testing)

UFT是QTP的新名字，叫统一功能测试框架，较QTP而言增加了一些新的功能。

• Insight智能图像识别
  图像识别一直是自动化测试的阻碍之一。包含游戏自动化、flash动态的一些 自动化。
  附：这个图像识别比较类似sikuli的方式，以图像方式进行识别，所以对验证 码等的识别没有太大的作用。（白兴奋了 o(╯□╰)o）【不知道几年过去了,UFT这方面有没有长进】

• 多脚本调试（个人观点，鸡肋。类似于开多个窗口进行调试）

• PDF文本验证点
  现在UFT可以识别PDF文件并对他们直接进行比较，甚至可以插入文本验证点。

• 支持开源CI（鸡肋，现在大多数自动化测试工具都支持CI）

• 支持移动设备（仍然鸡肋，移动端自动化的工具也很多）

2.4 RFT(IBM Rational Functionnal Tester)

• 框架结构：
  RFT的脚本可以分别被归类为AppObjects、Tasks和Testcases
  AppObjects：定义页面上的元素。在测试过程中，所有用到的页面元素都定
  义并储存在这一层中，这一层还包含了所有页面上显示的字符串。
  Tasks：定义可以单元化，可重用的任务，调用在AppObjects中定义的元素。
  Testcases：一个case写成一个脚本，每个测试场景，可以写成一个或多个脚 本，每个脚本只调用Tasks中定义的可重用的任务。
  附：这个架构的分层架构思路基本与WebDriver的分层架构思路一致。

• 传播与使用范围

  • 帮助文档和教程很少，很不系统。而提供额API接口只有说明文档，未 提供如何使用该文档；提供的例子很少。
  • 环境要求较高，至少得1G内存才能比较顺畅使用，512内存比较卡， 速度慢
  • 参数化只支持使用XML格式文件来存储测试数据
  • 回放速度超级慢
    附：所以才有了Selenium开发以后的强势和很多之前RFT使用者可以快速上手。

2.5 Monkeyrunner(手机自动化工具)

目前Android SDK里自带的现成的测试工具

Monkey和MonkeyRunner

Monkey：主要用于压力和性能测试上，运行该命令可以随机地向目标程序发送各种模拟键盘事件流，并且可以自定义发送的次数，以此观察被测应用程序的稳定性和可靠性，应用比较简单，记住那几个命令就可以了。

MonkeRunner：相比较之下更强大一些，主要用于功能测试，回归测试。并且可以自定义测试扩展，灵活性较强，测试人员可以完全控制。

2.6 Robotium(手机自动化工具)

Robotium是一款测试Abdroid Application的测试框架，它使得编写黑盒测试代码更 加容易和稳定。通过使用Robotium，测试用例开发人员能够跨越多个Activity，开 发出功能、系统以及验收测试用例。
Robotium是基于Android测试框架InstrumentTestCase2进行的2次封装，把一些基 本操作又简化了一遍。

也是最近比较流行和正在上升势头的手机自动化测试工具。

优势如下：

• 针对黑盒测试
• 在测试过程中，不必需要测试程序的源代码，只要apk文件（前提是需要知 道测试程序的package和activity）
• 可以直接运行在手机上，并通过adb端获得运行结果。

2.7 Sikuli(新型思路的自动化测试工具)

创新的图形化编程技术

Sikuli是由MIT的研究团队发布的新型图形化编程技术。它以图像检索技术为基础， 提供了一套基于Jython(Python语言在java中的完整实现)的脚本语言以及集成开发 环境。使用者可利用屏幕截图直接引用GUI元素进行编程，完成交互操作。Sikuli 一词取自墨西哥Huichol Indian 土著语，意为“上帝之眼”，正如其开发者所说–Sikuli 让电脑能像人一样“看”这个“真实世界”。

• Sikuli脚本
  Sikuli的脚本编写遵循Python语法规范，其本身提供了多种自定义类及其自 定义方法，其详细介绍可参见其官方 站文档。由于Sikuli基于Jython，其核 心代码由Java编写，可在用户自定义的Java工程中将其作为Java标准类库 进行引用，其官方 站亦提供了JavaDoc供参考。

• 下图为自动打开FireFox浏览器，并登陆Gmail的简单实例，快速一览Sikuli 脚本的独特之处。