資訊專欄INFORMATION COLUMN
摘要：解決鏈路間參數(shù)傳遞的問(wèn)題可以簡(jiǎn)化為解決接口間的參數(shù)傳遞問(wèn)題。當(dāng)然，針對(duì)這個(gè)問(wèn)題的解決方案，其實(shí)還是蠻多的。總結(jié)下來(lái)，自動(dòng)化用例的維護(hù)和開(kāi)發(fā)成本主要集中在接口間參數(shù)傳遞的維護(hù)上面。
做過(guò)接口自動(dòng)化測(cè)試的同學(xué)肯定都熟悉在全鏈路測(cè)試過(guò)程中，很多業(yè)務(wù)場(chǎng)景的完成并非由單一接口實(shí)現(xiàn)，而是由很多接口組成的一條鏈路實(shí)現(xiàn)。例如你在淘寶上購(gòu)物場(chǎng)景。
不同于單接口測(cè)試，這種鏈路型的接口自動(dòng)化測(cè)試，由于接口間有參數(shù)依賴關(guān)系，往往不能將鏈路中的接口入?yún)⒐潭▽?xiě)死，而是要依賴“上游”的響應(yīng)中的某個(gè)字段值，因此需要提取出來(lái)動(dòng)態(tài)地傳遞給下個(gè)接口，如下圖。
解決鏈路間參數(shù)傳遞的問(wèn)題可以簡(jiǎn)化為解決接口間的參數(shù)傳遞問(wèn)題。當(dāng)然我上圖舉例是比較簡(jiǎn)單的，下游對(duì)上游的依賴關(guān)系為1對(duì)1這種類型。實(shí)際業(yè)務(wù)場(chǎng)景中，更多的是多對(duì)一這種場(chǎng)景，即下游依賴上游的多個(gè)接口的返回結(jié)果。
當(dāng)然，針對(duì)這個(gè)問(wèn)題的解決方案，其實(shí)還是蠻多的。就以JMeter工具為例，它就提供了通過(guò)后置處理器的多種參數(shù)提取方法。
其解決方案是，通過(guò)正則、JSON Extracor等提取的結(jié)果作為變量，動(dòng)態(tài)傳遞數(shù)值給下游（變量）使用。
當(dāng)然，這種解決方案對(duì)于JMeter工具來(lái)說(shuō)，是個(gè)不錯(cuò)的解決方案，而且這個(gè)解決方案也具備普適性，就算你開(kāi)發(fā)自己的接口測(cè)試框架，也是可以使用這種解決方案的（實(shí)際上，我在前東家參與研發(fā)的接口測(cè)試框架，當(dāng)時(shí)解決接口間參數(shù)傳遞的問(wèn)題就是借鑒的這種思路。開(kāi)發(fā)了一個(gè)類似JMeter正則提取器的正則提取工具包，引用工具包可以允許你輸入要提取的字段key便可匹配到其字段值value，如果提取不到就返回默認(rèn)值，如果有響應(yīng)體中一個(gè)key存在多個(gè)value，則返回最后一個(gè)匹配到的value；下游接口則使用Java replace()方法替換掉請(qǐng)求體中的${xx}。）。
如果只追求可以用，這個(gè)方案沒(méi)問(wèn)題。但是這個(gè)方案缺點(diǎn)就是接口用例開(kāi)發(fā)效率比較低，增加了寫(xiě)接口測(cè)試用例的成本。這也是我當(dāng)時(shí)遇到的一個(gè)問(wèn)題，大家寫(xiě)自動(dòng)化測(cè)試用例的時(shí)間很大一部分花在接口間參數(shù)提取和調(diào)試上。此外，這個(gè)方案也會(huì)增加維護(hù)成本，導(dǎo)致用例的“穩(wěn)定性”比較低。是因?yàn)槿绻嫌谓涌诘捻憫?yīng)體結(jié)構(gòu)變化可能會(huì)影響提取結(jié)果，下游的接口請(qǐng)求體中的${xx}也需要手動(dòng)維護(hù)。總結(jié)下來(lái)，自動(dòng)化用例的維護(hù)和開(kāi)發(fā)成本主要集中在接口間參數(shù)傳遞的維護(hù)上面。
是否有更優(yōu)的解決方案呢？
試想一下，我們能否將整條鏈路可能使用到的字段集合作為一個(gè)池子，在上游接口的響應(yīng)結(jié)果提取出key-value并扔到池子里。下游的接口request體模版化，以${xxx}表示需要替換的變量，利用模板引擎(例如Java的velocity/FreeMarker)將${xxx}替換成“池子”中存在的value。實(shí)現(xiàn)的簡(jiǎn)圖如下。
動(dòng)手做
下面就以Java語(yǔ)言實(shí)現(xiàn)為例，寫(xiě)兩個(gè)方法A、B，且B依賴方法A的返回結(jié)果。
我們只需要開(kāi)發(fā) 上下文類、模版組裝工具、模擬場(chǎng)景代碼即可。
