phton可以做网站吗,电子商务网站建设的论文,做一个招聘网站需要多少钱,帝国cms做网站流程1、UI自动化测试简介
软件测试简介
软件测试是伴随着软件开发一同诞生的#xff0c;随着软件规模大型化#xff0c;结构复杂化#xff0c;软件测试也从最初的简单“调试”#xff0c;发展到当今的自动化测试。
自动化测试是什么呢#xff1f;自动化测试是把以人为…1、UI自动化测试简介
软件测试简介
软件测试是伴随着软件开发一同诞生的随着软件规模大型化结构复杂化软件测试也从最初的简单“调试”发展到当今的自动化测试。
自动化测试是什么呢自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程自动化测试通常会借助某些工具或者框架。虽然不能完全取代手工测试但相比手工测试来讲自动化测试可以减少人力成本降低重复工作从而更快速、高效的进行测试活动。
测试金字塔是一种自动化测试过程的金字塔形策略结构用来指导软件开发过程中各层测试投入的工作量比例其最早由Mike Cohn在2009年的著作《Scrum敏捷软件开发》中提出。Mike Cohn在书中指出测试金字塔从上到下分为三层分别是UI测试、服务/接口测试、单元测试越接近金字塔底部的测试活动投入的工作量应该越多即单元测试投入工作量最多接口测试次之UI测试投入最少。
UI测试
UI测试是最接近软件真实用户使用行为的测试类型。通常是模拟真实用户使用软件的行为即模拟用户在软件界面上的各种操作并验证这些操作对应的结果是否正确。
接口测试API测试
API测试主要针对的是各模块暴露的接口通常采用灰盒测试方法。首先以黑盒方式设计如何调用API的测试用例同时在测试执行过程中统计代码覆盖率然后根据代码覆盖率情况来补充更多、更有针对性的测试用例。
单元测试
单元测试属于白盒测试的范畴通常由开发工程师自己完成越早发现缺陷其修复成本越低。
为什么要做 UI 自动化
随着不停的版本迭代软件新增功能变的越来越多对测试资源的需求也变得越来越大执行人工测试的时间越来越长。对于人工测试的依赖开始变得棘手因此大家开始寻找解决方案UI 自动化也应运而生。
人工测试存在以下的弊端
人工回归测试需要花费很长时间才能完成很小的延迟就会让发布面临风险。发布节奏受到人工回归测试的限制。两天以上的人工回归测试意味着最好的情况下能够一个月发布两次。而且开发者需要一次性发布所有东西。要么全部发布要么什么都发布不了因为需要将所有东西一起测试。
UI 自动化测试存在以下的优点
解放了测试团队针对临时的和探索性案例的测试时间可以一边开发一边进行回归测试减少等待时间可重复性使用快速进行回归测试更好的利用资源周未/晚上的资源空闲时段。
UI 自动化测试的特点
了解到为什么要选择UI自动化测试之后我们需要了解UI自动化测试的使用场景。UI 即 User Interface用户界面的简称UI 自动化做的事情就是模拟用户行为进行操作完成对用户界面的测试。这也就从本质上限制了它的使用场景
软件需求变动不频繁产品更新维护周期长比较频繁的回归测试自动化测试脚本可重复使用
所以在开始之前我们最好先认识清楚哪些业务场景是可以自动化测试的。
2、Android UI自动化测试工具
UI自动化测试经过多年的发展也已经涌现出很多优秀的测试工具。下面简单介绍一下Android测试领域内的一些常见的测试工具。
1、Monkey
是Android SDK自带的测试工具在测试过程中会向系统发送伪随机的用户事件流如按键输入、触摸屏输入、手势输入等)实现对正在开发的应用程序进行压力测试也有日志输出。实际上该工具只能做程序做一些压力测试由于测试事件和数据都是随机的不能自定义所以有很大的局限性。
2、MonkeyRunner
也是Android SDK提供的测试工具。严格意义上来说MonkeyRunner其实是一个Api工具包比Monkey强大可以编写测试脚本来自定义数据、事件。Monkeyrunner 足够强大了但是录制的脚本是以坐标轴来作为定位方式而安卓设备类型众多各种分辨率所以移植性不好。
3、Instrumentation
是早期Google提供的Android自动化测试工具类虽然在那时候JUnit也可以对Android进行测试但是Instrumentation允许你对应用程序做更为复杂的测试甚至是框架层面的。通过Instrumentation你可以模拟按键按下、抬起、屏幕点击、滚动等事件。
Instrumentation是通过将主程序和测试程序运行在同一个进程来实现这些功能你可以把Instrumentation看成一个类似Activity或者Service并且不带界面的组件在程序运行期间监控你的主程序。
缺点是对测试人员来说编写代码能力要求较高需要对Android相关知识有一定了解还需要配置AndroidManifest.xml文件不能跨多个App。
4、UiAutomator
也是Android提供的自动化测试框架基本上支持所有的Android事件操作对比Instrumentation它不需要测试人员了解代码实现细节可以用UiAutomatorviewer抓取App页面上的控件属性而不看源码。基于Java测试代码结构简单、编写容易、学习成本低一次编译所有设备或模拟器都能运行测试能跨App比如很多App有选择相册、打开相机拍照这就是跨App。缺点是只支持SDK 16Android 4.1及以上不支持Hybird App、WebApp。
5、Espresso
是Google的开源自动化测试框架。相对于UIAutomator它的特点是规模更小、更简洁API更加精确编写测试代码简单容易快速上手。因为是基于Instrumentation的所以不能跨App。
6、Selendroid
基于Instrumentation的测试框架可以测试Native App、Hybird App、Web App但是网上资料较少社区活跃度也不大。
7、Robotium
也是基于Instrumentation的测试框架目前国内外用的比较多资料比较多社区也比较活跃。缺点是对测试人员来说要有一定的Java基础了解Android基本组件不能跨App。
8、Appium
Appium 是目前最主流的移动测试自动化框架不仅支持 Android 应用而且适用于 iOS、混合和 Web 应用程序。
它底层完全使用了 Selenium 和 WebDriver 的 API所以如果你之前有用过 selenium, 几乎不需要额外的学习成本就可以使用 appium。appium 通过 uiautomatorAPI 级别 16 或更高和 SeledroidAPI 级别低于 16支持 Android但是你不需要具体懂这两个框架的具体用法appium 都已经帮你封装成了统一的使用规则。Appium 的优势之一是几乎可以使用任何编程语言例如 Java、Objective-C、JavaScript、PHP、Ruby、Python 或 C# 等编写 Appium 脚本。不需要重新编译或改变应用程序来匹配AppiumAppium有一个非常大而活跃的社区。
9、Airtest
是网易出品的一款基于图像识别和poco控件识别的一款UI自动化测试套件由Airtest框架、poco框架、airtestIDE 组成。是一个跨平台的UI自动化测试框架适用于游戏和App。用户不需要一行行的去写代码而是用屏幕截屏的方式用截出来的图形排列组合成执行的程序。 另外Airtest也基于poco这个UI控件搜索框架这个框架也是网易自家的跨平台U测试框架原理类似于appium通过控件的名称id之类的来定位目标控件然后调用函数方法例如click(),swip()之类的方法来对目标控件进行点击或者是操作。
虽然Airtest刚开始是为了游戏测试现在在app测试中也有很大的应用范围。只是进行录制、执行脚本的AirtestIDE没有开源不方便进行深度定制。
10、Solopi
是蚂蚁金服开源的一款移动端APP测试工具提供脚本录制、编辑、回放结果展示以及一机多控即通过设备间的socket通讯实现1台手机可以控制多台手机执行脚本等功能其测试用例的录制和执行等操作均在手机端的一个APP中完成。不需要借助电脑软件与测试设备交互所以通信结构比Appium简单高效对元素的识别也是使用类似于appium的控件的方式并且引入了类似于airtest的图像识别的方式。
3、SoloPi的介绍
以往的性能测试工具无外乎三种形态PC 驱动工具、侵入式的测试模块、ROOT 工具。
PC 工具除了 Android Studio 自带的性能测试工具市面上大多数文档都是介绍命令行方法而且各家方案存在差异不少还存在错误实际成型的工具也不多。
侵入式的测试模块这类工具由于需要侵入到源码中需要单独打包进行测试工具本身也可能对性能产生影响。
ROOT 工具首先是需要 Android 系统的 Root 权限对于权限管控越来越严格的 Android 系统其路必将越走越窄。
SoloPi提供了一种能够在 Android 手机上不需要 root 也能实现应用提权的方案。可以简单概括为SoloPi是一种无线化、非侵入、免 Root 的 Android 专项测试方案。
传统的功能测试通常有两种方式一种是人工手动执行测试另一种则是编写基于测试框架的自动化脚本。前者成本巨大为应付不断加速的产品迭代可能需要投入大量人力而后者则对测试同学的代码能力有不小的要求这也导致由手动测试转化为自动化测试从而节省人力的进度相对缓慢。
SoloPi将传统上仅能用于 PC 的自动化测试能力移植到了移动平台并根据手机的使用习惯开发了一套简单易用且功能强大的自动化测试框架。不需要测试同学有代码能力降低了使用门槛更方便推广。
Solopi主要有以下功能自动化测试-录制回放、兼容性测试-一机多控、性能测试、稳定性测试。 虽然Appium和Airtest都有很大的应用范围但是Solopi相比于appium和airtest有以下优势
改进的控件匹配算法更高的匹配成功率
不需要依赖pc端的桌面应用全部操作都在手机端的app中完成实现了无线化随时可测
不需要代码基础使用人群覆盖范围广
提供性能测试的功能等。
1整体架构 这套方案中底层依赖主要是 “无线 ADB、系统辅助功能、Chrome 调试以及图像识别技术”后文将会介绍它们具体的应用场景。同时在底层依赖的基础上封装了一套核心能力由 “控件定位、事件驱动、性能采集以及依赖注入” 组成并在服务层实现了录制、回放、数据处理等公共服
务能力。在架构的最顶端结合界面交互逻辑包装出了各个功能的入口。
2录制回放 在录制过程中SoloPi 会对用户的操作进行拦截识别用户操作的位置高亮当前操作的控件记录用户当前要做的操作类型在每一步操作后将操作类型及目标控件的各种信息都记录下来。这里的控件信息包括控件的 ID、文字等基本信息以及相对布局、截图信息等。
在回放时SoloPi会逐条解析之前录制的数据通过智能查找算法综合各种属性定位目标控件找到控件后就会执行相应的操作如点击、滑动等。在所有步骤执行后会展示本次回放的结果包括日志、截图等信息作为本次回放的总结。
SoloPi 的录制和回放基于同一套逻辑包括控件结构构建、控件定位、事件驱动三个部分。两者的区别主要在于控件定位
在录制过程中SoloPi 会基于用户的点击行为进行定位
在用例回放时SoloPi 会根据录制时记录的控件信息通过 SoloPi 的控件查找算法进行定位。
3底层依赖的核心功能
1基础依赖
下面主要介绍SoloPi的控件查找功能和操作监控功能需要依赖的基础方案无线ADB方案和AccessiblityService方案。
无线ADB方案 对于 Android 自动化ADB shell 的执行能力是一切的基础。在 PC 上通过 Android SDK 提供的ADB client 与同样运行于 PC 中的 ADB server 通信再由 ADB server 通过 USB 与位于设备中的 Adbd 通信。要实现一套无线化的方案必须要摆脱对 USB 线的依赖。好在 Android 系统还提供了一种基于 Socket 的 ADB 连接模式既然是这样那么只需要按照 ADB 通信协议在端上与本机的 5555 端口进行通信即可获得 ADB shell 的执行能力。
此无线ADB方案是SoloPi区别于其他UI自动化测试框架的核心方案之一大家可以在其他项目中借鉴这种无线化方案。
AccessiblityService方案
辅助功能AccessibilityService其实是一个Android系统提供给的一种服务本身是继承Service类的。这个服务提供了增强的用户界面旨在帮助残障人士或者可能暂时无法与设备充分交互的人们。
从开发者的角度看主要使用两种功能查找界面元素实现模拟点击。
UiAutomatorAppium、Airtest使用的方案和AccessibilityService是有联系的UiAutomator底层使用的是AccessibilityManagerServiceAccessibilityService底层也是使用的AccessibilityManagerService它们都是通过RPC与AccessibilityManagerService进行交互获取界面元素和对界面元素进行操作的。区别是UiAutomator只能在shell环境中执行AccessibilityService是可以运行在app环境中的但是需要用户手动开启服务。
2基础功能
基于以上两种基础能力下面介绍solopi底层依赖的两种功能基础控件查找功能、用户操作监控功能。
控件查找功能
随着移动端动态化能力的稳步发展越来越多的应用采用了 “Native H5/小程序” 这种混合开发的方案。再考虑到近年来手游行业的飞速发展手机游戏自动化测试的需求也越来越多。为了尽可能的适配各种场景SoloPi提供了三种查找模式 第一种方案的核心就是基于 AccessbilityService 生成当前控件视图树并记录下id、文字等属性适用于 Native 场景。
第二种方案基于 Chrome 的调试协议通过注入js可以获得页面布局以及各元素属性控件的定位思路与辅助功能这一套方案是一致的。适用于 H5/小程序场景。
第三种方案是图像匹配方案SoloPi 在端上实现了一套图像比对能力结合了模板匹配、特征匹配等算法并做了一定的适配和调优。适用于游戏自动化的场景。
现阶段的开源代码中native控件和webview中的控件都是使用AccessbilityService生成的控件视图树断言功能和截图点击功能会使用到图像匹配方案现阶段基于 Chrome 的调试协议方案未开源。
用户操作监控功能
a、事件获取机制
关于用于操作监控与控件获取AccessibilityService 能够获取用户的操作事件并关联对应的控件可以实现大部分功能。
但 AccessibilityService 也有不足的地方比如面向 HTML5 场景辅助功能获取控件会出现延迟从而导致获取的控件结构不够精确另外对于部分自定义控件辅助功能只能获取到对应的控件但缺乏具体的坐标信息从而导致控件操作不符合预期。
因此SoloPi 采取了“结合 Android 系统 getevnet 功能”策略通过直接解析系统原生事件获取到用户的操作行为。 简单来说通过 geteventSoloPi 可以获取到用户操作屏幕的具体坐标以及手指落下、抬起的具体时间。不过getevent 命令的使用需要 SHELL 权限这限制了普通 Android 应用获取相关数据的能力。SoloPi 通过Android 系统的无线调试功能实现了一套纯端的 SHELL 执行能力能够在 Android 系统上执行 adb 相关命令。在SoloPi应用中集成了 AdbLib 开源库包装成一套 ADB 命令执行工具。
通过 getevent 命令SoloPi 获取到了用户点击的具体坐标结合 AccessibilityService 获取到当前页面的控件结构树。遍历控件树找到坐标点击位置最上层的控件。
b、事件拦截机制
在soloPi代码中当需要拦截事件时就会设置AccessibilityService进入触摸监控模式通过此标志位 FLAG_REQUEST_TOUCH_EXPLORATION_MODE。在此模式下系统不会在view树中分发事件各种事件会分发到AccessibilityService的实现类中。此时soloPi会自己监听get event事件进行事件的分发和处理。当不需要拦截系统分发事件时就会重新设置AccessibilityService的标志位。
4回放能力的扩展
通过 SoloPi 录制的用例会以 JSON 的形式存储起来用例不仅可以在设备本地直接回放还可以通过 SoloPi 的解析器将用例转换为 Appium等目前主流自动化测试框架的脚本轻松打通云测平台。另外得益于文本抓取和图像识别能力SoloPi还实现了在 Android 端录制一遍用例生成的脚本能够同时在 Android、iOS 双端回放的能力。 5脚本编辑 SoloPi还提供了用例步骤的插入、删除、修改等用例编辑功能可以有效降低用例的维护成本。另外SoloPi还引入了循环、条件等流程控制能力若对用例进行合理编排可轻松实现需要重复操作的工具脚本或是需要暴力回放的稳定性测试脚本。
6一机多控
在各类专项测试中兼容性测试是最为耗时费力的一项测试人员需要关注各种系统版本、各大手机厂商各种类型的屏幕等等想要通过纯人工测试来保证兼容性测试的质量成本是非常高的。
SoloPi 在录制回放能力的基础上实现了一套兼容性测试的解决方案。在录制回放的场景中先是在一台设备上记录了用户的操作然后再在任意一台设备上实现操作的回放。如果把场景扩展到多台设备上就可以实现通过一台设备操控多台设备这套功能称为 “一机多控”。具体说来就是主机与从机建立 Socket 连接然后在主机上将用户的操作实时发送到各个从机在从机上完成操作的回放。 一机多控的环境搭建比较灵活手边的手机在安装 SoloPi 后通过简单的建联操作即可完成部署。一机多控适配了目前市面上主流机型和 ROM并封装了一些提升测试效率的快捷功能如应用安装、数据清理、设备信息查看等等。
7性能测试-数据采集 性能数据随手测本地自动生成报表。数据采集支持手工和广播两种触发方式易于结合自动化。
最后感谢每一个认真阅读我文章的人礼尚往来总是要有的这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库虽然不是什么很值钱的东西如果你用得到的话可以直接拿走 这些资料对于【软件测试】的朋友来说应该是最全面最完整的备战仓库这个仓库也陪伴上万个测试工程师们走过最艰难的路程希望也能帮助到你
