專利名稱：一種電子類設備的自動測試方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及電子類儀器設備測試過程中的自動測試方法，尤其涉及電子類儀器設 備的檢定、校準過程的自動化。
背景技術：
電子類儀器種類、廠家、型號繁多，單臺儀器的功能也越來越多，由此導致的出廠 測試、定期校準以及強制檢定等環(huán)節(jié)的工作量非常繁重。目前，在自動測試或自動校準軟件方面，一些儀器廠商，開發(fā)了 一些針對本廠儀器 的自動測試軟件，這些軟件在兩方面存在局限性。一是，所使用的標準儀器和被測設備都只 能是該廠商的產(chǎn)品，不能添加進其他廠商的產(chǎn)品；二是，其程序的一體性導致不能方便地進 行其他測試項目程序的添加和升級。如果需要添加新的測試型號、測試項目或者使用其他 的標準儀器，程序員需要重新開發(fā)測試軟件，用戶需要重新購買，重新學習軟件使用。另外， 一些計量校準單位也在日常業(yè)務工作中開發(fā)了一些自動測試軟件，但通常是針對某種特定 被測儀器類型，使用的標準儀器和測試項目也相對固定，標準化程度很低，一個程序只完成 一種被測儀器的測試任務。遇有標準儀器、被測儀器升級或增加測試項目時，必須對其程序 主體進行修改，程序的魯棒性和可擴展性較差。目前的自動測試軟件只能按開始測試前設定好的測試順序對被測儀器的各個項 目進行測試，每次只能測試一臺被測儀器。在調度硬件系統(tǒng)，如標準儀器時，只能是靜態(tài)調 度。這種靜態(tài)調度對于只測試一臺被測儀器的情況尚沒有影響，但在實際測試或校準工作 中，為了提高效率，常常希望校準系統(tǒng)能夠同時對多臺不同型號被測儀器進行測試或校準。 在這種情況下，目前的自動測試軟件不再適用。即使同時運行多個軟件實例，也會經(jīng)常出現(xiàn) 一臺被測儀器在測試某個項目時占用了一臺標準儀器，而此時另一臺被測儀器的測試流程 正好也需要使用該標準儀器的情況，那么就必須等待前一個被測儀器使用完之后再占用。 在實際操作過程中，往往是人為地將校準系統(tǒng)分成兩半，或者將測試兩臺或兩臺以上被測 儀器的測試順序顛倒過來，以達到交叉占用標準儀器時間的目的。但這種測試方法要求測 試人員能夠根據(jù)測試進度實時地調整測試流程，這樣一方面使得測試人員勞動強度較大， 另一方面出錯率、漏測率都很高。而且測試方案也很難達到最優(yōu)，實際效率提升不大。另外， 由于測試過程中可以出現(xiàn)突發(fā)情況，如果在突友情況發(fā)生后導致某臺被測儀器占用標準儀 器的時間延長，那么之前人為優(yōu)化配置的測試流程將不能順利進行，由此往往帶來時間上 的更大浪費。因此迫切需要一種在帶有優(yōu)化算法的軟件控制下的全自動硬件動態(tài)調度的方 法來提升測試效率。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種電子類設備的自動測試方法及系統(tǒng)， 用于解決電子類設備在測試、定期校準以及強制檢定過程中，效率低、測試軟件的魯棒性和 可擴展性差等技術問題。
為達到上述目的，本發(fā)明的技術方案是這樣實現(xiàn)的—種電子類設備的自動測試系統(tǒng)，該系統(tǒng)包括服務端，用于根據(jù)客戶端提交上來的測試任務信息，結合測試任務中的測試項目 使用各標準儀器的時間，動態(tài)調度各測試任務中的測試項目的執(zhí)行順序；客戶端，用于設置測試任務參數(shù)，向服務端提交測試任務信息，并根據(jù)服務端決策 的測試任務中的測試項目的執(zhí)行順序動態(tài)加載對應的測試子程序，執(zhí)行測試。進一步地，所述客戶端包括設置模塊，用于設置測試任務參數(shù)及測試基本信息；所述測試任務參數(shù)至少包括 被測設備類型、被測設備型號、測試任務包含的測試項目；所述測試基本信息至少包括被測 設備和標準儀器的程控地址；上報模塊，用于在測試開始之前向服務端提交測試任務信息；還用于在測試過程 中，實時向服務端上報測試任務執(zhí)行情況；所述測試任務信息至少包括測試任務包含的測 試項目；動態(tài)加載模塊，用于根據(jù)設定的測試任務參數(shù)以及服務端決策的測試任務中的測 試項目的執(zhí)行順序，動態(tài)加載對應的測試子程序，執(zhí)行測試任務。進一步地，所述服務端包括接收模塊，用于接收客戶端上報的測試任務信息，以及在測試過程中實時接收測 試狀態(tài)信息，所述測試狀態(tài)信息至少包括測試項目的完成情況；動態(tài)調度模塊，用于根據(jù)客戶端提交上來的測試任務信息及實時上報的測試狀態(tài) 信息，結合測試項目使用各標準儀器的時間，通過優(yōu)化調度算法動態(tài)調度各測試任務中的 測試項目的執(zhí)行順序；下發(fā)模塊，用于將動態(tài)調度模塊的調度結果下發(fā)給客戶端。進一步地，所述動態(tài)加載模塊根據(jù)服務端決策的測試任務中測試項目的執(zhí)行順 序，基于統(tǒng)一的調用接口加載測試項目對應的測試子程序，在完成一個測試項目后卸載所 加載的對應測試子程序，然后加載下一個測試項目對應的測試子程序，直至完成所有測試 項目?；诒景l(fā)明實施例，還提出一種電子類設備的自動測試方法，該方法包括在客戶端設置測試任務參數(shù)，在同時對兩臺或兩臺以上被測設備進行測試時，向 服務端提交測試任務信息；服務端根據(jù)客戶端提交上來的測試任務信息，結合預存在服務端的測試項目使用 各標準儀器的時間，動態(tài)調度各測試任務中的測試項目的執(zhí)行順序，并將調度結果反饋給 客戶端；客戶端根據(jù)服務端決策的測試任務中的測試項目的執(zhí)行順序動態(tài)加載對應的測 試子程序，執(zhí)行測試。進一步地，在客戶端設置測試任務參數(shù)具體為選擇被測設備類型、選擇被測設備型號；定制測試任務，選擇測試任務包含的測試項目、測試項目所占用的標準儀器；設置測試基本信息，所述測試基 信息至少包括被測設備和標準儀器的程控地 址。
5
進一步地，所述客戶端根據(jù)服務端決策的測試任務中的測試項目的執(zhí)行順序動態(tài) 加載對應的測試子程序的步驟為所述客戶端根據(jù)服務端決策的測試任務中的測試項目的順序，基于統(tǒng)一的調用接 口加載測試項目對應的測試子程序，在完成一個測試項目后卸載所加載的對應測試子程 序，然后加載下一個測試項目對應的測試子程序，直至完成所有測試項目。進一步地，所述服務端動態(tài)調度各測試任務中的測試項目的執(zhí)行順序的方法具體 為所述服務端在測試開始時根據(jù)各客戶端提交的測試任務總量以及預存在服務端 的各測試項目需要的時間，通過優(yōu)化調度算法給出各測試任務中的測試項目的執(zhí)行順序；在測試過程中，所述服務端根據(jù)各客戶端上報的測試狀態(tài)信息，實時地根據(jù)標準 儀器占用時間需求，通過優(yōu)化調度算法對測試任務中的測試項目的執(zhí)行順序進行動態(tài)調 度，并將調度結果反饋給客戶端；所述測試狀態(tài)信息至少包括測試項目的完成情況。進一步地，所述優(yōu)化調度算法為模擬退火算法、神經(jīng)元算法或蟻群算法。本發(fā)明基于測試子程序的動態(tài)加載技術和硬件動態(tài)調度技術，實現(xiàn)了開放式的、 可自動優(yōu)化測試進程的自動測試軟件架構及系統(tǒng)，提高了測試效率、簡化了測試子程序的 開發(fā)。本發(fā)明基于測試子程序的動態(tài)加載技術和硬件動態(tài)調度技術實現(xiàn)了一種開放式 的、可自動優(yōu)化測試進程的自動測試軟件測試方法及系統(tǒng)，使得自動測試軟件開發(fā)、維護、 升級過程標準化、規(guī)范化，提升了電子類設備測試和自動校準軟件開發(fā)效率，提高軟件的魯 棒性和可擴展性。實現(xiàn)同時對多臺被測設備進行測試時的標準儀器動態(tài)調度，最大程度地 減少等待標準儀器的時間，提高效率。


圖1為本發(fā)明基于動態(tài)加載和硬件動態(tài)調度技術的自動測試系統(tǒng)結構；圖2為本發(fā)明客戶端執(zhí)行單臺被測設備測試的流程圖；圖3為本發(fā)明對多臺被測設備進行測試的方法流程圖；圖4為本發(fā)明對測試子程序執(zhí)行連線判斷的流程圖；圖5為本發(fā)明測試流程的數(shù)據(jù)流圖。
具體實施例方式本發(fā)明的基本思想是基于模塊化設計本發(fā)明電子類設備自動測試系統(tǒng)的客戶端 程序，測試子程序與測試項目和被測設備對應，客戶端程序通過規(guī)范化的、統(tǒng)一的接口調用 測試子程序。在同時對兩臺或兩臺以上被測設備進行測試時，由服務端程序根據(jù)特定的優(yōu) 化算法來動態(tài)配置各被測設備測試項目的順序，使標準儀器得到最大化利用。為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，以下舉實施例并參照附圖，對 本發(fā)明進一步詳細說明。圖1為本發(fā)明電子類設備自動測試系統(tǒng)的軟件架構示意圖，所述系統(tǒng)包括服務端 和客戶端兩個部分，在軟件架構上包括服務端程序、客戶端程序和測試子程序三個組成模 塊，具體描述如下
客戶端，用于提供用戶交互界面，提供測試任務參數(shù)設置功能，測試任務參數(shù)至少 包括被測設備類型、被測設備型號、測試任務包含的測試項目、測試項目所占用的標準儀 器、被測設備和標準儀器的程控地址；客戶端根據(jù)測試任務參數(shù)加載運行對應的測試子程 序。在對多個設備進行同時測試的情況下，所述客戶端還用于向服務端提交測試任務信息， 接收服務端下發(fā)的優(yōu)化測試流程，并根據(jù)服務端決策的測試任務中的測試項目的執(zhí)行順序 動態(tài)加載測試子程序，執(zhí)行測試任務。所述測試任務信息至少包括測試任務包含的測試項 目、測試項目所占用的標準儀器及測試過程中測試任務的執(zhí)行情況。所述客戶端進一步包括設置模塊，用于設置測試任務參數(shù)；所述測試任務參數(shù)至少包括被測設備類型、 被測設備型號、測試任務包含的測試項目、測試項目所占用的標準儀器、被測設備和標準儀 器的程控地址；上報模塊，用于在測試開始之前向服務端提交測試任務信息；還用于在測試過程 中，實時向服務端上報測試任務執(zhí)行情況；動態(tài)加載模塊，用于根據(jù)設定的測試任務參數(shù)以及服務端決策的測試任務中的測 試項目的執(zhí)行順序，動態(tài)加載對應的測試子程序，執(zhí)行測試任務。本發(fā)明所述測試任務包含一個或多個測試項目，為了完成一個測試項目，通常需 要某種標準儀器或者某套標準儀器，而當確定了使用某個標準儀器或某套標準儀器的組合 來實現(xiàn)該測試項目，稱為一種測試項目實現(xiàn)?？梢杂涗洖椤皽y試項目A-標準儀器A”、“測試 項目A-標準儀器B+標準儀器C”等。一個測試項目實現(xiàn)由一個測試項目和一臺標準儀器 或一套標準儀器組合唯一確定。即一個測試項目實現(xiàn)不會包含多個測試項目。一個測試項 目實現(xiàn)有可能需要同時占用多個標準儀器。測試項目實現(xiàn)唯一對應于一個測試子程序。服務端，用于根據(jù)客戶端提交上來的測試任務信息，結合測試任務中所包含的測 試項目使用各標準儀器的時間，動態(tài)調度各測試任務中測試項目的執(zhí)行順序，以使各標準 儀器的使用效率最大化；所述服務端進一步包括接收模塊，用于接收客戶端上報的測試任務信息，以及在測試過程中實時接收測 試狀態(tài)信息，所述測試狀態(tài)信息至少包括測試項目的完成情況；動態(tài)調度模塊，用于根據(jù)客戶端提交上來的測試任務信息及實時上報的測試狀態(tài) 信息，結合測試項目使用各標準儀器的時間，通過優(yōu)化調度算法動態(tài)調度各測試任務的執(zhí) 行順序；下發(fā)模塊，用于將動態(tài)調度模塊的調度結果下發(fā)給客戶端。本發(fā)明中，運行于客戶端的客戶端程序為通用程序，在對多個被測設備進行測試 時，可在多個客戶端上運行多個客戶端程序實例，每個客戶端程序實例都與服務端程序之 間建立通信連接。在對單臺被測設備進行測試的情況下，客戶端程序可不向服務端提交測試任務信 息，客戶端程序直接加載測試子程序執(zhí)行測試即可，對單臺被測設備進行測試時客戶端程 序的操作流程如圖2所示，具體描述如下步驟201、首先進入歡迎界面狀態(tài)，供用戶選擇需要測試的被測設備類型；步驟202、之后進入被測設備型號選擇和測試任務的制定界面，該狀態(tài)可以由用戶選擇使用預設測試任務，也可以由用戶從對于該類被測設備所有測試項目中選擇需要進行 的測試項目，并進行排序，自定義設置測試任務。例如，對于某類被測設備和某個被測型號可進行電壓、電流、溫度三個測試項目的 測試，用戶可以選擇預設的測試任務或自定義測試任務。預設測試任務為系統(tǒng)預先定義的 測試任務，例如包含電壓、電流、溫度三個測試項目，用戶自定義的測試任務可三個測試項 目中的一項或多項；步驟203、在測試任務確定之后，進入測試基本信息設置狀態(tài)，在該狀態(tài)中主要對 被測設備和標準儀器的程控地址進行設置，并記錄測試人員、測試溫濕度等參數(shù)。步驟204、之后進入測試狀態(tài)。在該狀態(tài)中，客戶端程序根據(jù)前面用戶制定的測試 任務中的測試項目序列，動態(tài)加載各對應測試項目的測試子程序模塊。本發(fā)明中，基于模塊化設計和開發(fā)客戶端程序和測試子程序，客戶端程序和測試 子程序的開發(fā)相互獨立。測試子程序具有統(tǒng)一的數(shù)據(jù)接口，客戶端程序只需根據(jù)測試任務 和測試要求加載相應的測試子程序并傳入測試參數(shù)即可進入測試。以使用Labview開發(fā)程 序為例，在客戶端程序和測試子程序之間使用自定義控件的形式將所有需要傳遞的參量打 包成一個自定義簇，用此來做為統(tǒng)一的接口。也就是說，事先根據(jù)實際需要定義了一個自定 義簇，其中包括所有需要從客戶端程序傳給測試子程序的參量。然后在客戶端程序中引用 該自定義簇，對其中的參量進行賦值，另一邊在測試子程序中也引用該自定義簇，并對其中 的值取出來使用。在本例中該自定義簇中包括被測儀器類型、型號、通用接口總線(GPIB) 地址，以及使用的標準儀器的型號、GPIB地址等參量。在客戶端程序執(zhí)行時，并不是一開始就將所有測試子程序進行加載，而是根據(jù)具 體測試項目的需要動態(tài)地加載測試子程序，當該測試項目結束后，卸載該測試子程序，然后 加載下一個測試項目對應的測試子程序；動態(tài)加載技術的核心思想是在開放的程序框架中設計統(tǒng)一的調用接口，具體進行 某項測試時，由主程序根據(jù)數(shù)據(jù)庫中的測試任務信息加載相應的測試子程序進行測試，測 試完成后再由主程序將其卸載。同時，開放式框架定義了統(tǒng)一的調用規(guī)范，使得主程序框架 在加載測試子程序時，可以附加調用參數(shù)，從而適應不同的測試要求，如不同的測試頻率點 等。這種開放式結構，使得軟件開發(fā)人員能夠分工明確，互不干擾，有效保證主程序的魯棒 性、健壯性、可擴展性和測試子程序的高效性、靈活性。采用這種動態(tài)加載方式具有以下優(yōu)占.
^ \\\ ·1.開放性客戶端程序在調用測試子程序時采用動態(tài)加載技術，結構完全開放， 可以隨時增加任何具有程控接口的被測設備種類和測試項目，并且客戶端程序和子程序升 級不會對軟件結構產(chǎn)生任何影響；2.測試子程序互不干擾性測試子程序完全獨立，由測試專業(yè)技術人員基于統(tǒng)一 標準規(guī)范和工具進行設計，而且測試子程序開發(fā)人員不需要閱讀和改動主程序，只要了解 測試流程就能編寫出符合要求的測試子程序，極大的降低了程序開發(fā)門檻，增強了軟件靈 活性；3.測試子程序結構的標準化測試子程序采用統(tǒng)一的編寫規(guī)范和結構，測試子程 序開發(fā)人員只需根據(jù)測試項目流程添加相應測試步驟，設定測試結果有效數(shù)字位數(shù)即可， 無需閱讀客戶端主程序，測試子程序開發(fā)效率很高；
4.維護便利性客戶端程序和測試子程序中設計的錯誤處理機制，能夠保證每個 測試子程序發(fā)生錯誤時不會影響客戶端主程序的運行，而是能夠繼續(xù)完成其他項目測試。 產(chǎn)生故障的測試子程序可單獨從測試框架中脫離，待完善后再重新接入主程序。本發(fā)明在測試子程序動態(tài)加載的基礎上，進一步提出動態(tài)調度技術，當同時對兩 臺或兩臺以上被測設備進行測試時，占用標準儀器在時間上可能出現(xiàn)沖突，動態(tài)調度技術 可以根據(jù)各測試項目占用標準儀器的時間，通過服務端程序根據(jù)特定的優(yōu)化算法來動態(tài)配 置各被測設備測試項目的順序，使標準儀器得到最大化的利用率，由此大大縮短測試時間。本發(fā)明主要根據(jù)測試項目需要占用什么標準儀器以及占用標準儀器的時間這兩 個參數(shù)來進行優(yōu)化。優(yōu)化算法的調用接口有如下幾個輸入?yún)?shù)被測儀器類型、型號、數(shù)量、 用戶選擇的測試項目、具備的標準儀器型號、數(shù)量。輸出為對每個客戶端的測試任務中的測 試項目的順序。硬件動態(tài)調度技術的優(yōu)勢在于可以最大限度提高所占用標準儀器的使用效率，非 常適合同時對多臺被測設備進行測試。而且結合以上所述的測試子程序動態(tài)調用技術，使 得程序在結構上完全分離，服務端程序和客戶端程序之前只有提交測試任務和給出調度指 令的接口，服務端程序和測試子程序不產(chǎn)生任何交互，這樣保證了程序開發(fā)的獨立性，和程 序使用過程中的魯棒性。由于服務端程序通過優(yōu)化算法對硬件進行動態(tài)調度給自動測試帶 來了以下優(yōu)勢1.最大化多臺被測設備同時測試的測試效率；由于服務端程序在開始時就根據(jù) 各客戶端提交上來的測試任務總量以及預設各測試項目需要的時間，進行優(yōu)化配置測試流 程，并且在測試過程中實時地根據(jù)標準儀器占用情況調制測試流程，所以可以達到標準儀 器占用率的最大化，從而提高對被測設備的測試效率。2.減少了測試人員人為控制的工作量；由于整個控制流程的程序化，使得在各儀 器之間進行人為配置的成分最小化，一方面減輕了測試人員的工作強度，另一方面也減少 了出錯率和漏測率。3.便于應對測試過程中的一些突發(fā)情況。在實際測試過程中，經(jīng)常會出現(xiàn)一些突 發(fā)情況，例如某個測試項目測試結果不理想，需要再次測試進行驗證。這些突發(fā)情況導致原 先制定的測試方案不能順利進行，如果沒有動態(tài)調度功能，該突發(fā)情況必然會打亂本臺被 測設備的測試進度，很可能導致其他被測設備需要占用標準儀器時不能得到分配。動態(tài)調 度技術可以實時地根據(jù)實際測試情況調度硬件的占用分配。當同時對兩臺或兩臺以上的被測設備進行測試時，需要啟動服務端程序，對標準 儀器的占用進行動態(tài)地調度。如圖3所示，具體的步驟如下步驟301 步驟303所執(zhí)行的功能同附圖2中的步驟201 步驟203，所不同的是 需要對多個被測設備的測試任務進行設置定制；步驟304 在完成所有測試任務的定制后，客戶端程序將被測設備的型號和需要 進行的測試項目以任務的形式提交給服務端程序；步驟305 服務端程序中事先存儲有各測試項目需要占用某標準儀器的時長，根 據(jù)各測試任務占用標準儀器的時長，服務端程序通過優(yōu)化算法給出最優(yōu)的測試順序安排， 反饋給客戶端程序。步驟306 客戶端程序根據(jù)服務端程 給出的測試項目的測試順序執(zhí)行測試。 9
優(yōu)化算法的優(yōu)化目標是完成所有被測設備的測試任務需要花費的時間最短，即各 客戶端程序按照服務端程序給出的最優(yōu)化測試序列對各被測設備進行測試，能在最短時間 內(nèi)完成所有測試任務。由于在測試過程中存在著很多突發(fā)因素的影響，導致一些測試步驟 消耗了大于理論時長的時間，那么此時如果繼續(xù)按照一開始給出的優(yōu)化測試序列就不能達 到最短時間完成所有測試任務的目標。因此，本發(fā)明還采用了實時調度技術，服務端程序在 結束第一次優(yōu)化測試策略的制定，并把結果傳輸給客戶端進行測試之后，服務端程序并沒 有結束運行，而是繼續(xù)監(jiān)控各個客戶端執(zhí)行測試任務的進度，當其中一個客戶端執(zhí)行完一 項測試項目時，即刻反饋給服務端一個信號，服務端程序再進行一次優(yōu)化計算，看此時是否 會有其他的測試策略比當前策略能更快完成所有測試任務，如果有，立即調整該客戶端以 及其他客戶端當前測試項目實現(xiàn)之后的測試策略，如果沒有，繼續(xù)按照之前策略進行。進入測試狀態(tài)后，由于有一些測試項目使用的硬件連線方式是一致的，而另一些 是不同的，對于連線相同的測試項目之間的過渡，可以直接由軟件自動控制，進行連續(xù)性地 測試，對于連線方式不同的測試項目過渡，就需要程序進入暫停狀態(tài)，以備測試人員手動調 整連線方式，再繼續(xù)程序。因此各測試子程序模塊在調用時按如圖4所示流程進行。開始 進入測試狀態(tài)時，程序執(zhí)行等待狀態(tài)，等待用戶按提示連接被測設備和標準儀器。連接好儀 器之后，主框架即根據(jù)當前測試任務順序加載相應測試子程序，進行該項目測試。每完成一 個項目測試后，進入下一個測試項目之前，客戶端程序會判斷下一測試項目的測試連線方 式是否與本測試項目相同。如果相同，即不需要改變連線方式，則直接進入下一個測試子程 序，開始下一項目的測試；如測試連線方式不相同，則進入等待狀態(tài)，客戶端程序提示用戶 更改連線方式，待用戶更改后繼續(xù)進行后繼測試。以此類推，直到測試任務中的最后一個測 試子程序執(zhí)行完畢后結束測試狀態(tài)，等待用戶做下一步選擇。用戶可以選擇進入生成證書 狀態(tài)、返回測試基本信息設置狀態(tài)繼續(xù)測試下一臺被測設備，或者直接退出該程序。本發(fā)明測試過程基于數(shù)據(jù)流，而不是傳統(tǒng)的過程流，即只有當數(shù)據(jù)準備好以后，才 進行下一步驟操作。這種方式特別適合于自動測試過程的實現(xiàn)。圖5所示為本發(fā)明執(zhí)行 測試所基于的數(shù)據(jù)流示意圖，本發(fā)明優(yōu)選實施例中，各種數(shù)據(jù)和信息的交換采用數(shù)據(jù)庫，其 中，對各被測設備類型有以下數(shù)據(jù)表被測型號及屬性表、標準儀器及屬性表、測試項目表、 測試子程序表、測試任務表、測試連線示意圖表、測試結果列表等。測試子程序表關聯(lián)著測 試項目表、被測設備型號及屬性表、標準儀器及屬性表、測試連線示意圖表，即每一個測試 子程序記錄必須有對應的測試項目、被測型號、使用的標準儀器及需要占用的時間、測試連 線示意圖這幾個屬性。測試任務表關聯(lián)著測試子程序表，即每一個測試任務記錄由一系列 測試子程序排列組合而成，這些測試任務可以是預先設置的，可以是用戶自定義的，也可以 是由服務端程序通過優(yōu)化算法進行配置的，也可以是服務端程序根據(jù)實際測試過程進行動 態(tài)調度配置的?？蛻舳顺绦蚋鶕?jù)主數(shù)據(jù)庫中的這些信息，動態(tài)加載相應的測試子程序進行 自動化測試。客戶端程序根據(jù)被測設備信息、測試子程序信息和測試要求加載相應的原始 記錄模板文件，并結合該被測設備產(chǎn)品序列號生成該臺被測設備的測試原始記錄文件，供 調用的測試子程序使用，讀取測試參數(shù)和存儲測試結果。在生成證書狀態(tài)中，證書創(chuàng)建子程 序調用數(shù)據(jù)庫中的有關信息自動生成規(guī)劃的測試證書。以下舉實例說明應用本發(fā)明的技術方案實現(xiàn)對射頻類電子設備的自動校準的過 程，所述的射頻類電子設備主要類型包括調制度分析儀、失真儀檢定裝置、數(shù)字多用表、射頻信號發(fā)生器、移動通信綜合測試儀等。各種被測設備類型都包括多家廠商的多種型號儀 器，各類被測設備都有多個測試項目。系統(tǒng)軟件部分開發(fā)主要分為以下幾個部分1、客戶端程序；主要完成人機交互功能、與服務端程序之間的接口、以及動態(tài)調用 測試子程序完成測試的功能。2、服務端程序；主要完成接收客戶端程序提交的測試任務，根據(jù)優(yōu)化算法制定最 佳測試序列。并在實際測試過程中實時動態(tài)調度標準儀器，實現(xiàn)標準儀器的最大化利用率。 優(yōu)化算法采用模擬退火算法，使用Matlab軟件加以實現(xiàn)。3、測試子程序；具有統(tǒng)一的接口，供客戶端程序調用。完成特定項目具體的測試任 務。4、主數(shù)據(jù)庫，用于存儲測試任務、測試項目、被測設備及標準儀器的相關信息及其 關聯(lián)關系，供客戶端程序和服務端程序訪問。該實施例采用高級編程語言(例如，非常適合儀器控制的LabVIEW開發(fā)軟件)進 行開發(fā)?？蛻舳顺绦蚝头斩顺绦蛴身椖拷M團隊進行開發(fā)，測試子程序由熟悉各類被測設 備測試、校準的技術人員開發(fā)。由于采用了本發(fā)明描述的基于動態(tài)加載技術的開放式框架， 整體程序開發(fā)效率非常高，而且程序的魯棒性和可擴展性很強，新測試儀器種類、型號和測 試項目可以隨時添加到該軟件系統(tǒng)中，不會對程序主框架產(chǎn)生任何影響。同時，由于測試子 程序由本專業(yè)技術人員負責，從而能夠有效保證測試的完整性和可靠性，保證測試結果的 準確可靠。該實施例的服務端程序根據(jù)多個客戶端提交上來的測試任務，對各客戶端的被測 設備進行測試任務的優(yōu)化配置。優(yōu)化配置的算法可以基于模擬退火算法、神經(jīng)元算法、蟻群 算法等成熟算法加以實現(xiàn)，本例中采用模擬退火算法。例如，客戶端提交上來3個測試任 務，分別為任務A、任務B和任務C，表1和表2中分別以不同的顏色了區(qū)分，三個測試任務 需要同時測試三臺被測設備，需要使用的標準儀器有四臺，即三臺被測設備必須輪流占用 這四臺標準儀器，整個測試流程需要占用標準儀器A兩個單位時間，需要占用標準儀器B兩 個單位時間，需要占用標準儀器C 一個單位時間，需要占用標準儀器D —個單位時間。將三 臺被測設備的測試任務，以及各測試項目需要占用的測試時長輸入優(yōu)化配置程序，優(yōu)化配 置程序以使用最短時間完成所有測試為優(yōu)化目標進行優(yōu)化計算，輸出是對三臺被測設備的 測試安排的時間序列，分別輸入到提交測試任務的三個客戶端程序，控制三臺被測設備開 始測試。如果不進行優(yōu)化，三臺被測設備都采用順序占用標準儀器A、標準儀器B、標準儀 器C、標準儀器D的測試序列，那么完成這三臺被測設備的測試任務需要十個單位時間，如 下表1所示。如果采用本發(fā)明的優(yōu)化算法進行優(yōu)化，得出如表2所示測試流程配置，則只需 要六個單位時間就可以完成三臺被測設備的測試任務。并且可以在實際測試過程中根據(jù)某 些突發(fā)情況，實時地調整測試流程配置，即對硬件進行動態(tài)調度。表1順序測試三臺被測設備
權利要求
一種電子類設備的自動測試系統(tǒng)，其特征在于，該系統(tǒng)包括服務端，用于根據(jù)客戶端提交上來的測試任務信息，結合測試任務中的測試項目使用各標準儀器的時間，動態(tài)調度各測試任務中的測試項目的執(zhí)行順序；客戶端，用于設置測試任務參數(shù)，向服務端提交測試任務信息，并根據(jù)服務端決策的測試任務中的測試項目的執(zhí)行順序動態(tài)加載對應的測試子程序，執(zhí)行測試。
2.根據(jù)權利要求1所述的系統(tǒng)，其特征在于，所述客戶端包括設置模塊，用于設置測試任務參數(shù)及測試基本信息；所述測試任務參數(shù)至少包括被 測設備類型、被測設備型號、測試任務包含的測試項目；所述測試基本信息至少包括被測設 備和標準儀器的程控地址；上報模塊，用于在測試開始之前向服務端提交測試任務信息；還用于在測試過程中，實時向服務端上報測試任務執(zhí)行情況；所述測試任務信息至少包括測試任務包含的測試項 目；動態(tài)加載模塊，用于根據(jù)設定的測試任務參數(shù)以及服務端決策的測試任務中的測試項 目的執(zhí)行順序，動態(tài)加載對應的測試子程序，執(zhí)行測試任務。
3.根據(jù)權利要求1或2所述的系統(tǒng)，其特征在于，所述服務端包括接收模塊，用于接收客戶端上報的測試任務信息，以及在測試過程中實時接收測試狀 態(tài)信息，所述測試狀態(tài)信息至少包括測試項目的完成情況；動態(tài)調度模塊，用于根據(jù)客戶端提交上來的測試任務信息及實時上報的測試狀態(tài)信 息，結合測試項目使用各標準儀器的時間，通過優(yōu)化調度算法動態(tài)調度各測試任務中的測 試項目的執(zhí)行順序；下發(fā)模塊，用于將動態(tài)調度模塊的調度結果下發(fā)給客戶端。
4.根據(jù)權利要求2所述的系統(tǒng)，其特征在于，所述動態(tài)加載模塊根據(jù)服務端決策的測 試任務中測試項目的執(zhí)行順序，基于統(tǒng)一的調用接口加載測試項目對應的測試子程序，在 完成一個測試項目后卸載所加載的對應測試子程序，然后加載下一個測試項目對應的測試 子程序，直至完成所有測試項目。
5.根據(jù)權利要求3所述的系統(tǒng)，其特征在于，所述優(yōu)化調度算法為模擬退火算法、神經(jīng) 元算法或蟻群算法。
6.一種電子類設備的自動測試方法，其特征在于，該方法包括在客戶端設置測試任務參數(shù)，在同時對兩臺或兩臺以上被測設備進行測試時，向服務 端提交測試任務信息；服務端根據(jù)客戶端提交上來的測試任務信息，結合預存在服務端的測試項目使用各標 準儀器的時間，動態(tài)調度各測試任務中的測試項目的執(zhí)行順序，并將調度結果反饋給客戶 端；客戶端根據(jù)服務端決策的測試任務中的測試項目的執(zhí)行順序動態(tài)加載對應的測試子 程序，執(zhí)行測試。
7.根據(jù)權利要求6所述的方法，其特征在于，在客戶端設置測試任務參數(shù)具體為 選擇被測設備類型、選擇被測設備型號；定制測試任務，選擇測試任務包含的測試項目、測試項目所占用的標準儀器； 設置測試基本信息，所述測試基本信息至少包括被測設備和標準儀器的程控地址。
8.根據(jù)權利要求6所述的方法，其特征在于，所述客戶端根據(jù)服務端決策的測試任務 中的測試項目的執(zhí)行順序動態(tài)加載對應的測試子程序的步驟為所述客戶端根據(jù)服務端決策的測試任務中的測試項目的順序，基于統(tǒng)一的調用接口加 載測試項目對應的測試子程序，在完成一個測試項目后卸載所加載的對應測試子程序，然 后加載下一個測試項目對應的測試子程序，直至完成所有測試項目。
9.根據(jù)權利要求6所述的方法，其特征在于，所述服務端動態(tài)調度各測試任務中的測 試項目的執(zhí)行順序的方法具體為所述服務端在測試開始時根據(jù)各客戶端提交的測試任務總量以及預存在服務端的各 測試項目需要的時間，通過優(yōu)化調度算法給出各測試任務中的測試項目的執(zhí)行順序；在測試過程中，所述服務端根據(jù)各客戶端上報的測試狀態(tài)信息，實時地根據(jù)標準儀器 占用時間需求，通過優(yōu)化調度算法對測試任務中的測試項目的執(zhí)行順序進行動態(tài)調度，并 將調度結果反饋給客戶端；所述測試狀態(tài)信息至少包括測試項目的完成情況。
10.根據(jù)權利要求9所述的方法，其特征在于，所述優(yōu)化調度算法為模擬退火算法、神 經(jīng)元算法或蟻群算法。
全文摘要
本發(fā)明公開了一種電子類設備的自動測試方法及系統(tǒng)，用于解決電子類設備在測試、定期校準以及強制檢定過程中，效率低、測試軟件的魯棒性和可擴展性差等技術問題。本發(fā)明基于測試子程序的動態(tài)加載技術和硬件動態(tài)調度技術實現(xiàn)了一種開放式的、可自動優(yōu)化測試進程的自動測試軟件測試方法及系統(tǒng)，使得自動測試軟件開發(fā)、維護、升級過程標準化、規(guī)范化，提升了電子類設備測試和自動校準軟件開發(fā)效率，提高軟件的魯棒性和可擴展性。實現(xiàn)同時對多臺被測設備進行測試時的標準儀器動態(tài)調度，最大程度地減少等待標準儀器的時間，提高效率。
文檔編號G06F11/22GK101986278SQ20101053020
公開日2011年3月16日 申請日期2010年10月29日 優(yōu)先權日2010年10月29日
發(fā)明者劉科, 卞昕, 周鑫, 徐暉, 方宏, 趙海寧, 高小珣 申請人:中國計量科學研究院