HttpRunner 實現參數化數據驅動機制
全文總長約一萬字，你確定現在有心思看么
哎，還真走了啊，走之前先點個贊哇
背景
在自動化測試中，經常會遇到如下場景：
1、測試搜索功能，只有一個搜索輸入框，但有10種不同類型的搜索關鍵字；
2、測試賬號登錄功能，需要輸入用戶名和密碼，按照等價類劃分後有20種組合情況。
這裡只是隨意找了兩個典型的例子，相信大家都有遇到過很多類似的場景。總結下來，就是在我們的自動化測試腳本中存在參數，並且我們需要採用不同的參數去運行。
經過概括，參數基本上分為兩種類型：
然後，對於參數而言，我們可能具有一個參數列表，在腳本運行時需要按照不同的規則去取值，例如順序取值、隨機取值、循環取值等等。
對於這一塊兒，沒有太多新的概念，這就是典型的參數化和數據驅動。遺憾的是，當前並未支持該功能特性。
考慮到該需求的普遍性，並且近期提到該需求的的人也越來越多（issue #74, issue #87, issue #88, issue #97），因此趁著春節假期的空閑時間，決定優先實現下。
經過前面的場景分析，我們的目標已經很明確了，接下來就是如何實現的問題了。
借鑒 LoadRunner 的數據參數化
要造一個輪子，最好是先看下現有知名輪子的實現機制。之前有用過一段時間的 LoadRunner，對其參數化機制印象蠻深的，雖然它是性能測試工具，但在腳本參數化方面是通用的。
我們先看下在 LoadRunner 中是如何實現參數化的。
在 LoadRunner 中，可以在腳本中創建一個參數，然後參數會保存到一個的文件中，例如下圖中的。
在文件中，是採用表格的形式來存儲參數值，結構與基本一致。
對於單個獨立參數，可以將參數列表保存在一個單獨的文件中，第一行為參數名稱，後續每一行為一個參數值。例如本文背景介紹中的第一類場景，數據存儲形式如下所示：
然後對於參數的取值方式，可以通過和進行配置。
的可選方式有：
的可選方式有：
而且，可以通過對這兩種方式進行組合，配製出9種參數化方式。
另外，因為 LoadRunner 本身是性能測試工具，具有長時間運行的需求，假如選擇為，同時設置為，那麼就會涉及到參數用完的情況。在該種情況下，可通過配置項實現如下選擇：
對於多個具有關聯性的參數，可以將關聯參數列表保存在一個文件中，第一行為參數名稱，後續每一行為一個參數值，參數之間採用逗號進行分隔。例如本文背景介紹中的第二類場景，數據存儲形式如下所示：
對於參數的取值方式，與上面單個獨立參數的取值方式基本相同。差異在於，我們可以只配置一個參數（例如）的取值方式，然後其它參數（例如）的取值方式選擇為。如此一來，我們就可以保證參數化時的數據關聯性。
LoadRunner 的參數化機制就回顧到這裡，可以看出，其功能還是很強大的，使用也十分靈活。
設計思路演變歷程
現在再回到我們的 HttpRunner，要如何來實現參數化機制呢？
因為 LoadRunner 的參數化機制比較完善，用戶群體也很大，因此我在腦海里最先冒出的想法就是照抄 LoadRunner，將 LoadRunner 在 GUI 中配置的內容在 HttpRunner 中通過來進行配置。
按照這個思路，在 HttpRunner 的 config 中，就要有一塊兒地方用來進行參數化配置，暫且設定為吧。然後，對於每一個參數，其參數列表要單獨存放在文件中，考慮到LoadRunner中的文件基本就是格式，因此可以約定採用大眾更熟悉的文件來存儲參數；在腳本中，要指定參數變數從哪個文件中取值，那麼就需要設定一個，用於指定對應的參數文件路徑。接下來，要實現取值規則的配置，例如是順序取值還是隨機取值，那麼就需要設定和。
根據該設想，在測試用例文件中，數據參數化將描述為如下形式：
這個想法基本可行，但就是感覺配置項有些繁瑣，我們可以嘗試再對其進行簡化。
首先，比較明顯的，針對每個參數都要配置和，雖然從功能上來說比較豐富，但是對於用戶來說，這些功能並不都是必須的。特別是這個參數，絕大多數情況下我們的需求應該都是採用，即每次腳本再次運行時更新參數值。因此，我們可以去除這個配置項，默認都是採用的方式。
經過第一輪簡化，配置描述方式變為如下形式：
然後，我們可以看到和這兩個參數，它們有關聯性，但卻各自單獨進行了配置；而且對於有關聯性的參數，除了需要對第一個參數配置取值方式外，其它參數的應該總是為，這樣描述就顯得比較累贅了。
既然是有關聯性的參數，那就放在一起吧，參數名稱可以採用約定的符號進行分離。考慮到參數變數名稱通常包含字母、數字和下劃線，同時要兼顧中對字元的限制，因此選擇短橫線（）作為分隔符吧。
經過第二輪簡化，配置描述方式變為如下形式：
接著，我們再看下參數。因為我們測試用例中的參數名稱必須與數據源進行綁定，因此這一項信息是不可少的。但是在描述形式上，還是會感覺有些繁瑣。再一想，既然我們本來就要指定參數名稱，那何必不將參數名稱約定為文件名稱呢？
例如，對於參數，我們可以將其數據源文件名稱約定為；對於參數和，我們可以將其數據源文件名稱約定為；然後，再約定數據源文件需要與當前測試用例文件放置在同一個目錄。
經過第三輪簡化，配置描述方式變為如下形式：
同時該用例文件同級目錄下的數據源文件名稱為和。
現在，我們就只剩下一個配置項了。既然是只剩一項，那就也省略配置項名稱吧。
最終，我們的配置描述方式變為：
不過，我們還忽略了一個信息，那就是腳本的運行次數。假如參數取值都是採用的方式，那麼我們可以將不同組參數進行笛卡爾積的組合，這是一個有限次數，可以作為自動化測試運行終止的條件；但如果參數取值採用的方式，即每次都是在參數列表裡面隨機取值，那麼就不好界定自動化測試運行終止的條件了，我們只能手動進行終止，或者事先指定運行的總次數，不管是採用哪種方式，都會比較麻煩。
針對參數取值採用方式的這個問題，我們不妨換個思路。從數據驅動的角度來看，我們期望在自動化測試時能遍曆數據源文件中的所有數據，那麼重複採用相同參數進行測試的意義就不大了。因此，在選擇的取值方式時，我們可以先將參數列表進行亂序排序，然後採用順序的方式進行遍歷；對於存在多組參數的情況，也可以實現亂序排序後再進行笛卡爾積的組合方式了。
到此為止，我們的參數化配置方式應該算是十分簡潔了，而且在功能上也能滿足常規參數化的配置需求。
最後，我們再回過頭來看腳本參數化設計思路的演變歷程，基本上都可以概括為，這的確也是崇尚和遵循的準則。
開發實現
設計思路理順了，實現起來就比較簡單了，點擊此處查看相關代碼，就會發現實際的代碼量並不多。
在這裡我就只挑幾個典型的點講下。
數據源格式約定
既然是參數化，那麼肯定會存在數據源的問題，我們約定採用文件格式來存儲參數列表。同時，在同一個測試場景中可能會存在多個參數的情況，為了降低問題的複雜度，我們可以約定獨立參數存放在獨立的文件中，多個具有關聯性的參數存放在一個文件中。另外，我們同時約定在文件中的第一行必須為參數名稱，並且要與文件名保持一致；從第二行開始為參數值，每個值佔一行。
例如，這種獨立的參數就可以存放在中，內容形式如下：
和這種具有關聯性的參數就可以存放在中，內容形式如下：
csv 解析器
數據源的格式約定好了，我們要想進行讀取，那麼就得有一個對應的解析器。因為我們後續想要遍歷每一行數據，並且還會涉及到多個參數進行組合的情況，因此我們希望解析出來的每一行數據應該同時包含參數名稱和參數值。
於是，我們的數據結構就約定採用的形式。即每一個文件解析後會得到一個列表（list），而列表中的每一個元素為一個字典結構（dict），對應著一行數據的參數名稱和參數值。具體實現的代碼函數為。
例如，上面的經過解析，會生成如下形式的數據結構。
這裡還會涉及到一個問題，就是參數取值順序。
在測試用例中，我們會配置參數的取值順序，是要順序取值（）還是亂序隨機取值（）。對於順序的情況沒啥好說的，默認從文件中讀取出的內容就是順序的；對於隨機取值，更確切地說，應該是亂序取值，我們需要進行一次亂序排序，實現起來也很簡單，使用函數即可。
多個參數的組合
然後，對於多個參數的情況，為了組合出所有可能的情況，我們就需要用到笛卡爾積的概念。直接看例子可能會更好理解些。
例如我們在用例場景中具有三個參數，為獨立參數，參數列表為[1, 2]；和為關聯參數，參數列表為[[111,112], [121,122]]；經過解析後，得到的數據分別為：
那麼經過笛卡爾積，就可以組合出4種情況，組合後的結果應該為：
這裡需要強調的是，多個參數經過笛卡爾積運算轉換後，仍然是的數據結構，列表中的每一個字典（dict）代表著參數的一種組合情況。
參數化數據驅動
現在，我們已經實現了在測試用例文件中對參數進行配置，從數據源文件中解析出參數列表，並且生成所有可能的組合情況。最後還差一步，就是如何使用參數值來驅動測試用例的執行。
聽上去很高大上，但實際卻異常簡單，直接對照著代碼來說吧。
對於每一組參數組合情況來說，我們完全可以將其視為當前用例集運行時定義的變數值。而在 HttpRunner 中每一次運行測試用例集的時候都需要對做一次初始化，裡面會用到定義的變數（即），那麼，我們完全可以在每次初始化的時候將組合好的參數作為變數傳進去，假如存在同名的變數，就進行覆蓋。
這樣一來，我們就可以使用所有的參數組合情況來依次驅動測試用例的執行，並且每次執行時都採用了不同的參數，從而也就實現了參數化數據驅動的目的。
效果展示
最後我們再來看下實際的運行效果吧。
假設我們有一個獲取token的介面，我們需要使用 user_agent 和 app_version 這兩個參數來進行參數化數據驅動。
YAML 測試用例的描述形式如下所示：
其中，user_agent 和 app_version 的數據源列表分別為：
那麼，經過笛卡爾積組合，應該總共有6種參數組合情況，並且 user_agent 為亂序取值，app_version 為順序取值。
最終的測試結果如下所示：
至此，我們就已經實現了參數化數據驅動的需求。對於測試用例中參數的描述形式，大家要是發現還有更加簡潔優雅的方式，歡迎反饋給我。
最後，本文發表於 2018 年大年初一，祝大家新年快樂，狗年旺旺旺！
TAG:DebugTalk |