測試平台系列(17) 用例邏輯設計

很久沒有更新文章了，此時已經是23:23了，有些愧疚，因為自己最近交接的事情+生活的事情還是比較多的，是以到了晚上就沒有力氣來更新了。這裡就更加佩服WQRF這個「神一樣的男人」！

記得上次說到，我們制作了一個簡易的支援「HTTP」請求的頁面，實際上我們卻沒有把它用到用例之中。

我這個人有個很大的缺點，想到啥就做啥，經常是事先設計一個簡版，然後後續進行「打磨」，其實這樣對一個成熟的系統來說太不友好了，很多東西可能在設計的時候就太過于局限了。這裡不扯廢話了，直接進入主題吧。

思考過很多次，目前在公司制作的測試平台有個特點，就是不需要寫代碼就可以完成「接口測試用例」的編寫，隻不過礙于對大家的成長沒有太大的提升，是以我這次打算做到「相容」，如果你願意寫代碼，那麼你可以「導入代碼」或者線上編寫代碼，如果不想看到代碼，也可以采用「無碼模式」，并且還要做到随時轉換。

從設計上來說，用例以鍊路的形式執行，一個用例會有很多個「臨時變量」，通過它們，我們可以解決資料依賴，完成對整個流程的測試。由于筆者「畫圖能力」有限，是以這裡就不上圖了。一個用例分為幾個部分:

前置setUp操作

用例執行

後置tearDown操作

其中每個操作裡面都擁有很多個步驟(step)，每個step産生的資料都會在主用例的生命周期中儲存，達到資料互通的效果。

這裡的步驟可以是http請求，redis操作，sql語句，python代碼片段等等，每個步驟都可以擁有一個傳回值，通過傳回值解決資料依賴問題。

如果我們需要擷取使用者的「餘額」，那麼我們的用例将這樣去編寫:

先設計一個登入的測試用例:

用例名稱: 使用者登入

前置條件: 無

用例執行: 發送http請求，擷取token

後置條件: 無

斷言語句: 校驗http狀态碼等

編寫擷取使用者餘額的測試用例(主用例):

用例名稱: 擷取使用者餘額

前置條件:

step1: 使用者登入

記錄傳回值為step1，通過step1.token擷取到登入接口中的token資料

用例執行:

把body中的${step1.token}替換為真實的token，發送http請求。

後置條件:無

斷言語句: 校驗code和msg以及data字段中的資訊

初期看不懂不要緊，大概方向是這個樣子。主要也沒有圖檔，這是一個流程化的東西。

主要内容有:

存儲用例生命周期産生的變量

尋找請求字段中的變量并替換成真實資料

redis相關操作

sql相關操作

http相關操作

python代碼塊相關操作

上述的代碼相關的操作都是為了能将「資料和代碼」進行互相轉換，具體的構思還沒有完全想好。我喜歡邊寫邊想，不然我想得肯定不全，隻有寫的時候遇到問題了才能想好要怎麼做下一步。

給我思考的時間有限，我隻能走一步算一步了！

其實這裡我也覺得自己說的雲裡霧裡，還是等後續成品出來了，回過頭來看或者修改這篇文章吧！

這邊我們自己内定一套規則，凡是${變量}這種資料，都是需要替換的變量，可能由其他前置或常量産生，需要随時替換。這個規則要求變量盡量簡單，不要搞特殊符号。

我們用正則提取變量，這樣如果我們的sql語句裡面有變量的情況下，可以做到動态sql語句，如上圖。不過基于這，我們還需要提供一個變量池，用來存放這個用例的所有臨時變量。

這裡建立了一個變量池類，實際上維護了一個map，當然由于複雜場景下，可能會有「變量沖突」的情況，是以我們會在web頁面層去控制，去保證使用者「不使用重複的變量」。

今天的内容就先到這裡了，主要還是一個構思的問題。後面慢慢補全這些概念，使它越來越明朗。因為我現在也很懵逼，如果疑惑的話，可以等整個用例流程打通了再來「回顧」一下。

後續的話pity_basic會作為一個「tar包」，可在pypi下載下傳，單獨抽出這個包的主要原因還是為了支援「代碼」和「無碼」模式的切換。

pity_basic代碼位址