稳定性测试​

1. 长时间运行测试​

1.1 系统在预期平均负载下，持续运行24/72/168小时。

系统无崩溃、无服务中断、无功能异常。核心业务成功率与响应时间保持稳定，无显著性能衰减。

1.2 模拟典型用户操作流，进行长时间（如8小时）的稳定性压测。

业务流程全程无报错，数据产生、处理、展示结果一致且正确。

2. 异常负载与压力测试​

2.1 负载测试：在预期峰值负载下稳定运行1-2小时。

系统资源（CPU、内存、磁盘I/O、网络）使用率处于安全水位，无错误率飙升。

2.2 压力测试：逐步增加并发用户数或请求量，直至系统出现性能瓶颈或错误。

明确系统的最大容量和拐点，观察系统在极限压力下的表现（是否优雅降级或直接崩溃）。

2.3 浪涌测试：在极短时间内（如1秒内）将负载从低值猛增至峰值。

系统能够快速弹性伸缩或处理队列，响应时间在可接受范围内恢复正常，不出现大面积失败。

3. 故障恢复测试​

3.1 服务/进程异常终止后重启。

服务能正常启动，并自动恢复对外提供服务，历史数据和状态可正确恢复。

3.2 依赖的中间件（如Redis、MySQL、消息队列）重启或网络闪断。

系统具备重连机制，在依赖服务恢复后能自动连接，期间业务影响可控（如部分请求失败但可重试）。

3.3 服务器节点重启或宕机（针对集群部署）。

负载均衡能自动将流量切换到健康节点，整体服务可用性不受影响。

4. 资源监控与泄漏测试​

4.1 内存泄漏测试：在长时间或高压力测试下，监控进程内存使用情况。

内存使用率应趋于稳定或呈周期性释放，无持续线性增长。

4.2 连接泄漏测试：监控数据库连接、网络连接、文件句柄等资源。

资源申请与释放匹配，在测试周期结束后，占用数量应回到初始水平。

4.3 CPU占用率监控：在负载平稳期，CPU占用率应保持相对稳定，无异常峰值或持续高占用。

可用性测试​

1. 服务可访问性测试​

1.1 服务健康检查接口（如/health）定期探测。

接口返回状态码为200，且包含的组件状态（DB、Cache等）均为健康。

1.2 核心业务接口/页面定期（如每分钟）访问。

访问成功，且响应内容符合预期，无核心功能缺失。

2. 多实例与负载均衡测试​

2.1 停掉其中一个服务实例。

用户请求能被自动路由到其他健康实例，无感或仅短暂影响。

2.2 新启动一个服务实例。

实例能自动注册到服务注册中心或负载均衡器，并开始接收流量。

3. 容错与降级测试​

3.1 模拟非核心依赖服务（如推荐系统、天气接口）故障或响应超时。

系统能触发熔断或降级策略（如返回缓存数据、静态兜底内容），保证核心主线流程可用。

3.2 模拟核心依赖服务（如用户数据库）慢响应。

系统有超时机制，能防止线程池被占满导致雪崩，并给出友好提示。

专项辅助测试​

1. 性能基准测试​

1.1 在标准测试环境下，对核心接口进行压力测试，记录TPS、平均/95分位响应时间、成功率。

建立性能基线，作为后续版本迭代和稳定性评估的基准。

2. 兼容性测试​

2.1 在不同版本的主流浏览器、操作系统、移动设备上验证核心功能。

功能表现一致，无布局错乱、功能失效等重大问题。

3. 安全与抗攻击测试​

3.1 恶意请求测试：如发送畸形报文、慢速攻击、重复快速请求同一接口。

系统有基本的防护（如参数校验、频率限制），不会因此崩溃或耗尽资源。

1.1 长时间运行测试​

1. 准备：部署基准版本，准备模拟正常流量的脚本。
2. 执行：使用压测工具，以预期平均并发/吞吐量，持续施压72/168小时。
3. 监控：全程记录系统成功率、响应时间、业务核心指标（如订单创建成功率）。
4. 检查：每小时记录一次系统资源（CPU、内存、IO）趋势，检查日志有无异常堆积或错误率攀升。

1. 明确“预期平均负载”的具体数值（如：每秒事务数TPS、并发用户数）。
2. 提供核心业务链路及对应的关键业务指标（如：从登录到支付的转化率）。
3. 协助分析测试中出现的任何业务逻辑错误或数据不一致问题。

1. 提供与生产环境配置一致的测试环境。
2. 提供监控大盘，集成系统（CPU/内存/磁盘/网络）和应用（JVM/慢SQL/错误日志）指标。
3. 协助配置监控告警，当资源使用率超过预设阈值（如CPU>80%持续10分钟）时告警。

1.2 异常负载与压力测试​

1. 阶梯增压：从低负载开始，分阶段增加并发，每阶段稳定运行10-15分钟。
2. 记录拐点：观察响应时间陡增和错误率开始上升的点，记录此时的最大吞吐量和最佳并发数。
3. 极限施压：增加负载至系统完全不可用或错误率超50%，观察系统表现（优雅降级？雪崩？）。
4. 性能分析：在性能拐点处，使用性能剖析工具定位瓶颈（CPU、数据库、某段代码）。

1. 设计负载模型（用户行为比例，如浏览:下单:支付=8:1:1）。
2. 确定性能期望（如：支持不低于XXX的峰值TPS）。
3. 根据测试结果，主导瓶颈分析，并提出优化方案（如：引入Redis缓存、优化SQL）。

1. 准备可快速弹性伸缩的资源池（如云服务器），以支持高压测试。
2. 在压测过程中，实时盯盘，快速提供资源使用详情（如：提供数据库锁等待、慢查询实时列表）。
3. 压测后，协助清理测试产生的垃圾数据。

1.3 故障恢复测试​

1. 制定故障清单：列出要模拟的故障（如：Kill -9 服务进程、重启MySQL、断开网络）。
2. 注入故障：在系统承受一定负载时，执行故障注入。
3. 观察影响：记录故障开始到业务完全恢复的时间，监控业务指标波动。
4. 验证恢复：故障恢复后，验证系统功能、数据一致性是否完全正常。

1. 识别单点故障和关键依赖，确定故障注入的优先级。
2. 设计系统应有的容错行为（如：重试、熔断），并验证其是否按设计生效。
3. 评估恢复时间目标是否满足业务需求。

1. 提供故障注入工具的权限和环境（如：ChaosBlade、网络模拟工具tc）。
2. 执行具体的破坏性操作（如重启数据库、拔网线）。
3. 负责故障恢复操作（如重启服务、恢复网络），并记录操作耗时。

1.4 资源泄漏测试​

1. 基线采样：在系统空载和负载下，分别采样内存、连接数、句柄数作为基线。
2. 长时间负载：执行长时间（如12小时）的压力测试或稳定性测试。
3. 对比分析：测试结束后，在负载释放后静置一段时间，对比资源占用是否回落至基线水平。
4. 堆分析：如果内存持续增长，在测试中或测试后dump内存堆，进行分析。

1. 审查代码中资源使用的关键路径（如数据库连接池、文件流、缓存客户端）。
2. 根据内存dump分析结果，定位可能导致泄漏的代码模块或第三方库。

1. 提供资源监控工具，能持续跟踪进程级别的内存细分（堆/非堆）、TCP连接数、文件描述符数量。
2. 协助在测试环境中获取Java堆转储文件。
3. 模拟线上环境，配置与生产一致的JVM参数和资源限制。

2.1 服务可访问性测试​

1. 配置拨测：在监控系统中，对服务的健康检查接口和核心业务接口配置周期性（如每分钟）HTTP拨测。
2. 设置断言：对返回结果设置断言（状态码为200，响应体包含特定字段）。
3. 统计可用性：统计拨测的成功率，计算服务可用性（如：成功次数/总次数）。

1. 明确必须监控的核心业务接口清单及其健康定义。
2. 设计并提供标准的健康检查接口，能反映服务及其关键依赖（DB、Cache）的状态。

1. 实施拨测配置，将拨测点部署在多个地域的网络节点。
2. 设置可用性告警（如：5分钟内成功率低于99.9%则告警）。
3. 提供拨测的历史数据和报表。

2.2 多实例与负载均衡测试​

1. 标记实例：在负载均衡器或监控中，标记出A、B两个后端服务实例。
2. 流量观察：观察流量是否均匀分发到A、B实例。
3. 摘除实例：从负载均衡中摘除或直接停止A实例。
4. 验证影响：验证用户请求是否全部由B实例处理，业务是否中断。
5. 恢复实例：恢复A实例，观察流量是否自动重新接入。

1. 设计服务发现与注册机制。
2. 定义实例健康检查的规则（如：连续失败几次标记为不健康）。
3. 评估单实例容量，以确定在实例故障时，剩余实例能否承受全部流量。

1. 操作负载均衡器（如Nginx, SLB, K8s Service）进行实例的摘除和挂回。
2. 监控在故障切换期间，业务请求的失败率和延迟变化。
3. 记录故障切换和服务恢复的完整时间。

2.3 容错与降级测试​

1. 模拟依赖故障：对指定的非核心依赖（如积分服务、推荐接口）进行故障注入（如：超时、返回500错误）。
2. 验证降级逻辑：观察主业务是否触发了预设的降级策略（如：返回本地缓存、默认值、友好提示）。
3. 验证熔断逻辑：连续模拟故障，观察系统是否会在一定次数后“熔断”，快速失败，不再调用故障依赖。
4. 恢复验证：停止故障注入，验证系统是否能自动或手动恢复对该依赖的调用。

1. 设计降级和熔断策略，并明确在代码/配置中的开关和参数位置。
2. 定义每个非核心依赖的降级后返回内容（静态数据、上一次缓存等）。
3. 评审测试结果，优化熔断器参数（如：错误阈值、熔断时间）。

1. 在测试环境中，对目标依赖服务进行故障模拟（如使用代理工具模拟超时和错误）。
2. 监控在熔断器打开/半开/关闭状态切换时，系统的流量和错误日志变化。
3. 协助配置和操作降级开关（如配置中心）。

3.1 性能基准测试​

1. 环境固化：确保测试环境、代码版本、数据量、测试脚本完全固定。
2. 执行测试：使用统一脚本，执行压力测试。
3. 记录数据：记录TPS、平均响应时间、P95/P99响应时间、错误率、资源使用率等关键指标。
4. 建立基线：将本次结果作为“性能基线”保存，并与历史版本对比。

1. 定义性能基准指标及其合格线（如：核心接口P99<800ms）。
2. 任何可能影响性能的架构或代码变更前，通知测试团队进行基准测试回归。

1. 保证测试环境的纯净与独占性，避免其他任务干扰测试结果。
2. 提供基准测试报告模板和数据存储位置（如：将结果自动录入数据库或监控系统）。

3.2 安全与抗攻击测试​

1. 构造恶意请求：使用工具构造并发送畸形报文、超大请求体、慢速HTTP请求、高频重复请求等。
2. 观察系统状态：监控服务进程的CPU、内存、连接数，观察是否异常增长或耗尽。
3. 验证防护效果：检查请求是否被正确拦截（返回4xx错误）、限流（返回429错误），后台是否记录攻击日志。

1. 在设计层面明确安全边界和防护点（如：输入校验、频率限制应在哪一层实现）。
2. 评估攻击测试结果，并设计加固方案（如：增加WAF规则、优化参数校验逻辑）。

1. 在测试环境部署/配置网络层防护工具（如防火墙、WAF）并进行规则测试。
2. 监控系统底层资源（如连接数、文件句柄），这些指标比应用层更早反映出资源耗尽型攻击。