一、為什么做數據分離
前面實現了接口的請求到校驗
那么如果要對多個商品價格查詢，或者要做對不存在的商品查詢之類的反例呢
於是我們再次新建一條case，再次編寫了下腳本
那如果用例有10條，100條，那這些代碼就要寫10遍100遍，那么萬一它的地址改了，我們就要改10遍100遍。
我們觀察這條用例，發現與前面那條用例，只有skuids與預期結果不一樣，那么我們是否可以把那些一樣的部分提取出來，做成一個類似模板的東西，每次使用的時候套用呢？
二、數據分離實現
1、新建關鍵字（模板）
右鍵目錄，點擊New Resource
輸入Name，勾選Txt或者ROBOT，點擊OK
如前面導入庫的方式，導入RequestsLibrary
新增New User Keyword
輸入名字，點擊OK
如下圖，點擊該關鍵字，在右側腳本行把腳本寫入，其中${skuIds}， ${except_result}參數化
PS：另外養成良好習慣，在documentation處寫上對應的備注
以上我們關鍵字就建好了，要怎么使用呢
2、使用關鍵字
跟導入庫類似，要先導入剛才新建的resource，這樣才能使用resource下的關鍵字
回到suite，點擊suite，右側點擊Resource，輸入剛才新建的resource文件名（練習flow.txt），點OK
回到suite下的測試用例，輸入前面新增的user keyword名，可以看到是藍色字樣，后面紅色格子代表該方法必傳的參數
光標在方法名上，按ctrl，可以看到方法說明，可以看到我們前面的備注也有展示
把skuids和預期結果再方法后面輸入，執行case，可以發現與前面完整case執行的效果一樣。
所以我們多個case的時候，通過這種方式，數據分離后，數據只管對應的輸入輸出，具體執行過程封裝到方法中。
3、數據維護方式
數據分離實現了，那么數據部分有哪些維護方式呢：
1、一條數據一個case
如下圖，每個case對應一條數據
2、通過模板在一個case中寫所有數據
如下圖，通過Template，在一個case中維護所有數據
以上數據直接維護在RF的case文件中，除了這種方式，還可以把數據維護在其他地方
3、通過excel、csv等文件維護數據，腳本從文件讀取（這塊因為作用與前兩種方式一樣，先不寫，以后補充）
4、數據維護在數據庫中，腳本從數據庫獲取（這塊是下個方法的簡化版）
5、直接獲取手工測試后生成的數據，處理后作為測試數據（后面的文章里寫這塊）
四、其他簡單封裝
回到我們接口的例子中，一個項目接口執行多個，我們會發現，項目中大多數接口的請求頭、請求的過程都相似，因此我們再做一下封裝：
在項目下新建一個resource文件（接口基礎方法），導入庫RequestsLibrary
封裝方法：獲取默認headers
封裝請求方法：
返回碼異常，拋異常或者提示
返回的結果如果本身就報錯，也可以拋異常（視情況使用）
這樣我們就可以更專注於實際業務
當然前面的結果對比，也可以做下封裝（這部分比較復雜，可跳過）
判斷兩個json是否相等，先全文本對比，如果相等則正確，跳過，若不相等則進行深入判斷
通過遞歸，逐層進行判斷，當找到不同的值時，拋出路徑及不等的原因
