一種WLAN自動(dòng)化測試平臺的設計及實(shí)現
加入技術(shù)交流群
2．1 總體框架
控制臺為測試平臺的核心部分，主要負責終端設備的遠程控制、測試任務(wù)的配置以及分發(fā)、測試結果的收集與顯示等工作?？刂婆_通過(guò)有線(xiàn)網(wǎng)絡(luò )與AP終端群、網(wǎng)卡終端群進(jìn)行控制流的交互，為了有效隔離無(wú)線(xiàn)通信鏈路與有線(xiàn)鏈路的數據流，控制臺可采用雙網(wǎng)卡模式或者VLAN技術(shù)進(jìn)行子網(wǎng)的劃分，確保網(wǎng)卡終端群與AP終端群的有線(xiàn)鏈路隔離。
當測試對象為網(wǎng)卡時(shí)，AP終端群作為測試支持設備工作，此時(shí)采用固件升級為DD-WRT的AP設備，接收來(lái)自控制臺的配置命令來(lái)組建不同類(lèi)型的網(wǎng)絡(luò )，以配合網(wǎng)卡終端群完成如加網(wǎng)、漫游、速率等功能的測試。
作為待測試對象時(shí)，網(wǎng)卡終端群通過(guò)接收來(lái)自控制臺的命令執行相應的測試腳本，完成BSS以及IBSS網(wǎng)絡(luò )功能的檢測。作為支持設備時(shí)，網(wǎng)卡終端群則充當驗證AP設備功能的角色。
Linux認證服務(wù)器采用OpenSSL技術(shù)提供應用層的認證，為網(wǎng)卡設備加入lli企業(yè)級模式提供認證服務(wù)。
Packets服務(wù)器主要有兩個(gè)作用：第一，作為基本的抓包工具，對測試過(guò)程中空中特定的包進(jìn)行捕獲和解析，用以配合功能測試中對測試結果的分析。第二，該服務(wù)器充當灰盒級測試功能的主體，通過(guò)對底層驅動(dòng)的修改以及對包的捕獲、過(guò)濾、修改、轉發(fā)等完成各種極限或特定場(chǎng)景的模擬測試。
在實(shí)際過(guò)程中，網(wǎng)卡設備工作的環(huán)境可以各不相同，如部分終端為L(cháng)inux環(huán)境，部分終端為Windows環(huán)境，通過(guò)控制臺進(jìn)行分發(fā)不同的測試腳本即可屏蔽測試設備終端的環(huán)境差異。
2．2 控制流程
根據測試平臺總體框架，可以將軟件框架分為四個(gè)模塊；測試用例管理模塊、平臺通信管理模塊、測試過(guò)程管理模塊、測試結果管理模塊，如圖3所示。本文引用地址：http://dyxdggzs.com/article/194002.htm
測試用例管理模塊負責測試用例的抽取、腳本參數的配置等功能。當配置完成后，通過(guò)通信管理模塊將測試腳本以及參數分發(fā)給測試平臺中的各個(gè)終端設備，接下來(lái)，由測試過(guò)程管理模塊負責完成整個(gè)測試執行工作，同時(shí)記錄測試執行的結果以及日志等信息，最后由測試結果管理模塊對測試結果進(jìn)行提取與分析，形成最終的測試報告。
在各個(gè)功能模塊中，平臺通信管理模塊是基礎，為其他模塊提供了控制通路。測試過(guò)程管理模塊對整個(gè)測試過(guò)程進(jìn)行凋控，實(shí)現測試過(guò)程的自動(dòng)化，保證過(guò)程的順利完成。
3 WLAN自動(dòng)化測試工具的實(shí)際應用
本系統控制端運行在Linux操作系統下，采用Glade+Gtk技術(shù)完成主控界面的開(kāi)發(fā)。通過(guò)主控端分別Telnet到AP端和STA端，并采用Expe ct技術(shù)分別完成與AP端和STA端的交互，主控端作為橋梁，進(jìn)而可以完成AP端與STA端的交互，保證了時(shí)間同步性。測試執行完成后，可以在主控端收集、查看測試日志，并生成測試報告。
3．1 自動(dòng)化測試平臺的具體實(shí)現
3．1．1 遠程控制
(1)AP控制。當網(wǎng)卡作為待測試設備時(shí)，需要借助于第三方的AP設備來(lái)完成基本功能的測試，而目前市面上的AP設備大都是采用Web界面進(jìn)行配置，即使提供了Telnet等遠程控制服務(wù)，由于廠(chǎng)家處于商業(yè)層面的考慮，使用者也很難獲取其內部的配置接口。
在實(shí)現的過(guò)程中，采用開(kāi)源的DD-WRT固件來(lái)升級測試平臺內的AP設備，通過(guò)DD-WRT的公共接口命令來(lái)實(shí)現對AP設備的配置。
(2)網(wǎng)卡控制。當AP作為待測試設備時(shí)，需要借助于第三方的網(wǎng)卡設備來(lái)完成基本的功能測試。對于工作在Linux平臺的網(wǎng)卡，由于源代碼為開(kāi)源，實(shí)現配置與控制比較容易；對于工作在Windows平臺的網(wǎng)卡，可以采用Native Wifi API構建控制臺程序，結合XML形式的無(wú)線(xiàn)配置文件Wireless Profile進(jìn)行綜合的控制。
(3)認證服務(wù)器控制。對于lli證書(shū)模式的測試，必須采用認證服務(wù)器。認證服務(wù)器有兩種實(shí)現方式，一種是采用Windows Server系列所提供的服務(wù)構建，另一種是采用Linux平臺配置OpenSSL。前者的操作較為復雜，不便于遠程控制，因此本系統擬采用后者的方式構建認證服務(wù)器。
3．1．2 時(shí)間同步
測試過(guò)程中，需要對平臺內的不同終端進(jìn)行配置，如執行聯(lián)網(wǎng)的測試時(shí)，首先要配置AP組建相應的網(wǎng)絡(luò )，確保成功后再配置網(wǎng)卡進(jìn)行聯(lián)網(wǎng)操作。因此在測試過(guò)程中，如何界定事件結束的時(shí)間是一個(gè)關(guān)鍵的問(wèn)題，需要一種交互式的控制方式以反饋執行的狀態(tài)或結果。
Shell命令可以實(shí)現簡(jiǎn)單的控制流功能，但無(wú)法完成需要交互的場(chǎng)合，而Expect可以實(shí)現自動(dòng)與交互式任務(wù)進(jìn)行通信，而無(wú)需人為干預，因此在實(shí)現時(shí)將采用兩者相結合的方式來(lái)完成不同終端以及同一終端不同測試項之間的同步控制。
3．1．3 平臺無(wú)關(guān)性
測試平臺要同時(shí)考慮待測設備工作在Windows以及Linux兩種平臺環(huán)境下的測試，由于兩種平臺環(huán)境本身存在差異，而且即使相同平臺環(huán)境下也存在不同版本，使得兼容以上所有平臺環(huán)境存在一定的難度。
現在將AP端和STA端的測試腳本及控制操作都放在控制端，做到與待測設備隔離，使控制臺完成所有與測試相關(guān)的控制、配置任務(wù)，而待測終端只進(jìn)行控制命令的接收和執行，這樣就保證了測試平臺不依賴(lài)于具體的待測設備終端系統。
3．1．4 用例腳本化
一方面，平臺無(wú)關(guān)性要求將與平臺系統環(huán)境相關(guān)的測試命令進(jìn)行相應的歸類(lèi)和抽取，另一方面，測試過(guò)程中測試終端之間的控制同步對命令的批量處理也有一定的要求。此外，為了提高用例的復用度，將測試用例腳本化是一個(gè)必然的要求。
3．1．5 包分發(fā)與捕獲
一方面，對于測試過(guò)程中特定用例的幀交互過(guò)程進(jìn)行檢查，需要對空中包進(jìn)行捕獲與過(guò)濾；另一方面，對于灰盒級的測試，需要模擬各種場(chǎng)景，勢必要借助于空中包分發(fā)裝置來(lái)完成。
評論