很多用户在使用手机的过程中都遇到过应用闪退、崩溃、失去响应（冻屏）等非常影响体验的现象，究其原因，可以归结为应用稳定性故障。应用稳定性是指应用软件在规定的条件下和规定的时间内完成规定功能的能力(源于国际标准 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.1应用稳定性

应用软件在规定的条件下和规定的时间内完成规定功能的能力(源于国际标准ISO-9126定义)。

1.6.2故障率

当期用户使用过程中本应用发生的故障总次数与当期用户使用本应用总时长的比值。

1.6.3自恢复

软件系统自我恢复机制，包含了确保系统稳定和平衡的自我恢复、调节机制。

1.6.4稳定性故障类型定义

1.6.4.1应用崩溃

在用户正常操作的情况下，应用突然出现强行退出、异常停止运行等完全不可用的情况。

1.6.4.2应用冻屏

整个系统内核和应用系统是正常的，只是某个应用或者某几个应用卡住屏幕不动或突然出现应用程序在一段时间内未能及时响应的故障，即是用户俗称的应用死机、卡死、卡屏、应用无响应ANR问题。

1.6.4.3应用资源异常(过载、泄漏、踩内存)

资源过载：在用户正常操作的情况下，应用滥用系统资源引起系统软件稳定性死机重启故障。

资源泄漏(包括内存泄漏)：在用户正常操作的情况下，因应用对内存、文件和线程使用不当，有限的资源超上限申请或使用完不释放会导致资源泄漏，进而引起应用崩溃、应用冻屏稳定性故障。

踩内存：在用户正常操作的情况下，程序指令非法访问内存地址，会造成应用崩溃、应用冻屏稳定性故障。

2.2测试方法与活动

2.2.1方法总体介绍和策略条件

根据应用上架测试、绿标测试的时长、能力成熟度不同要求，定义了各阶段测试活动策略如下：

2.2.2应用稳定性测试时长要求

【应用稳定性测试时长定义】：应用稳定性各专项测试周期统称为应用测试时长(单位h)。

【应用稳定性测试时长要求】：应用稳定性测试时长为4h。

【应用稳定性测试时长推导】：应用稳定性测试是在实验室中进行，测试时长是受限的，无法像真实用户那样真正长时间运行，但是我们可以通过加大使用频率来缩短测试时长，当前TOP应用类型中，单应用人均使用时长为12小时/月，单应用每个页面停留平均时间为161秒，那么实验室测试可以将页面停留时间缩短3倍到54秒，在大约4小时时间内完成用户1个月同样的应用体验时间和页面覆盖。

针对不同类型的应用，根据大数据可以获取到用户各类使用频度，我们可以设置一个相对合理的压缩测试时长，达到类似用户长时间使用的实验室测试效果。不同类型应用的压缩测试时长如下：

我们取各类应用的平均压缩测试时长4H为基准，作为统一的应用测试时长要求。

2.2.3AI菜单遍历测试方法

AI菜单遍历测试是基于AI窗口识别技术和深度遍历各应用页面有效控件算法的自动化测试专项：

2.2.4Monkey 测试方法

Android原生自带的通过随机输入按键键值来测试整机稳定性的小程序：

2.2.5 资源泄漏测试方法

【内存泄漏测试方法】：

【线程/FD资源泄漏测试方法】：

2.2.6踩内存测试方法

各位开发者可以通过

后续联盟将邀请各标准专家对标准进行详细解读，敬请关注。