软件测试自我学习总结：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

4.3、吞吐量：

5.2、平均吞吐量对比：

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

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

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

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

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