測試平臺-記一次不成功的 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 的那位小夥伴。