大型軟件中的QF快速集成機制及自動選擇算法

向 尕 張仰森

(北京信息科技大學 北京 100192)

0 引 言

大型軟件具有開發人員眾多、軟件規模大、復雜度高、模塊多、補丁多、部分補丁依賴具體的硬件資源及軟件配置參數等特點。比如電信領域，其中某一個網元的軟件通常由數十、數百的工程師分模塊來開發完成，軟件的規模和復雜度都較高。軟件進行質量的測試,是對軟件質量的保障的十分重要的方式[1]。在大型軟件產品發布交付之前的集成和驗證階段，會發現一些在前期單元測試和模塊功能測試中無法發現的問題。為了修復這些問題，各個模塊通常會提供快速補丁(Quick Fix，QF)。與此同時，這個階段通常非常接近產品的交付時間點，目前為了縮短產品的交付周期，通常給系統集成和驗證的時間很短，同時對按期交付的時間要求非常嚴格。因此，在大型軟件開發中靠近交付時間點的集成驗證階段，快速集成QF，并且保證產品質量穩定、保證按期交付成為一個需要解決的重要問題。如果要多集成QF，則有可能延期交付。如果優先按時交付，則有可能無法集成所有的QF。

要將這些QF集成到產品中，傳統的方法有三種：

(1) 在發布的產品中不包括這些QF，優先保證交付時間，等待后續發布的補丁包(Patch)來集成，這樣的缺點顯而易見，QF不能被迅速地集成到即將發布的產品中，無法保證提高產品的質量。

(2) 將這些QF加到產品發布中，重新編譯軟件模塊，這樣做的問題是有可能延遲交付時間、需要重新運行已完成的測試用例，更為嚴重的是，有可能引入新的問題,影響產品質量的穩定性。

(3) 提供文檔，讓終端用戶手動安裝QF，手動檢查QF安裝的日志文件，這無疑增加了用戶安裝的復雜度，增加了安裝的時間，特別是在QF數目巨大的時候，這樣將多耗費用戶大量的時間，降低產品的質量形象。在文獻[2]中，介紹了補丁分發管理系統來幫助用戶選擇和安裝合適的補丁包。

因此，尋找快速的QF集成方法變得非常重要。有了快速的QF集成方法，即使在非常接近產品發布的時間點，仍然可以快速集成QF，從而既保證按期交付，又能提高產品軟件質量。

1 QF快速集成機制

1.1 持續集成

眾所周知，隨著代碼量的劇增，軟件的復雜度隨之增加，軟件集成變得很困難。為了快速解決集成中的問題，保證每個軟件模塊能快速地被集成，持續集成的概念被提出并推廣[3-6]。持續集成是一種敏捷開發的實踐[7]。文獻[8]討論了持續集成中考慮測試用例合理執行順序，以提高發現問題的效率，節省時間。文獻[9]在持續集成中同時考慮到功能性測試和非功能性測試。文獻[10]提到Travis CI系統的某些特性功能被誤用。持續集成的主要目的是盡早地集成代碼，文獻[11]描述了特定領域的具體應用。盡早地、經常性地集成，能有效地提高軟件質量，降低風險。這樣能盡早發現問題，避免項目提交的失敗和延遲[12-13]。另隨著信息化應用水平日益提高，為用戶提供及時、靈活的更新已是日益迫切的需求[4，13-14]。

通常而言，持續集成主要應用于開發階段。主要包括以下關鍵點：

(1) 每日編譯一次代碼，這樣能將最新的代碼包括在軟件包中。

(2) 增加自動測試，能快速驗證基本功能和新代碼。

(3) 在持續集成中，能盡早發現集成的問題。這樣，軟件工程師可以將主要精力專注于修復軟件問題和開發新代碼；而不需要將主要精力放在集成及發現集成中出現的問題。

1.2 基于QF模式的持續集成及測試

但是上述持續集成的思想用于交付之前的系統集成和驗證階段，仍不能滿足所有需求。自動測試可以覆蓋基本功能測試，但是對于一些組合的場景、復雜的場景，以電信領域的軟件產品為例，針對特定運營商某些場景的軟件更新和修改的測試，或者不適合自動測試場景的測試用例，仍然需要手動測試，如果全部模塊重新編譯，理論上說為了保證軟件產品的質量，所有手動測試都需要重新驗證。這在時間和人力成本上幾乎不可接受。因此在實際中，通常會選擇小部分有代表性的測試用例，重新運行。這樣做的問題在于以個例代替整體，存在質量風險。因此本文提出一種基于QF模式的持續集成及測試機制。在開發通信產品的過程中，整個集成和測試階段(甚至在非?？拷浖a品發布的時間點)，一旦發現軟件問題，由相應模塊提供QF,并被快速集成，然后部署在運行的機器上，以便未進行完的測試用例繼續在此機器上運行，并驗證此QF修復的問題。與開發階段不同，不采用整個模塊重新編譯，避免重新安裝部署，可以減少反復重新安裝的時間，減少整個模塊替換引入新軟件問題的潛在風險。在這個過程中，我們需要權衡并盡量找到最優的平衡點：在保證產品總體質量的同時，盡可能多地集成QF。要做到這一點，需要盡量地讓QF的停止提交時間靠近產品最后發布的時間，與此同時，要嚴格地保證產品質量。不能因為集成了某一個QF，導致產品質量的嚴重衰退。這樣，才可以實現平穩迅速地集成更多的QF的目標(如圖1和圖2所示)，既能大力改善產品質量，又能避免延長測試時間，避免延期發布產品。

T1：產品開發階段 T2：產品的系統集成及驗證階段

T3：Patch(QFs)集成及測試階段 D1：產品交付時間點

D2：Patch交付時間點

對比以上圖1和圖2,我們可以清楚地看到，相比較傳統的集成測試模式，基于QF模式的持續集成能減少T3時間段的Patch集成測試工作，提高在D1點交付的產品質量。

綜上，基于QF模式的持續集成方式具有如下優點：

(1) 在發布產品之前，能盡快地集成所有已有的QF。這能夠顯著地提高產品質量。

(2) 所有子模塊軟件包不需重新編譯交付，也不需要重新部署安裝，節省大量集成與驗證時間。

(3) 已經驗證過的測試用例無須重新測試，這樣能保證軟件包質量沒有衰退。在剩下的測試中主要關注未測試過的測試用例，以及QF所提供的軟件修復。

2 QF自動選擇算法

基于前文所述的基于QF的持續集成模式，我們進一步研究QF自動選擇算法。

2.1 安裝過程分析

大型軟件的安裝過程相對比較復雜，部署步驟多，而且與具體的硬件資源、軟件模塊等配置相關。我們按照產品的安裝過程，將所有安裝過程分為n個步驟，同時將所有QF分為n+1個集合(P0,P1,…,Pn-1)。如圖3所示。

根據安裝過程，將QF集合分為n個子集合。

All_QF={P0,P1,…,Pn-1}

其中:

P0={fx,fx+1,…,fx+l}

P1={fy,fy+1,…,fy+m}

?

Pn-1={fz,fz+1,…,fz+k}

式中：

(x,y,z,l,m,n,k)∈N

fi(i∈(x,x+1,…,x+l,y,y+1,…,y+m,z,z+1,…,z+k)

fi是來自不同的模塊QF。為方便問題討論，設每個fi的安裝需要約4條命令完成(包括拷貝、檢查cksum值、解壓、安裝等)。如圖4所示。將QF按照集合All_QF={P0,P1,…,Pn-1}來安裝，可以減少命令單獨執行。所有QF的安裝簡化為n條命令。

在前面所述的n個固定的點，通過輸入固定的n條命令，在P0，P1,…，Pn-1集合中所包含的所有QF將被自動安裝好。這樣多個QF的安裝本來需要[(l+1)+(m+1)+…+(k+1)]×4條命令，縮減為n個固定的命令(n的大小取決于安裝步驟數目大小)。顯而易見，當n較小，而QF數目([(l+1)+(m+1)+…+(k+1)]×4)較大時，此方法的優勢更為明顯。這n條命令可以被集成到正常安裝和升級的步驟中，如果某兩個步驟之間，沒有QF要被安裝，則可以使Px為空。這樣做的好處是接口統一。

2.2 算法步驟

算法目標：考慮到每個QF適用于不同的軟件模塊、安裝的特定步驟、平臺、服務器類型和操作系統類型等，在安裝每個QF時，自動檢測以上信息，自動選擇并部署所需的QF，無須用戶做出人工判斷。

算法輸入：

1) 全體QF集合：

{fx,fx+1,…，fx+l,fy,fy+1,…，fy+m,…,fz,fz+1,…，fz+k}，

其中:

(x,y,z,l,m,n,k)∈N

fi(i∈(x,x+1,…,x+l,y,y+1,…,y+m,z,z+1,…,z+k)

2) 每個QF都有一組屬性標簽：

fiAttribute=[software_module,apply_phase,

servertype,OStype,…]

算法輸出：

All_QF={P0,P1,…,Pn-1}

其中:

P0={fx,fx+1,…,fx+l}

P1={fy,fy+1,…,fy+m}

?

Pn-1={fz,fz+1,…,fz+k}

算法描述：

1) 輸入全體QF集合：{fx,fx+1,…,fx+l,fy,fy+1,…,fy+m,…,fz,fz+1,…,fz+k}。

2) 輸入每個QF集合都有一組屬性標簽fiAttribute=[software_module,apply_phase,servertype,OStype]。

3) 獲取目標平臺的具體硬件資源、軟件配置、服務器類型、操作系統類型等信息。

4) for each QF:

將屬性標簽與獲取的信息相匹配。

如果匹配成功：

QF放入合適的子集合Pii∈{0,1,…,n-1}。

否則：

跳過該QF,并給出提示信息，此QF未能分入合適的子集合。

5) QF遍歷完成，結束退出。

算法復雜度約為O(QF_number)，其中QF_number為QF的數目，因此算法復雜度接近于多項式。在現有的硬件資源條件下，運行速度很快。

另考慮到日志內容繁多，為減少人工檢查安裝日志的時間，支持自動檢查安裝日志，可以對每一個QF，進行特定關鍵字搜索，以確定所有QF安裝成功，無報錯信息。

綜上，這種QF的自動安裝機制及自動選擇算法，具有以下優點：

(1) 所有的QF可以自動安裝，不需要用戶在安裝時手動輸入命令。

(2) 根據服務器配置類型、配置參數等具體信息，支持自動選擇適用的QF，并自動地安裝。

(3) QF安裝的日志，能自動檢查，發現安裝失敗的QF，無須人工檢查。

(4) 合適的體系結構，讓QF的集成簡單方便，無須太多編碼工作。

(5) 大大減少了QF的安裝時間。

3 系統設計及測試結果分析

3.1 系統設計及實現

基于前文提出的QF快速集成機制及自動選擇算法，我們設計實現了如圖5所示系統結構。

(1) 軟件模塊1-n，是大型軟件產品的軟件模塊,提供QF。

(2) QF快速集成模塊：負責將QF集成。提供統一的文件來處理每個QF。設計統一的QF處理結構，以及針對每個QF的配置文件。這樣能將集成新QF的工作量減到最少。每次集成無須新加代碼，只需要將QF內容及相應的配置文件定義好，拷貝至指定目錄下即可。

(3) QF庫：用于存放所有的QF和每個QF的配置文件，配置文件用于程序根據具體的服務器配置等，自動選擇需要安裝使用的QF。每個QF按照如下模板提供QF的屬性標簽，作為自動選擇算法模塊的輸入：

softwaremodule=; applyphase=; servertype=;OStype=;…

流程如圖6所示。

(4) QF安裝自動檢測模塊：對一個QF，可以自動檢測安裝是否成功，日志是否無錯誤和異常。

3.2 測試結果及分析

我們通過部署8個版本的軟件包，收取相關的數據。我們分別收集了部署本文機制方法和沒有部署的各項數據，進行比較和分析。為方便討論，按照QF數目從小到大的順序，對軟件版本進行了重新排序。

1) 安裝部署QF時間顯著減少。為了客觀計算減少的時間，忽略掉其他影響安裝的時間，我們在收集數據時，僅計算用戶或系統調用命令所耗費的時間。

如圖7所示。我們可以看到，引入基于QF模式的集成機制及自動選擇算法后，QF安裝的時間減少了10～142分鐘；而且QF數量越多，節省的時間就越多。當有多套系統需要部署和升級的時候，節省的時間成倍增長。

2) 檢查安裝日志的時間顯著減少。我們收集了檢查安裝日志的時間并進行對比。以前用戶需要一個一個檢查QF安裝日志，以便確定每個QF安裝成功。引入日志自動檢測機制后，可以由系統對安裝日志進行自動檢查，確保QF安裝正確，用戶只需要檢查日志自動檢查的總結日志。總結日志非常簡單，只包括對每一個QF安裝結果的說明，成功或失敗。因此能減少大量手動檢查日志的時間。如圖8所示。

3) 產品質量提升。如圖9所示，橫坐標表示每個Load，縱坐標表示對應于每個Load集成的QF數目。顯而易見，集成的QF數目越多，修復的軟件問題越多，產品質量也更好。

4 結 語

本文提出一種基于QF的快速集成機制，并設計實現基于此機制的QF自動選擇算法。實驗及實踐證明，可快速集成QF，具有不延遲產品發布時間、提高產品軟件質量的優點；與此同時，能夠節省用戶的安裝時間，減少人工檢查安裝日志的時間；適用于大型軟件的交付集成及驗證，推薦進一步推廣使用。下一步，研究集成測試序列生成方法[15-16]在持續集成中的應用。