最近测试可靠性，参考了业界的一些思维，有些想法和建议；
先说说软件可靠性的定义，根据我测试的体会和思考，我觉得软件的可靠性就是软件系统发生故障后自动恢复或者人工干预使其能恢复到正常状态的能力；
业界的测试有些把容错测试和可靠性测试搞混淆，其实两者不一样，容错测试是通过模拟一些可能发生的已知的异常操作而检测软件相应的容错机制是否生效；而可靠性测试是模拟那些会导致系统功能出现错误的不可预知的操作而验证系统在出错后的恢复能力；
经过测试和参考一些业界的认识，现有如下总结：
可靠性机制包括4个方面：发现故障、处理故障、收集信息和告知用户，针对每个功能的特点，这几个手段的实现有所不同：
1、发现故障：一般只有3种，启动时检测、定时检测和即时检测，启动时检测主要是检查磁盘等硬件是否有故障；有些模块部分不可能做到时时检测，因为那样太耗资源，会影响系统运行效率，况且也不需要时时检测，这种方法一般使用于进程、数据库、驱动、磁盘检测等；但有些功能就不能用定时检测，因为一旦出错就可能导致业务中断或者功能失效，如：exchange和cifs代理收到异常数据、配置文件损坏后进程无法读取，这类故障必须即时检测即时处理才行；
2、处理故障：业界对故障的处理通常有自动修复、恢复到最近一次正确配置或者替换设备（双机）、忽略放行和停止功能这几种方法，在我们的产品中都有用到；可靠性机制最理想的处理是自动修复，但并不是每个功能都能做到自动修复，更多的是采用后面三种后再通过人工干预使其恢复到正常状态；总之，无论是自动修复还是其它方式，目的只有一个，就是不会导致客户业务中断；
3、收集信息：有2种方式结合使用，一种是定时收集信息，一种是发生故障后触发可靠性机制产生日志之类的信息供排查使用；定时收集信息没有针对性，定时将产品所有核心功能和可供查询的信息收集打包供日后排查错误使用，故障触发产生的日志之类的记录能帮助研发人员准确的定位问题的位置，两者都是必要的；
4、告知用户：无非就是在显眼的地方发出告警提示、打出日志等通知性手段；
加速产品可靠性测试：
基本上可以分硬件可靠性测试和软件可靠性测试：
硬件可靠性测试点：
主要有cpu占用率，主要测试进程占用过高后的处理；
内存占用率，主要是进程占用内存过高的处理；
磁盘可靠性主要是：磁盘是否挂载成功（对加速来说是指高端设备的从盘是否成功挂载）、分区是否正确（包括格式和大小）、文件系统是否挂载成功、网口是否正常、宕机能否重启、设备不能工作了是否有替代设备马上替换；
软件系统可靠性测试：
主要是各功能的配置文件，进程，数据库，内核，驱动出现故障后的处理，如配置文件损坏了直接用备份的配置文件替换；进程退出了被软狗重新启动等这类故障的处理比硬件可靠性复杂；
对加速产品的可靠性机制提出一些建议：
1、为了保证核心功能的可靠性，建议在系统启动时对核心功能相关的配置进行检查，出现过母盘升级后，webdatache目录下不存在disk0目录的情况，这样启动后，只有跑过数据后才知道，而且影响功能，像这类涉及到核心功能的故障应该在系统启动时就进行检查，启动时具体检查哪些可以讨论决定；
2、域功能中的委派信息在网关和域控制器时间相隔超过一定时间后，委派信息就无效了，因为时间间隔导致不能正常交互了，这里可以考虑做可靠性机制，定时检测域控制器和网关的时间差，并告知用户；
3、md5值检查也是一种故障检查方式，一般用在配置文件的可靠性检查，虽然暂时觉得在我们的产品中还用不到，但是可以作为一种方法考虑；
4、故障处理时间限制：我们的产品现在只是做了可靠性机制，而大多数可靠性机制没有效率要求，业界对产品的可靠性都有效率要求，处理故障和恢复故障不能耗太多时间，虽然暂时的可靠性还没涉及到效率的要求，除了双机（双机并不是一种部署模式，而是一种硬件级的可靠性机制——直接替换设备）；
5、用例架构：建议按照上述的硬件可靠性和软件系统可靠性来划分架构，容易理解，也容易分开进行测试，按照目前的灰盒的理解来划分用例架构在执行的时候感觉有时候同一个功能点的可靠性分布在不同目录中，是分散的，不便于对其进行系统的理解和发散测试；
6、加速可靠性的完善可根据上述4个方面（检测、处理、收集信息和告知用户）去思考和发散，可对照每个功能模块进行测试，看哪些模块有必要做可靠性机制、哪些模块的可靠性机制不完善或者可靠性机制实现方法不合理，都可以提出来加以改进；