测试脚本容错能力需主动注入典型故障并验证预期行为：服务不可达、磁盘满、配置损坏、进程假死等场景下，检查降级、重试、告警等逻辑；并发与冷却机制、日志可追溯性、参数校验及沙箱兼容性均须覆盖。
测试和验证脚本的容错能力，关键不是等它出错才看反应，而是主动制造典型故障场景，观察脚本是否按预期降级、阻断、重试或告警。核心在于“可控注入异常 + 明确预期行为”。
构造真实失败场景来触发容错逻辑
脚本的容错机制（比如重试、跳过、回退、锁保护）只在特定错误下激活。需针对性模拟这些错误：
-
服务不可达：停掉目标服务（
systemctl stop nginx），或用防火墙拦截端口（iptables -A OUTPUT -d 127.0.0.1 -p tcp --dport 8080 -j DROP），再运行脚本，确认它不卡死、不误判、能识别超时并执行重试或退出 -
磁盘满/权限不足：用
dd if=/dev/zero of=/tmp/fill bs=1M count=2000占满临时空间；或chmod -w /var/log撤销日志目录写权限，验证脚本是否提前检查并报错退出，而非在写日志时崩溃 -
配置文件损坏：手动改坏配置（如删掉一个
}或加非法字符），运行含nginx -t或myapp --config-test校验步骤的脚本，确认它捕获失败、不继续重启 -
进程假死：启动服务后用
kill -STOP $PID暂停其运行，此时ps仍显示进程存在，但curl -sfL --max-time 3 http://localhost/health应超时——脚本必须依赖健康检查而非仅查进程，才能正确判定需重启
验证并发与重复触发的安全性
高可用脚本最怕“雪崩式重启”，要确认它真正串行化且有冷却机制：
- 用
for i in {1..5}; do ./restart.sh & done; wait并发拉起 5 个实例，检查/var/lock/restart_script.lock是否生效（只有一条重启日志，其余立即退出） - 连续快速执行脚本两次，中间间隔小于设定的冷却时间（如 20 秒），第二次应直接退出并记录“too soon”类提示
- 手动删除锁文件后再次触发，确认脚本能重建锁并继续，而非因残留状态失败
检查日志与状态快照是否完整可追溯
容错不是静默吞错，而是留痕归因。验证点包括：
- 每次健康检查失败，日志中是否包含原始响应（如
"Health check failed: timeout"或"status: down"），而非笼统的“服务异常” - 重启前是否记录资源状态：如磁盘使用率、端口占用情况、内存剩余量，且格式统一可被后续分析脚本提取
- 失败达到上限（如 3 次）时，是否写入独立告警日志（如
/var/log/restart_alert.log），并包含时间戳和终止原因 - 所有日志是否带明确标识（如
logger -t "auto-restart"），方便用journalctl -t auto-restart快速过滤
用参数校验和沙箱环境做安全边界测试
防止脚本自身成为风险源：
- 传入危险参数测试：如
./restart.sh "../etc/shadow"、./restart.sh "prod; rm -rf /"，确认脚本拦截非法字符或路径遍历，不执行后续操作 - 空参数、少参数、非法选项（如
-x）触发时，是否输出清晰用法提示并退出，而非继续执行默认逻辑 - 在非 root 用户下运行需特权的操作（如
nginx -t），确认脚本检测权限失败并友好提示，而不是静默失败或报错中断 - 在容器或 chroot 沙箱中运行脚本，验证其依赖命令（
flock、lsof、curl）是否齐全，缺失时能否降级处理或明确报错
