ui自动化测试工具（测试总结-robotframework之UI自动化）

本文目录

• 测试总结-robotframework之UI自动化
• 苹果启动ui自动化要打开吗
• 自动化测试工具有哪些
• 前端UI自动化puppeteer实践
• 哪个才是最适合你的WebUI自动化测试框架
• 应用程序的ui自动化测试使用什么工具

测试总结-robotframework之UI自动化

Robotframework做UI自动化测试示例框架

UI自动化测试用例也写过一阵子了，这边给大家分享一套完整的UI自动化测试框架，还是很感谢同事的帮忙和教导

1、搭建UI自动化框架

框架主通过测试用例，元素定位，系统关键字，系统变量，行为导入这五个模块组成。具体详情请看截图。
2、测试用例当中比较重要的一个东西就是tags，tags标识着每一个用例，再做回归测试的时候就不会那么乱，并且后期维护起来也会比较方便。

1》Force Tags：在文件型Suite这里还可以继续给子元素增加Force Tags，但是他不能删除父元素设置的tags。
2》测试用例tags
3、测试用例编写

Robotframework可以通过setup和teardown可以避免冗余操作，把登陆和关闭浏览器等操作放在Suite固定执行，就不必在每个用例中都写入登陆和关闭浏览器等操作。和python做自动化测试中setUp与tearDown的作用是一致，特别有意思。总感觉我对自动化测试的概念不是特别深入，还是需要不断尝试，学习当中。
4、页面中iframe嵌入HTML如何定位元素（番外）

这个算是这次总结的番外篇，之前都没怎么遇到比较复杂的元素，这次的项目包含iframe，百度了很久才解决了，如果遇到iframe中包含html，需要定位HTML中的元素，需要先进入iframe中，通过Select Frame操作即可。

select frame的用法如下：

示例如下：

苹果启动ui自动化要打开吗

苹果启动ui自动化要打开。具体步骤如下所示：
1、首先，确保自己的设备已连接到Mac电脑。
2、在Mac电脑上，打开"开发者选项"。进入"系统偏好设置"、"安全性与隐私"、"隐私"、"辅助功能"，然后点击左下角的锁图标进行解锁，并将自己的开发者工具（如Xcode）添加到"已授权的应用程序列表"中。
3、在自己的iOS设备上，打开"设置"、"通用"、"辅助功能"、"自动化"。确保"自动化"选项已启用。
4、确保自己的应用程序已安装在设备上，并且已在Xcode中进行了正确的配置，以便启动UI自动化测试。

自动化测试工具有哪些

自动化测试工具有如下几种：

1、WinRunner

Mercury Interactive公司的WinRunner是一种企业级的功能测试工具，用于检测应用程序是否能够达到预期的功能及正常运行。

通过自动录制、检测和回放用户的应用操作，WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试，提高测试人员的工作效率和质量，确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。企业级应用可能包括Web应用系统，ERP系统，CRM系统等等。

2、Rational Robot

是业界最顶尖的功能测试工具，它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面IBM Rational Test Manager上，在这里测试人员可以计划、组织、执行、管理和报告所有测试活动，包括手动测试报告。

这种测试和管理的双重功能是自动化测试的理想开始。

3、AdventNet QEngine

AdventNet QEngine是一个应用广泛且独立于平台的自动化软件测试工具，可用于Web功能测试、web性能测试、Java应用功能测试、Java API测试、SOAP测试、回归测试和Java应用性能测试。

支持对于使用HTML、JSP、ASP、.NET、PHP、JavaScript/VBScript、XML、SOAP、WSDL、e-commerce、传统客户端/服务器等开发的应用程序进行测试。此工具以Java开发，因此便于移植和提供多平台支持。

4、SilkTest

是业界领先的、用于对企业级应用进行功能测试的产品，可用于测试Web、Java或是传统的C/S结构。SilkTest提供了许多功能，使用户能够高效率地进行软件自动化测试。

这些功能包括：测试的计划和管理；直接的数据库访问及校验；灵活、强大的4Test脚本语言，内置的恢复系统(Recovery System)；以及具有使用同一套脚本进行跨平台、跨浏览器和技术进行测试的能力。

5、QA Run

QARun的测试实现方式是通过鼠标移动、键盘点击操作被测应用，即而得到相应的测试脚本，对该脚本可以进行和调试。在记录的过程中可针对被测应用中所包含的功能点进行基线值的建立，换句话说就是在插入检查点的同时建立期望值。

在这里检查点是目标系统的一个特殊方面在一特定点的期望状态。通常，检查点在QARun提示目标系统执行一系列事件之后被执行。检查点用于确定实际结果与期望结果是否相同

前端UI自动化puppeteer实践

背景
在表单（web页面）测试过程中，要经常对表单基本功能进行回归，曾经考虑过使用webUI自动化工具，减少重复性的操作，但是因为之前用过appium，对UI自动化的体验不是很好，所以有些纠结，但是，再仔细想一下，有可能存在比较好用又确实能提升效率的工具，也不妨去尝试一下。
上网查询了一下，puppeteer具有可以使用录制脚本的工具puppeteer-recorder、截图等功能，找了个demo开始试了一下，发现坑较少，安装方便，使用比较流畅。
puppeteer介绍
Puppeteer 是一个Node库， 它提供高级API，通过DevTools Protocol 来控制Chrome 或 Chromium。 Puppeteer 默认运行为headless ，但是可以配置为运行为non-headless。详见文末参考链接。
效果展示
目录结构
cases：用例脚本
config：配置文件，可区分测试、线上环境
screenshot_outputs：输出的截图文件
utils：用到的通用方法

测试思路
1、在脚本中写入测试执行步骤
2、运行脚本
3、查看执行结果（截图），查看是否符合预期。
这样操作会使简单很测试很多。就拿表单人工审核为例，全部人工操作的话，需要填写并提交表单，登录表单运营后台，找到对应的目录及表单，对表单进行审核，再重新打开表单并进行查看，而自动化的话，在写好脚本（在脚本中可进行接口请求）之后，就可以直接运行脚本，查看结果。

环境搭建
1、安装puppeteer：npm install puppeteer（前提是安装了node、npm）
2、安装chrome插件puppeteer-recorder（可自行百度，比较简单）
3、npm init，初始化一个项目
脚本编写

遇到问题
1、puppeteer-recorder只能录制获取元素、点击元素操作，没有获取到填写文本的操作，需要修改或添加已录制好的脚本
2、有些地方例如截图前，接口请求结束后，需要使用等待方法。await page.waitFor(3000)
3、使用await进行接口请求，不然会出现同步异步问题，后面的语句开始执行（但是要用到的参数还没有获取到）
参考：
***隐藏网址***
***隐藏网址***

哪个才是最适合你的WebUI自动化测试框架

移动端

1、Monkey是AndroidSDK自带的测试工具，在测试过程中会向系统发送伪随机的用户事件流，如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试，也有日志输出。实际上该工具只能做程序做一些压力测试，由于测试事件和数据都是随机的，不能自定义，所以有很大的局限性。

2、也是AndroidSDK提供的测试工具。严格意义上来说其实是一个Api工具包，比Monkey强大，可以编写测试脚本来自定义数据、事件。缺点是脚本用Python来写，对测试人员来说要求较高，有比较大的学习成本。

3、是早期Google提供的Android自动化测试工具类，虽然在那时候JUnit也可以对Android进行测试，但是允许你对应用程序做更为复杂的测试，甚至是框架层面的。通过你可以模拟按键按下、抬起、屏幕点击、滚动等事件。是通过将主程序和测试程序运行在同一个进程来实现这些功能，你可以把看成一个类似Activity或者Service并且不带界面的组件，在程序运行期间监控你的主程序。缺点是对测试人员来说编写代码能力要求较高，需要对Android相关知识有一定了解，还需要配置.xml文件，不能跨多个App。

4、UiAutomator也是Android提供的自动化测试框架，基本上支持所有的Android事件操作，对比它不需要测试人员了解代码实现细节（可以用抓去App页面上的控件属性而不看源码）。基于Java，测试代码结构简单、编写容易、学习成本，一次编译，所有设备或模拟器都能运行测试，能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App测试）。缺点是只支持SDK16（Android4.1）及以上，不支持HybirdApp、WebApp。

应用程序的ui自动化测试使用什么工具

　　曾经有一段时间，人们习惯于在MS Excel里面编写单元测试用例，然后开发人员就按照单元测试用例一步一步的来实现用例。这通常是很耗时的漫长的过程，尤其是如果应用很大或者UI很复杂的话。
　　这一套单元测试的执行过程常常成为瓶颈，因为任何代码修改都会带来手工执行大量单元测试，以确保新的修改没有破坏原有功能。

　　如今是个快节奏时代，人们希望工作能够无需人工介入、自动化的快速完成。每个人都喜欢执行一个命令就能把工作搞定，而且在执行期间不需要人工介入。需要做的仅仅是检查一下最终的输出结果。
　　当这个世界正在迈向自动化时，自动化测试也不甘落后，不论是在功能测试方面还是UI测试方面。每天我们都能听说自动化测试方面涌现出的新软件。
　　本文提供了一些信息给那些想用Coded UI自动测试框架来进行应用界面自动化的.Net开发者。

　　什么是Coded UI?
　　最近我一直在寻找一个自动化的用户接口测试的解决方案。用户接口测试需要用户多次进行手工输入操作，这是一个既枯燥又费时的过程。因此，我想寻找一种更智能的自动化UI测试的方案，这种UI测试在不需要人工干预下，能够被保存，记录并提供支持 ，快速测试代码的改变。
　　Coded UI 采用用户接口来驱动应用的进行自动化测试。这些测试包括UI控制的功能性测试。他们使你可以验证整个应用的功能是否正确，其中包括了用户接口。Coded UI尤其适合用于用户接口中存在校验或者其它的登录方式的测试，比如网页。Coded UI也可以用于人工测试用例的自动化。
　
　　Coded UI 测试帮助用户测试应用程序的用户接口。这些测试允许用户验证应用程序的功能。Coded UI 多数时间用于帮助验证在UI层本身的有效逻辑。它能够验证值对用户接口的控制的正确性。
　　其它方案
　　市场有许多自动化用户接口的方案，比如HP的QuickTest Professional, IBM Rational Functional Tester. 其它著名的，易于使用的开源工具解决用户接口自动化问题的有Selenium，也能够记录测试，需要的时候回放。市场上还有来自Microsoft的也能不需要太多努力做同样的事。用Visual Studio Microsoft还有Coded UI的方案用于单元测试。
　
　　Coded UI适合在哪儿用?
　　大多数安装了Visual Studio的开发者都喜欢在Visual Studio的环境里进行单元测试，而不是使用第三方工具。由微软提供的Coded UI，在Visual Studio环境里可谓上手即用。在开发者的机器上无需另外安装任何东西。一旦你安装了Visual Studio的Premium版或者Ultimate版，你就同时也安装好了Coded UI。
　　Coded UI可用性
　　为了使用Coded UI，需要安装Visual Studio 2010/2012/2013的Premium版或者Ultimate版。

　　Coded UI 测试的组成
　　Coded UI 测试的组成容易理解。它可分成下列文件：
　　UIMap.uitest
　　这个文件是UIMap类的XML表示。UIMap类包括视窗，控件，属性，方法，断言和动作。
　　UIMap.cs
　　对UIMap的自定义部分都存在这文件里。如果修改直接存在UIMap.designer.vb文件的话，那些修改都会在记录结束后丢失，因为这个文件重新创建了。
　　给每个在测应用程序中的每个模块创建一个独立的UIMap文件。
　　UIMap.Designer.cs
　　这是部分类表达各种类。这各种类是给多样的控件和他们的范围，属性，方法的类。
　　提示：不要直接修改 UIMap.Designer.cs。加入你这样做，这个修改会被覆盖掉。
　　CodedUITest.cs
　　这类表示的实际的CodeUI测试类，方法调用，和断言调用，所有的方法和断言默认都是从UIMap.Designer.cs文件调用的。这类有具有【codedUITest]属性TestClass和包含具有【TestMethod]属性的多种方法。

　　Coded UI的特性/好处
　　进行用户界面测试的同时进行校验.
　　生成VB.Net/C#代码.
　　测试用例可以被记录和重放.
　　集成了ALM Story
　　能够作为每日构建的一部分来运行.
　　根据需要进行高级扩展.
　　和Visual Studio集成在一起，所以无需单独购买许可.
　　Coded UI对Web和Windows应用同样适用.
　　著名的Microsoft支持.
　　创建Coded UI测试
　　Coded UI测试可以用下列方式创建
　　使用MTM进行快速自动构建
　　从现有的记录(从手动测试中记录下来的操作)中创建Coded UI
　　在Coded UI Test Builder创建的底稿的基础上创建一个新的Coded UI测试.
　　自己写Coded UI.
　　这个白皮书的范围仅限于“在Coded UI Test Builder创建的底稿之上创建一个新的Coded UI测试”。
　　小贴士: 尽量使用Coded UI Test Builder。
　　Coded UI Test Builder
　　每一个Coded UI测试的生成都需要遵从下列步骤.
　　记录/停止/暂停
　　记录下来的步骤
　　添加断言
　　生成代码
　　创建Coded UI 测试
　　创建新的Coded UI 项目
　　要开始使用Coded UI，首先我们需要创建一个测试项目，用来保存所有Coded UI测试。创建一个新的Coded UI项目包含下列步骤
　　打开Visual Studio 2012
　　选择 File 》 New 》 Project
　　选择需要的语言模板 (C# or VB.Net). 我们选择了C#.
　　选择Coded UI Project
　　输入一个名字
　　点击 OK 按钮

　　添加 Coded UI 测试
　　Visual Studio默认配置为创建Coded UI 测试使用 "Generate a new Coded UI Test from scratch using Coded UI Test Builder"
　　提示：在测试的应用程序中，当你创建UI控件时尽量使用有意义的名称，从而对于自动生成的控件显得更加有意义和可用。
　　一旦 Coded UI 测试工程创建完成，将会自动打开生成Coded UI 测试代码的对话框，请给出以下选项的设置。
　　记录操作，UI地图或添加断言
　　使用一个已经存在的操作记录
　　默认情况下 选择记录操作,UI地图或添加断言，无需做任何操作，然后点击 "ok"

　　Coded UI Test Builder
　　选择了上述选项后，Coded UI Test Builder就会被打开，同时Visual Studio窗口被最小化。这意味着我们已经为记录操作做好了准备。
　　正如之前描述的，Coded UI Test Builder基于下列4个操作来做记录
　　Record Steps
　　Update or Delete Steps
　　Verify Results (Add Assertions)
　　Generate Code
　　小贴士: 如果用户界面(UI)变化了，就重新记录测试方法或断言方法，或者重新记录一个既有测试方法中受影响的部分。
　　记录一个序列的操作.
　　记录一个操作主要需要下列几步.
　　Start Recording, 通过选择Record按钮即可.
　　Pause Recording, 用来处理记录过程中的其它操作，即Generate Code.
　　Edit/Delete 操作, 以防错误的操作被记录。
　　Generate code为记录下来的操作创建编号。会给每一个记录下来的操作都生成编号。
　　Add Assertions 用来校验结果。
　　小贴士: 创建断言最好使用Coded UI Test Builder，因为它会在UIMap.Designer.cs文件中自动添加一个断言方法。

　　为记录动作做计划
　　任何事情的成功都取决于它计划得有多好。较好地计划最大限度保证了任务成功完成。这样总是比较好，在开始记录动作之前，我们计划好所有的所有要计划的步骤。
　　这里我们将要使用应用程序Windows计算器来记录步骤。我们要自动地加和减两个数字。在记录加和减两个数字的时候，下面的步骤将会用到。
　　。点击“开始记录”控件
　　。到开始，点击执行
　　。在执行窗口，输入”calc"
　　。停止记录，看记录的步骤
　　。删除错误的步骤（存在的话）
　　。产生代码；提供和动作相匹配的名字。比如，打开计算器。
　　提示：当你产生一个方法时候，使用一个有意义的方法的名字，代替默认名字。
　　有意义的名字帮助识别方法的木的。
　　。重新记录，提供第一个数字，暂停记录产生代码
　　。重新记录，提供操作（加或者减），暂停记录，产生代码
　　。重新记录，提供第二个数字，暂停记录，产生代码。
　　。加断言
　　提示： 产生你的测试作为一系列记录的方法
　　提示： 可以的时候，限制每个方法小于10个动作。这模块化的方法让UI改变时候容易替换方法。
　　我们已经看到了Coded UI可以使开发者的生活变得多么轻松，尤其是遇到每次都需要进行很多输入的复杂页面的时候。这时，测试用例只需要被记录一次，就可以按照需要执行任意多次。使用Coded UI比使用其它工具的好处是，它能自动适配Web页面和Windows窗口应用。Coded UI测试可以用Visual Studio 2010来运行，也可以用任何版本的VS来运行，它们的功能正变得越来越强大。无需多说，Coded UI是一个由技术领导者提供的强大工具，想要体验Coded UI测试的强大，我们应该开始在项目中使用它看看它能带来多少ROI，我确信Coded UI不会让你失望。
转载