APP自动化测试方法

App应用测试绪论
1.1App测试策略
随着互联网浪潮的到来，手机app应用早已渗透到了我们日常生活的方方面面，成为不可或缺的一部分，而且在可以预见的未来这种趋势会更加明显而强烈。

对于软件开发、测试工作来说，其工作重点也在在这股浪潮的潜移默化中发生了转向。

本章节将分别介绍App 测试中需要关注的内容和重点，以及移动产品测试的特点和测试方法方法。

概括地说，手机APP测试点有如下几个方面：
图1-1App测试主要内容
App测试的主要内容为：
开发支持，开发支持的工作内容有：单元测试、功能测试、用户故事测试、原型模拟。

产品检查和确认，包括探索性测试、可用性
测试、验收测试。

技术验证，包含：安全测试及技术类测试验证。

这几个领域互有重叠，我中有你你中有我，其关系如下图：
1.2产品检查和确认
1.2.1安装和卸载
普通的安装卸载的方法，主要有三种方式：（一）生成APK文件在真机上操作；（二）android手机端的通用安装工具；（三）通过命令行adb install/uninstall进行安装卸载。

关于异常安装和卸载方面的测试，需要关注：
相关系统和应用：冲突检测、静默卸载。

安装过程中是否可以中途取消（断电、断网等），是否支持断点续传。

异常卸载：卸载期间中死机，断电，重启等异常，环境恢复后是否可以正常卸载。

可以在手机直接卸载，也可以通过软件卸载安装，或通过PC桌面删除应用，卸载过程应该随心所欲不会给用户造成任何心里负担，检查“取消卸载”功能是否正常，取消后正常回滚，软件没有被卸载，可以继续正常使用。

检查卸载后是否所有的安装文件夹、文件被全部
删除，同时，删除前系统应该提示是否保留用户数据。

此外，App是否可以在iOS或android等操作系统安装，并且支持不同的版本，如果系统版本过低导致应用不能适配、安装空间不足时是否有相应提示、如果应用需要通过网络验证之类的安装，测试断网时，应该提前明确提示。

1.2.2加载和运行
关于App应用的加载和运行，重点验证：（一）App安装完成后，是否可以正常打开软件？（二）软件安装后是否可以正常运行，安装后的文件夹及文件是否可以写到指定的目录里？（三）App运行时，是否有加载图示？运行速度如何，切换是否流畅？界面跳转是否正确？（四）是否会出现闪退？如有，频率有多高？是否超过用户能容忍的阀值？（五）涉及到图片处理的时候，是否容易出现程序崩溃现象等。

1.2.3登录和登出
关于登入：
最基本的情况，当登录用户名和密码错误时，界面有提示信息、对于未登录时候的页面的操作，是否做了控制？提示信息是否明确并且不存在安全隐患。

比方说，当系统校验用户名、密码不通过时，应该提示诸如“用户名或密码输入错误”，而不是明确的指出是“用户名不存在”或者“密码错误”，这是很容易成为安全漏洞并通过穷举或社会工程等手段突破校验的。

密码修改和忘记密码是两大需要重点测试的模块，对于密码更改功能，修改后重新登录时是否做到了有效
数据的校验？对于忘记密码功能，系统提示的信息是否足以是用户回忆起密码或提供足够的支持、同时还不能被安全领域的社工手段所利用。

凡此种种，看似简单的功能点，其实极为考验设计者的功底，也对验证者的要求非常高。

用户主动退出登录后，下次启动App时，应该首先进入登录界面。

如果app有“记忆”功能，使重启的app直接越过了登录环节，也是相当危险的，尤其是对于银行、金融等涉及金钱或其它敏感数据的app来说，很容易给用户造成不可估量的损失。

如果App支持自动登录，则需要关注数据交换时，应用是否能自动成功登录且数据库数据操作正确、切换账号登录，检验登录的信息是否及时更新？用户登录状态太久（并太久不操作），sessionID会过期，导致会出现”虽然是登录状态过，但系统会提示用户没有登录“用户没有登录”。

多个客户端同时进行操作时，验证数据库操作是否准确无误，且每个客户端都可以及时看到数据的更新？App切换到后台时，再次切换到前台，业务流程是否能正常的承接下去。

有些应用，一个账号只允许登录一台终端，这时，需要检查当账号登录多个终端设备时，是否将原用户剔除，且能够给出明确的提示信息。

对于IOS与android 不同设备登录同一个账号时，对个人信息等数据进行操作后，确保数据库信息无误，没有混乱，且IOS与android设备看到的数据都是最新的。

对于普通应用来说，合理的密码安全策略设计非常重要，设计者必须在安全和易用之前权衡折中：过于复杂的密码策略会让用户望
而却步甚至还没注册转身就走，而过于简单的密码策略则会直接导致安全、可靠性问题的产生。

关于登出：
对于某些程序，登录后即便没有网络也可以浏览本地数据，当然，没网络的时候刷新获取新数据时虽然操作失败但能给出友好提示。

支持切换到后台再切换到前台时。

离线后再联网，如果服务器数据有更新，需获取新数据至客户端。

当要更新本地缓存信息时，如果某些界面的数据不提供离线查看功能，需要给出相应提示。

本地缓存信息时，如果某些界面的数据不提供离线查看功能，需要给出相应提示。

另外，还需要确认以下情况：
在无网情况下浏览本地缓存数据（理论上是可以的），退出再开启App时能正常打开机浏览，切换到后台再切回App应用时可以正常浏览。

确认锁屏后再解锁回到应用前台可以正常浏览，服务端的数据有更新时有离线的提示？
1.2.4数据显示和更新
显示和加载：数据的排序、对齐方式是否合理，有无遵照业界通用规则（比如，金额的字段通常为右对齐）；前台展示的数据，后台进行变动（增、删、改），是否是实时更新还是app一开始运行再进行加载。

前台主动发出请求后，后台数据库中是否生成相应的数据、数据关联生成正确。

点击“加载更多”，检查分页处理技术：是否有
重复的数据、数据显示是否完整、到达最后一页后是否还有显示数据，等。

数据更新和缓存：有数据更新后，哪些地方需要手动刷新，哪些地方需自动刷新；从后台切换回前台时，哪些页面需要进行数据更新。

根据需求和逻辑，区分从服务端请求实时响应数据和缓存到本地的数据。

1.2.5消息推送
消息推送默认开关应该是全打开状态，可以通过设置任意打开或关闭消息推送开关。

打开开关的状态下，应用启用中和应用关闭时都应该能正常收到消息推送。

验证（微博、微信）分享还是push信息推送、推送功能是否正常？最后，当设置开关关闭时，客户端接收不到消息推送。

后台未打开App应用时，手机消息栏可以接收到消息提醒，点击查看，弹出应用通知的具体内容，点击后通知从消息栏中消失。

App 客户端启动期间，也可以收到消息提醒，并可点击查看。

客户端运行时，消息不会进消息栏，而是在当前界面或当前界面的浮动窗口弹出提示。

1.2.6软件更新
Android软件是否可以正确更新到新版本，且安装运行无异常。

确保IOS软件更新会有限制，只有上了商店且有版本更新时才会更新。

当客户端有新版本时，及时更新提示。

如果用户主动取消更新，老版
本可以正常使用，但是下次启动应用时，仍能出现更新提示。

当有新版本时，不删除客户端的情况下，可以直接而简便的更新到最新版本（正常来讲不用强制删除本地客户端可以正常更新）。

1.2.7UI交互和体验
交互是人和产品之间沟通的桥梁，体验是人对使用产品的感受。

比如吃早餐的时候用勺子喝麦片牛奶，其中勺子是交互方法，是人和粥的沟通桥梁，而麦片牛奶好不好喝，口感怎么样，则是体验感受。

UI交互、用户体验测试不是本书讲解的重点，这里提几个重点的关注点：
设计：合理的设计，体现人文关怀精神。

UI应用的设计应该够美观，交互不生硬，流畅自如，畅通无阻。

操作：比如人性化导航，在运行App时，不管在哪个接点，导航是否直观，精准，页面切换是否正确。

特殊字符处理：输入特殊字符、超长字符、空字符，验证系统是否能正常处理，按预期弹出错误提示。

易用性：系统功能是否让用户容易接受，是否符合大众的操作习惯，满足易用性要求，降低学习成本和使用门槛。

图片测试：检查图片、按钮是否能在各种情况下自适应，不同的分辨率、机型、OS等背景下，界面元素是否能正常显示而不变形。

其它影响交互、体验的元素。

1.3技术验证
1.3.1兼容性
在做兼容性测试时，需要考虑的因素众多，大体有：手机品牌、机器种类、操作系统版本/种类、网络兼容性、第三方软件兼容性等。

移动网络兼容：不同运营商、接入点和网络——多地域多网络测试、流量测试。

手机操作系统兼容：IOS、Android、WP——系统版本兼容性、OTA测试；随着越狱的手机越来越多，越狱的操作系统也需要纳入兼容性测试的范围。

移动设备兼容：手机、PAD、机顶盒、穿戴式设备——设备适配测试、功耗电
量测试。

验证App应用在不同设备、不同系统上是否适配，针对android/IOS各个系统版本进行测试，及测试屏幕分辨率进行测试；验证位图在不同的分辨率下是否失真。