“魂芯”DSP配套基礎軟件的自動化測試平臺①

林廣棟,耿 銳,王 昊

(中國電子科技集團公司第三十八研究所 集成電路設計中心,合肥 230088)

“魂芯”DSP是由中國電子科技集團公司第38研究所自主研發(fā)的一款高性能浮點處理器芯片.該芯片配套有若干個自主開發(fā)的基礎軟件單元,如編譯器、主機調試器、軟件模擬器等等[1,2].“魂芯”芯片配套的各軟件單元是一個緊密結合的整體,其中任何一個軟件單元產生錯誤都會使整體開發(fā)環(huán)境產生錯誤.這些軟件單元經常會修復一些自身的錯誤,但常常帶來另外一些新的問題.或者單個軟件單元的修改導致其與其他軟件單元不再匹配,進而使整個系統(tǒng)無法工作.發(fā)現(xiàn)與解決這些問題非常耗費時間和人力.雖然存在測試工具和方法對某個單獨的軟件單元進行測試,但是缺少一種對整體軟件環(huán)境進行測試的工具[3–5].

為解決以上問題,設計并實現(xiàn)了一個以主機調試器軟件為測試核心的自動化測試平臺,稱為: 回放式自動化測試平臺.回放式自動化測試平臺是一個基于命令行接口對“魂芯”DSP主機調試器軟件進行自動化測試的平臺.該平臺支持以命令行方式添加測試用例,并自動化地將測試用例中的調試記錄回放.若回放結果與添加測試用例時的輸出結果不一致,則認為測試失敗; 若全部一致,認為測試成功.由于通過主機調試器軟件調試的應用程序與編譯器、軟件模擬器都有關系,本平臺也可以同時測試其他軟件單元.本平臺支持批量式回放測試記錄,當主機調試器、編譯器、模擬器等任何相關的軟件單元發(fā)生變化時,可批量回放測試記錄,以測試軟件系統(tǒng)的整體正確性.

1 設計

1.1 被測軟件單元介紹

被測軟件單元是“魂芯”DSP配套的一系列軟件單元,包括: C編譯器、匯編工具鏈、主機調試器、軟件模擬器、調試鏈接服務軟件等等.它們之間的關系如圖1所示.

使用“魂芯”DSP主機調試器軟件的唯一接口就是命令行,而本測試平臺以命令行方式進行測試,因此可以測試“魂芯”DSP調試器的絕大部分功能.由于“魂芯”DSP主機調試器的調試對象是使用“魂芯”DSP編譯器編譯出的應用程序,因此,調試結果的正確性與編譯器編譯出的程序正確性、編譯器生成的調試信息的正確性密切相關.因此,本平臺還可以對編譯器進行測試.自動化測試平臺存儲的測試用例不僅包括調試器的輸入輸出,還包括源代碼程序.每次回放測試用例時,都要重新編譯一次源代碼程序,以實現(xiàn)對編譯器的測試.若以軟件模擬的方式運行被調試程序,則調試結果的正確性與“魂芯” 芯片軟件模擬器的正確性也密切相關.因此,本測試平臺還可以用來測試軟件模擬器.本平臺支持添加基于硬件平臺的測試用例,因此,也可以測試與硬件平臺通信的調試鏈接服務軟件.各軟件單元的功能以及測試方式如表1所示.

圖1 被測軟件單元之間的關系

表1 被測試軟件單元的功能與測試方法

1.2 編程語言與基礎設施

回放式測試平臺使用 TCL (Tool Command Language)腳本語言編寫.TCL語言是一種解釋型語言.在TCL語言中,所有的變量都可以看成是字符串.TCL語言集成了大量對字符串進行處理的功能,且語言本身就支持正則表達式的解析.選擇TCL語言是因為它進行字符串處理的功能很強,而本測試平臺就是基于字符串同被測試對象進行交互的.

回放式測試平臺還使用了Expect軟件組件.Expect是一種基于TCL語言的支持與其他軟件進行交互的軟件組件.基于 Expect,可以使用常規(guī)的 TCL 語言,也可以使用Expect提供的額外功能.使用Expect,可以方便地向其他軟件發(fā)送字符串,然后對其他軟件發(fā)回的字符串進行解析.Expect已經構建了一個軟件框架,可以向第三方軟件發(fā)送命令,然后期待(expect)第三方軟件的某種格式的回復.由于回放式測試平臺的測試對象是調試系統(tǒng),它們之間通過字符串進行交互,因此使用Expect是比較合適的選擇.

1.3 整體架構

使用自動化測試平臺分為兩個階段: 錄制(record)階段和回放(replay)階段.錄制階段,回放式測試平臺指導用戶指定一個測試用例號、編譯源文件、開始調試過程.在錄制過程,用戶不斷輸入調試命令,對調試系統(tǒng)、底層硬件、編譯器、軟件模擬器等進行測試.若用戶在錄制階段發(fā)現(xiàn)主機調試器的輸出與預期不符,用戶應立即展開排查,解決問題.即用戶錄制到測試用例庫中的測試用例都應該是正確的、符合預期的.

自動化測試平臺把發(fā)送給主機調試器的命令記錄在一個文本文件中,把主機調試器反饋的回復記錄在另外一個文本文件中.前者稱為命令序列,后者稱為回復序列.當測試平臺檢測到用戶發(fā)送exit命令時,終止錄制過程.每個測試用例還包括一個編譯被調試應用程序的makefile文件.命令序列文件、回復序列文件、makefile文件、應用程序源代碼文件、測試用例號共同組成了一個測試用例.測試用例被存儲在文件系統(tǒng)中,稱為測試用例庫.測試用例庫的組織結構如圖2所示.testcase文件夾存儲每個測試用例調試的應用程序源代碼以及makefile.每個測試用例號一個子文件夾,文件夾的名字就是測試用例號.testsuite存儲命令序列和回復回序文件.以.cmdstr為后綴的是命令序列文件; 以.resp為后綴的是回復序列文件,文件名就是測試用例號.

圖2 測試用例庫組織結構

在回放階段,用戶只需要指定測試用例號,自動化測試平臺會自動開始回放過程.測試平臺首先會根據測試用例記錄的makefile文件,運行該makefile文件,編譯生成可執(zhí)行文件.測試平臺隨后啟動一個主機調試器軟件,讀取該測試用例的命令序列,發(fā)送給主機調試器軟件.測試平臺每發(fā)送一次命令,都等待主機調試器的回復,并將主機調試器的回復與測試用例記錄的回復比較.若比較不同,則認為回放失敗,立即報錯,停止回放.若比較相同,則接著發(fā)送命令序列中的下一條命令,直到檢測到exit命令為止.整個過程如圖3所示.

1.4 常用命令緩存

每次進行調試時,需要進行與模擬器(或真實芯片)之間建立鏈接、選擇被調試芯片、選擇被調試文件、加載文件等調試操作.這些操作需要一些固定序列的調試命令來驅動.添加基于同一份應用程序工程的測試用例時,前面若干條調試操作也經常是相同的.為了方便使用本調試平臺,可在根目錄下添加common.cmdstr文件.該文件存儲每個測試用例的前面若干個調試命令,每行存儲一個調試命令.添加測試用例時,首先執(zhí)行common.cmdstr中存儲的調試命令,然后再提示用戶輸入剩余調試命令.所有的調試命令,包括common.cmdstr中的調試命令和用戶輸入的調試命令,都會被記錄到測試用例中.回放測試用例時,首先執(zhí)行common.cmdstr中存儲的調試命令,這些調試命令的回復不與測試用例回復序列進行比較.然后再執(zhí)行測試用例中相應個調試命令之后的調試命令.例如,若common.cmdstr中有 3 條命令,則回放時,首先執(zhí)行common.cmdstr中的3條命令,然后從測試用例中的第4條命令開始執(zhí)行.通過這種方法,可以方便地進行測試用例之間的移植.例如: 基于軟件模擬器的內核,已經添加了一批測試用例.現(xiàn)在希望復用這批測試用例,將其在真實芯片上回放,只需要在common.cmdstr加入一行與真實芯片建立調試連接的命令即可.回放時,測試平臺首先執(zhí)行common.cmdstr中的這行命令,與真實芯片建立鏈接,并且不將主機調試器的回復與測試用例中的回復進行比較.之后,測試平臺再從測試用例中的第二個命令開始進行執(zhí)行,并將主機調試器軟件的實際回復與測試用例記錄的回復比較.只要被調試應用程序僅僅與處理器內核有關系,基于模擬器的調試回復與基于真實芯片的調試回復應該是相同的.若回放成功,說明本測試用例測試通過; 若回放失敗,說明本測試用例未能測試通過.

圖3 回放式自動化測試平臺工作流程示意圖

1.5 臨時文件

為了避免編譯應用程序生成的.out、.o等臨時文件混雜在測試用例庫中,本測試平臺在添加測試用例和回放時,都會把被調試程序源代碼復制到測試平臺所在目錄下workdir目錄中,再進行編譯、調試.被調試程序的makefile應位于被調試程序源代碼所在目錄的根目錄下,makefile中的編譯命令都應該是相對路徑.被調試程序的整個工程源代碼都應當位于該目錄下.調試時,用戶需要指定加載的.out可執(zhí)行文件.用戶必須指定位于workdir中剛剛被本測試平臺編譯出來的.out文件,不能指定其他文件夾中的.out文件.否則,無法進行下一步操作.

1.6 限制條件

由于回放式測試平臺通過字符串與主機調試器之間進行交互,并通過字符串比較判斷測試是否成功,因此本測試平臺的使用具有一定的限制條件:

1) 不能運行scanf等接受用戶輸入功能的調試過程.

2) 調試過程中不能使用暫停命令; 運行之后,再執(zhí)行“暫?！闭{試命令,不同的平臺上處理器暫停的時機不同,測試用例的回復和回放時的回復不一定相同.因此,不能運行含有“暫?！闭{試命令的測試用例.

3) 單核運行時,應在單核停止之后再進行下一步調試操作.多核運行時,必須在所有的核停止之后再進行下一步調試操作.

4) 多核運行時,若其中一個核帶有printf打印操作,則運行結果有可能是不確定的.有可能是其中一個核先停下,也有可能是另一個核先停下來.因此,執(zhí)行多核調試測試用例時,謹慎使用printf功能.只有當用戶可以確定多核運行時每個核的輸出(printf)順序時,才添加多核運行測試用例.

5) 暫時不支持通過“上”、“下”方向鍵選擇上一條調試命令.

6) 為了方便將測試用例在不同主機上遷移,用戶輸入的測試用例目錄、makefile目錄等等都應該使用相對目錄.makefile內調用occ.exe(編譯器)時應不帶目錄,通過環(huán)境變量找到occ.exe.

1.7 應用情況

該自動化測試平臺已經提供給“魂芯”DSP配套基礎軟件的測試人員使用.測試人員在該平臺上添加了大量測試用例.這些測試用例包含軟件模擬器調試和硬件芯片調試兩類.測試用例加載調試的應用程序中包括對DSP的各項功能進行測試的應用程序.這些應用程序中也包括復雜的C語言程序,以測試編譯器的正確性.這些測試用例可以一次性批量回放.測試人員反映該平臺添加測試用例方便,回放測試用例更加快捷.每次發(fā)布一個“魂芯”DSP開發(fā)環(huán)境的正式版本前,測試人員不必再逐項進行各項調試操作確認各功能的正確性,只需輸入一條命令即可,大大減小了測試人員的工作量.

2 總結

本文介紹了一種“魂芯”DSP配套基礎軟件的自動化測試平臺.該平臺以主機調試器為測試對象,通過主機調試器與其他軟件模塊的交互,間接地測試其他軟件單元.該平臺可以方便地添加測試用例,也可以批量回放測試用例.是一個簡單高效的自動化測試平臺.下一步的工作方向是改進回放時的字符串匹配方式,不再簡單地進行字符串比較,而是利用正則表達式,僅僅對關鍵的子串進行匹配,從而減少使用本測試平臺時的限制條件.另一個工作方向是將該測試平臺與集成開發(fā)環(huán)境(IDE)結合起來,將用戶通過界面的調試動作記錄下來,再進行批量回放,以實現(xiàn)更加方便地添加測試用例.

參考文獻

1林廣棟,黃光紅,耿銳.一種C語言級單步調試系統(tǒng)的功能實現(xiàn)方案.單片機與嵌入式系統(tǒng)應用,2015,15(2): 48–51.

2林廣棟,朱艷,黃光紅.一種調試系統(tǒng)中C語言復雜變量查看功能實現(xiàn)方案.中國集成電路,2015,24(8): 41–49.

3宋婷.淺談軟件測試自動化解決方案.中小企業(yè)管理與科技,2010,(7): 217.

4徐進.自動化軟件測試的分析.信息技術,2010,(3): 152–155.

5郭俊.軍用軟件測試的影響因素及改進措施.現(xiàn)代計算機,2007,(11): 54–55.[doi: 10.3969/j.issn.1007-1423-B.2007.11.018]