本發(fā)明涉及測試技術，尤指一種實現持續(xù)集成測試的方法及裝置。

背景技術：

在軟件開發(fā)過程中，軟件的更新、編譯、打包、分發(fā)、啟動及自動化測試等都需要進行人為處理，需要占用很多人力和時間資源。持續(xù)集成技術將上述軟件開發(fā)過程分解為多個步驟，利用持續(xù)集成工具將各個步驟集成，完成軟件開發(fā)的自動化構建，自動化構建完成后對軟件進行測試用例的測試，繼而發(fā)現集成的軟件中存在的錯誤，降低了軟件開發(fā)過程通過人為處理在人力和時間資源上的消耗。

現有的持續(xù)集成技術主要用于：實現自動對修改后的程序進行編譯，并對編譯成功的程序進行測試；解決測試環(huán)境或者代理機器利用率不高的問題。然而，對于大規(guī)模的軟件開發(fā)項目、由于功能復雜，涉及測試多，如果采用持續(xù)集成直接進行自動化構建和測試用例測試，如果軟件存在基本功能的問題，則在所有測試環(huán)境中進行集成測試用例的測試都會由于基本功能存在問題而出現異常，自動化構建完成后軟件測試用例的測試無法進行，后續(xù)的所有測試用例的相關測試腳本執(zhí)行任務也將無法進行，持續(xù)集成的測試效率大大降低。

技術實現要素：

為了解決上述技術問題，本發(fā)明提供一種實現持續(xù)集成測試的方法及裝置，能夠提高持續(xù)集成測試的工作效率。

為了達到本發(fā)明目的，本發(fā)明提供了一種實現持續(xù)集成測試的方法，包括：

對需要進行集成測試的軟件的基本功能進行冒煙測試；

冒煙測試成功后，對軟件進行集成測試。

進一步地，進行冒煙測試具體包括：

更新所述需要集成測試的軟件并進行代碼編譯；

打包代碼編譯后的所述需要集成測試的軟件；

根據冒煙測試需求將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中；

啟動并運行被分配到冒煙測試的測試環(huán)境中各打包的軟件的基本功能，以完成冒煙測試。

進一步地，將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境之前，該方法還包括：

根據冒煙測試需求確定是否將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境；

需要將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境時，調用分發(fā)任務將所述打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中。

進一步地，持續(xù)集成測試為基于Jenkins持續(xù)集成工具的測試。

另一方面，本申請還提供一種實現持續(xù)集成測試的裝置，包括：冒煙測試單元和集成測試單元；其中，

冒煙測試單元，用于對需要進行集成測試的軟件的基本功能進行冒煙測試；

集成測試單元，用于冒煙測試成功后，對軟件進行集成測試。

進一步地，冒煙測試單元具體用于，

更新所述需要集成測試的軟件并進行代碼編譯；

打包代碼編譯后的所述需要集成測試的軟件；

根據冒煙測試需求將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中；

啟動并運行被分配到冒煙測試的測試環(huán)境中各打包的軟件的基本功能，以完成冒煙測試。

進一步地，該裝置還包括分發(fā)單元，用于將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境之前，

根據冒煙測試需求確定是否將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境；

需要將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境時，調用分發(fā)任務將所述打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中。

進一步地，持續(xù)集成測試為基于Jenkins持續(xù)集成工具的測試。

與現有技術相比，本申請技術方案包括：對需要進行集成測試的軟件的基本功能進行冒煙測試；冒煙測試成功后，對軟件進行集成測試。本發(fā)明方法通過需要進行集成測試的軟件的基本功能進行冒煙測試，避免了由于基本功能異常影響集成測試的測試用例測試和測試用例相關測試腳本執(zhí)行任務的執(zhí)行，提高了持續(xù)集成測試的工作效率。

附圖說明

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

圖1為本發(fā)明實現持續(xù)集成測試的方法的流程圖；

圖2為本發(fā)明實現持續(xù)集成測試的裝置的結構程圖；

圖3為本發(fā)明第一實施例的方法流程圖。

具體實施方式

為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚明白，下文中將結合附圖對本發(fā)明的實施例進行詳細說明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互任意組合。

圖1為本發(fā)明實現持續(xù)集成測試的方法的流程圖，如圖1所示，包括：

步驟100、對需要進行集成測試的軟件的基本功能進行冒煙測試；

進行冒煙測試具體包括：

更新所述需要集成測試的軟件并進行代碼編譯；

打包代碼編譯后的所述需要集成測試的軟件；

根據冒煙測試需求將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中；

啟動并運行被分配到冒煙測試的測試環(huán)境中各打包的軟件的基本功能，基本功能均正常時，冒煙測試成功；否則，冒煙測試失敗。

需要說明的是，對需要集成測試的軟件進行更新、代碼編譯、打包、屬于本領域技術人員的慣用技術手段；冒煙測試需求為本領域技術人員進行冒煙測試分析整理的內容，屬于本領域技術人員的慣用技術手段；冒煙測試過程需要針對軟件的基本功能進行腳本編輯，針對軟件的基本功能進行腳本編輯屬于本領域技術人員的慣用技術手段。

另外，如果冒煙測試失敗，則根據冒煙測試結果，技術人員對軟件進行錯誤修正，完成后按照冒煙測試步驟進行新一輪的冒煙測試。

將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境之前，本發(fā)明方法還包括：

冒煙測試需求確定是否將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境；

需要將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境時，調用分發(fā)任務將所述打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中。

需要說明的是，如果只需要將打包完成的軟件分配至一個冒煙測試的測試環(huán)境時，不需要調用分發(fā)任務進行分配，直接配置到冒煙測試環(huán)境即可。

步驟101、冒煙測試成功后，對軟件進行集成測試。

需要說明的是，軟件的集成測試為本領域技術人員的慣用技術手段，在此不再贅述。

本發(fā)明方法，持續(xù)集成測試基于Jenkins持續(xù)集成工具實現。這里，Jenkins是一個開源軟件項目，旨在提供一個開放易用的軟件平臺，使軟件的持續(xù)集成變成可能。通過Jenkins，可設定指定時間或代碼有更新時觸發(fā)任務，并且 可將持續(xù)集成測試中分解出的各個子任務有效地組織起來，使得持續(xù)集成測試的自動化測試成為可能，大大提高了自動化測試執(zhí)行效率。

本發(fā)明方法通過需要進行持續(xù)集成測試的軟件的基本功能進行冒煙測試，避免了由于基本功能異常影響集成測試的測試用例測試和測試用例相關測試腳本執(zhí)行任務的執(zhí)行，提高了持續(xù)集成測試的工作效率。

圖2為本發(fā)明實現持續(xù)集成測試的裝置的結構程圖，如圖2所示，包括：冒煙測試單元和集成測試單元；其中，

冒煙測試單元，用于對需要進行集成測試的軟件的基本功能進行冒煙測試；

集成測試單元，用于冒煙測試成功后，對軟件進行集成測試。

冒煙測試單元具體用于，

更新所述需要集成測試的軟件并進行代碼編譯；

打包代碼編譯后的所述需要集成測試的軟件；

根據冒煙測試需求將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中；

啟動并運行被分配到冒煙測試的測試環(huán)境中各打包的軟件的基本功能，以完成冒煙測試。

本發(fā)明裝置還包括分發(fā)單元，用于將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境之前，

根據冒煙測試需求確定是否將所述打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境；

需要將打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境時，調用分發(fā)任務將所述打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中。

持續(xù)集成測試為基于Jenkins持續(xù)集成工具的持續(xù)集成測試。

以下通過具體實施例對本發(fā)明方法進行清楚詳細的說明，實施例僅用于陳述本發(fā)明，并不用于限制本發(fā)明方法的保護范圍。

實施例1

本實施例的持續(xù)集成測試是基于Jenkins持續(xù)集成工具進行的測試，圖3為本發(fā)明第一實施例的方法流程圖，如圖3所示，包括：

步驟300、從代碼svn服務器檢出需要集成測試的軟件的代碼至本地編譯環(huán)境；這里，SVN是Subversion的簡稱，是一個開放源代碼的版本控制系統(tǒng)，相較于融合通信(RCS)、CVS(CVS是一個C/S系統(tǒng)，是一個常用的代碼版本控制軟件。主要在開源軟件管理中使用。)，它采用了分支管理系統(tǒng)，它的設計目標就是取代CVS?；ヂ摼W上很多版本控制服務已從CVS遷移到Subversion。

需要說明的是，步驟300根據Jenkins持續(xù)集成工具的設置，在需要持續(xù)集成測試的軟件出現代碼更新被提交至代碼svn服務器或者達到指定執(zhí)行持續(xù)集成測試的預設時間時觸發(fā)執(zhí)行。

步驟301、將檢出到本地編譯環(huán)境的代碼進行代碼編譯；

本步驟中，如果代碼編譯出現錯誤，將錯誤通過持續(xù)集成通告反饋錯誤信息；待根據代碼編譯錯誤解決并更新至代碼svn服務器后，再次執(zhí)行步驟300，該部分處理過程為本領域技術人員的慣用技術手段。如果代碼編譯無誤，則記錄該軟件的版本信息；

步驟302、打包代碼編譯后的需要集成測試的軟件；打包后的軟件可以方便地分配至測試環(huán)境使用；這里，需要記錄打包后的軟件所在地址和路徑以進行后續(xù)將打包后軟件分配至相應的冒煙測試的測試環(huán)境中。

步驟303、調用自動化測試工具模塊，通過Jenkins持續(xù)集成工具將冒煙測試模式傳遞給自動化測試工具；這里，自動化測試工具首先判斷當前進行的是冒煙測試，基于此讀取冒煙測試的測試環(huán)境的配置文件，獲取所需測試環(huán)境；

步驟304、根據冒煙測試需求將打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中；

本步驟具體包括：

根據冒煙測試需求如果只需要一個測試環(huán)境，則將在代碼編譯環(huán)境下完成打包后，把代碼編譯環(huán)境配置為冒煙測試的測試環(huán)境，將打包完成的軟件 直接分配給代碼編譯的環(huán)境即可；直接在編譯環(huán)境啟動軟件，一定程度上也可以提高測試效率；

根據冒煙測試需求如果確定需要將打包完成的軟件分配至兩個或兩個以上冒煙測試的測試環(huán)境時，調用分發(fā)任務將所述打包完成的軟件分配至相應的冒煙測試的測試環(huán)境中。

步驟305、自動化測試工具啟動并執(zhí)行測試環(huán)境中的打包完成的軟件；這里，如果冒煙測試中基本功能均正常則冒煙測試成功；否則，冒煙測試失敗。

需要說明的是，冒煙測試失敗時，通過持續(xù)集成系統(tǒng)通告技術人員進行基本功能異常的問題，解決后，更新代碼svn服務器中軟件的代碼，按照冒煙測試的進程從步驟300從新開始冒煙測試。

步驟306、冒煙測試成功后，對軟件進行集成測試；

具體的，調用自動化測試工具，通過Jenkins持續(xù)集成工具將集成測試模式傳遞給自動化測試工具，自動化測試工具讀取集成測試的測試環(huán)境配置文件，獲取所需測試環(huán)境信息；

自動化測試工具將打包軟件分發(fā)至獲取的集成測試環(huán)境；這里，獲取的集成測試環(huán)境為本領域技術人員的慣用技術手段；

自動化測試工具啟動集成測試環(huán)境，在測試環(huán)境中運行軟件，完成軟件集成測試用例測試和測試用例相關測試腳本執(zhí)行任務的執(zhí)行。

本實施例由于通過冒煙測試對軟件的基本功能進行了測試，避免了軟件集成測試過程中的由于基本功能異常導致的環(huán)境破壞，集成測試能夠完成測試用例相關測試腳步的執(zhí)行，達到了集成測試的目的，提高了持續(xù)集成測試的工作效率。

雖然本發(fā)明所揭露的實施方式如上，但所述的內容僅為便于理解本發(fā)明而采用的實施方式，并非用以限定本發(fā)明。任何本發(fā)明所屬領域內的技術人員，在不脫離本發(fā)明所揭露的精神和范圍的前提下，可以在實施的形式及細節(jié)上進行任何的修改與變化，但本發(fā)明的專利保護范圍，仍須以所附的權利要求書所界定的范圍為準。