引言
做過接口自動化測試的同學肯定都熟悉在全鏈路測試過程中，很多業務場景的完成并非由單一接口實現，而是由很多接口組成的一條鏈路實現。例如你在淘寶上購物場景。
不同于單接口測試，這種鏈路型的接口自動化測試，由于接口間有參數依賴關系，往往不能將鏈路中的接口入參固定寫死，而是要依賴“上游”的響應中的某個字段值，因此需要提取出來動態地傳遞給下個接口，如下圖。
解決鏈路間參數傳遞的問題可以簡化為解決接口間的參數傳遞問題。當然我上圖舉例是比較簡單的，下游對上游的依賴關系為1對1這種類型。實際業務場景中，更多的是多對一這種場景，即下游依賴上游的多個接口的返回結果。
當然，針對這個問題的解決方案，其實還是蠻多的。就以JMeter工具為例，它就提供了通過后置處理器的多種參數提取方法。
其解決方案是，通過正則、JSON Extracor等提取的結果作為變量，動態傳遞數值給下游（變量）使用。
當然，這種解決方案對于JMeter工具來說，是個不錯的解決方案，而且這個解決方案也具備普適性，就算你開發自己的接口測試框架，也是可以使用這種解決方案的（實際上，我在前東家參與研發的接口測試框架，當時解決接口間參數傳遞的問題就是借鑒的這種思路。開發了一個類似JMeter正則提取器的正則提取工具包，引用工具包可以允許你輸入要提取的字段key便可匹配到其字段值value，如果提取不到就返回默認值，如果有響應體中一個key存在多個value，則返回最后一個匹配到的value；下游接口則使用Java replace()方法替換掉請求體中的${xx}。）。
如果只追求可以用，這個方案沒問題。但是這個方案缺點就是接口用例開發效率比較低，增加了寫接口測試用例的成本。這也是我當時遇到的一個問題，大家寫自動化測試用例的時間很大一部分花在接口間參數提取和調試上。此外，這個方案也會增加維護成本，導致用例的“穩定性”比較低。是因為如果上游接口的響應體結構變化可能會影響提取結果，下游的接口請求體中的${xx}也需要手動維護。總結下來，自動化用例的維護和開發成本主要集中在接口間參數傳遞的維護上面。
是否有更優的解決方案呢？
試想一下，我們能否將整條鏈路可能使用到的字段集合作為一個池子，在上游接口的響應結果提取出key-value并扔到池子里。下游的接口request體模版化，以${xxx}表示需要替換的變量，利用模板引擎(例如Java的velocity/FreeMarker)將${xxx}替換成“池子”中存在的value。實現的簡圖如下。
動手做
下面就以Java語言實現為例，寫兩個方法A、B，且B依賴方法A的返回結果。
我們只需要開發 上下文類、模版組裝工具、模擬場景代碼即可。
import com.alibaba.fastjson.JSONObject;import org.apache.commons.beanutils.BeanUtils;import java.util.Map;?public class Client {?public static JSONObject login(){ JSONObject result = new JSONObject(); result.put("token","xsjkjdskdjsksjfksjfksjk"); return result; }?// pay接口，依賴login接口public static JSONObject pay(String request){ JSONObject result = new JSONObject();// 就簡單寫了if (request.contains("xsjkjdskdjsksjfksjfksjk")){ result.put("order", "122324434335"); result.put("status", "success"); } else { result.put("status", "fail"); }return result; }?// 場景模擬public static void main(String[] args) {?// 首先調用登陸接口 JSONObject loginResponse = login();// 步驟1.將結果寫入上下文 Context context = new Context(); context.setToken(loginResponse.getString("token"));// 創建一個pay接口的request模版String request = "{/"token/":/"${token}/"}";try {// 步驟2.利用Apache BeanUtils工具 BeanToMap方法 將上下文轉化為keyValues Map keyValues=null; keyValues = BeanUtils.describe(context);?// 步驟3.組裝模版，將${token}替換為上下文中的其key存在的valueString out_request = VelocityUtils.parse(request, keyValues); System.out.println("組裝request請求模版：" + out_request);?// 發起下單支付 JSONObject result = pay(out_request);// 打印接口返回結果 System.out.println("打印響應結果：" + result.toString());? }catch (Exception e){ System.out.println("異常退出"); } }}
這種方案的優點：
我們只需要care步驟1即可（將上游的響應結果寫入上下文），后面的組裝模版這些可以寫成同樣的工具，只需要傳入模版+上下文內容即可，無需關注其他，能大大節省自動化用例開發和維護的成本。
當然，本文只是拋磚引玉，如果有其他方案，也希望大家多多發散，多多交流溝通。
工具清單：
commons-beanutils
org.apache.velocity
com.alibaba.fastjson
org.projectlombok.lombok
往期推薦
多項目管理實踐論壇定于12月11-12日通過云端分享
經驗分享｜測試工程師轉型測試開發歷程
技術面必考：多線程、多進程
接口測試框架開發實踐2：接口自動化測試框架設計思路
接口自動化測試框架實踐1：接口測試概述
我在阿里做測開
