| 编辑推荐: |
本文介绍如何设计移动端自动化测试策略，希望对您的学习有所帮助。
本文来自于简书
，由Alice编辑、推荐。 |
|
移动端自动化测试策略
随着移动互联网的深入发展，移动端APP的需求不断增加，越来越多的数字化企业开始注重其APP的建设。在市场竞争日益加剧的今天，互联网为快不破的方法论也影响着当下企业的决策。企业纷纷实行移动端产品的快速迭代模式：如阿里提出的2-1-1模式，美团的单周发版节奏等，这也给研发团队带来了移动端高效测试的压力，各大公司纷纷开始了移动端自动化测试的探索与实践之路。
相较于API自动化测试以及Web自动化测试而言，移动端自动化测试的实施成本相对较高，原因一方面是因为移动端由于Android与iOS两大阵营都有自己独立的生态体系，而且相比于Google的Android系统, 苹果的iOS 系统生态更加封闭一些：如只能依靠苹果提供的工具链等。同时由于开源工具和框架还不够稳定和丰富，移动端自动化测试面临了很多新的挑战：不同的机型，系统版本，分辨率，网络抖动等等，都会影响到自动化测试执行的结果。要想在移动端做好自动化测试，团队需要制定与其项目相匹配的测试策略与方法。
01 - 移动端自动化测试策略设计
在设计移动端自动化测试策略的时候，我们可以思考以下几个问题，看我们能否给出合理的理由：
-
为什么要做移动端自动化测试，自动化测试的价值在哪里？
-
你的项目中质量内建成熟度如何？
-
如果单元测试足够覆盖的情况下，是否还有必要做端到端自动化测试？
-
是否已经有移动端专项测试体系了，如性能，安全，兼容性，稳定性等？
-
你的团队是否已经有完善的基础设施了，如Mobile CI/CD ?
- 如果连打包，构建，分发都不是自动且持续的，先解决这个问题，再来考虑自动化测试吧。 要想富，先修路 。
分层测试策略
如下图Bagmar Anand所画的测试金字塔所示：
在不同的层，我们所关注的重点会有所不同。
因此需要使用分层测试策略，制定不同的测试目标：
- 实现核心稳定的用例自动化，用于每次的迭代回归测试
- 对于新功能或者频繁变动的功能，采用手工探索性测试
- APP 的可用性与UX测试，可以引入产品和设计人员参与测试
- 对于一些UI样式和兼容性等需求，使用自动遍历测试
- APP的稳定性，可以采用随机测试，并且采集测试过程中的设备性能数据
- APP性能和安全测试，需要采用安全和性能专项测试策略
用例稳定性设计
自动化测试用例的稳定性和可维护性非常重要，关系到自动化的成效，需要关注以下几点：
1. 使用稳定的测试框架和工具
很多人喜欢造轮子，没有对开源框架的优缺点进行评估和分析，就开始自己实现一个简易版的框架和工具，在这里是不太推荐的，
一个稳定的测试框架是自动化测试的基础，在规模化的自动化测试工程中，稳定比灵活更加重要。我们可以在开源框架不符合需求的情况下，先进行二次开发，也不要贸然就从零开始自己写一个。
2. 失败重试机制，智能等待策略，智能判断等
自动化测试执行过程中，可能会遇到各种各样的突发异常，如网络波动，内存溢出导致APP进程被系统强制杀死等，因此必须要考虑容错处理，避免因环境的问题导致用例执行失败。
3. 好的测试用例设计方法
好的用例设计方法，可以使我们的用例具备更好的可维护性以及可读性。我们可以采用以下几种业内常用的设计方法：
- Page Object Model
- BDD
- Data Driven / Keywords Driven
02 - 移动端自动化测试框架
好的测试框架需要具备以下九个特点：
- 稳定性（框架必须有很多真实的使用案例，并且有稳定的版本，以及社区持续维护）
- 可扩展性 （用户可以很方便进行二次开发）
- 清晰的架构 （框架的设计必须清晰，模块化）
- 易于使用 （让测试开发人员可以用更多的精力投入用例编写上，而不是去耗费时间熟悉框架）
- 跨平台支持（windows, linux, macos）
- 可集成性 （可以与不同的CI平台集成，如Jenkins, GoCD, Bamboo等）
- 报告 （有易读的测试报告）
- 日志 （有友好的日志与错误提示）
- 技术栈支持 （可以支持多种语言技术栈工具）
业内有很多开源的测试框架，大部分具备上述这些特点，如开源社区的Robot Frameowork, Cucumber, 提供商业支持的Katalon, 以及阿里的Macaca 和网易的Airtest等，深入研究其中一种即可，详情可以参见这些项目的官网。
Robot Framework: https://robotframework.org/
Cucumber: https://cucumber.io/
Katalon: https://www.katalon.com/
Airtest: http://airtest.netease.com/
Macaca: https://macacajs.github.io/zh/
03 - 移动端测试工具
工欲善其事，必先利其器
选择移动端测试工具，目前业界使用比较多的移动端自动化测试工具有Appium, 它可以同时支持Android和iOS 模拟器和真机的自动化测试。下图是Appium的一个技术原理图。Appium采用B/S架构设计，整体分为服务端和客户端两个部分，Appium服务端是用nodejs实现的，提供REST API 服务的一个WEB服务器，主要是用来管理测试执行和结果反馈的。Appium客户端则提供了多种语言的三方库支持，可以方便开发人员使用自己熟悉的语言调用Appium客户端三方库来与Appium服务端进行交互。
为什么Appium是使用最广的移动端自动化工具，这也与它的设计理念有关：
Appium 的理念
Appium 旨在满足移动端自动化需求的理念，概述为以下四个原则：
- 你不应该为了自动化而重新编译你的应用或以任何方式修改它。
- 你不应该被限制在特定的语言或框架上来编写运行测试。
- 移动端自动化框架不应该在自动化接口方面重造轮子。
- 移动端自动化框架应该开源，在精神、实践以及名义上都该如此。
04 - 执行自动化测试
自动化测试脚本不仅仅是本地执行，从下图 DORA 给出的《 2019 DevOps 报告 》中可以看出，持续自动化测试是未来的趋势，因此必须要将自动化测试脚本集成到CI环境中。
一个好的持续测试需要关注以下四点：
速度 （Speed）
可靠性 （Reliability）
数量 （Quantity）
维护性（Maintenance）
05 - 测试脚本管理
自动化测试工程脚手架
自动化测试工程脚手架的目的是用于快速初始化一个测试工程项目，并且引入一些最佳的规范实践。同时对测试工程模块化划分，更有利于测试用例的开发与维护。
测试脚本版本控制管理
测试脚本也需要进行版本化管理，这样可以方便多人协作用例的开发维护，同时使用一定的分支策略，也保障了测试脚本的稳定性。
脚本可维护性
BDD + PageObject 构建可读性与可维护性的用例
-
用BDD的方式来编写测试用例，基于Gherkin语法， Given-When-Then 这样的用例更加易读。
使用PageObject来对UI页面和页面上的操作进行封装与页面对象建模，从而实现对上层用例屏蔽底层的具体实现细节，达到更好的功能复用。
06 - 自动化测试成效度量
我们可以通过一些指标来度量自动化测试的效果，并且快速给出反馈。
其他细节指标还有很多，可以选择团队中关注的部分来统计度量：
- 自动化测试需求覆盖率
- 自动化测试在测试用例中的占比
- 自动化测试通过率/失败率
- 缺陷逃逸率
- 缺陷发现率
- 自动化测试执行时间
- 自动测试失败流水线终止比率
- Flaky Test不可靠测试用例数
- 更多......
附图：统一自动化测试架构
我们可以用开源的框架和工具快速搭建一套多端自动化测试架构，并且具备高度的可扩展性。
工具清单
- 通用测试框架：Robot Framework
- APP测试工具：Appium
- Web测试工具：Selenium
- API测试工具：Requests
- iOS底层框架：XCUITest
- Android底层框架：Google UIAutomator2
- 持续集成平台：Jenkins
- 消息通知平台：Slack, 企业微信, Email
- 云测平台：Testin, SauceLabs, BrowserStack
- 执行环境：Docker
Q&A
- 如果单元测试足够覆盖的情况下，是否还有必要做端到端自动化测试？
从测试金字塔中可以看出，每一层的侧重点不同，而且都是不可或缺的。 这是因为单元测试是对软件中最小的单元进行功能验证和测试（从内部结构上），完备的最小单元功能的测试覆盖率 并不能保证端到端不出问题。而UI端到端自动化测试是对 软件提供的端到端业务功能模拟用户操作进行验收（从外部行为上）。并且基于2/8原则：用户最常用的功能大致占 软件所提供功能的20%，我们可以重点保障高业务价值，且稳定的核心功能自动化，加快回归测试效率，同时 可以增强团队信心。
- 如果团队已经实现了95%甚至更高的单元测试覆盖率，“是否还有必要做端到端自动化测试”呢？
高百分比的单元测试覆盖率并不直接等同于高代码质量，也可能出现需求漏做，异常漏处理等情况。更不能直接等同于业务功能需求的覆盖率。 单元测试有其自身的价值，如增强重构信心等；但是不能说100%的单元测试，就不需要其他测试手段，除非我们明确知道单元测试和外部行为的映射 关系，那么通常我们不太好说单元测试对外部行为的影响，因此也不能完全依赖于单元测试，而是需要多种测试手段从不同维度来保障系统功能正确性。
- 对于移动端的可测性，目前有无相对成体系的评价标准？
移动端应用的可测性相对于API或者Web UI而言，还是偏低的；网络/数据，应用状态，APP内部存储等都缺乏可观察性，对可测性也带来了挑战； 目前业内也都在探索一些移动端可测性的一些方法，比如通过deeplink来直接进入到待测页面，避免前序路径复杂或者难以到达等
|
