原文：http://mtydev.net/2016/01/27/分布式存儲產品的測試實踐及心得/
背景介紹
這幾年我一直從事分布式存儲產品的測試開發工作，伴隨着產品的第一次上線，第一次升級，一直到今天。期間參與發布了無數個版本，支持着海量的用戶對我們存儲產品的需求。
想寫一篇文章，總結下自己的工作，記錄工作中的一些心得。
如果有人能從中獲得一些啟發或者收獲，那將是我莫大的榮幸。
主要講幾個方面：
測試角色在整個分布式存儲產品發展過程中的變化
分布式存儲產品的測試實踐
測試實踐碰到的問題
一點心得
測試角色的改變
一般來說，一個項目中會有如下幾種角色：產品經理，開發工程師，測試工程師，運維工程師和項目經理。
項目的開發流程：
產品經理收集用戶的需求，分析用戶的業務場景，反饋給開發和測試工程師
開發和測試工程師討論需求，定義上線的功能以及驗收標准。
項目經理制定項目計划，跟蹤項目進度。
開發工程師開發完代碼后交給測試工程師。
測試工程師測試完成后，交給運維工程師上線。
運維工程師發布上線。
我的測試角色在產品的不同時期有着不同的分工。
一：測試角色在不同產品時期的不同分工
整個分布式存儲產品的發展主要分為兩個階段：
階段一：產品初期的快速迭代與發布
1個集群
2個開發, 1個測試, 1個運維, 1個產品兼項目經理
1個星期每天發布
特點：集群少，用戶量少，訪問量少，功能少
側重點：快速開發和迭代，主要是滿足功能需求，允許試錯。
在這個階段基本都是以快速發布為准。
開發的功能比較單一，1個測試基本能滿足業務需求。
問題：
由於時間緊迫，測試只能有所取舍。
沒有規范的流程，導致問題也比較多，需要修復。
再加上新需求，引入更頻繁的升級和測試。
陷入一個惡性循環。
測試角色：
這個階段，測試主要是執行測試用例。開發在完成單元測試后，基本不承擔測試任務。
階段二：產品穩定期的迭代與發布
數十個集群
10+開發, 1個測試, 3個運維, 2個產品, 1個項目經理
2個月發布一次
特點：集群多，用戶量多，訪問量多，功能多
側重點：產品的穩定性。不允許試錯。
問題：
不能再是之前的玩法。因為集群多，升級就變得很麻煩。開發，測試，運維分屬不同的部門，
對於開發來說，需求越快上線越好。最好每天都能發布一部分代碼。KPI是功能上線。
對於測試來說，測試時間不足，多次發布會帶來質量風險。KPI是產品質量。
對於運維來說，發布越少越好。每次發布都可能帶來誤操作的風險。KPI是發布穩定性。
各方的利益需求不一致，很容易產生矛盾。
測試角色：需要發生改變，因為一個人再也無法完成那么多的測試任務。
所以最后各方面商定的結果就是：
延長發布周期，降低發布頻率。
開發過程的改進：引入設計和代碼評審，引入靜態代碼掃描，引入測試覆蓋率的要求，尤其是UT測試覆蓋率的要求。行覆蓋率和功能分支覆蓋率。
測試過程的改進：引入提測標准，增強自動化測試，不再承擔所有的測試任務，將測試任務分配給其他開發同學，主要進行測試范圍評估，評審測試計划及測試用例。
運維過程的改進：引入自動化發布流程，加強線上監控。
這個階段，測試主要是建立一套測試的機制，讓每個開發都來做測試，開發需要承擔測試任務。
二：公司層面對測試角色的定位
在產品發展的過程中，公司對測試的定位也在不斷發生變化
一開始，測試和開發是在一個團隊。
后來，測試和開發分開，屬於不同的團隊。
再后來，測試和開發又屬於同一個團隊。
再后來，推行全棧工程師，沒有專職的測試工程師。
全棧工程師，每個人的理解可能不一樣。我的簡單理解就是全干工程師，對開發，測試，運維都能干的工程師。
這個概念有人支持，有人反對。都有道理，就像我們需要大而全的百貨商場，也需要小而美的專賣店。
公司所有的決定都是以能支撐業務需求為前提。我們需要做的不是討論對不對，而應該是全面擁抱。
努力做到一專多能，適應這個快速變化的環境。
分布式存儲產品的測試實踐
在分布式存儲產品的測試過程中，測試到底做了些什么事情呢？
一：測試工作內容
需求，設計評審
測試需要參與到每一個過程中
在設計評審的時候就需要知道驗收的標准，這是最重要的開始。因為這個時候如果沒有理解用戶的需求，驗收標准就會跑偏。
用戶的需求是測試的基准點。
測試范圍
需要確定測試范圍。上線的時間都是固定的，在有限的時間內可能無法覆蓋所有的測試，得指定測試范圍。這一方面取決於測試對整個系統的了解程度，另一方面也是考驗和開發溝通和交流能力。
測試用例的設計與開發
主要是根據需求編寫測試工具或者測試用例代碼。一些測試書籍上也介紹了一些常見的方法。這里不多講。
自動化測試框架的設計與維護
只有自動化測試才能把人從簡單，重復，繁瑣的勞動中解放出來。引入持續集成機制，及時發現代碼中存在的問題。
測試對象確定
主要是確定需要測試的版本，以保證最后上線的版本就是測試的版本。
測試實施及反饋
完成測試計划，編寫測試報告，在Bug跟蹤系統上記錄測試中發現的問題。
搜集這些結果給項目經理做質量評估。雖然不全面，但也是重要參考。
統計測試結果，分析。
統計測試覆蓋率，跟蹤未覆蓋到的地方。
這里需要說明的是，測試覆蓋率達標了，不意味着測試達標了，只是表示所有的代碼都覆蓋到了。還需要人工分析測試的完備性。
上線確認及寫發布備忘錄
上線版本及配置文件的最終確認。將所有上線的功能以郵件的形式通知給合作伙伴。
上線問題跟蹤及反饋
后期線上問題的反饋與追蹤，以避免在下個版本中出現同樣的問題。
分布式存儲產品的開發和測試是個龐大的工程，所涉及到的測試需要分類及分級。為此，引入了測試分級的概念。
二：測試的分級
測試分級 測試資源 測試目的 測試頻率
一級：單元測試 單機完成 不需要依賴其他環境，完成代碼函數級別的測試。會采取一些Mock手段去掉對環境的依賴 每次提交代碼
二級：功能測試 小集群 模擬真實場景，完成功能級別的測試。對其他模塊有依賴 每次提交代碼
三級：系統測試 小集群 模擬真實場景，完成系統級別的測試，是功能的組合。對其他模塊有依賴 每次提交代碼
四級：一級性能測試 中型集群 模擬真實場景，完成性能測試。主要關注Latency，QPS，毛刺率，吞吐量等指標。對其他環境有依賴 每次發布
五級：二級性能測試 中型集群 模擬真實場景，完成壓力測試，健壯性測試(Failover測試)。主要關注CPU，內存，網絡等資源耗盡或者不可用的情況下，系統的表現 每次發布
六級：數據兼容性及升級測試 小集群 模擬真實場景，完成存儲及上線發布相關測試。 每次發布
七級：端到端模擬用戶場景測試 大集群 模擬用戶的場景，獲得測試數據 每次發布
這個分級的目的主要是為了：
分工
開發需要負責單元測試和功能測試都通過，才表示代碼可測了。才能走到后面的測試流程。
在緊急上線的時候，有所取舍
不同的級別意味着不同的測試時間，一次單元測試和一次性能測試的時間是不一樣的。一級和二級是必須要全通過。往上的級別可以有選擇性地通過。
測試資源的分配
三：測試用例類型
分布式存儲產品的特點：
1 存儲海量的數據，不同類型
2 集群中機器的損壞是常態
3 海量的用戶訪問
所以在設計測試用的時候根據分布式存儲產品的特點設計了如下的測試用例：
數據兼容性測試
代碼一直在變，會有不同的數據類型出現，如何保證數據兼容性？
一般來說都需要考慮新舊版本寫入數據的兼容性。
實踐中可以每天模擬用戶寫入不同大小，不同類型的文件，在每次升級之前預發布，來校驗這些數據。以做到數據兼容測試。
開發也會在UT中包含這部分內容。只不過是在不同的級別來測試這一點。
數據完整性測試
作為分布式存儲產品，用戶的數據是不能丟的。這點是做存儲的底褲。
在實踐中會每天掃描新增的數據以檢查數據的完整性。
定期還會做全量數據掃描。
性能測試
每次版本發布的時候，我們需要知道這個版本和上一個版本相比，性能是否有提升。這個也是用戶比較能直觀感受到的。
性能測試是一個比較復雜的話題，這里不展開。
性能測試和測試的客戶端，使用的代碼，請求的類型，集群數據的多少都有關系。實踐中是選定差不多的測試環境，進行對比，以減少多個測試變量對性能結果帶來的影響。
壓力測試
模擬網絡，磁盤，CPU等資源消耗完，測試系統的表現能力。對系統設定報警閾值。一旦超過這個能力，系統開始報警。也可以供運維同學參考集群的負載能力。
穩定性測試
測試系統在長期運行下，觀察內存，網絡，CPU資源消耗的情況。常見的問題就是內存泄露，如果每次泄露一點，短時間測試是無法發現問題的。所以一般要求系統能連續運行7天以上。
安全測試
慢連接攻擊測試
大並發模擬攻擊測試
其他攻擊模擬
系統健壯性測試
也指Failover測試，實踐中也是分層的思想
先分模塊：
模擬系統各個模塊失效的情況。例如進程重啟，進程不再啟動等。
再分機器:
對於分布式系統來說，機器資源出現狀況簡直是一定的，例如CPU不夠用，內存超了，網卡無法使用，磁盤損壞，機器斷電等情況。自動化測試可以通過軟件來模擬這些情況。
在實際上線的時候，還是需要做一些模擬故障演練。例如：一台或者多台機器出現斷電。
再分集群:
整個集群掉電后重啟，數據是否丟失。
不可服務的時間，重啟后多久恢復服務。
集群中交換機不可用。這些測試還得依賴於運維工程師的合作。
四：測試工具
工欲善其事必先利其器，測試工具的選擇也很重要。在我們實踐的過程中沒有采用商業軟件，大多數也沒有現成工具，大多是通過工程實踐摸索，開發而來。
工具 目的
集群監控狀態收集與自檢工具 用於測試過程中收集監控數據和自動判斷是否異常以幫助測試及早發現問題
bug、case的報表分析工具 用於通過從bug或case的多個維度來判斷當前產品的質量風險點
測試結果報表分析工具 將測試結果用於比較和分析，方便性能問題的調查
性能壓力測試工具 該功能能夠模擬用戶的請求壓力，請求類型，方便地獲取性能數據
系統測試框架 該工具能夠很好地定制測試需求，完成測試任務，發出測試報告，提交測試結果
pre-check-in工具 該工具能夠確保代碼在提交前能夠自動跑通相關測試集合
代碼覆蓋率報表分析工具 代碼覆蓋率報告分析工具，能夠方便給出覆蓋率不足的各組件代碼
靜態代碼檢查工具 能夠確保代碼在提交前能夠跑通靜態代碼檢查並提供報表功能
協議層、工具層的覆蓋率檢查工具 能夠對組件的協議層和工具命令層進行覆蓋率檢查，來保證測試的覆蓋面
五：做好灰度發布
即使在做了如此多測試的情況下，還是可能會有漏網之魚。怎么辦？
在實踐中，我覺得比較行之有效的方法是做好灰度發布。
這里說的灰度發布指的是，發布的時候只發布一部分機器，觀察。沒有問題，再逐步分批次發布，直至最終全部上線。
做好灰度發布的前提：
1 系統是有兼容性的
也就是說，整個系統應該是能夠兼容新舊版本同時存在，且不會相互影響。如果新版本寫入的舊版本不能讀，那么需要發布到中間的兼容版本。
2 要有好的監控工具
機器資源的可視化與監控。例如CPU，內存，網絡等是否正常
各層模塊的可用性指標可視化與監控。例如成功率，隊列長度，健康度等是否正常
關鍵業務數據指標的可視化與監控。請求的正確率，性能，QPS等業務指標等是否正常
引入大數據工具對每天的訪問請求進行分析，得到真正的業務請求。
做好實時監控，以確定系統的穩定性
3 有責任心的工程師
一個有責任心的工程師會在發布以后去關注功能是否如期工作，那些日志是否正常，線上機器，業務是否都運轉正常。
六：做好上線后的跟蹤回顧
如果上線后有漏網之魚，應該及時地發現，並在缺陷系統中跟蹤，直至修復上線，並且在測試用例中覆蓋。以避免重復的錯誤出現。
七：產品質量的保障
如何保障產品發布的質量是一個很大的話題。總結自己在產品中的方法有：
1 靜態代碼掃描
2 測試覆蓋率
3 代碼及測試評審
4 執行好測試
5 灰度發布
6 發布總結，增加測試覆蓋，形成良好的閉環。
測試實踐中碰到的問題
在具體的測試實踐中，還是碰到了很多問題。
1 測試用例不穩定
由於測試不穩定，導致測試經常失敗。大家都失敗有時候都熟視無睹了。典型的破窗原理。
2 測試環境的問題
單一的環境無法滿足幾個層級的測試需求，但測試資源有時候是有限的。需要做好規划。
3 測試效率的問題
由於產品功能的不斷疊加，回歸的集合原來越龐大，越來越復雜。回歸一次的時間變得越來越長。需要重構測試用例。
4 多個版本同時發布的問題
由於產品在發布的時候可能會有多個分支在回歸，比如正在開發的代碼分支，線上需要修復的代碼分支。但回歸效率不高，只能排隊等待。還是需要提高測試效率。減少回歸的時間
5 測試調查問題困難
測試用例的要求沒有開發代碼要求高，測試框架中對日志支持不夠友好，都造成了調查問題困難。需要改進日志。
我們還是需要做很多工作，讓測試更快，更有效地發生。
一點心得
有幾點感受吧：
1 人靠譜了，事才靠譜
知道了和做到了之間還差十萬八千里。
用韓寒的話說就是：我懂得了許多道理，卻依然過不好這一生。
用成語說就是：知易行難。
但靠譜的人總是能在各種不靠譜的環境下，把事情做靠譜。
2 質量不是僅靠測試工程師來保障
好的測試工程師就像優秀的守門員，時刻預防着Bug的進攻，守住質量這扇門。
但再好的守門員沒有前鋒，后衛的團隊配合，單槍匹馬也無法阻止Bug的進攻。
質量貫穿在每一次評審，代碼Review，單元測試，上線觀察，灰度發布中等環節中。只有每一個環節都做到位，才會有好的質量。
質量是需要開發，測試，運維一起保障的。
3 質量很重要
沒有質量的代碼上線就是運維噩夢的開始。它可能伴隨着半夜報警，連夜修復，通宵緊急發布。
4 要引入全員評審
盡可能多的眼睛，就可以讓所有的問題浮現。每個人的視角不一樣，就像是手術台上的無影燈一樣，從各個角度照射下去，Bug就無所遁形。每個人的思想在碰撞，也許別人的一句提醒或者一個問題，就可以發現自己的視野盲區。
如果您在閱讀的過程中，有任何建議或者問題，歡迎與我交流。郵箱：liuhuang6398#163.com