软件测试自我学习总结：web性能测试

软件测试（性能测试）：初学

一、性能测试方案：
1、 用户体验角度：从登陆到诊断记录模块，所有业务功能模块测试一轮。观察其每个页面的响应时间。
2、 单用户：运用测试脚本，跑一下主要业务流程，主要重点是诊断记录模块。监控系统性能指标。
3、 多用户：多用户并发，持续加压测试。主要测试诊断记录模块，监控系统性能指标进行对比。

二、测试场景
场景一：
1、用户体验角度测试：手动点击每一步主要流程，分析大概页面功能响应时间。模拟用户操作，总结用户体验效果给出用户体验报告。遵循2、5、8响应时间原则。操作后2s内响应为“优秀”5s内响应为“良好”8s以外响应为“差”。考虑局部地区、电脑配置和网络等问题，最低要求平均响应时间不能超过8s。以确保用户体验良好。
2、具体数据角度测试：使用测试工具模拟用户操作，把每一步操作量化，给出具体响应时间。并给出性能测试报告，用以分析该项目是否达到用户体验的心里预期接受响应时间。
场景二：
1、运用自动化测试脚本：在单用户条件下模拟用户登录、诊断信息（新建）、诊断信息（空数据）、诊断信息（满数据）、各模块数据增删改查。监控系统监控系统资源：CPU、I/O、FPS、平均响应时间、系统资源利用率（CPU利用率）、系统处理能力（TPS）、吞吐量、内存使用率等数据。
场景三：
1、运用自动化测试脚本：多用户（20）条件下多次压测模拟用户登录、诊断信息（新建）、诊断信息（空数据查看）、诊断信息（满数据查看）、各模块数据增删改查。监控系统监控系统资源：CPU、I/O、FPS、平均响应时间、系统资源利用率（CPU利用率）、系统处理能力（TPS）、吞吐量、内存使用率等数据。

三、测试设计：
1、 此次性能测试涉及的模块为：诊断记录的优化后的效果。
诊断记录：
1、 综合睿云项目而言：由于涉及单机版本的优化和当前版本主要8个账号数据的验收。目前暂定压测20个用户并发梯度压力测试，当所有用户加载完毕后连续运行15分钟；
场景一：
序号 、模块 、并发量（在线用户）、 执行时间
1 、登录、 1 、 15
2 、诊断记录、 1 、15

场景二：
序号 、模块 、并发量（在线用户）、 执行时间
1 、登录、10 、15
2、诊断记录、 10 、15

场景三：
序号、 模块 、并发量、（在线用户）、 执行时间
1、 登录 、20、 15
2 、诊断记录、（无数据）、 20、 15
3 、诊断记录、（满数据）、 20、 15

备注：主要测试的诊断记录模块：分为患者下诊断记录空数据状态和患者下诊断记录内每个模块的功能都已添加，量表已经使用脚本在该患者下创建了所有量表数据（156张）状态下

四、场景一：（无基础数据）梯度压力测试分析
4.1平均响应时间梯度对比
事务、 单用户、 10用户、 20用户
登录、 5.8、 6.5、 7.8
诊断记录（空数据）、 1.0 、1.3 、1.5

平均响应时间分析：
从上图中可以看出，各操作的响应时间随着用户数的增加呈上升趋势，除登录页面的响应时间5S，主要页面诊断记录时间没有超过5s在接受范围内。

4.2、%CPU占用率：

%CPU占用率分析：
在上图中我们可以看出单用户、10用户及20用户在诊断信息数据为空时，CPU利用率均在正常范围内，系统表现良好

4.3、吞吐量：

图表 1-诊断信息（单用户无数据）

图表 2-诊断记录（10用户无数据）

图表 3-诊断记录（20用户无数据）

系统处理能力分析：
可以看出，在无基础数据的情况下，系统处理能力随用户数的增加呈上升趋势，即目前用户数量下系统无性能瓶颈。
4.4、%内存可用空间：

图表 4-诊断信息（单用户无数据）

图表 5-诊断信息（10用户无数据）

图表 6-诊断记录（20用户无数据）
% 内存可用空间分析：
可以看出：在诊断记录无数据的情况下，并发用户占用系统内存不大。不影响系统运行效率和性能。

五、场景二：对比测试分析
5.1、平均响应时间对比
用例设计：
模块 、用户数 、数据量
诊断信息、 1 、空
诊断信息 、1 、满数据
诊断信息 、20、 空
诊断信息 、20、 满数据

平均响应时间分析：
同样压力的情况下，在无基础数据的情况下，响应时间均小于5秒。当基础数据量为满数据状态的时候，20用户压力下响应时间有提高趋势，但还在5秒内。符合用户体验效果。

5.2、平均吞吐量对比：

平均吞吐量对比分析：
在有基础数据的情况下，单从处理能力看，依然可以满足客户所提出的要求，但与之前的无基础数据的处理能力比较发现，基础数据的存在是对处理能力有较大影响。

备注： “满数据”测试前使用脚本创建的数据，主要是诊断记录模块，各功能点小功能都添加了至少一项数据，主要是量表模块，新增了全部的量表数据。

5.3、平均CPU占用率对比：

平均CPU占用率对比分析：
在有基础数据的情况下，在线用户数相同，诊断记录模块在各个功能都添加了一轮，尤其是量表模块添加全部量表的满数据状态下，占用系统CPU明显增多，会导致响应时间变长，系统处理能力下降。

六、场景三：诊断记录模块优化前后对比：

平均响应时间调优后分析：
从上表可以看出，诊断记录模块调优后在有数据的情况下，响应时间明显快了很多。在图中我们可以看出调优前后，在相同压力的情况下，响应时间大幅度下降。调优效果明显，已满足响应时间小于5秒的业务要求。此时系统处理能力也有明显的提升。

七、测试结论
1、系统在诊断记录模块无数据的情况下：系统平均响应时间和CPU占用率在调优前后相差不大，主要是由于诊断记录模块调优前后数据接口的调用方式不同，调优前，诊断记录模块是一次性直接调用该模块下所有数据。这样会导致系统平均响应时间和CPU占用率等系统资源偏高。从而影响系统性能。但在无数据的情况、相同压力下系统性能调优前后相差不大。

2、系统在诊断记录模块有数据或者满数据的情况下，系统平均响应时间、CPU占用率和系统吞吐量等系统性能指标，在调优前后有明显差异。调优后主要系统性能指标:响应时间和CPU占用率、吞吐量等有明显的改善。平均响应时间在相同压力和数据的情况下，维持在5S以内，满足需求和用户体验。满足上线要求可以上线。

调优建议：
目前系统诊断记录模块已满足需求，系统响应时间也控制在5s以内。满足上线标准，以下所提建议仅作为系统进一步优化的参考。
1、 患者列表模块：患者列表模块刷新或获取数据的响应时间有待优化，响应时间随患者数量逐渐增加。是否可以考虑在不影响系统主要功能的前提下分批次获取。
2、 在有基础数据的情况下：持续加压新增用户并保持在线用户数量。在25个用户同时并发并保存在线用户数10个，系统出现接受响应信息超时，可能是CPU过高导致的，这种情况需要关注。