i-v: % 对于智能手机,你常常听到这样的抱怨:电池太不抗用了;玩游戏一点都不流畅;什么破摄像头,把我拍的这么丑……当然,另一些时候,你听到的抱怨也许是这样的:为什么我的手机总死机?为什么新品刚上市就断货?为什么我刚买没多久它就降价了啊……
d9S/_iCI C`;igg$t_ 第一类抱怨,基本和硬件配置有关,我们纵然无奈,但也有迹可循;第二类问题,则相对有些奇妙,起码,它的现象和本质并不太容易猜透。
#[=kQ& 今天,我们就来重点分析一下第二类用户的抱怨——关于智能手机的那些怪现象。
B=d<L^ 死机:有点像买彩票 差别的是中奖率 <)T| HKx 很多智能手机用户都有过“死机”的经历,画面不动,或者干脆屏幕一黑,常规操作无法恢复其活力的,我们称之为:“手机死了”。
akyMW7'3V< 死机和质量有着最根本的关系。苹果的iPhone可能几个月也不死一次,路边的山寨机,常常整得你死去活来。智能手机为什么会死机?
s;TB(M~i[ 现在假设你和我都穿上了隐身衣,我们悄悄潜伏到手机公司测试部门,看看一部智能手机的测试过程是否符合规矩,为什么会让可能死机的产品通过检验。
5m~9Vl-& 在迈进手机研发大厦前,简单介绍下一部手机的诞生流程,以免进去后迷了路。
0R)x"4Ww 手机的诞生简单可分为“预研--设计--研发--测试--制造--销售--维护”几个环节。这期间很多流程都是相互交叉,甚至来来回回折腾不休。例如测试会提前到研发初期介入,来保证产品的问题能提前发现,还有即便进入到研发和测试的末期,设计环节也有可能提出新的变更——然后一部分甚至一大部分成果需要推倒重来。
,A` |jF 走进测试部,你会发现一台台手机被连接到电脑上,电脑屏幕快速运行着一行行神奇的代码。这便是手机测试的核心环节——跑测试用例。
:
b`N(] 我们简化下,测试用例是根据经验和需求,设计出手机可能存在的各种场景,简单到“拨出一个电话”,当系统运行这个用例时,电脑把指令传给手机,手机就会真的拨打一个号码,然后反馈一个结果回来:成功,或者失败。
%htI!b+"@ 一般手机公司的测试用例库里,会有几万甚至十几万的测试用例,然后根据手机型号的不同,选出其中一部分进行针对性测试。测试通过的,打一个对号,测试不过的,测试员会提交一个“问题单”给测试经理,再通过研发经理辗转到开发对应代码或硬件的工程师手里。
M6p\QKi 如果问题单被研发人员解决了,会把修改的硬件或软件再次提交给测试部门,进行二次验证(术语叫回归测试)。
;iiCay37F 一台手机的研发过程,基本上就是开发部门与测试部门的博弈过程,一路的刀光剑影。测试部的KPI就是谁提的问题单更多更狠,开发部的绩效则是保证进度和少出问题。所以,两者基本上就是天敌。
_$AM=?P& 手机研发是个系统活,不可能等到最后再去看是否合格。精明的管理者会在整个流程里设置多个检测点(术语叫TR点),每个点必须实现一部分目标。这样可以做到风险可控。
L-`V^{R] 对于暂时无法解决的问题,测试与研发经过友好或者激烈的讨论,决定“解决掉”,不管了,装作什么事都没发生。
iz-z?)% OK,这就是死机的根源。一部分问题单由于能力问题,或者是测试过程太复杂,手机厂商会根据风险评估来把他们屏蔽掉,并且有一个很欣慰的理由——留待后续版本解决。因此,这些没有通过的测试用例,如果偶尔被你在操作时复现了,那基本上就是一个结局——死机。
'EIe5Op 手机死机的另一个常见可能,和情景无关,叫做“内存溢出”。
=?C <