收银台界面 -- 支付方式测试开坑

前言

第一次接触支付系统测试时，原本以为可以轻松撰写一篇博客，因为测试前我也在网上查找了一些其他人的经验分享，发现大多只是浅尝辄止，讨论的测试场景较为简单。然而，在与同事交流后，我意识到支付测试远不止于此，它涉及到商品锁定库存、解锁库存（将库存信息存储到Redis并在失败时刷新释放）、发票处理、红冲操作以及月结付款等复杂业务逻辑。

因此，本文仅仅是支付测试系列的开篇之作，后续学到新知识会继续分享。

收银台支付方式初始方式

• 我们公司的支付方式是后台配置：
  
  每种支付方式会因为商户类型、渠道以及产品类型的不同而传递不同的参数。由于我需要测试的是手机渠道且商户类型是相同的，因此我只需要考虑产品类型的不同即可。
• 接口初始化收银台界面
  
  

测试场景

根据支付方式的初始化逻辑，我们可以构建一个基本的支付测试场景

细化支付场景

支付流程

选择支付方式：
正常

• 验证各种支付方式是否可以正常支付,各支付方式走完一个简单的支付流程
• 提示信息是否合理，订单状态是否改变

异常

• 支付时结合优惠券/折扣券/促销价抵扣进行相关的抵扣，验证规则正确，并且可以正常抵扣和支付
• 支付失败，系统的逻辑是否和需求一致
• 手机没有安装对应的支付方式，系统如何处理
• 重复点击支付按钮（防止系统发起多次支付请求）
• 支付中断的场景，主动中断以及被动中断。主动中断包括用户取消支付，此时须验证系统的逻辑是否和需求一致；支付超时 - 支付页面停留时间超过可支付的时间，此时支付系统的逻辑否和需求一致；关闭应用，此时订单是否是待付款状态还是其他的状态；返回上一步，用户在支付流程中选择返回到之前的步骤，验证此时的系统的逻辑。被动中断包括断网、电话等（时间不够可以不测）。

退款流程

正常

• 点击退款可以退款成功，并且检查交易状态是退款，退款金额可以到账
• 结合优惠券等抵扣，可以退款实际支付金额

异常

• 提交错误退款（退款订单号不对），或者退款金额错误，都能够退款失败（此处一般会借助工具进行mock测试）

签名有关知识

签名作用

签名是一种基于加密算法生成的字符串，用于验证消息的真实性和完整性。具体来说，在三方支付中，签名用于确认交易请求和响应数据的合法性和未被篡改。

签名与与防止重复支付的关系

结论：关系不大
起先和同事讨论时他和我讲测试支付时还需要验证签名的唯一性与时效性，为的是防止重复支付，比如我在app端下了一单到了收银台界面，拉起了三方支付，此时去网页端支付订单，如果签名不唯一的话app再支付就可能会出现重复支付的情况。
我就去抓包试了一下，app端和网页端的签名确实是不一致的，但是导致不一致的原因有很多：

• 不同的时间戳或随机数：每次请求时可能会包含不同的时间戳或随机数，这会导致即使对于相同的订单，生成的签名也会不同
• 环境差异：App端和网页端可能是由不同的服务器或者不同的API版本处理请求，因此它们可能使用不同的密钥、算法或者其他参数来生成签名
• 额外数据：两个端口可能在签名过程中包含了不同的额外数据或字段，这些细微的不同也会影响最终生成的签名值
• 签名生成规则：不同平台（如App端与网页端）可能有不同的签名生成规则，包括但不限于使用不同的哈希算法、不同的排序方式等。

后面查了一下防止跨平台会不会出现重复支付的方法主要是幂等性接口设计，幂等性意味着无论客户端发送多少次相同的请求，服务器端的响应和状态变更都只会发生一次。

Tips

• 测试支付有时是需要自己付钱的，注意问一问之前测过的同事退款方法
• 记得把身份证和银行卡带着，以备测试时的需要

总结

我也是第一次测试支付，一开始完全不知道怎么测，网上找了博客总是感觉没讲到重点，之后从代码实现的角度思考，再问了开发一些问题，向同事求教，总算是深入了一点~
年底了，各项目都要封版了，后面就随缘一两周吧~