測試平臺-記一次不成功的 RF 遠端庫問題解決過程

該文原創為新潮質量保障技術團隊中的 “上進的中年軟體測試從業者”，用於技術交流分享

又到了週五的晚上，下班的時候看到了了企業微信推送的一條很尬的訊息。

不自覺的第一時間就想到了天下無賊的一句臺詞-你TM才沒腦子呢，純屬戲言。

又要開啟愉快的週末生活了，雖然已經差不多都安排滿了事情，但是沒有工作日那種壓迫感，還是不錯的。這也是為什麼加班最好在公司的主要原因，身心會不自覺就投入其中。

渾渾噩噩的過了兩週，感覺沒什麼可值得寫的，幸好今天解決了一個測試平臺架構上面的問題，可以拿出來給大家嘮叨嘮叨。

##開篇

昨天有同事發來一個問題，想要在測試平臺架構提供的RF Remote服務返回的http請求以Response物件的形式呈現，然後通過預先檢查status_code來避免因為開發亂寫返回而導致漏測(這邏輯真的很值得學習，自愧不如)。後面想了想，其實從自動化業務用例的場景來說，即使這個地方斷言有誤而導致本應失敗的用例判定承擔，後續的業務也同樣會失敗。舉個例子來說：建立使用者失敗，後端返回500的code和{"msg": "建立使用者成功"}的誤導訊息，但是後續的檢視使用者列表業務場景，同樣會因為使用者建立失敗而導致查詢失敗。

當然，這也比較考驗自動化用例設計者的嚴謹性。對於合理的使用者需求，我們通常都是儘可能的去滿足，至少我會要求以這種態度來處理測試平臺在推廣過程中任何反饋。

##背景

接到這個需求之後，就去同事那裡檢視具體的情況，然後看到了如下的資訊：

初步分析得到的結論是反序列化過程後的問題，熟悉我們平臺的同學都知道我們有公共工具服務以RPC的形式呈現，傳輸過程中更多的時候我們會把資料序列化。附上簡單的服務呼叫圖，方便後續問題解決過程中理解。

##調研

然後沒有多想就把reuqests請求後的Response物件沒有經過序列化過程直接返回給了RF Remote Server, 然後Remote Server再透傳給使用者。然後同事那邊又反饋了新的問題（這就是過度自信，不自測的下場）：

這個問題在通過google，嘗試各種關鍵字排列組合，都沒有找到合適的。今天早上到了辦公室繼續調研這個問題（再次強烈建議早上寶貴的時間一定要給最棘手的事情），突然靈光乍現想到了原理就是為什麼Python的物件無法通過RF Remote Server傳給使用者，然後就在本地打了斷點，開始探究根源：

熟悉的身影再次出現，至此問題的根源找到。（具體的原因就不說了，前面已經介紹很多次了）

##解決過程

找到了問題的根源就很好辦了。先嚐試用在RF Remote Server用直接用requests來生成Response物件返回

然後發現了一個奇怪的現象：

Response物件被在呼叫過程中，返回給客戶端的是被解析的byte集合。然後在官網上找到了正解：

也就是說Python物件在傳輸過程中會自動轉換為string， 具體到測試平臺這邊現有的架構，是沒有辦法來滿足同事的需求。

但是，只要思想不滑坡，辦法總比困難多。和同事商量後，決定在RF Remote Server這邊對需要status_code的需求，把status_code強制加到response的content裡面。當然，這是一種變通的方式，不是最優的解決方案。也請有解決方案的同學不吝賜教。

##思考

後面的一次嘗試，發現了一個驚喜。當呼叫一次RF Remote Server自己通過requests生成的Response，再次呼叫工具服務拿到Response後，通過RF Remote Server透傳後，居然不會報錯！！！大膽猜測一下如果RPC客戶端引入服務端傳送過來的物件對應的包，也就是說如果工具服務返回了requests的Response物件，並且RF Remote Server端引入了requests包，遠端呼叫將不是真正意義的遠端呼叫。當然，這本身也不符合RPC服務的宗旨。

大膽推測，小心求證。這裡就不去求證了，感興趣的小夥伴可以去試一下。

##結語

之前一直聽開發同學說websocket， 前段時間有幸接觸到了一個新專案有這樣的介面形式，有種撥開雲天的感覺。後續爭取能夠引入到測試平臺裡面，讓平臺的的服務形式更豐富。感謝大家的耐心閱讀，我們兩週後見！另外感謝在tester home指正MD5的那位小夥伴。