站在测试角度理解可靠性
2022-01-04 14:21:53 18 举报AI智能生成
从测试的思维理解可靠性
作者其他创作
大纲/内容
对于可靠性，用户关心什么？
系统是否能稳定运行
业务系是否失效/异常
业务失效/异常后是否可以尽快回复
如果无法回复，是否可以及时告警上报
AWS架构六大支柱
良好的运营
安全性
可靠性
设计原则
自动恢复故障
不仅仅是恢复故障而已，而是通过一些智能监控的方式，在关键性能指标出现异动时，
针对恢复过程的测试
通过自动化的方式，来复现验证曾经出现的过的故障；或者验证系统应当具备的恢复能力
水平扩展以提高集群负载和可用性
需要注意多个组成节点，不应具有公共故障点，即同一个故障不会导致节点大面积故障
按需调整所需资源
配合监控措施，监控硬件资源使用情况，按需自动扩容和削减资源
变更管理自动化
包括需求变更和自动化用例变更
性能提升
成本控制
稳定性
关于自动化
自动化的优势
提升效率
不需要人工操作并检查数据
减少重复投入
架构产生变化后，适应能力强
可以应对复杂的系统
减小杀虫剂效应
自动化的困难点
平台能力的缺失
用例生成管理
监控能力
告警能力
检验能力的缺失
规范/标准待完善
可依赖平台
用例自动编排
故障域
故障权重
用例管理、执行
自动化管理
需求（标准、规范）管理
性能压测平台
故障注入工具
分析、核对、监控、报告
现状分析
待补充
关于可靠性的不同定义
AWS
The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to
可靠性支柱包括工作负载在预期情况下正确、一致地执行其预期功能的能力。
可靠性支柱包括工作负载在预期情况下正确、一致地执行其预期功能的能力。
软件可靠性测试
可靠性是指产品在规定的条件下和规定的时间内完成规定功能的能力
1983年美国IEEE计算机学会
在规定的条件下，在规定的时间内，软件不引起系统失效的概率；
在规定的时间周期内，在所述条件下程序执行所要求的功能的能力；
从定义剖析可靠性因子
无效时间
运维时间
各种升级方式支持
故障时间
RTO
RPO
正常运行时间
N个9
根据历史数据统计
根据架构类比估计
组合计算
共因
单个组件可用性
正确性(规定时间、条件)
数据一致性
事务成功率
数据正确性验证
基础性能指标
监控
智能（算法）监控
告警，通知
弹性扩缩容
故障自动恢复
节点冗余
服务治理
熔断
过载保护
可靠性应该关心什么
运维监控能力
监控能力
升级能力
告警能力
弹性扩缩容能力
可用性
RTO
RPO
自我修复能力（容错性）
数据一致性/事务成功率
可靠性测试的意义/目的
检验
量化
评估
指导
调优
分析方法
失效模式影响分析法（Failure Mode and Effects Analysis）
步骤
列出（拆分）组件
对于每个组件，列出所有已知的失效模式
对于每个组件/失效模式，列出其对更高层次上的影响
对于每个组件/失效模式，列出影响的严重程度
局限性
由于每个组件都单独进行分析，因此导致严重问题的组合所产生的复合失效未得到辨识。
在容错系统中，共因失效很少被识别出来
在FMEA期间，操作和维护错误也很难分析
组件的所有故障模式都必须已知，否则会被忽略
辨识人员的技能和态度对于FMEA的质量非常重要
故障树分析法
步骤
列出已知或者预期的问题
推演可能产生相关问题的所有可能
制定相关场景
局限性
需要先了解潜在或者已知的问题（对经验的要求）
原因的分析可能会产生很多的分叉和不确定性，最终结果可能会产生较大偏差
待补充。。。
可靠性测试过程
确定可靠性目标（规范、标准）
环境规划、准备
设计测试用例
实施可靠性测试
分析测试结果
收藏
收藏
0 条评论
下一页
