毕设-大促质量保证测试方案

大促质量保证测试方案

一、背景介绍

针对淘宝双十一大促销售活动的场景,承接活动期间高峰流量,保证App端、web端系统运行稳定,让业务活动顺利开展。

二、业务介绍

常规购买流程

优惠活动类

限时秒杀类

三、架构介绍

四、测试策略

1 功能测试

  1. 下单接口对各主要字段进行验证

  2. 支付接口各主要字段进行验证

  3. 重点关注接口幂等性

  4. 扣减防重

  5. 防超卖

  6. 接口防刷

  7. 限流(接口限流,前端限流)

  8. 服务降级验证

  9. 库存回退等极端场景

  10. 回归验证主流程

2 兼容性测试

大促活动涉及App、web两类终端,根据数据埋点收集的设备数据,覆盖兼容性如下:

2.1 App端

iOS/安卓(手机、iPad…)

分辨率

2.2 Web端

浏览器(Safari、Chrome、Firefox…)

分辨率

3 自动化测试

3.1 UI自动化

背景:随着大促的到来,版本功能越来越多,有大量的重复性工作,传统的手工测试效率低。

目标:保证功能稳定性、降低测试成本、提高效率。

测试范围:主要功能、业务流程测试P0、P1级用例(如商品展示、加购物车、下订单等)

测试工具选择:以appium 为核心,jenkins实现持续集成,并选取python 作为编程语言实现。

测试框架设计

1、UI变动,维护成本大:基于PO设计模式,每一个页面封装一个page,

2、测试数据不好维护,测试数据抽离放在yaml中

3、测试结果记录,将日志、截图封装到框架中

测试执行

针对本地执行不稳定,docker部署使用jenkins服务执行

冒烟测试:执行P0级别功能测试用例,100% 通过,测试完成自动发送邮件给相关人员

回归测试:全量执行,100%通过

定时执行:每天下班定时执行测试脚本

单设备执行效率慢,STF管理设备,多设备分布式执行脚本

成果:测试覆盖率:40%,提升了了30%测试效率,线上故障率减少5% 。

3.2 接口自动化

背景:随着大促的到来,版本功能越来越多,传统的手工测试效率低,存在漏测情况

目标:保证功能稳定性、提高效率。

测试范围:针对于所有的接口去做全量覆盖(单接口、业务流程)
测试工框架选择: python+requests+pytest+allure

测试框架的设计:

1、 脚本不易维护:使用分层和封装, 把接口信息和测试用例解耦。

2、 大量地测试单个接口时会存在依赖调用的问题::基于业务进行高度抽象,用例通过流程进行组合,实现解耦。

2、有多套测试环境:通过环境变量与配置文件解决环境切换

3、支付调用的第三方接口,不方便调试:使用mock实现第三方接口调用
4、测试结果记录,将日志封装到框架中

测试执行

针对本地执行不稳定,docker部署使用jenkins服务执行

冒烟测试:执行P0级别功能测试用例,100% 通过

回归测试:全量执行,100%通过,测试完成自动发送邮件给相关人员

定时执行:每天下班定时执行测试脚本

成果:提升效率50%,减少线上故障20%。

4 性能测试

4.1 测试背景及目标

背景:大促期间,需要承接的流量比平时更大,对系统稳定性的要求更高。

目标:

  1. 保证大促正常开展;

  2. 保证用户大促期间抢购体验;

  3. 保证商品不少卖、不超卖;

4.2 测试范围

4.2.1 单接口范围

范围识别策略:

  1. 功能优先级P0;

  2. 查询类接口(商品查询、订单查询…);

  3. 业务类接口(加购物车接口、下订单接口…);

接口列表:

4.2.2 场景接口范围

范围识别策略:

  1. 功能优先级P0;

  2. 场景涉及跨服务、系统的逻辑交互;

场景列表:

涉及接口列表:

4.2.3 性能测试点

大促时,并发场景下需保证商品、订单数据等的完整性、准确性,以及库存数据的准确性。

测试点:

  1. 用户并发数<库存数,非超卖场景,正常校验数据;

  2. 用户并发数>库存数,超卖场景,校验是否超卖;

  3. 用户并发数=库存数,正常售罄,正常校验数据;

  4. 限时秒杀;

4.3 性能测试准备

4.3.1 环境准备

性能环境配置4C

数据库配置 xxx

4.3.2 数据准备

商品数据1000w

订单数据3000w

用户账号数据 1000w

4.4 性能测试指标

4.4.1 性能指标分析

方法一:运维监控线上数据收集

方法二:二八原则(需先从业务、产品人员处获取相关数据)

方法三:预估业务增长,增加buffer

收集源数据如下:

4.4.3 性能测试指标

并发数、TPS、平均相应时间、错误率

资源利用率:CPU占用率、数据库占用率<=80%

4.5 性能执行策略

  1. 脉冲压测:按照设定模型,脉冲至最高点,模拟大促当天零点流量脉冲;

  2. 摸高:关闭限流,往上摸高,直到系统扛不住为止;

  3. 限流验证:在摸高稳定状态下,打开限流,看各个系统限流能否将当前流量限制为预定值;

  4. 破坏性测试:压力保持在峰值,执行各个紧急预案,验证预案是否满足预期;

4.6 高可用测试

大促期间,为保证系统响应速度,重度依赖redis做数据缓存。

4.6.1 缓存击穿

范围:商品数据、优惠数据

热key,频繁请求,手动设置缓存失效/过期

4.6.2 缓存穿透

使用不存在的key,频繁请求。

五、测试计划

1 阶段一

1.1 目标

保证功能正常、正确,快速交付版本。

1.2 采用测试策略

  1. 单元测试

  2. 功能测试

2 阶段二

2.1 目标

建立在大部分功能正常、环境稳定之上,接入性能、兼容、安全等专项性测试。

2.2 采用测试策略

  1. 性能

  2. 兼容

  3. 安全

3 阶段三

3.1 目标

在大部分功能稳定、保证交付速度的基础之上,逐步建立自动化测试,提高冒烟、回归环节测试成本。

3.2 采用测试策略

  1. 自动化测试(UI、接口)

  2. CI/CD

五、测试目标

11.11保证开卖

1 Like