本發(fā)明涉及嵌入式技術(shù)領(lǐng)域,特別是涉及一種嵌入式Linux產(chǎn)品的測試方法、裝置及系統(tǒng)。
背景技術(shù):
嵌入式系統(tǒng)是一種專用的計算機系統(tǒng),作為裝置或設備的一部分。事實上,所有帶有數(shù)字接口的設備,如手表、微波爐、錄像機、汽車等,都使用嵌入式系統(tǒng)。一個嵌入式系統(tǒng)裝置一般都由嵌入式計算機系統(tǒng)和執(zhí)行裝置組成,嵌入式計算機系統(tǒng)是整個嵌入式系統(tǒng)的核心,由硬件層、中間層、系統(tǒng)軟件層和應用軟件層組成。執(zhí)行裝置也稱為被控對象,它可以接受嵌入式計算機系統(tǒng)發(fā)出的控制命令,執(zhí)行所規(guī)定的操作或任務。
Linux為一種基于POSIX和UNIX的多用戶、多任務、支持多線程和多CPU的操作系統(tǒng),Linux產(chǎn)品即運行Linux操作系統(tǒng)的產(chǎn)品。一般情況下,在嵌入式系統(tǒng)中,Linux產(chǎn)品的測試方法都是針對特定平臺的特定硬件進行測試,對于一個擁有多種外設設備的嵌入式Linux產(chǎn)品來說,多個硬件設備就有多個對應的測試程序,需要分模塊多次測試及控制。比如要測試某產(chǎn)品的LED和USB功能,兩個測試程序只能分別地單獨運行,并且只能按照固定的執(zhí)行順序逐項進行測試。然而嵌入式產(chǎn)品正常工作時都是多組硬件模塊同時運行的,因此現(xiàn)有的嵌入式Linux產(chǎn)品測試方法無法排除硬件模塊之間的相互干擾。
技術(shù)實現(xiàn)要素:
基于此,本發(fā)明實施例提供了嵌入式Linux產(chǎn)品的測試方法、裝置及系統(tǒng),能夠有效測試嵌入式Linux產(chǎn)品中各個硬件模塊間的相互影響。
本發(fā)明一方面提供嵌入式Linux產(chǎn)品的測試方法,包括:
檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描預設的目錄;所述目錄下包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊;
加載所述目錄下的全部測試模塊,并分別為各個測試模塊分配一線程;
啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試。
本發(fā)明另一方面提供一種嵌入式Linux產(chǎn)品的測試裝置,包括:
掃描模塊,用于檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描預設的目錄;所述目錄下包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊;
線程分配模塊,用于加載所述目錄下的全部測試模塊,并分別為各個測試模塊分配一線程;
測試控制模塊,用于啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試。
一種嵌入式Linux產(chǎn)品的測試系統(tǒng),包括:測試服務器和測試模塊管理單元,所述測試服務器和所述測試模塊管理單元之間通過網(wǎng)絡socket進行信息交換;
所述測試模塊管理單元中包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊;
所述測試服務器,用于若檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描所述測試模塊管理單元中的全部測試模塊,并分別為各個測試模塊分配一線程;以及用于啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試。
基于上述實施例提供的嵌入式Linux產(chǎn)品的測試方法、裝置及系統(tǒng),在檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描預設的目錄;所述目錄下包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊;加載所述目錄下的全部測試模塊,并分別為各個測試模塊分配一線程;啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試,因此能更好地模擬產(chǎn)品的正常使用狀態(tài),有效地測試出各硬件設備間的耦合性,排除產(chǎn)品故障;并且與傳統(tǒng)的測試方法相比,還增加了測試的靈活性,節(jié)省大量的測試時間。
附圖說明
圖1為一實施例的嵌入式Linux產(chǎn)品的測試方法的示意性流程圖;
圖2為一實施例的嵌入式Linux產(chǎn)品的測試方法的原理示意圖;
圖3為另一實施例的嵌入式Linux產(chǎn)品的測試方法的原理示意圖
圖4為一實施例的嵌入式Linux產(chǎn)品的測試裝置的示意性結(jié)構(gòu)圖;
圖5為一實施例的嵌入式Linux產(chǎn)品的測試系統(tǒng)的測試原理示意圖。
具體實施方式
為了使本發(fā)明的目的、技術(shù)方案及優(yōu)點更加清楚明白,以下結(jié)合附圖及實施例,對本發(fā)明進行進一步詳細說明。應當理解,此處所描述的具體實施例僅僅用以解釋本發(fā)明,并不用于限定本發(fā)明。
圖1為一實施例的嵌入式Linux產(chǎn)品的測試方法的示意性流程圖;如圖1所示,本實施例中的嵌入式Linux產(chǎn)品的測試方法包括步驟:
S11,檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描預設的目錄;所述目錄下包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊。
在一優(yōu)選實施例中,在步驟S11之前,還包括以下步驟:獲取待測硬件設備,預設各待測硬件設備對應的測試模塊,將全部測試模塊統(tǒng)一存放到一設定目錄下。本實施例中,預先把每個待測硬件設備的測試程序設置為一個獨立模塊,將這些測試模塊放在一個單獨的目錄下,通過將測試程序模塊化,可以根增強測試的靈活性。
本實施例中每個測試模塊中測試程序都包括初始化、測試執(zhí)行、執(zhí)行結(jié)束三個階段。
S12,加載所述目錄下的全部測試模塊,并分別為各個測試模塊分配一線程;
每次當Linux系統(tǒng)啟動時,首先啟動測試服務器,測試服務器中的服務器程序掃描對應目錄下的測試模塊并進行加載,并給各個測試模塊分配一條線程任務。與進程方式相比,線程能節(jié)省系統(tǒng)資源。
在一優(yōu)選實施例中,如圖2所示,加載所述目錄下的全部測試模塊,并分別為各個測試模塊分配一線程之后,先對各個測試模塊中的測試程序進行初始化,初始化后控制各個測試模塊對應的線程進入阻塞狀態(tài),當需啟動對應的測試模塊進行測試時,才可知對應的線程進入執(zhí)行狀態(tài)。
S13,啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試。
本實施例中,可同時啟動多線程,使得多個測試模塊中的測試程序同時執(zhí)行,每個測試模塊各用一個線程,根據(jù)不同的時間片去執(zhí)行各自的初始化、執(zhí)行和結(jié)束操作。由于產(chǎn)品中的若干待測硬件設備可以同時處于工作狀態(tài),因此可有效測試出硬件設備之間的相互影響。
在一優(yōu)選實施例中,參考圖3所示,在啟動各測試模塊對應的線程之后,還將接收各測試模塊返回的測試結(jié)果信息并進行顯示,各測試模塊的測試程序在執(zhí)行結(jié)束時,返回對應的測試結(jié)果信息。
優(yōu)選的,繼續(xù)參考圖3,采用網(wǎng)頁形式對測試模塊返回的測試結(jié)果信息進行顯示。用戶的所有操作均在網(wǎng)頁上進行,并直觀顯示測試結(jié)果,簡化了操作;通過網(wǎng)頁框架還可以直接移植到其他Linux嵌入式平臺,用戶無需了解網(wǎng)頁相關(guān)的知識,只需要編寫簡單的測試模塊即可。
在一優(yōu)選實施例中,還可從測試模塊返回的測試結(jié)果信息中識別出測試異常信息,將所述測試異常信息存儲到預設的異常記錄文件,例如得到對應的log文件。由此可對測試出的錯誤狀態(tài)log信息及時保存和查看,每次測試生成一個錯誤信息文件。
本實施例中,各測試模塊的屬性信息包括:單項單次測試、單次測試或者循環(huán)測試。其中單項單次測試針對的是蜂鳴器、LED、觸摸屏等需要用戶主觀判斷的硬件設備,對于這些硬件設備不適于采用連續(xù)的循環(huán)測試,為了避免用戶在循環(huán)測試中過于頻繁地“確認”這類硬件設備功能的完整性,可為此類設備設定了單項單次測試模式,即在測試中會彈出特定的確認信息,需要用戶主觀地判斷測試現(xiàn)象,這種單項單次測試模式不能切換到多線程的循環(huán)測試中,即不會將該測試模塊加入多線程測試,其屏蔽模式切換指令,且有獨立的判斷顯示邏輯。若測試模塊的屬性信息為單次測試,則也不會將該測試模塊加入多線程測試,但是用戶可以對其模式進行切換,即若接收到對此類測試模塊屬性的第一切換指令,則為該測試模塊分配一線程;若測試模塊的屬性信息為循環(huán)測試,則控制該測試模塊初始化,將該測試模塊加入多線程測試;當然用戶也可對此類測試模塊的屬性進行切換,即若接收到第二切換指令,則關(guān)閉該測試模式,并撤銷該測試模塊對應的線程。
單次測試和循環(huán)測試的具體說明如下:
單次測試是為了兼容傳統(tǒng)的普通設備測試,這是一種簡單的測試方法。上文提到,所有的測試模塊都放在同一個目錄下,當服務器程序掃描該目錄并加載測試模塊時,服務器程序會根據(jù)測試模塊加載的順序分配id,并把測試模塊信息保存在系統(tǒng)內(nèi)部的全局測試模塊鏈表中,當測試人員對所有測試項進行測試時,測試程序會根據(jù)全局測試模塊鏈表中的測試順序,即加載模塊的先后順序,對每個測試模塊按照“初始化->測試執(zhí)行->執(zhí)行結(jié)束”的測試流程進行測試,實際上各個測試程序是按順序先后執(zhí)行的,不會并發(fā)執(zhí)行,故難以測試出硬件設備之間的相互影響。
循環(huán)測試是在多線程模式下進行的連續(xù)不斷的測試。然而在外設設備輔助測試硬件欠缺,需要對同一產(chǎn)品在不同時刻使用不同的外設進行測試的情況下,為了減少測試人員在操作測試中的嵌入式產(chǎn)品時出錯,加入了“模式轉(zhuǎn)換”的控制方法,即在不重啟測試產(chǎn)品系統(tǒng)的情況下,停止所有多線程測試后,通過把應當需要進行單次測試的測試項的執(zhí)行模式轉(zhuǎn)為單次測試的測試項,使得該測試項從多線程循環(huán)測試中“剔除”,避免測試出錯;當條件允許時再將對應測試模塊“轉(zhuǎn)換”成多線程循環(huán)測試項進行即可測試。同理,對于原本的單次測試項,當實際情況需要進行循環(huán)測試時,也可在不重啟測試產(chǎn)品系統(tǒng)的情況下,停止所有多線程測試后,將對應的測試模塊轉(zhuǎn)換為循環(huán)測試,為其分配一線程即可。便于測試人員根據(jù)實際需求靈活調(diào)整測試策略。
相應的,在一優(yōu)選實施例中,在分別為各個測試模塊分配一線程之后,還包括:檢測各測試模塊的屬性信息是否為循環(huán)測試,若否,刪除該測試模塊對應的線程。
上述實施例的嵌入式Linux產(chǎn)品的測試系統(tǒng),采用“服務—模塊”方式加載測試程序,把每個測試程序做成一個獨立模塊,這些測試模塊會放在一個單獨的目錄下,每次系統(tǒng)啟動時首先啟動測試服務器,服務器程序再掃描對應目錄下的測試模塊進行加載,并給各個測試模塊分配一條線程任務,與進程方式相比,線程能節(jié)省系統(tǒng)資源。
需要說明的是,對于前述的各方法實施例,為了簡便描述,將其都表述為一系列的動作組合,但是本領(lǐng)域技術(shù)人員應該知悉,本發(fā)明并不受所描述的動作順序的限制,因為依據(jù)本發(fā)明,某些步驟可以采用其它順序或者同時進行。此外,還可對上述實施例進行任意組合,得到其他的實施例。
基于與上述實施例中的嵌入式Linux產(chǎn)品的測試方法相同的思想,本發(fā)明還提供嵌入式Linux產(chǎn)品的測試裝置,該裝置可用于執(zhí)行上述嵌入式Linux產(chǎn)品的測試方法。為了便于說明,嵌入式Linux產(chǎn)品的測試裝置實施例的結(jié)構(gòu)示意圖中,僅僅示出了與本發(fā)明實施例相關(guān)的部分,本領(lǐng)域技術(shù)人員可以理解,圖示結(jié)構(gòu)并不構(gòu)成對裝置的限定,可以包括比圖示更多或更少的部件,或者組合某些部件,或者不同的部件布置。
圖4為本發(fā)明一實施例的嵌入式Linux產(chǎn)品的測試裝置的示意性結(jié)構(gòu)圖;如圖4所示,本實施例的嵌入式Linux產(chǎn)品的測試裝置包括:掃描模塊310、線程分配模塊320以及測試控制模塊330,各模塊詳述如下:
所述掃描模塊310,用于檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描預設的目錄;所述目錄下包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊;
所述線程分配模塊320,用于加載所述目錄下的全部測試模塊,并分別為各個測試模塊分配一線程;
所述測試控制模塊330,用于啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試。
本發(fā)明還提供一種嵌入式Linux產(chǎn)品的測試系統(tǒng),包括:測試服務器和測試模塊管理單元,所述測試服務器和所述測試模塊管理單元之間通過網(wǎng)絡socket進行信息交換。其中,所述測試模塊管理單元中包含有預設的所述嵌入式Linux產(chǎn)品中各待測硬件設備對應的測試模塊;所述測試服務器,用于若檢測到嵌入式Linux產(chǎn)品的系統(tǒng)啟動,啟動預設的服務器程序,通過所述服務器程序掃描所述測試模塊管理單元中的全部測試模塊,并分別為各個測試模塊分配一線程;以及用于啟動各測試模塊對應的線程,以多線程方式對各待測硬件設備進行并發(fā)測試。
在一優(yōu)選實施例中,參考圖5所示,測試服務器與測試模塊管理單元之間的通訊通過網(wǎng)絡socket進行信息交換,測試服務器啟動的時候建立了TCP/IP的socket服務,在加載模塊的時候,測試服務器會把相關(guān)的socket信息傳到測試模塊上共同保存于全局的測試模塊鏈表中,加載模塊結(jié)束后,其控制由測試服務器中統(tǒng)一的測試控制模塊去控制,測試控制模塊會通過socket對測試模塊管理單元中對應的測試模塊發(fā)送單項單次測試、一鍵多項測試、循環(huán)測試、測試暫停、停止測試等指令信號,同時,測試模塊管理單元中測試模塊把執(zhí)行過程中的測試狀態(tài)(成功或失敗)通過socket傳到測試服務器,通過測試服務器進行網(wǎng)頁顯示。為了更好地追溯測試過程中硬件產(chǎn)生的問題,測試服務器中還添加了錯誤信息保存模塊。例如,每次測試服務器啟動時都會生成一個用于保存本次測試的錯誤信息的空log文件,而測試模塊管理單元中每個測試模塊都有“反饋問題”的能力,如果測試模塊在運行過程中產(chǎn)生錯誤信息,測試模塊管理單元將通過socket把該測試模塊的錯誤信息返回到測試服務器,并寫入到所述log 文件中,用戶可通過服務器發(fā)起讀取文件的指令,獲取所述log文件中記錄的信息,并將所述信息以網(wǎng)頁形式進行顯示。
本實施例的測試服務器中,控制模塊和網(wǎng)頁顯示模塊是基于開源的Web服務器—Goahead Webserver開發(fā)的,它是構(gòu)建在設備管理框架之上的一種網(wǎng)絡服務器,在Goahead上部署服務器框架,不需要額外地對網(wǎng)絡服務器進行編程。
測試模塊是與測試服務器相匹配的一種測試框架,能被測試服務器識別。測試服務器從網(wǎng)頁上接受到相應命令后通過socket把相關(guān)的命令發(fā)送到測試模塊管理單元中的測試模塊,從測試模塊處調(diào)用相應的操作函數(shù)。
在一優(yōu)選實施例中,測試模塊管理單元中各測試模塊的接口信息如表1所示。
表1:
在上述實施例的嵌入式Linux產(chǎn)品的測試系統(tǒng)實施例中,測試模塊管理單元中的每個測試模塊中的測試程序都包括初始化、測試執(zhí)行、執(zhí)行結(jié)束三個階段,且所述測試服務器和測試模塊管理單元以及各測試模塊之間也是相互獨立的,即測試模塊并不會影響測試服務器的運行,測試服務器掃描到對應的測試模塊后,生成線程,加載測試模塊并進行初始化,初始化后對應的線程會阻塞,等待測試模塊管理單元進行控制。并且測試模塊管理單元可以同時打開所有線程,讓多個測試模塊同時進入測試模式。使用這種方法測試,能更好地模擬產(chǎn)品的正常使用狀態(tài),有效地測試出各硬件設備間的耦合性,排除產(chǎn)品故障。與傳統(tǒng)的測試方法相比,增加了測試的靈活性,節(jié)省大量的測試時間,增強測試效率。
需要說明的是,上述示例的嵌入式Linux產(chǎn)品的測試裝置的實施方式中,各模塊之間的信息交互、執(zhí)行過程等內(nèi)容,由于與本發(fā)明前述方法實施例基于同一構(gòu)思,其帶來的技術(shù)效果與本發(fā)明前述方法實施例相同,具體內(nèi)容可參見本發(fā)明方法實施例中的敘述,此處不再贅述。
此外,上述示例的嵌入式Linux產(chǎn)品的測試裝置的實施方式中,各功能模塊的邏輯劃分僅是舉例說明,實際應用中可以根據(jù)需要,例如出于相應硬件的配置要求或者軟件的實現(xiàn)的便利考慮,將上述功能分配由不同的功能模塊完成,即將所述嵌入式Linux產(chǎn)品的測試裝置的內(nèi)部結(jié)構(gòu)劃分成不同的功能模塊,以完成以上描述的全部或者部分功能。其中各功能模既可以采用硬件的形式實現(xiàn),也可以采用軟件功能模塊的形式實現(xiàn)。
本領(lǐng)域普通技術(shù)人員可以理解,實現(xiàn)上述實施例方法中的全部或部分流程,是可以通過計算機程序來指令相關(guān)的硬件來完成,所述的程序可存儲于一計算機可讀取存儲介質(zhì)中,作為獨立的產(chǎn)品銷售或使用。所述程序在執(zhí)行時,可執(zhí)行如上述各方法的實施例的全部或部分步驟。其中,所述的存儲介質(zhì)可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory,ROM)或隨機存儲記憶體(Random Access Memory,RAM)等。
在上述實施例中,對各個實施例的描述都各有側(cè)重,某個實施例中沒有詳述的部分,可以參見其它實施例的相關(guān)描述。
以上所述實施例僅表達了本發(fā)明的幾種實施方式,不能理解為對本發(fā)明專利范圍的限制。應當指出的是,對于本領(lǐng)域的普通技術(shù)人員來說,在不脫離本發(fā)明構(gòu)思的前提下,還可以做出若干變形和改進,這些都屬于本發(fā)明的保護范圍。因此,本發(fā)明專利的保護范圍應以所附權(quán)利要求為準。