移动端测试

一.手机端常规测试

1.1 介绍

手机端测试,一般分为两大类:Android和ios

Android和ios两者之间有区别:

1. 两者运行机制不同：IOS采用的是沙盒运行机制，安卓采用的是虚拟机运行机制。
2. 两者后台制度不同：IOS中任何第三方程序都不能在后台运行；
                    安卓中任何程序都能在后台运行，直到没有内存才会关闭。
3. IOS中用于UI指令权限最高，安卓中数据处理指令权限最高。

4. Android开源导致碎片化比较严重,(手机型号,版本,分辨率,应用兼容)bug比较多，
   IOS通常bug会少一些。

1.2 软件测试考虑因素

1.2.1 功能测试

    我就先来说一下功能测试吧,对于手机app来说,和我们测试web项目差不太多,也是各种测试方式需
要考虑进来,比如说逻辑功能测试，现在移动端越来越火爆,大家用的软件也越来越多,对软件也越来越
挑剔,现在公司在开发移动端的时候,肯定是有相应的需求文档,我们做逻辑功能测试,就是根据这些资料,
当然也根据我们正常人的逻辑思维进行逻辑功能测试,就拿我上个项目来说,它就是一个移动端项目,在做
逻辑功能测试的时候,我们要测试主页面,我的页面,商城页面这些功能是否合理。

1.2.2 安装与卸载测试

   软件安装后是否可以正常运行，安装过程中是否可以取消,安装空间不足时，是否有相应提示,是否可以卸
载应用（可通过桌面卸载，也可以通过软件卸载。曾发现在IOS手机上有个应用安装时未完全安装，终止安装
后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）,卸载是否支持取消功能，单击取消后软件
卸载功能是否正常,卸载后文件是否全部删除所有的安装文件夹,从不同的应用市场下载进行安装测试，比如测
试小米市场，华为市场，应用宝，安卓市场，安智市场的安装测试。

1.2.3 软件升级更新测试

    当客户端有新版本时，是否有更新提示，当版本为非强制升级版时，用户可以取消更新，老版本能正常使
用，用户在下次启动app时，仍能出现更新提示；当版本为强制升级版时，当给出强制更新后用户没有做更新
时，退出客户端，下次启动app时，仍出现强制升级提示，当然现在强更已经很少出现了。检查更新后各个功
能是否能正常使用；在线跨版本升级后能否正常使用，当然现在主流的安装更新方式开始向热更新热部署方式
转变，就是在用户不需要手动更新的情况下，完成版本的静默更新，这个技术是有难度的，需要看公司中程序
员的技术能力还有就是是否有这样的产品需求

1.2.4 登录测试

    对于登录测试，基本上每一款app都有登录注册功能，所以在测试App的时候，登录测试是必不可少的一
项。
    我们做登录测试的时候，往往包含这么些项，登录用户名和密码错误时，界面有提示信息,用户主动退出
登陆后，下次进入app时，应该进入登陆界面,密码更改后，登录时是否做到了有效数据的校验，对于未登录状
态时，一些页面的操作，是否做了控制,切换账号登录，检验登录的信息是否做到及时更新，对于多个端
（web、iso、android等）进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新,一个账号
只允许一台机器登陆的软件，需要账号登录多个手机时，是否将原用户踢下线，且能够给出提示信息,用户登录
状态太久，session会过期，会出现“虽然是登录状态，系统会提示用户没有登陆”

1.2.5 安全性测试---权限测试

    对于手机权限，如果我们是刚开发不知名的app，权限这块尽量少一些，这些权限在安装的时候都必须用
户同意。在Android 6.0之后，权限需要动态的申请，我们测试的时候,需要测试在使用到这些权限的时候，
程序员是否做逻辑判断，用户同意权限应该怎么操作，不同意权限又应该怎么操作。

1.2.6 消息推送测试

消息推送，是移动端的一大特色。我就说一下消息推送我们所做的这些方面吧，
未锁屏时，应用后台运行，消息推送是否可正常接收，未锁屏时，APP客户端使用过程中，可以收到消息提
醒，且点击可查看。
锁屏时，手机消息栏是否可以接收到消息提醒。且点击可查看。点击后消息栏中消失。
精准推送
当推送消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误的将其他人的消息推
送过来
push推送消息是是否能有针对性的推送，如相应内容推送给相应用户（精准推送）
退出登录后，是否接受push推送（根据需求来）

1.2.7 前后台切换测试

APP切换到后台，再回到APP，检查是否停留在上一次操作界面；检查功能及应用状态是否正常；程序是
否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常
当APP使用过程中有电话进来中断后再切换到APP，功能状态是否正常
当关闭APP进程后，在开启APP，APP能否正常启动
对于有数据交换的页面，尤其是有视频图片之类的页面，每个页面都必须要进行前后台切换、锁屏的测试，这
种页面最容易出现崩溃

1.2.8 UI测试(界面测试)

确保产品UI符合产品经理制定的原型图与效果图
一般涉及界面（如菜单、对话框、窗口和其他可视控件）布局、风格、文字是否正确，页面是否美观，操
作是否友好。
如：安装app后的加载页显示，分享页面的产品logo显示

1.2.9 兼容性测试

我再说一下兼容性测试吧，兼容性测试主要考虑手机的版本，型号，分辨率，就像我说的，现在手机碎片
化比较严重，各个版本，比如Android，从Android4.0到Android10.0的版本它是不一样的，然后现在各
大手机厂商像华为，三星，小米，锤子，魅族，vivo这些厂商都修改android源代码，也是给我们增加和好多
工作量，好多时候开发的软件在三星上没问题，但是华为，小米就不行。还有手机分辨率，现在主流的可能是
1920*1080，但是还有好多其他分辨率，比如720*1280，还有一些更大分辨率的手机，都要考虑这些分辨率
的兼容，不然用户视觉体验就不好。
兼容测试，公司中会买好多测试机来太让我们进行测试，一般是不同厂商的手机，当然还有第三方云测平
台，比如testin还有腾讯wetest，就可以做兼容性测试。可以一次性测试100台测试机，同时会有相应的兼
容报告，bug报告。
对于IOS，ISO版本有7.1.2、8.3、9.1等；能否适配各种屏幕尺寸。

1.2.10 网络环境测试

测试2G、3G、4G、wifi、有网、无/网、弱网情况下应用的运行
网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒
有网到无网再到有网环境时，数据是否可以自动恢复，正常加载
无网络时，各种提示信息是否友好，数据本地化是否正确（比如提示当前已断开网络，请检查网络设置；还有
从wifi环境切换到4G环境提示是否启用4G网络，会产生扣费。

1.2.11 性能测试

    对于性能测试，（eclipse和Android studio中本身有检测cpu和内存的工具，也有检测手机内存泄
漏的工具）靠工具来测试手机cpu占用，内存占用，电池温度等，以及测试我们的app在后台持续运行的流量消
耗和电量消耗问题。

1.2.12 mokey稳定性测试

    对于手机测试，除了我们一些常规的功能测试，我们还会做稳定性测试，比如对于Android手机，我会使
用adb指令进行一些相应的操作，比如通过adb查看设置，进入设备，抓取log，我们测试的时候，会使用adb
logcat所抓出来的log日志存到电脑，发给开发，方便他们快速解决bug。
另外，我还会使用monkey对app进行测试，可以使用monkey对app做稳定性测试，主要就是测试操作app的时
候，程序是否会崩溃。
    我们使用adb shell monkey 指定对应的app，执行要测试的次数，指定要触摸的比率，超时时间和忽
略崩溃信息，就可以执行测试，将测试log存到某个位置，然后把测试出的bug 日志发送给开发。300000
    我就简单的说一下测试的指令吧，比如我上边所说的逻辑，我们用 adb shell mokey -p 指定要测试
的包名 --ignore-crashs 忽略崩溃 --ignore-timeout 忽略超时 --throttle 38指定延迟时间毫秒
-s 指定测试种子 指定测试次数，然后将文件 >输出到磁盘中。

二.Android介绍

2.1 android介绍

    Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和
平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使
用“安卓”.

2.2 android版本

    Android在正式发行之前，最开始拥有两个内部测试版本，并且以著名的机器人名称来对其进行命名，
它们分别是：阿童木（AndroidBeta），发条机器人（Android 1.0）。后来由于涉及到版权问题，谷歌
将其命名规则变更为用甜点作为它们系统版本的代号的命名方法。甜点命名法开始于Android 1.5发布的
时候。作为每个版本代表的甜点的尺寸越变越大，然后按照26个字母数序

2.3 android架构

Android的系统架构和其操作系统一样，采用了分层的架构。
从架构图看，Android分为四个层，从高层到低层分别是:
    应用程序层、
    应用程序框架层、
    系统运行库层
    Linux内核层

 2.4 android

Android四大组件分别为activity、service、content provider、broadcast receiver

参考: Android之四大组件,六大布局,五大存储

1. activity(窗口)

(1) 一个Activity通常就是一个单独的屏幕（窗口）。

(2) Activity之间通过Intent进行通信。

(3) android应用中每一个Activity都必须要在AndroidManifest.xml配置文件中声明，否则系统
    将不识别也不执行该Activity。

(2) service(服务操作)

(1) service用于在后台完成用户指定的操作。service分为两种：
    started（启动）：当应用程序组件（如activity）调用startService()方法启动服务时，服务处于started状态。
    bound（绑定）：当应用程序组件调用bindService()方法绑定到服务时，服务处于bound状态。

(2) startService()与bindService()区别：
    started service（启动服务）是由其他组件调用startService()方法启动的，这导致服务的onStartCommand()方法被调用。当服务是started状态时，其生命周期与启动它的组件无关，并且可以在后台无限期运行，即使启动服务的组件已经被销毁。因此，服务需要在完成任务后调用stopSelf()方法停止，或者由其他组件调用stopService()方法停止。
    使用bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止，大有“不求同时生，必须同时死”的特点。

(3) 开发人员需要在应用程序配置文件中声明全部的service，使用<service></service>标签。

(4) Service通常位于后台运行，它一般不需要与用户交互，因此Service组件没有图形用户界面。Service组件需要继承Service基类。Service组件通常用于为其他组件提供后台服务或监控其他组件的运行状态。

(3) content provider(数据共享)

(1) android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。其他
应用可以通过ContentResolver类从该内容提供者中获取或存入数据。

(2) 只有需要在多个应用程序间共享数据是才需要内容提供者。例如，通讯录数据被多个应用程序使用，
且必须存储在一个内容提供者中。它的好处是统一数据访问方式。

(3) ContentProvider实现数据共享。ContentProvider用于保存和获取数据，并使其对所有应用程序
可见。这是不同应用程序间共享数据的唯一方式，因为android没有提供所有应用共同访问的公共存储区。

(4) 开发人员不会直接使用ContentProvider类的对象，大多数是通过ContentResolver对象实现对
ContentProvider的操作。

(5) ContentProvider使用URI来唯一标识其数据集，这里的URI以content://作为前缀，表示该数据由
ContentProvider来管理。

(4) broadcast receiver(广播)

(1) 你的应用可以使用它对外部事件进行过滤，只对感兴趣的外部事件(如当电话呼入时，或者数据网络
可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice来
响应它们收到的信息，或者用NotificationManager来通知用户。通知可以用很多种方式来吸引用户的注
意力，例如闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并
获取消息。

(2) 广播接收者的注册有两种方法，分别是程序动态注册和AndroidManifest文件中进行静态注册。

(3) 动态注册广播接收器特点是当用来注册的Activity关掉后，广播也就失效了。静态注册无需担忧广
播接收器是否被关闭，只要设备是开启状态，广播接收器也是打开着的。也就是说哪怕app本身未启动，
该app订阅的广播在触发时也会对它起作用