当使用美团团购购买套餐后,后台发生了哪些业务流程?
1.客户端向服务器发起套餐购买,并带上用户ID、商品ID、token等信息。
2.服务器收到客户端发送的请求,校验用户信息以及根据商品ID查询库存情况,并将库存结果返回客户端。
3.客户端收到服务器返回的库存结果,库存不足提示库存信息,库存充足选择调起支付平台的支付SDK,并向服务器发起支付请求。
4.服务器收到客户端的请求后,校验用户信息以及商品ID信息,校验通过,服务器通知支付平台后台生成预支付订单号。支付平台后台将生成的预支付订单信息,预支付订单号返回美团服务器后台。美团服务器后台收到信息,生成带签名的客户端支付信息返回客户端。
5.客户端输入密码确认支付、支付平台返回支付结果给客户端。
6.客户端同步支付结果到美团服务器后台,上传订单信息、签名、用户信息等。
7.服务器根据客户端上传的订单号以及订单信息到支付宝或微信服务后台验单
8.验单通过,更新库存信息,更新用户账户信息,更新商品信息,更新订单管理记录,并将结果返回客户端和商家
9.客户端、商家后台订单信息及时更新,提示购买成功,并生成对应的订单记录。
1.首次打开App,App会进行应用的初始化和相关数据的加载。可能的缺陷包括启动闪退,打开过程加载时间过长,App启动过程的界面显示错误
2.登陆App的过程中会进行用户名和密码的校验,以及根据分控策略阻止异常账号的登陆。可能的缺陷包括用户名密码未加密存储和显示,账户登陆异常信息提示错误
3.App首页加载:用户位置定位,根据用户位置展示附近商圈的外卖门店信息。可能的缺陷包括用户位置定位失败或者错误,外卖门店信息加载失败和错误,网络加载失败等
抓住重点的词汇:第一次打开 第一次登陆 看到首页
1.第一次打开的话就会进行一个初始化,这个是所有哦APP都要注意的点,可能会出现闪退,可能会出现加载时间长(这些分析的点都是将自己看做一个用户的使用角度去考虑的)
2.第一次登陆,登陆用户界面都是要进行简单的校验,校验可能出现的错误:登陆不上,密码没有,账户异常都是
3.看到首页,美团的首页都是要定位到门店信息的,c/s模式有一个比较大的特点就是客户端会缓存一部分的数据,但是第一次打开的用户要根据自己的网络,定位来进行加载然后进行缓存,因此可以注意的就是缺陷可能包括定位,网络
1.二维码识别:开锁url、车辆id等
2.网络通信和页面渲染
3.业务逻辑判断:车锁状态正常、账户余额充足、用户身份正常、用户GPS位置正常
4.执行开锁、计费开始
界面未给出响应的原因:
程序问题:
1、按钮的监听事件未正确调用,或者干脆就没有添加监听
2、监听确认被调用,但监听过程出现错误或异常,例如参数传输失败。
3、前端调用接口错误,如后端出现运行时异常,没有给出相应的提示消息
设备问题:
1、网络延迟,响应没有及时出现,超时
2、手机卡顿,出现死机现象
3、响应被中断
1.从网络方面,可能发生了断网,或者碰到了极弱网的情况
2.从客户端发生考虑,可能是用户的移动设备发生故障,未读取到用户点击操作,同时可能是用户操作系统发生故障
3.从服务器段考虑,可能是系统负载较大,对用户响应很慢,也有可能用户请求再传输过程中丢失,导致服务器未读取到请求
参考答案:
功能性测试: 展示相关: 1.排版正常,不出现重叠、缺失等现象 2.图片正常展示,无明显拉伸现象 3.字体大小样式展示正常,过长截断4.点击跳转正常 5.用户滑动无卡顿 6.加载更多无重复
功能相关: 1.账号在登录和非登录状态领券 2.用户在经纬度缺失时距离显示 3.商户券领完后,不能重复领。商户券达到领取上限后,直接下线。 4.10点之前不能参加抢购; 5.抢之后『xxx人已抢』的显示数量要增加
兼容性测试: 1.屏幕大小测试:大屏、小屏手机 2.系统兼容性测试 ios、android
性能相关: 前端性能:CPU,内存占用,低配置Android机体验效果 后端性能:压测对应的后端接口的QPS,预测峰值流量及所对应集群的QPS。制定相应方案。 网络环境模拟测试: Wiki测试、3g/4g、弱网络情景
其他: (1)图片太多,图片不宜太大,以免消耗用户太多流量。 (2)用户数据统计等信息,统计商户曝光率,点击率等信息测试
1、静态黑盒测试:
查看产品说明书,看功能设置方面是否有需要补充的方面;
和产品经理对产品需求等进行交流,或者直接从客户(包括用户和商户)方面了解客户需求,完善功能设计;
2、动态黑盒测试:
设计测试用例,测试该活动的各项功能,如是否满足条件的用户可以领取优惠券,且是否每用户只可以领取同一商户优惠一次,商户优惠券存在上限功能是否能够实现,是否只可以在上午10点以后领券;
设计测试用例可以采取等价类划分的方法:
对于第一个功能设计的测试用例为:一个用户领取某一商户优惠券一次,一个用户领取多个商户优惠券各一次,一个用户领取一个商户优惠券两次
对于第二个功能设计的测试用例为:用户领取的某商户的优惠券数目小于其数目上限、用户 领取的某商户的优惠券数目等于其数目上限、 用户 领取的某商户的优惠券数目超过其数目上限
对于第三个功能设计的测试用例为:在上午10点前领券、在上午10点整领券、在上午10点以后领券
还需测试的功能为用户在当天领取某商户优惠券后第二天是否仍然可以领取、用户点击首页全程好券后是否可以正确进入到领取优惠页面等
3、白盒测试
查看代码、并根据代码语句分支、条件分支、不同状态等设计测试用例进行测试
4、性能测试
让很多个用户同时点击全程好券活动界面,看是否能够正常进入、以及等待响应的时间
让很多个用户同时领取同一商户优惠券,看是否能够正确领取,以及等待响应的时间
5、兼容性测试
测试用户是否只有更新版本够才可以使用全程好券活动功能,是否兼容以前版本
测试该活动功能在安卓、ios等不同系统下能否正常运行
测试增加该功能后其他功能的使用情况
考察测试用例设计思路,从功能、性能、安全等多方面思考;结合测试用例设计方法回答。 答案要点: 功能测试 1. 正向功能; 2. 参数为空; 3. dealid不存在; 4. dealid为非数字的值; 5. quantity为0或负值; 6. quantity大于库存量; 7. token无效 8. 入参不是JSON 性能测试 1. 压力测试,考察系统在极限压力下的处理能力 2. 狭义性能测试,验证系统能够达到一定的处理能力 3. 并发测试,测试数据库和应用服务器对并发请求的处理 安全性测试 1. 伪造token攻击 2. 订单潮水攻击 3. deal遍历攻击 4. SQL注入攻击 加分项 订单复用:当同一个用户提交的dealid、quantity相同时,返回的orderID总是一样(没有重复创建订单)
1.请求能否发送成功
2.发送正确请求能否接收返回的广告
3.发送正确请求返回的广告能否正常展示
4.发送错误的请求返回的数据内容是否显示正常
5.压测:同时发送100条请求或上千条请求,请求能否成功发送,顺序是否一致,能否正常接受返回的广告,返回的广告顺序是否一致,返回的广告是否能正常展示
1.考虑客户端所在的系统配置和性能是否满足要求,如果系统配置和性能正常,则转向第二步;
2.判断网络环境是否通畅,是否满足要求,如果网络环境满足要求,则转向的第三步;
3.对比系统打开同类软件的冷启动时间,如果打开同类软件的冷启动时间平均低于4s,则开启速度不合理。
4.对比系统打开不同类软件的冷启动时间平均低于4s,则开启速度不合理。
如何判断:
0.冷启动时间测试方法环境固定:
(1)同一台手机
(2)关闭网络
(3)连续三次求平均值
1.找到竟品的app,获取冷启动时间,然后进行对比
2.获取当前版本和之前版本的冷启动时间,纵向对比
3.通过不同性能型号(系统版本/内存大小等)的手机进行冷启动时间测试
找到问题:
1.通过不同版本的纵向对比,定位到启动时间不合理的版本的出现时间
2.测试启动时间时全程抓取log,分析进入应用时的系统调用栈和加载的资源的耗时
1.首先进行冒烟测试,看软件是否能正常启动,正常关闭,软件打开后,内容显示是否正常
2.进行功能测试,对这个系统所包含的功能:评论消息、点赞消息、关注消息、头条号提醒、问答提醒、以及系统消息进行功能测试,验证每个模块的功能是否正确
3.对于不同的软硬件环境都需要进行功能测试,看系统兼容性是否良好
4.功能测试完成后,若无功能问题,则对系统进行性能测试,比如:测试不同网络状态下、多个人同时登录系统、同时进行同一操作,系统的稳定性如何,可以利用性能测试工具LoadRunner,对性能指标进行分析,看是否达到要求
function test:
1. 登录后给信息评论、给信息点赞、点击关注/撤销关注、头条提醒、问答邀请、系统消息、是否被消息系统记录
2. 不登录给信息评论及其他操作,是否能成功?评论失败系统是否记录
3. 登录后给信息反复点赞及撤销点赞,反复关注及撤销关注,系统是否记录。
4. 登录后多次发送同内容的信息评论,系统是否多次记录。
5. 消息系统是否有定期清理机制,有的话需要资料说明
security test:
1. 记录的消息 是否完备,包括时间、用户、行为、结果
2. 记录的消息是否有敏感信息,如果有敏感信息要脱敏
3. 消息是否有导出机制,如果可导出需要客户同意声明、敏感信息使用说明
4. 消息系统的文件权限要严格控制访问权限。
5. 构造恶意语句如%0a%0d,看是否被解析成语句,从而可以构造日志注入
Performance test(压测):
1. 同时10000个消息评论,是否都记录到消息系统、记录是否有错误、系统是否延迟、挂死。
2. 同时10万人在评论、点赞、关注等消息,消息系统是否能正确不延时的记录消息。
3. 不停的评论、点赞消息,看消息系统内存/磁盘是否会被撑满。
1.用户手机欠费
2.用户为打开网络,或者用户手机本身接收网络信号不好
3.用户处于信号较弱地带
4.用户所处地带网络信号屏蔽
5.同一时间,刷新消息的用户超过了最大并行数,导致信息流刷不出来
6.用户操作太频繁,导致无新消息可刷
7.用户没有打开今日头条的网络操作权限
管理员权限:放入货物、订制价格等功能
用户权限:刷卡、塞钱、扫码支付、选择货物、货物正常掉出、吐出找零等功能
1、界面测试
外观是否设计合理、符合大众审美
2、功能测试
(1) ***作流程是否简单便捷、***作说明是否简单易懂无歧义
(2)售货机屏幕显示(广告轮播功能、商品和金额以及二维码等信息显示 等)
(2)管理员权限:放入货物、制定价格等功能
(3)用户权限:刷卡(工商卡、建行卡、农行卡等)、塞钱(根据不同商品以及金额大小进行商品兑换、找零、退钱等)、扫码支付(微信支付、支付宝支付、积分兑换支付等)、选择货物(不同零食、不同饮料等)、取出货物(不同零食、不同饮料等)等功能
3、性能测试
(1)异常处理:系统出错、断电之后售货机能否自动恢复、恢复之后能否继续处理未完成的任务等
(2)安全性:货物存放、现金存放以及金额设置等是否安全
功能测试:
(1)饮料能够正常放置
(2)饮料价格正常展示
(3)能够正常投币,以及支付之后能正常弹出相应的饮料
(4)空调系统正常运行
(5)装填饮料以及饮料分类正确
性能:
(1)长时间运行,可以正常使用
(2)购买之后,弹出饮料的响应时间
(3)空调系统温度
兼容性:
(1)不同规格的饮料都可以放置
(2)不同的支付方式(扫码、投币、现金)
易用性:
(1)购买面板是否操作简便
(2)装填饮料是否简易
http get/post
Get方式是从服务器上获取数据;在做数据查询时,建议用Get方式;如:商品信息接口、搜索接口、博客访客接口等;
Post方式是向服务器传送数据 ;在做数据添加、修改或删除时,建议用Post方式 ;如:微博图片上传图片接口、登录注册接口等;
1)get型接口
场景:get型接口用于获取信息,多用于查询数据,如列表查询功能,点击查询按钮就调用一个get接口,然后把信息返回出来
特点:1)请求数据量小,2)参数暴露于url地址中,故存在安全隐患
2)post型接口
说明:向指定资源位置提交数据(如提交表单、上传文件)来进行请求,post请求可能会导致新资源的建立
场景:如注册、上传、发帖等功能
特点:请求数据量大,安全性高
3)put型接口
说明:put请求用于向指定资源位置上传最新内容
场景:如用户在豆瓣网站修改对某本书的收藏、修改某篇笔记或修改评论
4)delete型接口
说明:请求服务器删除请求里url所标识的资源
场景:如用户在豆瓣网站取消对某本书的收藏、删除某篇笔记或删除评论
1. 所有页面链接功能正常,可以点击到正确页面;
2. 从商品信息页面添加的商品能显示在购物车中;
3. 商品未勾选的状态下,结算按钮是灰色无法点击的;
4. 勾选商品后,已选商品的总价会显示,结算按钮变高亮可点击工作;
5. 购物车页面中,可以对添加的商品数量修改,并自动保存成功;
6. 修改勾选物品数量,总价会做相应的改变;
7. 勾选商品,点击结算按钮后,进入确认订单信息页面;
8. 购物车能添加的商品种类是有数量上限的/显示库存;
9. 不要的商品,可以删除;
10. 卖家在线的时候,旺旺icon高亮,反之,灰色;
11. 页面关联本地软件阿里旺旺的icon点击后,能打开软件;
12. 登录测试:
未登录情况下,可以添加,查看,修改购物车, 但是提交订单后跳出登录或非登录用户购买方式。
未登录情况下,添加到购物测好的物品,登录后刷新会显示在登陆后的购物车中。