基于Agere開發平臺的GSM手機自動化測試解決方案

【摘要】本文就杰爾系統（ 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 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 信息。

該測試用例比較簡單，在此只列舉該測試任務中需要關注的呼叫是否成功，記錄實際呼叫成功的次數，具體呼叫函數、以及邏輯覆蓋因篇幅有限不列舉，設計一計數器（ NumOfCallSuclearcase/" target="_blank" >ccess ），如果呼叫成功，該計數器累加 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 腳本的制作，到回歸測試中腳本的測試運行，介紹了一個測試團隊在手機功能級測試中采用的自動化方案，本團隊在實際的使用中感受了該自動化測試方案所帶來的樂趣和效率，在此著成本文供大家一起探討，最后感謝本文的所有讀者，如果您能從中汲取一點有用的營養，得到一些幫助，那我將感到無限的欣慰，這也是我整理這篇手機自動測試資料的初衷。

由于時間倉促水平有限，錯誤之處在所難免，敬請廣大讀者批評指正。

 

原文轉自：http://www.anti-gravitydesign.com