前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >绿标3.0 | 让应用闪退、崩溃无处遁行,新稳定性标准将更全面

绿标3.0 | 让应用闪退、崩溃无处遁行,新稳定性标准将更全面

作者头像
软件绿色联盟
发布2022-03-31 12:51:13
1.2K0
发布2022-03-31 12:51:13
举报
文章被收录于专栏:软件绿色联盟动态

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

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

序号

触发方法

应用上架测试

绿标测试

1

AI菜单遍历

必选

必选

2

Monkey

可选

必选

3

内存泄漏验收测试

必选

必选

4

踩内存验收测试

必选

必选

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

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

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

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

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

应用类型

页面停留时间(秒)

页面停留时间(秒), 等比缩放 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为基准,作为统一的应用测试时长要求。

2.2.3AI菜单遍历测试方法

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

标准编号

2.2.3

AI菜单遍历测试

标准描述

AI菜单遍历测试

测试方法和用例

AI菜单遍历

测试工具

OpenLab DevEco平台

判定标准

a. 稳定性测试要覆盖80%用户的主流机型

b. 安装、启动等场景必须覆盖

c. 完成2小时内满足故障率标准要求

需考虑的特殊事项

覆盖机型:至少覆盖应用目标用户机型分布中top10,保证80%的机型被覆盖到。

2.2.4Monkey 测试方法

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

标准编号

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·

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-08-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 软件绿色联盟 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.6.1应用稳定性
  • 应用软件在规定的条件下和规定的时间内完成规定功能的能力(源于国际标准ISO-9126定义)。
  • 1.6.2故障率
  • 当期用户使用过程中本应用发生的故障总次数与当期用户使用本应用总时长的比值。
  • 1.6.3自恢复
  • 软件系统自我恢复机制,包含了确保系统稳定和平衡的自我恢复、调节机制。
  • 1.6.4稳定性故障类型定义
  • 2.2.1方法总体介绍和策略条件
  • 根据应用上架测试、绿标测试的时长、能力成熟度不同要求,定义了各阶段测试活动策略如下:
  • 2.2.2应用稳定性测试时长要求
  • 【应用稳定性测试时长要求】:应用稳定性测试时长为4h。
  • 【应用稳定性测试时长推导】:应用稳定性测试是在实验室中进行,测试时长是受限的,无法像真实用户那样真正长时间运行,但是我们可以通过加大使用频率来缩短测试时长,当前TOP应用类型中,单应用人均使用时长为12小时/月,单应用每个页面停留平均时间为161秒,那么实验室测试可以将页面停留时间缩短3倍到54秒,在大约4小时时间内完成用户1个月同样的应用体验时间和页面覆盖。
  • 2.2.3AI菜单遍历测试方法
  • Android原生自带的通过随机输入按键键值来测试整机稳定性的小程序:
相关产品与服务
云开发 CloudBase
云开发(Tencent CloudBase,TCB)是腾讯云提供的云原生一体化开发环境和工具平台,为200万+企业和开发者提供高可用、自动弹性扩缩的后端云服务,可用于云端一体化开发多种端应用(小程序、公众号、Web 应用等),避免了应用开发过程中繁琐的服务器搭建及运维,开发者可以专注于业务逻辑的实现,开发门槛更低,效率更高。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档