具体描述
编辑推荐
国内第1本原创的Robotium图书
紧跟移动平台开发、测试的热点技术
全面讲解了用Robotium建立测试工程、测试项目搭建、自动化测试脚本编写、测试框架完善、Robotium自动化测试用例、测试代码批量运行、持续集成、Crash处理、跨应用解决方案、代码覆盖率、代码覆盖率展现、常见错误及解决方法等实战技术和技巧,帮助读者尽快学懂用Robotium进行移动测试。 内容简介
《手机测试Robotium实战教程》讲解了用Robotium进行移动测试的主要技术,并通过实例,让读者达到学以致用的目的,主要内容为:移动端自动化测试的工具选择、测试开发环境搭建、Robotium入门、建立测试工程、运行第1个Robotium测试实例、被测App详细功能介绍、实战测试项目搭建、自动化测试脚本编写、测试框架完善、Robotium自动化测试用例、测试代码批量运行、持续集成、Crash处理、跨应用解决方案、代码覆盖率、代码覆盖率展现、常见错误及解决方法等实战技术和技巧,将帮助读者尽快学懂用Robotium进行移动测试的知识。
《手机测试Robotium实战教程》适合移动端功能测试人员、Web端功能测试人员、自动化测试人员、测试开发人员、移动端开发人员阅读学习,也可以作为大专院校相关专业师生的学习用书和培训学校的教材。 作者简介
杨志伟,从2011年开始接触移动端自动化测试工作,积累了丰富的自动化测试案例实战经验,擅长整合主流无线端自动化测试框架的运用。曾就职于知名外企RingCentral,负责Mobile自动化测试框架的开发和持续改进工作;现就职于网龙网络有限公司,负责BDD模式的运用和推广工作。 目录
目 录
第1章 自动化测试简介 1
1.1 何为自动化测试 2
1.2 自动化测试和手动测试的对比 2
1.3 移动端自动化测试工具的选择 3
1.3.1 Appium 3
1.3.2 uiautomator 4
1.3.3 Robotium 4
第2章 测试开发环境搭建 6
2.1 JDK安装及其环境变量配置 7
2.2 Eclipse的安装 9
2.3 Android SDK的安装及环境变量配置 9
2.4 ADT插件的安装 12
2.5 Genymotion 12
第3章 Robotium入门 18
3.1 Robotium简介 19
3.2 Robotium版 “Hello World” 19
3.2.1 导入被测试源码 19
3.2.2 新建测试工程 21
3.2.3 添加Robotium jar 22
3.2.4 新建第一个自动化测试类 23
3.2.5 运行第一个Robotium例子 24
3.3 基于APK的自动化测试 25
3.3.1 APK重签名 25
3.3.2 创建基于APK测试的测试工程 27
3.3.3 编写基于APK自动化测试的“HelloWorld”版 27
3.3.4 安装应用、运行自动化测试用例 29
3.4 基于APK测试的ID定位 30
3.5 Robotium API简介 35
3.6 Robotium录制回放 38
3.6.1 安装Recorder 38
3.6.2 录制回放脚本 41
第4章 第一个实战项目 45
4.1 被测App简介 46
4.2 导入ToDoList APP源码 46
4.3 被测App的详细功能 50
第5章 实战测试项目搭建 52
5.1 搭建实战测试项目 53
5.2 第一个测试用例 54
5.3 第一个自动化测试脚本 55
5.4 查看控件ID的工具 60
5.4.1 hierarchyviewer.bat的用法 61
5.4.2 uiautomatorviewer.bat的用法 62
第6章 完善测试框架 64
6.1 编写抽象父类 65
6.2 提取控件ID类 71
6.3 操作统一入口类 74
6.4 更新抽象父类及测试用例 75
6.5 调试简介 79
第7章 更多自动化测试用例 84
7.1 包管理 85
7.2 编写更多自动化测试用例 85
7.2.1 登录页面测试用例2 86
7.2.2 登录页面用例3 86
7.2.3 添加任务页面测试用例 93
7.2.4 任务列表页面测试用例 96
7.2.5 任务编辑页面测试用例 97
7.2.6 退出功能验证 102
第8章 批量运行测试代码 104
8.1 TestSuite 105
8.2 Runner 107
8.3 生成JUnit格式的report 111
第9章 持续集成 115
9.1 持续集成简介 116
9.2 持续集成工具 116
9.3 编译todolist项目源码 119
9.3.1 安装Ant 119
9.3.2 将添加build.xml到todolist项目 120
9.3.3 将build.xml添加到
todolisttest项目 124
9.4 Jenkins job的创建 127
9.5 Jenkins job的配置 130
9.6 shell脚本统一管理构建过程 135
9.7 Unit report展示 137
9.8 错误截图展示 142
9.9 参数化运行设备 145
9.10 完整的job配置 147
第10章 Crash处理 150
10.1 crash处理机制 151
10.2 shell部分编码处理 151
10.3 CommonRunner代码逻辑 153
10.4 为Runner1加入crash处理逻辑 159
10.5 制造Crash场景 160
10.6 report合并 163
第11章 跨应用解决方案 169
11.1 uiautomator 170
11.2 服务端编码 177
11.3 发送跨应用请求 183
11.4 跨应用实例 185
11.5 手动部署 188
第12章 代码覆盖率 190
12.1 代码覆盖率的好处 191
12.2 使用EMMA统计代码覆盖率 191
12.3 合并代码覆盖率文件 197
12.4 创建代码覆盖率Jenkins job 200
12.5 代码覆盖率展现 204
第13章 Android Studio和Gradle 206
13.1 Android Studio的安装和配置 207
13.2 Gradle简介与安装 208
13.2.1 Gradle简介 208
13.2.2 Gradle的安装 208
13.3 为Eclipse项目生成gradle配置文件 209
13.4 在Android Studio下新建todolist及其配置 212
13.5 持续集成配置 219
第14章 常见错误及解决方法 223 精彩书摘
《手机测试Robotium实战教程》:
10.1 crash处理机制
当自动化测试用例的数目比较大时,批量运行的时候,可能会出现这种情况:当用例运行时,因为一些原因导致crash了,自动化测试用例无法继续运行下去。在回归测试阶段,要确保所有的自动化测试用例都被执行过,就必须解决这种crash续跑的问题。
理想情况下是,在某个自动化测试用例crash后,启动后续的自动化测试用例继续运行,然后crash前后的测试结果都可以保存下来。
因为是通过启动adb进程来运行自动化测试用例,所以,可以在while循环体内启动自动化测试用例,如果有crash产生,就继续执行循环体内的启动自动化测试用例操作,如果没有crash发生,则终止循环。实现思路是每个自动化测试用例开始运行时,把当前的Case号写入sdcard的某个特定文件中,如crash.txt,第二个自动化测试用例运行时把第二个自动化测试用例的Case号覆盖第一个用例的Case号,这样crash.txt永远保存的是当前运行的Case号,新建一个自动化测试用例来删除crash.txt,这个测试用例放在最后一个执行。这样如果顺利运行的话,没有发生crash,最后一个测试用例被执行到了,crash.txt就会被删除,若循环的判断条件不满足,只会执行一次循环体的内容,如果有crash产生,则继续进入循环体内执行。
因为crash的Case号和所有需要运行的Case号都可以获得,只需重新组织getAllTests的Case列表,即剔除当前Case及其之前的所有Case号,即可从出现crash处的下一个Case继续运行了。
report的处理,如果有crash出现,只需把report的命名加上crash的个数就可以区分出来了,最后再写一个程序把所有的report合并成一份就可以了。
…… 前言/序言
《手机自动化测试:从入门到精通》 前言 在飞速发展的移动互联网时代,手机应用的质量直接关系到用户体验和市场竞争力。确保应用的稳定性和用户满意度,自动化测试已成为必不可少的环节。本书旨在为开发者、测试工程师及对手机自动化测试感兴趣的技术人员提供一份全面、深入的学习指南,带领读者掌握从基础概念到高级实践的完整技能链,构建高效、可靠的移动应用测试体系。 第一章:移动应用测试的挑战与机遇 移动应用的复杂性: 多样的设备与操作系统: Android碎片化(版本、厂商、分辨率、硬件配置)与iOS生态的相对封闭性,都为测试带来了巨大的挑战。 网络环境的不可控性: Wi-Fi、2G、3G、4G、5G,以及信号弱、网络中断等复杂场景,需要进行充分的网络适配性测试。 用户交互的多样性: 手势(滑动、捏合、长按)、传感器(重力、陀螺仪、GPS)、通知、来电、后台切换等,都增加了测试的维度。 性能与功耗: 应用在不同设备上的流畅度、响应速度以及电池消耗情况,是影响用户体验的关键因素。 安全性: 数据存储、传输、权限管理等方面的安全隐患,需要严格的测试来保障。 传统测试方法的局限性: 人力成本高: 手动测试耗时耗力,尤其是在回归测试中,效率低下。 重复性劳动: 大量重复的点击、滑动操作,容易导致测试人员疲劳,增加出错概率。 覆盖率不足: 难以覆盖所有可能的用户场景和边界条件,存在遗漏风险。 反馈周期长: 问题发现不及时,修复成本高。 自动化测试的价值与趋势: 提升效率: 快速执行大量测试用例,缩短测试周期。 降低成本: 减少人力投入,提高测试资源利用率。 提高质量: 保证测试的稳定性和一致性,减少人为错误,提高缺陷发现率。 支持敏捷开发: 快速的反馈机制,与CI/CD流程无缝集成。 应对碎片化: 通过自动化框架,实现跨设备、跨版本的测试。 持续改进: 自动化测试报告为产品改进提供了有力的数据支持。 本书的学习目标: 理解移动应用自动化测试的核心概念和原理。 掌握主流自动化测试框架的选型与应用。 学习如何设计、编写和维护高效的自动化测试用例。 掌握测试数据管理、测试环境搭建和结果分析的方法。 了解自动化测试在DevOps中的应用和最佳实践。 第二章:自动化测试框架概述与选型 自动化测试的分类: 基于API的自动化测试: 针对应用接口进行测试,效率高,但无法模拟真实用户交互。 基于UI的自动化测试: 模拟用户在界面上的操作,最接近用户真实体验,但对UI变化敏感。 混合型测试: 结合API和UI测试,取长补短。 主流移动应用自动化测试框架介绍: Appium: 跨平台特性: 支持Android和iOS,一套代码可用于多个平台。 开源免费: 社区活跃,生态丰富。 WebDriver协议: 兼容Web自动化标准,易于学习。 语言支持: 支持Java, Python, Ruby, C, JavaScript等多种编程语言。 驱动机制: UIAutomator2/Espresso (Android), XCUITest (iOS)。 优点: 灵活性高,扩展性强,能模拟真实用户操作。 缺点: 相对学习曲线稍陡,性能可能不如原生框架。 Espresso (Android): 原生框架: Google官方推荐,集成于Android Studio。 性能优越: 速度快,稳定性高,与应用进程同步。 与应用紧密集成: 能够可靠地同步UI操作,避免因异步操作导致的测试失败。 测试用例编写直观: DSL(领域特定语言)风格,易于理解和编写。 优点: 速度快,稳定性好,与Android开发流程集成度高。 缺点: 仅支持Android,测试用例编写的灵活性相对Appium较低。 XCUITest (iOS): 原生框架: Apple官方提供,集成于Xcode。 性能可靠: 与应用进程同步,测试稳定性高。 良好的开发体验: 在Xcode中即可编写、运行和调试测试。 优点: 稳定可靠,与iOS开发生态紧密结合。 缺点: 仅支持iOS,学习成本与Appium相当。 其他框架(简述): Selendroid: 早期Android自动化框架,现在Appium是主流。 UIAutomator (Android): Google提供的底层UI测试框架,Appium和Espresso在此基础上构建。 Calabash: 曾经流行的跨平台框架,现已停止维护。 框架选型原则: 平台需求: 是只需要测试Android,iOS,还是跨平台? 技术栈: 团队熟悉哪种编程语言? 性能要求: 对测试执行速度和稳定性有多高要求? 开发环境: 是否需要与现有的IDE集成? 社区支持与生态: 框架的活跃度、文档丰富度、第三方库支持。 成本考虑: 开源免费还是商业化软件? 第三章:Appium实战:从零开始构建自动化测试环境 Appium架构解析: Appium Server: 核心组件,接收客户端命令,将命令翻译成平台特定的指令。 WebDriver协议: Appium与客户端通信的协议。 Client Library: 各种编程语言的SDK,用于编写测试脚本。 Appium Inspector/UI Automator Viewer/Xcode UI Test Recorder: 用于定位UI元素。 Platform-Specific Drivers: UIAutomator2/Espresso (Android), XCUITest (iOS)。 环境搭建: 安装Node.js和npm: Appium Server的运行基础。 安装Appium Server: `npm install -g appium` 安装Appium Doctor: `npm install -g appium-doctor`,用于检查环境配置。 Android开发环境配置: 安装JDK。 安装Android SDK (Android Studio)。 配置`ANDROID_HOME`环境变量。 下载ADB工具。 准备Android模拟器或连接真实设备。 iOS开发环境配置 (macOS): 安装Xcode。 安装Command Line Tools。 安装Homebrew(包管理器)。 安装WebDriverAgentRunner(用于iOS自动化)。 准备iOS模拟器或连接真实设备。 编写第一个Appium自动化脚本(以Java为例): 创建Maven/Gradle项目: 集成Appium Client库。 Desired Capabilities详解: `platformName`: 平台名称 (Android/iOS)。 `platformVersion`: 平台版本。 `deviceName`: 设备名称。 `app`: 应用路径。 `appPackage`/`appActivity` (Android): 应用包名和启动Activity。 `bundleId` (iOS): 应用Bundle ID。 `automationName`: 自动化引擎 (UiAutomator2, Espresso, XCUITest)。 `noReset`, `fullReset`: 应用安装和重置选项。 初始化WebDriver实例: `new AndroidDriver(new URL("http://127.0.0.1:4723/wd/hub"), capabilities);` 定位UI元素: ID: `driver.findElement(By.id("com.example.app:id/button_login"));` Accessibility ID: `driver.findElement(By.accessibilityId("Login Button"));` XPath: `driver.findElement(By.xpath("//android.widget.TextView[@text='Welcome']"));` Class Name: `driver.findElement(By.className("android.widget.Button"));` UIAutomator Selector (Android): `driver.findElementByAndroidUIAutomator("new UiSelector().textContains("Submit");");` Predicate String (iOS): `driver.findElementByIosNsPredicate("type == 'XCUIElementTypeStaticText' AND label == 'Settings'");` 执行操作: `sendKeys("username")` `click()` `getText()` `isDisplayed()`, `isEnabled()`, `isSelected()` 断言与验证: 使用JUnit/TestNG进行断言。 退出Driver: `driver.quit();` 第四章:精通UI元素定位与操作 挑战: UI元素动态变化,ID不唯一,XPath脆弱。 高级定位策略: 结合多种定位器: 例如,先通过Accessibility ID找到某个区域,再在其内部通过XPath定位。 使用XPath的健壮性技巧: 避免使用绝对路径,多用相对路径。 优先使用文本内容、内容描述(content-desc/accessibility-label)或ID。 利用属性进行筛选,如`[@text='Username']`、`[@content-desc='Submit Button']`。 使用`contains()`函数处理部分文本匹配。 查找父元素或兄弟元素。 Android UIAutomator Selector的强大之处: `resourceId("...")` `text("...")` `textContains("...")` `className("...")` `description("...")` `checkable(true)` `clickable(true)` `selected(true)` `enabled(true)` `longClick()` `swipeDown()`, `swipeLeft()`, `swipeRight()`, `swipeUp()` iOS Predicate String的精细化定位: `type == 'XCUIElementTypeButton'` `label == 'Done'` `name CONTAINS 'Settings'` `value == '123'` `isVisible == 1` Page Object Model (POM) 设计模式: 概念: 将每个页面(或页面的一部分)封装成一个类,页面中的UI元素和操作都封装在该类的方法中。 优点: 提高代码的可读性和可维护性: 测试脚本与页面元素分离,修改UI元素时只需修改Page Object类,对测试脚本影响最小。 减少代码重复: 页面中的公共元素和操作可以被多个测试用例复用。 提高测试脚本的可重用性: Page Object类可以被不同的测试套件调用。 实现方式: 创建Page Object类,每个类对应一个页面。 在Page Object类中定义UI元素的定位器(Locator)。 为每个UI元素提供访问器方法(Getter)。 提供执行页面操作的方法(如 `login(username, password)`)。 在测试脚本中实例化Page Object,调用其方法进行操作和断言。 手势操作与复杂交互: 滑动(Swipe): `driver.swipe(startX, startY, endX, endY, duration);` 拖拽(Drag and Drop): 通常需要结合TouchActions API。 长按(Long Press): `driver.tap(element, duration);` (Appium 1.x) 或通过TouchActions。 捏合(Pinch): 模拟缩放手势。 多点触控: 模拟多个手指同时操作。 滚动(Scroll): `driver.scrollTo("elementName");` (Appium 1.x) 或使用UIAutomator/Predicate String滚动。 处理下拉刷新、上拉加载更多。 第五章:测试数据管理与集成 测试数据的挑战: 保证测试数据的独立性、可重复性、多样性。 数据来源: 硬编码: 不推荐,不易维护。 配置文件: properties, JSON, YAML。 CSV/Excel文件: 方便导入导出,适合大量数据。 数据库: 存储大量结构化数据,方便查询。 API生成: 调用接口动态生成测试数据。 模拟数据生成器: Faker库等。 数据驱动测试(Data-Driven Testing, DDT): 概念: 将测试数据与测试逻辑分离,让测试脚本从外部数据源读取数据进行执行。 实现: 使用JUnit @Parameterized / TestNG @DataProvider注解。 读取CSV/Excel文件,将数据填充到测试方法参数中。 实现数据读取器类。 测试数据准备工具: Apache POI: Java API for reading/writing Microsoft Office files (Excel). Jackson/Gson: JSON解析库。 CSV reader/writer: 常用Java库。 SQL Connector/J: Java数据库连接。 处理动态生成的数据: 在测试开始前生成数据,并在测试结束后清理。 利用UUID、时间戳生成唯一标识符。 测试数据隔离: 确保每个测试用例的数据互不影响。 测试完成后进行数据回滚或清理。 第六章:自动化测试报告与结果分析 为何需要详细的测试报告? 清晰展示测试执行情况: 哪些用例通过,哪些失败,失败原因。 便于问题追溯: 记录执行日志、截图、视频等信息。 提供数据支持: 帮助团队评估应用质量和测试覆盖率。 沟通桥梁: 向项目经理、产品经理等展示测试成果。 集成报告工具: Allure Report: 功能强大: 支持多种语言和框架,生成交互式HTML报告。 丰富的信息: 测试步骤、日志、截图、环境信息、历史趋势。 集成简单: 通常只需添加依赖并修改配置。 ExtentReports: 易于使用: 提供友好的API,可定制性强。 支持截图: 方便在报告中直接查看失败的截图。 HTML报告(如JUnit/TestNG自带): 基础报告,可扩展。 报告的关键要素: 执行摘要: 总用例数、通过数、失败数、跳过数、通过率。 详细的测试用例执行日志: 每个步骤的操作、预期结果、实际结果。 失败的测试用例: 错误信息: 堆栈跟踪(Stack Trace)。 截图: 关键失败时刻的屏幕截图。 视频录制: 记录整个测试过程(可选,但非常有价值)。 环境信息: 测试设备、操作系统版本、Appium Server版本等。 执行时间: 总执行时间、各个用例的执行时间。 趋势分析: (结合CI/CD)测试结果随时间的变化。 结果分析与问题诊断: 分析失败原因: 是代码Bug、UI变化、环境问题还是测试脚本问题? 定位失败模式: 是否是特定场景或特定数据导致失败? 跟进修复: 与开发团队紧密协作,快速修复Bug。 分析假阳性(False Positives)和假阴性(False Negatives): 优化测试脚本,减少误报。 关注性能指标: 应用启动时间、页面加载时间、内存占用等。 第七章:自动化测试在CI/CD中的应用 DevOps与自动化测试: 自动化测试是DevOps流程中的关键一环,实现持续集成、持续交付。 持续集成(CI): 概念: 开发者频繁提交代码到共享仓库,通过自动化构建和测试,尽早发现集成问题。 Jenkins, GitLab CI, GitHub Actions等CI工具: 配置CI作业,在代码提交后自动触发。 拉取代码,构建应用。 部署应用到测试环境(模拟器或真机)。 执行自动化测试脚本。 生成测试报告,并进行通知(邮件、Slack等)。 持续交付/部署(CD): 概念: 在CI通过后,自动化地将应用部署到更高级别的环境(如Staging, Production)。 自动化测试作为质量门禁: 只有当自动化测试通过率达到一定阈值,应用才能进入下一阶段的部署。 构建可靠的CI/CD测试流水线: 测试环境的自动化管理: 云测平台: 百度AI开放平台、阿里云盾、Testin、Sauce Labs、BrowserStack等,提供大量真实设备和模拟器。 本地设备池管理: 对于内部使用,可以搭建自己的设备管理服务器。 测试用例的选择策略: 冒烟测试(Smoke Tests): 覆盖核心功能,执行速度快,每天或每次CI触发都运行。 回归测试(Regression Tests): 覆盖主要功能,确保新修改没有破坏现有功能。 特性测试(Feature Tests): 针对新开发的功能。 并行执行测试: 缩短测试时间,提高CI效率。 测试失败的处理策略: 及时告警,分析原因,快速修复。 性能测试与稳定性测试的集成: 定期运行,检测性能退化。 第八章:提升自动化测试的效率与稳定性 测试用例的设计原则: 简洁明了: 每个用例聚焦于一个具体的功能点。 可维护性: 易于理解和修改。 可重用性: 避免重复编写相似逻辑。 覆盖率: 覆盖正常流程、边界条件、异常场景。 原子性: 尽量减少用例之间的依赖。 减少测试脚本的脆弱性: 避免硬编码等待时间: 使用显式等待 (`WebDriverWait`) 代替隐式等待 (`Thread.sleep`)。 使用智能等待机制: 等待元素可见、可点击、内容加载完成。 选择更稳定的定位器: 优先使用ID、Accessibility ID,谨慎使用XPath。 Page Object Model的应用。 处理异步操作: 确保UI操作在页面加载完成后执行。 优化测试执行速度: 并行执行: 使用多线程或多进程。 选择高效的测试框架和驱动。 精简测试用例: 移除不必要的用例。 利用云测平台进行分布式执行。 异常处理与容错机制: try-catch块: 捕获潜在的异常。 重试机制: 对于不稳定的网络或偶发问题,可以设置重试。 自定义异常类。 代码审查与重构: 定期审查测试代码,保持其整洁、高效。 重构重复或冗余的代码。 使用Mock与Stub: 在单元测试或集成测试中,模拟第三方服务或复杂依赖,加速测试,降低对外部环境的依赖。 第九章:高级主题与未来展望 性能测试自动化: 应用启动时间、页面加载时间、内存占用、CPU使用率的监控。 使用工具如Traceview, Profiler(Android Studio),Instruments(Xcode)。 集成性能测试到自动化流程。 安全测试自动化: 权限管理测试。 数据加密与存储安全。 API安全测试。 AI在自动化测试中的应用: AI辅助的UI元素定位。 AI驱动的测试用例生成。 AI分析测试报告,发现潜在问题。 AI优化测试策略。 跨平台测试框架的演进: Flutter, React Native等混合应用测试。 无代码/低代码自动化测试工具: 降低测试门槛,让更多非技术人员参与。 持续学习与社区贡献: 关注技术动态,参与开源社区,不断提升自身技能。 结语 移动应用自动化测试是一项系统性工程,需要理论与实践相结合。本书从基础概念入手,深入剖析了主流自动化测试框架的原理与应用,并提供了丰富的实战指导。通过本书的学习,您将能够独立搭建自动化测试环境,设计和编写高效的测试用例,将自动化测试融入CI/CD流程,最终提升移动应用的质量和开发效率。希望本书能成为您在自动化测试领域成长道路上的得力助手。