讀書筆記（SRE：Google運維解密）：第17章 測試可靠性

• 對服務品質的自信可以用過去的系統可靠度和未來的系統可靠度來衡量。前者可以通過抓取和分析曆史性監控資訊來獲得，後者可以用基于曆史資料的預測來量化。為了讓這些預測資訊足夠準确，必須滿足下列條件中之一：

  （a）在這段時間内，該系統完全沒有改變。包括沒有任何軟體更新以及伺服器數量變化，這意味着未來的行為方式應該與過去的行為方式類似。

  （b）可以充分描述整個系統的所有改變，這樣可以針對每個系統變化引入的不确定性進行分析。

• 軟體測試的類型：傳統測試和生産測試

  （a）傳統測試：

  

  1）單元測試：單元測試（unit test）是最小、最簡單的軟體測試形式。這些測試用來評估某一個獨立的軟體單元，比如一個類，或者一個函數的正确性。

  2）內建測試：通過獨立的單元測試的軟體元件被組裝成大的系統元件。工程師通過在這個元件中運作一個內建測試（integration test）來檢驗該元件的功能的正确性。依賴注入（dependencyinjection），利用類似Dagger這樣的工具，我們可以建立出複雜依賴的mock（測試中替代真實邏輯的僞元件），用以友善地測試某個系統元件。

  3）系統測試：系統測試（system test）是一個在未部署的系統上運作的大型測試。某個元件的所有子產品（Module）都會被裝載到系統中（例如通過內建測試的軟體伺服器）。

系統測試包括以下幾種類型：

• 冒煙測試（smoke test）：也被稱為理性測試，如果該測試不通過，那麼其他更昂貴的測試可以不用運作了。
• 性能測試（performance test）：確定它不會在沒人知道的情況下逐漸變慢
• 回歸測試（regression test）：保證之前的Bug不會重制

很重要的是，每個測試都有成本，時間成本和計算資源成本。時刻關注這些測試的成本，是軟體開發效率提升的重要因素。

（b）生産測試：也被稱為黑盒測試。生産測試對運作一個可靠的生産環境來說是必要的。

• 變更釋出與測試
• 配置測試：比較目前測試通過的版本和自動化系統的目标版本可以暗示我們生産環境目前與實際工作相差多遠。

• 壓力測試：了解系統群組件的性能邊界

  （1）資料庫容量滿到什麼程度，才會導緻寫請求失敗。

  （2）向某應用每秒發送多少個請求，将導緻應用過載并導緻請求處理失敗。

• 金絲雀測試：

  （1）一小部分伺服器被更新到一個新版本或者新配置，随後保持一定的孵化期。

  （2）并不真的是一個測試，而是一種結構化的最終使用者驗收測試。

• 将測試的重點集中在用最小力氣得到最大收益的地方。可以先從如下的問題開始：

  （a）是否能夠将源代碼按重要程度分出優先級？用研發管理和項目管理的行話來說，如果所有任務都是高優先級的，那麼它們就也全是低優先級的。是否可以将要測試的系統元件按重要度排序（用什麼标準來衡量重要度都可以，關鍵要排序）？

  （b）是否有某些函數或者類是非常關鍵的，或者對業務營運極為重要的？舉例來說，涉及計費系統的代碼通常對業務來說是很關鍵的。同時計費代碼也經常可以從其他部分很幹淨地剝離開進行測試。

  （c）哪些API是其他團隊需要內建使用的？有時最終使用者級别的測試能夠找到的問題比想象的要嚴重，因為它們可能會迷惑其他開發團隊，使他們寫出錯誤的（或者隻是效率低）API用戶端代碼。

• 優先處理建構問題。原因在于：

  （a）如果問題引入系統之後，又有新的變動，修複會更難。

  （b）不工作的代碼會對團隊造成影響，因為它們必須手動繞過這些問題。

  （c）定時地每晚建構和每周建構将失去意義。

  （d）團隊響應緊急釋出的能力将會受到嚴重影響，甚者非常複雜和困難（例如，發現代碼中以及依賴中的安全漏洞等）。

• 有時候靈活性需要靠穩定性來驅動。如果每次代碼建構的結果都堅如磐石非常可靠時，開發者才能疊代得更快！

• SRE工具具有兩個特點：

  （a）這些工具的副作用基本處于被良好地測試過的主流API範圍内。

  （b）由于現存的驗證和釋出流程，這些工具基本不會對使用者造成直接影響。

• 大規模測試：

  （a）使用工具

  （b）針對災難測試

  （c）速度

  （d）生産環境與測試不一緻

  （e）允許測試失敗

  （f）內建：用單元測試測試某個配置檔案可以提高可靠性之外，針對配置檔案進行內建測試也很重要

  （g）生産環境探針：1）釋出測試可能将內建伺服器包在一個前端伺服器和一個虛假的後端伺服器之間。2）探針測試可能将內建伺服器包在負載均衡的多個前端伺服器和一個真實的生産後端伺服器之間。3）前端伺服器和後端伺服器通常有獨立的釋出周期，這些釋出周期不會同步。