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