移动端测试做安卓移动终端测试需要注意什么？

移动测试和Web测试有什么区别

从本质上来说， 移动测试和Web测试都是一样的， 测试理论，测试方法都是一样的。

但是移动端，比如手机和平板电脑， 也有一些需要特殊测试的地方， 阅读目录 移动测试和Web测试的简单回答 相同点， 都是采用功能测试 一个在Web上测试， 一个在App测试 相同点: 同样的测试的基础知识 不管是传统的Web测试， 还是新兴的手机App测试， 都离不开测试的基础知识 1. 相同的设计测试用例方法： 边界值，等价类，错误推导法，场景法 2. 同样的测试方法， 验证业务功能是否符合预期 3. 都要检查UI： 界面的布局， 风格和按钮是否简洁美观， 是否统一 4. 页面的性能检测 5. 应用的稳定性： 测试应用的稳定性， 不会闪退卡死等。

后台都是一样的 移动测试和Web测试， 他们调用的是同样的后台， 同样的Restful API。

所以首先做好后台的RestfulAPI 测试。

移动测试强调用户体验 移动APP， 实质上就是一个缩小的Web程序， 屏幕小，操作不方便，所以强调用户体验。

移动APP的测试， 业务都相对简单 移动App, 一般都是面向个人用户的， 通常操作比较简单， 业务逻辑也比较简单。

所以测试起来会相对简单点。

移动端的特性 移动端有很多的特性，需要特殊测试 网络种类多 移动端有多种网络：无线网络、2G、3G、4G等，断网、网速较差及网络之间的切换时页面的显示等，这些对于移动端来说很重要。

此外，在非wifi下，还需要注意网络使用量问题。

弱网测试 模拟App在网速慢，网络不稳定的情况下。

中断测试 移动端有一个很重要的问题，一般情况下在使用软件的过程并不是长久的，这中间可能发生很多中断，如电话、短信、通知、断电等等，软件 需要特殊处理这些特殊情况。

打开一个页面，或在操作的过程中（点击一个按钮后），将手机屏幕锁住，再打开时，应用能否正常处理。

1. 来电中断： 呼叫中断， 被呼叫挂断，通话挂断，通话被挂断 2. 短信中断： 接受短信， 查看短信 3. 其他中断： 蓝牙，闹钟，插拔数据线， 手机锁定， 手机断电， 手机问题(系统死机， 重启) 屏幕的限制 图片及文字的显示；上传不同的图片尺寸显示是否正常；图片和文字一起显示时，效果如何。

操作区域；web端的应用，一般不会受 到屏幕的限制，而且通过鼠标操作更加准确。

但是移动端由于屏幕较小，页面及按钮会受到屏幕大小的限制，再加上用户都是通过手指进行操作，一些按钮、选择框 等是否容易点击，多个可点区域位置较近时，点击部位稍微偏移，也许就会造成不同的结果，这种情况下是否可以达到预先的效果。

安装卸载测试 用应用市场安装 用apk文件安装。

完全卸载（用户的profile文件） 部分卸载 升级测试 从上一个版本/上两个版本直接升级到最新版。

全新安装最新版 新版本覆盖旧版本安装 卸载旧版本， 安装新版本 卸载新版本， 安装新版本 增量更新 强制更新 测试点在于： 升级之后， 已经登录的用户，是否仍处于登录的姿态， 用户的缓冲文件， 配置文件是否还在。

软件启动运行 移动端启动、卸载、升级几个特性，这是比较常见、也很重要的，比如升级时用户的数据怎么办，卸载后用户的数据怎么处理，卸载再安装用户登录数据的显示等。

手势 移动端还有一大特性，就是移动端有自己比较简单的手势，用户可以通过手势进行一个操作，比如左滑删除、右滑返回上一个页面、左右滑动图片等，软件需要对这个手势进行适配。

多点触控， 事件触发区域 自动化工具不太一样 App 测试 用的是, Monkey, MonkeyRunner, Appnium, Web 主要用： Webdriver

怎么用monkey工具给移动端APP做测试？

一、简介 Monkey是Android中的一个命令行工具，可以运行在模拟器里或实际设备中。

它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试。

Monkey包括许多选项，它们大致分为四大类： 基本配置选项，如设置尝试的事件数量 运行约束选项，如设置只对单独的一个包进行测试 事件类型和频率 调试选项 在Monkey运行的时候，它生成事件，并把它们发给系统。

同时，Monkey还对测试中的系统进行监测，对下列三种情况进行特殊处理（自动停止）： 如果限定了Monkey运行在一个或几个特定的包上，那么它会监测试图转到其它包的操作，并对其进行阻止。

如果应用程序崩溃或接收到任何失控异常，Monkey将停止并报错。

如果应用程序产生了应用程序不响应(application not responding)的错误，Monkey将会停止并报错。

按照选定的不同级别的反馈信息，在Monkey中还可以看到其执行过程报告和生成的事件 二、测试准备 Monkey test前必须先进入android设备的adb shell（Android SDK环境配置不在此描述，网上有很多）步骤如下： 1. 开始—>运行—>cmd 2. usb连接手机，输入 adb shell 命令，待出现 即可输入以下内容 3. 进入手机后，输入相应的monkey命令即可测试 三、基本命令格式 adb shell monkey –p 程序包 –v 测试次数 比如“adb shell monkey –.htc.Weather –v 20000”意思是.htc.Weather 这个程序包单独进行一次20000次的monkey测试 其中程序包名称可以在串口终端这句命令获得：ls data/data 显示所有程序包 四、测试Log获取 用Monkey test测试，为了方便分析问题，可以在命令monkey命令后面加上 “|logcat -v time”，这样就能边测试边打印Log（记得用终端保存Log文本）例如： adb shell monkey –.htc.Weather –v 20000|logcat -v time 但是这个组合在monkey测试完成后，logcat仍然在执行，测试时需要注意。

如果测试monkey碰到crash或者anr（程序强制性退出或不响应）现象时，在抓取log的同时需要提供traces.txt，步骤如下： 1. 测试版本需要具备root权限 2. 进入data/anr目录下面 3. 将traces.txt文件拷贝到TF卡中，然后拷贝出来发给软件分析即可

web和移动端测试的区别

一个是pc端测试 一个是移动端测试 其实移动web是app和传统的web并没有本质的区别。

但是，同一个页面不可能被桌面浏览器和移动浏览器同时浏览. 可以为移动web提供一个系统自适应结构，这个结构可以为浏览器提供特定的输出. 而且可以将呈现逻辑细分为较小的部分，这样在显示区域和输入设备硬件都有限的情况下更好的工作。

做安卓移动终端测试需要注意什么？

1.明确需求 整个项目的完成，测试越早介入越好，产品需求评审是一定要参加的，在大家讨论的同 时，自己也可以发表遇到的问题，如果可以给产品提一些好的建议是最好不过了。

需求评审前尽可能多的发现问题，有设计不合理或者流程不通的地方大胆的向产品提，尽量的减少后期需求的变更。

后期产品的变更不仅会影响到开发，对已经设计好的用例等都会有影响，如果变更大的话甚至会影响整个项目的进度。

2.编写测试用例，通过评审 在完他了解需求的基础上，根据产品需求编写测试用例，除了覆盖所有的功能外，最主要的要有质疑精神，各种异常的操作、非法操作、用户体验（界面是否友好、物理键操作）等也需要详细设计到用例中。

我之前的一个项目就存在一个这样的问题，我们的产品下有一个更多功能，是我们公司的其它产品，更多列表下可以下载，而当时设计用例的时候下载这个用例考虑的不全，后期开发将所有产品都调用这个更多，代码重用。

就这个问题我大概总结了下： 注：默认下载需借助浏览器（与开发沟通结果），无浏览器直接下载，任务项提示进度 1）联网正常+空间充足+浏览器正常情况 2）断网情况下+空间+浏览器正常充足 3）软件装在手机上+浏览器正常+空间充足 4）软件装在手机上+浏览器正常+空间不足 5）软件装在T卡+浏览器正常+空间充足 6）软件装在T卡+浏览器正常+空间不足 7）卸载浏览器，默认可以下载，任务栏显示下载进度（此处会存在异常中断，属bug） 8）浏览器正常，弹出选择存储位置，选择空间充足 9）浏览器正常，不弹出选择存储位置，默认空间不充足 10）浏览器正常，弹出选择存储位置，选择空间不充足 以上用例在空间不足应给出提示，而经常会出现异常中断，需开发作处理，我之前多次出现这种情况，有的手机也会由于兼容性导致异常中断，做为测试可以提更好的建议给开发： 像360，91等手机助手，在自己的平台上下载、安装、暂停，我们可以任意控制，此问题解决了所有兼容性，又简代了下载考虑的测试情况，不需要借助浏览器等，从根本上解决了下载的问题。

另在评审前，先将用例发给相关产品、开发，他们看过后会提前了解，评审的时候会提出，产品和开发只观注需求和流程的问题，建议在评审时，可以邀请同为测试的同事一起参加，站在测试的角度可以更多的提出测试要考虑的问题，使我们的测试用例更完善。

评审时，有的用例需要更改或者删除，为了节省时间先标出来，待评审完成后，完善后发给大家，有意见再完善。

3.测试执行用例 产品提测后，开始测试，根据之前的测试用例将所有功能过一遍，保证所有功能正常。

当然用例也只是起到一起指导作用，除了执行用例外，还需要反复测试，站在用户的角度多次操作，要有足够的耐心去完成它。

所提的bug要描述清楚，必要时附上截图（可使用360，91手机助手截图）等，及时跟开发沟通，开发要求复现bug及时配合，复现给开发看。

待开发有新版本出来后，及时跟踪bug，修复 完成后，再验下与之相关的功能，保证修复后的bug未影响到其它功能。

在开发拒改bug时，一定要让开发备注不改的原因，因为有的bug开发是比较专业，他们的意见有足够的说明性。