Python自动化-APPium原理解析与测试实际案例分享
目录结构
一、Appium概述 1. Appium架构原理 2. 运行原理 1）Appium服务器 2）Bootstrap.jar 3）Appium客户端 二、Appium组件 三、Appium环境搭建 1. Node.js安装 2. Appium安装 3. Appium-Desktop安装 4. Python安装 5. Appium-Python-Client安装 6. JDK安装、Android SDK安装 7. Appium-doctor安装
一、Appium概述
Appium是一个开源自动化测试框架，使用WebDriver协议驱动IOS/Android/Windows应用程序，可用于原生、混合、移动Web应用程序的测试
Appium优势：
①可跨平台，同时支持Android、IOS
②支持多种语言：Java/Python/PHP/Ruby等等
③配置环境简易
④与Selenium有共通之处，便于快速上手
1. Appium架构原理
Appium是在手机操作系统自带的测试框架基础之上实现的， 对原有的自动化测试框架进行封装改良。
Android和IOS系统上使用的工具分别如下：
Android(>4.3)：UIAutomator，Android4.3之后系统自带的UI自动化测试工具
Android(≤4.3)：Selendroid，基于Android Instrumentation框架实现的自动化测试工具
IOS: UIAutomation（Instruments框架里面的一个模板)，IOS系统自带的UI自动化测试工具，相当于IOS封装了UIAutomation
2. 运行原理
电脑端运行自动化测试脚本，调用的是webdriver的接口，appium server接收到电脑端发送过来的命令后会将这些命令转换为UIautomator可识别的命令，然后由UIautomator在移动设备上执行自动化测试。
Appium架构是由客户端（Appium Client）和服务器（Appium Server）两部分组成，客户端与服务端通过JSON Wire Protocol进行通信
1）Appium服务器
Appium服务器是Appium框架的核心，是基于Node.js实现的HTTP服务器，Appium服务器的主要功能是接受从Appium客户端发起的连接，监听从客户端发送来的命令,将命令发送给bootstrap.jar（IOS手机为bootstrap.js）执行，然后将命令的执行结果通过HTTP应答反馈给Appium客户端
2）Bootstrap.jar
Bootstrap.jar是在Android手机上运行的一个应用程序，它在手机上扮演TCP服务器的角色。当Appium服务器需要运行命令时， Appium服务器会与Bootstrap.jar建立TCP通信，并把命令发送给Bootstrap.jar，由Bootstrap.jar负责运行测试命令
3）Appium客户端
主要是指实现了Appium功能的WebDriver协议的客户端Library，它负责与Appium服务器建立连接，并将测试脚本的指令发送到Appium服务器。
现有的客户端Library有多种语言的实现，包括Ruby、Python、Java、JavaScript(Node.js)、 Object C、PHP、C#，而Appium的测试是在这些Library的基础之上进行开发的
二、Appium组件
Appium Server
Appium是一个C/S结构，包括Server和Client。Appium Server是Appium的服务端，作为一个Web接口服务，使用Node.js实现
Appium Desktop
Appium Server的图像界面，可设置启动or停止服务器、查看日志，可使用inspect查看应用程序的元素
Appium GUI
是Appium Desktop的前身，也是把Appium Server封装成一个图像界面
Appium Client
Appium Client作为客户端，会给服务端Appium Server端发送请求会话来执行自动化任务。类似使用浏览器访问网页，可使用不同的客户端浏览器（IE/Firefox/Chrome...）访问同一个网站，通过操作发送请求到服务器来获取数据
Appium Client可使用不同的语言来实现，如：Python/Java
Python：https://github.com/appium/python-client
Java：https://github.com/appium/java-client
三、Appium环境搭建
环境依赖：
Node.js
Appium
Appium-desktop
Appium-doctor
Appium-Python-Client
Python
JDK
Android SDK
1. Node.js安装
中文站传送门：http://nodejs.cn/download/
官网传送门：https://nodejs.org/download/release/latest/
检查安装效果：
node -v npm -v
2. Appium安装
传送门：https://github.com/appium/appium/releases
Appium是由Node.js编写的，可直接利用包管理工具npm进行安装Appium：
npm install -g appium
但因网络特殊情况，常规网络下安装较慢甚至安装不成功，如下安装异常：
调整安装策略：
采用国内镜像源安装的方式，首先需要利用npm包管理工具安装cnpm，然后再利用cnpm安装Appium
镜像设置，安装cnpm：
npm install -g cnpm --registry=https://registry.npm.taobao.org
利用cnpm安装Appium：
# 安装最新版本 cnpm install -g appium # 安装指定版本 cnpm install -g appium@版本号
查看appium安装路径：where appium
查看appium版本：appium -v
运行appium：appium
3. Appium-Desktop安装
appium-desktop是对Appium Server和Node.js依赖环境进行封装过的图形界面工具
传送门：https://github.com/appium/appium-desktop/releases
根据需要选择适配自己操作系统的版本进行下载，启动时直接运行即可（启动过程比较缓慢，内存占用较高。。。）
双击运行，耐心等待
配置参数：
查看保存在预设中的配置：
启用Appium服务：
检测手机元素，会话请求相关配置的修改界面：
获取appium server的日志内容：
停止appium server：
停止appium server后，关闭appium server监听的界面接即可返回到启动初始界面：
4. Python安装
传送门：https://www.python.org/downloads/
过程从略。。。
5. Appium-Python-Client安装
安装命令：pip install Appium-Python-Client
检查安装效果：进入python，输入from appium import webdriver回车后无异常
6. JDK安装、Android SDK安装
参看：Android系统基础：Android SDK和Android模拟器安装使用 | adb命令实践
7. Appium-doctor安装
appium-doctor可检测Appium整体依赖环境配置的情况
安装命令：cnpm install appium-doctor -g
检查安装效果：appium-doctor
之前，我请大家先思考如下2个问题：
第一，我们为什么要做好测试用例设计？——why？
第二，好的测试用例设计有什么共性？ ——what?
深入思考这2个问题的答案是一件很有意义的事情，作为移动互联网时代的产品质量守卫军，我们必须提升自己的测试设计能力，必须清楚的知道要测什么，怎么测。但单从我们测试团队现状来看，有很多人都没有做好准备，测试设计方法仍然比较落后，所以我整理此文，旨在总结沉淀移动客户端测试用例设计实践，帮助测试人员时刻审视完善自我测试能力提升。
那么回到文章开头的2个问题，我也说一下我的理解，有不妥当之处望同行指出。
Why? 为什么要做好测试用例设计？
测试用例设计的目的，通俗来讲主要是通过对需求点的测试设计从而避免测试点的遗漏，而且现在每个公司也都非常认同测试用例设计这个环节存在的必要性和意义，不论测试用例设计的好坏与否，该环节的存在都对质量和效率起到最基本的促进作用。
那么我们为什么要做好测试用例设计？
第一，测试用例设计能力的好坏，直接影响了开发人员对我们的第一印象的好坏。例如，我们如何评价一个优秀的开发人员呢？
1、coding好，bug少
2、思维严谨，沟通顺畅，有责任心...
同理心，开发人员一般怎样评价一个优秀的测试人员呢？
1、case覆盖率高，漏测少
2、思维严谨，沟通顺畅，有责任心...
所以，测试人员写不出好的测试用例，就如同开发人员写不好代码一样，有点丢面儿，但是往往很多测试人员根本也意识不到这一点，包括我遇到很多工作了五六年的资深测试人员，测试用例设计能力很一般，姿态却摆的老高，这里就不说了。我想表达的是，测试用例设计毕竟是门基础课，不论是测试新兵老兵，没学好没学扎实都建议再学一遍。
第二，测试用例设计的好坏，直接关系着最根本的测试质量和测试效率的优劣。为什么这么说，从质量角度，好的测试用例设计都是需要经历根据需求设计层层剥析，开发设计逻辑的深入理解去构造的，因而其测试点挖掘的往往更深，场景更全，发生漏测的几率也更低。从效率角度，在开发人员提测前就做好的高质量测试设计，在测试执行阶段，则不用再去费心构造设计，按计划执行完测试用例后，那么这个需求的测试就基本完成了。
what?好的测试用例设计的共性？
这其实是一个见仁见智的问题，不同的测试人员有不同的测试设计风格，这里我们求同存异即可。好的测试用例设计的共性大致如下：
（1）测试设计结构组织合理。从测试用例的组织是开展测试的起点，良好的组织能够帮助我们快速定位到我们想关注的部分，这个部分的好坏关系到测试工作的持续性发展。
（2）测试用例设计覆盖全面且不冗余，用精简的语言描述清楚一条测试用例，用较少的测试用例描述清楚需求测试点的覆盖。
（3）测试用例设计具有可执行，可判定，可再现的特点，即在测试前提符合的前提下，按照测试步骤每一个测试用例都可以顺利执行，同时呈现相应的预期结果，而且测试用例在被多次执行的结果都应该是相同的。
另外在编写测试用例时，建议由提纲挈领到逐步细化，先写基本功能点，再逐步增加细节，切忌过早的陷入细节描述。同时测试设计粒度要适中，根据实际项目的测试效率和效果去平衡，太粗太细都不合适。
移动端测试设计—面向问题发现的测试全面性组织方式
移动客户端平台的测试，在传统的软件测试基础上，本身又具有自身比较突出的诸多特点。比如客户端平台多样化，系统碎片化问题突出，灵活性极高，因此仅仅将测试停留在基本功能以及传统理念上的测试组织，来确保移动客户端的测试全面性是不够的。
传统的用例组织方式，如等价类划分，边界值分析，因果分析等，更多的是从面向如果精简测试用例，确保测试全面的前提下，尽量降低冗余而来的。现在我们推荐一种是面向问题发现的测试的组织方式，即由bug出现的分布对应相应的测试内容，从而达到测试全面性的一种组织方式。
3.1 Basic – 基本功能测试
面向于被测应用的基本功能实现， 在测试用例的组织上，主要可以通过功能分层，逐级细化；画出草图，然后文字化得方式书写。主要采用功能图分析方法，因果图分析方法。
基本功能测试可以称之为一般性的功能实现测试，这部分可以不完全去考虑实现的好坏(如读取文件的速度)，不考虑特殊的输入输出，不考虑特殊的中断，不考虑特殊的环境。我们组织用例时，考虑将基本功能测试点和其他特殊测试内容分离的原因在于，按照经验，我们倾向于认为，基本功能在一般状况下，在实现并在一轮完整的测试之后通常即可保证该部分是完备的，之后的问题一般的都是出现在基本功能实现基础上的特殊状况中。因此如此组织用例，有利于我们后期，适当的裁剪测试用例，将更多的测试精力放在容易发生问题的部分，而基本功能基本上可以通过特殊状况的检验而覆盖到。
3.2 Boundary – 边界分析测试
在基本功能的基础上，开始考虑各种输入输出的影响。一般的，基本功能容易在边界附近出问题。主要采用等价类划分方法，边界值分析方法。用例组织上，可以梳理已经产出的基本功能草图，确定哪些部分存在边界问题。并构造测试用例，执行测试工作。
如：
· 边界类型数值大小 ，输入的数值的范围
· 字串长短，Null-max-max+1
· 内容有无
· 支持与否，（保留字符，特殊字符，计划外字符。
3.3 Memory – 存储测试
主要测试涉及存储空间读写的部分。最大的问题还是内存泄漏(memory leak)。
在测试用例组织上，主要考虑哪些部分容易发生memory的问题。特别是移动客户端容易出现的问题：
· 比如旋转屏幕—响应G sensor，画面需要重新载入，重新载入前的页面可能会发生内存无法释放的问题。移动客户端相对特有的。
· 连续加载页面
· 开多个窗口—比较典型的，如浏览器
· 应用多次的互相调用—应用之间的相互调用，调用传递之间，可能存在问题，另外要特别注意“重入”；所谓重入，是指一个应用A叫起了应用B，但是应用B又可以再次叫起应用A，如message编辑时插入图片可以叫起camera，拍摄之后，camera可以不直接返回message编辑器窗口，而是通过点击分享-message，重入message编辑器，由此产生循环的栈叠加，也容易发生内存问题。
· 多线程下载
3.4 Performance – 性能测试
响应速度，资源占用，流量消耗，CPU占用的测试需要比对benchmark，并依据和benchmark的比对来判断被测试应用的表现能力，另外一个参考是我们在立项阶段的对某些核心内容的预期，或者用户主观感受。立项初期就选择合适的竞品，选择核心的用例。所谓核心用例主要是依据用户的一个使用习惯，调研反馈总结出那些核心数据是用户在意的。比如一款导航产品，位置平均误差会有一个用户体验可以接受的范围，对路径的优化结果会有一个主观感受等等。在测试执行时，切忌完全依赖于主观感受，对修复的预期缺乏清晰的目标。比如，我们认为一款产品的首页打开速度很慢，那多快才是我们所预期的，这个需要我们明确。
3.5 Stress – 压力测试
可以简单理解为在基本功能上的提升负载，速度，吞吐量等性能指标。一般的，移动客户端通过monkey之类的测试工具加以覆盖，以及录制回放工具之类的测试来实现压力检验。
3.6 Capability – 兼容性测试
兼容性测试是指测试软件在特定的硬件产台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能很好地运行的测试。简单的说，兼容性测试是指测试某新开发的软件在某一特定环境下与各种软件的协调性，软件之间能否很好的运作。
移动客户端常见的兼容性测试测项
· 网络兼容性测试（不同运营商3G，4G， WIFI，弱网）
· 操作系统兼容性测试 （Android>=2.3， IOS >=7.0）
· ROM类型兼容性（主流厂商如苹果，华为，小米，魅族，OPPO等）
· 分辨率兼容性测试 （各种不同的分辨率）
· 数据兼容性（不同版本间的数据兼容）
· 其他可能会涉及移动客户端兼容性测试测项
· 蓝牙设备兼容性测试 （如果是一款使用蓝牙的应用）
· 存储卡兼容性测试（比如文件管理器）
· 第三方软件兼容冲突（比如输入法冲突）
3.7 Interrupt – 中断功能测试
当前的被测应用被另外的应用打断当前的功能执行状态。在用例组织上，主要在考虑执行某项操作时的系统打断，比如：
· 来电
· 短信
· 闹钟提醒，日历提醒，蓝牙提醒
· 插拔数据线，插拔耳机
· 待机，锁屏
· 低电量提醒
3.8 Interaction – 交互功能测试
应用以及应用之间的调用，以及不存在应用层面的调用，但是存在更低一层的资源抢夺以及公用。比如：
· 页面占用
· 内存占用
· 音频资源占用
· 摄像资源占用
移动端测试设计的实践经验
上文我们通过全面测试的指导思想提出了多种测试设计方法，但是每种测试方法其实都有一个最佳测试时间，如在版本测试阶段，我们应当要先做基本功能测试，边界分析测试和中断，交互功能测试，快速发现bug提单给开发去快速修复，保证主体功能可以尽快得到保证，而不是一开始就先纠结与性能，压力和兼容测试。一方面这类测试往往所消耗的时间会很长，降低了发现bug的速度，另一方面先做这部分测试后，再去发现主体功能的bug，那么在开发人员动了大量代码之后，还是要再执行一遍性能，压力和兼容测试的相关用例，不仅劳命伤财，效果还事倍功半。
所以在实际项目测试中，当前我们的项目将测试内容分为功能测试，兼容性测试，性能测试，稳定性测试四项，分别在不同的测试阶段进行（具体排期在测试计划时确定）：
（1）功能测试 —— 版本测试阶段
（2）兼容性测试 —— 回归测试阶段前期
（3）性能测试 —— 回归测试阶段，版本功能稳定后执行
（4）稳定性测试 —— 贯穿整个测试阶段，每晚执行monkey
因此我们的功能用例更多的会使用『基本功能测试』，『边界分析测试』『中断功能测试』『交互功能测试』这几类测试用例设计方法。具体大家在做项目测试时，也建议通过实际情况做调整。 荀子曰，”不闻不若闻之，闻之不若见之，见之不若知之，知之不若行之，学至于行止矣。”上文讲的方法论，只有通过大量的坚持实践和不断的总结积累，才能打破固有思维，提升自己的测试用例设计能力。因此我们也提炼了一些移动客户端的常见功能的测试用例设计点，这里就提供下我们总结的APP页面类型功能的测试点，大致如下：
1. UE体验
（1）布局与交互图保持一致
（2）真机效果与UE图没有视觉上的严重偏差，如字号，字体大小，加粗，字体颜色，行高，行间距，按钮摆放位置，间隔，尺寸等。
（3）资源图正确使用，没有不必要的拉伸，压缩或其他效果。
（4）各种提示，文字通顺不产生歧义，展示符合用户使用习惯。
（5）动画效果不卡顿，正常展现。
2. 页面操作
（1）是否有防重复点击，即连续快速点击不会出现多个页面或弹窗
（2）单指滑动，单指单击，单指双击，单指长按，单指缩放，多指点击
（3）摇一摇，横竖屏切换，前后台切换
（4）长时间使用，长时间放在后台
3. 不同场景下的页面操作
（1）不同网络，弱网下的页面跳转，点击响应的展现效果
（2）修改本地参数后的页面操作展现效果，如修改日期，时间，时区，语言，键盘等
（3）修改系统权限后的页面操作展现效果，如打开关闭定位，摄像，照片，通讯录等的授权等
（4）页面操作过程中有系统打断，如来电，短信，闹钟提醒，日历提醒，蓝牙提醒，插拔数据线，插拔耳机，待机，锁屏，低电量提醒等
（5）页面操作过程中进行前后台切换，如当页面数据交换时，有弹窗，提示框的时机进行切换容易发现问题。
（6）针对非主线程调用的接口，前端要对异常及无网络情况做异步处理，不提示异常且不影响主线程操作。
4. 页面数据获取和展现
（1）页面是否有缓存，缓存机制是怎样的，缓存的内容有哪些
（2）在提交页面数据失败后是否有重试机制，重试的接口参数是否保持不变
（3）在页面操作过程中，异步接口返回的内容，是否对用户透明（客户端兼容忽略请求返回msg）
作者：测码软件测试官方 https://www.bilibili.com/read/cv4144604/ 出处：bilibili
