测试思路：
- 业务流程逻辑，流程图；
- 细分模块：正常，异常
- 寻找输入项：长度数据类型；需求约束条件+隐形需求；
- 非功能测试点：界面、易用性、兼容性、安全性、性能压力
面试题：
- “说说你项目中的 xx 模块你是如何测试的？”
- “给你一个购物车，你要怎么测试？”
- "你说一下这个产品的登录功能有哪些测试点？"
- “支付功能怎么测试？”
史上最全软件测试工程师常见的面试题总结（七）【多测师】_多测师_王sir的博客-CSDN博客
常见测试项目
优惠券
创建优惠券：
- 基本信息：名称、副标题、类型、数量、使用说明；
- 规则：必填项，限领，有效期，跳转链接
- 优惠券审批：ID生成
优惠券发布后：
- 后台管理：基本信息（id\面值\使用期限\发放量），已领数量和更新，过期删除处理；
- 用户使用场景：已使用、已过期、订单取消/退款
聊天功能测试
微信朋友圈测试
抖音测试
1、直播客户端框架
直播原理：录制视频推送服务器，分发给观众。
直播环节：
- 推流端(采集、美颜处理、编码、推流)
- 服务端处理(转码、录制、截图、鉴黄)
- 播放器(拉流、解码、渲染)
- 互动系统(聊天室、礼物系统、赞、分享等)
直播功能点
观众端：
- 主播基本信息
- 在线观看人数
- 视频播放
- 更多直播
- 互动：评论、加关注、礼物、弹幕等
- 小黄车:提交订单、订单列表、咨询
- 可提现收益换抖币
- 更多∶分享、礼物特效、清屏、设置、举报、不感兴趣
- 退出直播
直播端：
- 主播基本信息、在线观看人数
- 开启直播
- PK:发起PK、邀请连线
- 观众连线:双人聊、聊天室
- 互动玩法:评论、礼物投票、福袋、心愿
- 装饰直播间:美化、道具、贴纸、手势魔法
- 购物车:添加直播商品
- 更多∶镜头旋转、录屏、管理、分享、礼物、任务、上热门、话题、暂停直播、音乐
- 关闭直播
支付测试
清分测试
测试点：
- 清分时间，实时情分（数据库订单状态，清分明细）
- 清分明细表（记录各个角色应该拿多少钱)
- 通过定时任务(2分钟清分一次，批处理)
- 同一笔订单只能清分一次(订单号)
- 精度问题(清分计算规则)：资产=负债+所有者权益 [四舍五入、银行家算法--账对不齐，兜底算法]
- 算法取值，计算过程是否失误
- 测试技巧：excel精准设置公式填写数据；
对账
对账的逻辑:
- 1、以自己平台为准和上游平台的订单进行对账，(支付时间、订单号、支付状态(支付成功)、金额)
- 2、以上游平台的订单为准，和自己平台进行对账
- 3、支付对账、退款对账
- 4、对账执行时间:凌晨执行对账任务，设置了定时任务的
- 5、开始对账--是否有挂账(在7天之内去找掉单的数据进行对账)--是否掉单(在7天之内去找掉单的数据进行对账)---对账完成
测试点:
- 1、对账结果:对平、挂账(我们平台有订单，上游无订单)、掉单(我们平台没有上游有，平台未存储订单信息)
- 2、日切场景:在我们平台23:59:59,到上游第二天，数据构造(修改数据库、修改服务器的时间)
- 3、销账
- 4、重复对账(支持)，先删除(逻辑删除)当天的所有的对账数据，重新对账
- 5、定时任务写的有没有问题(能否正确触发定时任务)
- 6、对账性能(10万条账单，10分钟以内完成对账)
- 7、对账单的解析:上游订单一般通过文件形式放到一个服务器上面，解析正常、解析异常
- 8、管理端的数据统计
结算测试
流程：
- 支付环节：商户入网---对商户进行配置(支付方式、支付渠道)---商户激活收款码---发起支付---清分---对账---结算
- 支付后环节：商户提现(渠道提现、地推提现)---退款(商户)
逻辑：
- 结算：平台做垫资结算(信息流来进行垫资)，为了垫资而作的结算，提升用户体验
- 结算维度：机构（微信、支付宝、京东、美团）、渠道（进件商户公司）、商户（大商户）；好处：能控制资金流
- 结算发起的：2次审核（运维审核、财务审核金额对不对） ---- 发起结算
- 结算逻辑：结算服务根据你的结算维度去获取对账结果，跟据对账结果（已经对账对平的订单）进行结算
测试点：
1、运营平台进行操作结算(前端做防多点)，点一次发一个http请求，你网络卡重复触发结算按钮(弱网测试，狂点)
2、直接测后端接口:幂等校验(脚本并发)
后端实现:触发这个接口，提前请求一个接口，后端生成一个唯一的UUID给前端然后再带着这个UUID去发起结算请求，python也有UUID
3、重新结算(支持)
4、非待结算的订单进行结算(未审核的进行结算)\'
5、未对账对平的订单进行结算(不支持)
6、批量结算(支持)
7、结算性能(时间不能太长，五分钟)
8、各种维度都要进行结算测试，(混合维度不支持)
9、金额精度(0.99,100.99,负数,0)
10、结算一定要稳定，容错性要强(服务器原因挂掉了)，恢复数据，数据库事务触发结算之前先备份结算相关的表数据
清分、对账、结算之间关系
测试点：
- 1、清分：做告警处理，清分异常了
- 2、对账：对清分数据进行校验(对比支付笔数，如果笔数差距太大，就没必要对账,触发告警机制(没对平的超过多少笔、未对平金额超过多少))、钉钉消息通知、微信消息通知、邮件、对账报错的日志
- 3、结算：容错处理，对账结果混乱了(只要发现对账有金额有问题的，马上停止结算，回滚已经结算的数据)
- 4、整个平台
1、各个页面的数据统计工准确性，一致性
2、财务报表
金融支付app-服务端测试
到三方平台生成支付订单，订单信息返回APP，APP使用js调用三方APP，查询订单支付结果，通知APP支付结果，隔日获取对账单
测试难点：
- 三方支付如支付宝，Sandbox环境除不扣钱和线上环境一致，只能依赖做调试不能做测试；
- 三方服务异常、超时等；
- 三方支付API文档的错误码难遇到，无法测试；
- 不真实扣钱没有对账单，不能测试对账
解决方案：
- Mock所有调用到的第三方支付的接口；
- 接口返回：固定逻辑[无订单不能支付]；配置逻辑[配置参数控制返回结果，使得各种特殊场景能够测试到]
- 将生成的订单数据保存到数据库，方便mock对账单
逻辑图：所有菱形处由配置决定；配置通过接口设置
eg：
exports.queryOrder = ctx => { let orderId = ctx.orderId||\'\'; let result = getResult(orderId); if (result.action === \'timeout\') { //超时result.time } if (result.action === \'success\') { //生成支付订单 } ... }
金融支付类APP测试方法——服务端部分_天谈的专栏-CSDN博客
购物车
入口-购物车界面-未登录进入界面-购物车为空-
功能点
1、入口测试：我的购物车，去购物车而结算
2、用户类型：登录的用户，未登录的用户
3、商品清单：
- 按店铺展示商品清单，包括图片、名称、单价、数量、小计等;
- 显示店铺合计金额、商品总结金额
- 购买数量可进行增减-- 等价类、边界值
- 商品支持删除、移到关注
4、选择商品
- "全选"
- 单个勾选、部分选;
- 删除选中商品，移入关注，清理购物车
5、去结算
- 点击“去结算”
- 跳转至订单确认界面--交互验证
6、空页面处理
- 当购物车商品为空时， 可选择“去购物”
N95口罩测试
N95型口罩，是NIOSH（美国国家职业安全卫生研究所）认证的9种防颗粒物口罩中的一种。N-非油性颗粒。
功能：
- 可以防护某些颗粒物，如打磨、清扫和处理矿物、面粉及某些其它物料等过程产生的粉尘；
- 可以防护因喷洒而产生的液体的或非油性的颗粒物；
- 能有效过滤和净化所吸入的异常气味，当然有毒气体除外；
- 能够降低某些可吸入微生物颗粒物，如霉菌、炭疽杆菌、结核杆菌等的暴露水平；
- 可以防护病菌，过滤效率达到95%以上；
- 测试一些油性颗粒物，确定是否不能防护；
界面：
- 看包装上是否有商品名，是否有制造商或者是供货商的信息，是否有口罩合格证或者使用说明；
- 如果是一次性口罩还要有一次性的标识，对于重复使用的医用防护口罩还要标明菌的方法；
- 用材料应没有异味，并对人体无害，特别是人体面部接触部分材料，应无刺激性和过敏性；
- 口罩的包装是否完整，有无破损，口罩表面不得有破洞、污渍；
- 医用防护口罩不应有呼气阀；
- 口罩的长、宽、厚度是否都符合对应的标准；
- 口罩是否配有鼻夹，鼻夹由可弯折的可塑性材料制成，并且长度符合要求；
兼容性：
- 口罩可以适配各种脸型，各种脸型的密合性都可以保证；
- 能适合各种肤质的，接触都不会引起敏感等反应。
性能：
- 挤压口罩，或者撕扯口罩是否会导致破损或者极易损坏；
- 带的时间过长，口罩防护作用是否降低；
- 口罩的鼻夹反复折合，是否容易会断。
安全性：
- 口罩虽然越密闭，越安全；但是同时越密闭，呼吸起来越困难，尤其对于心血管疾病患者，是否会因缺氧而导致头晕和呼吸困难等风险；
- 口罩的材质不会引起过敏反应 （此处跟易用性有重复哦，可以去重~）；
- 口罩材质和味道都无毒，不会引起不良反应；
- 耳带式口罩长期佩戴是否会勒伤皮肤。
易用性
- 口罩的内外、上下面易于分辨，易于佩戴；
- 口罩的上缘鼻夹方便按压，易于于面部紧贴；
- 口罩易折叠，方便携带。
小程序测试
小程序 APP
| 原生APP | 小程序 |
|
需要安装，卸载，操作麻烦;占用手机空间 需要注册登录系统 开发周期长，消耗大，成本高10倍+ 支持的平台(android、iOS)需要单独开发 宣发方面需要自己推流，成本高，效果差 |
无需安装，用完即走 使用微信的账号，无需注册登录 周期短，开发快，成本是APP的1/10 一个版本兼容各种手机平台 天然拥有超过10亿的微信用户流量 |
小程序：依赖于威胁你而不需下载安装的移动端应用程序
无需下载安装即可使用的应用，用完即走理念，应用无所不在随时可用，无需安装。
优点：无需下载，功能丰富，流量大易裂变
小程序架构：
- View 层用来渲染页面结构。视图层和逻辑层通过系统层的 JSBridage 进行通信
- wxss（多了rpx单位）控制样式 -> css
- wxml xml 语言控制渲染层展示 -> html
小程序测试
测试用例：项目立项 需求分析 测试计划和设计执行 评估结束
原生APP和小程序测试对比
1、开发周期和成本：小程序开发周期短，提供框架和API，基于HTML5发开，开发难度低成本低；
2、小程序可满足简单基础应用，低频次及偏向于线下和场景生活服务类的轻应用，如快递餐饮商户活动；需要大量计算如图片处理文档编辑只能使用原生APP;
3、高级用户体验：原生APP的UI\UE可更人性化，功能完善取决于开发者，对接口调用更为简单，一些如AR、语音识别能在APP上实现交互、视觉等高要求用户体验，小程序作为轻量级应用无法满足；
4、下载途径：APP在应用商城下载安装，小程序二维码、搜索、好友分享获取，公众号可关联小程序可轻松打开；
5、安装流程：
如何测试（六）“小程序" 如何测试？ - 守护往昔 - 博客园 (cnblogs.com)
贷款测试
银行放贷测试点：
- 正常放贷，考虑申请边界值
- 异常：
- 同时申请多笔；
- 剩余额度为0继续申请或关闭通道；申请金额非整数为0负数；
- 还款一笔，授信额度是否恢复；一次性申请完所有授信金额
还款：
功能：正常还款，逾期提前，不同账户还款，第三方还款，多期，死账，还错账；余额不足还款你，金额为空，0，负数；弱网点击继续还款，支付服务放把支付结果返回给下单发起方；
- 新年：还款响应时间
- 用户体验：系统提示理解，界面友好，输入框对其，按钮大小是否适中错别字；
- 安全性：SQL注入，防XSS攻击；还款金额被拦截篡改；还款密码等敏感信息是否加密；
- 兼容性
金融项目接口测试：充值模块，提现模块，项目新增模块，审核模块，投标模块，生成回款，获取各种列表信息等
P2P产品6个月的测试
- 每月还款日前邮件，短信，站内通知充值到平台账户上；每月还款资金足够、不足、不充值，系统处理方案如一些罚息；
- 借款人提前还款，支持与否，满足期限可提前，手续费；
- 最后一期还清，前后台查看借款产品状态；
- 借款产品投标结束日T+7，满标和不满表情况，产品提前满标情况
银行移动消费信贷业务