金融系统中容易踩坑的问题

1、产品类型指的是大类还是小类

有的产品比如员工贷既是指员工贷小类，也是指员工贷系列的产品，这时候需要关注需求描述的员工贷覆盖范围是产品大类还是小类。

2、未带参数时是否有默认处理

前端传输的某个值为空时，后端是否需要设默认值；接口返回的某个配置项为空时，前端是否需要展示默认选项。

3、大小写处理成一致之后再匹配

身份证校验的地方，需都转成同一种大小写格式再校验。

同时，在这我也准备了一份软件测试视频教程（含接口、自动化、性能等），需要的可以直接在下方观看，或者直接关注VX公众号：互联网杂货铺，免费领取

软件测试视频教程观看处：

2023最新【软件测试面试300问】面试八股文教程，涵盖自动化测试/接口测试/性能测试/测试开发等内容

4、基本校验不通过，数据是否还要提交

在用户提交申请信息时，有的处理方法是提交时进行基本校验，校验不通过不允许提交/报错，不保存数据，后台无法查看真实的用户申请记录和情况，后续无法进行记录查看和数据分析，用户也无法查看历史记录，体验感稍差。虽然从流程看没有问题，但是建议的做法是保存用户提交的记录，即使不通过也只是更改状态为校验未通过。

5、处理出错时需要有结果

后端处理出错时，尽量给友好的提示给用户（前端或后端处理都可），但不要直接把后端报的空指针或者空响应返回给用户。

6、结果同步发送给其他系统还是异步发送

比如额度申请需要风控系统进行处理，在用户提交申请后，如果同步发送请求给风控，当风控系统异常时，流程中断，数据未保留，在这种情况会容易由于系统问题丢失用户，影响业务，给用户带来不好的体验。

7、对额度的处理

提款时用的是审批额度而不是申请额度：用户申请20000，通过了15000，用户可提款的额度为15000而非20000；

额度过期后需作废该笔额度(变更状态或者变更数值)。

8、展示的地址

如果省市区是分开填写和存储的，在展示详细地址时是否有把省市区详细地址组合（特别是合同上）。

9、图片读取位置

对不同文件类型存放的位置是否有区别，导致人审时无法查看证件照等其它客户资料。

10、筛选数据时需要确认是只要某产品的数据还是所有产品数据

针对公共模块的数据展示，需要确认仅需处理某产品的数据还是需要所有产品的数据，仅该用户名下的数据还是总的数据。

11、需要加密的数据/需要解密的数据

避免漏解密、重复加密的情况：数据库中用户名是加密的，展示时直接取数据库中的值而未进行处理。

12、字典项对应

检查配置项是否缺失，配置项是否使用正确。

13、分页请求数据

分页处理的数据需要验证每页请求的数量，避免出现数据重复和缺失的情况（如第一页请求6个数据，第二页开始请求5个数据，导致出现重复）；下拉获取更多数据时较容易出现数据缺失的情况。

14、金额单位是元还是分

多个系统交互时，需注意两边的金额单位是否一致。

15、金额一分钱差异

金额类型进行计算操作可能有坑（先四舍五入后再计算还是先计算再四舍五入处理）；
两个地方取值来源和方式不同，比如明细里的总额是前端自己处理的，我的页面的总额是直接取后端返回的。

16、输入密码需要加密键盘

基于安全考虑，金融系统输入密码时需要使用加密键盘

17、放款时分账给各主体的金额

有的产品在放款/还款时需要分账，需要查看分账给各主体的具体金额是否正确。

18、放出/收到的钱和记账的钱需要匹配

需要关注放款表、实际放款的金额和借据金额、记账金额一致。

19、放款订单号和还款订单号不能重复

同一笔借据，即使放款和还款都是用同一支付方，也不能使用同一个订单号。

20、查询的订单号是否发起的订单号

发起支付的订单号是transno，查询时用了主键transid导致无订单数据。

21、合同落款时间

取当前签约时间还是合同时间，如果是当前签约时间，有可能由于签约失败隔天签约时合同落款时间非放款时间。

22、合同的签章主体

合同的签章主体需要和业务确认，避免出现签错章的情况。

23、合同上金额小数位数

合同上的金额数值需要精确到最低的数值，利率不能进行四舍五入。

24、连续解绑多张银行卡，解绑验证码需重置

解绑一张银行卡后，继续解绑第二张银行卡，此时获取短信验证码是否会直接取前一次的结果。

25、重置支付密码、设置支付密码是否可设置小于6位

如果仅校验两次输入的支付密码是否相等，有可能出现两次输入的密码确实相等但是并不等于6位的情况。

26、支付接口更改支付金额、手续费，后端有无校验

发起到支付系统的金额如果直接取支付接口的金额，则需要校验是否和账单金额一致，手续费是否和计算值一致，除了用户可更改支付金额的情况。

27、重复支付

同时操作同一笔订单（同一个账号不同客户端操作，不同用户操作同一笔账单）需拦截。

28、支付后跳转

支付成功后，选择系统键返回上一页或者页面返回上一页时，不能是支付页和支付确认。

29、还款计划表新增字段需要日终同步任务增加保存

如果借据表、还款计划表等表结构有新增字段，则日终处理任务中需增加处理和保存该字段，否则隔天/逾期后数据错误。

30、同一借据多期数据并行处理需考虑处理顺序

对借据进行还款、减免等操作时，需注意按期数顺序、科目顺序对项目进行处理。

31、借据的还款卡需要是用户选择的还款卡

当用户有多张银行卡时，借据的还款卡需要是用户设置的，且和代扣协议、借款合同对应，不可直接默认帮用户设置还款卡。

32、冲销利息时，计提也需修改

需要对借据进行冲销时，除了修改应收，还需要修改计提金额。

33、最后一期进行退货、提前结清、代偿等

在验证各种场景时，需要关注最后一期的处理，如最后一期内进行退货、提前结清、代偿；最后一期还款日进行退货、提前结清、代偿；最后一期宽限期进行退货、提前结清、代偿；以及这些场景下计算的手续费、应还利息等是否正确。

34、短信挡板

测试环境可能有短信挡板，上生产之前需要打开挡板验证是否能发送短信。

35、支付结果主动通知和异步查询

支付结果主动通知是指支付后将支付结果实时同步到其它系统；
需要有定时任务重推支付结果，因此支付结果的通知状态需要记录；
异步查询是指，如果没有主动通知/主动通知都异常，其它系统过来异步查询是否成功。

总结

PS：这里分享一套软件测试的自学教程合集。对于在测试行业发展的小伙伴们来说应该会很有帮助。除了基础入门的资源，博主也收集不少进阶自动化的资源，从理论到实战，知行合一才能真正的掌握。全套内容已经打包到网盘，内容总量接近500个G。如需要软件测试学习资料，关注公众号（互联网杂货铺），后台回复1，整理不易，给个关注点个赞吧，谢谢各位大佬！

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。