本發(fā)明涉及軟件自動化測試領(lǐng)域，尤其是涉及一種基于git代碼文件檢索粒度的自動化回歸測試方法。

背景技術(shù)：

為了使軟件產(chǎn)品能夠快速響應(yīng)市場，軟件版本的迭代頻率越來越高，項目發(fā)布周期越來越短，伴隨而來的必然是更多的資源投入。而多出來的這部分投入不再是新功能開發(fā)所需的時間和人力，而是每次版本迭代的回歸測試所耗費的時間和人力，越是龐大的軟件產(chǎn)品，手工回歸測試耗費的時間和人力越是大的驚人，回歸測試已經(jīng)成為了項目快速交付的新瓶頸。為了適應(yīng)越來越頻繁的軟件迭代版本的交付，尋求高質(zhì)量、高效率、低成本的回歸測試方法成為了目前軟件行業(yè)迫切需要攻克的難題。

軟件項目迭代頻率增高同樣導(dǎo)致了軟件開發(fā)過程中會持續(xù)產(chǎn)生多個待測版本，傳統(tǒng)的集中式版本控制系統(tǒng)要求所有代碼提交后才可以構(gòu)建整包以供測試，若是開發(fā)代碼質(zhì)量不高，影響范圍卻很廣，一旦出現(xiàn)問題，解決起來就非常費時費力。這樣的情況若是出現(xiàn)的頻率很高，則會嚴(yán)重影響開發(fā)代碼線的穩(wěn)定性。為了解決這個問題，很多軟件項目開發(fā)開始采用分布式版本控制系統(tǒng)。

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

本發(fā)明的目的就是為了克服上述現(xiàn)有技術(shù)存在的缺陷而提供一種粒度更細，頻率更高，資源更加節(jié)省的基于git代碼文件檢索粒度的自動化回歸測試方法，使得在檢測周期內(nèi)更新的開發(fā)代碼，都能得到及時的回歸測試，既增強了代碼線的穩(wěn)定性和健壯性，又大大降低了回歸測試所耗費的時間成本和人力成本，繼而打破項目快速迭代交付過程中回歸測試所帶來的瓶頸。

本發(fā)明的目的可以通過以下技術(shù)方案來實現(xiàn)：

一種基于git代碼文件檢索粒度的自動化回歸測試方法，包括以下步驟：

1)自動獲取git開發(fā)代碼主線上有代碼變化的文件，得到一張記錄了在檢測時間內(nèi)全部有代碼變化的文件名列表；

2)將被捕捉到的有變化的代碼文件轉(zhuǎn)化為受影響的功能特性列表；

3)將受影響的功能特性轉(zhuǎn)化為需要運行的自動化回歸用例標(biāo)簽；

4)將步驟1)、步驟2)、和步驟3)中所有的手動執(zhí)行操作轉(zhuǎn)化成自動執(zhí)行，并通過jenkins平臺將其集成起來，實現(xiàn)一鍵式觸發(fā)。

優(yōu)選地，所述的步驟1)自動獲取git開發(fā)代碼主線上有代碼變化的文件具體為：

第一步：檢查是否到檢測周期；

第二步：刪除前一次殘留的標(biāo)簽；

第三步：進入到git本地倉庫的開發(fā)代碼主庫路徑，打一個oldtag標(biāo)簽，記錄當(dāng)前舊的代碼狀態(tài)；

第四步：執(zhí)行更新代碼命令；

第五步：此時再打一個標(biāo)簽記為newtag，記錄的是當(dāng)前最新的代碼狀態(tài)；

第六步：通過git代碼管理工具自帶的命令gitdiff，輸出新老標(biāo)簽所代表的不同代碼版本之間，有代碼變動的部分，打印其文件名。

優(yōu)選地，所述的執(zhí)行更新代碼命令具體為：由多人協(xié)作分布式開發(fā)編寫的遠程倉庫里的代碼將被更新下載到本地代碼倉庫，使得本地代碼狀態(tài)與遠程倉庫代碼的最新狀態(tài)一致。

優(yōu)選地，所述的檢測周期為自定義設(shè)置，根據(jù)項目的具體情況，評估最佳的循環(huán)檢測周期。

優(yōu)選地，通過變化的代碼文件名，得到所有被影響的功能特性，通過特性規(guī)則表來描述某一模塊所有的代碼文件和與之對應(yīng)的功能特性之間的關(guān)系。

優(yōu)選地，所述的特性規(guī)則表中的對應(yīng)關(guān)系為一對一、一對多、多對一、多對多這四種情況中的一種。

優(yōu)選地，所述的特性規(guī)則表制定好以后，通過腳本工具將步驟1)中的執(zhí)行結(jié)果“有代碼變化的文件名列表中的文件名”與特性規(guī)則表進行比對，若存在，則輸出對應(yīng)的特性，組成一張功能特性列表，即實現(xiàn)在檢測周期內(nèi)，所有有代碼變化的文件影響到的功能特性列表輸出出來。

優(yōu)選地，所述的步驟3)具體為：

將步驟2)輸出的功能特性轉(zhuǎn)化為自動化回歸的用例標(biāo)簽，用以篩選用例執(zhí)行，這同樣需要一張規(guī)則表，將此規(guī)則表命名為標(biāo)簽規(guī)則表；

所述的標(biāo)簽規(guī)則表的直接對應(yīng)關(guān)系為“功能特性：用例標(biāo)簽”；

所述的標(biāo)簽規(guī)則表是完全匹配特性列表的，即步驟2)輸出的功能特性列表項一定能在此標(biāo)簽規(guī)則表中找到對應(yīng)的自動化用例標(biāo)簽，同樣需要一個腳本工具，來實現(xiàn)自動查找特性，輸出對應(yīng)標(biāo)簽，組成一張用于回歸測試的自動化用例標(biāo)簽列表，通過這張用例標(biāo)簽列表來篩選觸發(fā)自動化回歸用例。

優(yōu)選地，所述的步驟4)具體為：

設(shè)置各工作模塊：

job0_downgitcode：用于首次下載開發(fā)代碼，在同一個構(gòu)建節(jié)點上此任務(wù)只運行一次；

job1_getchangefileslist：用于獲取到開發(fā)主線倉庫的所有代碼有變化的文件名，并將文件名列表輸出到srt_changefileslist.txt，上傳公共文件服務(wù)器；

job2_diffpropertyrole：用于得到代碼變化影響到的功能特性列表，同樣輸出到srt_propertylist.txt，并上傳公共文件服務(wù)器；

job3_diffsuitetagrole：用于得到受影響特性所對應(yīng)的用例標(biāo)簽列表，輸出到srt_suitetaglist.txt，并上傳公共文件服務(wù)器；

at_slimsizert：用于通過用例標(biāo)簽篩選運行自動化測試用例，并郵件通知用例執(zhí)行結(jié)果；

job0_downgitcode在同一構(gòu)建節(jié)點上只需要運行一次，

而job1_getchangefileslist，job2_diffpropertyrole，job3_diffsuitetagrole和at_slimsizert任務(wù)均可多次重復(fù)運行，且執(zhí)行順序不變，在jenkins上通過設(shè)置關(guān)聯(lián)任務(wù)，將這些任務(wù)串聯(lián)起來，形成的效果是一旦job1_getchangefileslist執(zhí)行成功，自動觸發(fā)job2_diffpropertyrole開始運行，同理，一旦job2_diffpropertyrole運行完成，則自動觸發(fā)job3_diffsuitetagrole，完成后，接著觸發(fā)at_slimsizert任務(wù)。

優(yōu)選地，所述的下載開發(fā)代碼的存放路徑，放在此任務(wù)工作空間的同級目錄下。

與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點：

1、精準(zhǔn)性：實現(xiàn)針對文件級代碼變更的回歸測試，即只針對有代碼變化的文件所影響的功能特性進行回歸測試，縮小了回歸測試的范圍，提高了回歸測試的精準(zhǔn)性；

2、時效性：可通過適當(dāng)增加檢測頻率，使得任何有效提交的開發(fā)代碼都能及時的得到回歸測試的檢驗，及時發(fā)現(xiàn)問題并解決，長時間的保證代碼線的健壯性與穩(wěn)定性；

3、資源節(jié)?。和ㄟ^縮小測試范圍來降低回歸測試的工作量；通過使用rf自動化框架編寫自動化回歸用例來減少重復(fù)性的測試勞動，節(jié)約人力；通過jenkins集成平臺，有選擇的觸發(fā)自動化測試用例來避免全量用例集覆蓋所造成的時間浪費，同時減少人工干預(yù)，還可以利用非工作時間運行這些自動化回歸測試用例，再次縮短回歸測試階段的時間成本。

4、軟件越是龐大，應(yīng)用本發(fā)明所帶來的優(yōu)勢越明顯。

附圖說明

圖1為自動獲取git開發(fā)主線上有代碼變化的文件的流程圖；

圖2為jenkins集成整體流程圖；

圖3為對比腳本邏輯示意圖。

具體實施方式

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

本發(fā)明git是目前世界上最先進的分布式版本控制系統(tǒng)，可以有效、高速的處理從很小到非常大的項目版本管理，因為其適應(yīng)分布式開發(fā)，速度快，靈活，解決沖突容易，可以支持離線工作等優(yōu)點，而被廣泛應(yīng)用于各種規(guī)模的敏捷開發(fā)項目中。

git提供了便捷的多人協(xié)作分支管理，可以讓不同工程師在各自的分支上開發(fā)代碼并自測，也可以與其他分支自由的合并聯(lián)調(diào)，構(gòu)包驗證，這時再將這些進行過基本測試的代碼合并到同一條代碼線上，可以極大程度的保證這條代碼線的穩(wěn)定性，我們?nèi)藶榈亩x這條代碼線為開發(fā)代碼主線(以下簡稱開發(fā)主線)。在開發(fā)主線上構(gòu)建的整包才可以成為每次項目迭代版本發(fā)布的回歸測試對象。

git同時提供一個可以快速找到某一時刻版本的管理機制，這就是標(biāo)簽管理。git的標(biāo)簽是版本庫的一個快照，但是本質(zhì)是一個指向某個commit的指針，所以創(chuàng)建和刪除標(biāo)簽都是瞬時完成的。我們可以利用標(biāo)簽來獲取不同版本之間的代碼差異，以此為基礎(chǔ)得到較為精準(zhǔn)的回歸測試范圍。這樣就避免了全量回歸測試帶來的時間和人力上的資源浪費。

降低回歸測試的成本，除了要縮小回歸測試的范圍，還可以通過用自動化測試來代替手工測試，進一步節(jié)約人力成本。本研究采用目前比較主流的自動化測試工具robotframework(以下簡稱rf)，rf是一款開源的自動化測試框架，具備很好的可擴展性，可以集成很多測試庫，測試人員也可以使用python來創(chuàng)建自己需要的測試庫，利用已有的關(guān)鍵字，創(chuàng)建自己需要的關(guān)鍵字，形成更高級別的行為，可以同時測試多種類型的客戶端或者接口，可以利用“標(biāo)簽”功能對測試用例進行分類和有選擇的執(zhí)行。

最后借用jenkins持續(xù)集成平臺實現(xiàn)遠程控制robotframework自動化測試用例的執(zhí)行，可以減少自動化回歸測試中的人工干預(yù)，利用夜晚等非工作時間來完成測試任務(wù)，大大縮短了回歸測試階段整體所占用的時間，進一步節(jié)約時間成本。

本發(fā)明基于git代碼文件檢索粒度的自動化回歸測試方法，包括以下步驟：

第一部分：自動獲取git開發(fā)代碼主線上有代碼變化的文件。

此部分的目的是要定期找到有代碼變更的文件，確認(rèn)較為精準(zhǔn)的回歸測試對象。

git標(biāo)簽管理工具可以提供使用不同標(biāo)簽對代碼狀態(tài)差異的查詢操作。流程圖如圖1所示，具體步驟如下：

第一步：首先檢查是否到檢測周期；

第二步：刪除前一次殘留的標(biāo)簽；

第三步：進入到git本地倉庫的開發(fā)代碼主庫路徑，打一個oldtag標(biāo)簽，記錄當(dāng)前舊的代碼狀態(tài)；

第四步：執(zhí)行更新代碼命令，此時，由多人協(xié)作分布式開發(fā)編寫的的遠程倉庫里的代碼將被更新下載到本地代碼倉庫，使得本地代碼狀態(tài)與遠程倉庫代碼的最新狀態(tài)一致；

第五步：此時再打一個標(biāo)簽記為newtag，記錄的是當(dāng)前最新的代碼狀態(tài)；

第六步：通過git代碼管理工具自帶的命令gitdiff，輸出新老標(biāo)簽所代表的不同代碼版本之間，有代碼變動的部分，打印其文件名。

本次自動獲取代碼變化文件的循環(huán)結(jié)束后，實現(xiàn)的效果是得到一張記錄了在檢測時間內(nèi)全部有代碼變化的文件名列表，接下來將繼續(xù)檢測是否到檢測周期，進入下一個循環(huán)。

檢測周期是自定義設(shè)置的，可以根據(jù)項目的具體情況，評估最佳的循環(huán)檢測周期，檢測的間隔時間不宜過長，過長則導(dǎo)致無法保證新變更的代碼得到及時的回歸測試；也不宜過短，過短則可能會出現(xiàn)回歸用例執(zhí)行失敗，而失敗的原因可能是因為多人提交代碼時間有差導(dǎo)致某一功能模塊代碼不完整，而不是因為代碼本身有問題導(dǎo)致的。這會直接產(chǎn)生用于排查用例執(zhí)行失敗原因的工作量，耗費額外的，不能產(chǎn)生價值的時間。所以尋找到匹配項目的最合適的檢測周期，可以最大程度的發(fā)揮回歸測試方法所達到的效果。

第二部分：將被捕捉到的有變化的代碼文件轉(zhuǎn)化為受影響的功能特性列表。

此部分的目的是通過變化的代碼文件名，得到所有被影響的功能特性，為了完成此目的就需要一張規(guī)則表來描述某一模塊所有的代碼文件和與之對應(yīng)的功能特性之間的關(guān)系，將其命名為特性規(guī)則表。

特性規(guī)則表中的對應(yīng)關(guān)系可能是一對一，一對多，多對一，多對多這四種情況中的一種。例如某一代碼文件的修改可能只影響1個功能特性，或者影響到多個功能特性，也可能多個代碼文件所描述的是同一個功能特性，還存在多個代碼文件共同影響著2個或2個以上的功能特性。

這一技術(shù)環(huán)節(jié)的輸入是變化的文件名，要求的輸出是被影響的功能特性表，所以這張?zhí)匦砸?guī)則表的直接對應(yīng)關(guān)系為“文件名：影響特性”。下面來舉例說明，如何實現(xiàn)上述四種對應(yīng)關(guān)系：

一對一關(guān)系：filename1:特性a

一對多關(guān)系：filename2:特性b、特性c、特性d

多對一關(guān)系：filename3:特性e

filename4:特性e

多對多關(guān)系：filename5:特性f、特性g

filename6:特性f、特性g

filename7:特性f、特性g

我們將回歸測試中所有的文件名一一列出來，無論文件名與影響特性屬于哪一種對應(yīng)關(guān)系，特性規(guī)則表都可以用上述方式描述出來。

特性規(guī)則表制定好以后，還需要一個腳本工具，將本發(fā)明中第一部分的執(zhí)行結(jié)果——有代碼變化的文件名列表中的文件名與特性規(guī)則表進行比對，若存在，則輸出對應(yīng)的特性，組成一張功能特性列表，即實現(xiàn)在檢測周期內(nèi)，所有有代碼變化的文件影響到的功能特性列表輸出出來，也就是本次回歸功能點的測試范圍。

第三部分：將被影響的功能特性轉(zhuǎn)化為需要運行的自動化回歸用例標(biāo)簽。

此部分的目的是將第二部分輸出的功能特性轉(zhuǎn)化為自動化回歸的用例標(biāo)簽，用以篩選用例執(zhí)行，這同樣需要一張規(guī)則表，為了區(qū)分，將此規(guī)則表命名為標(biāo)簽規(guī)則表。

標(biāo)簽規(guī)則表的直接對應(yīng)關(guān)系為“功能特性：用例標(biāo)簽”，為了簡化標(biāo)簽規(guī)則表的復(fù)雜度，我們不用單一功能特性作為對比項，直接將第二部分輸出的功能特性組合作為對比項，下面來舉例說明，標(biāo)簽規(guī)則表的組織格式如下(以第二部分輸出的特性為例)：

特性a：標(biāo)簽ⅰ

特性b、特性c、特性d：標(biāo)簽ⅱ

特性e：標(biāo)簽ⅲ

特性f、特性g：標(biāo)簽ⅳ

標(biāo)簽規(guī)則表是完全匹配特性列表的，即第二部分輸出的功能特性列表項一定能在此標(biāo)簽規(guī)則表中找到對應(yīng)的自動化用例標(biāo)簽。它同樣需要一個腳本工具，來實現(xiàn)自動查找特性，輸出對應(yīng)標(biāo)簽，組成一張用于回歸測試的自動化用例標(biāo)簽列表。此時就可以通過這張用例標(biāo)簽列表來篩選觸發(fā)自動化回歸用例。

第四部分：將上述技術(shù)與jenkins集成，實現(xiàn)一鍵觸發(fā)。

此部分的目的是將第一部分、第二部分、第三部分中所有的手動執(zhí)行操作轉(zhuǎn)化成自動執(zhí)行，并通過jenkins平臺將其集成起來，實現(xiàn)一鍵式觸發(fā)。流程圖如圖2所示，下面來進行分別說明：

job0_downgitcode：用于首次下載開發(fā)代碼，在同一個構(gòu)建節(jié)點上此任務(wù)只運行一次，以后只需要更新代碼即可，不需要重復(fù)下載整個代碼庫，節(jié)約了后續(xù)任務(wù)的運行時間。注意，下載的開發(fā)代碼的存放路徑，不要直接放在此任務(wù)的工作空間下，否則任務(wù)每次運行前進行臨時文件清理時，就會刪除掉已經(jīng)下載的開發(fā)代碼，建議放在此任務(wù)工作空間的同級目錄下。

job1_getchangefileslist：用于獲取到開發(fā)主線倉庫的所有代碼有變化的文件名，并將文件名列表輸出到srt_changefileslist.txt，上傳公共文件服務(wù)器，便于查看和取用，例如ftp服務(wù)器。

job2_diffpropertyrole：用于得到代碼變化影響到的功能特性列表，同樣輸出到srt_propertylist.txt，并上傳ftp服務(wù)器。

job3_diffsuitetagrole：用于得到受影響特性所對應(yīng)的用例標(biāo)簽列表，輸出到srt_suitetaglist.txt，并上傳ftp服務(wù)器。

at_slimsizert：用于通過用例標(biāo)簽篩選運行自動化測試用例，并郵件通知用例執(zhí)行結(jié)果。

job0在同一構(gòu)建節(jié)點上只需要運行一次，而job1，job2，job3和at任務(wù)均可多次重復(fù)運行，且執(zhí)行順序不變，在jenkins上通過設(shè)置關(guān)聯(lián)任務(wù)，可以將這些任務(wù)串聯(lián)起來，形成的效果是一旦job1執(zhí)行成功，自動觸發(fā)job2開始運行，同理，一旦job2運行完成，則自動觸發(fā)job3，完成后，接著觸發(fā)at任務(wù)。這樣就可以將所有任務(wù)操作集成起來，實現(xiàn)了一鍵式觸發(fā)。

此外，job1執(zhí)行的頻率間隔就是代碼檢測周期，可以通過設(shè)置job1的自動觸發(fā)時間來實現(xiàn)代碼檢測頻率的調(diào)整。

應(yīng)用本發(fā)明提出的回歸測試方法與jenkins平臺集成，形成了一個完整的自動化回歸測試系統(tǒng)，又稱細粒度自動化回歸測試系統(tǒng)，此部分針對某一備份軟件項目為例，詳細描述該系統(tǒng)的組成和實現(xiàn)細節(jié)。

此自動化回歸系統(tǒng)包含5個任務(wù)，每個任務(wù)的功能作用已在技術(shù)解決方案第四部分內(nèi)容中闡述，此間不再贅述。下面將逐個描述任務(wù)實現(xiàn)細節(jié)。

job1的構(gòu)建腳本如下：

首先設(shè)置開發(fā)主線本地倉庫的檢測路徑；進入此路徑下，刪除前一次構(gòu)建殘留的兩個標(biāo)簽；然后設(shè)置當(dāng)前本地倉庫的狀態(tài)標(biāo)簽slimsizeold，接著從開發(fā)主線遠程倉庫中拉取最新代碼至本地倉庫，設(shè)置代碼倉庫更新后的狀態(tài)標(biāo)簽slimsizenew；最后執(zhí)行g(shù)it代碼管理工具自帶的命令gitdiff來輸出新老標(biāo)簽代表的不同代碼狀態(tài)之間，有代碼變化的文件名，并重定向到一個txt文件中，將此txt文件拷貝到任務(wù)的工作空間下，利用jenkins的插件，就可以將任務(wù)工作空間中的文件上傳到ftp服務(wù)器上，以供后續(xù)任務(wù)使用。

同時針對備份項目實例，制定檢測周期為24小時，調(diào)試任務(wù)時，測試整套任務(wù)的最長執(zhí)行時間不超過4小時，因此設(shè)置此任務(wù)的自動發(fā)起時間為每天凌晨3點，這樣測試工程師每天上班時就可以查看自動化回歸測試的執(zhí)行結(jié)果，處理相關(guān)問題。

job2的構(gòu)建腳本如下所示：

首先從ftp上下載job1產(chǎn)生的有代碼變化的文件名列表到本任務(wù)的工作空間；然后將特性規(guī)則表和對比腳本從測試代碼倉庫拷貝出來，也存放到本任務(wù)的工作空間；最后將對比腳本轉(zhuǎn)化成可執(zhí)行文件，并運行，同時將運行結(jié)果上傳到ftp服務(wù)器上。

此任務(wù)涉及三個文件：變化代碼文件列表srt_changefileslist.txt、特性規(guī)則表propertyrole.txt、對比腳本change_propertylist.sh。

其中特性規(guī)則表propertyrole.txt可以根據(jù)測試所需適當(dāng)修改，如下所示：

以某備份軟件中的文件備份項目為例，除了影響特性列和文件名列，還額外添加了模塊列和開發(fā)負(fù)責(zé)人列。模塊列用于區(qū)分其他模塊擁有相同的特性，例如操作系統(tǒng)備份也有新建備份，啟動備份等功能特性。添加開發(fā)負(fù)責(zé)人列，可以在回歸測試用例執(zhí)行失敗時，快速找到對應(yīng)的開發(fā)負(fù)責(zé)人來處理問題。

對比腳本change_propertylist.sh中的邏輯如圖3所示，首先逐行讀取特性規(guī)則表propertyrole.txt，若是讀取不到下一行，則對比操作執(zhí)行完畢；若是還可以讀取到一行內(nèi)容，則將這一行字符以冒號為分隔符拆分成變量，特性規(guī)則表則被拆分成4個變量，分別是模塊變量、影響特性變量、文件名變量、開發(fā)負(fù)責(zé)人變量；將對比標(biāo)準(zhǔn)變量，即文件名變量與輸入文件srt_changefileslist.txt逐個比對，若比對不成功，則讀取特性規(guī)則表的下一行，若比對成功，則將對比結(jié)果變量，即影響特性變量輸出到指定文件中，命名為srt_propertylist.txt。

job3的構(gòu)建腳本如下所示：

與job2的處理邏輯一致，首先從ftp上下載job2產(chǎn)生的功能特性列表到本任務(wù)的工作空間；然后將標(biāo)簽規(guī)則表和對比腳本從測試代碼倉庫拷貝出來，存放到本任務(wù)的工作空間；最后將對比腳本轉(zhuǎn)化成可執(zhí)行文件，并運行，同時將運行結(jié)果上傳到ftp服務(wù)器上。

此任務(wù)同樣涉及三個文件：功能特性列表srt_propertylist.txt、標(biāo)簽規(guī)則表tagrole.txt、對比腳本change_suitetaglist.sh。

其中標(biāo)簽規(guī)則表tagrole.txt示例如下所示：

同樣做了適當(dāng)?shù)男薷淖冃?，除了影響特性與用例標(biāo)簽的基本對應(yīng)關(guān)系，還添加了影響特性的所屬模塊，用例標(biāo)簽的備注和測試負(fù)責(zé)人。

對比腳本change_suitetaglist.sh的處理邏輯與job2的對比腳本處理邏輯一致，如圖3所示，不過此時的對比標(biāo)準(zhǔn)變量則是模塊的影響特性，輸入文件是影響特性列表srt_propertylist.txt，對比結(jié)果變量是用例標(biāo)簽，最終輸出的是由用例標(biāo)簽列表組成的文件srt_suitetaglist.txt。

at任務(wù)是通過job3產(chǎn)生的標(biāo)簽作為構(gòu)建參數(shù)，在自動化運行節(jié)點環(huán)境上，帶參執(zhí)行調(diào)用命令，并將自動化用例的執(zhí)行日志和結(jié)果打印出來。

以上就是細粒度自動化回歸測試系統(tǒng)的內(nèi)部組成和實現(xiàn)細節(jié)，并以某一備份軟件項目為例，優(yōu)化細粒度回歸方法中的特性規(guī)則表和標(biāo)簽規(guī)則表，使之更加匹配項目，方便測試人員對此回歸測試系統(tǒng)的執(zhí)行與跟蹤。

以上所述，僅為本發(fā)明的具體實施方式，但本發(fā)明的保護范圍并不局限于此，任何熟悉本技術(shù)領(lǐng)域的技術(shù)人員在本發(fā)明揭露的技術(shù)范圍內(nèi)，可輕易想到各種等效的修改或替換，這些修改或替換都應(yīng)涵蓋在本發(fā)明的保護范圍之內(nèi)。因此，本發(fā)明的保護范圍應(yīng)以權(quán)利要求的保護范圍為準(zhǔn)。