凡是涉及一點點有接口關聯的，都可能下一個接口需要上一個接口的某個返回值作為入參，最直接的例子，就是登錄依賴。用接口做業務性的測試，也絕對離不開接口依賴的，業務都是一系列接口串聯的結果，有時候一個接口操作的結果，也需另外的接口驗證，舉幾個例子，以某個文章的評論用例為例，我們選取幾個評論的冒煙用例來看看吧。
- 拉取評論列表（list接口）
- 增加一條評論（add接口）
- 將評論置頂及取消置頂（stick接口）
- 刪除評論（delete接口）
用例1很簡單，僅是個數據讀接口沒有做寫操作，做一些基本的響應校驗就OK了，這個接口不在我們的討論范圍。
再看用例2，增加評論是有個寫操作的，對於這一操作，如果用手工測試，完整校驗點應該是，1）增加評論成功 2）增加的這條評論在評論列表里（且在第一位，考慮到有置頂情況，那就在第2位），所以，這里的最基本的校驗點涉及兩個接口，第1個接口（add接口）依賴第2個接口（list接口）做校驗。事實上，這個評論id還需給其他接口使用，以達到數據清理及重復利用的效果，這個也不在本文的討論范圍。
當然，這些接口，還有個更全局的依賴，用戶登錄。用戶登錄的依賴在之前的文章已經有提到過，放在suite setup里是不錯的選擇：接口登錄保持
既然是需要一個用例里面有多個接口，我們希望代碼越少越好，最好是一行解決一個接口。這是反向思維，正向的思維是：接口類型固定時，總是有規律可循的，所以當很多很多代碼開始重復時，我們要抽取成一個比較通用的關鍵字，以達到精簡用例的效果，用例清晰明了，寫起來也簡單，擴展容易，維護工作量異常小。這有點像代碼重構的思想。
接口測試用一句話概括就是，用什么樣的測試數據，測哪個接口，得到的怎樣的響應。重點明確了，用例中，接口的基本要素只有1、待測接口 2、待測接口的入參 3、響應數據。一個關鍵字如果滿足了這些要素，也就能達到我們想要的效果。
來看一例：
在此用例中，mobile_post關鍵字將一些接口調用的細節全都掩蓋掉了，其中包括但不限於：
- 請求的host及一些固定的參數
- 接口入參反向update到入參模板里
- 接口數字簽名
- 目標返回值的分拆及獲取
該關鍵字的必需參數只有1、待測接口名 和 2、待測接口入參，其他一些只做為可選參數，有更多的輸入自由，也使得關鍵字的可重用性更高。然后，一個接口就一行腳本，斷言在關鍵字外做，也是為了提高寫用例的靈活性。實踐證明，使用這個關鍵字后，寫用例速度明顯提高了。該關鍵字中用到的更底層關鍵字，也盡量用rf的關鍵字在寫，rf的日志打印比較好，遇到問題方便日志追蹤。
這里重點講一下接口的入參模板：
1、為什么要有入參模板
百度結果中有好多告訴你怎么用rf做接口測試的文章，如何創建session，如何用create dictionary關鍵字構建測試數據，如何傳header，如何做一個post接口，如何做一個get接口。——那只是個demo
我們做自動化時是在做工程，不是在做demo，也就是那些解釋性的腳本，底層一步一步怎么實現的（header怎么傳，data怎么拼接，該用post還是get），已經不再是重點，我們更應該關注的，是用例本身，怎么寫用例能更好的覆蓋到驗證點，怎么處理測試數據，怎么寫好可維護性的用例，怎么去組織好用例結構，套件結構，工程結構，怎么讓用例有更好的環境（測試，預發，生產）移植性。
扯遠了，回到入參模板。實際中，單單一個接口的入參就多得不敢想象，十幾個，或更多，某個用例中這十幾個入參實際起作用的也許就3-4個。有些接口其實也不止一層json那么簡單，也有某個字段有多層結構的。這個時候，最好是有個模板，模板大概長這樣：
接口A：{key1:value1, key2:value2} #接口A及其入參
接口B：{key3:value3, key4:value4, key5:value5, key6:value6}
接口C：{key7:value7, key8:{Key81:value81}, key9:[value91, value92, value93]}
...
2、入參模板rf中怎么實現
參考了一些其他做接口測試的同仁，有用數據庫實現的，也有用初始化配置文件的。rf在這方面考慮還是蠻齊全，我用的是py變量文件vars.py，當配置文件用，另外可能還需要有一個輔助的py關鍵字文件common.py。
1）大致長這樣的vars.py
MOBILE_DEFAULT_VALUE={
#comment
"comment.add":{"v":"1.0","data":{"articleid":"1","content":u"大盤啥時候能好起來我就給好評","targetid":"","commentid":"",,"uid":"1"}}, #增加文章評論接口
"comment.list":{"v":"2.0","data":{"articleid":"","cursor":"-1","count":"20"}}, #獲取文章評論列表
"comment.delete":{"v":"1.0","data":{"commentid":"","uid":""}}#刪除評論
}
2）大致長這樣的common.py
# -*- coding:utf-8 -*-
import vars
def mobile_paras(apiName,dataStr='{}'):
'''
參數：待測接口名apiName 待測接口入參 dataStr
示例: ${return} | mobile_paras | user/sms | {"phone":"66666666"}
返回：接口版本號 及最終入參
'''
try:
datadict = vars.MOBILE_DEFAULT_VALUE[apiName]['data']
apiVersion = vars.MOBILE_DEFAULT_VALUE[apiName]['v']
except KeyError:
print u"不存在的api名，請重新輸入"
if dataStr == '':
dataStr = '{}'
dataNew = eval(dataStr)
datadictCopy = datadict.copy()
datadictCopy.update(dataNew)#這句是關鍵,把數據update到模板取到的data中去
return [apiVersion,datadictCopy]
分離變量文件和關鍵字文件是rf的規定，也是個好的編碼習慣，以后vars.py中還要擴展其他更多更多的變量，當然common.py中也不可避免增加一些rf不擅長但python擅長處理的關鍵字。
3）大致長這樣的mobile_post關鍵字：
最后，用一個rf的關鍵字，把一些關鍵數據組一組，該簽名的簽名，該登錄的登錄，該返回的返回：
再回到第1張圖，待測接口comment.add，目標待傳參數in_data為{"articleid":"3215","content":"大盤啥時候能好起來我就給好評","targetid":"","commentid":"","uid":"101123"}，用例傳參{"articleid":"3215","uid":"101123"}，其他參數在模板中已默認，實際傳參如目標待傳。
4）結構：
vars.py及common.py放同一級目錄，以如下方式導入含有mobile_post的resource文件中
以上，僅提供思路。有些同學的接口入參及調用都很簡單，3行內可以搞定一個接口，也可不必做得這么麻煩。在工程化的道路上，只有實踐出來的路才是最好的路。