本申請涉及系統(tǒng)測試技術(shù)領域，具體而言，涉及一種集中配置管理系統(tǒng)測試報告的生成方法及裝置。

背景技術(shù)：

puppet是一種linux、unix平臺的集中配置管理系統(tǒng)，使用ruby語言，可管理配置文件、用戶、cron任務、軟件包、系統(tǒng)服務等。puppet把這些系統(tǒng)實體稱之為資源，puppet的設計目標是簡化對這些資源的管理以及妥善處理資源間的依賴關系。

在實際生產(chǎn)環(huán)境中，將puppet的資源封裝成模塊來完成環(huán)境的部署。同其他代碼一樣，模塊也需要進行測試才能夠保證其功能的正確性。通常情況下，會采用手工方式來進行測試，整理bug，修復最后上線使用。但是手工方式的效率相對很低，會降低整個產(chǎn)品迭代上線的速度，因此引入自動化測試。在整個自動化測試的過程中，會自動完成相關用例的執(zhí)行，收集執(zhí)行的結(jié)果并整理成一份可讀性較強的測試報告來反饋測試的情況。

puppet官方網(wǎng)站提供了一種開源的自動化測試化工具beaker，可用來調(diào)度虛擬測試環(huán)境來完成自動化測試。beaker是基于rspec的開發(fā)套件，rspec在執(zhí)行完成后執(zhí)行結(jié)果可以通過標準輸出，json，xml甚至輸出一份html文件來進行保存和展示。本文將rspec輸出的json結(jié)果進行了保存，統(tǒng)計分析，最后渲染成一份可讀性強的報告，克服rspec報告可讀性不強的缺點，同時實現(xiàn)報告的可訂閱功能。在相關技術(shù)里面有描述到，beaker是基于rspec的開發(fā)套件，rspec可支持json，xml，html這幾種類型的報告。在現(xiàn)有的方案里面，經(jīng)常使用到的就是利用rspec來輸出一份html報告。然而，在rspec報告中可以比較直觀的反應單個用例的執(zhí)行結(jié)果，但是在一次自動化測試的過程中，需要的不僅僅是單個用例的測試情況。通常情況下，需要整體上了解測試的情況。總結(jié)rspec測試報告，有如下幾方面的不足:沒有整體上反應測試的情況，報告主要針對單個用例進行分析，不進行整體的統(tǒng)計分析；報告的可讀性不好。對于json格式和xml格式的報告，對普通用戶來說是完全不可讀的，而其輸出的html報告，把所有信息都糅合在一份報告中，很難理出用戶關心的內(nèi)容，尤其是執(zhí)行錯誤的報告信息。在beaker測試過程中，會多次執(zhí)行rspec命令，輸出多份測試報告，現(xiàn)有技術(shù)暫時沒有提供方式能夠整合多份測試報告的結(jié)果。

針對相關技術(shù)中測試報告難以從整體上反映測試情況的問題，目前尚未提出有效的解決方案。

技術(shù)實現(xiàn)要素：

本申請的主要目的在于提供一種集中配置管理系統(tǒng)測試報告的生成方法及裝置，以解決相關技術(shù)中測試報告難以從整體上反映測試情況的問題。

為了實現(xiàn)上述目的，根據(jù)本申請的一個方面，提供了一種集中配置管理系統(tǒng)測試報告的生成方法。該方法包括：檢測集中配置管理系統(tǒng)的代碼是否已更新；若檢測到所述集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，所述多個待測試操作系統(tǒng)由所述集中配置管理系統(tǒng)配置；獲取所述多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例；逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果；基于所述多個測試結(jié)果生成測試報告。

進一步地，基于所述多個測試結(jié)果生成測試報告包括：對所述多個測試結(jié)果進行分析，得到第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息，其中，所述第一目標數(shù)據(jù)信息中至少包括：測試用例的數(shù)量、測試失敗的數(shù)量和測試成功的數(shù)量，所述第二目標數(shù)據(jù)信息中至少包括：每個待測試操作系統(tǒng)中每個模塊的測試信息和對待測試操作系統(tǒng)中模塊測試失敗的信息；將所述第一目標數(shù)據(jù)信息和所述第二目標數(shù)據(jù)信息填充至預設模板中，生成所述測試報告。

進一步地，逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果之前，所述方法還包括：生成與每個待測試操作系統(tǒng)中每個模塊對應的目標文件夾，其中，所述目標文件夾用于存儲對應的模塊的測試結(jié)果；確定每個目標文件夾的存儲路徑。

進一步地，逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果包括：確定當前正在執(zhí)行測試用例的模塊；基于所述當前正在執(zhí)行測試用例的模塊調(diào)整其測試結(jié)果指向的目標文件夾；將對當前正在執(zhí)行測試用例的模塊的測試結(jié)果逐條寫入指向的所述目標文件夾下。

進一步地，在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之前，所述方法還包括：獲取更新后的所述集中配置管理系統(tǒng)的代碼；將所述集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中；在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之后，所述方法還包括：將所述緩存區(qū)中更新后的代碼移動至工作區(qū)，根據(jù)所述測試用例和所述更新后的代碼對對應的模塊進行測試，其中，所述工作區(qū)是所述集中配置管理系統(tǒng)的代碼執(zhí)行時的目錄。

進一步地，所述集中配置管理系統(tǒng)的代碼包括多個分支代碼，將所述集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中包括：確定待同步至所述緩存區(qū)中的當前分支代碼；判斷在所述緩存區(qū)中是否存在以所述當前分支代碼命名的文件夾；如果在所述緩存區(qū)中不存在以所述當前分支代碼命名的文件夾，在所述緩存區(qū)中創(chuàng)建以當前分支代碼命名的文件夾，并將所述當前分支代碼同步至所述緩存區(qū)中以所述當前分支代碼命名的文件夾下。

為了實現(xiàn)上述目的，根據(jù)本申請的另一方面，提供了一種集中配置管理系統(tǒng)測試報告的生成裝置。該裝置包括：檢測單元，用于檢測集中配置管理系統(tǒng)的代碼是否已更新；確定單元，用于若檢測到所述集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，所述多個待測試操作系統(tǒng)由所述集中配置管理系統(tǒng)配置；第一獲取單元，用于獲取所述多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例；測試單元，用于逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果；生成單元，用于基于所述多個測試結(jié)果生成測試報告。

進一步地，所述生成單元包括：分析模塊，用于對所述多個測試結(jié)果進行分析，得到第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息，其中，所述第一目標數(shù)據(jù)信息中至少包括：測試用例的數(shù)量、測試失敗的數(shù)量和測試成功的數(shù)量，所述第二目標數(shù)據(jù)信息中至少包括：每個待測試操作系統(tǒng)中每個模塊的測試信息和對待測試操作系統(tǒng)中模塊測試失敗的信息；填充模塊，用于將所述第一目標數(shù)據(jù)信息和所述第二目標數(shù)據(jù)信息填充至預設模板中，生成所述測試報告。

進一步地，所述裝置還包括：第二獲取單元，用于在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之前，獲取更新后的所述集中配置管理系統(tǒng)的代碼；同步單元，用于將所述集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中；所述裝置還包括：移動單元，用于在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之后，將所述緩存區(qū)中更新后的代碼移動至工作區(qū)，根據(jù)所述測試用例和所述更新后的代碼對對應的模塊進行測試，其中，所述工作區(qū)是所述集中配置管理系統(tǒng)的代碼執(zhí)行時的目錄。

進一步地，所述集中配置管理系統(tǒng)的代碼包括多個分支代碼，所述同步單元包括：確定模塊，用于確定待同步至所述緩存區(qū)中的當前分支代碼判斷模塊，用于判斷在所述緩存區(qū)中是否存在以所述當前分支代碼命名的文件夾；同步模塊，用于在所述緩存區(qū)中不存在以所述當前分支代碼命名的文件夾的情況下，在所述緩存區(qū)中創(chuàng)建以當前分支代碼命名的文件夾，并將所述當前分支代碼同步至所述緩存區(qū)中以所述當前分支代碼命名的文件夾下。

為了實現(xiàn)上述目的，根據(jù)本申請的另一方面，提供了一種存儲介質(zhì)，所述存儲介質(zhì)包括存儲的程序，其中，所述程序執(zhí)行上述任意一項所述的集中配置管理系統(tǒng)測試報告的生成方法。

為了實現(xiàn)上述目的，根據(jù)本申請的另一方面，提供了一種處理器，所述處理器用于運行程序，其中，所述程序運行時執(zhí)行上述任意一項所述的集中配置管理系統(tǒng)測試報告的生成方法。

為了實現(xiàn)上述目的，根據(jù)本申請的另一方面，提供了一種終端，包括：一個或多個處理器，存儲器，顯示裝置以及一個或多個程序，其中，所述一個或多個程序被存儲在所述存儲器中，并且被配置為由所述一個或多個處理器執(zhí)行，所述一個或多個程序包括用于執(zhí)行上述任意一項所述的集中配置管理系統(tǒng)測試報告的生成方法。

通過本申請，采用以下步驟：檢測集中配置管理系統(tǒng)的代碼是否已更新；若檢測到集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，多個待測試操作系統(tǒng)由集中配置管理系統(tǒng)配置；獲取多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例；逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果；基于多個測試結(jié)果生成測試報告，解決了相關技術(shù)中測試報告難以從整體上反映測試情況的問題。通過在檢測到集中配置管理系統(tǒng)的代碼已更新時，觸發(fā)對待測試操作系統(tǒng)進行測試，并基于測試得到的多個測試結(jié)果生成測試報告，進而達到了生成的測試報告可以從整體上反映測試情況的效果。

附圖說明

構(gòu)成本申請的一部分的附圖用來提供對本申請的進一步理解，本申請的示意性實施例及其說明用于解釋本申請，并不構(gòu)成對本申請的不當限定。在附圖中：

圖1是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法的流程圖；

圖2是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中緩存區(qū)結(jié)構(gòu)的示意圖；

圖3是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中代碼從緩存區(qū)搬運到工作區(qū)的示意圖；

圖4是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中測試用例結(jié)構(gòu)圖；

圖5是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中測試結(jié)果保存目錄的示意圖；

圖6是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中軟鏈接結(jié)構(gòu)的示意圖；

圖7是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中測試結(jié)果樣式的示意圖；

圖8是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中第一目標數(shù)據(jù)信息的示意圖；

圖9是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中第二目標數(shù)據(jù)信息的示意圖；以及

圖10是根據(jù)本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成裝置的示意圖。

具體實施方式

需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。下面將參考附圖并結(jié)合實施例來詳細說明本申請。

為了使本技術(shù)領域的人員更好地理解本申請方案，下面將結(jié)合本申請實施例中的附圖，對本申請實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分的實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術(shù)人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都應當屬于本申請保護的范圍。

需要說明的是，本申請的說明書和權(quán)利要求書及上述附圖中的術(shù)語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。應該理解這樣使用的數(shù)據(jù)在適當情況下可以互換，以便這里描述的本申請的實施例。此外，術(shù)語“包括”和“具有”以及他們的任何變形，意圖在于覆蓋不排他的包含，例如，包含了一系列步驟或單元的過程、方法、系統(tǒng)、產(chǎn)品或設備不必限于清楚地列出的那些步驟或單元，而是可包括沒有清楚地列出的或?qū)τ谶@些過程、方法、產(chǎn)品或設備固有的其它步驟或單元。

為了便于描述，以下對本申請實施例涉及的部分名詞或術(shù)語進行說明：

vagrant：一個基于ruby的工具，用于創(chuàng)建和部署虛擬化開發(fā)環(huán)境。它使用oracle的開源virtualbox虛擬化系統(tǒng)，使用chef創(chuàng)建自動化虛擬環(huán)境。

beaker：puppetlabs中一款開源的自動化測試工具，用于測試大型復雜的puppet系統(tǒng)。它可以通過本地的虛擬主機或者云平臺來搭建測試環(huán)境，一旦測試環(huán)境運行起來，beaker可以用重復的方式來執(zhí)行測試用例。

erb：embeddedruby是ruby的一項功能，允許開發(fā)者很方便的根據(jù)模板生成任何類型任何數(shù)量的文本。模板本身與ruby代碼合并，通過文本中嵌入的變量來進行替換和控制，使得模板很容易編寫和維護。

git：一個開源的分布式版本控制系統(tǒng)，可以有效、高速的處理從很小到非常大的項目版本管理。

實施例1

根據(jù)本申請的實施例，提供了一種集中配置管理系統(tǒng)測試報告的生成方法。

圖1是根據(jù)本申請實施例的集中配置管理系統(tǒng)測試報告的生成方法的流程圖。如圖1所示，該方法包括以下步驟：

步驟s101，檢測集中配置管理系統(tǒng)的代碼是否已更新。

本申請的實施例中，一旦集中配置管理系統(tǒng)(puppet)中的代碼發(fā)生變化(即檢測到集中配置管理系統(tǒng)的代碼已更新)，檢測到更新后利用beaker來進行自動化測試，，在本申請實施例中的預先在gitlab上配置了一個鉤子(hook)，利用gitlab的鉤子(hook)功能，每次有代碼提交會發(fā)送一個post請求給測試機，觸發(fā)自動化測試。在本步驟中判斷集中配置管理系統(tǒng)的代碼發(fā)生變化，即為檢測集中配置管理系統(tǒng)的代碼是否已更新。

步驟s102，若檢測到集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，多個待測試操作系統(tǒng)由集中配置管理系統(tǒng)配置。

在本申請中的待測試操作系統(tǒng)由集中配置管理系統(tǒng)配置。一旦檢測到集中配置管理系統(tǒng)的代碼已更新，由集中配置管理系統(tǒng)配置的操作系統(tǒng)的相關配置就會發(fā)生變化，因此，需要對其進行測試，因此，若檢測到集中配置管理系統(tǒng)的代碼已更新，則確定需要根據(jù)集中配置管理系統(tǒng)的代碼進行測試的操作系統(tǒng)，將其作為待測試操作系統(tǒng)，這里確定多個待測試操作系統(tǒng)的原因是因為集中配置管理系統(tǒng)可以應用于不同的操作系統(tǒng)。

步驟s103，獲取多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例。

由于每個待測試操作系統(tǒng)中包括多個模塊，在對每個操作系統(tǒng)進行測試時會將具體的模塊進行拆分，針對具體的模塊采用對應的測試用例，因此一次測試完成需要運行多組測試用例。因此，在檢測到集中配置管理系統(tǒng)的代碼已更新后，需要獲取多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例。

可選地，為了避免正在進行的測試代碼被后面提交的測試代碼所覆蓋，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中，在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之前，該方法還包括：獲取更新后的集中配置管理系統(tǒng)的代碼；將集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中；在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之后，該方法還包括：將緩存區(qū)中更新后的代碼移動至工作區(qū)，根據(jù)測試用例和更新后的代碼對對應的模塊進行測試，其中，工作區(qū)是集中配置管理系統(tǒng)的代碼執(zhí)行時的目錄。

例如，在測試機收到來自于gitlab的消息時，在本申請實施例中同步gitlab上的代碼到測試機的緩存區(qū)，在正式開始測試時，將代碼從緩存區(qū)移動到工作區(qū)，根據(jù)測試用例和更新后的代碼對對應的模塊進行測試。

可選地，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中，集中配置管理系統(tǒng)的代碼包括多個分支代碼，將集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中包括：確定待同步至緩存區(qū)中的當前分支代碼；判斷在緩存區(qū)中是否存在以當前分支代碼命名的文件夾；如果在緩存區(qū)中不存在以當前分支代碼命名的文件夾，在緩存區(qū)中創(chuàng)建以當前分支代碼命名的文件夾，并將當前分支代碼同步至緩存區(qū)中以當前分支代碼命名的文件夾下。

例如，在緩存區(qū)里，以代碼分支為名創(chuàng)建文件夾，在文件夾里面存放了此分支的代碼。緩存區(qū)結(jié)構(gòu)的示意圖，如圖2所示。例如有4個分支代碼在緩存區(qū)中，分別為branch_a、branch_b、branch_c和branch_d，代碼的更新分為兩種情況：當前更新的分支代碼還在緩存區(qū)中，這種情況表明此分支的代碼還未來得及測試，又有新的提交，此時新提交的代碼會去覆蓋已經(jīng)存在的代碼。例如branch_a已經(jīng)存在緩存區(qū)，當有程序繼續(xù)向branch_a提交代碼時，此時新的代碼會覆蓋branch_a這個目錄。當前更新的分支代碼在緩存區(qū)不存在，此時會以當前分支為名創(chuàng)建文件夾，并且把當前分支的代碼同步到此文件夾。如果圖2中所示的branch_d之前不存在，假如當前更新的分支為branch_d，則創(chuàng)建branch_d文件夾，然后將代碼同步到此文件夾中。

當在工作區(qū)的執(zhí)行的任務測試完畢之后，將緩存區(qū)中最早緩存的代碼移動到工作區(qū)，執(zhí)行測試任務。如圖3所示，代碼從緩存區(qū)搬運到工作區(qū)，左邊虛線框表示被移動的文件夾在執(zhí)行移動操作后就不再出現(xiàn)在緩存區(qū)。

步驟s104，逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果。

在多個操作系統(tǒng)上需要分別執(zhí)行測試用例，例如10個操作系統(tǒng)，測試用例有100條，10個操作系統(tǒng)每個都需要把這100條測試用例運行一次，因此需要運行100*10＝100次。在進行用例設計時，將測試用例根據(jù)具體的功能來進行分組，例如10條測試用例測試網(wǎng)絡相關功能，4條用例防火墻操作等等。如圖4所示，在執(zhí)行測試用例時，依次在宿主機上開啟測試虛擬機，例如debian7，然后按照模塊(網(wǎng)絡模塊，防火墻模塊)依次再執(zhí)行測試用例，每次執(zhí)行測試用例后會返回當前測試用例的執(zhí)行結(jié)果。

可選地，為了將測試結(jié)果進行有序組織，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中，逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果之前，該方法還包括：生成與每個待測試操作系統(tǒng)中每個模塊對應的目標文件夾，其中，目標文件夾用于存儲對應的模塊的測試結(jié)果；確定每個目標文件夾的存儲路徑。逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果包括：確定當前正在執(zhí)行測試用例的模塊；基于當前正在執(zhí)行測試用例的模塊調(diào)整其測試結(jié)果指向的目標文件夾；將對當前正在執(zhí)行測試用例的模塊的測試結(jié)果逐條寫入指向的目標文件夾下。

在測試過程中，每執(zhí)行一個測試用例時，都會產(chǎn)生一個當前測試用例的測試結(jié)果。為了在后期整理結(jié)果時方便知道某個測試結(jié)果是具體某臺操作系統(tǒng)中執(zhí)行某個模塊中的測試用例產(chǎn)生的。在本申請實施例中在具體用例執(zhí)行時，在本申請實施例中設置一個總的調(diào)度模塊，該調(diào)度模塊負責調(diào)度具體的測試操作系統(tǒng)執(zhí)行具體的測試用例。而具體的執(zhí)行依靠的是執(zhí)行測試用例，同時報告也是這個測試用例產(chǎn)生的。

在本申請中將測試用例與測試結(jié)果進行設置關聯(lián)。具體地，調(diào)度模塊在開始執(zhí)行時，會根據(jù)需要執(zhí)行的操作系統(tǒng)及模塊初始化一個文件夾。例如圖4中需要在debian7，debian8，debian9中分別執(zhí)行網(wǎng)絡模塊，防火墻模塊以及文件權(quán)限模塊。將初始化出來一個如圖5所示的目錄結(jié)構(gòu)。例如，測試結(jié)果保存目錄為reports文件夾，初始化完成之后在reports目錄下將會根據(jù)測試的操作系統(tǒng)類型，初始化出debian7，debian8，debian9三個目錄，然后在debian7，debian8，debian9三個目錄下分別會存在network，filewall以及filepermission三個文件。在調(diào)度模塊開始調(diào)度某個虛擬機開始執(zhí)行用例時，調(diào)度模塊會做執(zhí)行兩件任務，第一，調(diào)度模塊會在此操作系統(tǒng)對應的文件目錄創(chuàng)建一個指向文件夾的軟鏈接，在本申請實施例中將此軟鏈接命名為linkmachine。當現(xiàn)在需要開始在debian7虛擬機執(zhí)行時，將linkmachine指向debian7目錄，此時的效果是，當訪問reports/linkmachine時，實際訪問的是reports/debian7目錄。第二，調(diào)度模塊會在reports/debian7中創(chuàng)建一個指向文件的軟鏈接，將其命名為linkmodule，例如現(xiàn)在測試的是network模塊中的測試用例，則linkmodule指向network文件。此時當訪問reports/linkmachine/linkmodule這個文件，實際上訪問的是reports/debian7/network文件，如圖6所示。

頂層模塊在每次調(diào)度執(zhí)行時，會根據(jù)當前運行的測試系統(tǒng)和模塊更改指針指向，例如執(zhí)行debian8操作系統(tǒng)中的firewall模塊，則會將linkmachine指向debian8文件夾，將linkmodule指向firewall文件。具體執(zhí)行測試的實例只需要將測試結(jié)果逐條寫入到reports/linkmachine/linkmodule文件中。

需要說明的是，為了減小了系統(tǒng)性能的開銷，提升測試處理效率，在本申請實施例中也可以將測試生成的測試結(jié)果直接作為一個變量保存起來。

步驟s105，基于多個測試結(jié)果生成測試報告。

根據(jù)多個測試結(jié)果整理出一份可視化程度高的測試報告。生成的測試報告可以從整體上反映測試情況的效果。

可選地，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法中，基于多個測試結(jié)果生成測試報告包括：對多個測試結(jié)果進行分析，得到第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息，其中，第一目標數(shù)據(jù)信息中至少包括：測試用例的數(shù)量、測試失敗的數(shù)量和測試成功的數(shù)量，第二目標數(shù)據(jù)信息中至少包括：每個待測試操作系統(tǒng)中每個模塊的測試信息和對待測試操作系統(tǒng)中模塊測試失敗的信息；將第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息填充至預設模板中，生成測試報告。

具體地，測試完成之后，測試結(jié)果將會被組織成如圖7的形式，每個模塊中的測試用例執(zhí)行結(jié)果將會保存在對應的模塊文件中，例如，在debian7中執(zhí)行network模塊中的n_case_1的結(jié)果將會被保存在debian7目錄下的network文件中，記錄成n_caseresult_1這一條記錄。結(jié)果統(tǒng)計從測試系統(tǒng)和模塊兩個維度進行統(tǒng)計，掃描某個操作系統(tǒng)例如debian7目錄下所有的文件，然后逐條讀取文件中的執(zhí)行結(jié)果。整體上統(tǒng)計此次執(zhí)行總共的用例數(shù)，執(zhí)行失敗數(shù)和成功數(shù)。并且分模塊來整理成功失敗的用例數(shù)，對于失敗的用例還會將失敗的原因進行統(tǒng)計。

根據(jù)上述匯總的數(shù)據(jù)渲染出一份直觀的測試報告。可以采用靜態(tài)網(wǎng)頁是展示報告的形式，會將靜態(tài)網(wǎng)頁制作成一個報告的模板，在測試完成之后，將數(shù)據(jù)填充在模板中則可渲染出測試報告。

在本申請實施例中的靜態(tài)網(wǎng)頁主要包括兩個頁面，一個是信息總覽頁面，至少包括測試用例的總數(shù)，成功多少，失敗多少。另一個則為各個操作系統(tǒng)下的詳細測試信息，里面至少包括具體模塊的測試信息，失敗用例的信息。如圖8所示，圖8為本申請實施例生成的測試報告的示意圖。

在本申請中的預設模板是利用上述的靜態(tài)網(wǎng)頁，將一些數(shù)據(jù)提取出來，然后更換成rubyerb的語法。可以將上述的操作系統(tǒng)，測試用例執(zhí)行情況制作成如圖9所示的預設模板。圖9中的is_success，passed這些都是erb模板變量。

在每次測試完成之后，利用匯總的測試數(shù)據(jù)，填充到上述的預設模板中，例如is_success＝”失敗”，passed＝120填充到模板中，即可渲染成本申請實施例中的測試報告。通過上述操作，實現(xiàn)了整理自動化測試的結(jié)果，包括執(zhí)行失敗和成功的統(tǒng)計條目，失敗用例對應模塊或者接口的相關信息，用于后續(xù)問題的跟進和調(diào)試。

在本申請實施例中利用beaker-rspec作為核心的測試技術(shù)，在此基礎上以vagrant作為測試的載體來運行測試，解決多個操作系統(tǒng)的測試問題。通過新增或者修改模塊，提交到git之后自動觸發(fā)測試的運行，在測試過程中根據(jù)不同的操作系統(tǒng)來對測試結(jié)果進行歸類。最終進行匯總和分析，渲染成一份可讀性強且包含調(diào)試信息的測試報告，進而達到了生成的測試報告可以從整體上反映測試情況的效果。

綜上所述，本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成方法，通過檢測集中配置管理系統(tǒng)的代碼是否已更新；若檢測到集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，多個待測試操作系統(tǒng)由集中配置管理系統(tǒng)配置；獲取多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例；逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果；基于多個測試結(jié)果生成測試報告，解決了相關技術(shù)中測試報告難以從整體上反映測試情況的問題。通過在檢測到集中配置管理系統(tǒng)的代碼已更新時，觸發(fā)對待測試操作系統(tǒng)進行測試，并基于測試得到的多個測試結(jié)果生成測試報告，進而達到了生成的測試報告可以從整體上反映測試情況的效果。

需要說明的是，在附圖的流程圖示出的步驟可以在諸如一組計算機可執(zhí)行指令的計算機系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟。

實施例2

本申請實施例還提供了一種集中配置管理系統(tǒng)測試報告的生成裝置，需要說明的是，本申請實施例的集中配置管理系統(tǒng)測試報告的生成裝置可以用于執(zhí)行本申請實施例所提供的用于集中配置管理系統(tǒng)測試報告的生成方法。以下對本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成裝置進行介紹。

圖10是根據(jù)本申請實施例的集中配置管理系統(tǒng)測試報告的生成裝置的示意圖。如圖10所示，該裝置包括：檢測單元10、確定單元20、第一獲取單元30、測試單元40和生成單元50。

具體地，檢測單元10，用于檢測集中配置管理系統(tǒng)的代碼是否已更新。

確定單元20，用于若檢測到集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，多個待測試操作系統(tǒng)由集中配置管理系統(tǒng)配置。

第一獲取單元30，用于獲取多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例。

測試單元40，用于逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果。

生成單元50，用于基于多個測試結(jié)果生成測試報告。

本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成裝置，通過檢測單元10檢測集中配置管理系統(tǒng)的代碼是否已更新；確定單元20若檢測到集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，多個待測試操作系統(tǒng)由集中配置管理系統(tǒng)配置；第一獲取單元30獲取多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例；測試單元40逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果；生成單元50基于多個測試結(jié)果生成測試報告，解決了相關技術(shù)中測試報告難以從整體上反映測試情況的問題。通過在檢測到集中配置管理系統(tǒng)的代碼已更新時，觸發(fā)對待測試操作系統(tǒng)進行測試，并基于測試得到的多個測試結(jié)果生成測試報告，進而達到了生成的測試報告可以從整體上反映測試情況的效果。

可選地，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成裝置中，生成單元50包括：分析模塊，用于對多個測試結(jié)果進行分析，得到第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息，其中，第一目標數(shù)據(jù)信息中至少包括：測試用例的數(shù)量、測試失敗的數(shù)量和測試成功的數(shù)量，第二目標數(shù)據(jù)信息中至少包括：每個待測試操作系統(tǒng)中每個模塊的測試信息和對待測試操作系統(tǒng)中模塊測試失敗的信息；填充模塊，用于將第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息填充至預設模板中，生成測試報告。

可選地，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成裝置中，該裝置還包括：第二獲取單元，用于在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之前，獲取更新后的集中配置管理系統(tǒng)的代碼；同步單元，用于將集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中；其中，該裝置還包括：移動單元，用于在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之后，將緩存區(qū)中更新后的代碼移動至工作區(qū)，根據(jù)測試用例和更新后的代碼對對應的模塊進行測試，其中，工作區(qū)是集中配置管理系統(tǒng)的代碼執(zhí)行時的目錄。

可選地，在本申請實施例提供的集中配置管理系統(tǒng)測試報告的生成裝置中，集中配置管理系統(tǒng)的代碼包括多個分支代碼，同步單元包括：確定模塊，用于確定待同步至緩存區(qū)中的當前分支代碼；判斷模塊，用于判斷在緩存區(qū)中是否存在以當前分支代碼命名的文件夾；同步模塊，用于在緩存區(qū)中不存在以當前分支代碼命名的文件夾的情況下，在緩存區(qū)中創(chuàng)建以當前分支代碼命名的文件夾，并將當前分支代碼同步至緩存區(qū)中以當前分支代碼命名的文件夾下。

所述集中配置管理系統(tǒng)測試報告的生成裝置包括處理器和存儲器，上述檢測單元10、確定單元20、第一獲取單元30、測試單元40和生成單元50等均作為程序單元存儲在存儲器中，由處理器執(zhí)行存儲在存儲器中的上述程序單元來實現(xiàn)相應的功能。

處理器中包含內(nèi)核，由內(nèi)核去存儲器中調(diào)取相應的程序單元。內(nèi)核可以設置一個或以上，通過調(diào)整內(nèi)核參數(shù)來生成集中配置管理系統(tǒng)測試報告。

存儲器可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內(nèi)存等形式，如只讀存儲器(rom)或閃存(flashram)，存儲器包括至少一個存儲芯片。

本發(fā)明實施例提供了一種存儲介質(zhì)，其上存儲有程序，該程序被處理器執(zhí)行時實現(xiàn)所述集中配置管理系統(tǒng)測試報告的生成方法。

本發(fā)明實施例提供了一種處理器，所述處理器用于運行程序，其中，所述程序運行時執(zhí)行所述集中配置管理系統(tǒng)測試報告的生成方法。

本發(fā)明實施例提供了一種終端，包括：一個或多個處理器，存儲器，顯示裝置以及一個或多個程序，其中，所述一個或多個程序被存儲在所述存儲器中，并且被配置為由所述一個或多個處理器執(zhí)行，所述一個或多個程序包括用于執(zhí)行所述的集中配置管理系統(tǒng)測試報告的生成方法。

本申請還提供了一種計算機程序產(chǎn)品，當在數(shù)據(jù)處理設備上執(zhí)行時，適于執(zhí)行初始化有如下方法步驟的程序：檢測集中配置管理系統(tǒng)的代碼是否已更新；若檢測到所述集中配置管理系統(tǒng)的代碼已更新，確定多個待測試操作系統(tǒng)，其中，所述多個待測試操作系統(tǒng)由所述集中配置管理系統(tǒng)配置；獲取所述多個待測試系統(tǒng)中的每個待測試操作系統(tǒng)中每個模塊對應的測試用例；逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果；基于所述多個測試結(jié)果生成測試報告。

基于所述多個測試結(jié)果生成測試報告包括：對所述多個測試結(jié)果進行分析，得到第一目標數(shù)據(jù)信息和第二目標數(shù)據(jù)信息，其中，所述第一目標數(shù)據(jù)信息中至少包括：測試用例的數(shù)量、測試失敗的數(shù)量和測試成功的數(shù)量，所述第二目標數(shù)據(jù)信息中至少包括：每個待測試操作系統(tǒng)中每個模塊的測試信息和對待測試操作系統(tǒng)中模塊測試失敗的信息；將所述第一目標數(shù)據(jù)信息和所述第二目標數(shù)據(jù)信息填充至預設模板中，生成所述測試報告。

逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果之前，所述方法還包括：生成與每個待測試操作系統(tǒng)中每個模塊對應的目標文件夾，其中，所述目標文件夾用于存儲對應的模塊的測試結(jié)果；確定每個目標文件夾的存儲路徑。

逐次采用每個測試用例對對應的模塊進行測試，得到多個測試結(jié)果包括：確定當前正在執(zhí)行測試用例的模塊；基于所述當前正在執(zhí)行測試用例的模塊調(diào)整其測試結(jié)果指向的目標文件夾；將對當前正在執(zhí)行測試用例的模塊的測試結(jié)果逐條寫入指向的所述目標文件夾下。

在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之前，所述方法還包括：獲取更新后的所述集中配置管理系統(tǒng)的代碼；將所述集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中；在獲取每個待測試操作系統(tǒng)中每個模塊對應的測試用例之后，所述方法還包括：將所述緩存區(qū)中更新后的代碼移動至工作區(qū)，根據(jù)所述測試用例和所述更新后的代碼對對應的模塊進行測試，其中，所述工作區(qū)是所述集中配置管理系統(tǒng)的代碼執(zhí)行時的目錄。

所述集中配置管理系統(tǒng)的代碼包括多個分支代碼，將所述集中配置管理系統(tǒng)的代碼逐次同步至緩存區(qū)中包括：確定待同步至所述緩存區(qū)中的當前分支代碼；判斷在所述緩存區(qū)中是否存在以所述當前分支代碼命名的文件夾；如果在所述緩存區(qū)中不存在以所述當前分支代碼命名的文件夾，在所述緩存區(qū)中創(chuàng)建以當前分支代碼命名的文件夾，并將所述當前分支代碼同步至所述緩存區(qū)中以所述當前分支代碼命名的文件夾下。本領域內(nèi)的技術(shù)人員應明白，本申請的實施例可提供為方法、系統(tǒng)、或計算機程序產(chǎn)品。因此，本申請可采用完全硬件實施例、完全軟件實施例、或結(jié)合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、cd-rom、光學存儲器等)上實施的計算機程序產(chǎn)品的形式。

本申請是參照根據(jù)本申請實施例的方法、設備(系統(tǒng))、和計算機程序產(chǎn)品的流程圖和/或方框圖來描述的。應理解可由計算機程序指令實現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合。可提供這些計算機程序指令到通用計算機、專用計算機、嵌入式處理機或其他可編程數(shù)據(jù)處理設備的處理器以產(chǎn)生一個操作系統(tǒng)，使得通過計算機或其他可編程數(shù)據(jù)處理設備的處理器執(zhí)行的指令產(chǎn)生用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的裝置。

這些計算機程序指令也可存儲在能引導計算機或其他可編程數(shù)據(jù)處理設備以特定方式工作的計算機可讀存儲器中，使得存儲在該計算機可讀存儲器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能。

這些計算機程序指令也可裝載到計算機或其他可編程數(shù)據(jù)處理設備上，使得在計算機或其他可編程設備上執(zhí)行一系列操作步驟以產(chǎn)生計算機實現(xiàn)的處理，從而在計算機或其他可編程設備上執(zhí)行的指令提供用于實現(xiàn)在流程圖一個流程或多個流程和/或方框圖一個方框或多個方框中指定的功能的步驟。

在一個典型的配置中，計算設備包括一個或多個處理器(cpu)、輸入/輸出接口、網(wǎng)絡接口和內(nèi)存。

存儲器可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內(nèi)存等形式，如只讀存儲器(rom)或閃存(flashram)。存儲器是計算機可讀介質(zhì)的示例。

計算機可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術(shù)來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。計算機的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存(pram)、靜態(tài)隨機存取存儲器(sram)、動態(tài)隨機存取存儲器(dram)、其他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器(cd-rom)、數(shù)字多功能光盤(dvd)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質(zhì)，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質(zhì)不包括暫存電腦可讀媒體(transitorymedia)，如調(diào)制的數(shù)據(jù)信號和載波。

還需要說明的是，術(shù)語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括要素的過程、方法、商品或者設備中還存在另外的相同要素。

本領域技術(shù)人員應明白，本申請的實施例可提供為方法、系統(tǒng)或計算機程序產(chǎn)品。因此，本申請可采用完全硬件實施例、完全軟件實施例或結(jié)合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、cd-rom、光學存儲器等)上實施的計算機程序產(chǎn)品的形式。

以上僅為本申請的實施例而已，并不用于限制本申請。對于本領域技術(shù)人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內(nèi)所作的任何修改、等同替換、改進等，均應包含在本申請的權(quán)利要求范圍之內(nèi)。