一、引言
不少产品运行要求:集群化部署、分散服务、稳定性运行。硬件故障、网络异常、资源异常、其他依赖异常、配置异常等都会打破原有的平衡导致稳定性问题。稳定性被破坏的场景非常多,复杂的稳定性演进过程中又有很多场景出现,这样交织的变化对分布式系统测试,特别是稳定性测试带来非常大的挑战。
本文以笔者经历,梳理了一种稳定性测试方法。从测试、产品、质量、运营等多重角度挖掘出稳定性提升方式,从而达到稳定性量变式提升。
测试需要变被动为主动,参与到项目全过程中去,提前暴露及预防稳定性问题,才能更好体现真正的价值所在。
二、总体框架
以场景为基础/主干,以指标为目标驱动,通过梳理及细化影响因子,梳理合理逻辑处理方法,最终形成稳定性关注点,运用到评审、专项测试、预发布、生产观察等上,通过工具和测试方法让稳定性得以落地实施。

三、稳定性场景
梳理大的、完整的业务场景,作为基准,如**云提供虚拟机,其核心可能是创建/重建(创建入口多样性,创建方式多样性?)。
四、稳定性指标
- 来源:竞品、产品交付、运营分析、SLA等
- 常规指标:cpu,io,内存,磁盘,连接数,端口数,响应时间,进程数等
- 业务指标:业务成功率、业务时间等
- 其他指标:高可用策略、避免孤岛现象(集群间、集群内、多机等)、查询速度
五、稳定性影响因子
- 常规影响因子:网络(波动/丢包、断网、重复包等)、磁盘(不足、磁盘掉盘、磁盘不可读、文件不可写等)、内存(内存泄露、内存不足等)……
- 业务影响因子:从完整场景去拆分、哪些细化环节会影响到业务稳定性指标的因子,如残余、唯一性、配置错误(如dns、配置项错误)、依赖第三方组件(版本、存在与否、新旧版本)、集群多样性(不同运营商等)、权限……
- 其他影响因子:异常操作(如随机触发、快速多次操作、升级兼容)、大量数据、批量操作、资源扩容、数据量(查询、调用等)……
六、稳定性处理逻辑
以下举例一些思路供大家参考:
- 失败重试,重试次数
- 通过定时检测发送告警,运维介入修复(消息堆积、资源不足)
- 定时巡检,拉起或修复(如服务,第三方)
- debug打点,便于及时排查优化
- 结合业务量冗余情况,通过某些方式限制访问量
- 非关键配置不强制检验,使用默认值或忽略输出错误信息
- 异常数据容错,使用默认值
- 预取、缓存一些内容,提升业务响应速度
- 异常或并发、批量操作合理性
- 资源不足可以通过比较动态方式交互提醒、做预判断
- 日志、备份数据、其他数据需要考虑回滚,清理机制,数据持久化(重启不丢失)
- ……
七、稳定性测试方法举例
- 测试检验完整性,如删除是否干净,资源使用准确性,多平台信息是否一致性
- 数据清理跟回滚,需要关注默认等级、日志/数据产生速度、回滚生效、清理生效
- 脚本重复操作,统计业务成功率及平均时间
- 阶段并发操作,关注并发操作成功率
- 基础扩容(机器、资源)基本功能正常,机器类别变更
- 验证基础依赖缺失或错误情况,检验方式及强弱,提示告警等信息
- 制造服务异常或外部导致服务异常,验证自启动或外部阻碍清除后服务正常
- 验证内存是否回收,是否内存泄露
- 极限检验
- 其他根据稳定性质量点形成测试方法
八、稳定性部分参考工具
- 网络质量设置工具:iptable
- cpu跑高工具:stress、sysbench
- io跑高设置工具:fio
- 内存:memtester
- openstack环境使用的网络性能测试工具:shsker
九、稳定性文章学习
http://blog.youkuaiyun.com/weixin_33782386/article/details/91418601blog.youkuaiyun.com http://blog.soliloquize.org/2019/09/07/%E5%85%B3%E4%BA%8E%E5%AE%B9%E7%81%BE%E5%A4%84%E7%90%86%E7%9A%84%E4%B8%80%E4%BA%9B%E6%80%9D%E8%80%83/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.ioblog.soliloquize.org 社区 · TesterHometesterhome.com