公司xy项目真实第一轮测试报告总结

欣意系统性能测试计划

1 引言

1.1 背景

在上线前进行针对性的测试,评估及找出性能问题并及时的改正,呈现给用户一个快而好的系统

2 计划

1、 由于该系统为新系统,没有线上数据供参考无法指定性能指标,所以通过数据库查询老员工商城的数据量为参考依据3万数据量

2、 编写测试脚本来制造铺底数据,制造那些铺底数据 需要经过开发讨论评审后方可实施

3、 通过员工商城的数据参考,来指定我们的铺底数据,首先要系统到达一定的数据量后,在进行性能测试

4、 性能测试实施过程记录测试数据及问题,协助开发定位问题并反馈给开发(禅道建bug),

5、 问题修复后继续复测,复测后的数据指标 与产品、开发、及领导进行评估,评估通过后进行上线

3 测试资源

3.1 人员安排

角色 人员安排 任务描述 备注
组长 刘建强 1、负责组织制订性能测试方案(计划)
2、负责组织实施性能测试工作;
3、负责报告编写;
4、负责组织项目各阶段里程碑(基线)的评审活动;
5、负责对项目方案(计划)的实施跟踪。
测试人员 刘建强、常楚楚 1、维护该项目测试环境,确保环境可以实施测试(test5);
2、准备前期的铺底数据,编写构造数据脚本及压测脚本;
3、执行测试脚本
4、记录测试结果和问题反馈,编写《测试报告》。

3.2 测试工具

本模板中提出的工具均根据实际情形尽心更换

测试任务 工具 备注
测试计划 办公软件
测试报告 办公软件
铺底数据准备 Jmeter或python脚本
性能测试 Jmeter、skywalking、prometheus、arthas

3.3 测试进度

任务安排 测试人员 时间节点 负责人 备注
熟悉需求 刘建强、常楚楚、刘雨轩 2021\12\3
构造铺底数据,编写脚本及调试 刘建强、常楚楚 2021\12\6-2021\12\7 包含编写及调试的时间 编写过程中阻塞bug,等待开发更改bug时间 刘建强 该阶段过程中发现的bug,已反馈功能测试
脚本评审及优化脚本 刘建强、常楚楚 2021\12\7 石伟 评审通过! 被测接口14个,其中管理端8个,用户端6个
代码部署测试5环境 无需测试人员 2021\12\7-2021\12\09 石伟、许斌 image.png
创建商品数据 刘建强、常楚楚 2021\12\08 刘建强 批量构建商品数据、构造订单数据及售后订单数据
性能压测 刘建强、常楚楚、刘雨轩 2021\12\21 刘建强 中间的时间排查商城TPS抖动问题,暂停了该项目

4 测试策略

4.1.1 目标

1、 采用增压方式进行压测,找到性能拐点给出当前接口的最大TPS及响应时间

2、 压测过程中找出一些代码层影响性能的问题点反馈给开发进行改正

4.1.2 确定测试业务

和开发团队一起确认需要测试的页面/接口(开发评审通过)

管理端:

Ø 首页获取订单列表接口:api/gm-mgmt-api/order/list

首页进入后就调用该接口,压测铺底数据量为3万(参考员工商城一年的量),入参无需参数化

Ø 首页获取售后列表接口:api/gm-mgmt-api/after-sale/list

首页进入调用该接口,与开发讨论铺底数据量100左右即可,无需参数化入参

Ø 订单中心商品详情页面:

1、 详情接口:api/gm-mgmt-api/order/detail?orderNo=${orderNo}

通过list页返回值获取orderNo,在进行参数化处理保证压测过程中数据可变

2、 获取订单信息: api/gm-mgmt-api/order/logistics/${orderId}

参数数据来源同上

3、 查询发货单中物流信息:api/gm-mgmt-api/order/logistics/pack

入参:{"orderNo":"${orderNo}","logisticsNo":null,"orderDeliveryNo":"${orderDeliveryNo}"}参数数据来源同上

Ø 售后中心商品详情接口:api/gm-mgmt-api/after-sale/${id}

获取售后中心list中的返回值ID进行参数化

Ø 订单中心商品详情接口:api/gm-mgmt-api/order/list

通过返回值total计算分页值参数化入参 pageNum

Ø 订单中心商品详情接口:api/gm-mgmt-api/after-sale/list

员工端:

Ø 首页获取首页装修:api/gm-staff-api/m/malldecoration/definition/query

Ø 首页获取列表接口:api/gm-staff-api/m/sku/mall/30118/list

Ø 商品详情页接口:api/gm-staff-api/m/sku/mall/30118/sku/${skuid}

Ø 商品详情_integral:api/gm-staff-api/m/malluser/integral

Ø 购物车_判断价格变动接口: api/gm-staff-api/m/order/30118/item-confirm

脚本动态生成购物车入参数据

Ø 购物车_info信息:api/gm-staff-api/m/cart/info

5 测试报告

5.1.1 员工端

5.1.1.1 员工端-商品详情页接口

接口时间消耗平均在1.3s左右导致TPS不是很高只有75,由于先排查问题线程没有给到很高只给了30 image.png 拆分响应时间,问题定位,从左侧可以看出时间消耗1.3s左右其中该接口projectlist耗时460ms image.png 还有一个mysql占用时间为489ms 两个耗时加起来1s出头占比很高。先解决慢sql image.png image.png DBA优化慢SQL后再次压测,可以看到左侧的时间由原来的1.3s左右降到了600ms左右 image.png 同样的压力下TPS到了300左右 优化前是75左右提升了75% image.png 600ms下通过skywalking查看一个是file服务的查询文件列表,一个是mapping服务的list image.png 还有一个mapping服务查询数据接口后面也是查询数据库 佳文查询代码与数据库已是最优状态 image.png 增加压力后压测60线程TPS稍有提升 image.png 增加100线程后TPS表现与60线程TPS基本一致 image.png 在增大线程后问题表现更明显,追踪链路可以看出商品详情接口耗时较高占用了1.04s占比较高 image.png image.png image.png 总结:springMVC获取详情接口耗时较长,可能原因为tomcat线程池造成拥堵,需要更改gm-staff-api的tomcat线程池,随着压力增加会有一些3s左右的接口耗时,查看发现是商品服务getskudetail接口耗时较高,与佳文讨论后因为detail接口返回数据过多,员工端用不到这么多,后续可能需要定式化开发相应的接口在做测试

5.1.1.2 员工端-首页压测

多次压测,发现TPS较低,且波动较大 image.png 监控线程池占用,发现有阻塞情况 image.png 查看io 发现io w_await高点 15%左右,整体io的使用率不高 image.png

查看服务器资源使用情况,发现内存使用率较高 image.png order服务占用7个G内存,将内存降为6个G image.png 又降低商城的服务实例数,再进行压测 image.png User鉴权服务耗时较高 image.png 总结:user服务鉴权,没用fein,SpringRestTemplate没有连接池 优化后压测

优化内容:

1、 mongo索引优化

2、 mongo连接池配置的优化 image.png

5.1.2 管理端

5.1.2.1 管理端-首页压测

通过三次不同的压力场景下进行压测TPS最高到310左右tps,平均285tps image.png 查看skywalking耗时情况,发现售后列表耗时较长,查看该接口调用链路,

com.leading.gmcoreservice.aftersale.domain.service.impl.MgmtAfterSaleServiceImpl.findOrderAfterSaleList

方法和/after-sale/list接口耗时较长

com.leading.gmcoreservice.aftersale.domain.service.impl.MgmtAfterSaleServiceImpl.findOrderAfterSaleList经开发排查代码初步定位为资源问题和数据库连接导致的耗时长

image.png /after-sale/list,开发排查初步定位为网关,当前网关用的是Hystrix,没有用http线程池,当前系统使用的旧网关,后续升级为新网关后会启用http线程池,节约大量的3次握手和4次分手的时间,提升吞吐量 image.png 首页订单列表 查看链路,耗时主要在user鉴权服务上,经开发排查user服务鉴权,没用feign,SpringRestTemplate没有连接池

image.png image.png 增加了线程池代码后再次压测之前user鉴权问题已不存在。现在耗时主要还在findOrderAfterSaleList接口 image.png

5.1.2.2 管理端-订单中心商品详情_压测

image.png image.png image.png image.png

5.1.3 问题梳理:

1、 员工端详情接口存在慢SQL在DBA优化后对TPS提升明显

2、 员工端详情接口长时间压测过程中,商品服务的getskudetail接口耗时较大,与佳文讨论由于detail接口本身干的事很多,该项目不需要调用该庞大接口所以先定式化一个接口减少自身时间消耗,getskudetail接口后期不忙时在做优化处理,在定式化接口开发完后在压测如果还有耗时较长的情况考虑修改线程池

3、 User鉴权服务耗时较大,鉴权接口是通过SpringRestTemplate发起的请求,怀疑是没有配置连接池,导致每次都创建新的连接,造成的接口耗时,该问题属于共性问题,优化后问题修复

4、 网关耗时较大,当前网关用的是Hystrix,没有用http线程池,当前系统使用的旧网关,后续升级为springcloudgateway网关后会启用http线程池,节约大量的3次握手和4次分手的时间,提升吞吐量

5、 具体的接口耗时以反馈给开发需做进一步的排查定位

6、 Mongo没有增加索引,没有连接池,现均已优化