国内手机功能测试现状：

当前国内手机厂商和设计公司据统计已达到 300 多家，但至今所有的设计开发都是基于国外技术平台基础上的二次开发，即通常所说的 MMI 开发， 提供开发的手机平台目前主要有德州仪器（ TI ），英特尔（ Intel ），飞思卡特（ freescale ），杰尔系统（ Agere system ），英飞凌（ infineon ），瑞萨科技（ renesas ），菲利普半导体（ philips ），意法半导体（ ST ），美国博通（ broadcom ），美国模拟器件（ ADI ），微控科技（ wavecom ）。通常这些平台供应商的核心技术都不对外开放，只为购买其开发平台的用户提供一个可二次开发的环境，比如本文所要介绍的自动测试所基于的平台 ——Agere system ， 它在其软件架构的上层为开发用户做了一层 UI （ User Interface ） , 并做了最基本的 AL 开发，通常方案提供后可以直接作为国内厂商用于 FTA 测试，这即是国内众多手机厂商和 design house 开发和测试的母体。

曾听一位从事手机功能测试的同仁说 “ 做手机功能测试只要有手就可以了 ” ，确实手机功能测试很容易给人一种是简单而重复按键操作的感觉。但手机功能众多，并且回归测试工作量大，如果单个测试工程师靠手动按键来执行所有测试用例，花费的时间少则几小时，多则需要几天的时间，这样耗费大量测试时间的同时也容易让测试工程师产生疲倦甚至是厌倦心里，很容易造成测试的遗漏。手机测试中常碰到很多重复性高的工作，如发送数条 SMS 或者 MMS 以验证其收发成功率以及稳定性、连续进行多次呼叫、多次对文件系统进行添加删除操作、多任务多进程情况下的冲突测试以及极限测试等等，都是重复性高的工作，手动执行的话费时费力，如果能有一套自动执行的机制，将能大大提高测试的效率。

由于手机平台的特殊性，国内通常都没有自动化测试工具支持手机功能测试，纷繁复杂的功能测试大多只能通过文本化测试用例的指导，由广大测试员手工来完成。手机这种板机的 MMI 功能测试不同于基于 PC 上的 MMI 测试，后者借助 PC 平台，目前市场上已有非常多功能强大且通用的自动测试工具支持其测试，如比较典型的有 Winrunner ， Robot ， Loadrunner 等等，但这些工具通常不能兼容到象手机这种嵌入式系统中来。当然平台供应商对他们底层 lay1 ， lay2 ， lay3 的测试都有自己开发的测试工具来自动执行，但这些工具暂时都不提供给国内的开发厂家。

为了解决上述手机测试工作中的困难，笔者所在的测试团队经过不断的总结实践，目前已在基于杰尔系统（ Agere system ）平台上建立了一套实用的自动测试机制，通过该机制的建立，不但调动了测试工程师的工作积极性和热情，同时也大大提高了测试的效率。下面将围绕 Agere 平台上自动测试机制给大家做个总体介绍。在讲述该方案前，将先对 Agere 平台的窗体和消息，以及手机同 PC 的数据交互原理做个简单介绍。

手机中的窗体和消息：

功能测试时，在手机上每按下一按键，都是在特定的窗口下完成其功能，窗口处理函数接收到窗口所用键盘中定义的按键消息后执行相应的处理，完成指定的工作。这里所谈的窗口系统本质上是一个链表，主要是响应手机中常用的三类消息：用户的按键操作、 GSM 网络消息、以及计时器消息。

手机中窗体处理函数结构通常如下：

static UINT32 TestWindowProc( UIWINDOW * win, UINT16 cmd, UINT16 wParam, UINT32 lParam )
{
switch ( wParam )
{
case EV_KEYSEND: /*按发送键*/
CALL(MAOTelNumber);
return TRUE;

case EV_KEYEND: /*按挂机键*/
ENDCALL(MAOTelNumber);
return TRUE;
......
default：
break;
}
}

在窗体中除了对消息的实时处理外，还有通过具体的消息传递函数对本窗口中消息进行派发和定向流动，通常有 GSM 消息的流动和键盘消息的流动，派发 GSM 消息时，依据窗口建立的逆向顺序逐层往上流动，而键盘消息只向上传递一层，即子窗口向父窗口传送。 在系统功能测试过程中，窗口中的消息执行情况是看不到摸不着的东西，但是各个窗口中这三类消息的处理以及消息的派发流动都是测试所必须了解和测试的重点，怎样才能直观的看到，跟踪并了解这些消息的执行情况呢？测试工程师可以通过在跟踪点加测试桩或者跟踪语句来实现追踪，利用杰尔系统的 trace 工具（ optitrace ）以文本的形式输出所需要了解的信息，根据这些信息的输出流程和实际数据，以达到测试跟踪和分析的目的，如上面这一简单例子中所列举的两个事件 EV_KEYSEND 和 EV_KEYEND ，最简单的跟踪是通过在这两类事件触发前增加类似于 print 跟踪语句，判断 “ 发送键 ” 按下后是否在指定的窗口里执行到 EV_KEYSEND 事件并调用呼叫函数 CALL 执行呼叫请求 ， 实际运行时，根据 optitrace 工具所显示的 print 信息观察程序的运行及消息的执行情况，跟踪的手段很多，在此就不详细列举。下面介绍 PC 怎样通过 Optitrace 工具实现同手机板机的数

手机与 PC 的数据交互

通常每个平台为软件开发提供一系列的开发套件，常用的有仿真软件、 Trace 跟踪分析软件、 Download 目标代码的装载软件等等，通过这些软件实现手机同 PC 的数据交互，实现软件的开发仿真，问题的跟踪分析，以及程序的灌写等。这些软件大多采用串口通讯的方式，通过特定的数据线连接手机串口通讯端与 PC 的串口或者 USB 端（ USB 转串口）。下面将要介绍的是杰尔系统（ Agere system ）的开发套件之一 optitrace 。

该工具可以运行于 win9X/2000/NT 系统中，是 Agere 参考设计平台的辅助诊断工具，它为软硬件开发人员提供 Protocol Stack and MMI 的跟踪分析以及模拟用户硬件如串口显示和按键，为 field Test 人员提供 Trace Logs 和 Vital signs ，为产品测试工程师提供 Product Test environment （ PTE ） 窗口和脚本的定制以及播放。

该工具的运行界面如下：

以上运行界面中通过 optitrace 工具捕捉的用户按键消息，如 Key Code 4 ，表示用户在手机上按下数字键 4 ， key code 后面的数字是按键所定义的编码值，手机中每个按键都有唯一的按键编码值。从中可以看出，用户所有的按键动作都以 “AL got key AL_KeyDown event ， key code X” 的形式被记录下来。这些按键信息的捕捉只是该工具 trace 信息的一部分，该工具提供非常多的 trace 选项，实际应用中，可以根据所要跟踪的信息来选择显示。

该工具一个最重要的功能是可以在 PC 端通过 PTE 命令模拟用户来操作数据线另外一端的手机，该工具本身定义了 11 类的 PTE 命令，下面重点介绍两个重要的 PTE 命令，

模拟一个按键按下和释放

输入格式： Key <INT16 Keycode>

返 回： Key:DONE

用户可以在 optirace 的 PTE 命令输入行中，通过输入正确的 Key 命令，往手机端写入按键事件，手机端解析后执行相应的按键操作，如用户输入 key 8 回车后，手机端 LCD 显示 8 或者执行按键 8 所对应的操作，执行后返回 key ： DONE 消息。同时 trace 中显示 AL got key AL_KeyDown event ， key code 8 。

定义按键事件的发送间隔

输入格式： Wait <INT16 wait time>

返 回： Key:DONE

举例：

wait 6000 // 等待 6000Ms ，即 1 分钟

通过该命令，可以请求一个 pause 。比如呼叫 1001 通话 1 分钟后挂断。 PTE 脚本编写如下：

Key 1

Wait 500 // 按键间等待 0.5 秒

Key 10

Wait 500

Key 10

Wait 500

Key 1

Wait 500

Key 11 // 按呼叫键

Wait 3000 // 等待呼叫， 3 秒

Wait 60000 //1001 接通后等待 1 分钟

Key 12 // 按挂机键，结束通话

Wait 500

自动测试方案及框架体系：

下面介绍本公司实践的一套自动化功能测试方案架构，如下图 ：

方案简述：

自动测试主要工作流程分以下几个主要阶段：

测试用例的设计和准备 , 形成一套自动测试用例脚本库

自动测试用例的准备，如果贵公司在需求定义的同时有各功能详细具体的 menu tree 架构，那即可在此基础上手动编写 PTE 命令脚本。

如一菜单结构如下：

假设一手机的关机功能菜单位于主菜单中第 5 项菜单 “ 话机设置 ” 的第一子菜单中，可以用以下脚本方式实现手机执行关机。

Key 15 // 在待机下按左键进主菜单

Wait 500

Key 5 // 按 5 进入住菜单的第 5 个子菜单 “ 话机设置 ”

Wait 500

Keyhold 1 ， 2000 // 长按 1 键关机

Wait 500

从中可以看出只要定义了 menu tree ，理解菜单的排列顺序，以及实际的功能操作步骤，即可以用脚本来模拟所有按键和执行步骤来定义测试的 PTE 脚本。

另一种脚本编写方式可以通过录制加转换的方式实现，利用 optitrace 工具录制实际操作时的按键动作，存为 txt 文件，然后将该 txt 文本转换为 PTE 脚本文件。实际测试中通过在集成测试或者系统测试初级阶段录制脚本，这样不会因软件大的变更导致测试用例失效，或者需要大规模维护，降低了风险指数。这些脚本在日后的回归测试中将发挥巨大的作用。

按键录制时测试工程师针对某一功能或者依照某一组测试用例执行一次完整连续的手工测试，通过 optitrace 捕捉本次测试过程中所有的按键事件，生成一份对应的 << 按键事件列表文档 >>.TXT （ optitrace 只能生成文本文档），然后对应将所有按键事件转换为 <<*.PTE 文本 >> 。

代码桩或者跟踪语句

测试时根据实际情况可能需要在各检测点编写用户检验的代码桩或者跟踪语句，代码测试桩有利于对本自动测试体系中软件问题作出较精确的定位和分析，同时也有利于对测试结果的快速判断与自动生成测试报告。这些代码测试桩对应按键事件所对应的程序执行路径和逻辑，主要通过白盒测试方法跟踪代码执行的路径、逻辑覆盖、信息流，数据流和控制流等。在测试执行时，测试桩将执行结果响应并通过 Trace 跟踪语句显示在 optitrace 工具中。编写该测试桩需要测试工程师具备较强的编程能力，同时对手机系统要比较熟悉和了解。各功能完整的代码测试桩的编写工作量非常大，前期可以只针对部分功能的部分特性做尝试。同时测试桩插入在相应的代码中，为了避免混乱，配置时必须将测试代码同程序代码分开，只在测试执行时打开对应的编译开关得到对应的编译版本。

生成一份预期的测试报告

运行预先录制的 PTE 脚本和对应的测试桩，通过 optitrace 工具生成一份预期的测试结果报告 ( 实际就是 optitrace 生成的一份按键事件和测试桩跟踪输出信息 ) 。这份预期的测试报告日后同实际结果比较，作为实际测试结果与预期结果是否一致的判断。

生成自动测试用例库

最终由 << 按键事件列表文档 >> 、 <<*.PTE 文本 >> 、代码测试桩、 << 预期的测试结果报告 >> 组成一份自动测试用例。所有的自动测试用例按照一定的结构组织起来形成自动测试用例库。

测试用例的提取并执行

在回归以及后期的验证测试过程中，测试工程师或者程序员对应提取由 <<*.PTE 文本 >> 和测试桩组成的测试用例，执行后生成一份 << 实际的测试运行 trace 信息 >> ，保存该信息，从而测试执行结束。

测试结果分析，生成测试报告

测试结果的分析可以自动和手动执行，手动执行可以通过 Beyond Compare 工具比较 << 预期的测试结果报告 >> 和 << 实际的测试运行 trace 信息 >> ，即可以得出一份测试的执行报告。

自动生成测试报告比较复杂，需要在 pc 中用高级语言建立一个测试管理中心，该管理中心可用 VC 或者 C++ 等高级语言编写，在该管理中心中，用户可以选择需要执行的 PTE 脚本或者多个脚本串成的一组脚本，该测试管理中心可以指定测试用例的自动执行，自动提取对应的结果做自动比较分析，从而生成一份对应的测试报告，如果无差异，输出文件中只显示 OK ，否则输出差异信息文件。

实际应用：

下面以待机下呼叫 1001 共 100 次来测试呼叫成功率的例子来说明上述方案的应用。下面是该例的录制，脚本编写，及实际运行的例子。

录制按键事件 .

首先运行 optitrace.exe 程序

设置 trace 选项 , 只选择 application layer 中的 ALTraceUHMess 如图所示：

最后手机开机，跑动 trace ，测试工程师针对某一功能或者某一组测试用例执行一次完整连续的测试，得到以下按键信息，如图所示。

最后测试执行结束后，保存该按键 trace 信息，做好版本记录信息。生成对应事件的按键列表《呼叫 1001 共 100 次 .TXT 》文档， 该 TXT 文档内容完全同上图所示内容，在次不再重复。

生成 PTE 脚本：

因实际 optitrace 只录制按键消息，需要将这些按键消息转换为 PTE 命令并生成工 optitrace 工具运行的 *.PTE 脚本。而通常按键事件众多，手动逐一生成 PTE 脚本非常麻烦，因此需要做一个文件转换工具，逐行提取按键消息转换成 PTE 命令，并做一些相应的注释。

将以上按键列表转换为 PTE 命令列表，生成《呼叫 1001 共 100 次 .PTE 》文件，转换后的 PTE 脚本如图所示：

编写测试桩：

编写测试代码对需要检测的路径、逻辑覆盖、信息流、数据流和控制流等做测试跟踪，在检测点输出有效的 trace 信息。

该测试用例比较简单，在此只列举该测试任务中需要关注的呼叫是否成功，记录实际呼叫成功的次数，具体呼叫函数、以及逻辑覆盖因篇幅有限不列举，设计一计数器（ NumOfCallSuccess ），如果呼叫成功，该计数器累加 1 ，并且每次呼叫后用 printf 语句在 optitrace 工具上输出该计数器的实际值。

在呼叫窗口的处理函数中，对网络返回的 GSM 消息进行统一处理，在返回的回铃音处理消息中检测呼叫成功即可，如下所示：

case GSMAlerting: // 成功接收回铃消息

if(NumOfCallSuccess < 100) GSMprintf("\n====NumOfCallSuccess=%d======\n",

++ NumOfCallSuccess); // 呼叫成功

else

{

NumOfCallSuccess =0;

GSMprintf("\n====== NumOfCallSuccess ＝ %d======\n", NumOfCallSuccess);

}

break;

结合以上测试桩，运行《呼叫 1001 共 100 次 .PTE 》，生成预期的测试结果报告，《呼叫 1001 共 100 次 trace.TXT 》的 trace 跟踪记录文件，作为实际测试运行结果比较的依据。

Trace 信息去除无用信息及文件转换后如下所示：

自动运行《呼叫 1001 共 100 次 .PTE 》，测试结束后目录下共有以下文件：

《呼叫 1001 共 100 次 .PTE 》：测试运行的脚本

《呼叫 1001 共 100 次 trace.TXT 》：预期的测试结果文本， Txt 格式。

《呼叫 1001 共 100 次 trace2.TXT 》：实际运行的 trace log 结果，被管理工具转换后的 TXT 文本。

《呼叫 1001 共 100 次 .Txt 》：测试后生成的测试报告文件， TXT 格式。

总结：

本文结合杰尔系统（ Agere system ）中开发套件 optitrace 工具的使用，从 PTE 脚本的制作，到回归测试中脚本的测试运行，介绍了一个测试团队在手机功能级测试中采用的自动化方案，本团队在实际的使用中感受了该自动化测试方案所带来的乐趣和效率，在此著成本文供大家一起探讨，最后感谢本文的所有读者，如果您能从中汲取一点有用的营养，得到一些帮助，那我将感到无限的欣慰，这也是我整理这篇手机自动测试资料的初衷。