JavaScript API自動化測試方案的管理設計與實現

張令芬

（河海大學 商學院，江蘇 南京　211000）

JavaScript API自動化測試方案的管理設計與實現

張令芬

（河海大學 商學院，江蘇 南京211000）

在持續集成的軟件開發過程中，企業管理者需要對每個軟件版本的JavaScript API進行自動化測試。基于Robotium框架的測試程序，通過采用捕獲被測程序的Logcat信息，之后通過解析Logcat并寫入，最終寫成方案并測試，在應用程序中，JavaScript API作為連接程序與web頁面的橋梁，擴展了內嵌web頁面的JavaScript的能力，為web應用帶來更好的體驗。所以本文使用本方案，測試人員編寫了26條測試用例，共測試了26個API，除去用例編寫的問題以及一些不適合使用自動化來測試的API，方案的準確性達到100%。結果方案的實施結果證明了本方案是可行的。這為以后的研究奠定了堅實的基礎。

應用程序；JavaScript API；自動化測試；接口

在現階段的測試中，測試人員需要在測試頁面上逐一地手動觸發每個測試用例，根據返回值來判斷功能是否正常。隨著API種類的增多，加上版本迭代速度很快，手工測試變的繁瑣，浪費了很多人力物力。為代替人工測試，最終實現的工具須能夠自動化地完成以下功能：調用API、判斷返回值、計算調用耗時、判斷用例是否通過、發送郵件。

首先，測試頁面通過通用JavaScript對象調用API，回調函數等待接收返回值。返回值獲取后，判斷返回值是否正確，記錄下判斷結果與API從調用到獲得返回值之間的耗時。所有API測試完成后，將結果統一匯總并發送郵件到API相關責任人。

為實現上述功能，需要用到與相關的一些組件工具和框架。終端設備與PC之間的通信時通過Debug Bridge（ADB）來完成的。自動化測試要想順利實施則少不了Instrument工具，而Instrument的封裝則Robotium來完成，這就大大的方便了測試的進行。

1）ADB；ADB作為一種具有多種用途的命令行工具，它的運作可以借助模擬器實例或連接設備進行通訊。它是一個客戶端-服務器程序，包含3個部分：

客戶端，它運行在開發機器中。用戶通過發出的ADB命令從shell中調用客戶端。對于除此之外的工具就像ADT插件和DDMS，也有類似的功能。

服務端，在開發機器上作為后臺進程運行。服務端主要功能就是對客戶端進行管理和通信。

守護進程，它扮演的主要角色則是作為模擬器后臺進程運行。

ADB提供了一系列命令，在測試程序中可以通過命令行的方式調用。

2）Robotium：工具Robotium作為一個自動化測試的框架，它的功能很廣泛，可以全面支持混合和原生的應用。Robotium由于自身功能強大，所以可以很容易地編寫應用程和黑盒的UI測試。通過借助Robotium，測試的開發人員可以借此編寫功能、系統和驗收測試的方案，從而實現跨越多個Activity的功能。

由于本工具涉及到測試程序與被測程序之間的數據交換，而基于Robotium的測試程序能夠與被測程序處于同一進程中，為測試程序獲取被測程序的數據提供了有利條件。

1　系統設計

有關系統架構如圖1所示。

圖1　系統架構Fig．1　System architecture

控制模塊總控其他模塊的執行，并監測系統的運行情況，捕獲產生的異常。控制模塊控制整體流程，從檢查安裝包的版本、檢查測試程序與被測程序的安裝情況，到控制測試頁面中測試用例的自動執行等。工具在控制模塊的控制下完成一系列操作。

web模塊包含web頁面以及應用程序內嵌的web瀏覽器。web模塊初始化自動化測試用例中用到的JavaScript對象，定義測試用例執行的順序、時間間隔等參數。與之相關聯的測試用例模塊是該模塊的子模塊，測試用例模塊包含需要進行測試的API的用例。每個用例包含以下參數：

［用例名］［用例功能描述］［返回值］［測試結果］

API調用耗時由工具自動計算出，不包含在用例中。測試人員需要手動在此模塊添加測試用例。

數據統計模塊負責獲取每個API的用例參數（如上述）、計算API的調用耗時，并判斷用例是否通過。最終將獲得的數據寫入html文件。

郵件發送模塊負責發送郵件。

根據系統架構可以梳理出本工具的系統流程。如圖2所示。

圖2　系統流程Fig．2　System flow

自動化測試啟動后，執行程序檢查測試程序、被測程序等一系列測試前的準備工作，一切就緒后，測試程序啟動。測試程序通過Robotium提供的方法操作被測程序加載測試頁面。測試頁面是本地的，通過代理的方式載入被測程序的webView中。測試程序在測試頁面載入之后開始捕獲Logcat，并解析出相應字段，以html的格式寫入文件中。測試完畢后，將html以郵件的形式發送給相關人。

1.1測試程序

1.1.1基于Robotium框架的測試程序

Robotium作為一種工具，主要是建立在一個基于應用程序的自動化黑盒基礎之上。它使測試用例的編寫得到了大大的簡化，并且能夠編寫出黑盒測試程序用例，這種工具使得編寫出來的這種應用功能強大、健壯性很強。通過對Robotium應用，測試人員能夠編寫測試用例，系統測試，驗收測試方案等。

新建一個 Test Project，將測試工程指向設置為 this project，建立完成后引入Robotium需要使用的jar包。

由于內置瀏覽器所在Activity非啟動Activity，而應用程序也不支持直接喚起內置瀏覽器，所以在進行測試的過程中需要通過被測程序的內置瀏覽器加載測試頁面，故采用點擊界面元素跳轉的方法，借助Robotium實現界面跳轉。Robotium中的Solo類提供了一系列對Activity中的界面元素進行操作的方法，通過識別Activity中的控件樹來識別指定的元素。

1.1.2捕獲被測程序的Logcat信息

測試頁面、測試程序、被測程序之間沒有相互通信的媒介，測試頁面中的測試用例執行后產生的結果如何獲取是一個難點。Logcat作為平臺提供的系統功能能夠解決這一問題。日志系統提作為一種系統，為收集和對系統調試過程中出現的問題進行檢查提供了可能。這樣一來循環的緩沖區中就收集了各個系統的應用日志，如果需要對這些日志進行查看和過濾則需要借助logcat的命令可以實現這種功能。測試頁面中打出的log可以被Logcat收集，而根據單元測試原理，測試程序與被測程序是處于同一進程中的，這為測試程序獲取被測程序的Logcat提供了很大便利。

1.1.3解析Logcat并寫入

工具自定義的Logcat中測試頁面的log元數據結構如下：

#［標記］:［內容］

每條log的數據結構如下：

［時間］#［標記1］:［內容］#［標記2］:［內容］……#［標記n］:［內容］

根據定義的以上結構，在測試程序中解析出相應字段。

在測試程序中將獲得的結果寫入文件中，格式為html，便于郵件的發送與展示。

1.1.4簽名

系統要求所安裝的應用程序被相應的開發者簽名。它主要是作為識別應用程序的作者和建立應用程序之間的信任關系的一種手段。所以在進行測試的過程中，程序必須保持和被測程序的簽名保持一致。

使用如下方法為測試程序簽名：

jarsigner-verbose-keystore-release-key．keystore-storepass luozhifan@tencent-2010-keypass luozhifan@tencent-2010-digestalg SHA1-sigalg MD5withRSA-signedjar QQJsApiTest-release-signed．apk QQJsApiTest-release-unsigned．apk releasekey

其中各參數說明如表1。

1.2測試頁面

測試頁面由被測程序的內置瀏覽器加載，頁面中寫入需要測試的API接口的測試用例。當頁面加載完成后觸發onload方法時，頁面自動執行測試用例，將獲得的接口返回值以相應的格式打入Logcat，從而被測試程序捕獲。

表1　jarsigner參數說明Tab.1 Jarsigner parameter description

2　方案實施

測試人員首先在測試頁面下按照格式編寫測試用例。然后將終端設備通過數據線與計算機連接。計算機需要安裝并配置SDK。執行測試需要配置環境，即HTTP代理。使用HTTP協議調試代理工具fiddler將測試程序中的url對應的返回結果替換為本地的測試頁面。測試設備與PC須處于同一無線局域網中。同時將測試設備的Wifi代理配置為所連PC的無線局域網的IP地址。

方案的執行流程如圖3所示。

圖3　執行流程Fig．3　Implementation process

執行過程的界面如圖4所示。

執行程序入口腳本test．py后，測試啟動。測試完成后，給出測試信息，“．”代表通過的測試用例，“Time”給出完成測試的時間，單位是“秒”。測試完成后給出測試完成的信息。最后將測試報告導入計算機，并發送郵件。

最終生成并發送的測試報告如圖5所示。

圖4　界面Fig．4　Interface

圖5　測試報告Fig．5　Test Report

報告首部給出本次測試的通過率，包含接口總數、通過接口數、不通過接口數、通過率幾項。測試用例詳情給出了每個測試用例的用例名稱、功能描述、返回值、耗時和是否通過幾項。耗時的單位為毫秒，不通過的用例用紅色標記顯示。

為了驗證自動化測試工具返回的耗時是否準確，統計各API單獨執行返回的時間，進行比較，結果現實第2、3、4、6、 8、9、10、11、12、13、14、15、16、17個案例此時結果所用的自動化耗時與單獨耗時的時間是相同的，可以得出自動化測試所得耗時是很準確的。

3　結　論

使用本方案，測試人員編寫了26條測試用例，共測試了26個API，除去用例編寫的問題以及一些不適合使用自動化來測試的API，方案的準確性達到100%。

方案的實施結果證明了本方案是可行的。但是在局部的設計上還存在一些不足。主要體現在需要配置較為復雜的測試環境，例如使用代理的方式替換測試頁面在實施過程中會較為繁瑣。其次，使用界面跳轉方式調出內置瀏覽器，對UI的依賴較強，不具有擴展性。因此，研究優化測試頁面的替換策略將是未來需要解決的重要問題。

［1］肖冬平，李玲琳．軟件系統中性能測試方案的設計與實現［J］．企業技術開發，2014（13）:21-22．

［2］蔡增柱．基于移動平臺測試相關技術研究［D］．廣州：華南理工大學，2012．

［3］何偉．基于移動平臺的應用軟件性能優化技術研究［J］．計算機光盤軟件與應用，2014（12）:87-90，98．

［4］劉博．平臺上針對UI控件的測試工具的設計與實現［D］．哈爾濱：哈爾濱工業大學，2013．

［5］劉鑫正，陳玉華，黃利，等．智能終端功耗自動化測試系統的研究與設計［J］．電子測量技術，2014（9）:79-82，97．

［6］祝犇．基于爬蟲的Web測試生成系統的設計與實現［J］．蘇州科技學院學報：自然科學版，2014（3）：56-62．

［7］陳玉華，劉鑫正，蔡成亮，等．射頻全自動化測試系統的設計與實現［J］．電子測量技術，2013（9）:9-13．

［8］陳江勇，許力，張輝，等．Web自動化測試框架的設計與實現［J］．福建師范大學學報：自然科學版，2013（4）:39-45．

JavaScript API management design and implementation of automated testing program

ZHANG Ling-fen
（Hohai University Business School，Nanjing 211000，China）

In the continuous integration of the software development process，companies′s management need automated testing of each software version of JavaScript API．Robotium framework based on test procedures，test procedures by capturing Logcat information Logcat after parsing and writing the final written plan and test the application，JavaScript API with a web page as a connecting bridge program extends the embedded web ability of JavaScript page，for a better experience web application．So this use of the program，testers prepared the 26 test cases were tested 26 API，removing the problem and use cases that are not prepared for the use of automation to test the API，the program reaches 100%accuracy．Results prove that the implementation of this scheme is feasible．This has laid a solid foundation for future research．

applications；JavaScript API；automated testing；interface

TN31

A

1674－6236（2016）02-0035-03

2015-03-11稿件編號：201503155

張令芬（1986—），女，山東滕州人，碩士研究生。研究方向：財務管理。