移动端自动化测试策略
随着移动互联网的深入发展，移动端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 - 自动化测试成效度量
我们可以通过一些指标来度量自动化测试的效果，并且快速给出反馈。
| 测试的因素 | 指标 | 目标 |
|---|---|---|
| 自动化测试是否有意义 | 跟踪因实际缺陷导致的自动化测试失败的数量，以及因自动化测试脚本本身编码质量问题而导致的自动化测试执行失败的数量。 | 测试失败始终代表着产品中存在实际缺陷 |
| 自动化测试是否在流水线中执行 | 检查是否所有测试套件均在每个流水线触发器中运行 | 自动化测试在主流水线和主工作流中运行。 |
| 在验收测试、探索性测试和生产环境中发现的 Bug 数量。 | 所发现的 Bug 的比例随时间的变化。 | 在“修复成本较低”的测试阶段发现更多 Bug，团队可针对在探索性测试期间和生产环境中发现的 Bug 增加自动化测试，同时添加单元测试以发现在验收测试中发现的 Bug。 |
| 自动化测试ROI | 持续统计自动化测试的投入与收益比 | 随着时间推移，自动化测试的投入稳定，收益逐步增长 |
其他细节指标还有很多，可以选择团队中关注的部分来统计度量：
- 自动化测试需求覆盖率
- 自动化测试在测试用例中的占比
- 自动化测试通过率/失败率
- 缺陷逃逸率
- 缺陷发现率
- 自动化测试执行时间
- 自动测试失败流水线终止比率
- 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来直接进入到待测页面，避免前序路径复杂或者难以到达等，或者Mock数据来构造场景验证UI功能等，不过体系化的评价标准，目前还没有，大家都还在积累一些实践经验。
