手机作为专用的消费类电子产品需要进行以下测试：可靠性测试(对于硬件则是RQT;对于软件则是field trial);标准符合性测试(FTA);互操作性测试(IOT);安全性测试(安规测试);强度测试等。

其中，有些种类的测试，例如FTA，有严格的标准(GSM、3GPP等)来明确被测的功能点，测试人员所要做的是在测试用例的编写中体现出这些功能点，并且尽量营造这些测试用例所需的运行环境来完成测试，并反馈测试结果。但是对于性能测试，就没有这样的规范供测试人员来参考，因此性能测试需要进行哪些用例以及用例通过的指标的高低都有很大弹性，在很大程度上受限于测试人员的经验和项目的资源和进度压力。如何在资源、进度和质量之间找到平衡点是产品负责人需要考虑的问题，测试人员可以左右的是划定性能测试的范围、明确与性能测试相关的设计需求(提高产品的可测试性)以及通过自动化测试工具等手段来进行更加有效的性能测试，提高产品的质量。

一、手机性能测试的范围

性能测试强调长时间、重复或者高强度的进行某些操作，来验证产品在各种极限条件下的表现。性能测试隶属于软件测试中的系统测试，它对软件在集成系统中运行的性能行为进行测试，旨在及早确定和消除软件中与构架有关的性能瓶颈。通过对测试数据和log的分析，还可能找出被测系统隐藏的缺陷。终端作为移动通讯类电子产品，其性能测试又主要和其实现的功能相关，大致可分为以下几类：

1. 时间相关。

时间相关的性能测试可分为长时间保持测试和限定时间反应测试。

长时间保持测试主要是测试终端长时间稳定进行某项功能的能力。主要包括长时间待机能力、长时间CS域业务保持能力、长时间PS域业务保持能力、长时间组合业务保持能力等。长时间待机测试，就是根据手机电池的能力连续不间断待机一定时间(例如4天)，之后验证手机是否还能够发起主叫和被叫业务，能够发起主叫，表示终端在长时间待机后自身还处于正常状态，能够发起被叫，说明终端在睡眠模式下可以正常接收寻呼。长时间CS域业务保持测试，就是根据手机电池的能力连续不间断进行语音通话或者视频通话一定时间(例如2小时)，测试通话期间图象声音是否连续、清晰，是否有单通现象出现，是否会有手机板子过热现象。长时间PS域业务保持测试，主要是通过持续进行WWW业务、ftp业务或者流媒体业务一定时间(例如2小时)，测试进行数据业务期间上下行数据传输率是否稳定，网页显示是否流畅，流媒体播放是否连续等。长时间组合业务保持测试，就是同时保持CS和PS域业务一段时间，以验证终端长时间进行组合业务的能力。

限定时间反应测试主要是测试终端在规定时间内对用户的操作作出反应，给出操作结果的能力。主要包括开机驻留时延、关机时延、CS域业务接入时延、PS域业务接入时延、本地应用的操作时延等。开机驻留时延，是指从用户按下开机键(终端上电、系统引导、启动任务、搜索网络、完成位置更新)到终端进入待机界面，提示用户可以进行正常服务的总时间。关机时延，是指从用户按下关机键(终端完成网络detach、将RAM中修改过的数据写回flash)到终端完全下电所需的总时间。CS域业务接入时延，是指在进行语音或视频电话时从按下拨号键到听到对方回铃声所需总时间，由于该过程需要在网络侧分配资源，所以测试结果可能会受到当前网络资源可用程度的影响，例如在网络负荷高的时候申请CS 64k业务时，网络侧需要重新组织或合并无线资源来满足业务要求，所需时间相对会长一些。PS域业务接入时延，是指在进行数据业务时从开始连接到能正常进行数据业务所需总时间。本地应用的操作时延，是指完成某些本地操作维护功能所需的时间，例如打开电话薄，在电话薄里查找联系人，存储新建的联系人，存储短信，存储多媒体文件，打开浏览器，播放多媒体文件等所需时延，这些时延如果过长，也会极大地降低用户体验的满意度。

2. 次数相关。

次数相关的性能测试是测试终端重复稳定地进行某项功能的能力。包括开关机成功率、小区初搜成功率、小区重选成功率、CS域业务成功率、PS域业务成功率、组合业务成功率、切换成功率、本地应用的成功率等。这种重复操作包括很多对象被多次创建和释放，因此可能会发现潜在的内存泄漏等问题。开关机成功率测试，主要是检验多次开机是否会有物理层不能正确收到初搜命令的情况，关机不完全也可能会导致下一次开机失败，以及在某些情况下系统死机后只能通过插拔电池板来重新开机。CS域业务成功率的测试，是指通过进行一定次数的主叫或者被叫，统计失败的次数，对失败原因进行归类，分析是否能够找到和终端相关的失败原因。 PS域业务成功率、组合业务成功率、切换成功率的测试方法也类似。本地应用的成功率包括多次存储再删除文件、联系人、短信等操作，以及多次打开某个应用或执行某类操作来对该应用的稳定性进行测试，找出瓶颈。

3. 并发业务。

并发测试主要是测试终端同时进行多项业务时表现出的处理能力。例如同时进行CS域语音业务和PS域下载业务，或者在MP3播放的同时进行WWW上网业务，以测试协议栈、操作系统和处理器对并发业务的支持能力。

4. 负载测试。

负载测试主要是验证系统的负载工作能力。系统配置不变的条件下，在一定时间内，终端在高负载情况下的性能行为表现。例如同时进行多个ftp下载，使下行传输率接近极限值，观察终端是否可以正常工作。

二、手机性能测试的方法

手机性能测试的方法按照自动化程度不同可分为手工测试和自动测试。

手工测试主要是通过测试人员手动操作，并借助某些监测仪器和工具，来验证手机性能。但由于手机功能众多，并且性能测试工作量大，如果单个测试工程师靠手动按键来执行所有测试用例，花费的时间少则几小时，多则需要几天的时间，这样耗费大量测试时间的同时也容易让测试工程师产生疲倦甚至是厌倦心理，很容易造成测试的遗漏。手机测试中常碰到很多重复性高的工作，如发送数条 SMS 或者 MMS 以验证其收发成功率以及稳定性、连续进行多次呼叫、多次对文件系统进行添加删除操作、多任务多进程情况下的冲突测试以及极限测试等等，都是重复性高的工作，手动执行的话费时费力，如果能有一套自动执行的机制，将能大大提高测试的效率。

由此产生了对手机自动化测试工具的需求。手机这种板机的MMI功能测试不同于基于PC上的MMI测试，后者借助PC平台，目前市场上已有非常多功能强大且通用的自动测试工具支持其测试，如比较典型的有Winrunner， Robot， LoadRunner等等，但这些工具通常不能兼容到象手机这种嵌入式系统中来。这就要求测试人员能够基于当前平台进行二次开发，来满足自动化测试的需求。

手机的自动化性能测试一般分为以下几个步骤进行：

1. 系统分析

将系统的性能指标转化为性能测试的具体目标。通常在这一步骤里，要分析被测系统结构，结合性能指标，制定具体的性能测试实施方案。这要求测试人员对被测系统结构和实施业务的全面掌握。

2. 建立虚拟用户脚本

将业务流程转化为测试脚本，通常指的是虚拟用户脚本或虚拟用户。虚拟用户通过驱动一个真正的客户程序来模拟真实用户。在这一步骤里，要将各类被测业务流程从头至尾进行确认和记录，弄清这些过程可以帮助分析到每步操作的细节和时间，并能精确地转化为脚本。此过程类似制造一个能够模仿人的行为和动作的机器人过程。这个步骤非常重要，在这里将现实世界中的单个用户行为比较精确地转化为计算机程序语言。如果对现实世界的行为模仿失真，不能反映真实世界，性能测试的有效性和必要性也就失去了意义。

3. 根据用户性能指标创建测试场景

根据真实业务场景，对生成的测试脚本进行复制和控制，转化为满足性能测试指标的测试用例集。在这个步骤里，对脚本的执行制定规则和约束关系。具体涉及到对业务类型，并发时序等参数的设置。这好比是指挥脚本运行的司令部。这个步骤十分关键，往往需要结合用户性能指标进行细致地分析。

4. 运行测试场景，同步监测应用性能

在性能测试运行中，实时监测能让测试人员在测试过程中的任何时刻都可以了解应用程序的性能优劣。系统的每一部件都需要监测：协议栈，MMI应用程序，内存占用情况，驱动程序运行状态等。实时监测可以在测试执行中及早发现性能瓶颈。

5. 性能测试的结果分析和性能评价

结合测试结果数据，分析出系统性能行为表现的规律，并准确定位系统的性能瓶颈所在。在这个步骤里，可以利用数学手段对大批量数据进行计算和统计，使结果更加具有客观性。在性能测试中，需要注意的是，能够执行的性能测试方案并不一定是成功的，成败的关键在于其是否精确地对真实世界进行了模拟。