产品稳定性测试模板

本次产品稳定性测试报告写作思路

1. 本次产品稳定性测试的总体背景

2. 本次产品稳定性测试的方法及策略

3. 罗列已经进行稳定测试种类，并根据测试类型描述该次测试目的，并针对其测试目的给予简单的测试评论

4. 为其它同类型的测试，提供理论依据或为项目组成员提供参考依据，如：前期重新部署包、数据库或其它事项，测试服务器趋于正常。

5. 纵观产品稳定性测试结果，基本达到发布标准，稳定性测试总结论

6. 通过对产品性能分析结果，为项目组成员提供理论推导数据，给予标准的产品估算公式。

本次产品稳定性测试报告提纲内容

公司标准模版目录：

第1章引言 (3)

1.1 编写目的 (3)

1.2 测试背景 (3)

1.3 参考资料 (3)

第2章测试活动概述 (3)

第3章测试环境概述 (3)

3.1 WEB服务器 (3)

3.2 数据库服务器 (3)

3.3 客户端 (4)

3.4 网络环境 (4)

3.5 测试包信息 (4)

3.6 测试环境拓扑图 (4)

3.7 中间件及数据库参数设置 (5)

3.7.1 中间件参数设置 (5)

3.7.2 数据库参数设置 (5)

3.8 测试数据的分布 (6)

第4章测试过程评价 (6)

4.1 实际情况与目标 (6)

4.2 测试完整性评价 (6)

第5章测试结果及分析 (6)

第6章改进建议 (12)

第7章测试总结 (12)

1. 目录：

1) 项目介绍

2) 测试环境系统架构

3) 测试计划与方案

4) 测试分析与结论

a) 测试时间

b) 参数设置

c) 测试结果

d) 监测结果

5) 分析与结论

6) 最终产品发布结论

本次产品稳定性测试报告计划内容

测试场景与用例：

1. 场景一：复合场景（综合），测试目的：验证产品是否可连续运行1年以上，以测试基准数据进行估算，并结合实际项目的公文数量与用户总量进行估算，以求把产品的性能结果应用于项目的实际估算中。

2. 场景二：附件上传（单独），测试目的：验证前期在Linux下出现多次Was服务器宕机问题（在Windows下使用JProbe对JVM堆栈进行观测，并配合研发中心查找内存泄漏原因）

3. 场景三：发送组件（拆分），测试目的：针对前期复合场景及附件上传场景中频繁出现的Was服务器宕机行为，与研发中心沟通后把初时的附件上传脚本拆分为两个独立组件以进行后续排查性测试，为研发中心定位及排查问题提供理论依据。

4. 场景四：上传组件（拆分），测试目的：针对前期复合场景及上传中频繁出现的Was宕机问题，结合以进行发送组件测试。为求进一步缩小对产品内存泄漏问题的追踪，辅助研发中心对产品稳定测试给予综合结论。

5. 场景五：附件上传（单独），测试目的：针对前期排查性测试中未发现Was宕机和其它服务器异常行为，在已进行后续测试中对测试服务器环境进行重新部署及优化。从而排除了由测试环境配置问题而导致性能问题。

6. 场景六：复合场景（综合），测试目的：在以优化的测试环境中，重新赋予同测试用例、同数据量条件下复合场景测试。针对前期测试当中频繁发生Was宕机行为，从测试策略角度出发重新调整了内存堆栈截取策略。由此，进一步降低了由不正当的使用内存片段，而对产品性能造成的影响。

注意：在以上排查性验证测试中，均使用Linux应用与Windows应用配合进行的原则进行问题排查。

本次产品稳定测试报告资源列表

测试时间与结果位置：

1. 场景一：复合场景（综合）

测试时间：大致时间9-11至9-15(根据例会总结，工作周报)

测试结果：

2. 场景二：附件上传（单独）

测试时间：大致时间9-18

测试结果：Memory_2006_10_11

Memory_2006_10_12

3. 场景三：发送组件（拆分）

测试时间：大致时间10-17

测试结果：Memory_10_17

Memory_10_18

Memory_10_19（Memory_new/Memory_new1）

Memory_10_23

Memory_10_24

4. 场景四：上传组件（拆分）

测试时间：大致时间11-3-6：Linux下上传组件测试

测试结果：附加上传Linux下

5. 场景五：附件上传（单独）

测试时间：大致时间11-13：Linux下附件上传测试

11-14：Windows下使用JProbe观测附件上传测试6. 场景六：复合场景（综合）

测试时间：大致时间11-16：Linux下复合场景综合测试测试结果：