《腾讯Android自动化测试实战》读书笔记
# 介绍
《腾讯Android自动化测试实战》是16年腾讯移动品质中心（TMQ）出版的一本书。从2023年的角度来看，涉及到的跟多技术框架相对比较过时了，monkey目前已经被app-crawler替代，robotium也不再维护，uia已经进化到了uia2.2，appium进化到了2.0版本。
不过涉及到很多有丰富价值的实践案例和测试经验。视频性能测试等部分涉及了广阔的技术栈，关于各个框架的优劣和选型，以及在实际应用中的最佳实践选择，都给出了很好的方法论指导。相对来说后半部分的实践章节还是非常有阅读价值的，值得自动化领域相关同学借鉴学习。
# 1.内容综述
# 框架方案选型对比
主要是Monkey，Robotium，UiAutomator，Appium四个主要框架的基本入门。
关于框架的选型：如果熟悉Java语言，又面临Debug未混淆被测App的情况，可直接使用Robotium框架，因为Robotium操作简单、相关资料丰富，还能支持ant、maven打包，与jenkins结合较好；但Robotium不支持跨应用，所以对于需要支持跨应用的框架，可使用UIAutomator和Appium框架，其中Appium是借助WebDriver JSON协议实现的，能支持多种语言编写测试脚本；
# 自动化测试框架基本原理
自动化框架包括三个核心部分：一是如何获取坐标/控件并操作控件模拟用户端事件，二是脚本中的结果如何判断，三是测试结果报告的输出与展示。
# 2. UIAutomator 框架及实践
# 框架解读
UIAutomator的核心优势
官方目前大力支持的框架之一（另外一个是Expresso），
基于安卓原生控件解析，比坐标类型的兼容性更好
提供了丰富的等待机制
不依赖源码(纯黑盒)
可以跨应用。
目前官方最新的uiautomator2，2.2.0版本，已经有30多个类了，代码地址 (opens new window)
其中使用最多的五大基础类为UiDevice、UiSelector、UiObject、UiCollection、UiScrollable，
UiDevice是当前测试设备的抽象，相对来说是最重要的一个类，用来和当前的设备做交互用的
UiSelector是UiObject的成员变量，该变量的作用是用来约束控件的唯一性。
UiWatcher机制是uiautomator中一个非常重要的能力，可以用来做异常处理检测的逻辑。
重要
基于控件的自动化测试框架最重要的两个工作：控件解析和事件注入。
界面解析用于获取目标控件，事件注入用于完成操作交互。
click()方法的完整流程： 1.根据uiSelector查找到节点信息； 2.根据节点信息，获取到边框信息 3.根据坐标调用注入点击事件
控件遍历过程中每次只返回一个节点信息而不是控件树，效率比较低。
# 具体实践
(1) 用例代码，采用中断式风格的代码，所有的if判断都采用断言来做替换，不用显式的抛出异常。实际上这里一旦错误，框架会自己抛出异常，这样就使代码非常的干净清爽。
(2) tearDown()方法通常用于做测试执行后的结果收集及环境恢复。
(3) 用例设计原则，用例之间无依赖关系。前置条件都是明确的，谁污染谁治理，谁改的谁负责改回去。
# 3. Appium 框架及实践
# Appium架构原理
Appium服务器是基于node.js实现的http服务器。
Appium框架的4个优点：
1.黑盒，不依赖被测应用源码
2.跨平台，
3.支持应用间跳转
4.不限制语言。
# 具体实践
Appium查找元素，强依赖控件id。如果没有控件ID，建议与开发者沟通让其添加。因为控件的ID一般很少改变，后期维护成本小；而控件的文本等信息变更的可能性很大，每次变动测试脚本都需要投入维护成本；
# 测试脚本设计思想(本章比较精华的部分)
(1) 自动化脚本的开发其实不难，难的是长期的维护。因此测试用例的脚本设计，一定要体现出可重用性和稳定性，从而降低维护成本。这个原则是UI自动化的核心方法论。
(2) UI自动化最能产生收益的地方，是回归老功能
(3) 用例之间一定不能产生耦合，要遵循谁污染，谁治理的原则。
(4) 公共步骤的作用，是降低过程变化时的维护成本，流程有变化时，只需要改动公共方法就可以。
(5) 控件信息的变化，主要思想其实还是做隔离，将控件信息隔离到一个单独的常量文件中，有重复使用的地方，复用这个常量文件即可。
# 关于UI自动化的反思
如何应对UI自动化给人“变化太大，收益太低”的质疑。
1.降低建设成本，选择低学习成本且高效率的框架很重要。
2.提高使用频率，频率越高，收益就越高。
3.优先选择变动比较小的模块，
4.发掘多种业务使用场景，例如性能测试，热更新测试，场景越多，带来的收益就越大。