The Documents about Group Project of Software Analysis & Design
测试对象是服务器后端,采用白盒测试,以达到高代码覆盖率。
本产品是一个扫码点餐系统,包含小程序客户端和web商家端。本产品以扫码点餐结算业务为核心,商家端支持必要的管理功能,让顾客轻松点餐,商家省心省力。
postman、JMeter
| 模块 | 用例数 | 用例通过个数 | 问题数 | | —- | —— | ———— | —— | | 性能测试 | 20 | 20 | 0 |
前提:已经进入小程序(客户端用户登录)
功能 | 基本要求 | 测试情况 | 通过(Y/N) |
---|---|---|---|
查看菜单 | 准备一张商家二维码,小程序内扫码出现商家信息和菜单信息。可以滚动查看菜单,点击菜品显示详情页。 | 已实现 | Y |
选餐 | 一、可以直接加减选择菜品,有规格的菜品弹出浮窗选择规格,确认后添加到购物篮,购物篮累计价格。二、不可选择售罄菜品。三、查看购物篮中菜品,加减份数可以正确显示。四、更改规格购物篮中计价发生改变 | 发现没有售罄的设计 | N |
下单 | 选好两样菜品,去下单跳到确认订单页,添加备注,检查桌号和菜品信息是否相符。一、返回修改菜单信息之后再确认也能得到正确显示。二、确认下单后出现mock的支付成功页面。确认后看到订单正在进行的状态页。在商端验证收到的新订单 | 已实现 | Y |
| 功能 | 基本要求 | 测试情况 | 通过(Y/N) | | —- | ——– | ——– | ——— | | 显示与查看 | 正在进行中的订单按时间先后排列,点开订单可以查看详细信息 | 等待时间计数不正确 | N | | 操作 | 一到四、接单,拒绝,完成,取消,四种操作在客户端能看到对应的状态,在对应的筛选tab下可以看到 | 不正常能接单,进而发现小程序端不能正常支付等 | N | | 查询 | 输入任意字符串,模糊匹配到相关订单 | 已实现 | Y |
本模块测试要求所做修改动作在商端和客户端都能看到。
功能 | 基本要求 | 测试情况 | 通过(Y/N) |
---|---|---|---|
菜品基本信息管理 | 一、新建一个菜品。二、图、名、描述、状态、标签、售卖状态的增删改。三、删除一个菜品。四、使用筛选框搜索菜品 | 已实现 | Y |
分类管理 | 一到四、CRUD。五、修改一个菜品的所属分类。 | 已实现 | Y |
价格管理 | (菜品卡片上始终显示最低价)一、修改基础价格。二、增删改规格。三、增删改规格子选项 | 已实现 | Y |
快速编辑模式 | 一、拖动排序。二、修改菜品基本信息 | 拖动排序没做 | N |
基本排序 | 拖动卡片排序 | 理解错了需求做了分类排序没做这个 | N |
| 功能 | 基本要求 | 测试情况 | 通过(Y/N) | | —- | ——– | ——– | ——— | | 客户端查看历史订单 |(客户端用户登录)点击订单的tab,展示出历史订单 | 空空的 | N | | 商端首页 |(商端用户登录)一、增减订单和完成订单,订单统计数目正确。二、统计板块跳转正常 | 计数不符合需求 | N | | 生成二维码 | 输入桌数,生成对应张数的二维码,且能够正常扫描使用看到对应桌号 | 会拿到所有生成过的二维码,而不是这一次 | N | | 商端用户信息修改 | 点名、电话、介绍、Logo修改后回到首页显示修改结果 | 已实现 | Y |
*注:测试系统在预定环境和负载下的响应速度、通信效率、设备效率、执行效率。
性能测试主要分为后端性能测试以及网页性能测试,其中一部分的网页性能测试包括后端性能测试。
用例名称 | 基本要求 | 并发数 | 是否通过 |
---|---|---|---|
商家端登录 | 商家同时登录 | 100 | Y |
客户端登录 | 多个小程序客户同时登录 | 100 | Y |
查询订单 | 商家同时查询订单,且订单的各项参数合法 | 100 | Y |
新增菜品 | 商家同时新增菜品,且菜品各项参数合法 | 100 | Y |
获取菜品页面 | 商家同时获取菜品 | 100 | Y |
获取二维码 | 多个商家同时获取二维码列表 | 100 | Y |
点餐 | 同时点餐 | 100 | Y |
网页名称 | 并发数 | 是否通过 |
---|---|---|
首页 | 100 | Y |
搜索订单页 | 100 | Y |
正在处理中订单页 | 100 | Y |
已结束订单页 | 100 | Y |
全部订单页 | 100 | Y |
全部订单页 | 100 | Y |
菜品管理页 | 100 | Y |
新建/编辑菜品页 | 100 | Y |
生成二维码页 | 100 | Y |
商家信息页 | 100 | Y |
商家更改密码页 | 100 | Y |
| 参数名| 值| | —- | — | | 脚本循环次数 | 无限 | | 并发用户数 | 5/10/50/100/200 | | 真实客户端数量 | 1 | | 脚本录制方法 | 自动 | | 模拟路线类型 | 10/100M以太网 |
平均响应时间(s):
并发用户数 | 商家端登录 | 客户端登录 | 查询订单 | 新建菜品 | 获取菜品 | 获取二维码 | 下单 |
---|---|---|---|---|---|---|---|
5 | 0.195 | 0.258 | 0.421 | 0.033 | 1.218 | 0.109 | 0.071 |
10 | 0.294 | 0.213 | 0.293 | 0.057 | 0.976 | 0.168 | 0.063 |
50 | 2.502 | 1.400 | 1.501 | 2.714 | 15.218 | 1.028 | 1.347 |
100 | 5.228 | 3.775 | 6.841 | 1.812 | 32.207 | 3.224 | 7.985 |
根据JMeter聚合报告的结果可以看出,各后端api表现正常,在跑100个线程(用户)时,平均时间为9.862s,错误率在低并发(5-100)的情况下为0%,在样本数为160-170左右时错误率会开始指数性增加,原因是新建过多菜品导致每次需要读取很多数据,这会限制数据库对其他请求的响应,这时候服务器就会开始崩溃,无法响应其他请求,在测试过程中,我们大约等待20分钟,服务器才恢复正常。考虑到现实情况中我们的技术面向是小型商家,性能测试的结果是符合预期的。
根据JMeter聚合报告的结果可以看出,在跑200个线程(虚拟用户)时,当发出https请求数量为460左右,平均响应时间是1.452s而错误率仅是0.07%,符合预期的性能结果;当发出https请求数量从460开始增加时,错误率会明显上升,例如web商家端注册的请求数从464增到506时,错误率很快从0.00%增到8.30%,响应时间也明显增加,而每秒完成的请求数会降低。这说明https请求数量为460是服务器的瓶颈,当请求量继续增加时,消耗过多的服务器资源,使得服务器的性能降低并出现请求错误。
本次测试为“小欣点餐”第一次严谨而全面的系统测试,也是最后一次测试。测试完全模拟用户场景对功能性、易用性,以及系统性能各个方面进行了测试,做到了覆盖业务文档中的基本需求和用例。测试中发现很多bug,大多不是重大bug,比较容易找出原因和修补,但是第一次整合测试出现这些问题是可以理解和接受的。其中部分属于需求设计没有沟通清楚,也有一些属于很细小的交互细节问题,体现项目管理上的小缺陷。
1.在允许的时间和精力内把bug修复好。
2.在需求发生变更的时候,要及时开会明确变更点。
3.功能性测试在早期也要做,有利于提前发现比较重大的bug。