基于SOA自動化測試框架及其應(yīng)用
基于Perl的嵌入式軟件自動測試框架及其應(yīng)用
陳全員
（蔚來軟件科技（上海）有限公司瑞侮，上海 201102）
摘要：嵌入式軟件的自動化測試由于其自身的特性，相對于其他軟件的自動化測試更加困難盖腿。分析嵌入式軟件測試?yán)щy雾消，并尋求解決方案惧互，再此基礎(chǔ)上提出基于Perl的嵌入式軟件自動化測試框架鳍刷。依據(jù)該測試框架，建立“基于Perl腳本的OpenMax軟件自動測試系統(tǒng)”理盆，有效提高了測試效率痘煤，很好的支持了公司內(nèi)部OpenMax項目的開發(fā)以及相應(yīng)客戶，保證了軟件的順利交付猿规。
關(guān)鍵詞：SOA衷快；自動化測試；Python姨俩；OpenMAX
根據(jù)博世對未來電子電氣架構(gòu)發(fā)展趨勢預(yù)測蘸拔，電子電氣架構(gòu)從最早的分布式架構(gòu)逐步向集中式演進(jìn)方向。發(fā)展到現(xiàn)在环葵，汽車發(fā)展呈現(xiàn)兩個趨勢调窍，一個是網(wǎng)聯(lián)化，另一個是智能化张遭。從技術(shù)演進(jìn)的角度來講邓萨，汽車智能化的過程就是從最早傳統(tǒng)CAN/LIN 網(wǎng)絡(luò)、到車載以太網(wǎng)菊卷，最后從架構(gòu)開始升級缔恳。在軟件定義汽車的概念下，汽車軟件架構(gòu)逐步向SOA的架構(gòu)邁進(jìn)洁闰，而SOA架構(gòu)可以把車和云端口服務(wù)暴露出來歉甚，做各種開發(fā)，進(jìn)而衍生出測試的需求扑眉。
隨著汽車新四化的推進(jìn)纸泄，汽車整車廠在實現(xiàn)車輛網(wǎng)聯(lián)、自動駕駛和數(shù)據(jù)驅(qū)動的同時腰素，更要在滿足用戶體驗和基本服務(wù)的基礎(chǔ)上快速響應(yīng)客戶的個性化需求聘裁，為更好地解決這些新的挑戰(zhàn)，整車廠引入了高性能的芯片耸弄、突破性的技術(shù)產(chǎn)品咧虎，同時傳統(tǒng)的EE架構(gòu)也需要變革，SOA（面向服務(wù)的架構(gòu)）成為大多整車廠響應(yīng)市場需求的首選架構(gòu)计呈。SOA架構(gòu)的主要優(yōu)勢是可以在很大程度上實現(xiàn)分布式系統(tǒng)軟件模塊間的解耦砰诵，通過軟件升級OTA可以更方便靈活地將服務(wù)實體部署在任意的域控制器上，服務(wù)之間只需通過簡單捌显、精確定義的接口進(jìn)行通訊茁彭，不涉及底層編程接口和通訊模型。而且對于ECU的版本更新扶歪、信號庫更新理肺、代碼修改等過程更加簡便和靈活摄闸。簡化了注冊服務(wù)與調(diào)用API，節(jié)約了時間成本妹萨，提高系統(tǒng)的健壯性和可擴(kuò)展性年枕。
基于嵌入式系統(tǒng)設(shè)計的軟件稱為嵌入式軟件。隨著嵌入式系統(tǒng)的廣泛應(yīng)用乎完，嵌入式軟件的重要性也越來越突出熏兄。在各種實際應(yīng)用領(lǐng)域中，嵌入式軟件質(zhì)量往往關(guān)系到人民生命財產(chǎn)和生態(tài)環(huán)境的安危树姨。一旦軟件發(fā)生故障摩桶，就可能造成人的生命和財產(chǎn)的巨大損失或生態(tài)環(huán)境的破壞[1]。通過測試集對軟件進(jìn)行測試是保證軟件質(zhì)量的重要手段帽揪，在軟件生存期中占有非常重要位置硝清。根據(jù)Boehm的統(tǒng)計，軟件開發(fā)總成本中转晰，用在測試上的開銷要占30％到50％[2]芦拿。
對嵌入式軟件測試的研究由來已久[3～4]，不僅要測試系統(tǒng)軟件挽霉，而且也要考慮相關(guān)的硬件組件防嗡，實時性需求以及性能相關(guān)的特性等变汪。因此對于嵌入式軟件的測試侠坎，將更加復(fù)雜，尤其是實施測試自動化技術(shù)困難[4]裙盾∈敌兀基于Perl的嵌入式軟件自動化測試框架，提供了一種實現(xiàn)嵌入式軟件自動測試的方法番官，能夠有效提高測試效率庐完。
嵌入式軟件與其他軟件相比，具有專用性徘熔，它只能在需求所指定的硬件平臺上執(zhí)行门躯，并且嵌入式軟件的開發(fā)環(huán)境和運行環(huán)境是不一致的，因此即使宿主機(jī)環(huán)境下測試再充分酷师，也不能說明在目標(biāo)機(jī)環(huán)境下運行該軟件就不出問題讶凉。因而，嵌入式軟件還面臨著目標(biāo)環(huán)境的測試山孔。這不僅增加了測試的代價懂讯，而且還帶來了嵌入式軟件的測試策略問題，即哪些測試分配在宿主環(huán)境進(jìn)行台颠，哪些測試分配到目標(biāo)環(huán)境下進(jìn)行[5]褐望。
1.1. 嵌入式軟件測試與普通軟件測試的相同之處
傳統(tǒng)的軟件測試是將軟件分在不同的層面上進(jìn)行測試，包括模塊測試（或單元測試），集成測試瘫里，系統(tǒng)測試等实蔽。嵌入式軟件測試和一般的軟件測試存在著許多相似的問題和相似的解決方法。這就是嵌入式軟件的通用的測試方法谨读。
·? ? ? 按階段可分為單元測試盐须、集成測試、系統(tǒng)測試和確認(rèn)測試漆腌。
·? ? ? 根據(jù)測試時是否運行被測試的程序贼邓，軟件測試技術(shù)還可分為靜態(tài)測試方法和動態(tài)測試方法。
·? ? ? 從測試是否針對系統(tǒng)的內(nèi)部結(jié)構(gòu)和邏輯處理過程闷尿，通乘芫叮可分為:白盒測試與黑盒測試。
1.2. 嵌入式軟件的獨特之處
嵌入式系統(tǒng)由于自己本身的特點填具，如實時性強(qiáng)统舀、內(nèi)存不豐富、I/O通道少劳景、開發(fā)工具昂貴并且與硬件緊密相關(guān)誉简、CPU種類繁多等等，決定了不同的嵌入式系統(tǒng)必須有不同的測試方法盟广，下面介紹幾種不同的嵌入式產(chǎn)品在測試時應(yīng)特別關(guān)注的問題闷串。
·唯一系統(tǒng)——“一次性”開發(fā)：某些系統(tǒng)，比如人造衛(wèi)星筋量，一旦發(fā)射之后就無法對其進(jìn)行維護(hù)烹吵。對于這種系統(tǒng)，需要多考慮維護(hù)桨武、復(fù)用和回歸測試等因素肋拔。
·自治系統(tǒng)：有些嵌入式系統(tǒng)可以在無限長的時間內(nèi)自主運行，它們擔(dān)負(fù)某種任務(wù)呀酸。一旦運行后凉蜂，就不再需要有人干預(yù)或與人交互。因此就需要特殊的測試環(huán)境和測試工具來執(zhí)行測試用例性誉，并測量和分析結(jié)果窿吩。
·硬件限制：硬件資源的局限性會給嵌入式軟件帶來一定的約束，比如內(nèi)存使用和電力消耗艾栋。
·硬實時行為：“實時”的本質(zhì)就是輸入或輸出在發(fā)生的瞬間就能夠影響到系統(tǒng)的行為爆存。
·控制系統(tǒng)：控制系統(tǒng)通過連續(xù)的反饋機(jī)制和環(huán)境相互作用：系統(tǒng)的輸出會影響環(huán)境，而環(huán)境反過來會影響到控制的行為蝗砾。
·強(qiáng)調(diào)安全系統(tǒng)：在嵌入式系統(tǒng)中當(dāng)嵌入式系統(tǒng)的故障會導(dǎo)致對人體健康的嚴(yán)重傷害（或更為可怕的后果）時先较，則稱該系統(tǒng)是“強(qiáng)調(diào)安全”的携冤。
·極端的環(huán)境條件：有些系統(tǒng)需要在極端的環(huán)境條件下進(jìn)行連續(xù)的操作，比如極熱或極冷闲勺、機(jī)械震動曾棕、化學(xué)物質(zhì)或放射性等環(huán)境條件。測試這些系統(tǒng)需要有特殊的設(shè)備來提供極端條件菜循。
從表面看來翘地，嵌入式系統(tǒng)的行為通常簡單又明了。但實現(xiàn)這樣的系統(tǒng)仍然是非常困難的一件事情癌幕，可能需要大量的控制軟件來處理復(fù)雜的科學(xué)運算衙耕。針對以上對嵌入式系統(tǒng)的獨有特點的分析，可以看出嵌入式軟件的充分測試就顯得更有必要勺远。
2.? ?基于Perl的嵌入式軟件自動測試框架
2.1. 嵌入式軟件測試的難點
嵌入式軟件測試環(huán)境可以模仿交叉開發(fā)環(huán)境來搭建橙喘。因為前期的一些測試包括單元測試、集成測試都可以在宿主機(jī)上完成胶逢，所以前期的測試環(huán)境與主機(jī)開發(fā)環(huán)境類似厅瞎。后期的一些測試，包括硬軟件集成測試初坠、系統(tǒng)測試等則需要構(gòu)建交叉測試環(huán)境來完成和簸。
構(gòu)建交叉測試環(huán)境要解決的主要問題包括[6]：
·? ? ? 宿主機(jī)和目標(biāo)機(jī)之間的通信連接；
·? ? ? 目標(biāo)機(jī)如何反饋調(diào)試信息及調(diào)試信息在宿主機(jī)端的顯示碟刺；
·? ? ? 宿主機(jī)如何對目標(biāo)機(jī)程序進(jìn)行測試交互锁保；
·? ? ? 如何處理異常實現(xiàn)完全自動化；
·? ? ? 如何使自動測試系統(tǒng)不增加目標(biāo)機(jī)的負(fù)荷南誊。
為此提出基于Perl的嵌入式軟件測試框架身诺，其框圖如下圖1所示：
圖1 基于Perl的嵌入式軟件自動測試框架
2.2. 宿主機(jī)和目標(biāo)機(jī)之間的通信
在當(dāng)今的嵌入式軟件開發(fā)和測試過程中，宿主機(jī)和目標(biāo)機(jī)之間的物理連接抄囚，可以是通過串口，采用串口通信方式橄务；也可以是以太網(wǎng)口幔托，一般基于TCP/IP 協(xié)議傳輸，也可以基于Telnet進(jìn)行傳輸蜂挪；還可以通過USB進(jìn)行數(shù)據(jù)傳輸重挑，其速度更快，尤其用于燒錄文件系統(tǒng)棠涮，效果更好谬哀。在實際應(yīng)用中，可以根據(jù)需要严肪，混合使用多種傳輸方式史煎，比如燒錄文件系統(tǒng)谦屑，使用USB傳輸，在線調(diào)試使用串口通信篇梭。
由于實際的嵌入式系統(tǒng)在開發(fā)和測試過程中氢橙，實時交互頻繁，采用基本的串口通信仍然是最常用的方法恬偷。為此悍手，該自動測試系統(tǒng)，使用Perl提供的強(qiáng)大的串口模塊—SerialPort袍患，實現(xiàn)宿主機(jī)和目標(biāo)機(jī)之間的通信坦康。
2.3.目標(biāo)機(jī)如何反饋調(diào)試信息及調(diào)試信息在宿主機(jī)端的顯示
目標(biāo)機(jī)被測試模塊在獲取輸入后，進(jìn)行相應(yīng)處理诡延，產(chǎn)生正常響應(yīng)信息或拋出異常涝焙、錯誤信息。這些信息的反饋受目標(biāo)機(jī)資源限制（如沒有視頻顯示）或者不便于通過目標(biāo)機(jī)輸出（如目標(biāo)機(jī)的顯示屏正在用于視頻輸出）孕暇，一般都是通過宿主機(jī)和目標(biāo)機(jī)之間的通信（比如通過串口）仑撞，反饋給宿主機(jī)處理。這樣宿主機(jī)可以根據(jù)目標(biāo)機(jī)反饋的信息判斷測試用例是否通過妖滔，并決定是否繼續(xù)發(fā)送下一條測試命令隧哮。
2.4.宿主機(jī)與目標(biāo)機(jī)程序進(jìn)行測試交互
宿主機(jī)對目標(biāo)機(jī)程序進(jìn)行的測試控制，實際上主要是從宿主機(jī)輸入測試用例座舍，捕獲目標(biāo)機(jī)上被測試模塊是否正常接受測試用例沮翔，并依據(jù)目標(biāo)機(jī)的反饋信息，判斷測試結(jié)果曲秉，進(jìn)行相應(yīng)的操作采蚀。
2.5.異常處理及完全自動化
嵌入式軟件自動化測試的另外一個難題是，當(dāng)目標(biāo)機(jī)遇到異常承二，處于懸掛或死機(jī)狀態(tài)時榆鼠，自動測試系統(tǒng)將被終止，失去連續(xù)測試的能力亥鸠。為了解決這個問題妆够，在自動測試系統(tǒng)中，引入可控電源對目標(biāo)機(jī)供電负蚊∩衩茫可控電源是一種可以根據(jù)用戶需要，用程序控制其啟動或關(guān)閉的電源家妆。
在自動測試系統(tǒng)中鸵荠，宿主機(jī)通過串口，定期（如每隔2秒）檢測目標(biāo)機(jī)的狀態(tài)伤极，或者依據(jù)目標(biāo)機(jī)從串口反饋的信息蛹找，一旦確定目標(biāo)機(jī)處于懸掛或者死機(jī)狀態(tài)姨伤，則通過Perl腳本，遠(yuǎn)程控制可控電源（關(guān)斷電源片刻熄赡，然后重啟電源）姜挺，從而使目標(biāo)機(jī)重新啟動，恢復(fù)被測試環(huán)境彼硫。使用該方法炊豪，跳過導(dǎo)致目標(biāo)機(jī)懸掛或死機(jī)的測試用例（當(dāng)然判定該測試用例失敗，并手動驗證）拧篮，繼續(xù)執(zhí)行下一個測試用例词渤，實現(xiàn)自動測試的連續(xù)性。
2.6.自動測試系統(tǒng)不應(yīng)增加目標(biāo)機(jī)的負(fù)荷
眾所周知串绩，嵌入式系統(tǒng)的處理器相對于PC機(jī)的處理器缺虐，其CPU的主頻低、內(nèi)存容量小礁凡，因此高氮，即使當(dāng)今的嵌入式系統(tǒng)的處理器已經(jīng)有了飛速發(fā)展，其數(shù)據(jù)處理能力仍低于高端PC機(jī)的處理器顷牌。一些工程師喜歡將自動測試系統(tǒng)嵌入到目標(biāo)機(jī)剪芍，在目標(biāo)機(jī)上運行并處理運行結(jié)果。這樣雖然方法簡單明了窟蓝，但是會因此增加目標(biāo)機(jī)CPU的負(fù)荷罪裹，占用目標(biāo)機(jī)的內(nèi)存，從而影響測試的準(zhǔn)確性运挫。
那么如何減少自動測試系統(tǒng)對目標(biāo)機(jī)的影響状共，減少由于測試系統(tǒng)而引入的測試偏差呢？總的原則是：讓自動測試系統(tǒng)盡可能少的增加目標(biāo)機(jī)的負(fù)荷谁帕。為此峡继，將能夠在宿主機(jī)上完成的任務(wù)盡量在宿主機(jī)上完成。該“基于Perl的嵌入式軟件自動測試框架”雇卷，在宿主機(jī)上完成的任務(wù)有：
·? ? ? 設(shè)計測試用例鬓椭，將測試用例分解為便于通過串口向目標(biāo)機(jī)發(fā)生的腳本或者命令集合；
·? ? ? 建立基于Perl的串口環(huán)境关划，比如設(shè)置串口選項等；
·? ? ? 撰寫測試腳本翘瓮，為自動測試做準(zhǔn)備贮折；
·? ? ? 發(fā)送測試用例命令：依據(jù)測試需求及相應(yīng)的測試用例，通過串口向目標(biāo)機(jī)發(fā)生測試指令资盅；
·? ? ? 分析測試結(jié)果：捕獲從串口輸出的測試用例的執(zhí)行結(jié)果信息调榄，依據(jù)Perl提供的強(qiáng)大的文字處理能力踊赠，分析測試是否通過，并在測試結(jié)束后匯總測試結(jié)果每庆。
·? ? ? 控制被測試設(shè)備：如上節(jié)所述筐带，當(dāng)被測試系統(tǒng)處于死機(jī)等異常狀態(tài)時，通過Perl腳本缤灵，遠(yuǎn)程控制可控電源伦籍，重啟被測試系統(tǒng)，從而保證測試的連續(xù)性腮出。
·? ? ? 記錄測試日志信息與測試報告：以文件形式記錄測試日志帖鸦，便于分析測試用例失敗的原因。依據(jù)測試結(jié)果胚嘲，匯總測試報告作儿。
·? ? ? ?發(fā)送電子郵件：依據(jù)Perl提供的郵件模塊-- Net::SMTP和MIME::Lite，建立郵件發(fā)送函數(shù)馋劈，將測試結(jié)果以附件形式發(fā)送給相關(guān)人員攻锰。
而目標(biāo)機(jī)，則主要負(fù)責(zé)測試用例的執(zhí)行妓雾，并反饋相應(yīng)的測試日志娶吞。
3.? 基于Perl的嵌入式軟件自動測試框架在OpenMAX集成測試中的應(yīng)用
OpenMAX是一個多媒體應(yīng)用程序的標(biāo)準(zhǔn)，由NVIDIA公司和Khronos在2006年推出君珠。OpenMAX架構(gòu)可以加速操作系統(tǒng)和芯片平臺的多媒體組件的開發(fā)寝志、整合和編程，使庫和編解碼實現(xiàn)者能夠快速有效的利用新芯片潛在的加速功能策添，而不關(guān)心下層的硬件結(jié)構(gòu)[7]材部。
根據(jù)客戶需求，公司提供了OpenMAX的IL（Integration Layer）層接口唯竹，為此開發(fā)了“基于Perl的自動測試系統(tǒng)”對其進(jìn)行測試乐导。測試系統(tǒng)程序流程圖如下圖2所示。
圖2 基于Perl的OpenMax自動測試系統(tǒng)流程
該系統(tǒng)調(diào)用Perl腳本串口模塊浸颓，實現(xiàn)宿主機(jī)與目標(biāo)機(jī)系統(tǒng)的數(shù)據(jù)交互物臂。并將發(fā)送命令、測試分析产上、結(jié)果統(tǒng)計等功能由CPU處理能力強(qiáng)的宿主機(jī)實現(xiàn)棵磷，而目標(biāo)機(jī)只完成測試用例的運行，從而減少嵌入式被測試系統(tǒng)的CPU的負(fù)荷晋涣，減少由于測試系統(tǒng)而引入的測試偏差仪媒。
另一個需要注意的問題即如何判斷當(dāng)前測試用例是否運行結(jié)束，這就需要合理設(shè)計被測試系統(tǒng)的反饋信息谢鹊，讓被測試系統(tǒng)在每完成一個測試用例后算吩，向串口反饋相同的結(jié)束語句留凭，從而使宿主機(jī)在接收到相應(yīng)的結(jié)束語句后，判斷測試用例是否通過偎巢，并決定是否和怎樣發(fā)送下一條測試命令蔼夜。
總之，經(jīng)過約不斷的調(diào)試压昼、測試求冷，成功完成了該“基于Perl腳本的OpenMax軟件自動測試系統(tǒng)”，有效提高了測試效率巢音，很好的支持了公司內(nèi)部OpenMax項目的開發(fā)以及相關(guān)客戶遵倦，保證軟件順利交付。
4.? 總結(jié)
嵌入式軟件測試相對其他軟件測試要困難得多官撼，而嵌入式軟件自動化測試面臨更多的問題梧躺。“基于Perl的嵌入式軟件自動化測試框架”傲绣，能夠解決大多數(shù)嵌入式軟件自動化測試面臨的問題掠哥。基于該框架的“OpenMax軟件自動測試系統(tǒng)”秃诵，實現(xiàn)了嵌入式OpenMAX軟件的自動化測試续搀，有效提高了測試效率。值得提出的是菠净，該系統(tǒng)稍作改動和更新禁舷，也可以用于其他相關(guān)項目的測試，比如基于Android系統(tǒng)下的多媒體單元測試等毅往。
參考文獻(xiàn):
[1]. 欒輝. 基于SOA的車載服務(wù)及軟件開發(fā)設(shè)計與研究. 2022.
[2]. 鄭人杰．計算機(jī)軟件測試技術(shù)．北京：清華大學(xué)出版社牵咙，1992
[3]. Bart Broekman and Edwin Notenboom.Testing Embedded Software. 2003
[4]. 李慶誠，張建華攀唯，雷楊. 嵌入式系統(tǒng)的系統(tǒng)測試和可靠性評估.http://www.uml.org.cn/Test/200902197.asp
[5]. 戶軍茹. 嵌入式軟件關(guān)聯(lián)測試方法的研究. 西安：西安理工大學(xué)碩士學(xué)位論文洁桌，2007
[6]. 胡一飛. 嵌入式軟件測試技術(shù)的研究及其在閃存文件系統(tǒng)測試中的應(yīng)用. 上海：同濟(jì)大學(xué)碩士學(xué)位論文，2007
[7].?OpenMax.?http://www.hudong.com/wiki/OpenMax
[1]. 陳全員. 可視化技術(shù)在軟件測試集生成中的應(yīng)用. 同濟(jì)大學(xué)碩士學(xué)位論文. 2005
