产品稳定性测试报告撰写思路(更新版)
第1章 引言.... 5
1. 编写目的... 5
2. 测试背景... 5
3. 参考资料... 5
第2章 测试活动概述.... 5
第3章 测试环境概述.... 6
1. Linux（Suse＋DB2＋WAS）公司推荐环境[简称：测试环境一] 6
3.1.1 WEB服务器... 6
3.1.2 数据库服务器... 6
3.1.3 客户端... 6
2. Windows(Windows 2K Server SP4+DB2＋WAS)排查内存问题[简称：测试环境二]. 6
3.2.1 WEB服务器... 6
3.2.2 数据库服务器... 6
3.2.3 客户端... 6
3. 网络环境... 7
4. 测试包信息... 7
5. 测试环境拓扑图... 7
6. 中间件及数据库参数设置... 8
3.6.1 中间件参数设置... 8
3.6.2 数据库参数设置... 8
7. 测试数据的分布... 8
第4章 测试过程评价.... 9
1. 实际情况与目标... 9
4.1.1 2006年9月11-9月15日测试... 9
4.1.1.1 测试背景... 9
4.1.1.2 测试场景... 9
4.1.1.3 参数设置... 9
4.1.1.4 测试结果... 9
4.1.1.5 监测结果... 13
4.1.1.6 数据结论... 15
4.1.2 2006年9月18-9月22日测试... 15
4.1.2.1 测试背景... 15
4.1.2.2 测试场景... 16
4.1.2.3 参数设置... 16
4.1.2.4 测试结果... 16
4.1.2.5 监测结果... 23
4.1.2.6 数据结论... 26
4.1.3 2006年10月17-10月22日测试... 26
4.1.3.1 测试背景... 26
4.1.3.2 测试场景... 27
4.1.3.3 参数设置... 27
4.1.3.4 测试结果... 27
4.1.3.5 监测结果... 33
4.1.3.6 数据结论... 33
|
测试
场景
|
测试
类型
|
测试
日期
|
测试
内容
|
|
场景一
|
复合
场景
（综合）
|
2006
9-11
至
9-15
|
验证产品是否可连续运行1年以上，以测试基准数据进行估算，并结合实际项目的公文数量与用户总量进行估算，以求把产品的性能结果应用于项目的实际估算中。
|
|
场景二
|
附件
上传
（单独）
|
2006
9-18
至
10-12
|
验证前期在Linux下出现多次Was服务器宕机问题（在Windows下使用JProbe对JVM堆栈进行观测，并配合研发中心查找内存泄漏原因）
|
|
场景三
|
发送
组件
（拆分）
|
2006
10-17
至
10-24
|
针对前期复合场景及附件上传场景中频繁出现的Was服务器宕机行为，与研发中心沟通后把初时的附件上传脚本拆分为两个独立组件以进行后续排查性测试，为研发中心定位及排查问题提供理论依据。
|
|
场景四
|
上传
组件
（拆分）
|
2006
11-3
至
11-4
|
针对前期复合场景及上传中频繁出现的Was宕机问题，结合以进行发送组件测试。为求进一步缩小对产品内存泄漏问题的追踪，辅助研发中心对产品稳定测试给予综合结论。
|
|
场景五
|
附件
上传
（单独）
|
2006
11-13
至
11-14
|
针对前期排查性测试中未发现Was宕机和其它服务器异常行为，在已进行后续测试中对测试服务器环境进行重新部署及优化。从而排除了由测试环境配置问题而导致性能问题。
|
|
场景五
|
复合
场景
（综合）
|
2006
11-15
至
11-16
|
在以优化的测试环境中，重新赋予同测试用例、同数据量条件下复合场景测试。针对前期测试当中频繁发生Was宕机行为，从测试策略角度出发重新调整了内存堆栈截取策略。由此，进一步降低了由不正当的使用内存片段，而对产品性能造成的影响。
|
以下截取了其中一个场景的测试分析:
1.1.1 2006年9月18- 9 月22 日 测试
1.1.1.1 测试背景
本次稳定性复合场景测试，按照原定计划针对第一轮测试中Was宕机行为，进行进一步观测。在实际测试中，继续使用JProbe Memroy Debug工具对Windows下Was应用服务器进行长期监测。并调整了整个监视过程中，Debug工具的使用策略。即在Was服务器启动后1－1.5小时内，只在LoadRunner脚本运行后5－10分钟内截取一个SnapShot片段，以此作为BaseLine基准为后续片段提供比对依据。并在前期每20分钟做一次聚吸整理的基础上，调整为每40分钟做一次聚吸操作并结合实际测试情况合理调整SnapShot获取时间。在本次测试中，加入了对JProbe Memory工具Use Case的使用。该功能可以对长期监测过程中基础类及包数据进行定期截取，从而使得测试服务器在进行SnapShot内存快照时有良好的延展性。避免由于直接使用聚吸操作而造成的Was服务器宕机行为，影响测试监测结果。
1.1.1.2 测试场景
| 场景设计 |
事务点 |
集合点 |
|
| 登陆系统 (Login Transaction) |
①登陆系统 ②登出系统 |
登陆按钮 |
|
| 新建公文 (NewDoc Transaction) |
①登陆系统 ②新建公文 ③登出系统 |
新建公文 |
|
| 打开公文 (OpenDoc Transaction) |
①登陆系统 ②代办页面 ③打开公文 ④登出系统 |
点击公文 |
|
| 发送公文 (SendDoc Transaction) |
①登陆系统 ②新建公文 ③添加正文 ④上传附件 ⑤发送公文 ⑥登出系统 |
发送按钮 |
|
| 保存公文 (SaveDoc Transaction) |
①登陆系统 ②新建公文 ③添加正文（50K） ④上传附件（ 1M ×2） ⑤保存公文 ⑥登出系统 |
保存按钮 |
|
| 新建个人日程 (NewData Transaction) |
①登陆系统 ②个人事务 ③新建个人日程 ④提交个人日程 ⑤登出系统 |
提交按钮 |
|
1.1.1.3 参数设置
1. 应用服务器参数：请参考《ExOA（J2EE）版产品稳定性测试计划》
2. 数据库服务器参数：请参考《ExOA（J2EE）版产品稳定性测试计划》
3. 测试场景参数：
Ø 并发用户数－45人
Ø 测试环境－测试环境二
Ø LoadRunner监视服务器：
1) 172.16.14.98（数据库服务器）
2) 172.16.14.151（应用服务器）
3) 172.16.14.146（加压机）
1.1.1.4 测试结果
测试运行：2小时50分（小时）
附件上传：1227（份）
新建公文：613（份）
新建个人日程：634（条）
1. 平均事务响应时间：
图表 11：第二轮测试-复合场景各事务平均响应时间
如上图所示，在服务器运行00:01:25:20至00:01:42:24（秒），该段时间内各事务响应时间均呈放量增长。
注意：在以上排查性验证测试中，均使用Linux应用与Windows应用配合进行的原则进行问题排查。
2. 事务通过率：
图表 12：第二轮测试-复合场景每秒点击率
图表 13：第二轮测试-复合场景吞吐量
图表 14：第二轮测试-复合场景Hit（点击率）与Throughput（吞吐量）
通过以上Hits（点击率）与Throughput（吞吐量）分析，把曲线波动较为剧烈的三段时间取出独立进行分析，由此我们可以计算得出该事务的实际事务通过率下表所示：
1) 时间段一：00:17:04至00:25:36(秒)
图表 15：第二轮测试-复合场景第一段时间各脚本事务通过率
| 事务名称 |
通过率 |
| 登陆事务（Login） |
60.4% |
| 新建公文（NewData） |
100％ |
| 打开公文（OpenDoc） |
100％ |
| 新建个人消息（SendMessage） |
100％ |
| 上传附件1（UploadFile1） |
98.34% |
| 上传附件2（UploadFile2） |
95.79% |
| 平均事务通过率 |
≈92.42% |
2) 时间段二：01:12:32至01:29:36(秒)
图表 16：第二轮测试-复合场景第二段时间各脚本事务通过率
| 事务名称 |
通过率 |
| 登陆事务（Login） |
66.79% |
| 新建公文（NewData） |
100％ |
| 打开公文（OpenDoc） |
100％ |
| 新建个人消息（SendMessage） |
97.63％ |
| 上传附件1（UploadFile1） |
89.70% |
| 上传附件2（UploadFile2） |
90.16% |
| 平均事务通过率 |
≈90.71% |
3) 时间段三：02:25:04至02:50:40(秒)
图表 17：第二轮测试-复合场景第三段时间各脚本事务通过率
| 事务名称 |
通过率 |
| 登陆事务（Login） |
80.05% |
| 新建公文（NewData） |
100％ |
| 打开公文（OpenDoc） |
98.43％ |
| 新建个人消息（SendMessage） |
98.18％ |
| 上传附件1（UploadFile1） |
81.81% |
| 上传附件2（UploadFile2） |
85.18% |
| 平均事务通过率 |
≈90.61% |
3. 发生性能拐点时，事务错误状态分析
结合以上三段时间各事务通过率，我们可以较为清晰的发现登陆事务通过率相对与其它事务而言总事务通过率仅为67.54%，由此我们需对该事务错误进行进一步分析，如下图所示：
图表 18：第二轮测试-复合场景各事务错误状态分析
图表 19：第二轮测试-复合场景各事务详细错误分析
图表 20：第二轮测试-复合场景异常响应与Error -27728超时连接错误(120秒)
由上表可知，在总共1333个错误中有40.56%错误来自于登陆脚本第25行错误。错误代号为：Error -26612，该错误为服务器拒绝请求（HttpServer出现大量500或找不到页面404等）；错误数量：540；通过数据日志及Was服务器日志分析可知发生该问题可能由于并发用户数设置偏高，导致应用服务器与数据库服务器之间出现连接数不足的情况，由此在长时间超时错误后，系统无法有效分配服务器资源与等待连接。由此，导致Was服务器运行过程登陆事务通过较低。
4. JProbe Memory Debug SnapShot 横向数据对比：
1.1.1.5 监测结果
1. 应用服务器综合性能指标（172.16.14.151）：
图表 21：第二轮测试-复合场景应用服务器资源统计
通过对应用服务器实际观测，我们主要从以下三个指标判断服务器的健康情况以及是否肯能出现内存泄漏。
2. %Processor Time：Actual Average Value (≈98.70%) > 80% to 85%
图表 21：第二轮测试-复合场景％Processor Time
3. %Disk Time：Actual Average Value (≈1.607%) << 80% and Max_Value = 80.223% > 80%
图表 22：第二轮测试-复合场景％Disk Time
4. Page/Sec：Actual Average Value (≈1.91 s) << X 00 s (X=1,2,3,4…) and Max_Value = 472.98
图表 23：第二轮测试-复合场景Pages/Sec
1.1.1.6 数据结论
通过以上监测结果，我们可以在一定程度上肯定本次测试应用服务器的健康情况。从以上三个主要性能指标判断，本次测试结果中可能存在内存泄漏。通过JProbe工具对内存堆栈的使用情况的分析来看，部分Class类及包文件有明显的增长趋势。由于，以上趋势较为锐急。由此，需要更进一步的通过场景拆分，分别对该场景内两个组件进行测试。本轮测试结束后，与研发中心产品经理商榷后，决定继续在下一轮分拆组件测试中对之前的数据予以关注。针对本次测试中应用服务器实际运行2小时43分后出现的Was宕机现象，内存堆栈中几个Class有明显增加的趋势。在第三轮场景拆分测试中，我们将试图通过本次数据的实际结果与性能指标，对可能引起发生内存泄漏、Was宕机等问题进一步进行排查。并在一定程序上辅助研发中心了解产品真实的健康情况，在实际测试数据的基础上给予产品发布足够的信心与帮助。