很多用户在使用手机的过程中都遇到过应用闪退、崩溃、失去响应(冻屏)等非常影响体验的现象,究其原因,可以归结为应用稳定性故障。应用稳定性是指应用软件在规定的条件下和规定的时间内完成规定功能的能力(源于国际标准 ISO-9126定义)。
为构筑极致用户体验,需建立一套应用稳定性质量管控体系。通过增强稳定性衡量标准和测试能力,提升应用市场应用上架前后的质量保障,牵引生态内所有应用的稳定性质量改进,构建稳定和体验良好的应用生态。
软件绿色联盟邀请了阿里巴巴、百度、华为、腾讯、网易、360、中国泰尔实验室、新浪微博等知名企业和机构的应用稳定性专家共同组建了应用稳定性标准工作组,参与《软件绿色联盟应用体验标准3.0_稳定性标准》(下文简称《稳定性标准3.0》)的制定工作。
软件绿色联盟稳定性标准工作组成员
《稳定性标准3.0》在标准2.0的基础上,对稳定性衡量指标进行了优化和更新,由单一的应用崩溃率更新为故障率、资源过载、故障自恢复三个维度,同时测试活动与方法也在单一Monkey测试基础上增加了AI遍历测试、踩内存、内存泄漏测试、故障注入测试,并对不同应用故障率、故障率等级定义、常见稳定性问题进行了说明。《稳定性标准3.0》具备更好的稳定性衡量标准和测试能力。
稳定性衡量标准和测试活动与方法
经过理事会执行组多次评审,《稳定性标准3.0》于今日起至11月1日正式对外公示并征求广大应用开发者意见。如果您对稳定性标准公示内容有任何意见或建议,请发送邮件至邮箱:developer@china-sga.com,(邮件主题建议为 “稳定性标准公示意见反馈+应用或公司名称”形式)。重点修订内容如下:
1.6 术语及定义
1.6.4.1应用崩溃
在用户正常操作的情况下,应用突然出现强行退出、异常停止运行等完全不可用的情况。
1.6.4.2应用冻屏
整个系统内核和应用系统是正常的,只是某个应用或者某几个应用卡住屏幕不动或突然出现应用程序在一段时间内未能及时响应的故障,即是用户俗称的应用死机、卡死、卡屏、应用无响应ANR问题。
1.6.4.3应用资源异常(过载、泄漏、踩内存)
资源过载:在用户正常操作的情况下,应用滥用系统资源引起系统软件稳定性死机重启故障。
资源泄漏(包括内存泄漏):在用户正常操作的情况下,因应用对内存、文件和线程使用不当,有限的资源超上限申请或使用完不释放会导致资源泄漏,进而引起应用崩溃、应用冻屏稳定性故障。
踩内存:在用户正常操作的情况下,程序指令非法访问内存地址,会造成应用崩溃、应用冻屏稳定性故障。
2.2测试方法与活动
序号 | 触发方法 | 应用上架测试 | 绿标测试 |
---|---|---|---|
1 | AI菜单遍历 | 必选 | 必选 |
2 | Monkey | 可选 | 必选 |
3 | 内存泄漏验收测试 | 必选 | 必选 |
4 | 踩内存验收测试 | 必选 | 必选 |
【应用稳定性测试时长定义】:应用稳定性各专项测试周期统称为应用测试时长(单位h)。
针对不同类型的应用,根据大数据可以获取到用户各类使用频度,我们可以设置一个相对合理的压缩测试时长,达到类似用户长时间使用的实验室测试效果。不同类型应用的压缩测试时长如下:
应用类型 | 页面停留时间(秒) | 页面停留时间(秒), 等比缩放 3 倍 | 月使用时长(小时) | 月使用时长(小时), 等比缩放 3 倍 |
---|---|---|---|---|
影音娱乐 | 106.03 | 35.34 | 16.24 | 5.41 |
社交通讯 | 53.76 | 17.92 | 52.95 | 17.65 |
游戏 | 846.32 | 282.11 | 1.31 | 0.44 |
购物比价 | 30.14 | 10.05 | 5.49 | 1.83 |
金融理财 | 34.56 | 11.52 | 6.52 | 2.17 |
实用工具 | 63.6 | 21.2 | 4.61 | 1.54 |
出行导航 | 201.47 | 67.16 | 3.89 | 1.3 |
新闻阅读 | 108.56 | 36.19 | 17.34 | 5.78 |
教育 | 12.05 | 4.02 | 0.64 | 0.21 |
平均值 | 161 | 53.67 | 12 | 4.03 |
我们取各类应用的平均压缩测试时长4H为基准,作为统一的应用测试时长要求。
AI菜单遍历测试是基于AI窗口识别技术和深度遍历各应用页面有效控件算法的自动化测试专项:
标准编号 | 2.2.3 | AI菜单遍历测试 |
---|---|---|
标准描述 | AI菜单遍历测试 | |
测试方法和用例 | AI菜单遍历 | |
测试工具 | OpenLab DevEco平台 | |
判定标准 | a. 稳定性测试要覆盖80%用户的主流机型 | |
b. 安装、启动等场景必须覆盖 | ||
c. 完成2小时内满足故障率标准要求 | ||
需考虑的特殊事项 | 覆盖机型:至少覆盖应用目标用户机型分布中top10,保证80%的机型被覆盖到。 |
2.2.4Monkey 测试方法
标准编号 | 2.2.4 | Monkey测试 |
---|---|---|
标准描述 | Monkey测试 | |
测试工具 | OpenLab DevEco平台 | |
判定标准 | a. 稳定性测试要覆盖80%用户的主流机型 | |
b. 安装、启动等场景必须覆盖 | ||
c. Monkey确保覆盖页面>70% | ||
d. 完成2小时Monkey不出现异常 | ||
需考虑的特殊事项 | 覆盖机型:至少覆盖应用目标用户机型分布中top10,保证80%的机型被覆盖到。 | |
覆盖场景:全新安装、覆盖安装、冷启动、热启动及6 小时Monkey,Monkey过程要能覆盖登录与非登录状态,通过优化执行路径、多机运行累加结果等方式,保证页面覆盖率>70%。 |
2.2.5 资源泄漏测试方法
【内存泄漏测试方法】:
标准编号 | 2.2.5.1 | 内存泄露拦截测试 |
---|---|---|
标准描述 | 内存泄漏拦截测试 | |
预置条件 | a.软件版本具备内存泄露维测功能且维测开关必须开启 | |
b.覆盖应用返回桌面、热启动流程(不小于4次) | ||
c.覆盖应用关闭、冷启动流程(不小于4次) | ||
判定标准 | a.退出、关闭、热启动、冷启动等场景必须覆盖 | |
b.完成1小时AI菜单遍历不出现内存泄露问题 | ||
需考虑的特殊事项 | 覆盖应用:上架应用市场应用 |
【线程/FD资源泄漏测试方法】:
标准编号 | 2.2.5.2 | 线程/FD资源泄露拦截测试 |
---|---|---|
标准描述 | 线程/FD资源泄露拦截测试 | |
原理和测试能力描述 | a.FD泄露(文件描述符耗尽探测):当某个进程fd消耗超过水位的时候,生成告警信息,并采集该进程当前的fd消耗情况,最大采集次数可以配置 | |
b.子线程泄露(子线程创建过多):监控系统中任意进程的子线程数目,当某个进程的线程数消耗超过水位的时候,生成告警信息,并采集该进程当前的线程消耗情况,最大采集次数可以配置 | ||
预置条件 | a.软件版本具备资源泄漏维测功能且维测开关必须开启b.覆盖应用返回桌面、热启动流程(不小于4次)c.覆盖应用关闭、冷启动流程(不小于4次) | |
判定标准 | a.退出、关闭、热启动、冷启动等场景必须覆盖b.完成1小时AI菜单遍历不出现线程/FD资源泄露问题 | |
需考虑的特殊事项 | 覆盖应用:上架应用市场应用 |
2.2.6踩内存测试方法
标准编号 | 2.2.6 | 踩内存测试 |
---|---|---|
标准描述 | 踩内存拦截测试的标准 | |
预置条件 | a.提供被测应用ASAN版本(被测应用源码编译了ASAN) | |
b.整机软件版本具备ASAN检测能力且已配置被测应用的ASAN检测开关 | ||
c.覆盖应用返回桌面、热启动流程(不小于4次) | ||
d.覆盖应用关闭、冷启动流程(不小于4次) | ||
判定标准 | a.退出、关闭、热启动、冷启动等场景必须覆盖 | |
b.完成2小时AI遍历测试不出现地址越界问题 | ||
需考虑的特殊事项 | 覆盖应用:上架应用市场应用 |
·END·