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

程序员二黑①

于 2024-05-20 22:19:00 发布

阅读量77

点赞数 3

文章标签：自动化 python 压力测试软件测试自动化测试

本文链接：https://blog.csdn.net/m0_53918927/article/details/139076326

版权

🔥 交流讨论：欢迎加入我们一起学习！

🔥 资源分享：耗时200+小时精选的「软件测试」资料包

🔥 教程推荐：火遍全网的《软件测试》教程

📢欢迎点赞 👍 收藏 ⭐留言 📝 如有错误敬请指正！

1 - Web自动化测试简介

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

1.1 自动化测试的本质

其本质是把手工测试转化成使用计算机、软件、程序来测试产品的过程。在设计
测试用例并通过评审之后，由测试人员根据测试用例中描述的步骤来一步一步执行测试代码，得到的实际结果与期望结果进行比较。
重复姓的测试工作在时间紧迫的情况下会有范围遗漏，为了节省人力、时间、资源、提高测试效率，保证测试范围，引入了自动化测试概念。

1.2 自动化真的具有绝对的高效性？

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

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

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

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

手工测试的局限性：

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

自动化测试的优势：

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

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

1.5 自动化测试介入的场景

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

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

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

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

普遍的观点是：很多人认为自动化更适合回归测试和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毕竟是一种松散的、被阉割的、普及面很广的语言。【其实就是弱类型语言】
QTP支持录制和回放的功能。
录制产生的脚本，可以用来作为自己编写的template。
录制时还支持lower lever功能，该功能用于QTP不易识别的对象使用，不过它是使用坐标来标识的，对于坐标位置频繁变动的对象，此种方法不可取。
QTP编辑器：Keyword模式与Expert模式。
Keyword模式：类似RobotFrameWork的表格视图。
Expert模式：代码视图。

2.2 Selenium(Webdriver)

价格：开源、免费
相较于QTP而言（商业版、收费的、一个lessons大概价格100万美金左右）
绝大多数的公司在商业版软件上更愿意选择使用Selenium完成同样工作的高级自动化测试人才，毕竟大多数的公司的最终目的还是以营利为主。【插句题外话,商业版的软件往往在报告输出上做的非常完善。】
应用领域：基于浏览器的Web端自动化测试，Selenium仅支持Web页面的测试工作；
QTP不仅支持Web界面的测试工作，还支持Client方面的测试，这一点上是 Selenium的不足之处。
功能方面：
录制功能方面，QTP要强于Selenium。
QTP录制回放成功率很高，但是Selenium的录制回放功能成功率就非常的低，所以我们在测试过程中也不会使用录制功能。
脚本的编辑方面，不好判断。
熟悉Java、Python等的人，会比较喜欢Selenium，
熟悉VBScript就比较喜欢QTP。
框架处理能力：
在数据驱动方面，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)

IBM的一款适合功能测试、回归测试的自动化测试工具。
它的基础是针对于Java、.NET的对象技术和基于Web应用程序的录制与回放，
我们可以利用它以Eclipse为核心的特点用Java脚本自行编写更具有灵活性的自动化测试脚本用于日场和回归测试。这款自动化测试框架是在Selenium出现之前大家认为最容易进行扩展的一个框架。
TIP：尽管RFT提供了录制和回放的功能来开发自动化脚本，但这并不是一个很好的方法，很多测试团队也并没有采用，因为录制与回放功能对于程序运行的环境运行依赖性太大，包括了程序的位置、窗口的分辨率，每个变化都将会导致脚本无法正确的运行，因此更多使用该工具的测试团队采用了自己手动写脚本的方式来提高脚本的易读性以及可维护性。

框架结构：
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端获得运行结果。

附：在使用该工具的时候有一必须点：当编辑完测试脚本后，会生成一个apk文件，将该apk安装到手机端，并通过adb输入一系列命令后直接运行测试脚本。但该apk的签名必须要与测试程序的apk签名保持一致。

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 脚本的独特之处。

在这里插入图片描述

2.8为什么选择Selenium(Webdriver)

<span style="color:#000000"><span style="background-color:#fafafa"><code class="language-python">· 开源免费
· 使用灵活简单
· 后期用例易于维护
· 支持多种语言
· 容易与单元测试框架结合
· 可支持多浏览器同时，支持远程启动其他服务器
· 高度复用性
· 代码自主掌控，对于搭建框架、平台等有不可替代的优势
</code></span></span>

3 - 测试自动化和自动化测试

3.1 什么是测试自动化？

这是一种让测试过程脱离人工的一次变革。对于控制成本，控制质量，回溯质量和减少周期都有积极影响的一种研发过程。

3.2 什么是自动化测试？

通过将测试执行部分或者全部交由机器执行的一种测试，叫做自动化测试。这种测试不需要人的实时参与。同时这种测试在小规模应用时会比手工测试昂贵许多。
所以自动化测试可以看做测试自动化的一部分。

3.3 不同的工程师，工作不同

一个自动化工程师，会比较专注于测试工具的研发。最主要的是这个工程师会从成本的角度去考虑问题。这一点比较像PM。他所做的一切是为了减少自己或者团队的工作量，尽可能的将重复的，有规律可循的工作代码化，自动化。
一个自动化测试工程师，会比较专注于测试代码的开发，以及测试结果的分析。对于被测设备本身非常感兴趣。他们比较倾向于一种完美主义者，追求的是高质量而经常忽略成本。这一点更像是开发人员
现在绝大多数公司都会执着于自动化测试，而忽略测试自动化。这一点会让整个AT(automation test)成本变得非常高。

3.4 自动化测试的几个准则：

并不是将测试用例代码化了，就可以称之为自动化测试了。这是现在很多公司宣称自己做AT的一个噱头。
AT的代码是有很多的要求。
首先就是你的覆盖面要广。个位数case的自动化完全没有意义。
第二就是你的case必须要能够复用：软件每天都在变，如果你的case要天天跟着软件变，那你的case是完全不合格的
第三就是测试规模要够大：要么时间长（case多），要么测试产品多。这样才能体现出来自动化测试的优势。

3.5 测试自动化的几个准则：

一就是要减少除工具研发部门外，其他所有测试部门的人力成本。这就是测试自动化追求的终极目标之一。
二就是提高测试质量，不仅仅包括测试执行的质量，还包括测试的统计质量，数据回溯质量等等等等。这些质量的提高可以帮助测试团队修正他们的测试方法，而不是每天将精力扑在无止境的数据收集和分析中。
三则是要抢出时间。某一项工作自动化后的时间，要么比人手做时间短，要么可以在非工作的16个小时中进行。通过让电脑OT的方法来解放工程师和项目经理。

4 - 自动化测试三个阶段

4.1 基本脚本设计阶段

自动化测试：用例代码化
将要进行测试的功能代码化，能够将线性流程通过自动化脚本完成测试
举例：注册>>>登录>>>购物>>>支付>>>确认收货>>>退出

4.2 框架脚本设计阶段

测试自动化：繁杂的工作简要化，使用框架设计的手段。（数据驱动、关键字驱动、分层架构的思想）[测试自动化第一步]

4.3 平台设计阶段

如何开发一个自动化测试平台？讲道理,你都能搞定自动化测试平台了还干啥测试啊，产品经理、研发、架构师它不香么？等有时间了看看能不能把 "87test团队、雷子师傅"他们的自动化平台白嫖一个,到时候放出一个思维导图

5 - 自动化环境搭建准备与相关工具

~~这里以前写过一篇关于自动化环境搭建的文档,找到了再放出来把。~~

暂时没找到,先放一个大概通用的吧。

关于浏览器

浏览器（开发者工具使用【F12】）
Chrome（版本不要太高），同时注意驱动对应的浏览前版本
Firefox （版本不要太高），同时注意驱动对应的浏览前版本
IE9、IE10
详见：浏览器版本与DriverServer对应表与资源 chromedriver与chrome版本对应 - AlisaPan - 博客园