緩存測試分享篇：如何利用測試環境進行灰度測試緩存遷移solo

此文已由做者王婷英受權網易雲社區發佈。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

緩存，看到這兩個字，第一反應，最近怎麼又要弄緩存的改造啊，這個測試好複雜，一不不留心就踩一個線上bug。實在頭疼。通常對於這方面的測試，都不會掉以輕心。但仍是會踩到雷。那麼怎麼作才能夠又快又好完成這個任務呢？相信每一個QA都會有本身的測試應對方案，來達到高質量的上線。

接下來進行分享下社區這邊測試solo緩存遷移的測試方案，有不周到的地方你們多提建議，有更好的方案，也能夠分享下，讓咱們能更快更好的應對這方面的測試工做。本次社區這邊遷移solo的工程有comment、comment-compose、community-compose、contact-compose等核心工程。

案例一：contact-compose的solo遷移（改動不大，代碼改動總體比較清晰）

圖一：專輯的改動

上面這兩張圖都是對contact-compose工程裏涉及到專輯的內容進行NKV變動爲solo，你們能夠看到這個的代碼的改動基本是一對一的改動，改動的範圍基本都知道。那麼接下來咱們須要怎麼測試這個需求。

【測試流程】

第一步、咱們看了開發開發代碼改動不是很大，而後就能夠本身按照開發修改的地方列定下回歸的範圍

第二步、梳理下這個工程哪些業務是用到了緩存。

第三步、能夠再找開發對一下範圍

第四步、就雙方進行評估下回歸範圍，就能夠解決掉了。

經過上面的步驟，咱們不只能夠作到心中有數，還能夠起到監督開發是否有遺漏的地方沒有修改。

上面這個是NKV的緩存遷移爲solo的緩存，可是咱們測試中還存在NCR的緩存，那麼接下來聊一下NCR緩存的遷移。

案例二：community-compose的solo遷移（改動多，複雜性高）

圖三：代碼簡單的統計修改數

當我看到這個改動，瞬間人變得緊緻起來了，零碎的看開發改的代碼，看了兩天，當時抱着這個確定會出線上bug的心情在忐忑的測試。

圖四：community-compose工程對應的solo業務key有18個

這個迴歸起來若是沒有一週確定是不行了，當時內心這麼一想，壓力很大，怎麼辦還有好多任務，這個也是卡在4月底上線。有點想加班加死的想法。因而，我先把代碼都部署上，把開關都關閉的時候，花了兩個小時驗證了下社區的核心功能沒有什麼問題。而後我再把這18個Key所有都打開了，迴歸了下正常的狀況沒發現異常後，我開始灰度了。在我心灰灰的時候，就在想，這麼高風險的任務，怎樣才能更好的去避免線上不出問題？忽然一個開發過來和我說，單測過不了了，怎麼辦？

此時很感謝這位開發，讓我想到了能夠不用靠一己之力來處理了。藉助灰度方案來協助這個高危需求。可能有人覺得我是準備拿到beta環境進行灰度，NO，NO。預估了下再近一週內community-compose不會有上線，及時有上線也都是走hotfix分支，因而我把代碼合到了dev分支，在stable_dev進行灰度。

採用用stable_dev進行灰度緣由以下：

一、stable_dev環境的調用方是很是的多

二、stable_dev環境是單測執行環境

基於上面這兩點，stable_dev能夠模擬多併發下寫緩存和讀緩存的操做。能夠不用本身擔憂，只要關注下羣裏對應的環境反饋，保證工程能正常的運行。同時天天定時關注下stable_dev對應的solo相關的日誌便可。

總結：

一、對於部分遷移solo緩存改動不大的工程，咱們能夠按照常規流程去測試

二、對於複雜性高、改動大的工程進行solo遷移，咱們能夠用類比的方式利用有限的資源去協助測試（如用stable_dev環境進行灰度）

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

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 Impala源碼之資源管理與資源隔離