最近測試可靠性，參考了業界的一些思維，有些想法和建議；
先說說軟件可靠性的定義，根據我測試的體會和思考，我覺得軟件的可靠性就是軟件系統發生故障后自動恢復或者人工干預使其能恢復到正常狀態的能力；
業界的測試有些把容錯測試和可靠性測試搞混淆，其實兩者不一樣，容錯測試是通過模擬一些可能發生的已知的異常操作而檢測軟件相應的容錯機制是否生效；而可靠性測試是模擬那些會導致系統功能出現錯誤的不可預知的操作而驗證系統在出錯后的恢復能力；
經過測試和參考一些業界的認識，現有如下總結：
可靠性機制包括4個方面：發現故障、處理故障、收集信息和告知用戶，針對每個功能的特點，這幾個手段的實現有所不同：
1、發現故障：一般只有3種，啟動時檢測、定時檢測和即時檢測，啟動時檢測主要是檢查磁盤等硬件是否有故障；有些模塊部分不可能做到時時檢測，因為那樣太耗資源，會影響系統運行效率，況且也不需要時時檢測，這種方法一般使用於進程、數據庫、驅動、磁盤檢測等；但有些功能就不能用定時檢測，因為一旦出錯就可能導致業務中斷或者功能失效，如：exchange和cifs代理收到異常數據、配置文件損壞后進程無法讀取，這類故障必須即時檢測即時處理才行；
2、處理故障：業界對故障的處理通常有自動修復、恢復到最近一次正確配置或者替換設備（雙機）、忽略放行和停止功能這幾種方法，在我們的產品中都有用到；可靠性機制最理想的處理是自動修復，但並不是每個功能都能做到自動修復，更多的是采用后面三種后再通過人工干預使其恢復到正常狀態；總之，無論是自動修復還是其它方式，目的只有一個，就是不會導致客戶業務中斷；
3、收集信息：有2種方式結合使用，一種是定時收集信息，一種是發生故障后觸發可靠性機制產生日志之類的信息供排查使用；定時收集信息沒有針對性，定時將產品所有核心功能和可供查詢的信息收集打包供日后排查錯誤使用，故障觸發產生的日志之類的記錄能幫助研發人員准確的定位問題的位置，兩者都是必要的；
4、告知用戶：無非就是在顯眼的地方發出告警提示、打出日志等通知性手段；
加速產品可靠性測試：
基本上可以分硬件可靠性測試和軟件可靠性測試：
硬件可靠性測試點：
主要有cpu占用率，主要測試進程占用過高后的處理；
內存占用率，主要是進程占用內存過高的處理；
磁盤可靠性主要是：磁盤是否掛載成功（對加速來說是指高端設備的從盤是否成功掛載）、分區是否正確（包括格式和大小）、文件系統是否掛載成功、網口是否正常、宕機能否重啟、設備不能工作了是否有替代設備馬上替換；
軟件系統可靠性測試：
主要是各功能的配置文件，進程，數據庫，內核，驅動出現故障后的處理，如配置文件損壞了直接用備份的配置文件替換；進程退出了被軟狗重新啟動等這類故障的處理比硬件可靠性復雜；
對加速產品的可靠性機制提出一些建議：
1、為了保證核心功能的可靠性，建議在系統啟動時對核心功能相關的配置進行檢查，出現過母盤升級后，webdatache目錄下不存在disk0目錄的情況，這樣啟動后，只有跑過數據后才知道，而且影響功能，像這類涉及到核心功能的故障應該在系統啟動時就進行檢查，啟動時具體檢查哪些可以討論決定；
2、域功能中的委派信息在網關和域控制器時間相隔超過一定時間后，委派信息就無效了，因為時間間隔導致不能正常交互了，這里可以考慮做可靠性機制，定時檢測域控制器和網關的時間差，並告知用戶；
3、md5值檢查也是一種故障檢查方式，一般用在配置文件的可靠性檢查，雖然暫時覺得在我們的產品中還用不到，但是可以作為一種方法考慮；
4、故障處理時間限制：我們的產品現在只是做了可靠性機制，而大多數可靠性機制沒有效率要求，業界對產品的可靠性都有效率要求，處理故障和恢復故障不能耗太多時間，雖然暫時的可靠性還沒涉及到效率的要求，除了雙機（雙機並不是一種部署模式，而是一種硬件級的可靠性機制——直接替換設備）；
5、用例架構：建議按照上述的硬件可靠性和軟件系統可靠性來划分架構，容易理解，也容易分開進行測試，按照目前的灰盒的理解來划分用例架構在執行的時候感覺有時候同一個功能點的可靠性分布在不同目錄中，是分散的，不便於對其進行系統的理解和發散測試；
6、加速可靠性的完善可根據上述4個方面（檢測、處理、收集信息和告知用戶）去思考和發散，可對照每個功能模塊進行測試，看哪些模塊有必要做可靠性機制、哪些模塊的可靠性機制不完善或者可靠性機制實現方法不合理，都可以提出來加以改進；