补充：
“好的”测试用例必须具备哪些特征？
.。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。
1、：
（1）
（2）
（3）
（4）
（5）
（6）
（7）
（8）
(9)
（10）
12-19GUI自动化测试
浅谈移动应用测试方法与思路 移动端应用又可以进一步细分为三大类：Web App、Native App 和 Hybrid APP Web App指的是移动端的Web浏览器，其实和PC端的Web浏览器没有任何区别，只不过Ｗｅｂ浏览器所依附的操作系统不再是Ｗｉｎｄｏｗｓ和Ｌｉｎｕｘ了，而是IOS和AndroidＷｅｂＡｐｐ采用的技术主要是传统的HTML、Javascript、CSS等技术栈，当然现在Ｈｔｍｌ５也得到了广泛的应用。另外，ＷｅｂＡｐｐ所访问的页面内容都是放在服务器端的，本质上就是Ｗｅｂ网页，所以天生就是跨平台的Native APP指的是移动端的原生应用。对于Android是ａｐｋ，对于ｉｏｓ就是ｉｐａ。NativeＡｐｐ是一种基于手机操作系统（ｉｏｓ和Android），并使用原生程序编写运行的第三方应用程序。ＮａｔｉｖｅＡｐｐ的开发，Android使用的语言通常是Java，ｉｏｓ使用的语言是Ｏｂｊｅｃｔｉｖｅ－C。通常来说，ＮａｔｉｖｅAｐｐ可以提供比较好的用户体验以及性能，而且可以方便地操作手机本地资源。ＨｙｂｒｉｄAｐｐ（俗称：混血应用），是介于ＷｅｂＡｐｐ和NativeＡｐｐ两者之间的一种Ａｐｐ形式。ＨｙｂｒｉｄＡｐｐ利用了WebＡｐｐ和ＮａｔｉｖｅＡｐｐ的优点，通过一个原生移动应用中嵌入了Ｗｅｂｖｉｅｗ，然后通过该Ｗｅｂｖｉｅｗ来访问网页。
ＨｙｂｒｉｄＡｐｐ具有维护更新简单，用户体验优异以及较好的跨平台特性，是目前主流的移动应用开发模式。
针对不同的应用测试：对于 Web App，显然其本质就是 Web 浏览器的测试。
如果你的 Web 页面是基于自适应网页设计（即符合 Responsive Web 设计的规范），而且你的测试框架如果支持 Responsive Page，那么原则上你之前开发的运行在 PC Web 端的 GUI 自动化测试用例，不做任何修改就可以直接在移动端的浏览器上直接执行，当然运行的前提是你的移动端浏览器必须支持 Web Driver。
对 Native App 的测试，虽然不同的平台会使用不同的自动化测试方案（比如，iOS 一般采用 XCUITest Driver，而 Android 一般采用 UiAutomator2 或者 Espresso 等）.对 Hybrid App 的测试，情况会稍微复杂一点，对 Native Container 的测试，可能需要用到 XCUITest 或者 UiAutomator2 这样的原生测试框架，而对 Container 中 HTML5 的测试，基本和传统的网页测试没什么区别，所以原本基于 GUI 的测试思想和方法都能继续适用。移动应用专项测试的思路和方法
移动端测试：兼容性问题
第一：交叉事件测试
交叉事件测试也叫中断测试顺序，是指App执行过程中，有其他事件或者应用中断当前应用执行的测试。
此类测试目前基本还都是采用手工测试的方式，并且都是在真机上进行，不会使用模拟器。
交叉事件测试，需要覆盖的场景主要包括：
多个 App 同时在后台运行，并交替切换至前台是否影响正常功能；要求相同系统资源的多个 App 前后台交替切换是否影响正常功能，比如两个 App 都需要播放音乐，那么两者在交替切换的过程中，播放音乐功能是否正常；App 运行时接听电话；App 运行时接收信息App 运行时提示系统升级App 运行时发生系统闹钟事件App 运行时进入低电量模式App 运行时第三方安全软件弹出告警；App 运行时网络切换第二：兼容性测试
兼容性测试顾名思义就是，要确保 App 在各种终端设备、各种操作系统版本、各种屏幕分辨率、各种网络环境下，功能的正确性。常见的 App 兼容性测试往往需要覆盖以下的测试场景：
不同操作系统的兼容性，包括主流的 Andoird 和 iOS版本主流的设备分辨率下的兼容性；主流移动终端机型的兼容性；同一操作系统中，不同语言设置时的兼容性；不同网络连接下的兼容性，比如 Wifi、GPRS、EDGE、CDMA200 等在单一设备上，与主流热门 App 的兼容性，比如微信、抖音、淘宝等；兼容性测试，通常都需要在各种真机上执行相同或者类似的测试用例，所以往往采用自动化测试的手段。
同时，由于需要覆盖大量的真实设备，除了大公司会基于 Appium + Selenium Grid + OpenSTF 去搭建自己的移动设备私有云平台外，其他公司一般都会使用第三方的移动设备云测平台完成兼容性测试。第三方的移动设备云测平台，国外最知名的是 SauceLab，国内主流的是 Testin。
第三、流量测试
（1）App 执行业务操作引起的流量；
（2）App 在后台运行时的消耗流量；
（3）App 安装完成后首次启动耗费的流量；
（4）App 安装包本身的大小；
（5）App 内购买或者升级需要的流量。
流量测试，往往借助于 Android 和 iOS 自带的工具进行流量统计，也可以利用 tcpdump、Wireshark 和 Fiddler 等网络分析工具。
虽然，减少 App 消耗的流量不是测试工程师的工作，但了解一些常用的方法，也将有助于你的测试工作：
启用数据压缩，尤其是图片使用优化的数据格式，比如同样信息量的 JSON 文件就要比 XML 文件小；遇到既需要加密又需要压缩的场景，一定是先压缩再加密；减少单次 GUI 操作触发的后台调用数量；每次回传数据尽可能只包括必要的数据；启用客户端的缓存机制； 耗电量测试 App 运行但没有执行业务操作时的耗电量；App 运行且密集执行业务操作时的耗电量；App 后台运行的耗电量。 弱网络测试与传统桌面应用不同，移动应用的网络环境比较多样，而且经常出现需要在不同网络之间切换的场景，即使是在同一网络环境下，也会出现网络连接状态时好时坏的情况，比如时高时低的延迟、经常丢包、频繁断线，在乘坐地铁、穿越隧道，和地下车库的场景下经常会发生。所以移动应用的测试需要保证在复杂网络环境下的质量。具体的做法就是：在测试阶段，模拟这些网络环境，在 App 发布前尽可能多地发现并修复问题。
第六：边界测试
边界测试是指，移动 App 在一些临界状态下的行为功能的验证测试，基本思路是需要找出各种潜在的临界场景，并对每一类临界场景做验证和测试。
系统内存占用大于 90% 的场景；系统存储占用大于 95% 的场景；飞行模式来回切换的场景；App 不具有某些系统访问权限的场景，比如 App 由于隐私设置不能访问相册或者通讯录等；长时间使用 App，系统资源是否有异常，比如内存泄漏、过多的链接数等；出现 ANR 的场景；操作系统时间早于或者晚于标准时间的场景；时区切换的场景；1、目前主流的移动应用自动化测试框架Appium。是一种开源自动化的测试框架，支持ios和Android上web navite app和hybrid app的自动化测试
