後臺服務項目的白盒測試之旅

本文來自阿網易雲社區

做者：孫婷婷

白盒測試原由

17年下半年我開始介入部門新項目的服務v2版本的功能測試。剛接手項目時，感到十分頭疼，首先它不像我剛接觸測試時作的to C端項目，主要是頁面展現操做，黑盒測試足夠；其次它不像我剛來網易介入的圖像項目，主要經過接口判斷圖片屬性，擼擼產品需求也能經過黑盒測試覆蓋功能。

相比之下新項目的項目特色則是：

A.    是一個服務端項目，主要是接口測試；

B.    接口參數須要特定的加密格式加密後傳輸，服務端須要解密後處理，數據不透明；

C.    接口參數量多達至少30個，接口最後返回類型多達30種，邏輯複雜；

 總結起來，它就是一個數據不透明、邏輯複雜的後臺接口服務項目。剛拿到項目的時候我基本處在無從下手的階段，加密解密太複雜，我鏈接口測試都不會實現。被逼無奈，先把開發的單元測試用例拿來跑一跑，邊跑邊瞭解摸索，慢慢就走上了白盒測試的道路。

測試摸索

我在測試過程當中，主要按照經過數據追溯主幹，需求用例發散旁支，bug追因查看細節的思路，來一步步抓大放小學習開發代碼，同時完成測試任務。

1.追溯主幹：

在項目介入過程當中，我喜歡經過關注數據的流動來快速瞭解一個項目的主要實現過程，即擼清從調用一個接口傳入參數到得到結果這個過程當中數據通過哪些模塊，通過加工後落入哪一個存儲模塊。

舉例來講，在本次測試摸索過程當中，首先梳理項目各個接口的主要功能、梳理接口參數和返回值。因爲項目的主要功能接口是collect接口和check接口，則在代碼層主要關注這兩個相關模塊。

 

接着根據接口參數的數據流向走讀或者DEBUG代碼，查看在主幹鏈路上的流向。因爲項目的主要參數是收集的設備和行爲信息CheckData，就能夠重點關注CheckData的數據處理。在實踐中，遵循從上層深刻底層的原則，本項目中都是http接口，則能夠從代碼Controller層入手，跟蹤CheckData數據通過哪些系統、模塊處理，是否通過kafka、redis、nos等模塊，最終存入何處。這步操做，對於後續在測試過程當中進一步校驗測試數據處理是否正確會有很大幫助；同時面對分佈式系統，能讓你快速瞭解整個項目的模塊、依賴和架構，分分鐘畫出系統架構圖。

2.發散旁支：

在接觸接口後，能夠在功能用例的基礎上查看重點需求代碼發散旁支，瞭解需求細節，查看或者跟開發討論瞭解具體實現方法。結合測試用例，能夠邊測試邊瞭解代碼，補全用例沒運行到的代碼場景。例以下圖中在測試collect接口功能時，已經經過梳理主幹看到代碼中參數會被解密後解析，此時就能夠詳細去查看數據處理方法decode和parse，增長些解密解析中的異常場景，也便於後續校驗傳參是否合理、解析是否正確等。

3.bug追因查看細節

當測試過程當中輸出結果不符合預期卻又不能確定定性爲bug時，就是白盒測試上臺的最好時機啦。將項目配置成遠程debug模式，復現問題場景，在觸發場景過程當中單步調試代碼，查看代碼實現細節，確認每一步是否符合預期最終定位問題緣由。將結果自信反饋給相關開發。

對於DEBUG這個過程，沒有接觸過遠程DEBUG的小夥伴，能夠首先嚐試把代碼下載到本地review代碼；review熟了能夠求助開發，幫着先把代碼在本地跑起來進行本地debug；當本地debug玩的飛起的時候，遠程debug就也不是問題啦~（爲了不一些環境配置問題，測試環境測試仍是比本地環境測試靠譜的）

能夠參考二組小夥伴宋亞敏寫的遠程debug配置：http://ks.netease.com/blog?id=8113

總結：

完成白盒測試，首先創建在很是瞭解需求的基礎上，其次，對於代碼有必定的熱情，最後也要熟悉java基本知識（若是開發使用其餘語言，還須要瞭解相應的技術知識）。不過還沒上道的小夥伴也不用心急，會看到這裏，說明你也是感覺到了代碼的迷人之處準確嘗試啦，平時注意積累技術知識，拿一個合適的項目介入實踐，白盒測試並非一個遙遠的話題。

在測試實踐過程當中，因爲項目測試確實投入了大量的時間和精力，讓我途中質疑過白盒測試的意義，同一個bug，用功能測試方法可否測出來？是否更節省時間人力呢？認真思考後我以爲白盒測試做爲一個高技巧的測試手段，在這個過程當中我仍是收穫更多的：

1.     對於業務，有了更加深入的認識和理解，在和開發產品溝通的時候能更好的傳達雙方的需求，也得到你們的承認；

2.     技術實力提高，白盒測試雖然增長了閱讀代碼的時間投入，可是減小了bug溝通成本，讓咱們有更多的機會去了解開發的技術，擴充技術知識面，提高測試信心。

固然，這個過程確實投入了大量的時間，有些異常順着開發思路也容易形成異常漏測。不過我以爲這不全是白盒測試的鍋，更多的是我一開始黑盒用例設計不完善以及過多依賴白盒的緣由，所以之後項目測試中對於多種測試方式的使用分配還須要再磨鍊。

最後，之前QA向開發提bug時對話是這樣的：

QA：你這個功能實現好像有個bug……

開發gg：什麼bug，你環境是測試環境嗎，代碼有從新部署嗎？

QA：最新的測試環境……

開發gg：數據發的對嗎？參數接口有沒有調錯？

QA：確認了好像沒錯

開發gg：那你重現一下試試？

QA：好……

如今的對話則是這樣的：

QA：你這段代碼邏輯跟需求不符啊

開發gg：啊，是的是的，我改一下

QA：你這段代碼是否是粗心了哇，true和false弄反了哎

開發gg：哎呀好像是的，我改一下

（彩蛋：）

開發gg：大家這邊有沒有自測用例，讓我先自測一下看有沒有問題哦~~

最大收穫：無形之中，我已經推進了開發自測啦！！

網易雲免費體驗館，0成本體驗20+款雲產品！

更多網易研發、產品、運營經驗分享請訪問網易雲社區。

相關文章：
【推薦】 盤點大數據在遊戲行業中的應用