App测试全景图

2025-11-05 12:17:37   0  举报





AI智能生成

在App测试全景图中，核心内容涵盖了一系列细致的测试流程和环节，它们确保应用能在不同的环境、设备和场景中稳定运行。文件类型多样，包括自动化脚本、用例文档、缺陷报告以及性能分析记录等，这些文件保障了测试工作的持续性和可追溯性。使用的修饰语体现出极高的专业性和严谨性，例如“全面性”强调了测试覆盖了所有关键功能，“细致入微”突出了对用户体验和细节的关注，“不断迭代”映射出测试是持续进行的过程，以及“严格把控”体现了测试过程中的高标准和质量要求。通过这种方法，应用程序能够有效识别并修复缺陷，最终交付给用户高质量、稳定可靠的移动应用体验。

业务流程

架构

面试技巧

作者其他创作

大纲/内容

App与Web的区别

C/S（Client/Server）：即客户端/服务器，需要下载安装客户端。

B/S（Browser/Server）：即浏览器/服务器，基于浏览器访问。

Web与App区别：App是C/S结构，Web浏览器是B/S结构。

App测试范围

功能测试：业务、单功能

专项测试：安装、卸载、升级、兼容性、push消息推送、交叉事件、用户体验

性能测试：内存、CPU、电量、流量、启动时间、流畅度、稳定性

App发布

概述

将开发完成的移动应用程序通过特定的渠道和流程，向公众发布，使得用户可以下载、安装并使用一个用程序。

分类

内部发布渠道

在实际测试工作中，为了方便测试程序包的安装和管理，可以使用一些应用内测分发平台。如：蒲公英、Testlink、see平台等。

步骤：
开发将应用测试包上传到这些平台上；
平台可以生成对应的二维码；
测试直接扫码进行应用安装。

线上发布渠道

产品测试完成后，将App发布到应用个中平台上。
安卓应用：豌豆荚、应用宝、360助手、各类手机品牌商城等；
IOS应用：主要有App store、iTools、爱思助手等。

步骤：
开发者账号注册，申请在发布平台（各种应用商店）上架；
针对不同的发布平台，在软件包中加入对应的平台ID（渠道ID），上传到发布平台；
平台审核通过后，用户即可在应用商店中下载。

注意事项：

一般线上发布过程，由开发人员负责。

在软件包加入平台ID后，上传到发布平台时，需要测试人员验证核心的业务功能。

发布策略

项目发布时采用的一种策略，先发布少数（1-3个）服务器，待运行稳定后再发布到所有服务器。

总结

1. App发布方式

内部发布：蒲公英、Testlink、see平台等。

线上发布：

安卓应用：豌豆荚、应用宝、360助手、各类手机品牌商城等；
IOS应用：主要有App store、iTools、爱思助手等。

2. 上线发布策略

开发环境→测试环境→（策略：灰度发布）→生产环境
灰度发布：部分用户可用，若有异常则回滚。
线上发布：所有用户可用。

App测试

功能测试

使用技术手段，验证程序功能符合应用需求。
对象：核心业务、单功能

流程：

需求分析
测试计划
测试用例设计
测试用例执行
缺陷管理
测试报告

方法

等价类：穷举数据选取
边界值：长度范围覆盖
判定表：多条件之间约束限制
流程图：业务流程

以登录为例

需求如上：

测试点提取

正向

登录成功（注册手机号+正确密码+勾选协议）

登录成功（微信）

登录成功（QQ）

逆向

登录失败：手机号未注册+其他正常输入

登录失败：手机号为空+其他正确输入

登录失败：密码错误+其他正确输入

登录失败：密码为空+其他正确输入

登录失败：未勾选协议+其他正确输入

分析

账号

正向

已注册手机号

逆向

为空

未注册手机号

密码

正向

正确密码

逆向

为空

错误密码

协议

正向

正勾选协议

逆向

不勾选协议

第三方登录

微信

其他

关闭登录窗口

密码可见，点击查看图标（眼睛）

打开用户注册协议

用户隐私协议

打开注册界面成功（手机号快速注册）

打开找回密码页面成功，点击找回密码

登录界面和原型图一致

用户名和密码错误,漏填时,界面有提示信息;

密码更改后,登录是否正常;

用户主动退出登录后,下次启动APP时,应该进入登录界面;

IOS与Android设备登录同一个账号,用户数据是否同步;

APP安装完成后,是否可以正常打开,是否有加载图示等;

APP的运行速度正常,切换是否流畅.

免登录应用

考虑无网络情况时能否正常进入免登录状态。

切换用户登陆后，要校验用户登录信息以及数据内容是否相应更新，确保原用户退出。

根据Mtop的现有规则，一个账户只允许登陆一台机器。所以，需要检查一个账户登录多台手机的情况。原手机里的用户需要被退出，给出友好提示。

App切换到后台，在切换回前台的校验。

切换到后台，再切换回到前台的测试。

密码更换后，检查有数据交换时是否进行了有效身份的校验。

支持自动登录的应用在进行数据校验时，检查系统是否能自动登录成功并且数据操作无误。

检查用户主动退出登录后，下次启动App，应停留在登录界面。

App专项测试

软件权限

扣费风险：包括短信、拨打电话、连接网络等。

隐私泄露风险：包括访问手机信息、访问联系人信息等。

对App的输入有效性校验、认证、授权、数据加密等方面进行检测

限制/允许使用手机功能接入互联网

限制/允许使用手机发送接收信息功能

限制或使用本地连接

限制/允许使用手机拍照或录音

限制/允许使用手机读取用户数据

限制/允许使用手机写入用户数据

限制/允许应用程序来注册自动启动应用程序

当权限没有开启时,或友好提示是否运行设置,当运行开启时,跳转到设置界面;

有限制允许读写通讯录/用户数据提示或选项;

有限制允许定位功能提示或选项.

安装和卸载以及升级

安装

正常场景

在不同得操作系统版本上安装

从不同得安装渠道安装（app商城、手机助手、直接下载apk、ipa文件安装）

不同的安装路径（安装到手机上、安装到SD卡上）

卸载后安装

正在运行时覆盖安装

异常场景

安装时出现异常（关机、断网）恢复后能否继续安装

安装时存储空间不足

安装时手动取消后再次安装

低版本覆盖安装高版本

安装成功（安卓）

安装成功（IOS）

安装成功（鸿蒙）

安装成功（商城下载安装）

安装成功（手机助手）

安装成功（安装包）

安装成功（SD卡）

安装成功（卸载后安装）

安装成功（运行时覆盖安装）

安装成功（安装一般关机后继续安装）

安装成功（断网）

安装成功（存储空间不足，清理后继续安装）

安装成功（安装取消后再次安装）

安装成功（低版本覆盖高版本（跨版本安装））

能够在安装设备驱动程序上找到应用程序的相应图标

安装路径应能指定

安装空间不足时如何表现，是否有相应提示，提示是否友好

安装过程中断网或网络不稳定的情况下，是否有相应提示，以及网络恢复后是否能继续安装

卸载

卸载关注点

正常卸载（APP手动卸载、工具卸载）

运行时卸载

取消卸载

卸载异常中断卸载

卸载后无数据残留

卸载成功（手动卸载）

卸载成功（工具卸载）

卸载成功（运行时卸载）

卸载成功（取消卸载后再卸载）

卸载成功（异常中断后再次卸载（关机））

卸载成功（无数据残留）

卸载成功（保留设置、配置数据）

应用卸载后所有的安装文件夹是否全部删除

卸载过程中出现死机，断电，重启等意外的情况，等待环境恢复后是否可以继续正常卸载

卸载是否支持取消功能，单击取消后软件卸载情况是否正常

升级更新

升级

升级关注点

从临近版本升级

跨版本升级

不同渠道升级（应用商城、手机助手）

升级成功提醒

可提示升级

不提示升级

强制升级

应用内升级非wifi提醒

升级成功（从临近版本升级）

升级成功（跨版本升级）

升级成功（应用商城升级）

升级成功（手机助手升级）

升级成功（在线更新升级）

升级成功提醒（非wifi提示）

升级后要观察升级前的数据是否正常（当数据结构改变而开发没有处理好时很容易出现升级前的数据混乱）

更新

当APP有更新版本时,手机端有更新提示;

当APP版本为非强制升级版本时,可以取消更新,旧版本能正常使用.用户在下次启动APP时,仍出现更新提示;

当APP有新版本时,直接更新新检查是否能正常更新

强制更新（APP开启后要求必须更新，否则无法使用APP）

点击更新是否正确跳转至后台配置的更新页面；

多次关闭和打开APP后是否正常跳出更新弹窗，且无法关闭

当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动App时，仍出现更新提示。

当版本为强制升级版时，但给出强制更新后用户没有做更新时，退出客户端。下次启动App时，仍出现强制升级提示。

当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。

当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。

当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。

APP更新后版本号应有更新；

APP更新后新增功能和老功能可正常使用。

删除APP后更新

运行

软件安装后需要检查应用是否能正常运行

APP安装完成后，是否可以正常打开，稳定运行

APP的速度是可以让人接受，切换是否流畅

网络异常时，应用是否会崩溃:在请求超时的情况下，如果程序逻辑处理的不好，就有可能发生Crash。

Push推送

原理

Push推送场景

产品角度：
功能需要，如：资讯类产品的新闻推送、工具类产品的公告推送等等

运营角度：
活动运营需要，如：电商类产品的促销活动；召回用户 / 提高活跃度等等

技术实现

AppPush 消息推送技术的核心在于通过云端服务与设备端的通信机制，确保消息能够可靠送达。在 Android 平台上，Firebase Cloud Messaging (FCM) 是主流的推送服务。FCM 提供了高效的消息传递机制，支持单播、多播和主题订阅等多种模式。开发者可以通过 FCM 的服务器 API 发送消息，并在客户端应用中处理接收逻辑。

iOS 平台则依赖于 Apple Push Notification service (APNs)，其特点是高安全性与低延迟。静默推送（Silent Push）允许应用在不打扰用户的情况下更新内容，适用于数据同步等场景。此外，富媒体推送支持图像、视频等内容的展示，提升用户体验。

本地消息通信机制也是不可忽视的一部分，Android 中的 WorkManager 可用于调度后台任务，包括消息的本地处理与通知构建。NotificationCompat 类提供了兼容不同 Android 版本的通知样式与交互方式。

Android系统级别的推送走的是 Google 的 Firebase 服务器，这个服务器在国内不能直接访问。所以一般用个推、极光等第三方服务商SDK，同时各家Android手机厂商也会有系统级的厂商Push推送服务。

IOS是系统级推送，简称APNS。APNS 是Apple Push Notification Service（Apple Push服务器）的缩写

最佳实践

消息优先级管理：合理设置消息的优先级，避免频繁唤醒设备导致电池消耗。例如，在 Android 上可以使用 FCM 的 priority 字段来控制消息的重要性级别

后台任务调度优化：利用 WorkManager 或 iOS 的 Background Fetch 功能，将非紧急任务延迟到设备处于充电或连接 Wi-Fi 时执行，从而减少对用户体验的影响

推送到达率优化：通过分析推送失败的原因，调整重试策略和网络请求参数，提高消息的成功送达率。此外，定期清理无效的设备令牌也是必要的步骤

隐私合规性考虑：随着全球范围内对用户隐私保护法规的加强，开发者需要确保推送内容符合相关法律要求，尤其是在处理敏感信息时应获得用户的明确同意

跨平台适配：对于同时支持 Android 和 iOS 的应用，需注意两者在推送机制上的差异，设计统一的消息处理逻辑以简化开发流程并保证一致性

开发与上线注意事项

配置环节复杂度：无论是 Android 还是 iOS，都需要在各自的开发者后台完成证书申请、密钥配置等工作。特别是 iOS 的推送证书管理较为繁琐，容易成为上线前的一大障碍

监控与日志记录：实施详细的日志记录和错误追踪系统，便于快速定位问题所在。同时，可以借助第三方工具如 Firebase Analytics 来获取更全面的应用行为数据

测试环境搭建：建立完善的测试环境，模拟各种网络状况下的推送表现，确保在真实环境中也能稳定运行

推送服务器分类

操作系统级别

iOS: APNs (Apple Push Notification service)

Android: C2DM (Cloud to Device Messaging)

自建服务器

需要软硬件结合，性能强、安全性高，但成本高。

三方平台

手机厂商: 小米推送、华为推送

第三方平台: 友盟推送、极光推送

BAT大厂: 阿里云移动推送、腾讯信鸽推送、百度云推送

Push推送呈现效果

在屏幕顶部显示的一条横幅

在锁屏界面显示的一块横幅

更新app图标的数字

测试点

APP服务器设置测试点

推送内容: 推送的内容是否符合预期。

推送时机: 推送的时间点是否准确。

推送频率: 推送的频次是否符合设定。

推送人群: 推送是否针对特定用户或全部用户

手机端设置测试点

不接收推送: 设置不接收推送消息时，用户是否还会收到Push消息。

显示位置: Push消息显示的位置是否与配置一致。

打开跳转: 收到Push消息后，是否能正常打开并跳转。

其他测试点

前台提示: APP在前台使用时，收到Push消息如何提示。

后台提示: APP在后台运行时，收到Push消息如何提示。

离线接收: APP离线时，是否能收到Push消息。

push消息内容的准确性

push推送的用户是否正确（全部推送/部分推送/指定用户推送）

设置不接收推送消息时，用户是否会收到push消息

push消息推送的点击链接是否正常

app在前台运行和后台运行，用户是否能够收到push消息

用户未登录是否能收到push消息

用户长时间未登录，后续第一次登陆是否会收到历史的推送消息

应用的前后台切换

App切换到后台，再回到App，检查是否停留在上一次操作界面。

App切换到后台，再回到App，检查功能及应用状态是否正常。

App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

手机锁屏解锁后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

当App使用过程中有电话进来中断后再切换到App，功能状态是否正常。

当杀掉App进城后，再开启App，App能否正常启动。

出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。

对于有数据交换的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

权限设置

首次启动APP询问是否同意启用权限

消息权限开启时，消息推送是否正常接收（iOS系统应用启用和后台关闭时都应该可以收到；Android系统在后台关闭进程后就不会推送）

消息权限关闭后，APP客户端接收不到消息推送。

位置权限开启时，APP可定位到当前位置（比如杭州公交APP，能自动定位到用户当前位置，展示出附近的公交站）

位置权限关闭后，APP需定位才可用的功能，是否有提示引导用户开启权限，比如“请打开系统设置中’隐私-定位服务’，允许“XXXX”使用您的位置”。

网络权限关闭时，APP是否有提示（“服务器或网络错误，请稍后重试”），是否有提示引导用户开启权限。

网络测试

网络异常时，数据交换失败是否会有提醒

3G,4G,5G，wifi 网络环境下应用的各功能可正常运行；

有网到无网再到有网环境时，数据是否可以自动恢复，正常加载；

只允许内网访问的APP，在连接到外网时是否有友好提示。

在网络信号不好时,检查数据是否会一直处于提交中的状态,有无超时限制.如遇数据交换失败时要给与提示;

弱网络下操作是否有提示.

使用真实的SIM卡、运营商网络来进行测试（移动无线测试中存在一些特别的BUG必须在特定的真实的运营商网络下才会发现）

通过代理的方式模拟弱网环境进行测试（charles 硬延迟）

连接模拟弱网的热点进行测试

通过设置iPhone的开发者模式之后共享热点（硬延迟）

FaceBook开源的ATC（可使用树莓派来搭建ACT环境）

在应用中统一弱网加载的界面样式、动画效果、菊花icon等

统一网络错误、服务端错误、超时等展现给用户的界面和提示语句

定义清楚在每个中间过程是的用户交互行为

交叉事件测试

多个App同时运行是否影响正常功能

App运行时前/后台切换是否影响正常功能。

App运行时拨打/接听电话。

App运行时发送/接收信息。

App运行时发送/收取邮件。

App运行时浏览网络。

App运行时使用蓝牙传送/接收数据。

App运行时使用相机、计算器等手机自带设备。

APP运行时电量告警、插播充电器

兼容测试

与本地及主流App是否兼容

与各种设备是否兼容，若有跨系统支持则需要检验是否在个系统下，各种行为是否一致。

新旧版本兼容性测试

新旧版本覆盖安装升级正常

新增功能，新旧版本覆盖安装后使用正常

不同机型测试

系统兼容性

iOS11.x、iOS12.x、iOS13.x、iOS14.x、iOS15.x、iOS16.x、iOS17.x、iOS18.x、iOS26.x

Android系统：Android5.x、Android6.x、Android7.x、Android8.x、Android9.x、Android10.x、Android11.x、Android12.x、Android13.x、Android14.x、Android15.x

鸿蒙系统：HarmonyOS 1-6、OpenHarmony

屏幕兼容性

iOS

刘海屏机型

2017-2019年：iPhone X、iPhone XR、iPhone XS/XS Max
2020-2021年：iPhone 12全系（12/12 mini/12 Pro/12 Pro Max）、iPhone 13全系（13/13 mini/13 Pro/13 Pro Max）
2022年：iPhone 14/14 Plus
2025年：iPhone 16e（最后一款刘海屏机型）

非刘海屏（灵动岛）机型列表

2022年及以后：iPhone 14 Pro/Pro Max、iPhone 15全系（15/15 Plus/15 Pro/Pro Max）、iPhone 16全系（16/16 Plus/16 Pro/Pro Max）
2026年：iPhone 17e（首次在中端机型采用灵动岛）

Android

全面屏：例如：华为P30、红米K30至尊纪念版、荣耀X10、vivo APEX 2020等

非全面屏：例如：华为P10、华为P10 plus、荣耀8等

曲面屏：例如：三星Galaxy S10+、三星Galaxy Note 10+ 5G、华为Mate30 Pro、华为P30 Pro、vivo NEX3等

折叠屏：例如：华为Mate XS 5G、华为mate X2、三星Galaxy Z Fold2 5G、三星 Galaxy W21 5G

分辨率兼容性

iOS

2868×1320：iPhone 17 Pro Max、iPhone 16 Pro Max

2796*1290：iPhone 15 plus、iPhone 15 pro max

2556*1179：iPhone 14 Pro、iPhone 15、iPhone 16

1080*2340 ：iPhone 12 mini

1284*2778：iPhone 12 pro max

1170*2532：iPhone 12 、iPhone 12 pro

750*1334：iPhone SE 2、iPhone 7、iPhone 8、iPhone 6、iPhone 6s

1242*2688：iPhone 11 pro max、iPhone XS Max

1125*2438：iPhone 11 pro

828*1792：iPhone 11、iPhone XR

1125*2436：iPhone XS、iPhone X

1242*2208：iPhone 8 plus、iPhone 7 plus、iPhone 6s plus

640*1136：iPhone 5s

iOS系统自带的显示模式：标准模式、放大模式

Android

尺寸兼容性

iOS:5寸-6.9寸

Android:4寸-6.7寸

不同网络兼容性

Wi-Fi切换4G/5G网络情况下功能是否正常

4G/5G网络切换Wi-Fi情况下功能是否正常

有网切换无网情况下功能是否正常

无网切换有网情况下功能是否正常

其他兼容

数据兼容性（不同版本间的数据兼容），一般是测试缓存数据，如果覆盖安装之后，是否保存用户的信息，比如：登录信息、用户收藏信息

蓝牙设备兼容性测试（如果是一款使用蓝牙的应用）

存储卡兼容性测试（比如文件管理器）

第三方软件兼容冲突（比如输入法冲突）

定位、照相机服务

App有用到相机，定位服务时，需要注意系统版本差异。

有用到照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。

测试照相机服务时，需要采用真机进行测试。

客户端数据库测试

一般的增、删、改、查测试

当表不存在时是否能自动创建，当数据库表被删除后能否再自建，数据是否还能自动从服务器中获取回来并保存。

在业务需要从服务器端取回数据保存到客户端的时候，客户端能否将数据保存到本地

当业务需要从客户端取数据时，检查客户端数据存在时，App数据是否能自动从客户端数据中取出，还是仍然会从服务器端获取？检查客户端数据不存在时，App数据能否自动从服务器端获取到并保存到服务器端。

当业务对数据进行了修改、删除后，客户端和服务器端是否会有相应的更新。

性能测试

性能测试工具

SoloPi

是一个无线化、非侵入式的 Android 自动化工具，具备录制回放、性能测试等功能。

SoloPi安装

可独立安装的 SoloPi（ APK， IOS无该版本），像普通APP一样安装。

作用

基础性能测试：能够记录待测应用的各项指标，可以在悬浮窗中观察实时更新的数据，也可以对性能数据进行录制，在录制结束后查看图表；同时，还支持性能加压，能够对CPU、内存与网络环境进行限制，复现应用在性能较差、网络环境不佳场景下的表现。

录制回放：通过SoloPi执行用例步骤，能够将用户的操作记录下来，支持在各个设备上进行回放，这一切都能够在手机上独立完成。

一机多控：支持通过操作一台主机设备来控制多台从机设备，不需要在各个设备上分别进行重复冗杂的兼容性测试，能够极大提升兼容性测试的效率。

SoloPi使用

注意事项： SoloPi使用时，需要申请悬浮窗权限， adb权限，读写权限：参考地址：https://gitee.com/jaawu/SoloPi/

打开SoloPi，选择性能测试

选择被测应用，勾选监控指标，勾选后悬浮窗会出现在手机屏幕上

点击开始监控，随后打开被测APP应用，开始测试

结束监控，保存录制数据，查看数据采集结果

结果展示

可下拉选择其他性能项

APP性能测试

CPU

空闲状态下的应用CPU消耗情况

中等规格状态下的应用CPU消耗情况

满规格状态下的应用CPU消耗情况

应用CPU峰值情况

基线:如果有基线要求,CPU曲线图是否存在长期超过基线的现象(min)

如果没有基线,行业默认90%
CPU占用过高时可能出现的问题:
手机发烫
页面卡顿
电量消耗严重
快速恢复:清空后台运行的进程

内存

内存测试中的测试子项

空闲状态下的应用内存消耗情况

中等规格状态下的应用内存消耗情况

满规格状态下的应用内存消耗情况

应用内存峰值情况

应用内存泄露情况

应用是否常驻内存

压力测试后的内存使用情况

内存问题现象

内存抖动

大内存对象被分配

内存不断增长

频繁GC

内存数据获取

各种linux命令（top、free、meminfo…）

通过dumpsys
adb shell dumpsys meminfo [pakagename | pid]

通过/system/xbin/procrank工具
adb shell procrank

说明：
VSS – Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS – Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS – Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS – Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存） USS 是针对某个进程开始有可疑内存泄露的情况，是一个程序启动了会产生的虚拟内存，一旦这个程序进程杀掉就会释放。不过USS需要通过root的手机。一般没有root的手机我们可以获取PSS。而PSS通过如下命令来获取：adb shell dumpsys meminfo <Package Name>|grep TOTAL

异常曲线

正常曲线

流量

流量测试中的测试子项

应用首次启动流量值

应用后台连续运行 2 小时的流量值

应用高负荷运行的流量峰值

应用中等负荷运行时的流量均值

获取流量数据

tcpdump＋wireshark

/proc/net/目录下相关文件
cat /proc/net/dev 获取系统的流量信息

询应用的pid： adb shell ps | grep tataufo #如：31002
通过PID获取该应用的流量数据： adb shell cat /proc/31002/net/dev
（wlan0代表wifi上传下载量标识, 单位是字节可以/1024换算成KB, 打开手机飞行模式再关掉就可以将wlan0中的值初始化0）

查询应用的pid： adb shell ps | grep tataufo #如：31002
通过PID获取UID：adb shell cat /proc//status
通过UID获取：adb shell cat /proc/net/xt_qtaguid/stats | grep 31002

流量优化方法

数据的压缩
不同数据格式的采用
控制访问的频次
只获取必要的数据
缓存机制
针对不同的网络类型设置不同的访问策略

电量

功耗测试中的测试子项

手机安装目标APK前后待机功耗无明显差异

常见使用场景中能够正常进入待机，待机电流在正常范围内

长时间连续使用应用无异常耗电现象

常见的电量消耗较大的场景

定位，尤其是调用 GPS 定位。
网络传输，尤其是非 Wi-Fi 环境。
屏幕亮度
CPU 运算：复杂的运算逻辑、死循环等会直接导致CPU负载过高，会导致耗电；
wake_locker（锁屏-解锁）时间和次数

功耗测试方法

采用市场上提供的第三方工具，如金山电池管家之类的。

自写工具进行

基于android提供的PowerManager.WakeLock来进行

比较复杂一点，功耗的计算=CPU消耗+Wake lock消耗+数据传输消耗+GPS消耗+Wi-Fi连接消耗

通过 adb shell dumpsys battery来获取

battery-historian（google开源工具）

一般使用万用表或者功耗仪安捷伦进行测试，使用功耗仪测试的时候，需要制作假电池来进行的，有些不能拔插电池的手机还需要焊接才能进行功耗测试

启动速度（响应时间）

理解

从单击事件触发到容器启动NativeAPP消耗的时间（埋点）

NativeAPP完整启动消耗的时间（可以通过system.log获取）

Native调用RPC请求方法的延迟时间（埋点）

RPC请求发出去过程中的具体数据（req_size req_header req_time等，通过埋点获取）

RPC请求返回的具体数据（res_size res_header res_time等，通过埋点获取）

本地解析返回数据所消耗的时间（埋点或者TraceView工具可获取）

界面渲染的时间（可以通过慢速摄像机或者埋点获取）

应用的启动时间的测试，分为三类

冷启动: APP离线的状态下启动; 时间长
热启动: APP后台运行的状态下启动. 时间短

首次启动 --应用首次启动所花费的时间

非首次启动 --应用非首次启动所花费的时间

应用界面切换--应用界面内切换所花费的时间

应用启动时间数据获取

adb logcat > /address/logcat.txt #所有activity打印的日志
find “Displayed” /address/logcat.txt > /newaddress/fl.txt #通过日志过滤关键字Displayed来过滤
find “ActivityName” /newaddress/fl.txt > /newaddress/last.txt #通过activity名来过滤获取所测应用

流畅度

帧率(FPS): 每秒切换多少帧

60fps为最佳

稳定性(monkey)

app自动化会接触monkey命令

模拟器使用常见异常处理

app自动化中会介绍到

用户体验测试

是否有空数据界面设计，引导用户去执行操作。

是否滥用用户引导。

若按钮当前不可用，应将其置灰或移除，以免误导用户。

菜单层次是否太深。