【摘要】本文就杰尔系统（Agere system）平台基础上开发的GSM手机自动化测试提供一些技术介绍，并结合实际例子讲解一些应用经验，来说明自动化测试在手机功能测试一级中所带来的效率。

【关键字】手机平台，杰尔系统，Trace，PTE命令，手机软件功能测试，自动化测试

• 国内手机功能测试现状：

当前国内手机厂商和设计公司据统计已达到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 UINT32TestWindowProc( 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;

}

}

• 手机与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

返回：Key:DONE

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

• 定义按键事件的发送间隔

输入格式：Wait

返回：Key:DONE

举例：

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

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

Key 1

Wait 500//按键间等待0.5秒

Key10

Wait 500

Key 10

Wait 500

Key 1

Wait 500

Key11//按呼叫键

Wait3000//等待呼叫，3秒

Wait60000//1001接通后等待1分钟

Key12//按挂机键，结束通话

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

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

• 综合信息

•  方案简述:

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

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

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

如一菜单结构如下：

待机窗口－主菜单－（5）话机设置

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

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

Wait 500

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

Wait 500

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

Wait 500

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

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

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

2)代码桩或者跟踪语句

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

3)生成一份预期的测试报告

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

4)生成自动测试用例库

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

5)测试用例的提取并执行

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

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

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

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

•  实际应用:

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

1)录制按键事件.

首先运行optitrace.exe程序

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

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

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

2)生成PTE脚本：

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

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

3)编写测试桩：

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

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

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

caseGSMAlerting: //成功接收回铃消息

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

++ NumOfCallSuccess); //呼叫成功

else

{

NumOfCallSuccess =0;

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

}

break;

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

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

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

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

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

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

• 总结

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