手機自動化測試工具實現
一、PC 端監控工具實現
1、手機自動化可解決的問題
( 1 ) 壓力測試：一些連續不斷的操作，比如反覆切換歌曲播放及聯網操作等
( 2 ) 極限臨界測試：一些極限條件的構造（創建多個列表）及輸入字符個數等
( 3 ) 兼容及中斷：比如在播放或下載歌曲的時候來電話或者信息(動態交互)
( 4 ) 基本功能迴歸測試：這樣大大的節約了時間和人力成本
( 5 ) 預測試（版本接收測試）
( 6 ) 專項測試
2、實現原理
(1) 手 機 自 動 化 測 試 的 原 理 爲 PC 上 一 個 控 制 端 （ 測 試 工 具 ） 與 手 機 上 的 一 個agent 端，通過串口、USB 或者無線方式將 PC 與手機終端相連，然後應用測試工具向手機發送請求或者命令，手機收到命令或者請求後，交給 agent 端解析，然後 agent 將這些解析的命令下發給手機的各個功能模塊所能識別的命令，調用那些功能模塊模擬操作。完成這些操作後，手機會返回一些信息，agent 可以抓取這些信息，然後傳回給 PC 端，這樣就完成了一個完整的手機自動化測試。
(2) 關鍵點在於 agent，可以利用 MMI_Command（AT comand）的方式來控制手機終端，原理就是給手機提供一個響應的接口。
(3) 而對於 PC 控制端，這個測試腳本用各種編程語言都可以，看如何定義。
3、TMTS 的 PC 端框架架(agent)說明
爲什麼需要 PC 端框架
單單依靠 Instrumentation 無法滿足跨應用測試的需求
一些功能，如在測試用例中修改服務器端數據庫，很難在移動設備端實現
PC 端框架的原理
PC 端運行時，會不停嘗試去連接 PC 本地指定端口，由於執行了 adb
forward 命令（所以要求運行測試的設備都是具有 root 權限的），PC 端實際會去連接移動設備端指定端口
移動設備端框架在運行時會啓動一個 ServerSocket，監聽來自 PC 端的
Socket 請求
移動設備端發送 athrun 自定義格式的命令至 PC 端，PC 端收到後收到後
會解析命令，然後執行具體的操作，將結果再通過 socket 發送至移動設備端
PC 端目前提供的功能
首先以下功能的 API 都在 framework 中提供，agent 只是負責實現這些功
通過 Android 系統中 monkey 去點擊屏幕上一個點或是物理按鍵（目前建立與 monkey 的通信機制，暫提供這兩項操作，可根據自身需求進行擴展）
修改服務器端（android 應用是客戶端）的數據
在模擬器上模擬來電，模擬短信
二、關鍵技術實現
1、消息傳送機制
利用手機 Modem 中提供的 AT Command 通過串口向手機端建立命令消息通訊，目前手機廠商提供了常用的 AT Command，基本滿足普通的自動化測試需求。
2、圖像識別
圖像識別主要通過抓取 LCD 屏幕顯示圖像進行智能識別來模擬測試工程師的雙眼辨識文字或圖像信息，以此判斷測試結果。主要涉及圖像的獲取和對比分析，智能識別是一個比較專業的研究領域，更進一步的研究需要進行調研，目前我們可以考慮是否能夠通過第三方工具來實現，比如藉助目前已經成熟的測試工具QTP 等。對於圖像獲取在手機平臺上應該具備這樣的接口，或者自行開發這個接口。
3、測試腳本
測試腳本的定義：
通常來說，測試腳本就是被測試工具執行的一系列指令，而不是在被測系統上執行的指令。測試腳本一般通過腳本開發人員編寫或者錄製腳本工具錄製。拿我所用的手機自動化測試工具舉例來說，被測試工具執行的是 python 腳本，而手機是用 C 開發的。最後發給手機執行的命令是通過手機 server 對測試工具發來的消息的解析。
測試腳本相關技術的目的
知道了什麼是測試腳本之後，我覺得下一步應該去想一想爲什麼要去探討這些技術，這些技術又給測試腳本帶來了哪些好處。
關於上面的兩個問題，我們首先得知道與測試腳本相關的兩大活動。第一個是開發，另一個是維護。這兩個活動都跟時間成正比，測試腳本的好，複雜，維護少，開發週期長；測試腳本簡單，開發週期短，維護週期長。它們之間的關係可以用如下圖來表示：
那麼把開發
腳本作爲一個工程來講的話，我們就希望用最少的時間及最少的成本去做這兩件事。使開發和維護達到一個最佳值。如此，我們探討測試腳本技術的目的也就出來了，就是減少自動化測試腳本開發和維護的成本。
好的測試腳本的特性既然我們知道了運用測試腳本技術的目的，那麼爲了達到這個目標我們就要把其具體化。那下面我們就來羅列一下好的測試腳本應該具有的特性。
1. 可維護性
2. 模塊化
3. 健壯性
4. 複用性
接下來我們要談的關於測試腳本的關鍵技術就是爲了使測試腳本具有以上這些
特性。
測試腳本關鍵技術
下面我會以所用到的手機自動化測試工具爲例，講解一個最原始的”腳本”
如何運用這些技術對腳本進行封裝和設計使其演變成一個高級的好的測試腳本 。
首先我們來看看最原始的腳本使個什麼樣子，你可以這樣理解，它是最後運
行在被測軟件上的那段代碼，嚴格上來說，它都不能被稱爲腳本，所以我給加上
引號。就那我所用的手機測試工具來說吧，最原始的腳本就是一個自定義的 xml
結構的消息。xml 結構通常如下，
<teststep>
<key_input_sequence>
<key/>
</key_input_sequence>
<expect>
<display/>
</expect>
</teststep>上 面 的 xml 消 息 由 自 動 化 測 試 工 具 的 客 戶 端 通 過 usb 數 據 線 發 給 手 機 的 test
server 端，test server 端對消息進行解析，然後再由 Server 端發給相關 Server 。
這些相關 Server 在這裏通常是 keyboard server 和 window server. Keyboard
server 通 常對 接受 到的 按鍵序列 進行 響應，test server 會 從 Window server
獲得手機的 UI 信息並和 expect 的值進行對比。
現在我們就要對這個最原始的腳本進行設計和封裝。
1．線性腳本
線性腳本是我們對最原始的腳本的第一次封裝，線性腳本就是簡單的測試腳本，形象的來定義就是我們通常錄製手工測試用例得到的腳本，這些腳本由低層次的一些函數組成，這些低層次的函數通常由測試框架來提供。他們通常提供按鍵，移動，輸入數據，比較數據的功能。比如筆者的手機自動化測試工具所提供的相關函數有 pressKey(),expectText(),
expectAnimation()，expectBitmap()函數。通過線性腳本使我們遠離了編寫 xml消息的繁雜，我們只需根據測試用例錄製腳本就能完成測試腳本的編寫，這邁出了自動化測試腳本編寫的第一步，我們來看看線性腳本的特點。
簡單，開發週期短
沒有邏輯判斷，也就是說編程語言中的控制語句 if,else,while
可維護性差，腳本很差，只要 case 發生一點變化，就要進行重新錄製
沒有複用性
讓我們用好的測試腳本所具備的特點來判斷，基本都不符合。所以線性腳本不是我們最終所追求的腳本，我們還需繼續努力。
2．結構化腳本
自動化腳本的價值體現在腳本的複用，複用的次數越多，價值也就越大。爲了提高腳本的複用性，引用了結構化設計的腳本。結構化腳本就是在原有線性腳本的基礎上增加了各種邏輯結構，包括選擇性結構，分支結構，循環迭代結構，還具有函數調用功能。這樣就可以使腳本模塊化，使腳本具有複用性，維護性也得到了提高。但依然存在問題，比如，測試數據和測試邏輯混在一起，相當於測試數據硬編碼在腳本中，於是我們引入了數據驅動這個技術。
3.數據驅動腳本
結構腳本健壯性已經很好了，但是缺點還是有的，通過研究測試用例一般分爲測試數據和測試邏輯。就能發現結構化腳本沒有把這兩個分開，測試數據還是和測試邏輯黏在一起，這樣就會給維護帶來複雜性，比如，我們只想改改測試數據，我們不得不去動測試邏輯相關的腳本。這樣就很可能會無意中破壞測試邏輯。如果把兩者分開，則可以保證兩者的修改無不影響。這樣對 tester 來說修改測試數據就變的容易了，而不需要去懂腳本相關的知識。另外數據驅動腳本也進一步提高了腳本的複用性，尤其是對那些只需改動測試數據的測試用例，測試邏輯腳本得到了複用。而在原來的結構化腳本是不行的。其實數據驅動這項技術不僅在測試中用到，在開發中也在用，就比如 web 開發，html 語言，wpf 的 xaml,moziila
的 xul 等的一些 xml 方式的界面開發都應該是數據驅動的。筆者的自動化測試工具就是用的 xml 來定義測試數據，然後通過對 xml 的解析來導入所需的數據從而建立相關的測試模型。
4.關鍵字驅動腳本
關鍵字 驅動 就是 面向腳本 開發工程師和 tester.使 他們編寫 腳本 和閱 讀腳 本更加容易。就拿筆者使用的測試工具來說吧，比如要通過手機的 option 選項來選擇 option 菜 單 中 的 某 一 項 ， 如 果 不 用 關 鍵 字 驅 動 腳 本 ， 我 們 就 會 寫 一 大 堆pressKey（）的按鍵序列，來讓手機執行這些按鍵命令，這樣對 tester 就很不友好，這些按鍵序列其實應該是面向機器的。如果用了關鍵字驅動腳本，我們會提供 select 關鍵字，然後提供 item 參數。加入關鍵字驅動技術後，同樣實現這
個功能，只需調用函數 select(item)即可，這樣既利於腳本編寫，也利於維護。
因爲，從維護的角度來看，你只需要維護 select(item)這個方法。
這些技術都不是各自獨立存在的，是相互共存的。講完了這些測試腳本技術，那麼我們可以對測試腳本語言的選擇有一些瞭解。爲了實現這些測試腳本技術，我們的腳本語言一定要擴展性好，那麼自己定製的測試腳本語言在擴展性方面就比較差，所以我們要選擇標準的測試腳本語言，比如 python,vb,tcl,ruby.它們的擴展性好，功能強大，能良好的與開發人員進行溝通。