1、資料倉儲服務架構
資料倉儲服務（data warehouse service），下面簡稱dws 。主要為客戶提供資料儲存，資料探勘，資料分析等功能。其核心採用開源的關聯式資料庫管理系統postgres sql加以定製開發。服務部署在集群上，集群有3~32個虛擬主機組成。使用者使用dws集群的請求處理流程如下：
1.1、使用者通過客戶端，例如chrome，ie，firefox等瀏覽器登入dws介面，對應於下圖中的1。
1.2、使用者對dws集群做了乙個操作，比如重啟，對應於下圖中的2。
1.3、nginx根據排程策略將重啟請求下發到某乙個console節點上，對應於下圖中的3.
1.4、console節點將請求通過haproxy根據某種排程策略，將請求下發到service節點上，對應於圖中的4。
1.5、service節點處理重啟任務，並更新資料庫中相關表的記錄，對應於圖中的5，並返回處理結果。
其它節點功能說明：
1.6、monitor節點：監控集群的狀態。
1.7、billing節點：計費。
1.8、om sevice節點（insight）：運維節點，一些運維操作會通過該節點下發到service節點上。
1.9、db節點：資料庫節點，一主一備。
2、可靠性測試的含義與測試過程
可靠性測試是指：系統在常規與意外環境執行和保持其功能的能力，系統必須能以一致性和可重複性的方式執行並保持其功能。（概念出自《敏捷軟體測試：測試人員與敏捷團隊的實踐指南》）
測試過程：
2.1、明確可靠性測試的目標，同乙個系統，不同的測試目標設計出來的用例也不一樣。
2.2、了解軟體的架構。
2.3、設計可靠性測試用例。
2.4、執行可靠性測試用例。
2.5、分析可靠性測試結果並輸出測試報告返回給測試經理。
3、用例設計
主要從以下幾個方面來考慮，可靠性測試的原則之一：故障恢復後業務能夠自修復。
3.1、從架構設計圖來看一共涉及的的節點有：console，service，billing，db，insight，monitor。其中只有insight部署在一台主機上，其餘節點均部署在2臺或2臺以上的伺服器上，以service為例，一台伺服器宕機了是否會影響業務，兩台呢，或者全部宕機後開機能否自行恢復業務呢？
3.2、記憶體佔用率：單個節點的記憶體佔用率達到90%和100%；多個節點 記憶體佔用率達到90%或100%。
3.3、cpu佔用率：：單個節點的cpu佔用率達到90%和100%；多個節點 cpu佔用率達到90%或100%。
3.4、磁碟使用率：：單個節點的磁碟使用率達到90%和100%；多個節點 磁碟使用率達到90%或100%。
3.5、網路故障：單個節點網路故障，多個節點網路故障。單個節點和多個節點某個網絡卡down掉。
3.6、單個節點重啟，或多個節點重啟。
3.7、功能首次失敗時間，比如：建立dws集群首次失敗時間，即初始操作和首次失敗之間的平均時間。
3.8、dws集群長時間執行業務，是否出問題。
3.9、併發操作：比如同時建立50個集群，觀察成功率，可以使用brupsuite工具。
3.10、業務能否從節點a遷移到節點b，比如建立集群的任務正在節點service1上執行，此時，service1宕機，任務能否成遷移到service2或service3上。
4、可靠性測試過程中用到的工具
寫滿磁碟
佔滿記憶體
待補充佔滿cpu
參考：
可靠性測試學習 可靠性測試理解
最近測試可靠性，參考了業界的一些思維，有些想法和建議 先說說軟體可靠性的定義，根據我測試的體會和思考，我覺得軟體的可靠性就是軟體系統發生故障後自動恢復或者人工干預使其能恢復到正常狀態的能力 業界的測試有些把容錯測試和可靠性測試搞混淆，其實兩者不一樣，容錯測試是通過模擬一些可能發生的已知的異常操作而檢...
可靠性測試
在產品前期各個版本中已經分層進行過如下可靠性測試 基於特性的功能可靠性測試 1 首先分析清楚本特性詳細的處理流程，包括涉及的所有部件和協議，訊息的詳細互動過程 如訪問多少次db，每次記錄什麼資料，失敗後如何回滾等，考慮各種異常處理分支 部件間超時配合等 2 針對處理流程考慮如下可靠性因素，主要包括 ...
可靠性測試
可靠性是最初是確定乙個系統在乙個特定的執行時間內有效執行的概率的乙個標準。可靠性的衡量需要系統在某段時間內保持正常的執行。目前，使用最為廣泛的乙個衡量可靠性的引數是，mttf mean time to failure，平均失效等待時間 定義為隨機變數 出錯時間等的 期望值 但是，mttf經常被錯誤地...