上海交通大学工程管理硕士学位论文 摘要

基于DMAIC的高通智能手机系统稳定性测试流程改善研究

摘 要

智能手机系统稳定性是指手机在长时间运行过程中手机系统出现
自动重启、冻屏、黑白屏、系统崩溃的频率，使用平均无故障间隔时
间来衡量。近些年来，随着用户对智能手机使用频率的增加，以及手
机厂商为了追求产品差异化而不断对手机硬件进行升级，再加上 5G
和人工智能等新技术在智能手机上的广泛应用，当前的智能手机的系
统稳定性测试流程面临着严重的挑战。为了更好地应对挑战，手机厂
商以及手机芯片厂商都在不断地对各自的测试流程进行优化，以希望
提高测试效率，改善测试质量。
本研究针对全球手机芯片市场份额常年占据前两名的手机芯片厂
商高通公司的智能手机系统稳定性测试流程进行优化。主要采用搭载
高通公司手机芯片的智能手机的系统稳定性的测试数据来驱 动
DMAIC 模型进行流程改善并在以下三个方面进行了创新。首先，针对
智能手机系统稳定性测试自动化程度较高，测试人员不易掌握测试细
节，也不易积累有效的经验去定位测试流程中的改善对象的问题，本
文在定义阶段提出了利用帕累托图、层次分析法和质量功能展开对手
机厂商客户问题数据和内部测试技术指标进行分析的方法，以权重最
高的测试技术指标为改善对象，解决了依据工程经验不易确定改善对
象的问题。其次，针对智能手机系统稳定性测试过程中使用的测试设

I
上海交通大学工程管理硕士学位论文 摘要

备和工具较多而导致潜在影响因子过多且不易量化分析的问题，本文
在测量和分析阶段提出了利用过程能力分析、因果图和 5M1E 分析法，
失效模式与效果分析将潜在影响因子缩小在过程能力不足的测试工序
中并结合工程经验对潜在影响因子进行量化分析的方法，提高了潜在
影响因子分析的效率和质量。最后，针对智能手机系统稳定性的测试
时间较长，通过实际测量的方法去评估改善效果耗时较长的问题，本
文在改善和控制阶段提出了手机使用率的理论计算的方法，利用快赢
改善措施和 DOE 实验改善的评估结果来计算改善效果的理论值，加快
了改善效果评估的速度。
经本研究的分析和改善，当前测试流程中的测试手机的使用率提升
了 10%，每年节省了 15 万美金的设备闲置费用。同时，改善了 MTBF
测试报告的质量，总测试时长增长了 58.8%，发现的系统崩溃数量增
长了 132%。

关键词：手机系统稳定性测试，DMAIC 模型，层次分析法，质量功能
展开，失效模式与效果分析，DOE 实验设计

II
上海交通大学工程管理硕士学位论文 ABSTRACT

RESEARCH ON IMPROVING THE STABILITY TEST PROCESS

OF QUALCOMM SMART PHONE SYSTEM BASED ON DMAIC

ABSTRACT

The stability of smart phone system refers to the frequency of

automatic restart, frozen screen, black-and-white screen, and system crash
of the mobile phone system during the long-term operation of the mobile
phone, which is measured by the mean time between failures. In recent
years, with the increasing use of smart phones by users, and the continuous
upgrading of mobile phone hardware by mobile phone manufacturers in
pursuit of product differentiation, coupled with the wide application of 5g
and artificial intelligence and other innovative technologies in smart
phones, the current system stability test process of smart phones is facing
serious challenges. To better cope with the challenges, mobile phone
manufacturers and mobile phone chip manufacturers are constantly
optimizing their test processes to improve test efficiency and test quality.
This research aims to optimize the smart phone system stability test
process of Qualcomm, the world's top two mobile phone chip
manufacturers in terms of market share. It uses the test data of the system
stability of smartphones equipped with Qualcomm mobile chips to drive
the DMAIC model for process improvement and makes innovations in the
following three aspects. Firstly, in view of the high automation level of
smart phone system stability test, testers cannot get to the test details and
accumulate effective experience to locate the improvement objects in the
automated test process, this thesis uses Pareto Diagram, analytic hierarchy
process and quality function deployment to analyze the customer data and
internal test technical indicators of mobile phone manufacturers, and take

III
上海交通大学工程管理硕士学位论文 ABSTRACT

the test technical indicators with the highest weight as the improvement
object, which solves the problem that the improvement object cannot be
determined based on engineering experience. Secondly, due to the large
number of test equipment and tools used in the stability test of smart phone
system, there are too many potential influence factors, and it is not easy to
analyze quantitatively. This thesis uses process capability analysis, cause
and effect diagram, 5M1E analysis method and failure mode and effect
analysis in the measurement and analysis stage to reduces the potential
impact factors in the test process with insufficient process capacity and
combines the method of quantitative analysis of potential impact factors
with engineering experience, which improves the efficiency and quality of
potential impact factor analysis. Finally, in view of the long test time of
smart phone system stability and the long time-consuming problem of
evaluating the improvement effect through the actual measurement method,
this thesis puts forward the theoretical calculation method of mobile phone
utilization rate in the improvement and control stage, and uses the quick
win improvement measures and the evaluation results of DOE
experimental improvement to calculate the theoretical value of the
improvement effect, which speeds up the evaluation speed of the
improvement effect.
Through the analysis and improvement of this research, the utilization
rate of the tested mobile phones in the current test process has increased by
10%, saving $150000 in idle equipment costs every year. At the same time,
the quality of MTBF test reports was improved. The total test duration
increased by 58.8%, and the number of system crashes found increased by
132%.

Key words: smart phone system stability test, DMAIC, analytic hierarchy
process, quality function deployment, failure mode and effect analysis,
DOE

IV
上海交通大学工程管理硕士学位论文 目录

目 录

摘 要 ................................................................................................................................ I

ABSTRACT ................................................................................................................. III

第一章 绪论 ....................................................................................................................1

1.1 研究背景和意义 .................................................1

1.1.1 智能手机系统稳定性测试流程改善的背景与挑战 ................ 1

1.1.2 智能手机系统稳定性测试流程改善的意义 ...................... 2

1.2 国内外研究现状 .................................................3

1.2.1 智能手机系统稳定性测试流程改善的国外研究现状 .............. 3

1.2.2 智能手机系统稳定性测试流程改善的国内研究现状 .............. 4

1.3 研究内容和关键技术 .............................................5

1.3.1 研究内容 .................................................. 5

1.3.2 DMAIC 流程改善模型 ......................................... 5

1.3.3 研究方法和工具 ............................................ 6

1.4 研究框架 .......................................................8

第二章 智能手机系统稳定性测试流程的现状和问题定义 ....................................... 9

2.1 智能手机系统稳定性测试流程的现状 ...............................9

2.1.1 智能手机系统稳定性测试流程介绍 ............................. 9

2.1.2 智能手机系统稳定性测试流程中存在的问题 .................... 10

2.2 手机厂商客户问题的收集与分析 ..................................12

2.2.1 手机厂商客户问题的处理流程 ............................... 12

V
上海交通大学工程管理硕士学位论文 目录

2.2.2 手机厂商客户问题的收集 ................................... 13

2.2.3 手机厂商客户问题的测试场景分析 ........................... 16

2.3 改善对象和改善目标的确立 ......................................20

2.3.1 智能手机系统稳定性测试流程技术特性展开 ................... 20

2.3.2 智能手机系统稳定性测试场景与技术特性质量功能展开 ......... 22

2.3.3 制定智能手机系统稳定性测试流程改善的目标 ................. 23

2.4 制定项目任务计划书 ............................................23

2.5 本章小结 ......................................................25

第三章 智能手机系统稳定性测试流程的测量和分析 ............................................. 26

3.1 智能手机系统稳定性测试流程的关键工序测量 ......................26

3.1.1 确定关键测试工序 ......................................... 26

3.1.2 关键测试工序的测量系统分析 ............................... 28

3.1.3 关键测试工序的过程能力分析 ............................... 31

3.2 智能手机系统稳定性测试流程的影响因子的识别与分析 ..............35

3.2.1 潜在影响因子的识别与分析 ................................. 35

3.2.2 关键影响因子的识别与分析 ................................. 41

3.3 本章小结 ......................................................44

第四章 智能手机系统稳定性测试流程的改善与控制 ............................................. 45

4.1 智能手机系统稳定性测试流程的初步改善 ..........................45

4.1.1 快赢改善措施 ............................................. 45

4.1.2 快赢改善措施的效果评估 ................................... 47

4.2 智能手机系统稳定性测试流程的深度改善 ..........................52

4.2.1 DOE 实验设计改善 .......................................... 52

4.2.2 DOE 实验设计改善的效果评估 ................................ 58

VI
上海交通大学工程管理硕士学位论文 目录

4.3 智能手机系统稳定性测试流程的改善效果评估 ......................60

4.3.1 手机使用率的理论改善效果评估 ............................. 60

4.3.2 手机使用率的实际改善效果评估 ............................. 61

4.4 智能手机系统稳定性测试流程的控制措施 ..........................62

4.5 本章小结 ......................................................67

第五章 智能手机系统稳定性测试流程改善的成果评估 ......................................... 68

5.1 智能手机系统稳定性测试流程改善的直接成果评估 ..................68

5.1.1 测试手机使用率提升评估 ................................... 68

5.1.2 MTBF 测试报告质量改善评估 ................................. 69

5.2 智能手机系统稳定性测试流程改善的间接成果评估 ..................69

5.2.1 测试执行人员工作量评估 ................................... 70

5.2.2 改善经验可推广性评估 ..................................... 71

5.3 本章小结 ......................................................72

第六章 总结与展望 ......................................................................................................73

6.1 总结 ..........................................................73

6.2 不足与展望 ....................................................74

参 考 文 献 ..................................................................................................................76

致 谢 ............................................................................................................................80

VII
上海交通大学工程管理硕士学位论文 第一章 绪论

第一章 绪论

1.1 研究背景和意义

1.1.1 智能手机系统稳定性测试流程改善的背景与挑战

智能手机系统稳定性是指手机在长时间运行过程中手机系统出现自动重启、
冻屏、黑屏或者白屏、手机系统崩溃的频率，通常使用平均无故障间隔时间（Mean
Time Between Failures, MTBF）[1]来衡量。近些年来，手机厂商和手机芯片厂商都
在不停对自家手机系统稳定性测试流程进行优化，并且利用该流程在手机上市前
对自家的手机系统稳定做深度测试。通常是采用数十台，上百台，甚至是上千台
上市前的量产手机或者工程手机，通过长时间的运行自动化测试用例，来模拟用
户在不同场景下，长时间的操作智能手机。最后，在测试结束时，统计所有手机
的总测试时长和发现的总的系统稳定性问题数量，来计算 MTBF 数值。因为整个
测试流程中，测试时长很长，测试设备也很多，基本不可能通过纯人工去完成这
一测试，只能通过自动化的测试手段来完成智能手机系统稳定性测试。但是由于
测试工具和测试方法的缺陷，以及测试场景的不断变化，即使手机厂商和手机芯
片厂商不停对自家手机系统稳定性测试流程进行优化，当前的智能手机系统稳定
性测试流程中依然有很多问题。
智能手机系统稳定性测试流程改善工作面临的挑战主要来自三个方面。首先，
是近些年来智能手机用户的手机使用时长和频率不断增长。当前，人们获取网络
连接的首要途径，已经从电脑过渡到移动端的设备[2]，人们通过智能手机即可连
接互联网，形成了移动互联网。人们的日常生活在移动互联网出现以后，已经变
得截然不同[3]。人们可以更加方便快捷的利用移动互联网来解决人们的衣食住行
等生活问题，从而使智能手机成为人们生活中的必需品[4]。也就导致人们日常生
活中智能手机的使用频率和使用时长，都较以往功能机时代急剧增长。为了应对
这一使用频率和时长的变化，就需要保证当前的智能手机系统可以连续无故障运
行更长的时间，就需要改善后测试流程能提供更长时间，更高效的测试。其次，

1
上海交通大学工程管理硕士学位论文 第一章 绪论

是 5G 和人工智能等新兴技术在智能手机上的广泛应用。当前，因为智能手机是
与 5G 技术关联度较高的行业，其围绕 5G 开发的功能场景十分丰富[5]，随着 5G
技术不断地创新演变，手机应用的使用场景也十分广阔，特别是智能手机用户的
体验也越来越流畅舒适[6]。而随着人工智能技术在智能手机上应用，指纹和人脸
识别等技术已经广泛地应用于智能手机的各个使用场景[7]。这些新技术在智能手
机的应用，一方面可以给用户带来更多更好更快的手机使用体验，但是另一方面，
也增加了更多的智能手机的使用场景，这些新的使用场景给智能手机的系统稳定
性带来了更多的不确定影响因素，因此需要不断地改善当前的测试流程，覆盖这
些新的智能手机系统稳定性的相关场景，发现更多的智能手机系统稳定性问题。
最后，则是国内各个手机厂商为了和友商的产品区别，以便吸引更多的客户，都
在不停地对自家产品的外观，软件以及所使用的硬件器件上进行创新[8]。对外观
和硬件的升级，除了最常见的手机屏幕和手机摄像头的升级以外，部分技术实力
较为强硬的手机厂商会使用自研芯片，如小米推出的澎湃 C1 芯片，VIVO 推出的
自研 ISP 芯片 V1 以及 OPPO 推出的自研 NPU 芯片“Mari Silicon X”[9]。除了这
些，智能手机的电池续航能力、手机存储空间的大小以及手机的实际运行速度等
都会给智能手机的用户带来不同体验[10]。这些差异化的软件和硬件，不仅给智能
手机的系统稳定性带来了更多不确定的影响因素，也给智能手机芯片厂商提供的
手机芯片处理器带来了挑战。如何针对这些不同手机厂商的差异化的软件和硬件，
设计不同的测试用例，以便更好地发现在不同软件和硬件下的自家手机芯片导致
的系统稳定性问题，避免遗漏问题，对于当前的测试流程改善工作来说，也是一
个巨大挑战。

1.1.2 智能手机系统稳定性测试流程改善的意义

为了应对这些挑战，手机厂商和手机芯片厂商都在不断地对各自的测试流程
进行优化。厂商们使用更多的测试手机，在更多的手机设计和生产环节进行系统
稳定性测试，希望更早的发现手机系统稳定性问题并集中力量去解决这类系统稳
定性的问题。由于在手机系统设计，手机主控芯片设计以及手机设计等环节均使
用了大量的量产手机或者工程手机，各种系统稳定性的问题也就有更多的机会暴
露出来，那么每个厂商解决这类问题的经验也就越来越丰富。再经过一代代智能
手机技术的更新和经验的积累，手机系统的稳定性自然也就越好，手机厂商的口
碑也就越来越好，销量也越来越多，对手机系统稳定性的反馈也就越多，最终形

2
上海交通大学工程管理硕士学位论文 第一章 绪论

成一个良性的循环。因此无论是对于手机厂商，还是手机芯片厂商来说，手机系
统稳定性的测试都是值得花大量人力物力和时间去优化改善的。

1.2 国内外研究现状

1.2.1 智能手机系统稳定性测试流程改善的国外研究现状

国外对于智能手机系统稳定性测试流程的改善研究，主要分为随机测试流程
和针对性测试流程的改善。
随机测试流程，主要是采用一些随机测试工具在智能手机上模拟用户随机的
操作智能手机，来验证手机在长时间随机测试过程的系统稳定性。在 Android 上，
一般使用 Android 提供的随机测试工具 Monkey 来进行随机测试。但是因为这类工
具，完全随机的测试策略，导致其测试效率不高，依然需要进行改善[11]。为了改
善这种随机测试流程的测试效率，Jordan Doyle 等人设计了一种基于模型驱动的新
的随机测试架构，希望通过给予随机工具足够多的测试环境信息，来生成更有效
的随机事件，从而提高随机测试流程的测试效率[12]。虽然该方式可以提高 Monkey
测试的效率，但是这种程度的改善却依然达不到针对性测试中的所有元素全覆盖
的效果，反而可能会因为测试环境信息获取的偏差而导致部分关键功能未覆盖，
从而导致随机测试流程未能做到真正的随机。
针对性测试流程，主要是采用一些能实现精准控制的自动化测试工具来模拟
一些用户常用操作，来验证智能手机的系统稳定性。在 Android 系统上，一般是
使用 Android 提供的 UIAutomator 工具，利用它来分析 Android 原生应用的界面元
素并控制操作这些元素，从而达到操作测试应用的目的[13]。但是 UIAutomator 只
能识别原生应用的控件信息，对于一些基于 web 的应用，它并不能识别到详细的
控件信息。随着近年来 web 应用发展，特别是小程序这类轻型应用的发展，对于
web 应用的精确测试控制的需求越来越多。为了应对这类 web 应用的测试，国外
的测试人员开始采用 Appium 这类新型自动化测试工具来实现控件控制[14]。除了
在 Android 上进行自动化操作以外，Appium 还可以同时兼容 IOS 系统，使同一套
测试用例同时跑在不同的平台之上[15]。但是该工具的环境配置方式和使用方式较
为复杂，对于上百台机器的系统稳定性测试来说，其测试环境的维护工作量巨大。
本文所进行的智能手机系统稳定性测试流程改善研究工作，主要是对随机测
试和针对性测试流程中的一些测试步骤及方法进行优化改善。比如，使用 DOE 实

3
上海交通大学工程管理硕士学位论文 第一章 绪论

验设计来选择最佳的 Monkey 测试参数。相较于国外的研究方法，本文中的智能

手机系统稳定性测试流程中所使用的方法，一方面，能保证测试的完全随机性和
测试的有效性；另一方面，在尽可能地识别并控制智能手机测试的同时，也能简
化测试环境的维护和测试用例的设计工作。

1.2.2 智能手机系统稳定性测试流程改善的国内研究现状

国内对于智能手机系统稳定性测试流程的改善研究可分为对国外现有工具的
完善和升级来提高测试流程效率和利用管理类的方法进行流程优化这两类。
对国外现有工具的完善和升级的工作包括：利用 python 脚本对 UIAutomator
的接口进行封装，来简化测试用例的开发和维护执行流程[16]；设计新型手绘测试
脚本语言来减少人工测试成本[17]；利用神经网络模型来识别手机屏幕中的图标和
文字，获取其在屏幕中准确的位置[18]；设计一套手机稳定性测试监控系统提高测
试流程中测试日志分析的效率[19]。虽然这些工作通过简化测试用例设计，提高测
试效率等方式对当前的测试流程进行了优化，但是在实际使用过程仍发现，这些
工具在长时间的测试过程，其自身的稳定性并不可靠，经常出现一些因工具自身
问题而导致的测试异常问题。此外，采用这些工具在设计测试用例的过程中，设
计和维护过程较为复杂，不利于测试用人员更新和维护。因此，在选用测试工具
进行流程改善的同时，仍需要将工具的稳定性，易用性作为首要考虑因素。
利用管理类的方法进行流程优化的工作包括：在手机测试用例的设计阶段，
采用正交试验设计法等方法来设计测试用例[20] ；在测试用例执行过程中，采用
PDCA 循环的质量管理的工具来对测试流程进行改善[21]；在测试组织形式和过程
中，通过风险管理的手段来进行改善[22]。虽然这些方法，可以对当前测试流程的
各个环节进行优化和改善，但是所采用的方式只是针对局部环节进行改善，缺少
一种从测试全局改善的视角，因此所进行的改善仍具有一定的局限性，不能彻底
地对当前的测试流程进行改善。
本文所研究的智能手机系统稳定性测试流程，结合了自身测试机器多，测试
时间长，测试流程自动化程度高的特点，从测试全局出发，采用 DMAIC 流程改
善模型，在测试过程中使用了一些稳定性和易用性均较高的测试工具，进行流程
改善。相较于国内的研究人员所采用的工具或者管理类方法，本研究中的方法一
方面可以更符合本测试流程中测试机器多，测试时间较长的实际情况；另一方面，
也可以从全局更加彻底的对当前的测试流程进行改善。

4
上海交通大学工程管理硕士学位论文 第一章 绪论

1.3 研究内容和关键技术

1.3.1 研究内容

本研究主要是采用 DMAIC 流程改善模型，对高通公司应用端手机系统稳定性

测试项目组所使用的一套自动化测试流程进行分析改善。希望找出当前流程中存
在的问题，并制定相应的改善措施，最终通过制定标准化作业书的形式，将改善
措施固化，确保改善措施能够长久持续的执行，以达到提高测试效率，改善测试
质量的目的。
该项目组的主要工作内容是通过编写模拟用户操作 Android UI 的测试用例，
在使用高通公司芯片的工程手机上进行长时间的压力测试，来验证芯片的稳定性。
该项目组每年承担 5 到 6 个左右的高中低端手机芯片的压力测试工作。每个项目
会使用 20 台左右的工程手机同时进行测试。当前，整个项目组已经为手机系统稳
定性测试设计一套全自动化的测试流程。通过公司开发的 Axiom 智能手机自动化
测试平台，将刷机，驻网，手机预设置，执行测试用例，抓测试日志，上报问题
和问题自动去重，统计问题数量等流程全部串联在一起。经过这些自动化工具方
法的改善，当前该项目组的手机自动化测试流程得到了初步改善。但是由于一些
人为因素，环境，机器以及测试方法的局限性，当前的测试流程仍面临测试用例
执行效率低，部分机器异常导致自动化测试流程阻塞，测试机器发现问题数量不
一致等问题。因此，本研究希望通过使用 DMAIC 流程改善模型，对这些问题进
行分析，找出关键问题，作为改善对象，并制定改善目标，通过测量和分析，制
定相应的改善措施，最后在通过制定标准作业书的形式，确保改善措施得到长久
有效的执行。

1.3.2 DMAIC 流程改善模型

DMAIC 模型是六西格玛理论中一种对现有流程的改进方法[23]。一般是通过定
义，测量，分析，改进和控制这五个阶段，由表及里、系统性全盘考虑影响项目
目标的每个环节、每个因素[24]。用客户或流程伙伴处收集到的信息[25]，强调以了
解客户需求为其关注的焦点[26]。
本研究选择 DMAIC 模型作为基础模型， 第一，DMAIC
主要基于以下三点原因。
模型以数据作为流程改善的依据。相较于以工程经验进行改善的方法，以数据为

5
上海交通大学工程管理硕士学位论文 第一章 绪论

基础的改善，可以更彻底的解决问题。第二，DMAIC 模型以客户的需求作为改善
的方向。相较于依据自身需求的改善方法，以客户需求为导向的改善方法，可以
使改善结果更符合客户的需求，提升自身产品对客户的吸引力。第三，DMAIC 模
型可以对改善效果进行控制并且保证改善措施长久有效的持续执行。相较于其他
只解决当前具体问题的方法，DMAIC 模型不仅可以解决当前主要问题，还可以通
过制定标准化文件的方式，将改善措施固化，确保改善措施可以长久有效的执行。

1.3.3 研究方法和工具

本研究除了采用 DMAIC 作为基础模型，还采用了帕累托图、层次分析法、质

量功能展开、测量系统分析、过程能力分析、鱼骨图 5M1E 分析法、失效模式和
效果分析、快赢措施、DOE 试验设计法、标准化作业书和 Minitab 等方法和工具。
帕累托图是基于帕累托原则绘制而成的一个直方图，它强调 80%的价值是来
自 20%的因子，其余的 20%的价值则来自 80%的因子[27]。本研究中收集了客户半
年内上报的 5000 多个系统稳定性问题。由于数据量大，问题类型也多，不易直接
从中找出对客户最为重要的问题类型。但是通过绘制帕累托图，再根据帕累托原
则，则可以直接将其中占比达到 20%以上的问题类型，作为客户最为关心的关键
系统稳定性问题类型，方便后续进一步分析。
层次分析法（Analytic Hierarchy Process， AHP）是一种定性与定量分析相结
合的系统分析方法[28]。本研究中，客户测试场景主要有九个，这么多的测试场景，
很难直接通过经验去判断相对重要度。而利用层次分析法则可以将客户的测试场
景按照目标，准则，方案等层次进行展开，并通过相关专家经验打分的方式，找
出最优的方案。同时也会得到每一个方案的权重，对每个方案的重要度进行排序。
基于上述的特点，该方法可以很方便地对客户上报的关键系统稳定性问题的测试
场景进行展开，并且得到每个测试场景的重要度排序，方便后续进一步分析。
质量功能展开（Quality Function Deployment，QFD）是将客户需求与内部技
术指标通过质量屋模型相联系起来，进而提高产品质量的一种分析方法[29]。该方
法可以很好地将客户需求与项目的内部质量相关技术指标相关联，确定重要度较
高的质量相关技术指标。本研究在通过层次分析法确认客户上报的关键系统稳定
性问题的测试场景的相对重要度得分后，再结合工程经验和工程人员的评估[30]，
确定客户的测试场景与内部的测试技术指标的强弱关系，创建 QFD 质量屋关系
矩阵。最后，通过 QFD 技术特性权重和 QFD 技术特性的权重系数公式[31]，计算

6
上海交通大学工程管理硕士学位论文 第一章 绪论

出技术特性重要度，根据重要度排序，进行综合分析，选取重要度最高的测试技
术指标作为本研究的改善对象。
测量系统分析（Measurement Systems Analysis，MSA）主要用于 DMAIC 改善
工作中测量阶段，用于判断工序的测量系统是否合格[32]。本研究在确定改善对象
后，通过 SIPOC 图找出了一些关键测试工序。在采集这些影响工序的数据时，需
要一个可靠的测量的系统来确保测量数据的准确性。测量系统分析可以通过预先
采集数据并统计测量数据分布的方法，来帮助判断测量系统的是否符合关键工序
的测量要求。后面再结合过程能力分析，去确定过程能力不足的影响工序，方便
后续进一步分析。
鱼骨图法又称因果图，一般使用它来逐条分析产品开发过程中遇到问题的原
因[33]，5M1E 分析法主要用来分析整个产品生产过程中的所有质量影响因素 [34]，
一般 5M1E 分析法与鱼骨图法相结合使用。本研究中，由于测试流程较为复杂，
导致测试工序过程能力不足的影响因子也较多，通过 5M1E 分析法和鱼骨图法可
以较为全面的深度梳理导致工序过程能力不足的所有影响因子。
失效模式和效果分析（Failure Mode and Effects Analysis，FMEA）可以按照系
统中每一个故障模式的严重程度予以分类[35]。其中应用最广的两种 FMEA 工具为
DFMEA 和 PFMEA, 分别用来识别设计和生产过程中的失效模式[36]。本研究中导
致手机使用率较低的故障类型较多，故障原因也各不相同，不易直接对每个故障
的严重程度进行分级。而通过 FMEA 对每个故障按严酷度，发生频率，可探测度
等进行专家打分，再去计算出风险优先数，就可以很容易地将风险优先数值大于
90 的作为严重等级较高的故障，即 DMAIC 模型的关键输入影响因子 X, 从而建
立起 DAMIC 模型方程 Y=F(x)。
快赢措施主要用于流程的改善阶段。对于能较快实施、较易实现、较低成本、
可能有效、较易恢复原状的影响因子可直接使用。实验设计（Design of experiment，
DOE）是一种通过设计正交表安排试验，来得到产品生产的最佳参数组合的方法
[37]
。在对手机系统稳定性测试流程中主要影响因子的改善过程中，通过 DOE 全因
子实验设计法，实验多组改善参数组合，从中寻找到最优改善参数组合。
标准化作业书一般可以按照工程作业标准化和工程管理标准化这两种类型来
划分[38]，它可以有效地减少员工无效工作[39]。通过对手机系统稳定性测试流程的
定义，测量，分析以及改善，已经实现了对现流程优化的目的。在控制阶段，则
需要巩固改善成果，可以利用标准化作业书的形式对改善流程的方法进行总结，
用于对所有测试相关人员的工作指导，确保改善措施能够长久有效的执行。

7
上海交通大学工程管理硕士学位论文 第一章 绪论

Mintab 是质量改善工作中常用到的一种统计分析工具[40]，本研究主要用于测
量系统分析，过程能力分析，绘制鱼骨图，设计 DOE 全因子实验。过程能力分析
通常用于 DMAIC 模型改善工作的测量阶段 [41]，将工序的测量数据代入 Minitab
得到分析结果[42]，再根据分析结果中 CPK 数值判定工序的过程能力是否充足[43]。

1.4 研究框架

如图 1-1 所示，为本文的论文结构框架图。本研究可分为六个章节，包括绪论，
DMAIC 模型的定义、测量分析和改善控制阶段，以及改善成果评估和总结展望。

图 1-1 论文结构框架图
Fig.1-1 Thesis structure frame diagram

8
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

第二章 智能手机系统稳定性测试流程的现状和问题定义

2.1 智能手机系统稳定性测试流程的现状

2.1.1 智能手机系统稳定性测试流程介绍

图 2-1 为当前项目组的智能手机系统稳定性测试流程的业务流程图。首先，是
版本部门拉取一个手机项目的主线代码和一些代码改动合成一个测试版本，以邮
件的方式发送测试需求给各个测试部门。系统稳定性测试组接收到测试需求后，
则开始根据测试需求，安排对应的测试手机开始准备测试。目前，所有的测试任
务都是通过公司开发的自动化测试平台 Axiom 管理的。公司自动化的测试用例开
发完成以后，一般需集成到该系统上运行。在接收到测试需求以后，测试执行人
员需在正式测试前，确保所有测试电脑上的 Axiom 客户端能正常运行，所有测试
手机均需在 Axiom 上可以正常识别。对于所有掉线的手机，需人工去检查原因，
恢复手机上线。当确认所有手机上线后，则通过 Axiom 网页端，填写测试版本信
息，选择测试用例和测试所使用的测试机器，提交测试任务。测试任务提交后，
按照事先编写的自动化测试脚本，Axiom 客户端会先根据版本信息给所有测试的
手机进行刷机和一些常用的手机预设置，开始执行测试用例。在测试过程中，
Axiom 会实时监测手机状态，一旦发现手机出现系统崩溃，则会调用系统崩溃抓
取工具，来抓取系统崩溃日志，日志抓取完成后，手机会自动重启，测试用例则
继续运行。一般测试至少运行一个晚上，第二天有新的测试需求，则在网页端提
交停止测试请求。此时，可通过 Axiom 网页端，查询当前测试任务中所有机器运
行的总时间，以及发现的系统崩溃总数量。再根据总时间和系统崩溃数量来计算
MTBF 数值。测试人员整理测试报告，统计总的测试时间和系统崩溃数量以及
MTBF 数值，发送给研发人员分析。研发人员会对发现的系统崩溃进行分析，找
到系统崩溃的原因以后，则提交代码改动，并经过相关人员审阅以后合并到项目
主线。最后版本部门则在下一个测试需求时，拉取对应改动和主线代码给测试部
门，一方面验证改动是否有效，另一方面验证主线代码是否有其他问题。这样直

9
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

到项目结束，系统稳定性测试组，按照每周三到五个版本的频率，不断进行系统
稳定性测试。最终当这个项目的 MTBF 数值达到公司内部的标准后，即可发布给
客户使用。

图 2-1 智能手机系统稳定性测试的业务流程图
Fig.2-1 Smart phone stability test transaction flow diagram

2.1.2 智能手机系统稳定性测试流程中存在的问题

目前项目组基于 Axiom 开发的自动化测试流程已经运行了一年以上的时间。

相对于原来半自动化的测试流程，全自动化测试流程不仅可以快速地对测试需求
进行响应，使测试频率由原来的每周一个测试版本，提升到最快一天一个版本的
测试频率。而测试机器，则由原来的一个人负责十多台机器的测试，提高的每个
人负责两到三个项目的六七十台机器同时测试。在提高测试频率和测试机器数量
的同时，每个人的工作量并没有显著增加，相反测试人员每天只需要检查测试机

10
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

器状态和测试问题的跟踪之上，对于测试执行和上报问题完全交给 Axiom 和自动

化测试脚本完成，使人从繁重的测试任务执行和日志分析并上报问题的工作中解
脱出来，有了更多的时间，去优化当前测试流程和问题的跟踪之上。
根据近一年的自动化测试流程运行经验，发现当前的自动化测试流程中主要
有以下四个挑战。第一，测试工具经常更新导致部分测试环境无法正常工作。由
于 Axiom 平台刚开发完成不久，公司 Axiom 团队经常对该自动化平台进行更新，
特别是对客户端的强制更新。虽然，大部分测试电脑可以顺利更新完成，但由于
使用的测试电脑有上百台，再加上更新频率也比较高，因此经常会遇到更新后，
有个别测试电脑的 Axiom 无法正常使用。由于 Axiom 并非测试组维护，每当遇到
这种情况，只能联系 Axiom 对应的团队去解决问题，但因为使用 Axiom 的人较多，
维护团队对问题反应速度较慢，从而影响当天的测试。第二，经过近一年的测试
结果观察，可以发现在每个测试版本上所有测试器上发现的问题数量分布不均匀。
同样的版本和同样的测试用例，有的机器发现问题多，有些机器发现的问题却相
对较少。正是基于这种问题分布不均的问题，每当需要复现某些问题的时候，并
不能百分之百地复现，影响关键问题的复现概率和定位问题原因的进度。第三，
缺乏有效手段去监督测试用例的实际执行情况。因为整个测试流程是由测试人员
远程触发，交由 Axiom 全自动化执行，最终只看测试运行的时间和发现的问题数
量，来看测试效果。对于项目前期，版本稳定性较差的时候，这种方法可以有效
地看出测试效率。但是对于项目后期，因为版本较为稳定，问题数量较少，对于
此种情况，当前缺乏有效手段去监督测试用例的执行情况。第四，测试设备管理
的相对松散。实验室有一百多台测试电脑，每年测试手机有一百到两百台左右，
目前尚没有制定合理的设备管理办法，均是由各个测试项目的负责人自己管理，
无法有效地监督各个项目的机器使用情况和机器具体去向。
除了内部面临的一些问题，同时还面临着一些来自客户的外部问题。首先，
近些年来为了保证各自手机品牌的影响力，减少手机故障的发生，客户的 MTBF
测试指标逐年增加。其次，客户加大了对测试场景和测试用例的优化，发现了一
些内部测试用例无法复现的问题。最后，客户为了产品差异化，而在手机上引入
的新技术，但是却缺乏相关新技术的测试经验。
为了更好地应对这些问题，在 DMAIC 改善模型的定义阶段，本研究从客户上
报的系统稳定性问题的主要类型开始分析，找出客户的主要测试场景，并与内部
的测试技术指标相联系，确定急需改善的测试技术指标并对其进行改善。

11
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

2.2 手机厂商客户问题的收集与分析

2.2.1 手机厂商客户问题的处理流程

智能手机系统稳定性问题的来源主要是手机芯片厂商自己的测试团队，手机
厂商测试团队以及手机售后团队。其中大部分的问题主要还是芯片厂商在芯片发
布给客户之前，靠自身的测试团队尽早发现的。对于小部分未能在芯片厂商测试
中发现的问题，也会在手机量产的过程中，被手机厂商的测试团队发现。真正流
入到手机客户手中的问题再通过手机售后团队反馈的问题则十分稀少。如果大量
系统稳定性的问题流入到手机客户手中，则说明该型号的手机研发流程出现了重
大失误。因此，为了在手机上市前尽可能地发现更多的智能手机系统稳定性相关
的问题，避免出现大量问题流出到客户手中，提高手机研发流程的质量，手机芯
片厂商和智能手机厂商均会在手机上市前做大量的测试工作。一般手机芯片厂商，
会在手机芯片量产前利用先期少量的手机芯片制作一些工程手机，先在芯片厂商
内部做系统稳定性的测试，当内部的 MTBF 指标满足条件，就可以交付给客户。
客户拿到手机芯片以后，则开始进行手机量产的工作。从手机芯片交付给客户，
到客户的手机上市，中间一般需要几个月的时间。在此期间，手机芯厂商依旧会
对手机做系统稳定性测试，以不断提高手机的 MTBF 指标。同时，客户也会利用
工厂量产的机器，采用更多的手机，在不同的量产环节，在更多的测试场景下，
对手机做系统稳定性测试。一般手机芯片厂商内部发现的问题，会及时解决，并
通过给客户发布的新的软件版本上进行更新，或者直接提供补丁。而客户发现的
问题，则会先由自己的研发人员进行分析，如果发现是手机芯片厂商引入的问题，
则会通过手机厂商的客户支持团队，提交问题，并由手机芯片厂商的研发人员进
一步分析，并提供相应的补丁。
图 2-2 即为公司客户提交的系统稳定性问题的处理过程数据流图。首先客户会
在公司系统上创建问题单，同时会产生系统稳定性问题的数据，该数据描述了这
些问题的基本复现场景和报错日志。公司的客户支持团队收到问题单后，会进行
问题的初步分析，并把初步分析数据记录在系统上。同时公司测试团队也会去复
现该问题，如果不能复现该问题则会要求客户提供详细的问题复现步骤，去复现
问题。如果内部团队，发现该问题在内部不具备复现条件，则由客户去复现该问
题。复现问题后，则会提供详细的问题日志给公司研发团队进行深度分析。分析
定位出问题以后，则提交对应的代码改动并合成新的测试版本，给测试团队或者

12
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

客户，去确认该问题是否还能复现。如果仍能复现，则会提供新的详细测试日志
给研发团队分析，直至问题无法复现。客户支持团队，则会向客户发布代码补丁，
客户拿到补丁，则会合入正常手机版本里，该系统稳定性问题得到解决。

图 2-2 客户系统稳定性问题处理的数据流图
Fig.2-2 Customer stability issue debug data flow diagram

2.2.2 手机厂商客户问题的收集

由于智能手机系统稳定性问题的来源主要是手机芯片厂商自己的测试团队，
手机厂商测试团队以及手机售后团队。一般售后团队反馈的问题数量较少，不利
于数据的有效分析。手机芯片厂商的问题，则是已经被现有测试流程发现，对手

13
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

机芯片厂商来说，对这类问题的分析，不能有效地找出现有流程存在的问题。而
手机厂商的问题，一部分是由于手机芯片厂商未及时更新软件版本，导致一些已
知问题流入到客户手里，这类问题随着版本的更新会逐步得到解决。另一部分，
则是由于手机芯片厂商内部测试流程的缺陷，未能很好地覆盖所有的测试场景，
导致问题流入到手机厂商手中。再加上，手机厂商量产的过程使用的测试机器和
机型种类众多，更有利于问题的进一步暴露，从而得到大量的系统稳定性问题的
样本。因此通过对手机厂商上报问题的分析，一方面可以有更多的分析样本，另
一方面也可以找出手机芯片厂商和手机厂商测试场景的差异，从而指导手机芯厂
商找出当前测试流程中存在的问题，以便于测试流程的升级改造，进一步提高自
身的测试能力，减少问题的流出。
由于公司每年都会推出一款或几款高中低端芯片，因此在去收集客户上报的
系统稳定性问题的时候，需要选取近年来具有代表性一款芯片，而综合条件下，
A 系列产品是最为合适的分析对象。 A 系列产品是公司于 2020 年 12 月份正式对
外发布的一款 5G 移动平台。这款芯片，是公司首次在该系列旗舰产品中集成 5G
调制解调器，同时还包括了人工智能引擎，游戏引擎和摄影相关功能的更新。由
于这款芯片采用了较多的新技术，导致了当时无论公司内部还是客户方面，都上
报了大量的系统稳定性问题。因此，通过对该型号机器系统稳定性问题数据的分
析，可以更好地去发现当前测试流程在面对一些新技术的应用时，所暴露出的不
足，更有利于去发现和改善当前测试流程中存在的问题。
如表 2-1，是公司 A 系列产品在 2020 年 7 月至 12 月期间，客户通过客户支持
团队上报的系统稳定性问题统计表。该数据表收集整理了 A 系列产品上市前，近
半年的 5000 多个系统稳定性问题。这些问题主要来源于中国市场上的主流智能手
机厂商。本研究首先把这些问题按照 21 个类型划分，再按照每个类型出现的数量
进行统计，绘制帕累托图，根据二八法则找出客户上报的最重要的系统稳定性问
题类型。接着，再进一步分析该类问题的主要出现场景和测试手段，利用层次分
析法对这些场景的重要度进行排序。最后，则把这些场景和内部测试流程中的一
些技术指标通过质量功能展开图相关联，找出测试流程中最为重要的测试技术特
性，并通过对其进行定义来设定改善指标，从而完成智能手机系统稳定性测试流
程改善研究的问题定义阶段，也为制定改善任务的项目计划书提供了方向。

14
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

表 2-1 A 系列产品 2020 年 7 月至 12 月份客户系统稳定性问题统计表

项次 问题类型 问题说明 问题数量 比例 累积百分比
1 AP Kernel 应用处理器内核 1153 22.76% 22.76%
2 WLAN 无线网络子系统 825 16.29% 39.04%
3 Camera 相机模块 650 12.83% 51.88%
4 5G others 5G 相关的其他问题 497 9.81% 61.69%
5 LTE 4G 网络制式问题 303 5.98% 67.67%
6 Audio 音频模块 243 4.80% 72.46%
7 PMIC 电源管理集成电路 231 4.56% 77.02%
8 5G SUB-6 5G sub-6 频段相关 211 4.17% 81.19%
9 TZ Trust Zone 安全模块 209 4.13% 85.31%
10 RPM 资源电源管理 137 2.70% 88.02%
11 Framework Android 框架 112 2.21% 90.23%
12 RF Cal 射频校准 93 1.84% 92.06%
13 ADSP ADSP 子系统 76 1.50% 93.56%
14 CDSP CDSP 子系统 69 1.36% 94.93%
15 5G mm W 5G 毫米波 58 1.14% 96.07%
16 IMS IP 多媒体子系统 58 1.14% 97.22%
17 Bluetooth 蓝牙模块 52 1.03% 98.24%
18 GPS 全球定位系统 45 0.89% 99.13%
19 Sensor 传感器 20 0.39% 99.53%
20 CDMA1x 3G 网络制式 12 0.24% 99.76%
21 Video 视频模块 12 0.24% 100.00%
合计 5066 100%

图 2-3 即为由表 2-1 转换而来的客户系统稳定性问题的帕累托图。通过累积百

分比数据可知，百分之八十的手机系统稳定性问题来源于应用处理器内核，无线
网络子系统，相机模块，5G 和 4G 模块以及音频模块。这些问题，一方面是由于
5G 等新技术首次在该型号芯片上应用，另一方面也是由于客户对这相机，音频等
用户体验的投入和重视，以至于加了大量的相关测试场景，导致这类问题的集中
爆发。进一步对数据分析可知，手机应用处理器内核相关的问题，占到了总数的
22.76%, 即超过了 20%。根据二八法则可知，尽管其他系统稳定性的问题发现的
数量很多，但是却只是次要的。而手机应用处理器的问题在数量上超过了总数的
百分之二十， 即可认为它是对客户来说最重要的问题。内核问题的重要性高于

15
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

5G 和其他相机音频模块，最主要的原因还是手机内核在手机系统中发挥着不可替
代的重要作用，它管理着手机系统的进程，内存，设备驱动，文件和网络系统等，
也就是说所有手机相关的功能基本都要与系统内核相关联。而一些新技术的应用
和新场景的出现，对于系统内核来说，由于以前并未有效地测试过相关场景，因
此更加容易导致相关稳定性问题的出现。

图 2-3 A 系列产品系统稳定性问题的帕累托图
Fig.2-3 Product A customer stability issues Pareto chart

2.2.3 手机厂商客户问题的测试场景分析

首先，通过对客户上报的系统稳定性问题的收集和整理，可以得出手机应用
处理器内核的问题才是客户上报问题中最为重要的问题。因此，进一步对收集的
数据进行分析，找出手机应用处理器内核问题的主要复现场景和测试手段。通出
对客户复现场景和测试手段数据的整理，可以发现手机内核处理器的问题的复现
场景和测试手段主要可以分为三大类，即随机测试，针对性测试和功能测试。接
着通过如图 2-4，对客户系统稳定性问题的场景进行层次展开。目前客户随机测试

16
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

的场景，主要是 Monkey 随机测试，以及客户自己研发的随机测试用例，如 MTBF

测试和老化测试用例。而针对性测试，则是指对基本常用功能的重复性测试，一
般进行上万次的重复测试。对于手机系统稳定性来说，大部分手机厂商进行的针
对性测试，主要是对手机屏幕的休眠和唤醒进行重复性测试，对手机开关机进行
反复的重启测试，部分厂商会利用恒温箱去制造一些特殊环境，来验证手机在一
些特殊温度条件下的稳定性。至于功能测试，可以分为在生产线上进行基本的功
能验证测试，或者测试人员拿着手机在全国各地进行实地场外测试。手机在待机
过程中出现的随机问题，也会被测试人员上报。特别是近些年来出现的语音唤醒
技术，大部分厂商都会利用音箱在手机待机状态下随机唤醒，来验证手机系统的
稳定性。

图 2-4 智能手机客户系统稳定性问题的场景层次展开图
Fig.2-4 Smart phone customer stability issue scenario hierarchical expansion diagram

通过该层次划分，基本可以很好地反映客户所有的测试场景和测试手段，也
对进一步分析提供了很好的数据支撑。最后，开始利用层次分析法来分析这些测
试场景和测试手段的重要度。为了更好地利用层次分析法，首先制作了表 2-2，来
说明客户系统稳定性问题的场景层次。在目标层，设定确定智能手机客户系统稳
定性问题的场景为层次分析法的目标。在准则层，则利用随机测试，针对性测试

17
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

以及功能测试，作为这些场景的重要度分类准则和依据。在方案层，则具体放置
了 Monkey 测试，MTBF 测试，老化测试，休眠唤醒测试，重启测试，高低温测
试，待机测试，产线功能测试以及场外功能测试等九个具体的测试场景作为最终
分析的测试场景和手段。除此之外，还增加了一列方案说明，以对这些测试场景
进行详细说明。通该表的说明，已经初步完成了层次分析法的数据分层任务。
表 2-2 智能手机客户系统稳定性问题的场景层次体系及说明表
目标层 准则层 方案层 方案说明
C1 Monkey 测试 谷歌提供的自动测试工具
B1
C2 MTBF 测试 客户 A 进行的压力测试
随机测试
C3 老化测试 客户 B 进行的压力测试
A
C4 休眠唤醒测试 重复执行手机休眠唤醒
客户问题 B2
C5 重启测试 重复执行手机重启
的测试场 针对性测试
C6 高低温测试 高温低温下手机测试
景分析
C7 待机测试 手机待机过程出现系统崩溃
B3
C8 产线功能测试 手机生产线上进行的功能测试
功能测试
C9 外场功能测试 在外场进行的功能测试

接着通过工程经验对已建立的客户测试场景和测试手段的准则层和方案层，
通过两两比较的方法，去得出一个相对重要性，并根据表 2-3，智能手机系统稳定
性问题的场景重要度两两比较九级标度表，来对这个相对重要度进行打分，从而
对每个层次构建出合适的判断的矩阵，作为进一步分析的判断依据。本研究主要
利用 Python 软件中的 Numpy 工具包来计算判断矩阵的权重向量和特征值，并通
过查表的方式得到 RI 的值为 0.58, 最后进行一致性检验。如表 2-4 所示，本研究
所使用的 A-B 层次，B1-C 层次，B2-C 层次，B3-C 层次这四个三阶的判断矩阵均
通过了一致性检验，可以作为分析客户系统稳定性问题的测试场景和测试手段的
判断矩阵。进一步可以通过算术平均法或直接利用特征值法求得当前层次每个元
素对应的权重。本研究在 Python 代码里主要采用算术平均法来计算每个层次的权
重向量。通过表 2-4，可以直观地看到每个层次的判断矩阵以及对应的各种指标的
计算方式和计算结果，也能更好地反映出所使用的层次分析法的分析过程，极大
地提高了分析过程的直观程度，也方便在后续工作中对此表的维护和相关数据的
查询。完成该表后，即可计算方案层的所有方案的最终重要度排序，即通过选择
判断矩阵和计算对应的权重向量得到表 2-5 所示的客户系统稳定性问题的场景重
要度总排序表。

18
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

表 2-3 智能手机系统稳定性问题的场景重要度两两比较九级标度表
标度 含义
1 两个智能手机系统稳定性测试场景的重要度一致
3 当前智能手机系统稳定性测试场景比另一个稍微重要
5 当前智能手机系统稳定性测试场景比另一个明显重要
7 当前智能手机系统稳定性测试场景比另一个强烈重要
9 当前智能手机系统稳定性测试场景比另一个极端重要
2 ，4 ， 6 ， 8 上述智能手机系统稳定性测试场景比较结果的中间值
倒数 上述两两比较结果的倒数

表 2-4 智能手机客户系统稳定性问题的场景层次分析结果表
一致性
权重 最大特 CI 值 CR 值
项目 判断矩阵 RI 值 检验结
向量 征值λ (λ-n/n-1) (CI/RI)
果
A B1 B2 B3
A-B 0.724
B1 1 5 7
层次 0.193 3.065 0.0324 0.58 0.056 通过
B2 1/5 1 3
分析 0.083
B3 1/7 1/3 1

B1 C1 C2 C3
B1-C 0.090
C1 1 1/5 1/5 6.67x 1.149x
层次 0.455 3.000 0.58 通过
C2 5 1 1 10-16 10-15
分析 0.455
C3 5 1 1

B2 C4 C5 C6
B2-C 0.292
C4 1 1/3 5
层次 0.627 3.094 0.047 0.58 0.081 通过
C5 3 1 6
分析 0.081
C6 1/5 1/6 1

B3 C7 C8 C9
B3-C 0.082
C7 1 1/3 1/8
层次 0.236 3.002 0.0008 0.58 0.001 通过
C8 3 1 1/3
分析 0.682
C9 8 3 1

19
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

表 2-5 智能手机客户系统稳定性问题的场景重要度总排序表
B1 B2 B3
C/B 总权值 总排序
随机测试 针对性测试 功能测试
0.724 0.193 0.083
C1 Monkey 测试 0.090 0 0 0.0652 3
C2 MTBF 测试 0.455 0 0 0.3294 1
C3 老化测试 0.455 0 0 0.3294 1
C4 休眠唤醒测试 0 0.292 0 0.0564 5
C5 重启测试 0 0.627 0 0.1210 2
C6 高低温测试 0 0.081 0 0.0156 7
C7 待机测试 0 0 0.082 0.0068 8
C8 产线功能测试 0 0 0.236 0.0196 6
C9 外场功能测试 0 0 0.682 0.0566 4

通过计算可以发现，客户 A 和客户 B 进行的 MTBF 测试和老化测试是最为重

要的两个测试场景。而高低温测试和待机测试的相对重要性则十分低下。因此可
以得出，需要进一步去模拟客户 MTBF 测试和老化测试的测试场景，以求发现更
多的客户问题。同时对于一些重要度较低的问题，也可以根据实际情况，按照一
定的优先级去安排对应的测试。

2.3 改善对象和改善目标的确立

通过收集关键客户问题并对其测试场景进行层次分析，目前已经确立了客户
的主要测试场景和测试手段和对应的重要度排序，最后则需要确定这些测试场景
和测试手段与内部的测试技术特性的关系，以此来确定改善对象和改善目标。

2.3.1 智能手机系统稳定性测试流程技术特性展开

如表 2-6 所示，项目组对应的应用端手机系统稳定性测试的主要技术特性有以
下 10 点。第一，测试手机数量。一般根据每个测试团队的测试能力来决定，但至
少需要数十台的机器测试。如果机器太少，一方面无法满足总的测试时长要求；
另一方面，也缺乏足够的测试样本去发现更多的问题。第二，测试手机种类。虽
然，采用的都是公司生产的工程手机，但有些机器的生产批次，所使用的制造工
艺，设计用途等也有很大的差别，所以采用更多种类的智能手机进行测试，能有

20
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

效地提高测试智能手机测试的样本多样性。第三，测试手机的使用率。由于目前
都采用自动化测试，机器众多，再加上版本切换之间的空隙时间，很难确保所有
测试手机均可以一天 24 小时不停地运行，一旦中途因为一些原因导致测试用例停
止，这台机器就会处于空闲状态，造成机器使用率的浪费。第四，总测试时长。
一般来说测试时长越长，发现问题的概率也就越大，而由于版本切换的原因，很
难确保机器能够跑满足够的测试时长，因此一般采用增加测试机器的方式，使用
众多的测试手机，把它所有的测试时长加在一起，算总测试时长。至于第五，第
六和第七点，则是关于测试用例相关的技术特性。目前所采用的测试方式仍是随
机测试，即通过设计上百条测试用例，在每轮测试中，随机的选取其中的一些测
试用例执行，来达到模拟用户随机操作手机的目的。因为测试时间长，测试用例
随机选择，有些测试用例并不一定能运行成功或者被运行到，因此在每轮测试结
束以后，都需要评估测试用例的通过率。还要不断地去增加测试用例的数量，以
达到覆盖更多测试场景的目的。第八点，并发测试用例数量。不同于正常的 UI
测试，此类测试通过运行一些二进制文件，可以直接在手机后台运行，调用相关
的接口直接运行，且不会影响前台的测试。这类测试用例，一般采用公司内部的
测试工具或者 Android 常用的测试工具来进行。一般也是很多并发测试用例，随
机选择在后台运行。第九点和第十点，则是有关测试版本选择的技术特性。目前
测试版本一般选择调试版本进行测试，对于高性能版本或者正常版本则会有其他
功能测试团队选择。而测试频率，对于重要系列产品是每天一个版本。对于比较
成熟的，则是每周一到三个版本的频率进行测试。
表 2-6 智能手机系统稳定性测试技术特性展开表
编号 指标 指标说明
D1 测试手机数量 一般测试需 20 台以上测试手机
D2 测试手机种类 生产阶段的差异，用料的差异，芯片代工厂的差异
D3 测试手机使用率 每台机器的测试用例实际测试时长与理论测试时长的百分比
D4 总测试时长 所有机器总的测试时长
D5 测试用例数量 一般会设计几百条测试用例随机执行
D6 测试用例成功率 所有随机测试用例成功运行的比例
D7 测试场景覆盖率 一轮测试下来，测试场景与总设计的场景的百分比
D8 并发测试用例数量 除了正常了 UI 测试，还会加一些并发测试用例在后台运行
D9 测试版本种类 测试版本可分为正常版本，高性能版本，调试版本等
D10 测试版本切换频率 每周三到五个测试版本

21
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

2.3.2 智能手机系统稳定性测试场景与技术特性质量功能展开

如图 2-5，是由客户测试场景 C1 到 C9 重要度的权重值和内部测试流程的 D1
到 D10 技术特性组成质量功能展开图。此屋的左侧为由层次分析法得到的智能手
机系统稳定性客户测试场景以其对应的重要度权重值。而屋顶，则是项目组智能
手机系统稳定性测试流程所对应的技术特性以及技术特性的相关性。屋子的中间，
则是客户场景与内部测试技术特性的相关性，本研究采用测试专家打分的方式，
给客户测试场景与内部测试技术特性的相关性进行打分。而屋子底部，则分别是
内部测试流程的技术特性得分，权重，和排序。技术特性得分是把每一列的相关
度得分与对应的客户场景重要度的乘积进行求和，即可得到每一项技术特性的得
分。最后，根据得分和权重，对所有技术特性进行排序，即可得到内部智能手机
系统稳定性测试的所有技术特性重要度的排序。

图 2-5 智能手机系统稳定性测试场景与技术特性质量功能展开图
Fig.2-5 Smart phone stability test scenario and technical characteristics QFD
根据图 2-5 所示的质量屋，可看到权重最高的为测试手机使用率，占总权重的
15%。而权重最低的为测试版本种类，仅占总权重的 2.81%。由此即可得出，对于

22
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

内部的测试流程来说，测试手机的使用率对于模拟客户场景来说，具有最高的重
要度。而测试版本种类，则与客户场景的模拟相关度最低。通过质量屋，很快地
得到内部测试的技术特性重要度排序，也准确找出当前的主要改善目标是提高当
前的测试手机的使用率。最后，则需要确定当前手机使用率的具体数值，并设定
一个合理的目标，通过一系列的流程改善手段，来完成这一目标。

2.3.3 制定智能手机系统稳定性测试流程改善的目标

由质量屋得到本研究的主要改善目标是测试手机的使用率。经过查询整理 A
系列产品在 2020 年 7 月份至 12 月份的测试报告，可以得到如表 2-7 所示的测试
机器使用率统计表。表中的有效测试天数，除了 10 月份国庆放假时间较长，机器
停止测试了 11 天左右，其余月份，理论上机器均应每天在测。表中的测试机器数
量，随着测试的进行，可能有一部分机器在测试过程中损坏而无法继续使用，因
此从测试中去除，而项目后期也没有新机器的补充，只能使用较少数量的机器进
行测试。利用有效测试天数和平均每日测试机器数量即可得到理论测试时长。再
结合测试报告中得到的实际测试时长，即可算出机器使用率。通过计算，可知半
年的时间内，机器最低使用率为每月 55.56%，最高的为每月 75.11%, 平均使用率
为 67%。因此结合表中的统计结果，本研究把研究目标定为，将当前手机的平均
使用率由 67%提高到每 77%。
表 2-7 A 系列产品 2020 年 7 月至 12 月份测试机器使用率统计表
月份 7月 8月 9月 10 月 11 月 12 月 总计
有效测试天数 X（天） 31 31 30 20 30 31 173
平均每日测试机器数量 Y（个） 25 21 17 15 15 15 18.21
理论测试时长 Z=X*Y*24（小时） 18600 15624 12240 7200 10800 11160 75624
实际测试时长 W（小时） 13971 10040 8860 4000 7404 6429 50704
机器使用率 U=（W/Z）*100 % 75.11 64.26 72.39 55.56 68.56 57.61 67.00

2.4 制定项目任务计划书

本研究通过对客户上报的系统稳定性问题进行分析，找出了客户最为关心的
问题类型。并通过层次分析法，将这些问题的测试场景进行了重要度排序，通过
质量功能展开确定了目前最需要改善的问题，为提高测试手机的使用率。经过对
A 系列产品 2020 下半年的测试数据分析可知，机器最低使用率为每月 55.56%，

23
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

最高的为每月 75.11%, 半年平均使用率为 67%。机器使用率波动较大，急需进行

改善。根据项目实际情况，制定了将测试手机使用率提高到 77%的目标。为了项
目的顺利进行，制定了如表 2-8 所示的基于 DMAIC 的智能手机系统稳定性测试流
程改善项目立项书。该立项书，确定了本项目的负责人，项目前景，项目意义，
主要改善问题，改善目标，项目的范围以及与本项目相关的部门及人员。
表 2-8 基于 DMAIC 的智能手机系统稳定性测试流程改善项目立项书
基于 DMAIC 的智能手机系统稳定性测试流程改善项目立项书
项目名称：智能手机系统稳定性测试流程改善
项目负责人：本论文作者 立项日期：2021 年 1 月 8 日
项目背景： 项目意义：
由于一些人为因素，环境，机器以及测试方法的局 通过提高测试效率，改善测试质量，
限性，当前的测试流程仍面临测试用例执行效率 减少应用端的手机系统稳定性问题流
低，部分机器异常导致自动化测试流程阻塞，测试 入到客户手中，降低客户对产品的不
机器发现问题数量不一致等问题。因此，急需制定 良反馈。
一系列改善措施，改善当前测试流程。

主要改善问题： 改善目标：
经过对 A 系列产品 2020 下半年的测试数据分析可 当前手机的平均使用率由 67%提高到
知，机器最低使用率为每月 55.56%，最高的为每 每半年 77%。
月 75.11%, 平均使用率为 67%。机器使用率波动
较大，急需进行改善。

项目范围： 相关部门及人员：
测试需求获取，刷机，手机预设置，执行测试，收 系统稳定性测试项目组
集问题，发送测试报告等流程。 项目组组长
测试用例及工具开发人员
测试执行人员

预期计划 完成日期 实际日期 评审

定义 2021/1/15 2021/1/15 完成目标
测量 2021/1/22 2021/1/22 完成目标
分析 2021/2/10 2021/2/10 完成目标
改进 2021/4/2 2021/4/2 完成目标
控制 2021/4/16 2021/4/16 完成目标

24
上海交通大学工程管理硕士学位论文 第二章 智能手机系统稳定性测试流程的现状和问题定义

2.5 本章小结

本章首先介绍了当前智能手机系统稳定性测试的测试流程以及当前测试流程
中存在的主要问题。为了更好地应对这些问题，在 DMAIC 改善模型的定义阶段，
从客户上报的系统稳定性问题的主要类型开始分析，找出客户的主要测试场景，
并与内部的测试技术指标相联系，确定急需改善的测试技术指标并对其进行改善。
首先，利用帕累托图分析法找出了客户上报问题中最为重要的 20%的类型。接着，
利用层次分析法，对这类问题的测试场景和测试手段进行重要度排序并通过质量
功能展开图与内部的测试技术特性关联在一起。通过质量屋，找出了内部测试流
程中最为重要的技术特性并以它作为改善目标。最后，结合实际情况和其他团队
的情况，通过制定项目任务计划书的方式，利用三个月左右的时间，完成将当前
手机的平均使用率由 67%提高到 77%左右的改善目标。

25
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

第三章 智能手机系统稳定性测试流程的测量和分析

3.1 智能手机系统稳定性测试流程的关键工序测量

在智能手机系统稳定性测试流程改善的测量阶段，通过 SIPOC 分析，测量系

统分析以及过程能力分析，来对当前测试流程进行测量和初步分析，从而找出当
前测试流程中对测试手机使用率影响最大的工序。

3.1.1 确定关键测试工序

图 3-1 从供应商，输入，过程，输出以及客户等角度对当前的测试流程进行了
分析。在内部测试过程中，测试项目组需要供应商提供测试的手机系统版本和提
供测试的手机设备。一般测试版本，会由公司的版本控制团队定期发布。而测试
手机，则在项目开始前根据测试需求向公司项目管理团队提交订购机器的数量及
类型需求，再由项目管理团队向手机代工厂提交生产任务，当手机代工厂生产完
成后，再发往公司，根据之前提交的订购需求来分配测试手机。因此测试项目组
的供应商主要为公司内部的版本控制团队以及手机代工厂。由此也可知，整个测
试的项目输入主要有两个，手机系统版本和工程测试手机。对于手机系统版本，
主要可以分为两大类。一类是内部使用的包含所有资源的内部版本，另一类是准
备发布给客户的，删除了一些资源的版本。本项目组主要测试的版本，是发布给
客户的版本。而包含了所有资源的版本，一般由别的项目组负责。版本的发布频
率，一般也根据项目的成熟度来决定。一般成熟度较低的项目，版本一般是一天
一个版本。对于成熟度较高的项目，则按每周一到三个版本的频率来测试。而测
试手机，按测试手机类型分，可分为生产调试用的芯片组调试平台和接近商用机
的参考机型。当前项目组的测试一般使用大量的参考机和少量的调试平台。当拿
到测试手机后，一般就会根据版本团队给版本的频率展开测试。整个测试过程包
括，拷贝测试版本，手机刷机和驻网，对手机做一些预设置，执行测试用例，收
集测试日志并上报问题，整理测试报告等。由于版本控制团队在美国总部，生成
的测试版本一般也在美国总部的服务器上，直接用这个地址的版本刷机，耗时很

26
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

长，也极容易刷机失败，因此一般需花费一到两个小时的时间进行版本同步。此
外，在版本生成完以后，还需由印度的同事进行基本功能验证的测试，验证完毕
以后，才会由印度同事发布给中国的测试团队进行测试。而中国与印度有两个半
小时左右的时间差，因此当基本功能测试完成以后，再去做系统稳定性测试时，
一般已经到下午两点左右了。再加上测试版本的拷贝过程，测试开始的时间一般
是下午 4 点左右。如果中间某一个环节出问题，则会导致测试开始时间延长，甚
至加班的情况。当手机测试版本顺利拷贝到本地的服务器上，则开始进行系统稳
定性测试流程。近些年来，通过项目组不断对测试用例的优化和改进，对于传统
的手机刷机，手机预设置，执行测试用例，收集测试日志并上报问题等流程均已
移植到公司的自动化测试系统 Axiom 之上。可通过在 Axiom 上填写测试版本，选
择测试用例和测试机器以后，即可一键测试。此流程减少了人工的参与，也极大
地提高了测试更多机器的能力。但是由于测试版本或者机器不稳定，再加上测试
工具和测试电脑也经常更新或者出问题，大量的测试机器中也总会有少量的问题，
导致部分机器测试结果异常，需要人工时常监测这些机器的测试状态并手动调整。
一般测试开始以后，会测试到下一个测试版本需求的到来，此时才会停止原先的
测试任务，开始下一轮的测试。同时，也会对此轮的测试结果进行统计，主要是
统计所有机器的总测试时间以及发现的系统崩溃数量，来计算 MTBF 的数值。整
理完成以后，即可向项目管理团队，版本控制团队以及版本开发团队发送手机
MTBF 测试报告。版本开发团队，收到的测试报告以后，则会对发现的问题进行
分析，并提交代码改动。而版本控制团队，则会在这些改动确认过以后，合进主
线测试版本之中。项目管理团队，则会根据 MTBF 的指标，来监控整个项目的稳
定性和成熟度，以及能否向客户发布该版本。
经过 SIPOC 分析，可知输入中的手机系统测试版本和工程手机，客户的一些
流程均是由其他团队完成，与本团队的关系不大或者本团队能改善得较少。而过
程中的拷贝测试版本中的流程问题，涉及国外团队的配合以及服务器同步的问题，
该流程短时间内也不太容易解决。收集测试日志并上报问题和整理测试报告，这
部分是已经加进自动化测试用例中并自动执行，只需人工检查即可，也不会也太
多问题。综上可知，主要可能出问题的测试过程是刷机和驻网，手机预设置，执
行测试用例。

27
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

图 3-1 智能手机系统稳定性测试 SIPOC 分析图

Fig.3-1 Smart phone stability test SPIOC diagram

3.1.2 关键测试工序的测量系统分析

根据第二章的分析结果，可知本研究中需要测量手机的使用率。为了得出手
机的使用率，一方面需要测量有效的手机测试时间，另一方面也需要测量出手机
不在测试时，其他过程所需花费的时间。根据 SIPOC 分析图可知，智能手机系统
稳定性测试的关键的三个过程是刷机和驻网，手机预设置，执行测试用例。而这
三个过程目前均已集成到公司内部开发的自动化测试平台 Axiom 之上，目前可以
通过查询历史测试记录来查询每个测试任务的执行时间。为了验证本公司自动化
测试平台 Axiom 统计时间的准确性，本研究特地编写了三个测试时长分别了 10
分钟，30 分钟，60 分钟的测试用例，并集成到 Axiom 上。每个测试用例通过 Axiom
分别在三台电脑上单独运行 10 次，统计每台测试电脑上每个测试用例在 Axiom
系统上的记录时间，统计结果如表 3-1 所示。
将表 3-1 的统计结果，输入 Mini tab 进行量具分析，即可对每台测试电脑上通
过 Axiom 测量统计的测试时间的准确性进行判断。经过 Mini tab 分析，可得到如
图 3-2 和图 3-3 所示的量具分析报告和分析结果。

28
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

表 3-1 Axiom 自动化测试系统测量数据统计表

测试 Axiom 系统记录的时间（分钟）
测试电脑
用例 1 2 3 4 5 6 7 8 9 10
10 分钟 11 11 12 10 11 13 10 12 13 11
aptcn-farm-001 30 分钟 31 33 35 32 30 29 36 31 32 32
60 分钟 58 63 66 65 62 61 60 59 63 65
10 分钟 10 12 12 11 9 12 13 12 11 9
aptcn-farm-002 30 分钟 28 35 32 33 34 32 35 31 29 30
60 分钟 61 58 63 65 62 61 63 64 59 60
10 分钟 12 13 11 10 12 9 8 12 13 11
aptcn-farm-003 30 分钟 30 32 32 31 33 32 34 29 30 32
60 分钟 62 63 62 61 65 66 61 63 62 60

如图 3-2 所示的 Axiom 自动化测试系统的量具分析报告。如变异分量图，一

般希望 Axiom 自动化测试系统的量具间的重复性和再现性变异较小，而不同时长
的测试用例之间的差异较大。如图可知，Axiom 自动化系统对于不同测试时长统
计结果有较大的变异，但是对量具本身的变异较少，分析结果满足预期。对测试
用例的 S 控制图，一般希望测试用例的所有的点都落在控制界限之内，如果一台
测试电脑（操作员）上测量的时间超出界限，则说明这台电脑上统计时间的方法
不准确。如果所有的点都超出界限，则说明 Axiom 统计的时间方法本身不可靠。
如果所有的范围值为 0，则说明 Axiom 自动化测试系统的测量系统的分辨力不可
靠。而下图所示的点均在控制范围以内，说明 Axiom 统计时间的方法是可靠的，
符合预期的。对于测试用例的 X bar 控制图，一般希望测试用例的所有的点都落
在界限范围以外，以确保所有测量的变异均来自不同的测试用例（测试部件）上。
下图所示的点，基本都在界限之外，Axiom 自动化测试系统的量具系统也满足 X
bar 控制图的要求。对于测量值按测试用例比较图，一般希望每个测试用例的各点
十分紧凑，每个测试用例的均值有明显的差异，如下图所示的测量值按测试用例
图，可知该系统满足要求。对于测量值按测试电脑的比较图，一般期望是一条直
线，即所有测试电脑利用 Axiom 系统进行测量时，测量的平均水平是保持一致的，
下图所示的比较图依旧满足要求。最后，测试用例乘测试电脑的交互图，一般期
望是一条平行线，下图满足要求。

29
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

图 3-2 Axiom 自动化测试系统的量具重复性和再现性方差分析报告

Fig.3-2 Axiom automation test system gauge R&R ANOVA report

30
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

图 3-3 Axiom 自动化测量系统量具评估结果

Fig.3-3 Axiom automation test system gauge evaluation result

如图 3-3 所示，经过 Mini tab 分析得到的量具评估结果显示，Axiom 自动化测

试系统的量具总百分比研究变异为 7.46%，可区分的类别数为 18，该两项指标，
均满足可区分的类别数目大于 5 和总百分比研究变异低于 10%的接收标准。综上
可以知，Axiom 自动化测试系统的测量系统是满足测量要求的。可以利用该测量
系统去测量智能手机系统稳定性测试的刷机和驻网，手机预设置，执行测试用例
等三个关键过程。

3.1.3 关键测试工序的过程能力分析

智能手机系统稳定性测试的过程能力，是指智能手机系统稳定性测试过程在
没有外因干预的条件下，每个过程用时的平均情况。因为不可能对整个过程直接
进行测量，因此只能通过测量每个过程的用时来评估每一个过程的能力。本研究
中主要采用过程绩效 K 指数（Process Performance K Ratio, PPK）作为评估每一个
过程的指标。首先，通过 Axiom 的测试记录，收集 A 系列产品工程手机随机的一
次测试任务中，20 台机器的刷机，手机预设置以及执行测试用例的耗时，并形成
如表 3-2 所示的智能手机系统稳定性测试工序关键特性 PPK 测量数据统计表 。将
测量数据代入 Mini tab 进行过程能力分析，得到这三个关键测试工序的过程能力
PPK 指标。再根据 PPK 的指标来判断，每一个测试的过程能力是否充足。

31
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

表 3-2 智能手机系统稳定性测试工序关键特性 PPK 测量数据统计表

测试手机编号 1 2 3 4 5 6 7 8 9 10
刷机（分钟） 7 7 7 6 7 7 7 7 6 7
手机预设置（分钟） 59 58 55 56 60 65 57 63 67 60
执行测试用例（小时） 20 18 15 5 20 21 20 20 19 21
测试手机编号 11 12 13 14 15 16 17 18 19 20
刷机（分钟） 7 7 7 7 7 7 8 7 7 7
手机预设置（分钟） 58 63 57 60 64 68 63 64 66 62
执行测试用例（小时） 20 8 19 12 18 20 20 19 20 18

如图 3-4，其为智能手机系统稳定性测试流程中刷机工序的过程能力分析报
告。通过 Minitab 分析，可知该工序的 PPK 为 1.03，该工序的过程能力较为充足。

图 3-4 智能手机刷机工序的过程能力报告
Fig.3-4 Smart phone image flash process capability report

对刷机工序的数据进一步分析，可以不难看出， 20 台机器中大部分机器刷机
的用时为 7 分钟，只有两台为 6 分钟，一台为 8 分钟，因此机器刷机的过程用时
较为一致。这个主要是因为每台手机所使用的刷机工具与刷的版本都是一样的，

32
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

在正常情况下，每台机器刷机的用时都几乎是一致的，不会有太大差异，因此这
个过程的过程能力较为充足。
如图 3-5，其为智能手机系统稳定性测试流程中手机预设置工序的过程能力分
析报告。通过 Minitab 分析，可知该工序的 PPK 为 0.77，该工序的过程能力不足。

图 3-5 智能手机预设置工序的过程能力报告
Fig.3-5 Smart phone presetting process capability report

手机预设置，主要是为了保证手机在测试时状态正常，通常是设置手机常亮，
手机时间以及无线网络等基本设置，也包括安装测试执行时所需要用到的多媒体
文件和手机应用，以及抓取测日志的相关工具和运行测试用例本身所需要的工具。
这个过程基本持续时间在 60 分钟左右。因为这个过程需要持续与测试手机进行交
互，而测试手机可能对于某些交互的反应时长不一致，甚至因为某些操作失败而
需重复几次，因此导致所有手机在执行这个预设置的时间也就不一致，最终导致
整体过程能不足。虽然每台手机的延迟时间仅为 10 分钟左右，但是实验室每天会
有上百台机器同时测试，即使只有小部分机器出现预设置时间延长的情况，整体
上也会有数个小时的测试时间延迟，进而影响手机整体的使用率。
如图 3-6，其为智能手机系统稳定性测试流程中测试执行工序的过程能力分析
报告。通过 Minitab 分析，可知该工序的 PPK 为 0.18，该工序的过程能力偏低。

33
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

图 3-6 智能手机系统稳定性测试用例执行过程能力报告
Fig.3-6 Smart phone stability test case execution process capability report

测试执行这个工序，从 Mini tab 的分析结果来看 PPK 仅为 0.18，过程能力十

分低下。分析数据可以看出，这 20 台机器的整体测试时长分布并不均匀。最长运
行时间为 20 多个小时，此种机器基本是测试人员手动停止任务才结束测试的机
器。但是有几台机器的测试时长不足 10 个小时，说明这部分机器，在长时间的测
试过程中出现了明显的问题。常见的现象有手机出现离线状态，Axiom 客户端异
常退出，电脑自动重启等。此种特殊情况，因大部分发生在长时间测试之中，且
多发生于测试人员下班以后，无法及时处理，导致这些机器有效的测试时长不多，
进而导致执行测试的过程能力偏低。
综上分析可知，智能手机系统稳定性测试过程中的刷机的过程能力尚可。而
手机预设置过程中，虽然部分手机仅会有 10 分钟左右的超时，但对于上百测试机
器来说，每天仍会有数个小时的超时，造成手机使用率低下的问题，其过程能力
不足的问题需要得到重视。除此之外，目前对手机使用率影响最大的工序为测试
用例执行的测试过程，其过程能力严重不足。

34
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

3.2 智能手机系统稳定性测试流程的影响因子的识别与分析

为了进一步分析手机预设置和手机测试用例执行这两个工序过程能力不足的
深层次原因，在分析阶段，首先利用鱼骨图因果分析法并结合 5M1E，从测试用
例执行人员、测试的机器设备、测试的材料、测试方法、测试环境等方面，找出
这两个工序中影响测试手机手用率的所有潜在原因。

3.2.1 潜在影响因子的识别与分析

如图 3-7 所示，首先召集了项目团队人员进行头脑风暴，利用鱼骨图因果分析
法，将导致手机预设置和手机测试用例执行这两个工序过程能力不足的影响因子
一一列出。

图 3-7 智能手机系统稳定性测试手机使用率过低的因果分析图
Fig.3-7 Smart phone stability test low utilization cause and effect diagram

35
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

其中测量值，环境和材料等相关影响因子分别为 3 个， 3 个和 4 个，总计为
10 个。而方法，人员，机器等相关的影响因子，则分别为 6 个，6 个和 6 个，总
计为 18 个。所有的影响因子为 28 个。为了进一步对这些影响因子进行分析，首
先需要对这些影响因子进行一些基础分析和说明。
如表 3-3 所示，是导致测试手机使用率低下的人员因素分析表。通过因果图分
析可知，测试团队人员共确定了六项可能导致手机预设置和手机测试用例执行这
两个工序过程能力不足的人员影响因子。分别为人与机器分离、巡检不认真、业
务不熟练、责任人不明确、培训不到位、技术水平不足等。第一点，人与机器长
期分离。一般的测试人员的办公室与测试机器所在实验室是不在一起的，测试机
器众多，一般也只是通过远程工具，去远程各个电脑去操作各个测试电脑上的测
试环境。再加上 Axiom 自动化测试系统的使用，所有测试均通过自动工具完成，
不需要人员手动操作。这样一来，测试人员为了方便，就很少去实验室去实际检
查手机测试用例的实际运行情况，就有可能出现，所有远程观察的指标均正常，
但实际机器运行状态异常的现象。因此人与机器长期分离，会造成测试人员不能
实时掌握机器运行状态的现象，从而漏检因自动化程序出错，导致的测试异常。
第二点，巡检不认真。因为实验测试机器众多，摆放位置也比较杂乱，测试人员
即使去实验室巡检，也不会很仔细，很可能会遗漏掉某些机器，造成巡检不认真，
导致异常测试机器未处理的情况。第三点，培训不到位。因为日常的测试任务和
测试用例开发的任务都比较重，组织培训并在一起交流的时间相对较少，因此在
测试人员未被充分培训的情况下，很可能会导致一些自动化测试需要的环境或者
参数使用错误的情况，从而导致测试步骤出错。第四点，责任人不明确。目前，
测试用例开发维护和执行是分开的，一些测试工具也是由其他团队完成的。有些
测试时出现的问题，很难确定责任人，去找到合适的人员解决，从而导致问题不
能及时解决，影响测试进度。第五点，业务不熟练。主要是当前的测试机器多，
测试中使用的工具也较多，测试流程比较复杂，而新员工不能及时掌握这些工具
和测试环境，导致处理一些测试环境相关问题的时候，耗时较长，从而影响整体
测试进度。第六点，则是测试人员技术水平不足。作为一家外企，目前项目组的
所有文档均是英文版本。由于不是中文的，一方面测试人员英文水平不过关，很
可能无法准确理解文档上的所有的步骤并按要求执行，另一方面也可能是文档中
的一些技术操作不熟悉，而导致测试人员未按要求执行，从而引起测试步骤未按
要执行，导致测试异常。综上可知，这六个影响因子均影响手机预设置和手机测

36
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

试用例执行工序的过程能力。
表 3-3 导致测试手机使用率低下的人员因素分析表
编号 影响因子 原因
X1 人与机器分离 远程自动化执行测试，人与机器不需在一起。
X2 巡检不认真 测试机器数量多，摆放位置杂乱，巡检任务重。
X3 培训不到位 测试任务较重，组织培训时间较少。
X4 责任人不明确 测试人员职责较为分散。
X5 业务不熟练 测试流程复杂，不易快速掌握。
X6 技术水平不足 英文文档和部分技术操作不能正确理解。

如表 3-4 所示，是导致测试手机使用率低下的机器因素分析表。通过因果图分
析可知，测试团队人员共确定了六项可能导致手机预设置和手机测试用例执行这
两个工序过程能力不足的机器影响因子。分别为测试电脑卡顿、电脑存储不足、
电脑自动重启、其他电脑故障、手机存储不足、手机黑屏死机等。第一点，测试
电脑卡顿问题。因为是做手机压力测试，所有的测试手机均需要连着电脑进行，
手机测试用例运行多长时间，电脑也就要运行多长时间，因此在对手机进行压力
测试的同时，也相当于在对电脑进行压力测试。目前，所有测试电脑大部分也都
运行两到三年左右的时间，有的时间甚至更长。再加上近些年来，全面自动化测
试，众多自动化工具不停地在电脑上运行，经常会出现电脑卡顿，自动化工具无
法正常运行的情况。第二点，电脑存储不足。目前，所有的测试手机的日志均会
定时地从手机里抓出来放到电脑的硬盘上，再进行分析。但是，压力测试过程平
均每台手机每天会产上百 GB 的日志，此外一个系统崩溃的日志就可以达到 8GB ，
如果出现连续系统崩溃的情况，电脑硬盘很快就会满了，自动化工具检测到电脑
硬盘存储不足，也就会停止测试。第三点，是测试电脑自动重启。这个主要是公
司的 IT 部门，定时对公司所有电脑进行 Windows 升级。因为不清楚升级的计划，
经常会在测试执行的过程中，收到电脑升级的提醒，而测试人员一旦忽略这个提
醒，测试电脑就会定时升级而重启，从而导致整个测试任务中断。第四点，则是
其他的电脑故障。常见的比如，电脑蓝屏，电脑某些文件损坏等。这些故障，基
本会导致自动化测试工具无法正常运行，从而影响整个测试。此外，测试项目众
多，基本所有电脑都在使用中，很少会有电脑作为备份，一旦电脑出现故障去找
IT 部门维修，所消耗的时间也比较长。因此，电脑突发故障，很大程度上会影响
测试的顺利进行。第五点，手机存储不足。目前所有测试手机在测试过程中大概
会有 200GB 左右内存，但是由于测试的时间较长，压力测试产生的测试日志也较

37
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

多，一旦自动化测试脚本没有及时清理测试日志，手机的存储就会存满，从而导
致测试任务停止。第六点，则是比较常见的手机黑屏死机的问题。因为本身就是
系统稳定性测试。在测试过程中，除了比较常见的系统崩溃问题以外，手机黑屏
白屏、无响应也是比较常见的问题。一旦遇到这种问题，一般测试用例也是无法
执行，测试也会立即停止。需要人工检查后，再决定测试是否继续执行，还是保
留现场，让开发分析。
表 3-4 导致测试手机使用率低下的机器因素分析表
编号 影响因子 原因
X7 测试电脑卡顿 测试工具需占用较多系统资源。
X8 电脑存储不足 测试日志过多，测试电脑无法全部处理。
X9 电脑自动重启 公司 IT 部门定期升级测试电脑系统。
X10 其他电脑故障 测试电脑蓝屏，系统文件损坏等问题。
X11 手机存储不足 手机测试日志清理不及时。
X12 手机黑屏死机 测试手机刷机或长时间压力测试，状态异常。

如表 3-5 所示，是导致测试手机使用率低下的材料因素分析表。通过因果图分
析可知，测试团队人员共确定了四项可能导致手机预设置和手机测试用例执行这
两个工序过程能力不足的材料影响因子。分别为 USB 连接断开，电池供电不足，
相机音频不工作，屏幕无响应等。第一点，USB 连接断开。目前，实验室内的所
有测试手机和测试电脑相连接，均是通过 USB 线相连，但是 USB 线属于耗材，
实验室内又没有单独对 USB 线进行管理，经常是发现一根 USB 线出现连接异常
的问题，就把其他的换下来。时间一长，有问题的 USB 线和正常的放在一起，使
用异常 USB 线的概率就会增大。因此，需要对老化损坏的 USB 线进行集中管理。
第二点，电池供电不足。由于是压力测试，手机的电量消耗特别巨大，经常是没
过多久手机就会因电量不足，而自动关机，从而使测试停止。虽然，采购了一批
可以通过 USB 进行充电的设备，但是使用下来，仍然发现部分机器，因为电池供
电不足，使测试停止的现象。第三点，则是相机音频等模块不工作。一方面，是
手机温度等达了某一临界点，触发的手机温度保护，从而使用相机音频等模块不
工作。另一方面，在实际测试过程中，因为长时间的测试使用，也会出现部分模
块损坏的情况，从而导致测试不能正常进行。第四点，手机屏幕无响应。则有可
能是手机屏幕损坏，出现花屏等问题，导致手机屏幕无响应。

38
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

表 3-5 导致测试手机使用率低下的材料因素分析表
编号 影响因子 原因
X13 USB 连接断开 USB 连接线老化。
X14 电池供电不足 手机电池电量过低。
X15 相机音频不工作 手机相机音频等模组损坏。
X16 屏幕无响应 手机屏幕损坏。

如表 3-6 所示，是导致测试手机使用率低下的方法因素分析表。通过因果图分
析可知，测试团队人员共确定了六项可能导致手机预设置和手机测试用例执行这
两个工序过程能力不足的方法影响因子。分别为测试用例未有效执行、测试环境
配置错误、测试用例失败率过高、测试工具识别不到手机、测试工具无法正常启
动、测试工具异常停止。第一点，测试用例未有效执行。项目组在测试过程中有
采用自动化测试工具 Monkey 来做随机测试，但是该工具随机性太大，经常会出
现某台设备长时间测试后，Android 常见的 Tombstone 和 ANR 等应用问题都没有。
对于这些机器，在项目初期或者中期，稳定性问题较多的时候，通常认为测试用
例未有效执行，不计入 MTBF 计算时长中。第二点，测试环境配置错误。当前智
能手机系统稳定性测试的测试环境配置步骤较为复杂，如果没有完善的文档，普
通测试人员很难能一次性配置好完整的测试环境，经常会在测试中遇到各种测试
环境问题。第三点，测试用例失败率过高。这个原因通常是把功能测试的测试用
例直接拿到系统稳定性测试之中，因为系统稳定性的测试时间长，测试中出现的
异常情况也相对较多。如果直接使用功能测试的测试用例，那么因为测试标准较
高，面对一些测试场景，在稳定性测试里可以算通过的，在功能测试里就只能算
失败。第四，五和六点，即测试工具识别不到手机、测试工具无法正常启动和测
试工具异常停止，则是测试工具的问题。由于自动化测工具，随着项目的更新，
也会不断地进行更新，在更新过程中，就会出现各种问题，对工具本身的稳定性，
对多线程的支持等都会有影响。进而产生测试工具识别不到手机、测试工具无法
正常启动和测试工具异常停止等在长时间的自动化测试过程较为常见的工具问
题。

39
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

表 3-6 导致测试手机使用率低下的方法因素分析表
编号 影响因子 原因
测试用例随机性大，部分无效测试机器，不计入
X17 测试用例未有效执行
总测试时长。
X18 测试环境配置错误 测试文档缺失，没有正确配置测试环境。
X19 测试用例失败率过高 测试用例容错能力较差，测试步骤出错率高。
X20 测试工具识别不到手机 测试工具长时间运行后，手机处于离线状态。
X21 测试工具无法正常启动 测试工具升级频繁，升级后常无法正常重启。
X22 测试工具异常停止 测试工具稳定性较差，长时间运行，会自动停止。

如表 3-7 所示，是导致测试手机使用率低下的测量值因素分析表。通过因果图
分析可知，测试团队人员共确定了三项可能导致手机预设置和手机测试用例执行
这两个工序过程能力不足的测量值影响因子。分别为统计的测试时间较少、测试
任务状态显示错误和测试用例失败误报。第一点，统计的测试时间较少。因为本
测试均使用公司开发的 Axiom 智能手机自动化测试平台。一般所有机器的总测试
时长，会通过 Axiom 进行统计。但 Axiom 本身可能不会及时统计出测试用例开始
和结束的时间，从而导致最终统计的测试时间较少的情况出现。第二点，测试任
务状态显示错误，即使测试用例正常运行，测试机器也是正常的，但是 Axiom 显
示的测试任务却是失败状态，自动停止。这种情况，一般是由于 Axiom 对一些环
境问题的容错能力较差，导致测试机器状态检测异常，而自动停测。第三点，是
测试用例失败误报。对于长时间的稳定性测试，如果测试用例的成功或者失败出
现测量错误，对于一些特殊场景，无法正确判断测试用例是否成功运行，那么整
个测试用例的成功率就很低，进而导致智能手机系统稳定性测试异常停止。
表 3-7 导致测试手机使用率低下的测量值因素分析表
编号 影响因子 原因
X23 统计的测试时间较少 测试时间的测量结果不准确。
X24 测试任务状态显示错误 测试任务状态的测量结果不准确。
X25 测试用例失败误报 测试用例执行结果的测量结果不准确。

如表 3-8 所示，是导致测试手机使用率低下的环境因素分析表。通过因果图分
析可知，测试团队人员共确定了三项可能导致手机预设置和手机测试用例执行这
两个工序过程能力不足的环境影响因子。分别为高温，断电和断网。第一点，高

40
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

温。在长时间的压力测试过程中，手机满负荷运行，手机发热较为严重，经常导
致手机表面温度较高。目前的测试手机系统都会有高温保护措施，一旦手机温度
超过某个临界点，手机的性能就会下降或者某些模块就不能正常使用，以防止手
机出现一些安全性的问题。而由于长时间的系统稳定性测试，手机的温度难免出
现过高的情况，这种情况下，手机的测试也会自动停止。第二和第三点，则是物
业的日常对电力设施和网络设施的维护。通常会对整个实验室有半天或者一天的
影响。通常这种情况下整个实验室的测试都会停止。
表 3-8 导致测试手机使用率低下的环境因素分析表
编号 影响因子 原因
X26 高温 压力测试时，手机满负荷运行，手机发热严重。
X27 断电 电力系统定期检修。
X28 断网 网络系统定期检修。

综上可知，以上列出的 28 个影响因子均会对手机预设置和手机测试用例执行
工序的过程能力产生影响，进而影响手机的使用率。虽然有这么多影响因子，但
是根据这些影响因子出现的频率，影响的严重程度以及探测难度等角度分析，这
些影响因子的重要度也并不一样。对于重要度较低的影响因子可暂不改善，对于
重要度较高的影响因子，则需要详细地分析，并制定较为完善的改善方案。

3.2.2 关键影响因子的识别与分析

如表 3-9 所示，为导致测试手机使用率低下的影响因子的失效模式与效果分析
表。表中的故障来源，故障编号，故障模式，以及故障原因，均是在智能手机系
统稳定性测试因果图分析中所对应的影响因子。根据工程测试经验以及历史的测
试记录，对每一项影响因子的严酷度，发生频率，被探测的概率进行打分，每一
项的分数为 1 到 10 分。本研究中主要把风险数 RPN 值大于 90 的作为关键影响因
子，并进行详细的分析和改善。对于 RPN 值低于 90 的影响因子，因其为非关键
影响因子，对测试流程的影响较少，为了节约人力，将更多的精力花费在改善关
键影响因子上，暂不对非关键影响因子进行改善。

41
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

表 3-9 导致测试手机使用率低下的影响因子的失效模式与效果分析表
被 风险
发
严 探 优先
生
故障 故障 故障 酷 测 数
编号 故障原因 频
来源 模式 后果 度 难 RPN(
率
S 度 S*O*
O
D D)
人员 X1 人与机器分离 停测 远程操作即可完成测试 3 1 3 9
人员 X2 巡检不认真 停测 巡检任务重 3 1 5 15
人员 X3 培训不到位 停测 组织培训时间较少 5 1 4 20
人员 X4 责任人不明确 停测 测试人员职责较为分散 3 1 4 12
人员 X5 业务不熟练 停测 测试流程复杂 5 3 6 90
人员 X6 技术水平不足 停测 文档和技术操作不理解 5 1 2 10
工具需占用较多系统资
机器 X7 测试电脑卡顿 停测 3 2 1 6
源
机器 X8 电脑存储不足 停测 测试日志过多 6 3 5 90
机器 X9 电脑自动重启 停测 公司定期升级电脑系统 5 2 5 50
机器 X10 其他电脑故障 停测 蓝屏、系统文件损坏等 6 1 5 30
手机测试日志清理不及
机器 X11 手机存储不足 停测 6 5 4 120
时
刷机和压力测试的过程
机器 X12 手机黑屏死机 停测 6 1 3 18
中概率出现
材料 X13 USB 连接断开 停测 USB 连接线老化 6 1 6 36
材料 X14 电池供电不足 停测 手机电池电量过低 8 3 5 120
手机相机音频等模组损
材料 X15 相机音频不工作 停测 3 1 5 15
坏
材料 X16 屏幕无响应 停测 手机屏幕损坏 5 1 1 5
测试用例随机性大，部
测试用例未有效
方法 X17 停测 分无效测试机器，不计 5 4 6 120
执行
入总测试时长。

42
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

表 3-9 导致测试手机使用率低下的影响因子的失效模式与效果分析表（续）
风
险
发 优
严 被探
生 先
故障 编 故障 故障 酷 测
故障原因 频 数
来源 号 模式 后果 度 难度
率 RP
S D
O N(S
*O*
D)
测试环境配置错
方法 X18 停测 测试文档缺失 6 1 3 18
误
测试用例失败率
方法 X19 停测 测试用例容错能力较差 6 3 3 54
过高
测试工具识别不 测试工具长时间运行
方法 X20 停测 6 3 6 108
到手机 后，手机处于离线状态
测试工具无法正
方法 X21 停测 测试工具升级频繁 3 3 5 45
常启动
测试工具异常停
方法 X22 停测 测试工具稳定性较差 4 4 3 48
止
统计的测试时间 测试时间的测量结果不
测量 X23 停测 5 2 3 30
较少 准确
测试任务状态显 测试任务状态的测量结
测量 X24 停测 2 2 3 12
示错误 果不准确
测试用例失败误 测试用例执行结果的测
测量 X25 停测 4 5 3 60
报 量结果不准确
手机测试压力大，运行
环境 X26 高温 停测 5 4 3 60
负载高，发热严重
环境 X27 断电 停测 电力检修 6 1 1 6
环境 X28 断网 停测 网络检修 6 1 1 6

综上分析可知，这 28 个影响因子中，对手机使用率影响最大的关键影响因子
为 X5, X8, X11, X14, X17, X20。至此本研究的 DMAIC 模型 Y=X5+X8+X11+X14+
X17+X20 正式建立。最后则会着重去分析改善这 6 个影响因子，以达到提高手机
使用率为 77%的目标 Y。

43
上海交通大学工程管理硕士学位论文 第三章 智能手机系统稳定性测试流程的测量和分析

3.3 本章小结

本章主要是对智能手机系统稳定性测试流程的测量和分析，同时完成了
DAMIC 模型的测量和分析阶段。在测量阶段，首先利用 SIPOC 图对测试流程进
行分析，找出了刷机，手机预设置，手机测试执行这三个对手机使用率有影响的
关键工序。利用测量系统分析，对这三个工序的测量系统进行分析。确认完测量
系统准确以后，则开始对这三个工序进行测量并进行过程能力分析。最终，通过
过程能力分析，得知手机预设置和手机测试执行这两个工序的过程力不足。则开
始在分析阶段，对导致这两个工序过程能力较低的影响因子进行分析。通过因果
图、5MIE 和 FMEA，得到了 28 个潜在影响因子和 6 个关键的影响因子。至此本
研究的 DMAIC 模型 Y=X5+X8+X11+X14+ X17+X20 正式建立。最后则会着重去
改善这 6 个影响因子，以达到提高手机使用率为 77%的改善目标。

44
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

第四章 智能手机系统稳定性测试流程的改善与控制

4.1 智能手机系统稳定性测试流程的初步改善

4.1.1 快赢改善措施

本研究中主要通过快赢措施来进行初步改善。对于其改善的影响因子，需要
同时满足五个基本条件。第一，制定的智能手机系统稳定性测试改善措施要能快
速实施。第二，制定的智能手机系统稳定性测试改善措施也要能很容易的实现。
第三，制定的智能手机系统稳定性测试改善措施的成本要比较低。第四，制定的
智能手机系统稳定性测试改善措施的结果可能有效。第五，整个改善过程要能恢
复到改善之前的样子。
根据上述原则，本文对上文中发现的 28 个影响因子进行分析改善并绘制如表
4-1 所示的智能手机系统稳定性测试流程的初步改善表。首先，分析风险优先数大
于 90 的关键影响因子。关键影响因子 X11 手机存储不足的问题，是由于稳定性测
试时间较少，测试日志较多，可通过自动化脚本定时清理的方式快速解决。关键
影响因子 X14 电池供电不足的问题，可通过采购模拟电池电路板、可充电 USB
HUB 等新设备来快速改善。关键影响因子 X20 测试工具识别不到手机的问题，这
个是稳定性测试中较为常见的问题，和测试工具、测试手机、测试电脑的稳定性
都有很大关系，目前没有特别合适的方法对其改善，只能通过合理地安排巡检频
率来尽早发现问题并解决。关键影响因子 X17 测试用例未有效执行，主要是当前
采用的 Monkey 测试用例，随机性过大，在大规模机器测试中，较易出现部分无
效测试的机器，因此需要优化该测试用例，本研究中，通过 DOE 实验设计对
Monkey 的常用测试参数进行分析，找出最为合适的 Monkey 随机测试参数，来对
智能手机系统稳定性随机测试用例进行优化。关键影响因子 X5 业务不熟练的问
题，可通过加强新人业务培训，并在培训后进行业务考核，以检验培训效果，确
保新人可以熟练掌握测试业务。关键影响因子 X8 电脑存储不足，则可以通过采
购大容量硬盘快速改善。最后，对于其他风险优先数小于 90 的影响因子，因其为

45
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

非关键影响因子，对测试流程的影响较少，为了节约人力，将更多的精力花费在
改善关键影响因子上，本研究暂不对非关键影响因子进行改善。
表 4-1 智能手机系统稳定性测试流程的初步改善表
编号 影响因子 风险优先数 快赢改善措施
X11 手机存储不足 120 自动化脚本定时清除测试日志
X14 电池供电不足 120 模拟电池电路板、可充电 USB HUB 供电
X17 测试用例未有效执行 120 需进一步优化测试参数
X20 测试工具识别不到手机 108 可通过巡检尽早处理问题
X5 业务不熟练 90 加强新人业务培训
X8 电脑存储不足 90 采购大容量硬盘
X25 测试用例失败误报 60 非关键影响因子，暂不改善
X26 高温 60 非关键影响因子，暂不改善
X19 测试用例失败率过高 54 非关键影响因子，暂不改善
X9 电脑自动重启 50 非关键影响因子，暂不改善
X22 测试工具异常停止 48 非关键影响因子，暂不改善
X21 测试工具无法正常启动 45 非关键影响因子，暂不改善
X13 USB 连接断开 36 非关键影响因子，暂不改善
X10 其他电脑故障 30 非关键影响因子，暂不改善
X23 统计的测试时间较少 30 非关键影响因子，暂不改善
X3 培训不到位 20 非关键影响因子，暂不改善
X12 手机黑屏死机 18 非关键影响因子，暂不改善
X18 测试环境配置错误 18 非关键影响因子，暂不改善
X2 巡检不认真 15 非关键影响因子，暂不改善
X15 相机音频不工作 15 非关键影响因子，暂不改善
X4 责任人不明确 12 非关键影响因子，暂不改善
X24 测试任务状态显示错误 12 非关键影响因子，暂不改善
X6 技术水平不足 10 非关键影响因子，暂不改善
X1 人与机器分离 9 非关键影响因子，暂不改善
X7 测试电脑卡顿 6 非关键影响因子，暂不改善
X27 断电 6 非关键影响因子，暂不改善
X28 断网 6 非关键影响因子，暂不改善
X16 屏幕无响应 5 非关键影响因子，暂不改善

46
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

4.1.2 快赢改善措施的效果评估

经上文分析可知，除关键影响因子 X17 外，其余关键影响因子，均可通过快

赢措施进行快速改善。快赢改善措施可以分为两大类。一类是提高手机停测的故
障处理效率，如巡检和培训等改善措施。另一类是，降低手机停测的故障发生频
率，如采用自动化脚本和采购新设备等改善措施。该两类方法理论上均可对当前
的测试流程进行改善，并提高测试手机的使用率。为了验证上述快赢措施的改善
效果，在上述改善措施落实到所有项目执行之后，通过相关测试数据统计分析，
评估快赢改善措施是否有效。
(1) 手机停测的故障处理效率评估
为了对测试执行人员处理停测问题的效率进行评估，本研究通过收集三名不
同测试人员分别负责的三个不同测试项目的测试日志，找出这三个项目在改善前
和改善后一周内的测试过程中，在手机刷机和预设置工序出现的手机停测问题的
次数以及其对应的恢复正常状态所用时间。该工序在测试刚开始两个小时内可以
完成，这时会刚开始第一轮巡检，可以认为在其出现问题后，测试人员可以马上
发现问题并着手解决，因巡检时间间隔过长而导致的额外用时的影响可以不考虑。
改善前，经数据统计，三个项目在 2021 年 1 月份第一周内，共使用了 37 台
机器和执行了 10 次测试需求。A 项目使用 12 台机器，测试了 5 个版本。B 项目
使用了 15 台机器，测试了 3 个版本。C 项目使用了 10 台机器，测试了 2 个版本。
上述项目，一周内，刷机和预设置工序出现 31 次停测问题，停测问题处理用时统
计表，如表 4-2 所示。智能手机系统稳定性测试停测问题处理用时控制图，如图
4-1 所示。通过统计表和控制图，可知在改善前，测试执行人员处理一次手机停测
问题平均用时为 30.2 分钟。而且第 10 组数据超过了控制线，说明改善前手机停
测问题处理的时间并不稳定。
表 4-2 改善前手机停测问题处理时间统计表
编号 1 2 3 4 5 6 7 8 9 10 11 12
停测处理时间（分钟） 19 28 15 28 8 16 32 21 25 98 12 15
编号 13 14 15 16 17 18 19 20 21 22 23 24
停测处理时间（分钟） 53 25 63 56 12 45 8 23 24 53 14 15
编号 25 26 27 28 29 30 31 32 33 34 35 36
停测处理时间（分钟） 14 52 9 50 52 25 26 / / / / /

47
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

分钟

图 4-1 改善前手机停测问题处理时间的单值控制图
Fig.4-1 Single value control chart for processing time of test suspension before improvement

改善后，经数据统计，三个项目在 2021 年 4 月份第一周内，共使用了 37 台

机器和执行了 9 次测试需求。A 项目使用 12 台机器，测试了 4 个版本。B 项目使
用了 15 台机器，测试了 3 个版本。C 项目使用了 10 台机器，测试了 2 个版本。
上述项目，一周内，刷机和预设置工序出现 22 次停测问题，其停测问题处理用时
统计表，如表 4-3 所示。智能手机系统稳定性测试停测问题处理用时控制图，如
图 4-2 所示。通过统计表和控制图，可知在改善后，测试执行人员处理一次手机
停测问题平均用时为 24.95 分钟。
表 4-3 改善后手机停测问题处理时间统计表
编号 1 2 3 4 5 6 7 8 9 10 11 12
停测处理时间（分钟） 35 15 47 26 25 8 21 13 9 26 31 54
编号 13 14 15 16 17 18 19 20 21 22 23 24
停测处理时间（分钟） 21 36 9 7 45 19 25 36 26 15 / /

48
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

分钟

图 4-2 改善后手机停测问题处理时间的单值控制图
Fig.4-2 Single value control chart for processing time of test suspension after improvement

综上所述，可知改善后，智能手机系统稳定性测试的停测问题的处理时长得
到了一定改善。从改善前平均用时 30.2 分钟，到改善后平均使时 24.95 分钟，改
善后相对于改善前，手机停测问题处理用时减少了 5.25 分钟，停测问题的处理时
长也更加稳定。因此，可以得出结论，本文研究所提出的巡检、培训等改善措施
等快赢改善措施，可以提高测试执行人员处理机器停测问题的效率。
(2) 手机停测的故障发生频率评估
为了对手机停测问题出现的频率进行评估，本文在上文收集到三名不同测试
人员分别负责的三个不同测试项目的测试日志的基础上，找出这三个项目在改善
前和改善后一周内的测试过程中，测试执行工序中手机停测的比例。该工序通常
在测试人员下班以后开始，一直执行到新测试需求到来才停止。因为该工序持续
时间较长，测试巡检间隔时间较长，很难及时发现这些停测问题并进行处理，可
认为其一旦停测，后面就没有机会恢复正常状态。本文通过统计每次测试执行工
序中手机停测的比例，来评估快赢改善措施执行后，手机停测问题的出现频率是
否得到改善。

49
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

由前文可知，改善前，三个项目在 2021 年 1 月份第一周内，共使用了 37 台

机器和执行了 10 次测试需求。A 项目使用 12 台机器，测试了 5 个版本。B 项目
使用了 15 台机器，测试了 3 个版本。C 项目使用了 10 台机器，测试了 2 个版本。
这些项目，一周内的手机停测比例，如表 4-4 所示。其手机停测比例控制图，如
图 4-3 所示。通过统计表和控制图，可知在改善前的 10 次测试需求中，手机平均
停测比例为 42.3%，所有的点都在控制线之内，没有明显的趋势，手机停测比例
较为稳定。
表 4-4 改善前手机停测比例统计表
编号 1 2 3 4 5 6 7 8 9 10
手机总数量 12 12 12 12 12 15 15 15 10 10
手机停测数量 5 7 3 5 6 8 3 5 6 4
手机停测百分比 0.42 0.58 0.25 0.42 0.50 0.53 0.20 0.33 0.60 0.40

百分比

图 4-3 改善前手机停测比例的单值控制图
Fig.4-3 Single value control chart for proportion of test suspension before improvement

由前文可知，改善后，三个项目在 2021 年 4 月份第一周内，共使用了 37 台

机器和执行了 9 次测试需求。A 项目使用 12 台机器，测试了 4 个版本。B 项目使

50
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

用了 15 台机器，测试了 3 个版本。C 项目使用了 10 台机器，测试了 2 个版本。

这些项目，一周内的手机停测比例，如表 4-5 所示。其手机停测比例控制图，如
图 4-4 所示。通过统计表和控制图，可知在改善后的 9 次测试需求中，手机平均
停测比例为 36.89%，所有的点都在控制线之内，没有明显的趋势，手机停测比例
较为稳定。
表 4-5 改善后手机停测比例统计表
编号 1 2 3 4 5 6 7 8 9
手机总数量 12 12 12 12 15 15 15 10 10
手机停测数量 4 5 6 4 3 7 4 3 5
手机停测百分比 0.33 0.42 0.50 0.33 0.20 0.47 0.27 0.30 0.50

百分比

图 4-4 改善后手机停测比例的单值控制图
Fig.4-4 Single value control chart for proportion of test suspension after improvement

综上所述，可知改善后，手机停测问题出现的频率得到了一定改善。从改善
前平均 42.3%，到改善后平均 36.89%，改善后相对于改善前，手机停测比例减少
了 5.41%。因此，可以得出结论，本研究所提出的采用自动化脚本，采购新设备
等改善措施，可以减少手机停测问题出现的频率。

51
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

4.2 智能手机系统稳定性测试流程的深度改善

4.2.1 DOE 实验设计改善

关键影响因子 X17 测试用例未有效执行，主要是因为 Monkey 测试工具随机

性大，部分机器经常会出现如 Android 常见的 Tombstone 和 ANR 等应用相关的稳
定性问题都没有被发现的情况。对于这部分测试机器，在项目初期或者中期，稳
定性问题较多的时候，通常认为测试用例未有效执行，也不计入总测试时长。因
此为了提高测试效率，减少无效测试机器的数量，本研究中利用 DOE 实验来确定
合适的 Monkey 测试参数。
(1) 设计 DOE 全因子实验
首先，本研究设计了如表 4-6 所示的 DOE 全因子实验设计可控因子水平表，
来进行实验设计。通过进行实验，来找出最佳的 Monkey 测试命令中随机事件总
数、每个随机事件间隔参数的数值和最佳的测试应用数量。至于 Monkey 测试的
其他参数，由工程经验判断，其对智能手机系统稳定性测试影响较小，故不在本
研究中深入分析。
表 4-6 全因子实验设计可控因子水平表
因子 A B C
水平 事件总数（个） 事件间隔（ms） 测试应用数量（个）
-1 100 300 30
0 550 550 60
1 1000 800 90

得到上述可控因子水平表后，在 Minitab 中选全因子实验设计，中心点重复 2

次，即可生成全因子实验设计表，如表 4-7 所示。按照 DOE 全因子实验设计表确
定每组实验的 Monkey 测试参数以及对应的手机应用数量以后，即开始进行实验。
本实验中，采用 10 台手机同时进行 10 个小时左右的系统稳定性测试，这 10 台测
试手机除了 Monkey 的测试参数和对应的手机应用数量不同之外，其余的条件均
相同。测试结束以后，统计每台手机上发现的安卓 Tombstone，ANR 问题数量，
并记录。如果测试过程中发现系统崩溃，则一次系统崩溃算作 10 个安卓 Tombstone
或 ANR 问题。最终将测试结果记录在表 4-7 所示的稳定性问题数量一栏，作为输
出响应。

52
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

表 4-7 全因子实验设计表
运行序 1 2 3 4 5 6 7 8 9 10
事件总数 100 1000 1000 1000 100 100 550 100 550 1000
事件间隔 300 800 800 300 300 800 550 800 550 300
测试应用数量 90 30 90 30 30 30 60 90 60 90
稳定性问题数量 12 9 10 25 3 1 9 8 8 38

(2) 拟合实验数据的数学模型
其次，将上述实验结果代出 Minitab 进行因子设计分析，拟合实验数据的数学
模型，得到表 4-8 和图 4-5 所示的分析结果。
表 4-8 第一次拟合模型的方差分析表
来源 自由度 Adj SS Adj MS F 值 P 值
模型 8 1099.6 137.45 274.9 0.047
线性 3 845.5 281.833 563.67 0.031
事件总数 1 420.5 420.5 841 0.022
事件间隔 1 312.5 312.5 625 0.025
测试应用数量 1 112.5 112.5 225 0.042
2 因子交互作用 3 205.5 68.5 137 0.063
事件总数*事件间隔 1 180.5 180.5 361 0.033
事件总数*测试应用数量 1 0.5 0.5 1 0.5
事件间隔*测试应用数量 1 24.5 24.5 49 0.09
3 因子交互作用 1 12.5 12.5 25 0.126
事件总数*事件间隔*测试
1 12.5 12.5 25 0.126
应用数量
弯曲 1 36.1 36.1 72.2 0.075
误差 1 0.5 0.5
合计 9 1100.1
S R-sq R-sq（调整） R-sq（预测）
模型汇总
0.70710 99.95% 99.59% *

由表 4-8 方差分析表可知，模型 P 值为 0.047，小于 0.05，结果是显著的，说

明模型总的效果可接受。此外，弯曲项 P 值为 0.075，大于 0.05，结果是不显著的，
说明模型拟合的稳定性问题的数量没有明显的弯曲趋势，符合预期。R-sq 和 R-sq
（调整）的值分别为 99.95%和 99.59%，该值较为接近，说明模型拟合效果较好。

53
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

结合表 4-8 与图 4-5 所示的帕累托效应图，可知 A、B、AB 和 C 为显著因子，

即 P 值小于 0.05 的事件总数、事件间隔、事件总数与事件间隔和测试应用数量因
子为显著影响因子，其他各项为不显著影响因子。说明此模型可以较好地拟合预
期的显著影响因子。

图 4-5 第一次拟合模型的累托效应图
Fig.4-5 Pareto factor graph of the first fitting model

为了更好地拟合实验数据，本研究中把上文分析得到的初步模型中不显著的
项 BC、ABC 和 AC 项移除，再重新拟合模型，得到了图 4-6 和图 4-7 所示的新的
分析结果。图 4-6 第二次拟合得到的帕累托效应图只保留了显著影响因子，已经
满足需求。
进一步分析图 4-7 第二次拟合得到的四合一残差图，可以发现左上角的残差正
态概率图和左下角的残差正态直方图已经满足了正态分布，右上角的残差与拟合
值图也没有出现“漏斗型”或“喇叭型”这种非等方差现象，右下角的残差与顺
序图的各点也都散落在水平方向上无规则的上下随机波动。综上所述，可知第二
次拟合的模型已经满足了残差均值为零，正态性，方差齐性和独立性这四个特性，
拟合的模型十分可靠。

54
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

图 4-6 第二次拟合模型的帕累托效应图
Fig.4-6 Pareto factor graph of the second fitting model

图 4-7 第二次拟合模型的四合一残差图
Fig.4-7 Four in one residual graph of the second fitting model

55
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

(3) 分析实验结果
最后，在得到了可靠的拟合模型后本研究利用 Minitab 分析该模型的主效应和
交互作用，以及最佳的响应参数，最终得到图 4-8、图 4-9 和图 4-10 所示的分析
结果。
从图 4-8 因子主效应图上可以看出，因子 A 事件总数为 1000 个，因子 B 事件
时间间隔数为 300ms，因子 C 测试应用数量为 90 个时可以获得最大的均值响应，
即可以发现最多的稳定性问题。
从图 4-9 因子间的交互作用图可以发现，事件总数与事件间隔的效应线不平
行，说明这两个因子存在交互作用。
从图 4-10 响应优化器的最佳参数组合的分析结果来看，最佳测试参数为事件
总数为 1000 个，事件时间间隔数为 300ms，测试应用数量为 90。
由上述实验结果可以得出结论：Monkey 测试在选择如下参数时，可以发现最
多的稳定性问题数量。即事件总数=1000 个，事件时间间隔数=300ms，测试应用
数量=90。

图 4-8 各因子的主效应图
Fig.4-8 The main effect picture of each factor

56
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

图 4-9 因子间的交互作用图
Fig.4-9 The interaction diagram of each factor

优化 事件总数 事件间隔 测试应用数量

D: 0.9257 1000 800 90
1000 300 90
100 300 30

稳定性问题
数量最大值

y=35.25
d=0.92568

图 4-10 响应优化器的最佳参数组合
Fig.4-10 The best optimized parameter of response optimizer

57
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

4.2.2 DOE 实验设计改善的效果评估

为了验证上述测试参数可以有效地减少无效测试机器数量，本研究在实际测
试过程中分别选取 10 台测试机器运行不同的测试参数，在同一个项目上连续测试
10 个版本，观察无效测试机器比例。其中 A 组 10 台机器，选取实验得到的最佳
测试参数进行测试，即事件总数=1000 个，事件时间间隔数=300ms，测试应用数
量=90。B 组 10 台机器，则保留原先的测试逻辑继续测试，即脚本里随机选择测
试参数，事件总数随机选择 1000，500 和 100，事件间隔随机选择 800，500 和 300。
测试应用随机选择 90，60 和 30。最终得到如表 4-9、表 4-10、图 4-11 和图 4-12
所示的结果。
A 组实验结果为表 4-9 和图 4-11 所示的统计表和单值图。可以看出，使用改
善后的 Monkey 参数进行测试后，每次依然有至少一台机器会出现无效测试的情
况，但是一次出现 3 台无效测试的情况，只有一次。平均出现无效测试机器的比
例为 14%
B 组实验结果为表 4-10 和图 4-12 所示的统计表和单值图。可以看出，使用原
先的 Monkey 测试参数，有一半的测试版本中出现了至少 2 台无效测试机器的情
况，说明整体无效测试机器的数量要多于 A 组。由单值图可以看出 B 组实验中，
平均出现无效测试机器的比例为 19%。
由上述实验结果，可以看出使用了优化后的参数进行测试的机器，平均无效
测试的机器数量要少于原测试参数的机器数量。由此可以得出结论，经 DOE 实验
设计，无效测试机器比例由 19%降低到 14%， 降低了 5%。
表 4-9 A 组实验无效测试机器统计表
编号 1 2 3 4 5 6 7 8 9 10
总机器数量 10 10 10 10 10 10 10 10 10 10
无效测试机器数量 2 1 1 1 1 3 1 2 1 1
无效测试机器百分比 0.20 0.10 0.10 0.10 0.10 0.30 0.10 0.20 0.10 0.10

表 4-10 B 组实验无效测试机器统计表
编号 1 2 3 4 5 6 7 8 9 10
总机器数量 10 10 10 10 10 10 10 10 10 10
无效测试机器数量 1 3 2 2 1 2 2 3 1 2
无效测试机器百分比 0.10 0.30 0.20 0.20 0.10 0.20 0.20 0.30 0.10 0.20

58
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

百分比

图 4-11 A 组实验结果的单值控制图
Fig.4-11 Single value control chart for experiment A

百分比

图 4-12 B 组实验结果的单值控制图
Fig.4-12 Single value control chart for experiment B

59
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

4.3 智能手机系统稳定性测试流程的改善效果评估

4.3.1 手机使用率的理论改善效果评估

由工程经验可知，手机使用率主要与理论测试时长和实际测试时长有关。其
中理论测试时长，在智能手机系统稳定性测试中，一般认为从拿到测试机器开始
到项目结束，测试机器都应该在不停地测试，中间不会暂停，以保证手机系统稳
定性进行了足够时长的测试。而实际测试时长，则与手机停测的故障发生频率、
手机停测的故障处理效率以及无效测试的机器比例有关。综上所述，可以得到如
下经验公式：
T1=D*t (4.1)
式中，T1 为理论测试时长，D 为测试机器总数量，t 为项目周期
T2=D*t-D*P1*t-D*P2*t(1-R) (4.2)
式中，T2 为实际测试时长，D 和 t 同公式 4-1 所表示的值，P1 为无效测试的
机器比例，即从项目开始测试到项目结束，机器没有停测过且一个稳定性相关问
题也没有出现过的机器比例；P2 为停测机器的比例，即测试过程因各种故障导致
手机出现至少一次停测情况；R 为停测手机的使用率，即停测手机所进行的有效
测试时长与其对应的项目理论测试时长的比值。这里不考虑停测手机中在测试过
程中没有发现稳定性问题的情况，即停测手机在停测前，均假设是在进行有效测
试的机器。
由公式 4.1 和公式 4.2，即可推出手机的使用率公式：
U = T2/T1=1-P1-P2*(1-R) (4.3)
式中，U 为手机使用率，T2, T1, P1, P2, R 均为上文所表示的量。
由前文可知，改善前后手机的平均停测比例分别为 42.3%和 36.89%，改善前
后无效测试机器比例分别为 19%和 14%，代入公式 4.3，即可得到如下改善前后的
手机使用率计算公式：
U1=1-19%-42.3%*(1- R1)=0.81-0.423*(1-R1) （4.4）
式中，U1 为改善前的手机使用率，R1 为改善前的停测手机使用率。
U2=1-14%-36.89%*(1-R2)=0.86-0.3689(1-R2) （4.5）
式中，U2 为改善后的手机使用率，R2 为改善后的停测手机使用率。
由公式 4.4 和公式 4.5 可得到如下手机使用率增长量公式：

60
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

U3=U2-U1=0.86-0.3689*r2-(0.81-0.423*r1)
=0.05+0.423*r1-0.368*r2 （4.6）
式中 U3 为手机使用率增长量，r1 为改善前手机停测系数 1-R1，r2 为改善后
手机的停测系数 1-R2。
由前文手机停测的故障处理效率评估可知，改善后测试执行人员处理机器停
测问题的效率得到提升，因此可以推出 0<R1<R2, 即 0<r1<1, 0<r2<1 且 r1>r2。为
了得到 r1, r2 的具体数值，本研究中，根据测试日志，选取改善前后各 10 次停测
记录，记录其实际测试时长与理论测试时长，计算其停测手机的使用率，最终绘
制出如表 4-11 和表 4-12 所示的改善前后的停测手机使用率统计表。由统计结果可
知，r1=1-0.6=0.4, r2=1-0.74=0.26。代入公式 4.4、公式 4.5 和公式 4.6 可得，
U1=0.64,
U2=0.76, U3=0.12, 综上可知，理论上改善前手机使用率为 64%，此理论计算结果
与实际测量值 67%基本一致，表明理论计算结果是可靠的。此外，改善后手机使
用率为 76%，改善后手机使用率增长了 12%。表明改善后，智能手机系统稳定性
测试中测试手机的使用率达到了设立的改善目标。
表 4-11 改善前停测手机使用率 R1 统计表
总
次数 1 2 3 4 5 6 7 8 9 10
计
实际测试时长 2 22 18 15 8 19 18 20 21 1 144
理论测试时长 24 24 24 24 24 24 24 24 24 24 240
手机使用率 0.08 0.92 0.75 0.63 0.33 0.79 0.75 0.83 0.88 0.04 0.60

表 4-12 改善后停测手机使用率 R2 统计表

总
次数 1 2 3 4 5 6 7 8 9 10
计
实际测试时长 20 18 20 19 21 13 16 20 18 12 177
理论测试时长 24 24 24 24 24 24 24 24 24 24 240
手机使用率 0.83 0.75 0.83 0.79 0.88 0.54 0.67 0.83 0.75 0.50 0.74

4.3.2 手机使用率的实际改善效果评估

经过理论计算可知，改善后手机使用率可以达到设定的改善目标。进一步在 A
系列产品进行深度验证。通过将改善措施全部应用在 A 系列产品上，连续运行一

61
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

个月。统计这一个月的 A 系列产品的手机使用率是否能达到改善目标。经过数据
统计，发现这一个月的 A 系列产品的手机平均使用率已达到 78.16%，已经满足了
设立的 77%的改善目标。具体数据，如下图 4-13 和表 4-13 所示。在 A 系列产品
升级项目中，一共使用了 15 台手机，其中最低的使用率为 53.06%，最高的可达
的 98.63%，平均使用率为 78.16%。由上述结果可知，手机使用率的实际改善效果
已经达到在问题定义阶段设定的改善目标，即手机使用率由 67%增长到 77%。
表 4-13 2021 年 4 月 A 系列产品的测试手机使用率统计表
设备号 Dev1 Dev2 Dev3 Dev4 Dev5 Dev6 Dev7 Dev8
使用率 66.45% 53.06% 98.28% 98.63% 85.03% 97.71% 63.56% 98.46%
设备号 Dev9 Dev10 Dev11 Dev12 Dev13 Dev14 Dev15 /
使用率 76.48% 75.28% 62.97% 84.87% 85.06% 63.57% 62.95% /

百分比

设备号

图 4-13 2021 年 4 月 A 系列产品的测试手机使用率单值图

Fig.4-13 2021.4 Product A device utilization single value chart

4.4 智能手机系统稳定性测试流程的控制措施

在通过快赢措施和 DOE 实验设计等提出了的改善措施以后，还需要通过一些

62
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

控制手段，来确保这些改善措施，在以后的测试过程中可以得到有效的执行，如
果发现新问题，也可以重新启用新一轮的 DMAIC 循环继续改善。为了确保本研
究所提出的改善措施的顺利实施，本研究通过制定标准化作业书来将所有的改善
经验固化下来。
为了固化改善措施，将改善措施以标准化标化作业书的形式的保留下来，本
研究中将测试执行人员所需要关注的改善措施以表 4-5 智能手机系统稳定性测试
标准化作业书的形式确定下来，方便测试执行员按照标准化作业的形式执行测试，
避免在测试过程因没有遵守标准作业而导致的各种测试问题。此外，如果测试执
行人员在测试执行过程中，如发现该标准化作业书仍存在不足，在后续的改善过
程中的，依旧可以对此标准化作业书进行更新。
表 4-14 所示的标准作业书，主要是针对通过 DMAIC 改善后的高通公司智能
手机系统稳定性项目组的测试流程制定的。该标准作业书的主要目标是确保制定
的改善措施可长久有效地落实，从而保证测试效率和质量，确保测试手机使用率
不低于 77%。该标准作业书，主要从作业条件，作业流程以及作业标准及方法等
三个方面，对改善后的测试流程进行固化。
作业条件主要是包含五个方面。第一点是人员方面，主要包括测试用例和工
具开发人员以及测试执行人员。当前项目组的测试基本实现了全自动化测试流程，
而这一自动化测试流程主要是依靠测试用例和工具开发人员来实现的。需要测试
用例和工具开发人员对当前的测试流程和所使用的工具十分熟悉，并把所有的流
程通过代码的形式的串联起来，保证整个自动化测试流程尽可能地稳定长时间地
运行，进而高效率高质量地进行测试，发现更多的手机系统稳定性相关的问题。
基于这种现状，就需要对测试用例和工具开发人员提供更高更严格的要求。其主
要职责包括：需熟练掌握 DOE 实验设计等理论工具并运用到测试用例和工具的开
发工作之中，需熟练掌握代码审查及文档管理工具并加强测试用例审查和文档管
理工作，需对测试执行人员进行相关测试用例和工具的使用培训，确保相关人员
正确掌握相关测试用例和工具的使用方法。而测试执行人员，更多的负责具体项
目的执行工作。虽然只是执行工作，但是由于测试机器数量较多，测试版本切换
频率高等原因，也需要测试执行人员能够熟练地掌握当前自动化测试流程，能对
自动化测试流程中出现的问题快速反应解决，对一些不合理的流程设计或者测试
用例设计也要能及时发现并反馈给测试用例和工具开发人员，协助测试用例和工
具开发人员共同优化当前的测试流程。因此，测试执行人员需熟练掌握项目组开
发的测试用例和工具的使用方法。对于新员工，需作入职报告，报告通过后，方

63
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

可进行具体测试工作。第二点机器方面，主要是测试电脑和测试手机。因为是进
行长时间的手机系统稳定性测试，测试期间会产生大量的测试日志。一般这些日
志会先存储在手机里，在定时转移到电脑上进行分析。通常一个晚上会有几十 GB
的测试日志产生，如果项目初期，手机系统稳定性问题较多时，甚至有可能达到
上百 GB 的测试日志。因此，在保证能定时将手机存储日志转移的同时，也要确
保测试电脑和测试手机存储能满足手机系统稳定性测试日志存储的要求，电脑一
般选取 1TB 硬盘，手机存储需大于 100GB。第三点材料方面，主要包括测试所使
用 USB 等耗材，测试手机自身功能模块以及供电设备。这些设备需定期检测，对
于损坏的，不能正常工作的，需及时更换。第四点方法方面，要保证测试用例，
运行环境，工具均需正常稳定工作，要加强实验室和测试设备的巡检。第五点测
量值方面，需确保手机测试用例正常测试，测试任务正常执行，确保测试报告上
统计的测试时间，真实反映的测试有效时长。第六点，环境方面，需确保实验室
电力，网络及温度等正常。如遇电力或者网络检修，需及时通知各项目负责人，
合理安排测试进度。
智能手机系统稳定性测试作业流程主要包括五个步骤。首先，当接收到测试
需求以后，需及时从国外的服务器上拷贝测试版本，通常需要花费两个小时左右。
此时，可以同步的去检查所有的测试设备状态是否正常，能否开始下一轮的测试，
对于有问题的测试设备及时检修并恢复。当版本拷贝完成，即可通过 Axiom 网页
填写测试版本信息，选择测试用例及测试机器来创建测试任务。测试任务创建完
成后，则需要定时去实验室巡检，观察测试是否正常执行。对于出现问题的机器，
可以手动利用一些工具灵活处理，并恢复中断的自动化测试。测试结束以后，收
集测试上报的系统稳定性问题和统计所有机器的总测试时长，计算 MTBF，汇总
后发送测试报告即完成当前一轮的测试。
作业标准及方法主要包括拷贝测试版本，刷机，手机预设置，执行测试用例，
收集测试日志并上报问题，整理并发送测试报告。其中刷机，手机预设置，执行
测试用例，收集测试日志并上报问题均已集成到 Axiom 自动化测试系统里，对于
测试执行人员来说，更多的是监控自动化测试系统有没有完成这些预先设计好的
流程，如果没有则需要测试执行人员手工干预自动化测试流程。拷贝测试版本涉
及从国外服务器同步的问题，其中需使用专用网络有一定的时间要求，测试执行
人员需合理掌握控制该部分时间。如果所有流程均无问题，则可以正常整理发送
MTBF 测试报告。

64
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

表 4-14 智能手机系统稳定性测试标准作业书
智能手机系统稳定性测试标准作业书
发文部门 手机应用端系统稳定性测试组 文件编号 001
生效日期 2021/4/16 页码 第 1 页/共 2 页
目标 保证测试效率和质量，确保测试手机使用率不低于 77%
项目 作业条件 业务流程图
1.测试用例及工具开发人员：
1) 需熟练掌握 DOE 实验设计等理论工具并运用 开始测试
到测试用例和工具的开发工作之中。
2) 需熟练掌握代码审查及文档管理工具，加强测
试用例审查和文档管理工作。 拷贝测试版本
3）需对测试执行人员进行相关测试用例和工具的
人员
使用培训，确保相关人员正确掌握相关测试用例
和工具的使用方法。 检查测试设备
2. 测试执行人员： 状态
1) 需熟练掌握项目组开发的测试用例和工具的
使用方法。对于新员工，需作入职报告，报告通
过后，方可进行具体测试工作。
Axiom 网页创
测试电脑和测试手机存储能满足手机系统稳定性
建测试任务
机器 测试日志存储的要求，电脑一般选取 1TB 硬盘，
手机存储需大于 100GB。
需及时更换损坏的 USB 线以及相机，屏幕不能正
常工作测试手机，确保测试设备正常连接。 实验室巡检测
材料 试状态
需保证电池持续供电，一般使用可供电 USB HUB
或者使用模拟电池供电。
测试用例，运行环境，工具均需
方法
正常稳定工作 整理发送测试
需确保手机测试用例正常测试，测试任务正常执 报告
测量值 行，确保测试报告上统计的测试时间，
真实反映的测试有效时长。
需确保实验室电力， 结束测试
环境
网络及温度等正常

65
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

表 4-14 智能手机系统稳定性测试标准作业书（续）
智能手机系统稳定性测试标准作业书
手机应用端系统
发文部门 文件编号 001
稳定性测试组
生效日期 2021/4/16 页码 第 2 页/ 共 2 页
作业标准及方法
工序 作业事项 作业方法 注意事项
通过专用网络从国外服 一般同步时间为 2 个小时左右，
1 拷贝测试版本 务器同步测试版本到本 如排队时间较长，需发邮件说明
地服务器。 情况。
Axiom 网页上填写版本 如不适合自动化刷机，可人工使
2 刷机
信息，自动刷机。 用刷机工具，手动刷机。
如不适合自动化预设置，可人工
Axiom 网页上选择预设
3 手机预设置 使用刷机工具，手动进行预设
置脚本，自动预设置。
置。
需定时到实验室巡检，查看测试
Axiom 网页上选择测试
4 执行测试用例 机器状态是否正常，并在巡检签
用例，自动执行测试。
到表上签到。
目前 Axiom 上报的问题主要有
System crash, Framework
Reboot, Tombstone 等稳定性问
收集测试日志并 Axiom 自动收集日志，并
5 题。其中前两个算入系统稳定性
上报问题 上报问题。
MTBF 计算之中，Tombstone 不
计入，仅作为普通安卓问题处
理。
人工收集统计上报问题 需检查部分无任何问题报出的
整理并发送测试 数量与所有机器的总测 机器是否正常运行测试用例，如
6
报告 试时长，计算 MTBF 并 确实状态异常，应不统计该机器
发送测试报告。 的测试时长。
编制 本论文作者 审核 项目组所有人员
编制日期 2021/4/3 批准 项目组组长

66
上海交通大学工程管理硕士学位论文 第四章 智能手机系统稳定性测试流程的改善与控制

4.5 本章小结

本章主要介绍了智能手机系统稳定性测试流程的改善和控制阶段。在改善阶
段，本研究通过快赢措施和 DOE 实验设计等对在分析阶段找到的 6 个关键影响因
子进行了改善，并在 A 系列产品升级项目上进行了一个月的应用和实验。通过理
论计算和项目实际数据统计，发现以上改善措施，可以有效地让项目中的测试手
机使用率达到 77%以上，满足了在定义阶段设定的改善目标。为了确保改善措施
能在以后所有的项目中均能得到有效落实，在控制阶段，利用标准作业书，从作
业条件，作业流程以及作业标准及方法等三个方面，对改善后的测试流程进行固
化。综上可知，通过改善和控制阶段，已实现对 6 个关键影响因子的改善，并达
到了设立的 77%手机使用率的目标。也通过制定标准作业书的形式，让这些改善
措施在以后的项目中均能准确实施，保证了改善成果的持续有效。

67
上海交通大学工程管理硕士学位论文 第五章 智能手机系统稳定性测试流程改善的成果评估

第五章 智能手机系统稳定性测试流程改善的成果评估

5.1 智能手机系统稳定性测试流程改善的直接成果评估

经过 DMAIC 模型的分析和改善，本项目组的智能手机系统稳定性测试流程中
测试手机的使用率已经达到了 77%的改善目标。在将所有改善措施一一落实到所
有项目之中，并在所有项目中广泛运行后，发现其所获得的直接成果主要有两方
面，一方面是测试手机的使用率得到提升，另一方面，随着测试手机使用率的提
升，每个版本的有效时长也相应地得到提升，从而直接导致 MTBF 测试报告的质量
得到了提升。

5.1.1 测试手机使用率提升评估

如表 5-1 所示，为改善措施执行后 2021 年 7 月至 12 月 A 系列产品的测试机

器使用率统计表。由表可知，该项目上手机的最低使用率为 12 月份，仅为 79.15%。
而最高为 10 月份，达到 91.25%。该使用率已经达到了在流程改善问题定义阶段
设定的测试手机平均使用率由 67%提高到 77%左右的改善目标。相对于改善前 A
系列产品的手机使用率，改善后 A 系列产品整体手机使用率提高了 10%以上。经
过统计，同一时期进行的其他项目的使用率，也均达到了 77%以上。本项目组每
年采购测试所用的工程手机的费用约为 150 万美金。项目手机的使用率提高了
10%，相当于每年减少了 15 万美金的设备闲置费用。
表 5-1 改善后 2021 年 7 月至 12 月 A 系列产品的测试机器使用率统计表
月份 7 8 9 10 11 12
机器数量 23 23 23 21 21 21
使用率 79.72% 83.91% 79.43% 91.25% 84.27% 79.15%

综上分析可知，通过 DAMIC 模型的分析改善工作以后，项目组的手机使用

率完成了既定改善目标。

68
上海交通大学工程管理硕士学位论文 第五章 智能手机系统稳定性测试流程改善的成果评估

5.1.2 MTBF 测试报告质量改善评估

通过改善测试手机的使用率，可以提高每个版本的总测试时长和发现的系统
崩溃数量。如表 5-2 和表 5-3 分别为改善措施执行前的 A 系列产品和改善措施执
行后的 A 系列产品在 2020 年和 2021 年下半年的 MTBF 测试指标统计表。由下表
可知，在排除一些版本回退问题的前提下，随着项目的进行，一般系统崩溃数量
逐渐减少而 MTBF 数值则逐渐增加。改善以前，A 系列产品的半年的总测试时长，
仅为 50704 个小时，总共发现了 5039 个系统崩溃问题；而改善以后，A 系列产品
的半年的总测试时为 80520 个小时，总共发现了 11700 个系统崩溃问题。改善以
后，总测试时长增长了 58.8%，发现的系统崩溃数量增长了 132%。总测试时长增
长如此之多，一方面是因为提高了每台手机的使用率，使得每台设备的总时长得
到增长。另一方面，也是在改善测试过程中，优化了测试流程，能够保持更多地
测设备持续测试。
表 5-2 改善前 2020 年 A 系列产品 MTBF 测试指标统计表
月份 7 8 9 10 11 12 总计
机器数量 25 21 17 15 15 15 /
测试时长（小时） 13971 10040 8860 4000 7404 6429 50704
Crash 1462 882 857 463 1260 115 5039

表 5-3 改善后 2021 年 A 系列产品 MTBF 测试指标统计表

月份 7 8 9 10 11 12 总计
机器数量 23 23 23 21 21 21 /
测试时长（小时） 13642 14359 13154 14257 12742 12366 80520
Crash 5174 3884 1511 835 266 30 11700

综上分析可知，通过 DAMIC 模型的分析改善工作以后，本项目组的 MTBF 测试

报告的关键指标，总测试时长和系统崩溃的数量得到了显著增长。MTBF 测试报告
的质量也得到了显著改善。

5.2 智能手机系统稳定性测试流程改善的间接成果评估

经过 DMAIC 模型对测试流程的改善，原有的测试流程得到优化的同时，也取
得了很好的直接成果，同时也带来了一些额外的间接成果。一方面，减轻了智能

69
上海交通大学工程管理硕士学位论文 第五章 智能手机系统稳定性测试流程改善的成果评估

手机系统稳定性测试执行人员的工作量。另一方面，由于改善经验，不只适用智
能手机系统稳定性测试，对于其他项目，比如车载芯片，虚拟现实设备芯片和物
联网设备芯片的系统稳定性测试也都具有一定的参考价值。

5.2.1 测试执行人员工作量评估

改善前的全自动化测试中，测试人员的工作量主要来源于三个方面。第一，
项目开始前的环境搭建工作。主要包括测试电脑，测试手机和其他测试所需要用
到测试物料和各种测试工具以及测试用例所需要的软件配置。第二，项目进行时
的具体测试工作。主要是包括测试系统版本的切换工作，测试任务的检查工作，
测试报告的汇总工作。第三，则是项目结束以后的测试总结工作，将整体测试情
况进行经验和成果总结。对于好的方面，在下一个项目中继续保持，对不做的不
足的方面，在下一个项目中给予改善。
改善前的测试流程主要存在两点问题。第一，针对测试环境搭建工作，由于
在改善前没有制定详细的文档。测试执行人员，大多凭经验进行环境配置，但是
由于测试用例开发人员，一旦对原测试用例或者环境进行更改，而测试执行人员，
未得到及时更新，就会造成测试任务执行异常的问题。从而增加了测试执行人员
重新配置测试环境，进行返工的问题。而改善后，加强了新员工培训的工作，在
项目开始前统一进行测试用例审查与测试文档更新，避免了项目开始以后，因测
试环境问题导致的返工问题。第二，对于项目进行中的具体测试工作。虽然在改
善后，增加了巡视环节，但是由于增加了对以前测试异常问题的改善方案，后面
在改善项目进行中，发生测试异常问题的概率大大降低。
综上可知，经过改善以后，节省了项目前期测试执行人员的测试环境返工的
时间，项目进行中解决测试异常问题的时间。其中主要的时间，是花费在项目进
行中的具体测试工作。经过对测试执行人员的工作量进行统计，在改善开始前，
对于同时负责两个手机项目共 50 台测试手机的测试执行人员，平均每天需花费 6
个小时左右在测试项目执行上。一般整理测试报告 0.5 小时左右，处理异常测试
机器 4 个小时左右，准备新版本的测试大约 1.5 个小时左右。而改善以后，由于
测试异常问题发生概率降低，每个人只需花费 2.5 个小时的时间去进行测试项目
巡视以及处理测试异常的问题。再加上一些测试工具的应用，准备新版本的测试，
也降低到 1 个小时左右，再加上 0.5 个小时左右的报告整理工作，测试人员每天
花费在智能手机系统稳定性测试项目执行上的时间，只有 4 个小时左右。从这里

70
上海交通大学工程管理硕士学位论文 第五章 智能手机系统稳定性测试流程改善的成果评估

可以看出，改善工作节约了测试执行人员每天 2 个小时的工作量，多出来的时间，
可以让测试人员参与测试用例的开发工作，或者承担更多的执行工作，增加手机
系统稳定性测试的机器数量和测试能力。

5.2.2 改善经验可推广性评估

市场调研机构 CounterPoint 统计报告显示，高通公司在 2022 年第一季度全

球智能手机芯片市场的份额为 30%，位于所有芯片厂商中的第二名，距第一名，
也只差了 8%的全球市场份额。近些年来，高通公司的市场份额也相对稳定，这就
导致目前所有的主流手机厂商生产的智能手机大都搭载有高通公司生产的手机芯
片。目前除苹果手机外，主流手机厂商的产品均采用安卓系统，尽管其使用了不
同手机芯片厂商的芯片，但是基于安卓系统的测试方法也都相同。因此，采用搭
载高通公司手机芯片的主流手机厂商的系统稳定性问题数据与高通公司的测试工
序和测试技术指标数据来驱动 DAMIC 模型进行的流程改善经验，对于广大的主流
手机厂商具有重要的参考价值。
除此之外，随着近些年自动驾驶，元宇宙和物联网相关概念的持续火爆。高
通公司也加大了对相关领域的车载芯片，虚拟现实设备芯片和物联网设备芯片的
开发。当前公司的开发这些芯片的验证机器也都是基于安卓系统。虽然和智能手
机芯片的测试场景有一定的区别，但是在交付给客户时，也都要确保交会给客户
的芯片系统稳定性达到一定的标准。但是由于这些团队成立时间较晚，相对测试
技术积累较为薄弱，大部分还停留在半手动半自动化测试的流程之中。虽然也开
始对各自的项目开展全自动化测试部署，但也难免会走一些弯路。本项目组基于
公司开发的 Axiom 智能手机自动化测试系统进行全自动化测试的升级，还对升级
以后遇到的问题进行了改善，这些测试经验可以推广给其他需要做系统稳定性测
试的项目组。
经过进一步分析可知，当前测试流程改善经验可以推广到其他项目组的主要
有以下三个方面。第一点，利用快赢措施来迅速改善较容易改善的影响因子。本
研究所提出的采用自动化脚本，采购新设备等改善措施均可作为参考。第二点，
测试用例设计过程中可以使用 DOE 实验设计等来帮助选择较为合适的测试参数进
行测试，避免因为测试参数选择不合适而导致的测试无效测试。最后，也可以参
考制定的标准化作业书来制定各个团队合适的标准作业流程，以提高每个团队的
测试效率和测试质量。

71
上海交通大学工程管理硕士学位论文 第五章 智能手机系统稳定性测试流程改善的成果评估

5.3 本章小结

本章主要分析了智能手机系统稳定性测试流程改善措施执行以后所带来的直
接成果和间接成果。直接成果主要包括提升了测试手机的使用率和改善了 MTBF 测
试报告的质量。其中手机使用率提高了 10%左右，相当于每年节省了 15 万美金的
设备闲置造成浪费。而在对改善后 A 系列产品和改善前 A 系列产品的测试结果分
析中，也发现本项目组的 MTBF 测试报告的关键指标，总测试时长和系统崩溃的数
量得到了显著增长。间接成果，则包括节约了每个测试执行人员每天 2 个小时左
右的项目执行时间和积累了丰富的自动化测试流程的改善经验。在减轻测试人员
负担的同时，改善经验也可以推广到主流手机厂商以及高通公司的其他车载芯片，
虚拟现实设备芯片和物联网设备芯片的系统稳定性测试之中，可以极大地节约其
他项目在进行自动化测试升级项目的时间。

72
上海交通大学工程管理硕士学位论文 第六章 总结与展望

第六章 总结与展望

6.1 总结

本文从智能手机系统稳定性测试的工程实践出发，采用搭载高通公司手机芯
片的智能手机的系统稳定性的测试数据来驱动 DMAIC 模型进行流程改善，从而提
升了搭载高通公司手机芯片的智能手机的系统稳定性的测试效率和测试质量，将
当前测试流程中的手机使用率由改善前平均 67%提高到 77%，并在以下三个方面
进行了创新：
第一，针对智能手机系统稳定性测试的自动化水平较高，测试人员无法关注
测试细节，无法积累有效的经验去定位测试流程中的改善对象的问题，本文在定
义阶段提出了利用帕累托图、层次分析法和质量功能展开对手机厂商客户问题数
据和内部测试技术指标进行分析，再以权重最高的测试技术指标为改善对象的方
法，解决了依据工程经验不易确定改善对象的问题。首先，通过帕累托图分析法
对客户上报的问题进行分类和重要度排序，找出了客户最为关心的问题。其次，
通过层次分析法对这个问题的测试场景进行分析展开和重要度排序。最后，结合
QFD 质量功能展开将客户测试场景与内部的测试技术指标相关联，以权重最高的
内部测试技术指标作为本次改善的改善对象。
第二，针对智能手机系统稳定性测试过程中使用的测试设备和工具较多而导
致潜在影响因子过多且不易量化分析的问题，本文在测量和分析阶段提出了利用
过程能力分析、因果图和 5M1E 分析法，失效模式与效果分析将潜在影响因子缩小
在过程能力不足的测试工序中并结合工程经验对潜在影响因子进行量化分析的方
法，提高了潜在影响因子分析的效率和质量。
第三，针对智能手机系统稳定性的测试时间较长，通过实际测量的方法去评
估改善效果耗时较长的问题，本文在改善和控制阶段提出了手机使用率的理论计
算的方法，利用快赢改善措施和 DOE 实验改善的评估结果来计算改善效果的理论
值，加快了改善效果评估的速度，也丰富了评估手段。首先，采用快赢措施进行
快速改善，对比改善前后，测试过程中手机的故障处理效率和故障发生频率，来

73
上海交通大学工程管理硕士学位论文 第六章 总结与展望

判断来改善措施是否有效。其次，利用 DOE 实验设计对较为复杂的影响因子进行

深度优化，在改善结束后统计无效测试机器的比例，判断复杂影响因子是否被改
善。最后，通过手机使用率的经验公式，代入相关测量统计得到的参数，在理论
上对手机使用率是否满足改善目标进行判断。同时，统计了改善后，真实测试项
目中的手机使用率，进一步验证改善效果。
因为高通公司的手机芯片常年占据全球手机芯市场份额的前两名，因此目前
的主流手机厂商的智能手机均搭载有高通公司的手机芯片。此外，目前除苹果手
机外，主流手机厂商的产品均采用安卓系统，尽管其使用了不同手机芯片厂商的
芯片，但是基于安卓系统的测试方法也都相同。因此本研究所使用的测试数据驱
动的测试流程改善框架，在很好地对高通公司智能手机系统稳定性测试流程进行
了改善优化的同时，也可以供主流的手机厂商进行借鉴。
本研究使当前的测试效率和测试质量得到了极大提升，避免了以前因采用以
测试经验为基础的主观改善措施而导致改善效果不如预期的问题，并最终形成以
下四个成果：
第一，测试手机的使用率提升了 10%，完成了设立的改善目标，相当于每年节
省了 15 万美金的设备闲置造成浪费。
第二，改善了 MTBF 测试报告的质量。改善以后，本项目组的 MTBF 测试报告
的关键指标，总测试时长和系统崩溃的数量得到了显著增长。改善以后，总测试
时长增长了 58.8%，发现的系统崩溃数量增长了 132%。
第三，节约了每个测试执行人员每天 2 个小时左右的项目执行时间，极大地
减轻了测试人员的工作负担，进一步提高当前的测试效率。
第四，为其他同类型的测试项目提供了一种新的测试流程改善框架。改善中
所采用的快赢改善措施和基于 DOE 实验优化 Monkey 测试参数和制定的标准化作业
书等方法均可以推广到主流手机厂商以及高通公司其他车载芯片，虚拟现实设备
芯片和物联网设备芯片的系统稳定性测试之中，可以极大地节约其他项目在进行
自动化测试升级项目的时间。

6.2 不足与展望

虽然本研究通过 DMAIC 流程改善模型对当前的智能手机系统稳定性测试做出

改善，并完成了预期目标，取得了不错的成果。但是本项目中仍有许多不足之处
需要改进。比如，项目的测试执行过程中仍要花费 2.5 小时去处理各种异常情况。

74
上海交通大学工程管理硕士学位论文 第六章 总结与展望

比如，Monkey 的测试效率虽然得到改善，但效果仍和客户的 MTBF 测试和老化测

试存在一定差距。因此如何进一步减少测试中的异常问题，以及提高测试用例的
测试效率仍是系统稳定性测试项目的当务之急。
展望未来，在保证现在自动化测试流程和改善措施的正确实施以外，还是希
望可以利用一些新的理论知识和新的技术手段对当前的测试流程，测试工具以及
测试用例进行改善。比如，结合强化学习的方法对 Monkey 的随机事件生成方式进
行优化，从利用默认或指定百分比的方式进行随机的事件的生成，到通过设置奖
励函数，通过强化学习去学习每一个手机应用页面生成哪种事件奖励最高，来对
Monkey 的测试用例进行改进。除此之外，加强与其他团队的沟通，把手机自动化
测试项目上取得的良好经验，推广给其他部门，提高公司的整体自动化测试水平。

75
上海交通大学工程管理硕士学位论文 参考文献

参 考 文 献

[1] Zhua H X, Cheng Z F, et al. Research on Reliability Modeling and Evaluation

Method Based on MTBF Definition[J]. International Core Journal of Engineering, 2021,
7(2): 298-302.
[2] 苏中 , 崔书锋 . 从手机应用看全球数字技术之争 [J]. 发展研究 , 2022, 39(01):
36-43.
[3] 王君堂. 移动通信技术与互联网技术的结合发展[J]. 中国新通信, 2021, 23(04):
1-2.
[4] 包金武. 中国手机市场发展现状分析[J]. 河北企业, 2021(1): 82-83.
[5] 聂万祥, 赵傅艳. 移动数据流量数据基于 5G 网络的建设与应用[J]. 中国宽带,
2022(2): 95-96.
[6] 周俊成. 手机 APP 应用前景及发展瓶颈[J]. 信息记录材料, 2021, 22(07): 55-56.
[7] 文波, 马莹. 人工智能在计算机网络技术中的应用探究[J]. 网络安全技术与应
用, 2022(01): 102-103.
[8] 李梅 . 基于 SCP 视角的我国智能手机行业发展探究[J]. 北方经贸 , 2021(01):
79-81.
[9] 赵熠如 . 抢占高端手 机行业抢食华为高端市场展开拉锯战 [J]. 中国商界 ,
2022(Z1): 76-78.
[10] 王子怡, 杨杉. 基于 SPSS 的国产手机使用反馈情况分析 [J]. 长江信息通信,
2021, 34(06): 210-213.
[11] Paydar S, Houshmand M and Hayeri E. Experimental study on the importance and
effectiveness of monkey testing for android applications[A]. 2017 International
Symposium on Computer Science and Software Engineering Conference (CSSE)[C].
Shiraz: IEEE, 2017: 73-79.
[12] Doyle J, Saber T, Arcaini P, et al. Improving Mobile User Interface Testing with
Model Driven Monkey Search[A]. 2021 IEEE International Conference on Software
Testing, Verification and Validation Workshops (ICSTW)[C]. Porto de Galinhas: IEEE,
2021: 138-145．

76
上海交通大学工程管理硕士学位论文 参考文献

[13] Wang X M, Huang X, et al. Research of Mobile Applications Automated Testing

Using Uiautomator[A]. 2016 4th International Conference on Machinery, Materials and
Computing Technology(ICMMCT 2016)[C]. Hangzhou: Atlantis Press, 2016: 963-968.
[14] Alotaibi A A and Qureshi R J. Novel Framework for Automation Testing of Mobile
Applications using Appium[J]. International Journal of Modern Education and
Computer Science(IJMECS), 2017, 9(2) : 34-40.
[15] Wang J and Wu J. Research on Mobile Application Automation Testing
Technology Based on Appium[A]. 2019 International Conference on Virtual Reality
and Intelligent Systems (ICVRIS)[C]. Xiangxi: IEEE, 2019: 247-250.
[16] 季美辰. Android UI 错误自动化检测系统的设计与实现 [D]. 上海: 上海交通
大学, 2019.
[17] 成浩亮 , 汤恩义 , 玉淳舟等. 一种手绘制导的移动应用界面测试方法 [J]. 软
件学报, 2020, 31(12): 3671-3684.
[18] 刘维维. 人工智能技术在移动终端自动化测试中的应用[J]. 软件导刊, 2021,
20(02): 59-62.
[19] 史中雨 . 智能手机稳定性监控系统的设计与实现[D]. 上海 : 上海交通大学,
2019.
[20] 杨沁晓 , 郝小敏 , 严航. 浅谈手机软件测试用例的设计方法及技巧 [J]. 电子
测试, 2021(21): 123-124+67.
[21] 罗思蕊. 基于 PDCA 的 M 手机系统测试项目质量管理过程的研究[D]. 北京:
北京工业大学, 2018.
[22] 赵浩然. 基于风险管理的手机系统测试方案设计与实现 [D]. 北京: 中国科学
院大学(工程管理与信息技术学院), 2013.
[23] Adeodu A, Mpofu K, et al. Application of lean Six Sigma methodology using
DMAIC approach for the improvement of bogie assembly process in the railcar
industry[J]. Heliyon, 2022, 8(3): e09043.
[24] Rodriguez D R, Medini K, et al. A DMAIC Framework to Improve Quality and
Sustainability in Additive Manufacturing—A Case Study[J]. Sustainability, 2022, 14(1):
581.
[25] 刘淑君. 基于 DMAIC 的变速箱制造质量提升[D]. 上海: 上海交通大学, 2020.
[26] 叶美健. 基于 DMAIC 理论的动力环境监控系统运行质量改进研究[D]. 上海:
上海交通大学, 2020.

77
上海交通大学工程管理硕士学位论文 参考文献

[27] Acharya S G, Sheladiya M V, et al. An Application of PARETO Chart for

Investigation of Defects in FNB Casting Process[J]. Journal of Experimental & Applied
Mechanics, 2018, 9(1): 33-39.
[28] 李鑫, 尤凤翔. 基于 AHP 的企业精益生产实施关键因素分析[J]. 中国管理信
息化, 2019, 22(01): 86-89.
[29] Reda H and Dvivedi A. Decision-making on the selection of lean tools using fuzzy
QFD and FMEA approach in the manufacturing industry[J]. Expert Systems with
Applications, 2022, 192: 116416.
[30] 殷慧亭. 基于 QFD 和 FMEA 的民机起落架需求分析和概念设计[D]. 上海: 上
海交通大学, 2020.
[31] 陈国强, 戴成, 申正义等. 基于 QFD 与 FBS 的可移动电力检测设备创新设计
[J]. 包装工程, 2021, 42(02): 43-50.
[32] 高军呢, 谭卫红, 李晓鑫. 应用 Minitab 进行测量系统分析及评价[J]. 设备管
理与维修, 2021(12): 39-40.
[33] 高祖成 , 周喆 , 陆向科等 . 鱼骨图在解决产品开发问题中的应用 [J]. 内燃机
与配件, 2021(14): 206-207.
[34] 昝现亮. 基于 5M1E 分析法的轧制产品质量控制研究[J]. 塑性工程学报, 2021,
28(08): 83-91.
[35] Ng Y J, Muthugala M A, et al. Application of an adapted FMEA framework for
robot-inclusivity of built environments[J]. Scientific Reports, 2022, 12(1): 3408.
[36] 林水燕. FMEA 工具在汽车零部件质量提升中的应用研究[D]. 上海: 上海交
通大学, 2016.
[37] 赵玲玲, 樊树海, 吕庆文等. 基于 Minitab/TURN5DOE 的试验设计在质量管
理的应用[J]. 机床与液压, 2021, 49(13): 25-28.
[38] 张春宇 , 董春雨 , 史晓强. 标准化作业在包装过程中的实践与应用 [J]. 中国
钢铁业, 2020(07): 44-45.
[39] Mogaramedi M, Marnewick A, et al. Impact of Standard Work for Leaders On
Reducing Unused Employee Creativity During Lean Implementation[J]. South African
Journal of Industrial Engineering, 2020, 31(2): 1-10.
[40] 何磊, 蔡媛媛, 魏然等. 基于 Minitab 的宇航集成电路质量控制方法[J]. 电子
与封装, 2021, 21(06): 58-62.
[41] 陈洪根, 闫鑫, 牛小娟等. 基于 DMAIC 的转向轴生产质量改进[J]. 工业工程,

78
上海交通大学工程管理硕士学位论文 参考文献

2021, 24(02): 100-109+124.

[42] Pawar H U, Bagga S K, et al. Investigation of production parameters for process
capability analysis: A case study[J]. Materials Today: Proceedings, 2021, 43(P1):
196-202.
[43] 白杨丰, 于丽君, 李亚明. 基于过程能力指数的金钢线多晶切片质量控制[J].
电子工业专用设备, 2019, 48(01): 24-28.

79