最近測試可靠性，參考了業界的一些思維，有些想法和建議；
先說說軟體可靠性的定義，根據我測試的體會和思考，我覺得軟體的可靠性就是軟體系統發生故障後自動恢復或者人工干預使其能恢復到正常狀態的能力；
業界的測試有些把容錯測試和可靠性測試搞混淆，其實兩者不一樣，容錯測試是通過模擬一些可能發生的已知的異常操作而檢測軟體相應的容錯機制是否生效；而可靠性測試是模擬那些會導致系統功能出現錯誤的不可預知的操作而驗證系統在出錯後的恢復能力；
經過測試和參考一些業界的認識，現有如下總結：
可靠性機制包括4個方面：發現故障、處理故障、收集資訊和告知使用者，針對每個功能的特點，這幾個手段的實現有所不同：
1、發現故障：一般只有3種，啟動時檢測、定時檢測和即時檢測，啟動時檢測主要是檢查磁碟等硬體是否有故障；有些模組部分不可能做到時時檢測，因為那樣太耗資源，會影響系統執行效率，況且也不需要時時檢測，這種方法一般使用於程序、資料庫、驅動、磁碟檢測等；但有些功能就不能用定時檢測，因為一旦出錯就可能導致業務中斷或者功能失效，如：exchange和cifs**收到異常資料、配置檔案損壞後程序無法讀取，這類故障必須即時檢測即時處理才行；
2、處理故障：業界對故障的處理通常有自動修復、恢復到最近一次正確配置或者替換裝置（雙機）、忽略放行和停止功能這幾種方法，在我們的產品中都有用到；可靠性機制最理想的處理是自動修復，但並不是每個功能都能做到自動修復，更多的是採用後面三種後再通過人工干預使其恢復到正常狀態；總之，無論是自動修復還是其它方式，目的只有乙個，就是不會導致客戶業務中斷；
3、收集資訊：有2種方式結合使用，一種是定時收集資訊，一種是發生故障後觸發可靠性機制產生日誌之類的資訊供排查使用；定時收集資訊沒有針對性，定時將產品所有核心功能和可供查詢的資訊收集打包供日後排查錯誤使用，故障觸發產生的日誌之類的記錄能幫助研發人員準確的定位問題的位置，兩者都是必要的；
4、告知使用者：無非就是在顯眼的地方發出告警提示、打出日誌等通知性手段；
加速產品可靠性測試：
基本上可以分硬體可靠性測試和軟體可靠性測試：
硬體可靠性測試點：
主要有cpu佔用率，主要測試程序占用過高後的處理；
記憶體佔用率，主要是程序占用記憶體過高的處理；
磁碟可靠性主要是：磁碟是否掛載成功（對加速來說是指高階裝置的從盤是否成功掛載）、分割槽是否正確（包括格式和大小）、檔案系統是否掛載成功、網口是否正常、宕機能否重啟、裝置不能工作了是否有替代裝置馬上替換；
軟體系統可靠性測試：
主要是各功能的配置檔案，程序，資料庫，核心，驅動出現故障後的處理，如配置檔案損壞了直接用備份的配置檔案替換；程序退出了被軟狗重新啟動等這類故障的處理比硬體可靠性複雜；
對加速產品的可靠性機制提出一些建議：
1、為了保證核心功能的可靠性，建議在系統啟動時對核心功能相關的配置進行檢查，出現過母盤公升級後，webdatache目錄下不存在disk0目錄的情況，這樣啟動後，只有跑過資料後才知道，而且影響功能，像這類涉及到核心功能的故障應該在系統啟動時就進行檢查，啟動時具體檢查哪些可以討論決定；
2、域功能中的委派資訊在閘道器和域控制器時間相隔超過一定時間後，委派資訊就無效了，因為時間間隔導致不能正常互動了，這裡可以考慮做可靠性機制，定時檢測域控制器和閘道器的時間差，並告知使用者；
3、md5值檢查也是一種故障檢查方式，一般用在配置檔案的可靠性檢查，雖然暫時覺得在我們的產品中還用不到，但是可以作為一種方法考慮；
4、故障處理時間限制：我們的產品現在只是做了可靠性機制，而大多數可靠性機制沒有效率要求，業界對產品的可靠性都有效率要求，處理故障和恢復故障不能耗太多時間，雖然暫時的可靠性還沒涉及到效率的要求，除了雙機（雙機並不是一種部署模式，而是一種硬體級的可靠性機制——直接替換裝置）；
5、用例架構：建議按照上述的硬體可靠性和軟體系統可靠性來劃分架構，容易理解，也容易分開進行測試，按照目前的灰盒的理解來劃分用例架構在執行的時候感覺有時候同乙個功能點的可靠性分布在不同目錄中，是分散的，不便於對其進行系統的理解和發散測試；
6、加速可靠性的完善可根據上述4個方面（檢測、處理、收集資訊和告知使用者）去思考和發散，可對照每個功能模組進行測試，看哪些模組有必要做可靠性機制、哪些模組的可靠性機制不完善或者可靠性機制實現方法不合理，都可以提出來加以改進；
可靠性測試
在產品前期各個版本中已經分層進行過如下可靠性測試 基於特性的功能可靠性測試 1 首先分析清楚本特性詳細的處理流程，包括涉及的所有部件和協議，訊息的詳細互動過程 如訪問多少次db，每次記錄什麼資料，失敗後如何回滾等，考慮各種異常處理分支 部件間超時配合等 2 針對處理流程考慮如下可靠性因素，主要包括 ...
可靠性測試
可靠性是最初是確定乙個系統在乙個特定的執行時間內有效執行的概率的乙個標準。可靠性的衡量需要系統在某段時間內保持正常的執行。目前，使用最為廣泛的乙個衡量可靠性的引數是，mttf mean time to failure，平均失效等待時間 定義為隨機變數 出錯時間等的 期望值 但是，mttf經常被錯誤地...
可靠性測試模板
可靠性測試模板 可靠性測試是為了滿足軟體可靠性要求進行一系列設計 分析 測試等工作。其中確定軟體可靠性要求是為了軟體可靠性測試中需要解決的首要問題。可靠性要求可以包括定性定及量要求等。可靠性測試是在軟體生存週期系統測試階段提高軟體可靠性水平有效途徑。許多測試方法 測試技術都能發現導致軟體失效的軟體中...