基于依賴要素比對的國產操作系統兼容性測試方法

陳 鵬，陳麗容，高艷鹍,李洪波

(1.中國航天科工集團第二研究院 北京計算機技術及應用研究所，北京 100854;2.73658部隊 信息技術中心,北京 239400)

0 引 言

隨著我國操作系統技術的迅猛發展，對其進行兼容性測試一直是一個亟需解決的問題[1]。目前對操作系統進行兼容性測試主要是判斷其實現是否符合國際標準LSB[2]或者POSIX[3]。然而目前國產操作系統廠商眾多，如中標、普華、麒麟等操作系統都存在著大量的用戶群體，并且操作系統廠商都有著各自的開發標準并且各開發標準存在著較大的差異，導致國產操作系統難以形成統一的開發標準；另外操作系統開發廠商經常各自適配不同的第三方庫，導致標準符合性的測試方法無法解決當前的全部需求[4]。許侃等曾提出通過編寫測試腳本在整機上運行來測試操作系統整機兼容性的方法，測試了硬件在操作系統上的運行性能以及穩定性[5]。在其它操作系統領域，任海鵬等曾提出利用安卓原生CTS測試包以及人機交互界面的Android操作系統兼容性測試技術，提升了兼容性測試的自動化能力[6]。另外，張曉敏提出針對軟件功能設計測試環境及用例，測試軟件在操作系統中運行效率的測試方法[7]。本文吸取前人將操作系統與軟硬件結合測試的經驗，從操作系統兼容性概念著手，對應用程序在操作系統中運行的原理進行分析，提出了一種基于依賴要素比對的國產操作系統兼容性測試方法，并利用相關實驗驗證了該方法的可行性。

1 操作系統兼容性以及依賴要素

本文對操作系統兼容性的概念進行分析，了解到操作系統的兼容性測試可以引申到應用程序在操作系統中的運行情況，進而對應用程序在操作系統中運行的原理進行解析，了解到應用程序在操作系統中運行需要對操作系統提供的庫函數進行調用，而對庫函數的調用又依賴于操作系統提供準確的庫函數簽名。進而明確了通過比對庫函數得到操作系統兼容性測試結果的方法。

通過對ELF文件格式進行分析，明確操作系統內可執行程序以及庫文件都是以ELF文件格式保存的，并且ELF文件格式中保存了庫文件的各種信息以及庫文件所包含的庫函數的信息，進而找到了基于對ELF文件格式進行分析得到操作系統兼容性依賴要素的方法。

最后通過上述兩點的分析，明確了操作系統兼容性依賴要素并對依賴要素進行了分級。

另外，由源代碼到可執行程序的過程需要經過編譯器、連接器等工具的配合工作才能實現，考慮到編譯器等工具并非操作系統提供的工具，為不可控因素，故在本文提供的兼容性測試方法中默認庫函數的編譯由同一類編譯器、連接器進行，進而排除編譯器等對可執行代碼的影響。

1.1 操作系統兼容性

操作系統兼容性是指在一個操作系統上面開發的應用程序可以不加修改、不用編譯直接運行于另外一個操作系統上的特性[8]。我們把前者稱為當前操作系統，把后者稱為目標操作系統。程序在操作系統中轉變為可執行文件需要經歷4個步驟：預編譯、編譯、匯編以及鏈接。前3個步驟是對程序本身進行分析，將程序翻譯為機器可以執行的指令的過程；鏈接是一個重定位的過程，當指令內涉及某個符號時，需要從操作系統或者程序本身找到這些符號，將目標在系統中的地址填入指令中，這個過程就是鏈接。鏈接分為靜態鏈接與動態鏈接兩種，其中靜態鏈接是將多個文件組合成一個可執行程序的過程，動態鏈接則是對系統庫文件進行查詢，找到程序調用的庫函數的地址進行重定位的過程。通過以上分析可以知道，程序在操作系統上的運行涉及到對系統庫函數的調用，因此本文找到當前操作系統以及目標操作系統的庫文件和庫函數，對兩操作系統依賴要素進行比對，根據比對結果判斷操作系統兼容性。

1.2 ELF文件格式及各個段介紹

ELF(executable and linkable format)是UNIX系統實驗室(USL)作為應用程序二進制接口(application binary interface，ABI)而開發和發布的，也是Linux的主要可執行文件格式[9]。它保存了程序編譯以及執行時的各種相關信息(如文件名、文件絕對路徑、版本號、代碼段、數據段、.bss段等)。

ELF一個特別的優點在于同一文件格式可以用于Linux內核支持的幾乎所有的體系結構上。該格式標準不僅用于用戶空間應用程序和庫文件，還用于構建模塊，且內核本身也是ELF格式。ELF文件格式包括文件頭(ELF header)、程序頭(program header table)、節頭表(section header table)以及各個段(sections)[10]。表1給出了ELF文件格式的一些字段及其含義。

可以看出ELF文件頭中保存著各個段的起始地址以及長度，通過地址以及長度可以計算出各個段的地址范圍；.text段保存著程序以及庫文件的代碼段，通過對.text段進行解析，就可以得到庫文件包含的所有庫函數的編譯信息；.symtab段保存著庫文件的符號表，其中包含符號的名稱、地址以及長度，通過判斷符號的地址是否在.text段的地址范圍內，就可以確定該符號是否是庫文件所包含的庫函數[11]。

1.3 操作系統兼容性依賴要素

程序能在操作系統中運行主要依靠的是調用系統提供的庫函數[12]，對庫函數的準確調用又依賴于系統提供正確的庫函數簽名，考慮到程序依賴的多個庫函數可能存在于同一個庫文件中，操作系統兼容性依賴要素主要分為3級，分別為庫文件的.text段、庫函數對應的.text段、庫函數簽名對應的.text段，這里的函數簽名指函數的參數傳遞。

2 基于依賴要素比對的兼容性測試方法

操作系統的升級往往伴隨著庫函數的修改，兩個不同類型的操作系統也必然存在著庫函數實現上的差異，為了保證用戶程序可以在不加修改的情況下在目標操作系統中運行，應保證軟件在當前和目標操作系統中調用的庫函數的簽名相同，基于依賴要素比對(dependency function element comparison，DFEC)的兼容性測試方法基于該原則，對當前和目標操作系統在庫函數的實現層面進行比對，并根據比對結果將兼容性測試報告反饋給用戶。

DFEC兼容性測試方法分為兩個過程：首先對當前操作系統和目標操作系統進行庫文件掃描，獲取庫文件和庫函數的包含關系，搭建操作系統庫函數模型；之后根據搭建好的庫函數模型，對當前和目標操作系統進行依賴要素的分級比對，得到兼容性測試結果。

2.1 搭建當前和目標操作系統庫函數模型

在操作系統中，庫函數信息以二進制碼的形式保存在庫文件中，掃描庫函數信息要先獲取操作系統的所有庫文件，而庫文件又以.so的后綴名保存在操作系統中，因此首先遍歷操作系統文件資源，獲取所有帶有.so后綴名的庫文件。這里的庫文件包括系統自帶的庫文件以及第三方庫文件。

找到了庫文件后，需要基于ELF文件格式對庫文件進行掃描，獲取庫文件包含的庫函數信息，基于1.2節對ELF文件格式的介紹，ELF文件格式的.symtab段保存了文件的符號表，其中包含了符號的名稱、地址以及長度，為了保證提取的符號是庫文件包含的庫函數，需要對符號表進行篩選，ELF文件格式的函數信息保存在.text段中，另外在ELF的頭部表中保存著各個段的地址以及長度，從中取出text的起始地址和長度，就可以得到.text段的整段范圍，這樣，對.symtab段中的符號地址進行范圍篩選就能得到所有在.text段中的符號，也就是庫函數。

在知道了庫函數的名稱、地址以及長度后，就可以從庫文件中讀出所有庫函數的信息，進而對庫函數信息進行解析，獲取每個庫函數對應的.text段內容以及庫函數簽名對應的.text段內容。掃描庫函數信息的流程如圖1所示。

圖1 掃描庫函數信息

2.2 對依賴要素進行哈希值計算

從庫文件ELF格式中獲取的.text段內與各依賴要素有關的部分實際上是一串二進制數，這些二進制數對應機器指令的機器碼，鑒于二進制數過于冗長，并且對依賴要素的比對只需判斷兩操作系統下的依賴要素是否相同，不需要知道依賴要素的具體改動情況，我們將獲取的二進制數利用哈希算法轉換成哈希值，對兩操作系統下的依賴要素進行哈希值比對，節省比對的時間。

2.3 對目標和當前操作系統進行依賴要素比對

構建好庫函數模型后，依據分級好的操作系統兼容性依賴要素，以庫函數為單位對目標和當前操作系統進行依賴要素比對。比對之前需要確認在目標操作系統中是否可以找到當前操作系統提供的庫文件，在找不到庫文件的情況下，認為目標操作系統缺少需要的庫文件，不能兼容于當前操作系統。

在找到所有的庫文件后，按照依賴要素分級，分別對當前操作系統以及目標操作系統中每一個庫文件.text段、庫文件下庫函數的.text段、庫函數簽名的.text段進行逐級比對，如果比對過程中有庫文件的.text段一致，則認為該庫文件下的所有庫函數未進行修改，可以判定該庫文件下的所有依賴要素未影響操作系統的兼容性；如果庫文件的.text段不一致，則需要對該庫文件下的所有庫函數進行之后的兩個.text段的比對，若比對過程中某一級的.text段一致，則認為庫函數未進行對操作系統兼容性有影響的修改，判斷該庫函數的修改未影響操作系統兼容性。如果所有庫函數的修改都被判定為未影響操作系統兼容性，則認為操作系統的修改沒有影響到程序的運行，目標操作系統兼容于當前操作系統；若對某個庫函數的比對過程中每一級依賴要素的比對結果都不一致，則認為該庫函數的修改影響了程序的調用，對該庫函數進行調用的應用程序無法在目標操作系統上正確運行，目標操作系統不能兼容于當前操作系統。具體工作流程如圖2所示。

圖2 依賴要素分級比對流程

2.4 給出兼容性比對結果及建議

從2.3節中可以得到當前操作系統和目標操作系統的依賴要素比對結果，從依賴要素分級比對流程圖可以看出，依賴要素的比對結果決定著操作系統兼容性比對結果是兼容還是不兼容。對于比對結果是兼容的兩個操作系統，證明在當前操作系統下運行的應用程序可以不加修改地遷移到目標操作系統中。對于比對結果是不兼容的操作系統，在當前操作系統下運行的部分應用程序對目標操作系統中導致兩操作系統不兼容的庫函數進行了調用，因此無法直接遷移到目標操作系統中，對這些應用程序，DFEC兼容性測試方法對兩操作系統下比對結果不相同的依賴要素進行標紅顯示，為應用程序設計廠商以及操作系統廠商提供修改建議。

3 方法驗證

為了驗證方法的可行性，分別對利用同一套編譯工具的不同類型的操作系統和相同類型操作系統的不同版本的兼容性進行測試，并根據應用軟件的實際運行情況驗證測試結果的準確性。

3.1 在不同類型操作系統下的測試

3.1.1 測試方案

當前操作系統：centos7

目標操作系統：deepin15.4

基于DFEC兼容性測試方法，對兩操作系統中包含的所有庫文件進行掃描，獲得centos7操作系統和deepin15.4操作系統的庫函數依賴模型，對兩個操作系統的依賴要素進行比對，根據比對結果給出centos7操作系統和deepin15.4操作系統的兼容性測試結果。

3.1.2 兼容性測試結果

對兩操作系統下的庫文件進行掃描，比對庫文件中包含的庫函數信息。部分比對結果見表2。

在目標操作系統中找到了部分當前操作系統的庫文件，這些庫文件包含的庫函數在實現上與當前操作系統不同，但在函數簽名部分的哈希值比對結果還是一致的，但由于有部分庫文件以及庫函數未在目標操作系統下找到，判定對這些庫文件進行調用的程序無法被移植到目標操作系統下，目標操作系統不能兼容于當前操作系統。

3.1.3 應用軟件運行情況

選取dot工具對兼容性測試結果進行驗證，dot工具在centos下對libgvc.so.6和libcgraph.so.6進行了調用，這兩個庫文件在deepin15.4中沒有被找到，因此dot工具應該不能在deepin15.4下運行。將dot工具移植到deepin下運行，系統顯示“dot not found”，證明dot工具不能在deepin15.4操作系統下運行，兼容性測試結果無誤。

表2 centos7和deepin15.4依賴要素比對結果

3.2 在同一操作系統的不同版本下的測試

3.2.1 測試方案

當前操作系統：deepin15.4

目標操作系統：deepin15.9

基于DFEC兼容性測試方法，對兩操作系統中包含的所有庫文件進行掃描，獲得deepin15.4操作系統和deepin15.9操作系統的庫函數依賴模型，對兩個操作系統的依賴要素進行比對，根據比對結果給出deepin15.4操作系統和deepin15.9操作系統的兼容性測試結果。

3.2.2 兼容性測試結果

對兩操作系統下的庫文件進行掃描，比對庫文件中包含的庫函數信息。部分比對結果見表3。

表3 deepin15.4和deepin15.9依賴要素比對結果

經過掃描和比對發現，deepin15.4下的5704個庫文件在deepin15.9下均存在，并且庫文件的哈希值比對結果均一致，證明庫文件均未發生改變，因此判斷目標操作系統兼容于當前操作系統。

3.2.3 應用軟件運行情況

我們選取了包括Firefox瀏覽器、Google瀏覽器等常用軟件，結果這些軟件在兩操作系統下都可以正常運行，證明了兩個操作系統具備良好的兼容性，與實驗結果一致。

4 結束語

本文針對目前國產操作系統缺少兼容性測試方法的現狀，基于對操作系統兼容性概念以及動態鏈接原理的研究，提出了一種基于依賴要素比對的國產操作系統兼容性測試方法。該方法對操作系統內與兼容性有關的依賴要素進行提取和分級比對，根據比對結果得到國產操作系統兼容性測試結果，并利實驗數據驗證了方法的可行性。結果表明，基于依賴要素比對的國產操作系統兼容性測試方法不僅對操作系統兼容性給出了測試結果，還對導致操作系統不兼容的問題進行了定位，從而為國產Linux操作系統兼容性測試提供了研究方向和解決方案。