本發(fā)明涉及計算機領(lǐng)域，具體而言，涉及一種軟件開發(fā)項目中修改內(nèi)容的測試方法及裝置。

背景技術(shù)：

目前，在典型的軟件開發(fā)項目中，在軟件開發(fā)項目沒有交付測試前的一段漫長的開發(fā)時間內(nèi)，測試人員都無法對研發(fā)成果進行測試。在此期間，測試人員既無法及時掌握軟件開發(fā)項目的每一次程序改動是否存在缺陷，也無法在眾多改動提交當中準確定位具體哪一次提交的改動引發(fā)上述缺陷，而只能在軟件開發(fā)項目的研發(fā)周期最后階段發(fā)現(xiàn)重大問題時，才開始盲目摸索原因。此種測試方式存在如下重大問題：一旦發(fā)現(xiàn)軟件開發(fā)項目存在的缺陷是由提交時期較早的改動所引起的并且這個改動又被其他功能模塊所依賴從而導致難以修改的話，則極容易導致軟件開發(fā)項目不能按時交付而最終研發(fā)失敗。

由此可見，相關(guān)技術(shù)中所提供的只能在軟件開發(fā)項目的研發(fā)周期最后階段對研發(fā)過程中提交的改動進行統(tǒng)一測試的方案，一旦在交付測試時發(fā)現(xiàn)重大缺陷則易導致軟件開發(fā)項目無法按時提交或者研發(fā)過程失敗。

針對上述的問題，目前尚未提出有效的解決方案。

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

本發(fā)明實施例提供了一種軟件開發(fā)項目中修改內(nèi)容的測試方法及裝置，以至少解決相關(guān)技術(shù)中只能在軟件開發(fā)項目的研發(fā)周期最后階段進行統(tǒng)一測試，一旦在交付測試時發(fā)現(xiàn)重大缺陷則易導致軟件開發(fā)項目無法按時提交或者研發(fā)過程失敗的技術(shù)問題。

根據(jù)本發(fā)明實施例的一個方面，提供了一種軟件開發(fā)項目中修改內(nèi)容的測試方法，包括：

實時獲取軟件開發(fā)項目的待測試修改內(nèi)容；對待測試修改內(nèi)容進行打包處理，得到待測試包體；向一個或多個測試服務端提供測試接口，其中，測試接口用于一個或多個測試服務端獲取待測試包體。

可選地，在對待測試修改內(nèi)容進行打包處理之前，還包括：判斷預設(shè)隊列中是否存在尚未執(zhí)行或正在執(zhí)行打包處理的修改內(nèi)容；如果存在，則等到預設(shè)隊列中當前存在的全部修改內(nèi)容均打包完畢后，再確定對待測試修改內(nèi)容進行打包處理。

可選地，在對待測試修改內(nèi)容進行打包處理之前，還包括：判斷待測試修改內(nèi)容對應的版本號信息是否與前一個已經(jīng)成功打包的修改內(nèi)容對應的版本號信息一致；如果不一致，則確定對待測試修改內(nèi)容進行打包處理。

可選地，對待測試修改內(nèi)容進行打包處理，得到待測試包體包括：對待測試修改內(nèi)容進行鎖定；獲取與待測試修改內(nèi)容對應的打包腳本；采用打包腳本對待測試修改內(nèi)容進行打包處理，得到待測試包體；對待測試修改內(nèi)容進行解鎖，并對打包處理過程中產(chǎn)生的中間文件進行清理。

可選地，在向一個或多個測試服務端提供測試接口之后，還包括：接收一個或多個測試服務端反饋的與待測試修改內(nèi)容對應的測試結(jié)果；當測試結(jié)果表明待測試修改內(nèi)容通過測試時，對一個或多個測試服務端上與待測試修改內(nèi)容對應的配置內(nèi)容進行更新；當測試結(jié)果表明待測試修改內(nèi)容未通過測試時，則發(fā)出異常提示信息。

根據(jù)本發(fā)明實施例的另一方面，還提供了另一種軟件開發(fā)項目中修改內(nèi)容的測試方法，包括：

經(jīng)由打包服務端提供的測試接口從打包服務端獲取待測試包體，其中，待測試包體是由打包服務端在實時獲取軟件開發(fā)項目的待測試修改內(nèi)容并對待測試修改內(nèi)容進行打包處理后得到的；對待測試包體進行測試。

可選地，經(jīng)由測試接口從打包服務端獲取待測試包體包括：經(jīng)由測試接口從打包服務端獲取待測試包體對應的版本號信息；采用版本號信息向打包服務端請求待測試包體的下載地址；根據(jù)下載地址從打包服務端獲取待測試包體。

可選地，在經(jīng)由測試接口從打包服務端獲取待測試包體之前，還包括：對本地當前存在的包體進行備份，得到備份包體，其中，備份包體用于在采用待測試包體對本地對應的已存在包體進行更新過程中發(fā)生異常時，通過備份包體對已存在包體進行恢復。

可選地，對待測試包體進行測試包括：獲取與待測試包體對應的測試用例和測試腳本；采用測試用例和測試腳本對待測試包體進行測試。

可選地，在對待測試包體進行測試之后，還包括：將與待測試包體對應的測試結(jié)果反饋至打包服務端。

根據(jù)本發(fā)明實施例的又一方面，還提供了一種軟件開發(fā)項目中修改內(nèi)容的測試裝置，包括：

獲取模塊，用于實時獲取軟件開發(fā)項目的待測試修改內(nèi)容；處理模塊，用于對待測試修改內(nèi)容進行打包處理，得到待測試包體，并向一個或多個測試服務端提供測試接口，其中，測試接口用于一個或多個測試服務端獲取待測試包體。

可選地，上述裝置還包括：第一判斷模塊，用于判斷預設(shè)隊列中是否存在尚未執(zhí)行或正在執(zhí)行打包處理的修改內(nèi)容；第一確定模塊，用于在第一判斷模塊輸出為是時，則等到預設(shè)隊列中當前存在的全部修改內(nèi)容均打包完畢后，再確定對待測試修改內(nèi)容進行打包處理。

可選地，上述裝置還包括：第二判斷模塊，用于判斷待測試修改內(nèi)容對應的版本號信息是否與前一個已經(jīng)成功打包的修改內(nèi)容對應的版本號信息一致；第二確定模塊，用于在第二判斷模塊輸出為否時，確定對待測試修改內(nèi)容進行打包處理。

可選地，處理模塊包括：鎖定單元，用于對待測試修改內(nèi)容進行鎖定；獲取單元，用于獲取與待測試修改內(nèi)容對應的打包腳本；第一處理單元，用于采用打包腳本對待測試修改內(nèi)容進行打包處理，得到待測試包體；第二處理單元，用于對待測試修改內(nèi)容進行解鎖，并對打包處理過程中產(chǎn)生的中間文件進行清理。

可選地，上述裝置還包括：接收模塊，用于接收一個或多個測試服務端反饋的與待測試修改內(nèi)容對應的測試結(jié)果；更新模塊，用于當測試結(jié)果表明待測試修改內(nèi)容通過測試時，對一個或多個測試服務端上與待測試修改內(nèi)容對應的配置內(nèi)容進行更新；提示模塊，用于當測試結(jié)果表明待測試修改內(nèi)容未通過測試時，則發(fā)出異常提示信息。

根據(jù)本發(fā)明實施例的再一方面，還提供了另一種軟件開發(fā)項目中修改內(nèi)容的測試裝置，包括：

獲取模塊，用于經(jīng)由打包服務端提供的測試接口從打包服務端獲取待測試包體，其中，待測試包體是由打包服務端在實時獲取軟件開發(fā)項目的待測試修改內(nèi)容并對待測試修改內(nèi)容進行打包處理后得到的；測試模塊，用于對待測試包體進行測試。

可選地，獲取模塊包括：第一獲取單元，用于經(jīng)由測試接口從打包服務端獲取待測試包體對應的版本號信息；請求單元，用于采用版本號信息向打包服務端請求待測試包體的下載地址；第二獲取單元，用于根據(jù)下載地址從打包服務端獲取待測試包體。

可選地，上述裝置還包括：備份模塊，用于對本地當前存在的包體進行備份，得到備份包體，其中，備份包體用于在采用待測試包體對本地對應的已存在包體進行更新過程中發(fā)生異常時，通過備份包體對已存在包體進行恢復。

可選地，測試模塊包括：第三獲取單元，用于獲取與待測試包體對應的測試用例和測試腳本；測試單元，用于采用測試用例和測試腳本對待測試包體進行測試。

可選地，上述裝置還包括：反饋模塊，用于將與待測試包體對應的測試結(jié)果反饋至打包服務端。

在本發(fā)明實施例中，采用實時獲取軟件開發(fā)項目的待測試修改內(nèi)容；對待測試修改內(nèi)容進行打包處理，得到待測試包體，以及向一個或多個測試服務端提供測試接口的方式，在實時獲取到的待測試修改內(nèi)容對自動化打包處理的同時，提供多種擴展測試功能的接入，使得軟件開發(fā)項目能夠持續(xù)集成并獲得實時缺陷反饋，從而實現(xiàn)了有效地降低軟件開發(fā)項目的失敗風險，節(jié)約測試成本的技術(shù)效果，進而解決了相關(guān)技術(shù)中只能在軟件開發(fā)項目的研發(fā)周期最后階段進行統(tǒng)一測試，一旦在交付測試時發(fā)現(xiàn)重大缺陷則易導致軟件開發(fā)項目無法按時提交或者研發(fā)過程失敗的技術(shù)問題。

附圖說明

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

圖1是根據(jù)本發(fā)明實施例的軟件開發(fā)項目中修改內(nèi)容的測試方法的流程圖；

圖2是根據(jù)本發(fā)明實施例的另一種軟件開發(fā)項目中修改內(nèi)容的測試方法的流程圖；

圖3是根據(jù)本發(fā)明實施例的一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖；

圖4是根據(jù)本發(fā)明優(yōu)選實施例的一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖；

圖5是根據(jù)本發(fā)明實施例的另一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖；

圖6是根據(jù)本發(fā)明優(yōu)選實施例的另一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖。

具體實施方式

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

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

根據(jù)本發(fā)明實施例，提供了一種軟件開發(fā)項目中修改內(nèi)容的測試方法的實施例，需要說明的是，在附圖的流程圖示出的步驟可以在諸如一組計算機可執(zhí)行指令的計算機系統(tǒng)中執(zhí)行，并且，雖然在流程圖中示出了邏輯順序，但是在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟。

圖1是根據(jù)本發(fā)明實施例的軟件開發(fā)項目中修改內(nèi)容的測試方法的流程圖，如圖1所示，該方法應用于打包服務端，該方法包括如下步驟：

步驟S102，實時獲取軟件開發(fā)項目的待測試修改內(nèi)容；

步驟S104，對待測試修改內(nèi)容進行打包處理，得到待測試包體；

步驟S106，向一個或多個測試服務端提供測試接口，其中，測試接口用于一個或多個測試服務端獲取待測試包體。

通過上述步驟，采用實時獲取軟件開發(fā)項目的待測試修改內(nèi)容；對待測試修改內(nèi)容進行打包處理，得到待測試包體，以及向一個或多個測試服務端提供測試接口的方式，在實時獲取到的待測試修改內(nèi)容對自動化打包處理的同時，提供多種擴展測試功能的接入，使得軟件開發(fā)項目能夠持續(xù)集成并獲得實時缺陷反饋，從而實現(xiàn)了有效地降低軟件開發(fā)項目的失敗風險，節(jié)約測試成本的技術(shù)效果，進而解決了相關(guān)技術(shù)中只能在軟件開發(fā)項目的研發(fā)周期最后階段進行統(tǒng)一測試，一旦在交付測試時發(fā)現(xiàn)重大缺陷則易導致軟件開發(fā)項目無法按時提交或者研發(fā)過程失敗的技術(shù)問題。

可選地，在步驟S104，對待測試修改內(nèi)容進行打包處理之前，還可以包括以下執(zhí)行步驟：

步驟S108，判斷預設(shè)隊列中是否存在尚未執(zhí)行或正在執(zhí)行打包處理的修改內(nèi)容；

步驟S110，如果存在，則等到預設(shè)隊列中當前存在的全部修改內(nèi)容均打包完畢后，再確定對待測試修改內(nèi)容進行打包處理。

在構(gòu)建頁面上發(fā)起構(gòu)建的任務都會加入至等待隊列中，一旦發(fā)現(xiàn)當前存在構(gòu)建任務正在執(zhí)行，那么新發(fā)起的構(gòu)建任務則進入等待狀態(tài)，直到前一個構(gòu)建任務執(zhí)行完畢，才會開始執(zhí)行下一個構(gòu)建任務。通過構(gòu)建等待隊列的模式，可以有效地減輕打包機服務端的負載，防止打包機服務端因打包服務占用大量資源而請求無法響應的問題。通過隊列還可以防止多個打包進程同時訪問同一個項目的代碼資源導致資源混亂、文件占用等問題。

可選地，在步驟S104，對待測試修改內(nèi)容進行打包處理之前，還可以包括以下執(zhí)行步驟：

步驟S112，判斷待測試修改內(nèi)容對應的版本號信息是否與前一個已經(jīng)成功打包的修改內(nèi)容對應的版本號信息一致；

步驟S114，如果不一致，則確定對待測試修改內(nèi)容進行打包處理。

進入構(gòu)建的任務首先需要檢測項目代碼的版本，即，通過將最新獲取到的代碼版本與上一個打包成功的代碼版本進行比對，如果發(fā)現(xiàn)版本變化，則執(zhí)行構(gòu)建操作，如果未發(fā)現(xiàn)版本變化，則不執(zhí)行構(gòu)建操作，由此可以防止同一份項目代碼重復打包浪費資源，還可以防止相同版本項目代碼出現(xiàn)不同MD5值打包輸出的問題。

可選地，在步驟S104中，對待測試修改內(nèi)容進行打包處理，得到待測試包體可以包括以下執(zhí)行步驟：

步驟S1041，對待測試修改內(nèi)容進行鎖定；

步驟S1042，獲取與待測試修改內(nèi)容對應的打包腳本；

步驟S1043，采用打包腳本對待測試修改內(nèi)容進行打包處理，得到待測試包體；

步驟S1044，對待測試修改內(nèi)容進行解鎖，并對打包處理過程中產(chǎn)生的中間文件進行清理。

在優(yōu)選實施例中，可以基于版本控制系統(tǒng)(例如：SVN)提供專用的版本控制接口，其中，該版本控制接口可以對項目代碼執(zhí)行檢出指定版本、更新、獲取提交日志、獲取最新版本號等基本操作，其中，檢出是指在建立版本控制基線之后，獲取控制項當前版本的拷貝(副本)到個人工作區(qū)進行變更。由此測試人員能夠獲取清晰的版本信息和提交記錄，為出現(xiàn)的程序缺陷得到一個準確的定位，提高了開發(fā)人員修復程序缺陷的效率。

在打包服務端中可以包含但不限于：客戶端打包模塊、模板打包模塊、資源打包模塊、更新包打包模塊和安裝包打包模塊。各個模塊輸入指定的源代碼文件，通過對應的打包模塊進行編譯打包并輸出打包產(chǎn)物。打包模塊具有可配置和可拓展的特性。在持續(xù)集成構(gòu)建系統(tǒng)中，每個需要構(gòu)建的項目會被配置為一個構(gòu)建項，亦稱為“打包項”，其可以通過配置打包腳本(其為構(gòu)建項目中的重要組成部分，腳本主要會對源文件進行編譯、壓縮、上傳以及一些特殊處理，每一個打包項都會對應一個打包腳本，在持續(xù)集成構(gòu)建系統(tǒng)執(zhí)行構(gòu)建的過程中，會通過上述配置定位到對應的打包腳本，并執(zhí)行打包腳本)靈活地對打包模塊進行拓展，增加特殊處理操作以滿足每個不同項目的不同打包需求。另外，可拓展性使得持續(xù)集成構(gòu)建系統(tǒng)能夠滿足多種項目類型的構(gòu)建需求，提高了項目新增構(gòu)建的便捷性。最終，通過將最新修改內(nèi)容的版本號和代碼詳情附加到每個打包的包體中，并對外提供可擴展接口，以便測試人員實現(xiàn)自動化測試需求。

為了防止項目代碼在構(gòu)建過程中被其他構(gòu)建項目占用而造成打包異常，需要對打包中的項目代碼進行鎖定，防止其他構(gòu)建過程或應用進程占用文件。項目構(gòu)建結(jié)束后，可以對項目代碼進行解鎖。由于構(gòu)建過程中會產(chǎn)生體積較大的臨時文件或編譯中間產(chǎn)物，項目構(gòu)建結(jié)束后將會對臨時文件和編譯中間文件進行清理，為打包服務端節(jié)省出大量的存儲空間。

可選地，在步驟S106，向一個或多個測試服務端提供測試接口之后，還可以包括以下執(zhí)行步驟：

步驟S116，接收一個或多個測試服務端反饋的與待測試修改內(nèi)容對應的測試結(jié)果；

步驟S118，當測試結(jié)果表明待測試修改內(nèi)容通過測試時，對一個或多個測試服務端上與待測試修改內(nèi)容對應的配置內(nèi)容進行更新；

步驟S120，當測試結(jié)果表明待測試修改內(nèi)容未通過測試時，則發(fā)出異常提示信息。

打包服務端可以接收QA服務端(相當于上述測試服務端)返回的自動化測試結(jié)果，如果測試未通過，則需要向相關(guān)程序人員發(fā)送失敗提醒消息；而當成功構(gòu)建一個打包版本并經(jīng)自動化測試驗證通過后，該打包版本就可以提供給測試人員進行進一步的人工測試使用?？紤]到自動化測試的結(jié)果未必完全正確，因此，還需要測試人員采用人工方式做進一步地確認；再者，并非軟件開發(fā)項目所要實現(xiàn)的全部功能都能夠通過自動化測試覆蓋到，因此，對于自動化測試無法覆蓋到的部分需要人工測試來完成。此外，打包服務端可以根據(jù)輸出的最新打包版本內(nèi)容自動更新QA服務端上的配置文件，測試人員只需要重新登錄待測試軟件，待測軟件即可通過對比MD5碼和文件增量更新的下載形式，從服務端獲得變化的內(nèi)容，并將本地的上一個版本的待測軟件更新成為最新版本的待測試軟件。

例如:原來的版本號是1，最新打包的版本號是2，當版本2通過了自動化測試之后，便可連接測試服務端，將其配置文件數(shù)據(jù)更改為版本2，那么測試人員重新登錄測試軟件，即可獲取服務端配置文件中測試軟件更新到版本2的內(nèi)容，隨后開始測試。

在獲取到異常提示信息時，可以通過訪問打包機服務端提供的接口獲得當前各類打包模塊下各個最新包體對應的打包詳情，其可以包括但不限于以下至少之一：包體內(nèi)所有文件的MD5碼，包體對應SVN版本號、提交人員信息、美術(shù)資源詳情、代碼詳情和打包日志，其中，打包詳情用于在未通過自動化測試時，通過打包詳情來定位異常問題。

此外，為了確保打包服務端與一個或多個測試服務端進行正常通信，需要在打包機服務端部署一個公共模塊，主要負責實現(xiàn)以下兩大功能：

功能一、在發(fā)現(xiàn)異常問題時向訂閱者(任何需要獲知打包流程的人員均可以成為訂閱者，即開發(fā)人員、測試人員、產(chǎn)品經(jīng)理、項目經(jīng)理都可以成為訂閱者；在默認狀態(tài)下，提交這個內(nèi)容的開發(fā)人員和負責測試對應內(nèi)容的測試人員為訂閱者)輸出異常信息；

具體地，可以將打包過程中遇到的異常問題采用多種不同的形式進行輸出，按照通知訂閱者的要求來定制輸出形式。例如：以郵件形式通知訂閱者，以即時通訊軟件的即時聊天通知。

在構(gòu)建過程中發(fā)生異常的時候，通過利用郵件系統(tǒng)協(xié)議，采用自動發(fā)送的技術(shù)，將構(gòu)建異常提示以及輸出通過一封電子郵件的形式抄送給多個訂閱者。在持續(xù)集成過程中，如果在任一執(zhí)行步驟中發(fā)現(xiàn)異常而卻無法及時解決，都會導致整個集成過程的阻塞，從而直接影響到測試人員的測試工作。在構(gòu)建過程中發(fā)生異常時及時提醒相關(guān)人員處理，能夠有效地防止構(gòu)建異常所導致的測試阻塞。

另外，在構(gòu)建過程中發(fā)生異常時，還可以通過利用即時通信協(xié)議，采用自動發(fā)送的技術(shù)，將構(gòu)建異常提示以及輸出通過即時消息的形式發(fā)送給多個訂閱者。

功能二、管理不同服務端之間的通信，確保主從服務端之間的通信正常。

由于使用了分布式的主從服務端架構(gòu)，那么在網(wǎng)絡不穩(wěn)定的情況下，有可能會出現(xiàn)各個服務端之間的通信被中斷或者因網(wǎng)絡傳輸錯誤而導致接收到錯誤的數(shù)據(jù)。因此，為了確保數(shù)據(jù)傳輸?shù)臏蚀_性，可以實時監(jiān)測各個服務端之間的通信是否正常，如果發(fā)現(xiàn)網(wǎng)絡丟包或者傳輸錯誤，則需要進行包檢測、網(wǎng)絡配置重置、多次重連和錯誤糾正等方式來處理網(wǎng)絡異常情況，進而確保主從服務端之間的通信正常。

根據(jù)本發(fā)明實施例，還提供了另一種軟件開發(fā)項目中修改內(nèi)容的測試方法的實施例，圖2是根據(jù)本發(fā)明實施例的另一種軟件開發(fā)項目中修改內(nèi)容的測試方法的流程圖，如圖2所示，該方法應用于測試服務端，該方法包括如下步驟：

步驟S202，經(jīng)由打包服務端提供的測試接口從打包服務端獲取待測試包體，其中，待測試包體是由打包服務端在實時獲取軟件開發(fā)項目的待測試修改內(nèi)容并對待測試修改內(nèi)容進行打包處理后得到的；

步驟S204，對待測試包體進行測試。

可選地，在步驟S202中，經(jīng)由測試接口從打包服務端獲取待測試包體可以包括以下執(zhí)行步驟：

步驟S2021，經(jīng)由測試接口從打包服務端獲取待測試包體對應的版本號信息；

步驟S2022，采用版本號信息向打包服務端請求待測試包體的下載地址；

步驟S2023，根據(jù)下載地址從打包服務端獲取待測試包體。

通過訪問打包機服務端提供的接口，獲得當前各類打包模塊下最新包體的版本號信息，其中，版本號信息用于訪問打包服務端，從打包服務端獲得版本號對應的包體的URL下載地址。

打包服務端通過統(tǒng)一資源定位符(URL)下載的方式實現(xiàn)自動分發(fā)包體并自動部署到由測試人員搭建的一個或多個測試服務端(即QA服務端)上，再由QA服務端上的自動化測試腳本將會對獲得的最新包體進行自動化回歸測試。

可選地，在步驟S202，經(jīng)由測試接口從打包服務端獲取待測試包體之前，還可以包括以下執(zhí)行步驟：

步驟S206，對本地當前存在的包體進行備份，得到備份包體，其中，備份包體用于在采用待測試包體對本地對應的已存在包體進行更新過程中發(fā)生異常時，通過備份包體對已存在包體進行恢復。

在優(yōu)選實施例中，可以將對本地QA服務端現(xiàn)有的包體數(shù)據(jù)進行備份，用于如果更新包體失敗(例如：如果測試服務端磁盤已滿或者更新時突然斷電導致更新失敗)時，執(zhí)行包體還原恢復操作。

在獲得從打包機服務端發(fā)出的自動部署指令后，通過URL地址將最新包體下載到本地QA服務端上。在對本地包體進行更新時，如果更新過程一切正常，本地包體將會被更新到最新版本，并發(fā)送啟動指令觸發(fā)自動化測試。如遇到更新失敗，將調(diào)用本地已存在的包體備份數(shù)據(jù)恢復到以前的包體內(nèi)容。

可選地，在步驟S204中，對待測試包體進行測試可以包括以下執(zhí)行步驟：

步驟S2041，獲取與待測試包體對應的測試用例和測試腳本；

步驟S2042，采用測試用例和測試腳本對待測試包體進行測試。

在接收到上述啟動指令后，開始對最新包體進行各類自動化測試，并向打包機服務端返回自動化測試結(jié)果。QA服務端上可以包含各類自動化測試用例和測試腳本，例如：敏感詞過濾、進出房間、切換頻道、靜態(tài)代碼檢測和代碼覆蓋率檢測。

可選地，在步驟S204，對待測試包體進行測試之后，還可以包括以下執(zhí)行步驟：

步驟S208，將與待測試包體對應的測試結(jié)果反饋至打包服務端。

通過利用現(xiàn)有自動化測試技術(shù)搭建的測試用例和測試腳本可以對本機上的最新包體進行自動化測試，并向打包機服務端返回自動化測試結(jié)果。

同樣地，為了確保打包服務端與一個或多個測試服務端進行正常通信，還需要在測試服務端也部署一個公共模塊，主要負責以下兩大功能：

功能一、在發(fā)現(xiàn)異常問題時向訂閱者(任何需要獲知打包流程的人員均可以成為訂閱者，即開發(fā)人員、測試人員、產(chǎn)品經(jīng)理、項目經(jīng)理都可以成為訂閱者；在默認狀態(tài)下，提交這個內(nèi)容的開發(fā)人員和負責測試對應內(nèi)容的測試人員為訂閱者)輸出異常信息；

功能二、管理不同服務端之間的通信，確保通信內(nèi)容正確。

下面將通過一個具體示例對上述打包服務端與一個或多個測試服務端進行通信交互完成對軟件開發(fā)項目中修改內(nèi)容的測試過程作進一步地說明。

假設(shè)程序員A對娛樂房間模板(一種虛擬房間界面)的“公屏聊天”模塊進行過修改并提交了相關(guān)代碼，打包機服務端在檢查到新提交內(nèi)容(可以包含代碼、資源(圖片、flash、css)文件)后將會將該最新提交內(nèi)容加入到構(gòu)建隊列中排隊等待打包。當構(gòu)建開始時，首先會進行代碼更新，對構(gòu)建代碼進行鎖定并建立構(gòu)建臨時目錄。在導入所有項目代碼之后開始運行打包腳本進行構(gòu)建。當執(zhí)行完自動打包操作后，將會輸出本次打包產(chǎn)物：待測包體(模板)和對應版本號、提交程序和相關(guān)代碼詳情等信息，并將模板URL地址分發(fā)到一個或多個QA服務端上。在項目構(gòu)建結(jié)束后，需要對項目代碼進行解鎖，并且，由于構(gòu)建過程中會產(chǎn)生體積較大的臨時文件或編譯中間產(chǎn)物，在項目構(gòu)建結(jié)束后，還需要對對臨時文件和編譯中間文件進行清理，為打包服務端釋放存儲空間。

QA服務端在獲得模板URL地址后，將會根據(jù)服務端下發(fā)信息自動下載該測試包體(模板)并將本地模板更新到最新版本。

假設(shè)QA服務端A上部署了驗證公屏聊天內(nèi)容(可以包括但不限于：中文、英文、特殊字符、圖片和表情輸入)的各類自動化測試腳本，在QA服務端B上部署了進出房間、切換頻道的自動化測試腳本，在QA服務端C上部署的是敏感詞過濾的自動化測試腳本，而在QA服務端D上部署的是靜態(tài)代碼檢測的自動化測試腳本，那么當QA服務端A、B、C和D分別獲取到最新的關(guān)于“公屏聊天”模塊修改的模板文件后，將分別運行各自的自動化測試腳本內(nèi)容，如果測試通過將會對打包機服務端返回測試通過結(jié)果。

如果打包機服務端接收到來自于QA服務端A、B、C和D的測試通過消息后，證明該提交版本通過自動化測試驗證，那么打包機服務端將會登錄對應服務端，并對指定的配置文件或目標源數(shù)據(jù)進行更新操作，測試人員只需要退出房間再重進便可獲得最新的房間模板，并可以進一步驗證“公屏聊天”模塊是否存在自動化測試尚未發(fā)現(xiàn)的缺陷存在。

如果打包機服務端接收到來自于QA服務端A關(guān)于“中文輸入”的自動化測試腳本測試未通過的消息以及來自于QA服務端B、C和D的測試通過消息后，那么將會輸出相關(guān)異常信息并通知相應的訂閱者，例如：通知程序員A(訂閱者之一)，其提交的“公屏聊天”模塊修改，在“中文輸入”功能上存在異常，以便及時提醒該開發(fā)人員盡快修復缺陷。

通過上述示例可以看出，本發(fā)明實施例所提供的技術(shù)方案基于持續(xù)集成理論，提供一種軟件開發(fā)實踐，當團隊的成員頻繁提交各自的工作成果(通常每名成員每天至少提交一次)時，對于每次提交的成果都通過自動集成、自動構(gòu)建(打包)和自動部署。在持續(xù)集成的開發(fā)過程中，每完成一個完整的部分，便可向下一個環(huán)節(jié)交付，如發(fā)現(xiàn)問題可以馬上進行調(diào)整，因此，被發(fā)現(xiàn)的缺陷不會被遺留至后繼環(huán)節(jié)中。開發(fā)人員在每次提交最新代碼之后，立刻對開發(fā)人員提交的代碼進行構(gòu)建以及測試，并根據(jù)測試結(jié)果可以確定新提交的代碼與原有代碼能否正確地集成在一起。測試人員只要通過運行對應的自動化測試腳本，對提交的修改內(nèi)容進行自動化測試，便可獲知是具體哪次提交引發(fā)了缺陷，進而可以使得軟件開發(fā)項目團隊在項目研發(fā)的各個階段能夠持續(xù)接收到測試反饋并加以改進，而不必等到項目生命周期的最后階段才開始查找及修復缺陷。因此，對于開發(fā)人員而言，在其提交改動內(nèi)容之后，如在改動內(nèi)容中存在缺陷，則可以及時得知錯誤原因并馬上進行修復；對于測試人員而言，在其獲得最新版本之前，該版本的基本邏輯已經(jīng)通過自動化測試驗證無基礎(chǔ)邏輯錯誤，這樣測試人員可以節(jié)省大量時間，將測試精力集中投入到更加復雜的邏輯測試中去。

根據(jù)本發(fā)明實施例，還提供了一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的實施例，圖3是根據(jù)本發(fā)明實施例的一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖，如圖3所示，該裝置應用于打包服務端，該裝置包括：獲取模塊100，用于實時獲取軟件開發(fā)項目的待測試修改內(nèi)容；處理模塊102，用于對待測試修改內(nèi)容進行打包處理，得到待測試包體，并向一個或多個測試服務端提供測試接口，其中，測試接口用于一個或多個測試服務端獲取待測試包體。

可選地，圖4是根據(jù)本發(fā)明優(yōu)選實施例的一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖，如圖4所示，上述裝置還可以包括：第一判斷模塊104，用于判斷預設(shè)隊列中是否存在尚未執(zhí)行或正在執(zhí)行打包處理的修改內(nèi)容；第一確定模塊106，用于在第一判斷模塊輸出為是時，則等到預設(shè)隊列中當前存在的全部修改內(nèi)容均打包完畢后，再確定對待測試修改內(nèi)容進行打包處理。

可選地，如圖4所示，上述裝置還可以包括：第二判斷模塊108，用于判斷待測試修改內(nèi)容對應的版本號信息是否與前一個已經(jīng)成功打包的修改內(nèi)容對應的版本號信息一致；第二確定模塊110，用于在第二判斷模塊輸出為否時，確定對待測試修改內(nèi)容進行打包處理。

可選地，處理模塊102可以包括：鎖定單元(圖中未示出)，用于對待測試修改內(nèi)容進行鎖定；獲取單元(圖中未示出)，用于獲取與待測試修改內(nèi)容對應的打包腳本；第一處理單元(圖中未示出)，用于采用打包腳本對待測試修改內(nèi)容進行打包處理，得到待測試包體；第二處理單元(圖中未示出)，用于對待測試修改內(nèi)容進行解鎖，并對打包處理過程中產(chǎn)生的中間文件進行清理。

可選地，如圖4所示，上述裝置還可以包括：接收模塊112，用于接收一個或多個測試服務端反饋的與待測試修改內(nèi)容對應的測試結(jié)果；更新模塊114，用于當測試結(jié)果表明待測試修改內(nèi)容通過測試時，對一個或多個測試服務端上與待測試修改內(nèi)容對應的配置內(nèi)容進行更新；提示模塊116，用于當測試結(jié)果表明待測試修改內(nèi)容未通過測試時，則發(fā)出異常提示信息。

根據(jù)本發(fā)明實施例，還提供了另一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的實施例，圖5是根據(jù)本發(fā)明實施例的另一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖，如圖5所示，該裝置應用于測試服務端，該裝置包括：獲取模塊200，用于經(jīng)由打包服務端提供的測試接口從打包服務端獲取待測試包體，其中，待測試包體是由打包服務端在實時獲取軟件開發(fā)項目的待測試修改內(nèi)容并對待測試修改內(nèi)容進行打包處理后得到的；測試模塊202，用于對待測試包體進行測試。

可選地，獲取模塊200包括：第一獲取單元(圖中未示出)，用于經(jīng)由測試接口從打包服務端獲取待測試包體對應的版本號信息；請求單元(圖中未示出)，用于采用版本號信息向打包服務端請求待測試包體的下載地址；第二獲取單元(圖中未示出)，用于根據(jù)下載地址從打包服務端獲取待測試包體。

可選地，圖6是根據(jù)本發(fā)明優(yōu)選實施例的另一種軟件開發(fā)項目中修改內(nèi)容的測試裝置的結(jié)構(gòu)框圖，如圖6所示，上述裝置還可以包括：備份模塊204，用于對本地當前存在的包體進行備份，得到備份包體，其中，備份包體用于在采用待測試包體對本地對應的已存在包體進行更新過程中發(fā)生異常時，通過備份包體對已存在包體進行恢復。

可選地，測試模塊202包括：第三獲取單元(圖中未示出)，用于獲取與待測試包體對應的測試用例和測試腳本；測試單元(圖中未示出)，用于采用測試用例和測試腳本對待測試包體進行測試。

可選地，如圖6所示，上述裝置還可以包括：反饋模塊206，用于將與待測試包體對應的測試結(jié)果反饋至打包服務端。

通過本發(fā)明實施例所提供的技術(shù)方案，可以包括：一個主服務端(即打包機服務端)以及一個或多個從服務端(即QA服務端)，主服務端主要由自動化構(gòu)建系統(tǒng)組成并對外提供多種訪問接口，打包機服務端由程序進行日常維護。從服務端主要由多種自動化測試模塊構(gòu)成，QA服務端通過運行自動化測試模塊與打包機服務端進行網(wǎng)絡通信，通過接口獲得包體版本號和代碼詳情(即自動化測試模塊執(zhí)行測試用例對應模塊的代碼，其中，在測試用例、輸入的代碼以及版本號三者之間存在一一對應關(guān)系)等數(shù)據(jù)并實時向打包機服務端反饋測試結(jié)果。不同的QA服務端上會部署不同的自動化測試用例，以供同時進行分布式多點自動化測試，QA服務端由測試人員進行日常維護。具體交互過程請參見上述方法實施例中介紹的內(nèi)容，此處不再贅述。

上述本發(fā)明實施例序號僅僅為了描述，不代表實施例的優(yōu)劣。

在本發(fā)明的上述實施例中，對各個實施例的描述都各有側(cè)重，某個實施例中沒有詳述的部分，可以參見其他實施例的相關(guān)描述。

在本申請所提供的幾個實施例中，應該理解到，所揭露的技術(shù)內(nèi)容，可通過其它的方式實現(xiàn)。其中，以上所描述的裝置實施例僅僅是示意性的，例如所述單元的劃分，可以為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個單元或組件可以結(jié)合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口，單元或模塊的間接耦合或通信連接，可以是電性或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個單元上。可以根據(jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能單元的形式實現(xiàn)。

所述集成的單元如果以軟件功能單元的形式實現(xiàn)并作為獨立的產(chǎn)品銷售或使用時，可以存儲在一個計算機可讀取存儲介質(zhì)中。基于這樣的理解，本發(fā)明的技術(shù)方案本質(zhì)上或者說對現(xiàn)有技術(shù)做出貢獻的部分或者該技術(shù)方案的全部或部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品存儲在一個存儲介質(zhì)中，包括若干指令用以使得一臺計算機設(shè)備(可為個人計算機、服務器或者網(wǎng)絡設(shè)備等)執(zhí)行本發(fā)明各個實施例所述方法的全部或部分步驟。而前述的存儲介質(zhì)包括：U盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、移動硬盤、磁碟或者光盤等各種可以存儲程序代碼的介質(zhì)。

以上所述僅是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術(shù)領(lǐng)域的普通技術(shù)人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視為本發(fā)明的保護范圍。