总体测试计划
| 测试模块 | 子模块 | 测试内容 | 预期结果 |Y/N
|:--------|:-------|:-------------|:--------------- |
|用户登入 |登入 |学号为空 |提示“学号不能为空” |Y
| | |教务处密码为空|提示“密码不能为空” |Y
| | |学号或密码错误|提示“账号或密码错误” |Y
| | |学号和密码都正确|登入成功 |Y
|个人信息修改|头像修改|点击头像 |提示“是否允许访问”,后进入照相或选择相册图片|Y
| | |选择图片 |图像修改成功 |Y
| |我的信息|点击我的信息 |出现用户的相关信息 |Y
| | |点击注销 |退出账号 |Y
|消息 |各个对话框|点击对话框,和买家对话,|可以实现 |Y
|学习资料库 |专业课资料||点击相关资料|出现相关产品 |Y
| | |点击该栏目下相关产品|出现商品详情及用户信息和“联系卖家”按钮| Y
| | |点击“联系卖家”|出现卖家信息和“发消息”按钮 |Y
| | |买家卖家通讯 |能正常通讯 |Y
| |考研资料 |点击相关资料|出现相关产品 |Y
| | |点击该栏目下相关产品|出现商品详情及用户信息和“联系卖家”按钮| Y
| | |点击“联系卖家”|出现卖家信息和“发消息”按钮 |Y
| | |买家卖家通讯 |能正常通讯 |Y
| |课外资料 |点击相关资料|出现相关产品 |Y
| | |点击该栏目下相关产品|出现商品详情及用户信息和“联系卖家”按钮| Y
| | |点击“联系卖家”|出现卖家信息和“发消息”按钮 |Y
| | |买家卖家通讯 |能正常通讯 |Y
|福大图书馆|bug...
|二手市场 |电动车 |点击相关产品|出现相关产品 |Y
| | |点击该栏目下相关产品|出现商品详情及用户信息和“联系卖家”按钮| Y
| | |点击“联系卖家”|出现卖家信息和“发消息”按钮 |Y
| | |买家卖家通讯 |能正常通讯 |Y
| |锐捷 |点击相关产品|出现相关产品 |Y
| | |点击该栏目下相关产品|出现商品详情及用户信息和“联系卖家”按钮| Y
| | |点击“联系卖家”|出现卖家信息和“发消息”按钮 |Y
| | |买家卖家通讯 |能正常通讯 |Y
| |生活用品 |点击相关产品|出现相关产品 |Y
| | |点击该栏目下相关产品|出现商品详情及用户信息和“联系卖家”按钮| Y
| | |点击“联系卖家”|出现卖家信息和“发消息”按钮 |Y
| | |买家卖家通讯 |能正常通讯 |Y
|发布产品 |TextView |点击相应的对话框 | 是否可以进行编辑 |Y
| |添加照片 |打开相机或选择照片 |可以进行 |Y
|求购信息 |bug...
Bug记录:
存在的bug
- 由于服务器限制,查询信息速度没有很快,不太稳定
- 个人和主页点击切换时都会显示被选中状态
- 部分用户操作错误提示没有显示
场景测试
场景一 | 即将毕业的大四学生刘星,宿舍里有很多闲置的二手物品想转让,经好友推荐,下载这款福大易宝APP。用起来最大的感受就是操作简单易懂容易上手。考虑好要卖哪些二手物品以及相应的价位后,刘星发布了他的第一个商品信息,随后联系到了几个想买他二手物品的童鞋,完成了他的第一笔交易。 |
---|---|
场景二 | 刚进大学的大一小鲜肉夏雪,他觉得有些生活用品可以买一买二手的,可以省很多很多很多money。于是他打开了福大易宝这款超级牛的APP,在购得他的第一个二手物品之前,他浏览了不少商品信息,他感觉商品种类有点少(毕竟现在用户量比较少),整体上感觉功能有点少,没有特别好的用户体验。 |
场景三 | 大二的老油条夏雨,他偶尔会逛一逛淘宝,偶尔逛一逛二手市场,偶尔会出售自己的二手物品。所以他很喜欢这种二手市场APP。他感觉这款福大易宝APP用起来还是和咸鱼有挺大区别,不过整体感觉还行,基本的功能都能满足自己的需要。目前还需要一个可以发布求购信息的功能,以便能买到自己真正需要的二手物品。期待下一个版本可以带来一些更好、更新的用户体验! |
上述三个场景中,场景一和场景二分别代表了买家和卖家,他们对这款福大易宝APP的评价和感受还是非常客观的。普遍感觉整体不错,但是还需要更多能刺激他们内心痛点的功能。买家发布求购商品信息后,卖家可以实时地查看这些消息,以便随时和买家取得联系并完成交易。而卖家发布二手商品信息后,买家通过浏览商品信息再完成交易,这两种功能相辅相成,非常合理地满足了用户的需要。
安卓兼容性测试
- 总体概况
- 失败情况汇总
- 失败机型如下
- 成功机型如下
- 性能概况
- 性能分析
可以根据性能对比可知,app的性能指标远远低于行业平均指标,占用的空间内存等都比较小,这与我们app功能和定位有很大关系,apk的安装包不足10M,功能有限,不过在已完成的功能体验上有一定的较好体验感。 - 失败原因分析
由上图,发现5.0.0以下系统的手机不能够很好兼容,这与我们开发时采用的框架不支持5.0.0以下的智能手机有关。
app深度性能测试
- 性能分数
- 性能建议
- 性能问题
- 失败分析
由于性能测试采用的手机系统版本较低,所以造成测试时不能够进行安装,只能对安装包进行分析。
性能测试
考虑到APP的实际使用情况,查询数据应该是用户使用最多的功能。我使用siege对商品的根据一个类别查询数据进行了性能测试。
这是siege的参数说明:
Transactions: 265 hits #完成265次处理
Availability: 100.00 % #成功率
Elapsed time: 27.27 secs #总共使用时间
Data transferred: 0.68 MB #共数据传输 0.68 MB
Response time: 11.33 secs #响应时间,显示网络连接的速度
Transaction rate: 9.72 trans/sec #平均每秒完成 9.72 次处理
Throughput: 0.02 MB/sec #平均每秒传送数据
Concurrency: 110.13 #实际最高并发连接数
Successful transactions: 265 #成功处理次数
Failed transactions: 0 #失败处理次数
Longest transaction: 27.26 #每次传输所花最长时间
Shortest transaction: 0.61 #每次传输所花最短时间
从测试结果来看,在265并发,重复1次的时候,系统还可以正常运行,平均响应时间为11.33s,实际最高并发连接数可以达到110.13,但是到266并发重复1次时,数据库就直接崩溃,连接断开了。第一次测试的我超级虚的,还好重启了下mariadb就可以了。
下面尝试重复2次。
可以看出 在210并发重复请求2次就开始发生错误,最大并发连接数是66.23。
这是查询模块服务器目前可以访问的压力测试。
但是用siege,没有实际的数据图表来显示,不友好的命令行。我尝试用了腾讯的压力测试工具。
这是我们的测试数据
我们选择了从10人开始,依次增加到15人,每阶段增加1人,每阶段持续30s的压力测试。
可以看出总共请求了11520次,失败了72次。 并且109次出现了peerclose。平均响应时间是213.68ms.。
从post的请求率来看,在查询这块,服务器还是能应对较多请求。只是服务器CPU的使用率。。。
针对这个,我们的想法是:
第一点, 服务器是1g内存 1核的学生特惠服务器,硬件方面就只能先将就了。
第二点, 考虑到数据库的查询优化,我们打算在β做数据库的缓存优化。