Android App常规测试内容

本文详细介绍了安卓APP从冒烟测试到安全测试的全面测试流程,包括安装/卸载、在线升级、业务功能、稳定性、性能、适配性、压力、界面易用性等测试类型,确保APP质量。

以下是一些基本安卓 APP要测试的内容,根据不同时期测试内容不一样~

 

测试内容测试类型目标
冒烟测试Monkey 1.编写adb.exe 的Monkey 命令
   2.通过logcat定位问题,保证软件的健壮性
模糊测试1.快速的定位软件的主要功能的实现聚程度
用例覆盖率测试1.通过执行的用例,推敲出软件的聚合度
安装/卸载测试在真机上的安装/卸载1.确认安装/卸载是否有问题?(覆盖安装)
第三方软件协助安装/卸载1.是否支持主流的第三方软件辅助安装/卸载
在线升级安装及使用性测试在线升级1.验证数字签名
   2.升级后能正确使用
   3.跨版本升级
   4.渠道下载包升级
业务功能测试业务逻辑测试1.客户端业务正常
功能点测试1.功能点正常
   2.前后端数据交互,页面显示及功能正常
关联性测试1.与PC端交互正常
稳定性及异常性测试交互性测试1.客户端多种被打扰测试
   2.待机,插拔数据线等操作
异常性测试1.断电,断网等异常,确认客户端稳定性
压力测试1.通过输入adb命令进行10H以上的随机操作,确认稳定性
性能测试基准性能测试1.主要测服务器借口,写多线程脚本
   2.客户端不同网络下响应速度
大数据量测试1.客户端不同网络下响应速度
接口测试模块之间,系统与模块,第三方与模块 
界面易用性测试界面与交互性测试1.符合安卓交互规范
   2.用户的体验良好
   3.使用方便,快捷
可用性测试1.可用性强,操作简单
   2.使用操作错误率低
   3.完成任务的使用时间短
适配性测试分辨率1.支持多种分辨率显示
不同版本系统1.支持多种系统运行
不同厂家定制系统1.支持多种系统运行
不同尺寸1.支持多种尺寸显示
不同屏幕1.支持多种屏幕显示
不同网络1.支持多种网络运行
联机调试测试eclipse +android sdk+jdk+代码1.连接真机进入联调模式
专项测试启动时间第一次启动与非第一次启动时间
流量启动第一次与非第一次,图片加载多的页面,
电量后台运行24小时以及模拟用户使用2天
GPUGPU过度绘制
CPU 
内存 
FPS 
稳定性测试monkey测试 
遍历测试 
固定路径压力测试常规测试:  10W   压力型测试:30W
   稳定性测试:50W   长时间执行:100W
权限测试 第三方工具跳出的提示禁止,是否会影响程序正常流程
病毒扫描测试 PC和手机工具检测
安全测试腾讯金刚网测试 
apk反编译 
签名校验 
完整性(MD5)校验 
敏感信息泄漏 
软键盘劫持 
账号安全 
服务端接口安全 
数据通信安全 
文件夹权限 
xss注入 
Android控件检查 
数据安全清除数据影响程序的数据第三方工具,如360安全卫士,猎豹
双卡双待 影响到读取手机号码以及短信支付,特别是充值方面
多语言页面UI展示 
注意输入法不同厂商预装的输入法调用以及低系统输入法调用
杀进程登录数据丢失杀进程,登陆信息丢失
输特殊字符闪退在话题输入&zwj会闪退,(\^O^/)提交异常。\字符转义
快速点击按钮快速点击或者快速刷新,会造成显示异常或者闪退
横屏视频播放点击返回卡顿
删除数据,上拉,下拉数据刷新数据填充满以后,对数据删除后进行刷新操作,会页面异常
断网数据加后载断网;断网后联网;数据加载过程中断网;断网后APP操作
修改系统时间对相关时间显示得功能或者时间判断的接口会出现异常
按home键数据刷新或者加载,按home键,在进入,页面异常或者闪退
数据跨年15年查找之前14年APP存储数据,数据显示异常或者闪退
数据互通(Android&IOS)IOSapp相通模块修改,引起的功能异常
签到,小米手机分身绕过防刷机制,可以多次签到
代码检测sonarqube 
竞品对比测试性能专项对比;用户体验 

 

 

对于质量平台(接口测试,自动化测试,性能测试,兼容性,数据收集)只是一概而过,这个无法一一说清楚。

<think>好的,我现在需要在Android应用中测试电源键(Power键)的功能。根据用户提供的参考资料,我需要了解如何拦截或处理Power键的事件,以便进行测试。首先,我应该回顾一下用户提供的引用内容,看看有哪些方法已经被提到。 引用[1]和[3]提到在PhoneWindowManager.java中处理按键事件,特别是interceptKeyBeforeQueueing方法。这里系统会处理Power键,导致应用层无法直接捕获或屏蔽该按键。所以如果要在系统层面处理,可能需要修改这个文件,添加自己的逻辑。例如,在case KeyEvent.KEYCODE_POWER中添加处理代码,可能包括传递事件给应用或者阻止默认行为。 引用[2]提到在Android 11上可以通过广播命令来启用或禁用Power键。使用adb命令发送广播,例如:adb shell am broadcast -n com.android.systemui/.WiwoodPowerKeyReceiver -a action.wiwood.enable_powerkey --es isEnable "true"。这可能是在系统UI中注册了一个广播接收器,用来控制Power键的状态。这对于测试来说可能比较方便,不需要修改系统源码,但需要系统应用的支持。 引用[4]则是在Android 12中通过设置系统属性persist.sys.tpw.keytest来控制是否将Power键事件传递给应用。当设置为1时,系统可能会允许应用接收Power键事件,测试完成后重置为0。这需要在PhoneWindowManager.java中添加相应的逻辑,检查该系统属性,并决定是否将事件传递给用户应用。 用户的问题是如何在应用中测试Power键功能。通常,普通应用无法直接捕获Power键事件,因为系统会优先处理这些按键。所以可能的解决方案包括: 1. 修改系统层代码(如PhoneWindowManager.java),在拦截事件的地方添加逻辑,允许将Power键事件传递给应用。这需要系统级权限,可能需要定制ROM或拥有root权限。 2. 使用系统提供的广播或adb命令,临时启用Power键的事件传递。例如引用[2]中的方法,这可能依赖于特定系统版本或厂商定制。 3. 通过系统属性控制,如引用[4]中的persist.sys.tpw.keytest,在测试模式下允许应用接收Power键事件。这也需要修改系统代码,但可能更灵活。 对于应用开发者来说,如果没有系统权限,可能需要寻找其他方式。例如,在设备或模拟器上使用adb命令模拟按键事件,但Power键可能无法通过常规的input命令模拟。或者,使用Instrumentation测试框架,但同样可能受系统限制。 总结可能的步骤: - 系统级修改:在PhoneWindowManager.java中的interceptKeyBeforeQueueing方法处理Power键事件,添加条件判断,当测试模式开启时(如系统属性为1),将事件传递给应用。这需要重新编译系统镜像,可能不适用于所有开发者。 - 使用广播命令:如引用[2],发送特定广播来启用或禁用Power键的功能。这可能适用于特定设备或系统版本,需要确认系统是否有此接收器。 - 设置系统属性:通过设置persist属性,控制事件传递。需要系统权限,并且修改系统代码来响应这个属性。 对于测试应用中的Power键功能,可能需要结合系统级修改和测试模式。例如,在厂测模式下设置属性,让系统传递Power键事件到应用,然后在应用中监听按键事件。 现在,用户可能需要具体的操作步骤,例如如何修改PhoneWindowManager,或者如何使用adb命令。同时,要注意不同Android版本的差异,比如引用[4]是针对Android 12的修改,而引用[3]是Android 4.2。因此,在实施时需要根据目标系统版本调整方法。 另外,测试Power键的功能可能涉及屏幕的唤醒/休眠,所以在处理事件时需要考虑屏幕状态,避免影响其他功能。例如,在测试时可能需要保持屏幕常亮,或者在处理事件后恢复原有状态。 最后,确保测试完成后能够正确重置系统设置,避免影响设备的正常使用。例如,通过adb命令在测试结束后关闭测试模式,恢复系统属性的默认值。</think>### 分步解答:Android应用测试Power键功能的方法 #### 方法一:通过系统属性控制事件传递(需修改系统源码) 1. **修改`PhoneWindowManager.java`** 在系统源码的`frameworks/base/services/core/java/com/android/server/policy/PhoneWindowManager.java`文件中,找到`interceptKeyBeforeQueueing`方法,添加以下逻辑: ```java if (KeyEvent.KEYCODE_POWER == event.getKeyCode() && SystemProperties.getBoolean("persist.sys.tpw.keytest", false)) { result |= ACTION_PASS_TO_USER; // 允许事件传递给应用 Log.i(TAG, "Power键事件已传递给应用"); return result; } ``` 此逻辑会在系统属性`persist.sys.tpw.keytest`为`true`时,允许Power键事件传递到应用层[^4]。 2. **设置系统属性** - 开启测试模式: ```bash adb shell setprop persist.sys.tpw.keytest 1 ``` - 关闭测试模式: ```bash adb shell setprop persist.sys.tpw.keytest 0 ``` 3. **应用中监听Power键事件** 在Activity中重写`onKeyDown`方法: ```java @Override public boolean onKeyDown(int keyCode, KeyEvent event) { if (keyCode == KeyEvent.KEYCODE_POWER) { Log.d("PowerTest", "Power键被按下"); return true; // 拦截事件 } return super.onKeyDown(keyCode, event); } ``` #### 方法二:通过广播控制(需系统应用支持) 1. **发送广播启用Power键测试** ```bash adb shell am broadcast -n com.android.systemui/.WiwoodPowerKeyReceiver -a action.wiwood.enable_powerkey --es isEnable "true" ``` 2. **在应用中接收Power键事件** 通过`BroadcastReceiver`监听自定义广播或系统事件(需系统签名权限)。 #### 方法三:使用ADB模拟按键(有限制) 普通应用无法直接捕获Power键,但可通过以下命令模拟: ```bash adb shell input keyevent KEYCODE_POWER ``` 注意:此命令可能仅触发屏幕开关,无法直接传递到应用层。 #### 注意事项 1. **系统权限要求** 方法一和方法二需系统级修改或签名权限,适用于定制ROM或工厂测试环境。 2. **兼容性** - Android 11/12的广播和系统属性方法可能因厂商定制失效。 - 测试完成后需重置系统属性: ```bash adb shell setprop persist.sys.tpw.keytest 0 ``` 3. **替代方案** 若无法修改系统源码,可通过**物理按键触发+日志分析**间接测试功能,例如: ```bash adb logcat | grep "PowerManagerService" ``` --- ### 相关问题 1. **如何判断Power键事件是否被系统拦截?** 可通过`adb logcat`查看`WindowManager`或`PhoneWindowManager`的日志输出,确认事件处理流程[^3]。 2. **普通应用能否完全屏蔽Power键功能?** 无法完全屏蔽,系统层始终优先处理Power键(如熄屏),但可通过方法一在测试模式下临时传递事件到应用[^1][^3]。 3. **Android不同版本对Power键处理的差异?** - Android 4.2需修改`interceptKeyBeforeQueueing`方法。 - Android 11+可通过广播或动态系统属性控制[^2][^4]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值