大话移动APP测试

大话移动APP测试

移动APP测试的学习参考了《大话移动APP测试》这本书籍，该篇文章作为自己的学习记录

目录

大话移动APP测试

第1章&&第2章

第3章 用户体验测试

3.1 移动互联网与传统互联网体验上的区别

3.2 Android vs iOS

3.3“愚笨”的用户-用户引导

3.4“捣乱”的用户-应用容错

3.5 专业精神-风格一致性

3.6“我”即最终用户：过程体验测试

3.7使用更多的应用：对比体验测试

3.8模拟场景体验测试

3.9用户究竟关心的是什么？

3.10用户体验是bug吗?

3.11如何提升自身的用户体验经验？

第4章 功能测试要点

4.1多分辨率测试

4.2多系统测试

4.3用户不同的使用习惯

4.4网络的不稳定性

4.5安装/卸载测试

4.6升级测试

4.7并发测试

4.8数据来源

4.9 推送

4.10分享跳转

第5章 常用工具介绍和实践

5.1Monkey

5.2Emulator

5.3 MonkeyRunner

5.4Hierarchy Viewer

5.5DDMS

5.6Compatibility Test Suite

5.7Tcpdump/WireShark

5.8 FindBugs

5.9 Lint

5.10 反编译、重编译

5.11 Ant

5.12 Charles

5.13 Instruments

第6章 常用框架介绍和实践

6.1Instrumentation

6.2Emma Code Coverage

6.3robolectric

第7章 移动应用测试案例实践分析

7.1深入了解被测试对象

7.2多种数据来源

7.3在生活中使用产品

7.4社交应用分层设计实践案例

7.5联系人搜索案例测试设计实践

第8章 性能测试介绍和实践

8.1Emmagee

8.2Instrumentation

8.3HPROF

8.4Gfxinfo

8.5Systrace

8.6TraceView

8.7Instruments——Leaks

8.8Android多分辨率自动化实践

---

 

 

第1章&&第2章

1.测试用例编写：老题目，新认识。

常见的回答需要常规知识的积累，随着时代变化会有新需求新认知，怎么做一个有心人，注意知识的积累，同时也要不断学习新知识，是写好测试用例，做好测试工作的要点。一名测试人员如果要想有长期和系统的提升，就必须不能被自己所在的企业、团队、项目等外在因素所制约、要学会自己定目标，不停的学习才是真正的解决之道。真的是见识限制了自己的眼界。

2.Android开源文档=Android测试

3.在移动互联网时代可能会发生仅仅完成创意功能就发布产品，其他功能可以全部不做，尽量赶在另外一个应用发布前发布，用户不会关心创意是谁的，先入为主很重要，在他们看来其余的都是抄袭第一个应用的。

4.需求来源：产品经理、客户和用户

5.敏捷开发：开发人员为新功能疲于奔命，测试人员既要测试新功能，又要做老功能的回归测试，这样一来必然漏洞百出。所以需要测试策略和高效的测试方法来支撑。

6.应用更新迭代快，全面测试应用的“兼容性”，这样就大大增加了测试工程师的碎片化测试。而此时测试工程师面对的基本上是一个无解的问题--Android智能机的适配测试该怎么做？在这个问题面前，任何的测试技术都变得苍白无力

 

6.1Android模拟器

6.2Testin和mtc兼容性平台

 

7.自行学习能力：开源文档或WIKI找到很详细的描述

8.测试工程师：保证发布的产品没有缺陷

测试工程师对外是一个从零趋向负区间的概念

测试人员把“测试”当成是自己的产品，而我们要做的第一步就是学会自我尊重，对自己和测试本身都要充满信心，然后我们才能去感染身边的人，让更多的人了解测试，正确的看待测试，喜欢测试这份职业

 

第3章 用户体验测试

用户体验在移动互联网中是很重要的测试点，但同时也是不为广大测试工程师所重视，甚至认为不在测试人员职责之内的一项工作。其实，在移动互联网的激烈竞争中，产品的用户体验甚至比功能更重要，换句话说，功能的完善最终都是为了更好的用户体验。实际上，整个项目团队中的每个成员都应该对产品做用户体验测试。不同职位的人关注点不同，测试的切入点就不同。那么对于软件测试工程师来说，用户体验测试到底是什么呢？需要测试那些点？

 

3.1 移动互联网与传统互联网体验上的区别

界面、场景、交互等并不只是产品经理、交互设计师等考虑的问题，作为产品质量的保证的测试人员，仍然需要时刻关注产品用户体验

 

3.2 Android vs iOS

 

区别不仅是在界面设计上，更多体现在两家公司 的理念以及硬件上。

 

3.3“愚笨”的用户-用户引导

用户引导测试是互联网测试的重点之一

 

3.4“捣乱”的用户-应用容错

应用容错的用户体验测试很重要

3.5 专业精神-风格一致性

3.6“我”即最终用户：过程体验测试

1. 作为一个测试人员，应该像真正的用户一样去使用应用
2. 每款应用都有自己的核心功能，而移动应用的核心功能越简单越好
3. 测试工程师要比项目中的任何一个人都要多的使用应用，体验应用，要从不同的角度去体验应用的使用过程，找出可能会让用户感到困惑、厌烦的地方

 

3.7使用更多的应用：对比体验测试

1. 在我们测试一款应用时，最好用的一种测试方法是，在同样的测试环境下，去使用同类型的其他应用，这样很容易就能看出自己测试的应用设计上的缺陷。使用更多的应用有助于我们提升用户体验
2. 国外应用也应多关注

 

3.8模拟场景体验测试

1. 场景测试就是测试工程师需要模拟用户使用应用时候遇见的真实场景、尽可能发现应用中的问题，从而保证应用的可用性
2. 进行场景模拟测试之前，首先要弄清楚应用的受众群体处于哪个年龄段、性别、工作等信息
3. 好的应用要有明确的用户群和市场定位
4. 场景测试用例必不可缺

3.9用户究竟关心的是什么？

3.10用户体验是bug吗?

1.用户体验肯定是bug

移动互联网用户首当其冲的就是用户体验，不过用户体验的问题和一般的缺陷问题是要区分开的，我们可以通过bug的类型、重要等级、优先级等附加字段来进行区分，任何细小的问题都应该记录在缺陷管理系统中。

2.测试不是某一刻或某项目周期为单位的活动，而是一种长期、迭代的过程。在多个迭代周期之后，我们能够更好的分析风险高的功能模块，制定更好的测试策略，有针对性的改进测试流程等等。测试工程师要在系统中记录这些重要但是优先级相对不高的问题，主动在报告以及项目中去告知团队的其他成员，并确保最终能够被修复。

 

3.11如何提升自身的用户体验经验？

用户体验是一个没有定论、无法量化的概念，但却是移动互联网用户最在乎的点

1. 使用大量应用
2. 让现实中的用户来使用
3. 在应用中添加数据统计功能
4. 适当阅读一些设计方面的书籍，同时多和交互设计师沟通

 

 

第4章 功能测试要点

移动互联网和传统互联网区别在于移动端业务和系统的特殊性，设计出好的用例必须对应用以及应用的系统要有足够的认识才行，本章列举一些相关要点，但绝不仅于此。

4.1多分辨率测试

4.2多系统测试

4.3用户不同的使用习惯

4.4网络的不稳定性

1. 移动互联网时代，相比传统互联网，人们的行为习惯并没有改变，只是行为模式发生改变
2. 移动互联网时代，移动应用连接的3G/4G/wifi，没有传统互联网时代的实体连接网线稳定，针对出现的网络错误，测试工程师应对各种网络错误情况进行细化并测试。网络错误情况复杂，与其设计复杂的方法进行模拟，更倾向于实际场所测试测试。
3. 当被测应用有长连接支持时，除了容错和网络切换测试之外，还需要在不同网络环境下，根据服务器设置的心跳时间来进行边界值的一些测试。

 

4.5安装/卸载测试

4.6升级测试

4.7并发测试

多个应用同时启动或多个事件同时触发的情况。

4.8数据来源

在移动互联网应用的测试过程中，如碰到与文件相关的测试，要想使测试用例覆盖的尽量全面，那就必须在日常生活中使用自己的产品，要经常和使用产品的用户进行沟通，把自己放在用户的角度去思考才有可能

 

4.9 推送

测试推送的时候需要注意一下几点：

1. 关机、待机、打开、等状态下推送的功能、消息提示、以及推送跳转等是否正确
2. 应用在打开、未打开状态、应用启动且在后台运行等情况下、查看推送的功能、消息提示以及推送跳转是否正确
3. Android系统和iOS系统虽然都有推送这种功能，但是使用机制完全不同，需要对两者同时关注多次推送以及推送的成功率
4. 推送本身分成主动推送和被动触发推送（某些业务场景触发的回调推送）。
5. 推送的消息在阅读前后，其标示消息数量的数字是否改变
6. 单条或多条推送的文字显示以及跳转界面是否正确
7. 多语言系统环境下，推送的本地化翻译信息是否显示正确

.......

4.10分享跳转

 

第5章 常用工具介绍和实践

5.1Monkey

Monkey是Android SDK提供的一个命令行工具，可以简单、方便的运行在任何版本的Android模拟器和实体设备上，会发送伪随机的用户事件流，适合对应用做压力测试

5.2Emulator

5.3 MonkeyRunner

MonkeyRunner更适合做系统级别的回归测试、压力测试，跟多更多的功能需自己扩展API来满足测试需求

用于应用界面的对比的回归测试和一些压力测试，基本流程图如下：

 

 

5.4Hierarchy Viewer

5.5DDMS

 

5.6Compatibility Test Suite

5.7Tcpdump/WireShark

使用模拟器作例子，因为该工具需要测试机root之后才有权限使用。流程如下

1.将Tcpdump放入到Android系统目录中

adb push /data/local/tcpdump

2.分配权限给存有Tcpdump文件的目录

adb shell chmod 6755 /data/lacal/tcpdump

3.使用adb shell进入类似于Linux的终端模式

/data/local/tcpdump -p -vv -s 0 -w /data/local/capture.pcap

成功抓包后反馈：

tcpdump: listening on eth0,link-type EN10MB(Ethernet),capture size 65535 bytes

Got 32

Got的数据即是抓包数据，会随时间延长而不停增长。

 

adb shell /data/local/capture.pcap .

通过DDMS将文件从Android系统中导出（命令中最后的点代表将文件导出到当前目录，也可直接指定路径）

 

4.拿到.pcap文件之后，需要使用WireShark程序打开可以看到非常详细的信息

 

5.8 FindBugs

1、FindBugs是一款Java静态代码分析工具

2、findbugs本身可以作为Eclipse的插件进行下载

 

5.9 Lint

1、Lint和Findbugs一样都是静态代码扫描工具，区别在于它是Android SDK提供的，会检查Android项目源文件的正确性、安全性、性能、可能性等潜在的bug并优化改进。

图 Lint工具原理

2、在Eclipse中右键工程，在出现的菜单中选择Android Tools中的Run Lint 即可执行Lint测试

3、Lint也可通过命令的方式对工程进行测试，并同时生成测试报告

在终端输入： lint apidemos --html apitest.html

 

5.10 反编译、重编译

下载Apktools工具

1、反编译

打开终端指向apktools根目录，输入以下命令即可完成反编译

Java  -jar apktool.jar d xxx.apk

2、重编译

在终端输入

java  -jar apktools.jar b <反编译出来的文件夹>

3、Android应用的签名

Eclipse设置中点击Android标签中的Build选项

4、re-sign.jar能将之前重编译的应用变成带有签名证书的应用

5、dex2jar查看反编译过程中的源代码

运行命令给予相应权限： chmod +x dex2jar.sh

使用该文件进行反编译：./dex2jar.sh xxx.apk

成功之后会出现_dex2jar.jar文件

6、使用JD-GUI打开_dex2jar.jar文件就能直接看见应用程序代码

 

5.11 Ant

1、Ant是Apache的项目，是一个基于Java的build工具，可以提升Android项目的工作效率，比如自动编译、自动打多渠道包等

2、以Android自带的Spinner项目为例，命令：

Android update project -n Spinner -t 1 -p /Users/apple/Desktop/workspace/Spinner

参数具体描述：

-n 项目名称

-t 所选项目target ID （可通过android list target来查看不同Android版本对应的target ID）

-p 选择build.xml生成的路径

 

5.12 Charles

1、Charles可以对IOS设备进行远程http和https抓包的应用

2、打开IOS设备的WiFi设置，点击【手动】标签，填入安装Charles的Mac机器的IP地址和端口号

3、设置完后，Charles弹框选择允许之后，会出现非常详细的结构以及每次请求的详情

4、Charles可支持网络模拟

 

5.13 Instruments

1、如果要正式进行IOS应用开发，Mac是必需品

2、mac xcode 自带的测试工具Instruments中的Automation功能介绍，Automation支持用JavaScript编写脚本来进行IOS设备的界面自动化测试。

 

第6章 常用框架介绍和实践

6.1Instrumentation

6.2Emma Code Coverage

1、Emma可以很方便的统计Android Junit test的测试代码覆盖率，稍作修改就能实现以黑盒手动测试的方法统计代码覆盖率

2、Instrumentation+Ant 例子

（1）emulator命令新建模拟器

（2）emulator命令启动模拟器

（3）选择被测工程Snake和创建测试工程Snake_test

（4）Snake_test中创建一个JUnit Test测试类snakeTest

（5）创建被测程序的build.xml文件

（6）执行命令:

cd 


android update project --path

执行成功后在被测应用工程路径下会生成一个build.xml文件

（7）执行命令：

   android update test-project -m -p

     执行成功后测试工程路径下生成一个build.xml文件

（8）安装应用apk到android模拟器

（9）使用ant emma dubug test 运行写好的android junit test 代码最终会生成覆盖率的html文件

（10）被测工程源代码的每个类都可以点击查看代码具体的覆盖率，覆盖率代码中红色标示代码标示测试用例执行中没有被运行到，黄色标示的代码标示在测试用例执行中部分被运行到，绿色标示的代码标示在测试用例执行中完全被运行到

 

3、注意事项：

（1）若在Android的Junit test类中有多个接口或单元测试的话，最终代码覆盖率会根据具体的自动化用例计算。在测试方法中添加类似thread.sleep()实现黑盒功能测试来计算代码覆盖率。在sleep过程中操作被测应用在用例执行完毕后同样能够生成手动用例所对应的代码覆盖率，但是要注意的是如果被测应用在Junit执行过程中崩溃的话，默认方式是不生成报告。

（2）Ant编译过程中出现@override error错误，需关注jdk版本及环境变量路径是否设置正确，若出现not found symbols，是因为遗漏了被测程序所依赖的lib，将lib包放入工程的lib即可如果没有emma.jar的话，可以选择升级SDK

 

6.3robolectric

1、从框架定义来看，robolectric其实是一个单元测试框架，但它的代码编写却与功能业务测试绑定

2、举例：

（1）新建一个被测工程MyProject，新建类MainActivity，并添加代码，配置Activity_main.xml，在MyProject中新建文件夹test

（2）创建Java测试工程MyProjectTest，连接MyProject中的test文件夹，添加Junit4的依赖包，添加robolectric的主要依赖包，添加与被测工程Android版本对应的Android的依赖包Android.jar

（3）测试工程MyProjectTest  run configuration：test runner为Junit4，选择Eclipse Junit Launcher，arguments标签中：Working directory中选择other （被测工程：MyProject）

（4）在测试工程MyProjectTest的文件下test下新建一个类，并添加相应代码

特点：添加的代码根本就是第2个robotium，只不过是编写规则上不同而已

3、robolectric的精妙之处：看似业务测试的代码确可以像单元测试一样执行和验证

4、Robolectric运行的是Junit Test并非Android Junit Test，所以不需要去运行模拟器或依赖真机

 

第7章 移动应用测试案例实践分析

传统测试用例在设计时一般只需要抓住需求和覆盖分支就行了，而移动应用测试用例的设计除了以上两点，更应注重用户场景和测试环境

 

7.1深入了解被测试对象

面对不熟悉的测试对象首先要问自己了解多少，注意了解和验证需求，眼见为实

7.2多种数据来源

1、看似平常的数据在测试时要特别注意，由于数据有不同的来源，可能会出现我们意想不到的测试用例。

2、移动互联网中和图片相关模块测试用例设计

首先想到：

（1）移动设备拍照

（2）移动设备载入相册中的图片

深思之后：

（3）分辨率、格式、大小不同的图片

结合用户习惯：

（4）喜欢自拍、考虑前置摄像头

（5）喜欢拼图

（6）喜欢使用美化后的图片

（7）随着iPhone普及，全景图片会越来越多

（8）智能机普及，用户喜欢将电脑图片导入手机

（9）从其他应用将图片保存到本地

经调查：

（10）智能机图片会来源于应用临时文件

（11）Google、FaceBook等邮箱、应用的绑定，会在用户登录智能机的同时，将用户账户下的图片同步到本地

（12）某些网页会将临时文件保存到本地

综上，测试工程师要用上面的思维去设计测试用例，否则会遗漏很多测试点

 

7.3在生活中使用产品

智能机“黑名单”功能测试举例

首先想到：

（1）添加一个或多个联系人号码进入黑名单，阻止通话

（2）黑名单中删除一个或多个联系人

新的用例：

（3）黑名单未添加任何号码时，界面显示是否正常

（4）黑名单添加一个号码后，界面显示是否正常

（5）当黑名单正好满一个屏幕后，界面显示是否正常

（6）当黑名单超过一个屏幕后，界面显示是否正常

生活场景中抽取用例设计思路：

（7）被陌生号码一直骚扰

（8）有意识不想联系某号码

（9）恶作剧

（10）女神号码？

.................

日常流程场景：

（11）直接添加一个号码到黑名单

（12）联系人中选一个联系人添加到黑名单

（13）通话记录中选择一个号码添加到黑名单

另外几个不确定因素：

（14）联系人存储方式（gmail等账号同步、直接创建、从短信添加、从通话记录添加、甚至微信等应用摇一摇添加）

（15）号码长度（固话、移动电话、短号码、小灵通）

（16）号码的不同表现形式（例如18621519900和+8618621519900是同一个号码，包括漫游甚至跨国号码等）

（17）双卡双待

利用我们的态度、策略、知识、技能以求接近完美，在实际生活中去用这些应用会让我们拓展思维，更贴近用户，更接近完美。

 

7.4社交应用分层设计实践案例

1、举例

应用类型：社交应用

所在系统：Android、IOS、windowsphone等

应用核心功能：发布自己喜欢的图片、评论、互粉等

应用所属结构：C/S

应用账户：可使用自己账号登录，也可使用新浪微博等第三方账号登录

初步了解之后列出核心测试点：

（1）不同账号的登录

（2）发布一张或多张照片

（3）测试照片的不同来源

（4）测试照片或智能机的经纬度

（5）测试不同网络下的交互

（6）测试交友功能

（7）测试评论、喜欢、互粉等功能

（8）测试照片预览、放大、旋转等功能

（9）测试发布照片时候，@好友、增加描述、增加定位、增加滤镜等功能

（10）多智能机同时登录

....................

引入自动化测试是为了提升测试效率，帮助做回归测试，但是手工测试的比例依然很高。

大约有80%的数据是由服务器返回，测试点

（11）使用账号登录->发布一张图片->从我的界面或好友界面查看这张图片是否发布成功

（12）使用账号登录->与某用户成为好友关系

对于这些用例执行的时候有几种方法：

（1）手动执行测试用例

（2）界面自动化测试

（3）分层测试

建议：不推荐在项目周期短的移动应用上做界面自动化测试，更多的应用在系统集成测试中

2、详解分层测试：在测试单个接口的同时，紧紧和应用业务做强绑定，从而将用户平时用到的功能逻辑一并进行自动化测试。

1. 第1层：测试代码中创建第1个文件夹实现所有的单独接口
2. 第2层：创建第2个文件夹实现关联性较强接口的组合，与应用功能做强绑定
3. 第3层：完全与业务强绑定，一个业务可能由一个或多个功能组成

总结这3层的逻辑

1. 第1层：单一接口实现                ——接口文档
2. 第2层：多个接口的组合封装实现      ——应用功能列表
3. 第3层：多个方法的组合封装实现      ——应用业务列表

 

3、当服务器接口测试有保证之后，对客户端的测试可细分，使用各种方法进行测试保证：

界面自动化、内存测试、代码规范、压力测试、客户端接口测试、单元测试

4、测试人员看到的应用应该是应用的实现、结构、用户习惯等

 

7.5联系人搜索案例测试设计实践

1、举例

1. 应用类型：智能拨号软件
2. 所在系统环境：Android、IOS、windowsphone等
3. 应用核心功能：联系人搜索、Voip、智能IP拨号
4. 应用所属结构：纯本地应用
5. 应用账号：无账号

智能联系人搜索应用的特色各有不同，但最常用的核心功能都一样——搜索

2、测试之前要先准备测试数据，需了解用户需求，比如联系人姓名的显示形式

1. 全中文名称
2. 全中文复姓名称
3. 多音字姓氏名称
4. 全英文名称
5. 中英文名称
6. 带有特殊字符的名称
7. 全号码名称

基本上就以上情况，再根据边界制作一定的设计，就会出现测试用例

3、因项目实践和人力有限需引入自动化测试，使用instrumentation框架

对搜索功能进行自动化测试，需要输入测试用例，通过使用应用的搜索方法之后，再对搜索列表做遍历查询，看看是够有期望结果。

先准备两个文本文档，一个存放测试用例（用户真实的搜索数据），另一个存放期望搜索出来的结果（用户想要的结果）

1. 新建一个Android Junit test项目
2. 将准备的测试用例数据和保存期望结果的两个文档放入测试工程的assets目录下，在setup（）方法中将对象实例化，并将测试用例和期望结果存放入list列表中
3. 将测试数据放入搜索方法，然后在搜索方法返回的结构列表中去匹配期望结果数组中对应的数据是否存在。如果存在说明搜索方法功能正常，反之说明搜索方法功能存在问题。
4. 还应关注用户体验问题，关注搜索结果排序是否靠前。

总结：如果是一个系统平台，那么使用界面自动化做一些内置应用的启动操作等保证回归测试必不可少，如果是一个应用的话，就可以把一些核心功能抽出来做接口自动化也能起到同样效果。

 

 

第8章 性能测试介绍和实践

性能测试：

1. 服务器性能测试：从服务器角度看，主要是并发量、吞吐量等性能，信息的来源可以是电脑、移动客户端、网页等，但无论是哪个，都不太影响服务器的性能测试。
2. 移动客户端应用的性能测试：与服务器端有差别

8.1Emmagee

1. 市场上出现的对系统进行管理的应用比如360、手机管家等，这类应用得到的一些数据来源未知，不能作为测试数据
2. Emmagee安装后，界面显示已安装应用，选择被测应用点击“开始测试”，Emmagee会自动启动被测应用，并进行相关数据记录，终止测试后生成相应测试报告，并保存在Android目录中。

 

8.2Instrumentation

1. Android Junit test可以做单元测试、功能测试、性能测试、压力测试等等，能够mock一些值和方法为单元测试提供方便。目前大部分的界面自动化框架都是基于Instrumentation框架做二次开发封装而成的。该工具具体怎么用视测试目的和测试切入点而定。
2. Android Junit test展开性能测试的点包括：应用的多次启动时间、多个应用的多次启动时间、应用内多个界面的切换时间、应用中image View等控件对图像的绘制时间等
3. MultiAppStartupTest测试类为例

（1）创建测试类以及制定被测应用的Acitivity和Package名称

（2）封装一个获取intent的方法

（3）编写代码计算启动时间

 

8.3HPROF

1、HPROF是一种后缀名为.hprof的文件，一个heap dump会保存为一个.hprof的二进制文件

2、介绍得到.hprof文件的其中两种方式

（1）使用Monkey工具时增加--hprof参数，然后在/data/misc目录中获取到Monkey测试开始前和结束时应用的两个.hprof文件

（2）启动DDMS，选择被测应用，单击相应按钮即可生成应用在该时刻的.hprof文件

3、hprof可使用Eclipse的MAT插件解析，分析前必须从Dalvik格式转换成J2SE HPROF格式，可直接使用hprof-conv 命令进行文件转换

4、Android提供查看内存命令：adb shell dumpsys meminfo

 

8.4Gfxinfo

1、开发者模式-->勾选Profile GPU rendering选项后即可操作测试界面，终端运行命令：adb shell dumpsys gfxinfo

2、产生日志中的profile数据，绘制数据，每一列给出了每一帧花在渲染上的时间估计。

（1）“Draw”是指Java层用在创建“display lists”（显示列表）上的时间

（2）“Process”是指Android 2D渲染引擎用在执行“display lists”上的时间

（3）“Execute”是指将一帧图像交给合成器“compositor”的时间

3、关于Execute，如果Execute花费很多时间，就意味着你跑在了系统绘图流水线的前面。应用阻塞原因：

（1）应用在Dalvik（Java虚拟机）端画的太快，而在它的Display list在GPU端执行太慢

（2）应用在前几帧的渲染上花费了太多时间，一旦流水线满了，它就跟不上，直到动画完成

 

8.5Systrace

1. 能够让我们在非常详细的时间轴上更清楚地看到应用和系统在性能上消耗的时间
2. 执行步骤

（1）开发者工具选择需要记录的trace模块

（2）终端运行Python systrace.py即可运行程序，生成trace.html报告

8.6TraceView

1、TraceView是Android SDK自带的性能测试工具，能够准确地查看到代码的更改给性能带来的变化。

2、以Android自带的NotePad应用工程举例

（1）在NoteEditor.class的onCreate（）方法中添加Debug.startMethodTracing(“NoteEditor”)；在onDestroy()方法中增加Debug.stopMethodTracing()

（2）运行并使用一些简单功能后，在/sdcard/下找到NoteEditor.trace文件，在命令框中输入：

 Traceview NoteEditor.trace

（3）在onDraw（）方法中尝试添加多个canvas.drawLine()方法，drawLine()方法占用率从3.3%增长到了16.5%

（4）在onDraw（）方法中增加canvas.drawColor(Color.BLUE)方法，整个onDraw（）方法的CPU占用率急剧升高

3、报告中相关名称解释如下：

1. Exclusive：同级函数本身运行的时间
2. Inclusive：除统计函数本身运行的时间外，再加上调用子函数所运行的时间
3. Name：列出所有的调用项，前面的数字是编号，展开可以看到有些有Parent和Children子项，就是指被调用和调用
4. Incl：Inclusive时间占总时间的百分比
5. Excl：执行总时间的百分比
6. Calls+Recur Call/Total:调用和重复调用次数
7. Time/Call:总的时间（ms）

 

8.7Instruments——Leaks

1、Leaks功能介绍:

（1）打开Instruments选择Leaks

（2）选择需要执行分析的智能手机设备及被测应用

（3）点击Record开始测试，可查看整个内存的变化情况，一段时间后应用占用的内存趋于稳定，此时若进行相关操作会看到内存增长极Instruments给出的内存不足警告

2、Leaks工具能够找出促使内存持续高涨的蛛丝马迹甚至直接原因，若在调试过程中应用直接崩溃则可从xcode的崩溃日志迅速找到导致崩溃的源头

8.8Android多分辨率自动化实践

1、真机测试通常会遇到的问题：

1. 公司机器不够
2. 真机没有root权限
3. 大规模真机测试容易出现的adb服务断开或者各种不可预计的问题

2、运行在模拟器上的测试方案要用到：

1. Python：负责总体集成
2. Shell脚本：控制启动和关闭不同分辨率的Emulator
3. MonkeyRunner：负责模拟非应用的操作以及协助截图
4. Instrumentation：负责应用内的操作
5. 最后由Python进行图片对比测试