一、项目介绍与部署
1.1微商城功能介绍
轻商城是一个电商项目，需要综合评估各个项目各个接口的功能，给出优化建议；
功能框架
- 前台：首页、商品页详情、加入购物车、订单、支付、团购、优惠券；
- 后台：商品管理、会员管理、商城管理
1.2轻商城项目的技术介绍
前端（看得到的部分---HTML、JS技术实现)：
- 微信小程序
- web页面
后端（看不到的部分---通过后端技术代码实现JAVA）：
- 服务器（应用服务器、数据库服务器、后台业务逻辑代码）
1）轻商城是一个支持web和微信小程序的前后端分离的项目。
- 前后端分离可以理解为前端系统与后端分离成两个子项目进行开发：
- 对外表现是：前后端分离项目前端发送请求后响应的内容为json字符串；
- 如果是前后端不分离的项目，响应的是HTML页面
前后端分离的项目与不分离的项目相比：
运行效率高 ：数据传输时只需要传输基本数据即可，不需要传递html格式；
扩展性好：前后端分离是通过数据接口传递，只要借口不改变，前端代码可以添加任何想添加的功能，后端代码也是可以独自加功能，若前后端耦合，加功能需要前后端一起动。
2）前端使用VUE技术框架开发，即支持微信小程序，也支持手机移动端，还支持web页面。
3）后端使用了SpringBoot框架进行开发，MySql做数据库。
4）目前还在开发完善阶段
1.3微商城项目的技术构架
技术构架图：
1.4熟悉数据库设计
在性能测试前需要对要测试的部分业务功能涉及到的数据库表有一定了解；
1）熟悉数据库设计结构，便于后期对数据库的性能监控；
2）性能测试过程中，数据库容易出现瓶颈；
1.5 微商城项目的部署过程
准备工作：
安装JDK
安装MySQL
安装Nginx
安装node.js
项目搭建步骤：
项目部署过程：
二、性能测试需求分析
- 功能测试：关注需求规格中的业务功能（正向、逆向）
- 性能测试：关注系统对特定业务需求场景的满足程度（时间、资源）
- 关注维度：业务功能、项目代码、服务器、硬件配置
-
2.1性能需求获取
1)客户提出（客户可以是甲方，也可以是产品）
- 能够明确提出需求的一般都是金融、银行、电信、医疗相关的行业软件
- 即使是客户提出的需求，需要做初步评估需求的合理性
2)根据历史数据分析(根据软件在运行过程中的运营数据来计算出应该达成的性能指标)
- 日活 —— 初步评估稳定性负载
- 峰值 —— 初步评估压力负载
2.2新能测试点提取
性能测试点提取规则：
轻商城性能测试点提取：
- 1）根据性能测试点的提取规则，结合轻商城项目的功能，整理出要进行性能测试的测试点；
- 2）通过使用前面讲解的获取性能指标的方法（产品给/运营数据计算），得到每个测试点要满足的性能指标
- 3）确定性能测试目标：
- 针对每个核心的业务功能都要求达到对应的性能指标要求
- 基于业务流程（多个接口组合）来测试是否达到性能指标要求
- 模拟用户真实业务场景，进行长时间的稳定性测试
2.3性能测试计划（这部分与上面有重合之处，前面是思考点，最后都要落实在测试计划文档中）
1）测试背景
轻商城是公司新开发的一个电商项目，为了保证项目上线后能够稳定运行，且在后期推广中能够承受用户增长，需要对项目进行性能测试；
2）测试目的
- 确定核心业务功能的TPS
- 对业务流程（多接口组合）进行压测
- 系统能在实际系统运行压力的情况下，稳定运行24小时
| 编号 | 功能模块 | 业务功能 | TPS | 响应时间 |
| T01 | 登录 | 登录 | 20 | 3s |
| T02 | 首页 | 进入首页 | 100 | 5s |
| T03 | 商品 | 搜索商品 | 40 | 3s |
| T04 | 商品 | 查看商品详情 | 100 | 3s |
| T05 | 购物车 | 添加购物车 | 20 | 3s |
| T06 | 购物车 | 查看购物车 | 20 | 3s |
| T07 | 订单 | 商品结算 | 10 | 3s |
| T08 | 订单 | 提交订单 | 10 | 3s |
| T09 | 订单 | 查看我的订单 | 40 | 2s |
3）测试范围
| 编号 | 功能模块 | 业务功能 | 功能描述 | 优先级 |
| T01 | 登录 | 登录 | 用户通过用户名和密码登录 | 高 |
| T02 | 首页 | 进入首页 | 获取商城首页数据 | 高 |
| T03 | 商品 | 搜索商品 | 通过关键字搜索商品 | 高 |
| T04 | 商品 | 查看商品详情 | 点击商品进入详情页 | 高 |
| T05 | 购物车 | 添加购物车 | 将商品加入购物车 | 高 |
| T06 | 购物车 | 查看购物车 | 用户查看购物车内商品 | 高 |
| T07 | 订单 | 商品结算 | 对已选择的商品进行结算 | 高 |
| T08 | 订单 | 提交订单 | 用户提交商品订单 | 高 |
| T09 | 订单 | 查看我的订单 | 用户查看商品列表 | 高 |
4）测试策略：
- 基准测试-----先做基准测试，确定估算标准
- 负载测试-----通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能承受的最大负载测试；
- 分别模拟5、10、30、50、100个用户对系统进行负载测试，查看不同并发时，系统软件各项指标是否符合要需求；
- 稳定性测试 -----用200个用户对系统进行7*24小时的不间断稳定性测试，查看服务器日志内有无异常和报错：系统软件各项指标中有无异常波动，是否存在内存溢出的问题；
- 验证系统长期运行的稳定性以及是否存在内存溢出之类的问题。
5）风险控制：
| 风险类型 | 风险描述 | 风险级别 | 应对方案 |
| 环境风险 | 部署出现问题，联调进度缓慢 | 中 | 更换环境，增加资源配置 |
| 数据风险 | 构造测试数据时间较长 | 中 | 开发人员协调 |
| 交付风险 | 发现比较严重的bug | 中 | 延长测试时间，增加对应人员 |
6）交付清单：对应进度安排中每个阶段的产物；
性能测试计划、测试脚本、性能缺陷统计和性能测试报告等；
7）进度与分工：性能测试工作分为几个步骤以及每个步骤的开始、结束时间和对应的负责人
| 阶段 | 事项 | 开始时间 | 结束状态 | 状态 | 责任人 |
| 需求阶段 | 需求评审 | 完成 | 多方参与 | ||
| 系统架构图 | 完成 | 开发 | |||
| 需求调研 | 完成 | 性能测试人员 | |||
| 准备阶段 | 环境支付 | 完成 | 运维、开发 | ||
| 应用部署 | 完成 | 运维、开发 | |||
| 数据准备 | 完成 | 开发、DBA、测试 | |||
| 脚本开发 | 完成 | 性能测试人员 | |||
| 实施阶段 | 执行压测 | 未完成 | 性能测试人员 | ||
| 服务监控 | 未完成 | 运维、测试 | |||
| 数据收集 | 未完成 | 性能测试人员 | |||
| 结束 | 报告评审 | 未完成 | 多方评审 |
2.4性能测试用例编写
参考以下性能测试用例的模板来编写：
- 对于单个业务功能的性能测试，每个测试点编写一个测试用例（多个接口有强关联——依照接口而言，可以将多个接口放入同一个用例）
- 对于多个业务功能的组合测试，按照用户实际的业务场景，挑选出有代表性的业务流程编写测试用例。
三、性能测试脚本开发
使用JMeter编写测试脚本并调试；
3.1 常用的测试元件
| 常用的测试元件 | |
| 取样器---HTTP请求 | 发送HTTP请求 |
| 配置元件---HTTP请求默认值 | 设置HTTP请求的默认参数 |
| 配置元件---用户定义的变量 | 定义变量，供后面引用 |
| 后置处理器---JSON提取器 | 提取JSON响应结果中的内容 |
| 断言---响应断言 | 对响应结果进行断言 |
| 断言---JSON断言 | |
| 监听器---查看结果树 | 用于JMeter脚本调试时查看运行日志 |
| 监听器---聚合报告 | 用于JMeter性能测试时查看运行结果 |
初始化工作：
1）创建测试用例结构
注意：一个线程组就是一个用例，与其中有多少个请求无关；
2）设置HTTP请求默认值
3）用户定义的变量
4）添加监听器---查看结果树
5）添加监听器---聚合报告
3.2 编写脚本
3.2.1 登录脚本
断言：状态码、errmsg
如果做接口测试，必须断言响应中的业务数据，可以加上状态码和描述信息
如果做性能测试，可以只添加状态码和描述信息断言
3.2.2 获取首页数据
3.2.3 搜索商品
如果url中的参数有中文，建议将参数写到下面列表中
断言：状态码、errmsg
如果是接口测试脚本，必须针对响应中的商品数量进行断言。
3.2.4 查看商品详情
断言：状态码、errmsg
如果是接口测试脚本，必须针对响应中的商品详细信息进行断言；
3.2.5 加入购物车
| 用例名称 | 添加购物车 | |||
| 用例编号 | Index005 | |||
| 用例描述 | TPS达到20的情况下，加入购物车的时间不超过3s | |||
| 前置条件 | 首页相关的商品数据已经配置完成 | |||
| 用例步骤 | 动作 | 期望的性能 | ||
| 1 | 填写用户名密码进行登录 | <=3s | ||
| 2 | 选择商品加入购物车 | <=3s | ||
添加请求1--登录
添加json提取器：
提取token后，完善在信息头管理器中
添加请求2--加入购物车
添加断言：状态码、errmsg
如果是接口测试脚本，需要再查询我的购物车，检查我的购物车返回的数据是否与加入购物车返回的数据一致，也就是需要再添加一个请求；
3.2.6 查看购物车
| 用例名称 | 查看购物车 | |||
| 用例编号 | Index006 | |||
| 用例描述 | TPS达到20的情况下，查看购物车的时间不超过3s | |||
| 前置条件 | 首页相关的商品数据已经配置完成 | |||
| 用例步骤 | 动作 | 期望的性能 | ||
| 1 | 填写用户名密码进行登录 | <=3s | ||
| 2 | 进入购物车进行查看 | <=3s | ||
请求：先发送登录请求，提取token信息，添加查看购物车，将token信息赋值为X-litemall-Token头域，填写请求路径和参数；
3.2.7 提交订单
| 用例名称 | 结算并下订单 | |||
| 用例编号 | Index007 | |||
| 用例描述 | TPS达到10的情况下，结算下订单的时间不超过3s | |||
| 前置条件 | 首页相关的商品数据已经配置完成 | |||
| 用例步骤 | 动作 | 期望的性能 | ||
| 1 | 填写用户名密码进行登录 | <=3s | ||
| 2 | 选择购物车中的商品进行结算 | <=3s | ||
| 3 | 下订单 | <=3s | ||
提交订单：1）先发送请求登录，提取token信息；2）添加结算请求，将token信息赋值为X-litemall-token头域，填写路径请求和参数；3）添加订单请求，将token信息赋值为X-litemall-token头域，填写路径请求和参数（注意地址与ID必须与用户ID匹配）
响应：
状态码；errmsg
如果脚本为接口测试脚本，需要断言响应报文中的订单数据，与数据库中订单表中我的订单数一致；
3.2.8 查看订单
在编写脚本的过程中，常用的静态数据可以写到用户定义的变量中，在脚本运行中引用，好处是后续如果不修改数据，可以直接修改变量，不需要去每个脚本中进行修改；
3.2.9 业务流程的脚本
| 用例名称 | 业务流程1 | |||
| 用例编号 | Index009 | |||
| 用例描述 | 在业务流程过程中，响应时间和TPS达到要求 | |||
| 前置条件 | 首页相关的商品数据已经配置完成 | |||
| 用例步骤 | 动作 | 期望的性能 | ||
| 1 | 填写用户名密码进行登录 | <=3s | ||
| 2 | 进入首页 | <=5s | ||
| 3 | 查看商品详情 | <=3s | ||
| 4 | 加入购物车 | <=3s | ||
| 5 | 选择购物车中的商品进行结算 | <=3s | ||
| 6 | 下订单 | <=3s | ||
看起来用例复杂，但是写脚本简单，因为单接口脚本都已经写好，直接组合即可；
