软件产品确认测试：系统长期运行稳定性（72 小时）测试

    软件产品确认测试系统长期运行稳定性（72 小时）测试，先搭符合要求的测试环境。硬件配置要和生产环境一致，CPU 型号、内存大小、硬盘容量不能差。我们测过一款服务器软件，用普通 PC 机搭环境，72 小时运行中频繁死机，换和生产一致的服务器后，稳定性明显提升，环境不匹配会导致测试结果无效。​

  设置持续的负载压力  按用户日常使用的平均负载，加上 30% 的峰值负载，持续施加到系统上。比如日常并发 100 用户，测试时设 130 用户持续请求，确保负载接近真实使用场景。我们遇到过只按最低负载测试，72 小时没出问题，上线后峰值负载下崩溃，这种负载设置不合理的测试，不能验证真实稳定性。​

    监控核心系统资源   CPU 使用率、内存占用率、磁盘 IO、网络带宽，每 5 分钟记录一次数据。72 小时内，CPU 使用率不能持续超过 80%，内存不能有泄漏，比如初始占用 2GB，72 小时后涨到 10GB，就是内存泄漏，得记录并让开发排查。我们会用监控工具实时看数据，发现异常先截图，再分析原因。​

    应用服务状态  Web 服务、数据库服务、中间件，72 小时内不能自动停止、重启，也不能出现报错日志。我们测过一个电商系统，运行 48 小时后数据库服务突然断开，查日志是连接池配置不足，这种服务中断属于稳定性问题，必须修复后重测。​

    数据一致性  72 小时持续读写数据，比如每小时批量插入 1000 条数据，同时查询、修改，结束后核对数据总量和内容。有的系统运行中数据丢失，或者查询结果和实际不一致，这种数据问题会直接影响使用，得作为测试失败项记录。​

    系统恢复能力  72 小时内故意断一次网，断 30 秒后恢复，看系统能不能自动重连，数据会不会丢失。我们遇到过断网后系统无法恢复连接，得手动重启服务，这种恢复能力不足的情况，不符合稳定性要求，得优化网络重连逻辑。​

    日志记录要完整  72 小时内的系统日志、应用日志、错误日志，都要保存下来，不能遗漏。后续分析问题时，没有日志就没法定位原因。我们见过测试结束后日志被覆盖，无法排查中间出现的一次短暂卡顿，这种日志管理问题，得提前设置日志存储策略。​

    稳定性指标   72 小时总运行时间减去服务中断、报错的时间，除以 72 小时，得出稳定性达标率，一般要求 99.9% 以上。比如 72 小时内服务中断 10 分钟，达标率约 99.7%，不满足要求，得找出中断原因并修复，重新执行 72 小时测试。​

测试过程中不能中断  72 小时要连续运行，即使遇到夜间或节假日，也得远程监控，不能暂停。我们测过一个项目，中途暂停测试去调整环境，导致测试周期延长，且结果不具备连贯，这种中断测试的情况，会让系统长期运行稳定性（72 小时）测试失去意义。