此文已由作者王婷英授權網易雲社群釋出。

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

快取，看到這兩個字，第一反應，最近怎麼又要弄快取的改造啊，這個測試好複雜，一不不留心就踩一個線上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進行灰度原因如下：

1、stable_dev環境的呼叫方是非常的多

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

基於上面這兩點，stable_dev可以模擬多併發下寫快取和讀快取的操作。可以不用自己擔心，只要關注下群裡對應的環境反饋，保證工程能正常的執行。同時每天定時關注下stable_dev對應的solo相關的日誌即可。

總結：

1、對於部分遷移solo快取改動不大的工程，我們可以按照常規流程去測試

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

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

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

相關文章：
【推薦】 談談驗證碼的工作原理