趙明明，周靜，補(bǔ)沖

（1 咪咕互動(dòng)娛樂(lè)有限公司，南京 210041；2 咪咕音樂(lè)有限公司，成都 610000）

在早期的軟件開(kāi)發(fā)過(guò)程中，測(cè)試常常由開(kāi)發(fā)人員自行完成，大家對(duì)測(cè)試的關(guān)注度和重要性認(rèn)識(shí)都不夠全面。直到1972年，美國(guó)北卡羅來(lái)納大學(xué)召開(kāi)了首屆軟件測(cè)試技術(shù)會(huì)議之后，軟件測(cè)試才作為軟件工程中的一個(gè)重要分支開(kāi)始逐步發(fā)展。1983年，Bill Hetzel在其著作中對(duì)軟件測(cè)試做了定義：“測(cè)試是以評(píng)價(jià)一個(gè)程序或者系統(tǒng)屬性為目標(biāo)的任何一種活動(dòng)”。隨著軟件系統(tǒng)越來(lái)越復(fù)雜，軟件工程師們普遍意識(shí)到，必須要借助工具才能對(duì)系統(tǒng)進(jìn)行快速而充分的測(cè)試，同時(shí)，伴隨著國(guó)外很多機(jī)構(gòu)和學(xué)者投入大量的研究工作，測(cè)試工具開(kāi)始逐漸受到人們的重視。

軟件自動(dòng)化測(cè)試的主要原理是針對(duì)測(cè)試人員對(duì)于手工測(cè)試所進(jìn)行的設(shè)計(jì)，通過(guò)一定的技術(shù)方法進(jìn)行自動(dòng)化測(cè)試程序編寫(xiě)以及運(yùn)行來(lái)達(dá)到模擬普通測(cè)試人員對(duì)軟件系統(tǒng)的操作過(guò)程，并且對(duì)結(jié)果進(jìn)行檢。常見(jiàn)的自動(dòng)化測(cè)試方法包括腳本錄制回放、數(shù)據(jù)驅(qū)動(dòng)、關(guān)鍵字驅(qū)動(dòng)。

1 自動(dòng)化測(cè)試工具分類

常見(jiàn)的自動(dòng)化測(cè)試工具包括QTP、RFT、Selenium、Watir、Phoenix Framework、Robot Framework（ 以下簡(jiǎn)稱RF）等。自動(dòng)化測(cè)試工具從功能實(shí)現(xiàn)上可以分為兩類：一類是提供了可重用的基礎(chǔ)自動(dòng)化測(cè)試能力，如Selenium、Watir等，它們可以進(jìn)行基礎(chǔ)的自動(dòng)化測(cè)試，比如打開(kāi)一個(gè)程序，模擬鼠標(biāo)點(diǎn)擊被測(cè)對(duì)象，最后驗(yàn)證被測(cè)對(duì)象的屬性以判斷程序的正確性。另外一類是提供了自動(dòng)化測(cè)試執(zhí)行和管理的能力，如Phoenix Framework、Robot Framework等，它們本身不具備基礎(chǔ)的自動(dòng)化測(cè)試能力，只是用于組織、管理和執(zhí)行那些獨(dú)立的自動(dòng)化測(cè)試用例，測(cè)試完成后統(tǒng)計(jì)測(cè)試結(jié)果，這類工具往往可以集成多個(gè)提供基礎(chǔ)自動(dòng)化測(cè)試能力的工具，以滿足不同類型的自動(dòng)化需求，使用較靈活，可擴(kuò)展性也更強(qiáng)。

Robot Framework最初是由Nokia Networks公司開(kāi)發(fā)的一個(gè)開(kāi)源自動(dòng)化測(cè)試框架，框架基于Python語(yǔ)言實(shí)現(xiàn)，包含豐富的測(cè)試工具及測(cè)試庫(kù)，同時(shí)具有很強(qiáng)的擴(kuò)展性。RF框架通過(guò)集成不同的測(cè)試工具，可以進(jìn)行各種自動(dòng)化測(cè)試，如Web自動(dòng)化測(cè)試、Http接口自動(dòng)化測(cè)試、移動(dòng)App的自動(dòng)化測(cè)試等。

2 軟件接口自動(dòng)化測(cè)試的重要性

分層的自動(dòng)化測(cè)試倡導(dǎo)在產(chǎn)品的不同階段（層次）都需要開(kāi)展自動(dòng)化測(cè)試，并且不同階段的投入比重有所不同。如Google的產(chǎn)品，70%的自動(dòng)化投入為單元測(cè)試，20%為接口測(cè)試，10%為UI層的自動(dòng)化測(cè)試。因?yàn)樵酵蠈樱_(kāi)展自動(dòng)化測(cè)試的成本越高，相反，越是底層的自動(dòng)化，收益卻越高。

不同階段的測(cè)試關(guān)注點(diǎn)不同，UI層關(guān)注的是頁(yè)面展示邏輯及頁(yè)面前端與服務(wù)端的集成驗(yàn)證，而服務(wù)層的接口測(cè)試更關(guān)注系統(tǒng)整體業(yè)務(wù)邏輯實(shí)現(xiàn)的驗(yàn)證，相對(duì)于UI層自動(dòng)化，服務(wù)層的接口測(cè)試自動(dòng)化更加穩(wěn)定，測(cè)試用例也更容易維護(hù)。因此，項(xiàng)目在開(kāi)展自動(dòng)化測(cè)試過(guò)程中，接口自動(dòng)化測(cè)試投入更多的人力，是重要而明智的。

3 RF在軟件接口自動(dòng)化測(cè)試中的應(yīng)用

3.1 自動(dòng)化工程結(jié)構(gòu)及測(cè)試詞庫(kù)的封裝

RIDE是Robot Framework提供的自動(dòng)化腳本管理工具，通過(guò)RIDE可以創(chuàng)建或?qū)胱詣?dòng)化工程、創(chuàng)建資源文件、創(chuàng)建測(cè)試套、編輯調(diào)試自動(dòng)化腳本、查看腳本執(zhí)行日志等。如圖1左側(cè)展示的AutoTestProject是我們某個(gè)項(xiàng)目的自動(dòng)化工程，工程根目錄下的TestCases、Keywords和Resources目錄分別用于存放測(cè)試套、測(cè)試詞庫(kù)資源文件、變量類資源文件。按照被測(cè)系統(tǒng)的特性，測(cè)試人員可以在TestCases目錄下新建多個(gè)子目錄，分別存放不同特性對(duì)應(yīng)的測(cè)試套。

根據(jù)不同的自動(dòng)化需求，測(cè)試人員在Keywords目錄下分別創(chuàng)建資源文件，用于保存不同類型的上層關(guān)鍵字，這類資源文件我們稱為詞庫(kù)，如Http請(qǐng)求詞庫(kù)、Redis操作詞庫(kù)、Kafka操作詞庫(kù)、數(shù)據(jù)庫(kù)操作詞庫(kù)等，如圖1所示。每個(gè)詞庫(kù)分別引用相關(guān)的開(kāi)源擴(kuò)展庫(kù)或自定義庫(kù)，獨(dú)立管理和維護(hù)。詞庫(kù)中的關(guān)鍵字由多個(gè)內(nèi)置庫(kù)或擴(kuò)展庫(kù)或自定義庫(kù)中的底層關(guān)鍵字組合而成，如圖1右側(cè)展示的是數(shù)據(jù)庫(kù)操作詞庫(kù)中數(shù)據(jù)庫(kù)校驗(yàn)關(guān)鍵字的構(gòu)成，這類滿足RF語(yǔ)法由底層關(guān)鍵字組合而成的關(guān)鍵字我們稱為上層關(guān)鍵字。在項(xiàng)目自動(dòng)化實(shí)施過(guò)程中，底層自定義關(guān)鍵字的開(kāi)發(fā)和上層關(guān)鍵字的封裝，都由具備一定代碼基礎(chǔ)的測(cè)試開(kāi)發(fā)人員完成，普通的測(cè)試人員只需要了解上層關(guān)鍵字的用法，即可完成自動(dòng)化腳本的寫(xiě)作。

3.2 數(shù)據(jù)驅(qū)動(dòng)的自動(dòng)化腳本實(shí)現(xiàn)

圖1 自動(dòng)化工程結(jié)構(gòu)及測(cè)試詞庫(kù)關(guān)鍵字的構(gòu)成

開(kāi)展接口自動(dòng)化測(cè)試的過(guò)程中，一個(gè)接口往往定義一個(gè)測(cè)試套（由一組自動(dòng)化腳本構(gòu)成），測(cè)試套下包含該接口所有的自動(dòng)化腳本。由于接口的測(cè)試報(bào)文結(jié)構(gòu)基本是固定的，不同的腳本往往只是修改報(bào)文中某個(gè)或某幾個(gè)參數(shù)的值，如果在每個(gè)腳本中都帶上測(cè)試報(bào)文，就會(huì)造成數(shù)據(jù)冗余、維護(hù)成本高的問(wèn)題，尤其在報(bào)文結(jié)構(gòu)復(fù)雜，腳本數(shù)量多的情況下格外突出。為此，我們的自動(dòng)化腳本在實(shí)現(xiàn)上使用數(shù)據(jù)驅(qū)動(dòng)的模式，將腳本與測(cè)試報(bào)文分離。首先，在測(cè)試套同級(jí)目錄下保存一個(gè).conf后綴的文本文件，文件中保存一條完整的測(cè)試報(bào)文，自動(dòng)化腳本先從該文件中讀取報(bào)文，再根據(jù)需要修改報(bào)文中某個(gè)或某幾個(gè)字段的值，然后將請(qǐng)求發(fā)送給被測(cè)系統(tǒng)并進(jìn)行結(jié)果校驗(yàn)。圖2左側(cè)展示的是一個(gè)腳本示例，其中${Req_Data_File}變量指向了.conf后綴的文件，我們建議將其定義為測(cè)試套變量，變量值使用RF的內(nèi)置變量，例如${CURDIR}${/}訂單查詢接口.conf，可以自動(dòng)適配Windows和Linux操作系統(tǒng)。

3.3 接口參數(shù)校驗(yàn)場(chǎng)景的自動(dòng)化腳本實(shí)現(xiàn)

接口測(cè)試存在很多參數(shù)校驗(yàn)的場(chǎng)景，例如字段為空、字段超長(zhǎng)、字段取值錯(cuò)誤等，這類腳本往往占據(jù)全部自動(dòng)化腳本的50%以上。而參數(shù)校驗(yàn)類的測(cè)試用例或自動(dòng)化腳本步驟基本一致，唯一的區(qū)別就是響應(yīng)結(jié)果中錯(cuò)誤碼和錯(cuò)誤提示的差異，鑒于此，我們對(duì)參數(shù)校驗(yàn)類的測(cè)試用例和自動(dòng)化腳本的寫(xiě)作方法進(jìn)行了優(yōu)化。

測(cè)試用例的設(shè)計(jì)階段，針對(duì)某個(gè)接口各種參數(shù)校驗(yàn)的場(chǎng)景，整合為一個(gè)測(cè)試用例。針對(duì)該測(cè)試用例，在測(cè)試套同級(jí)目錄下新增.error后綴的文本文件。有多少個(gè)參數(shù)校驗(yàn)場(chǎng)景，該文件就包含多少行，每行的第一列表示要校驗(yàn)的場(chǎng)景，如appId為空、appId取值錯(cuò)誤、報(bào)文缺少appId等，如涉及多個(gè)參數(shù)的校驗(yàn)，使用英文逗號(hào)隔開(kāi)，校驗(yàn)參數(shù)使用JsonPath語(yǔ)法描述，例如$.appId：100001，$.userId：20001，從第二列開(kāi)始表示該場(chǎng)景下要校驗(yàn)的內(nèi)容，例如錯(cuò)誤碼、錯(cuò)誤提示等，多列之間使用tab鍵分隔。

自動(dòng)化腳本寫(xiě)作階段，首先從.conf后綴的文件中獲取一條測(cè)試報(bào)文，然后循環(huán)從.error文件中獲取要校驗(yàn)的場(chǎng)景，解析后替換到報(bào)文中，并發(fā)送請(qǐng)求到被測(cè)系統(tǒng)，最后進(jìn)行錯(cuò)誤碼、錯(cuò)誤提示等的校驗(yàn)。經(jīng)過(guò)關(guān)鍵字封裝，最終的自動(dòng)化腳本僅包含圖2右側(cè)展示的兩個(gè)步驟。從項(xiàng)目實(shí)施經(jīng)驗(yàn)看，經(jīng)過(guò)以上優(yōu)化，接口自動(dòng)化腳本的數(shù)量可以減少50%以上，不僅提升了腳本寫(xiě)作效率，也降低了測(cè)試人員后期維護(hù)自動(dòng)化腳本的工作量。

3.4 自動(dòng)化腳本與測(cè)試環(huán)境的解耦

產(chǎn)品迭代開(kāi)發(fā)過(guò)程中，可能會(huì)有多套被測(cè)環(huán)境，如果自動(dòng)化腳本不進(jìn)行相關(guān)約束，那么切換被測(cè)環(huán)境必然會(huì)導(dǎo)致大量的腳本執(zhí)行失敗，此時(shí)又需要投入測(cè)試人力修改腳本，這個(gè)問(wèn)題經(jīng)常會(huì)影響到項(xiàng)目自動(dòng)化測(cè)試開(kāi)展的及時(shí)性。為此，我們采用以下方法，解決了切換被測(cè)環(huán)境引起的腳本修改問(wèn)題。

在項(xiàng)目自動(dòng)化腳本寫(xiě)作過(guò)程中，和被測(cè)環(huán)境相關(guān)的信息，必須全部定義為變量，存放在資源文件中，自動(dòng)化腳本引用資源文件中定義的變量，不能直接使用被測(cè)環(huán)境的信息。如針對(duì)服務(wù)端URL地址，我們會(huì)定義變量 ${G_URL}=http：//10.138.10.10：8080， 自 動(dòng) 化腳本發(fā)送請(qǐng)求關(guān)鍵字的參數(shù)必須使用${G_URL}變量，不能寫(xiě)死http：//10.138.10.10：8080。由于可能存在多套被測(cè)環(huán)境，因此，我們?cè)赗esources目錄下新建多個(gè)資源文件，如Test_Env_Alpha.robot、Test_Env_Beta.robot、Test_Env_Gamma.robot，分別代表不同的測(cè)試環(huán)境，如圖1所示，這些文件中存放自動(dòng)化腳本中引用的與被測(cè)環(huán)境相關(guān)的變量，其中變量名完全一致，區(qū)別在于變量值不同。最后我們新增資源文件Test_Env_Cur.robot，該文件引用當(dāng)前生效的被測(cè)環(huán)境資源文件，如Test_Env_Alpha.robot，所有的測(cè)試套都引用Test_Env_Cur.robot，經(jīng)過(guò)以上處理，如果需要切換測(cè)試環(huán)境，僅需要修改Test_Env_Cur.robot文件中引用的資源文件名即可，自動(dòng)化腳本不需要做任何修改，實(shí)現(xiàn)了自動(dòng)化腳本與測(cè)試環(huán)境的解耦。

圖2 數(shù)據(jù)驅(qū)動(dòng)的自動(dòng)化腳本實(shí)現(xiàn)及接口參數(shù)校驗(yàn)?zāi)_本實(shí)現(xiàn)

3.5 測(cè)試用例與自動(dòng)化腳本的互相轉(zhuǎn)換

很多公司都有自己的測(cè)試用例管理系統(tǒng)，支持Excel文檔的導(dǎo)入導(dǎo)出。產(chǎn)品迭代開(kāi)發(fā)過(guò)程中，測(cè)試人員往往都是根據(jù)需求先梳理Excel格式的測(cè)試用例，然后導(dǎo)入用例管理系統(tǒng)，最后根據(jù)測(cè)試用例描述，完成自動(dòng)化腳本的寫(xiě)作。

為了提升自動(dòng)化腳本的寫(xiě)作效率，我們對(duì)RIDE工具做了定制開(kāi)發(fā)，支持將Excel格式的測(cè)試用例與自動(dòng)化腳本互相轉(zhuǎn)換。如圖3所示，Tools菜單下新增了Convert Excel To Test Suite功能，單擊后選擇某個(gè)測(cè)試用例Excel文檔，工具會(huì)按照Excel文檔的目錄結(jié)構(gòu)自動(dòng)生成同樣目錄結(jié)構(gòu)的測(cè)試套文件，并將測(cè)試用例名稱、編號(hào)、測(cè)試步驟等信息寫(xiě)入自動(dòng)化腳本的Documentation部分，測(cè)試人員只需要添加腳本步驟即可完成自動(dòng)化腳本的寫(xiě)作，省去了很多從測(cè)試用例文檔到測(cè)試套的復(fù)制粘貼工作。

相反的，只要測(cè)試人員按照規(guī)范要求，在自動(dòng)化腳本的Documentation中寫(xiě)入用例名稱、編號(hào)、測(cè)試步驟等信息，右鍵自動(dòng)化工程的TestCases目錄或其子目錄，然后選擇Convert to Test Case，就可以將選中目錄下的測(cè)試套轉(zhuǎn)換為Excel格式的測(cè)試用例文檔，如圖3所示，轉(zhuǎn)換生成的文檔可直接導(dǎo)入測(cè)試用例管理系統(tǒng)。

測(cè)試用例轉(zhuǎn)換為測(cè)試套的功能，一定程度上提升了自動(dòng)化腳本的寫(xiě)作效率；測(cè)試套轉(zhuǎn)換為測(cè)試用例的功能，用于自動(dòng)化腳本先于測(cè)試用例之前完成，可以由自動(dòng)化腳本轉(zhuǎn)換生成一份測(cè)試用例，方便后續(xù)測(cè)試用例的管理和維護(hù)。

3.6 自動(dòng)化腳本規(guī)范問(wèn)題靜態(tài)檢查

為了提升RF自動(dòng)化腳本的質(zhì)量，我們會(huì)要求測(cè)試人員按照規(guī)范寫(xiě)作自動(dòng)化腳本，但是，由于人員能力參差不齊，對(duì)規(guī)范的掌握程度也不盡相同，所以測(cè)試人員輸出的自動(dòng)化腳本往往需要經(jīng)過(guò)多次評(píng)審和優(yōu)化才能達(dá)到要求。為了提早發(fā)現(xiàn)腳本規(guī)范問(wèn)題、提升腳本評(píng)審的效率，我們將一些常見(jiàn)的腳本問(wèn)題歸類，開(kāi)發(fā)了相應(yīng)的規(guī)范檢查工具，用于自動(dòng)識(shí)別腳本中存在的問(wèn)題。測(cè)試人員在提交腳本前，先主動(dòng)執(zhí)行靜態(tài)檢查，就可以提前識(shí)別出一些不符合規(guī)范的問(wèn)題并加以修改。

圖3 測(cè)試用例與自動(dòng)化腳本的互相轉(zhuǎn)換

圖4 自動(dòng)化腳本靜態(tài)檢查工具及報(bào)告

檢查規(guī)則分為強(qiáng)制和建議兩種，目前實(shí)現(xiàn)的如圖4所示的8條，其中每條檢查規(guī)則都對(duì)應(yīng)一條腳本寫(xiě)作規(guī)范。如我們的規(guī)范要求自動(dòng)化腳本不能使用Sleep關(guān)鍵字進(jìn)行強(qiáng)制等待（除非有特殊的業(yè)務(wù)要求），規(guī)則2會(huì)掃描所有的測(cè)試套文件，識(shí)別出使用了Sleep關(guān)鍵字的腳本步驟；規(guī)范要求自動(dòng)化腳本必須包含結(jié)果校驗(yàn)，規(guī)則4會(huì)掃描所有的測(cè)試套文件，識(shí)別出缺少結(jié)果校驗(yàn)步驟的自動(dòng)化腳本。最后，檢查工具會(huì)按照規(guī)則輸出問(wèn)題統(tǒng)計(jì)報(bào)告，并給出詳細(xì)的問(wèn)題位置及文件路徑。從項(xiàng)目實(shí)施經(jīng)驗(yàn)看，檢查工具使用前期會(huì)發(fā)現(xiàn)很多問(wèn)題，如圖4是我們一個(gè)項(xiàng)目第一次掃描的結(jié)果，上千個(gè)同類問(wèn)題，如果依賴人工評(píng)審，需要耗費(fèi)的時(shí)間難以估量，隨著腳本的不斷優(yōu)化及測(cè)試人員對(duì)規(guī)范的掌握，相關(guān)問(wèn)題會(huì)越來(lái)越少。這些檢查規(guī)則的自動(dòng)化可以有效牽引測(cè)試人員提升自動(dòng)化腳本的質(zhì)量，我們也在積極擴(kuò)展實(shí)現(xiàn)其它的檢查規(guī)則，進(jìn)而不斷提升團(tuán)隊(duì)的測(cè)試效率。

4 結(jié)束語(yǔ)

Robot Framework是一個(gè)開(kāi)源的自動(dòng)化測(cè)試框架，基于關(guān)鍵字驅(qū)動(dòng)，使用靈活，可擴(kuò)展性良好。經(jīng)過(guò)我們的優(yōu)化，該框架既具備關(guān)鍵字驅(qū)動(dòng)的靈活性和可重用性，又具備數(shù)據(jù)驅(qū)動(dòng)框架的低耦合，很大程度的降低了開(kāi)展自動(dòng)化測(cè)試的成本投入。從真實(shí)的項(xiàng)目實(shí)施情況看，接口自動(dòng)化覆蓋率可以達(dá)到100%，在小步快跑、快速迭代的大趨勢(shì)下，可以有效縮短回歸測(cè)試時(shí)長(zhǎng)，提升自動(dòng)化測(cè)試的價(jià)值，本文所闡述的方法很值得在相關(guān)軟件測(cè)試領(lǐng)域推廣使用。