什么是MTBF测试

MTBF测试

目前,终端侧的可靠性测试基本上是采用称为”MTBF测试”的专有测试活动来进行的。

 

中国移动2015版的MTBF测试的标准是:每轮测试5台终端并行连续循环执行以下用例7X24小时,期间记录系统级问题,包括死机、重启、白屏、脱 网等严重问题。最终计算终端的无故障运行时间

 

T:T = 5X7X24 /(故障数)

 

如果终端支持稳定性测试中对应的本地及通信类业务,则要求终端对于支持的业务满足稳定性测试中,在 TD-SCDMA、TD-LTE 网络下平均无故障运行时长指标不低于 250 小时。零售价 2500 元以上不低 于 350 小时。

 

北美电信运营商AT&T的MTBF指标是这样定义的:7台手机每天24小时不间断运行AT&T规定的测试,测试内容包括2G/3G语音呼叫、短彩信、浏览器上网、电话本操作。测试过程中出现的测试用例失败情况都会记录下来,然后用7台手机总的运行时间除以全部手机出现的测试失败次数,即得到MTBF值。整个测试过程全部采用自动化方式,并且都在AT&T的现网环境下进行,该测试已经成为所有与AT&T合作的终端厂商都必须通过的测试,而且是所有厂商公认的最难通过的测试。

 

YunOS的MTBF测试是由YunOS系统测试团队执行的,同时制定了更为严格的通过标准。

 

MTBF测试与系统可靠性

可以看出,MTBF测试标准的定义与上文介绍的System Availability的概念不是完全一致,因为移动终端毕竟与服务端从架构,实现方法,到用户群体都不尽相同;严格来讲MTBF测试是终端可靠性测试其中的稳定性测试部分。然而有不少地方是两者是相通和可以借鉴的。比如:

 

MTBF中的故障数可以近似理解为Outage,系统重启属于Total Outage, 模块Crash属于Partial Outage

提升可靠性都是需要降低故障数减小downtime

在系统和应用设计中都需考虑如何减少错误,或者出现错误如何恢复。

终端上的一些后台服务可以近似理解为服务端应用,虽然不能完全照搬上文中提到容灾和恢复的场景,但是可以借鉴其中的一些思路。

终端上可以通过参考DPM的概念增加数据衡量指标,但可能不需要也不现实每个场景都执行100万次操作,可以依据实际情况调整标准要求

可以参考Failover策略中错误探测,隔离,恢复的操作在出现错误时及时发现,快速恢复重新启动来减少对用户造成的负面影响,恢复时间即Failover Recovery Time就成了一个关键指标

### Android MTBF测试概述 平均无故障时间 (Mean Time Between Failures, MTBF) 是衡量系统可靠性的重要指标之一。对于Android系统而言,MTBF测试旨在评估设备在长时间连续工作下的稳定性和可靠性。 #### 测试目标 确保设备能够在各种条件下持续正常运作,减少因硬件或软件问题导致的意外停机次数[^1]。 #### 准备阶段 为了有效开展MTBF测试,需先做好充分准备: - **构建稳定的测试环境**:创建一个尽可能接近实际使用的场景,包括但不限于网络连接状态、电源模式切换等。 - **选择合适的样本量**:依据统计学原理选取适当数量的目标设备参与测试,以提高结果的有效性。 - **定义清晰的操作规范**:制定详细的脚本指导整个过程中的每一步骤,从开机到关机期间的所有交互行为都应有明确规定[^2]。 #### 执行流程 ##### 自动化工具的应用 采用自动化框架可以极大提升效率并降低人为因素干扰的可能性。常用的工具有如下几种: - **MonkeyRunner**: 提供了一套Python API用于控制模拟器或真实设备上的应用程序启动/关闭及其他UI事件触发动作。 ```python from com.android.monkeyrunner import MonkeyRunner, MonkeyDevice device = MonkeyRunner.waitForConnection() package = 'com.example.app' activity = '.MainActivity' runComponent = package + '/' + activity device.startActivity(component=runComponent) ``` - **Appium**: 支持多平台移动应用自动化的开源项目,在此背景下可用于跨版本间对比分析不同ROM环境下相同APP的表现差异情况。 ##### 数据收集与监控机制建立 在整个周期内保持对关键性能参数的关注至关重要,比如CPU占用率、内存泄漏状况、电池消耗速度等等。借助ADB命令行接口能够方便快捷地获取这些信息: ```bash adb shell dumpsys meminfo <package_name> ``` 同时建议部署专门的日志管理系统以便于事后追溯异常现象发生的具体时间节点及其前后关联事项。 #### 结果分析 最终形成的报告应当包含以下几个方面内容: - 整体稳定性评分; - 发现的主要问题列表连同重现路径描述; - 针对未来改进方向提出的建设性意见。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值