测试用例之支付功能测试点整理【建议收擦】

本文详细阐述了支付系统的测试流程,包括选择支付方式、确认金额、输入密码等阶段的测试点,强调了功能测试、接口测试、安全测试的重要性,并列举了支付流程中的常见问题和测试案例,如金额一致性、支付入口覆盖、支付成功后的订单状态等。同时,文中分享了实际工作中遇到的坑,提醒测试人员需全面覆盖支付流程,防止线上事故的发生。

一、梳理支付的业务流程如下 :

  点击支付---> 选择支付方式 ---> 确认金额---> 输入密码 ---> 成功支付

  完成这个流程测试,也就是完成了项目的冒烟测试!然后需要测试针对流程中的每个阶段和步骤,具体分析可能导致异常的测试点,所以我们按阶段和输入项来进行划分。

  如下:

  非现金支付时代,非现金支付已经成为了生活不可或缺的一部分,我们只需要一台手机便可走遍全国各地(前提是支付宝,微信有钱<00>),那么作为测试人员,支付测试也是非常重要的一环,那么下面我就结合一下我的工作中遇到的一些问题,总结一下常见的支付测试:

  一:支付的分类:

  首先,根据不同维度,通常我们可以把支付分为如下图所示的种类:

  其次,一般来讲,线上支付分为两种消费模式。一种是直接支付金额,如淘宝,京东等购物网站,或是360云盘,视频会员等这种会员服务;另一种是充值购买金豆之类的虚拟币,在网站中使用虚拟币进行消费,比如游戏平台、花椒等产品!

  其次,一般来讲,线上支付分为两种消费模式。一种是直接支付金额,如淘宝,京东等购物网站,或是360云盘,视频会员等这种会员服务;另一种是充值购买金豆之类的虚拟币,在网站中使用虚拟币进行消费,比如游戏平台、花椒等产品!

  二:功能测试

  接下来就是测试方面的工作了,首先进行的是功能测试,那么我将边界值、等类划分、错误推测,因果图等各种测试方法相结合,整理出来了一套相对全面的测试案例,对支付功能进行测试,从而确保整个支付流程和涉及到的支付流程在任何情况下都能使用。

  三:接口测试

  明确整个支付流程所需要调用的接口,分清楚商家和第三方平台的接口以及参数的请求方式,包括对接口特定参数的加密,使用异常单号模拟支付,对服务端的检验等等。

  四:安全测试

  支付都会涉及到金额,那么就需要考虑安全测试这个方面,支付请求的伪造,金额的恶意篡改,恶意模拟第三方接口来调用商家接口等,均是我们需要考虑清楚的问题。

  五:支付流程

  如下图:

  六:测试点

  支付流程测试点

  1、付款金额和应付金额是否一致,(比如:扫描的支付二维码,和显示的应支付金额是否一致)。支付还是要走整个支付流程才行,从确认订单到最后的支付成功,任何一步都有可能有问题。

  2、同一种支付方式,不同的支付入口(比如:如下图所示,支付宝有两个支付入口。即可通过扫描二维码支付,也可以通过支付宝网页支付。在测试过程中,两个入口都要覆盖到。

  3、支付成功后,产品购买是否成功。

  比如会员服务产品,购买后会员到期时间是否正常延迟;比如购买商品,支付成功后,订单状态是否更改,商品种类和数量是否正确等等。

  4、支付成功后,用户的金额是否扣除成功。

  支付金额测试点

  1、正常金额支付

  2、金额的最小值:0.01

  3、无意义的值:0元

  4、最大金额:设置支付的最大金额

  5、银行卡或微信等,设置每日最大消费金额或者单笔最大消费金额

  6、银行卡或微信余额不足时支付

  支付流程测试点

  1、正常完成支付流程

  2、调起订单后,取消订单

  3、支付中断后,继续支付

  4、支付中断后结束支付

  5、单笔订单单笔支付

  6、多订单合并支付

  7、持续点击支付,是否会出现多次购买

  支付方式测试点

  1、支付宝支付

  2、支付宝网页支付

  3、微信支付

  4、银行卡支付

  · 优惠券或折扣(有一定的优惠)

  · 支付中使用优惠券/折扣,应付金额和实际支付金额是否正确

  · 优惠券/折扣是否是必选,是否可以不选择折扣

  · 支付订单退款完成后,优惠券/折扣是否还能使用

  坑一:页面显示的应付金额通过接口vip.product返回了,前端显示出来应付金额。但是,支付的二维码是通过接口vip.getPayUrl这个接口返回的,结果二维码扫出来的值和显示的应付金额不一样呀!!!最后问题是在于,vip.getPayUrl中取的是服务器缓存,导致二维码显示的金额跟前端展示的应付金额不一致。所以测试支付还是要走整个支付流程才行,从确认订单到最后的支付成功,任何一步都有可能有问题。

  坑二:通过支付宝网站支付,支付成功后,页面没有跳转回原服务套餐网页。最后的原因是服务配置的return_url不正确,导致支付后,没有跳回原页面。如果测试用例覆盖不到这种场景,那么将会造成非常严重的线上事故。

最后感谢每一个认真阅读我文章的人,看着粉丝一路的上涨和关注,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

<think>好的,我需要为用户寻找关于支付功能的测试用例示例,并且确保回答符合IT软件质量保证的要求。首先,我要回忆一下软件测试的基本知识,特别是支付功能的关键测试支付功能涉及多个方面,比如接口、安全性、用户体验、异常处理等,所以测试用例需要覆盖这些方面。 首先,支付流程的正常流程测试。用户发起支付请求,输入正确的支付信息,系统应该处理成功并返回正确的状态。这时候需要验证订单状态是否更新,支付金额是否正确,以及是否有支付成功的通知。这部分可以参考用户提到的引用[4],关于接口功能的测试,确保数据结构与文档一致,正常功能完成。 然后是支付接口的参数检查。比如必填字段缺失、金额格式不正确(比如负数或非数字)、超长字符等。这些属于参数检查测试,引用[4]提到参数检查和异常测试,所以需要设计这些用例。 接下来是安全性测试。支付涉及敏感信息,必须测试敏感信息是否加密传输,比如使用HTTPS。另外,重复提交支付请求是否被拦截,防止重复扣款。还有SQL注入和XSS攻击的防范,确保系统安全。这部分可能没有直接引用,但属于常见的安全测试,需要包含进去。 异常场景测试,比如网络中断、支付超时、余额不足等。这时候系统应该有友好的错误提示,并且订单状态正确处理。比如余额不足时提示用户,而不会导致支付流程崩溃。引用[2]提到测试用例需要保证不遗漏测试功能,所以这些异常情况必须考虑。 兼容性测试也很重要,不同浏览器、移动设备、操作系统上的支付功能是否正常。引用[3]提到DOM和UI的一致性,可能涉及跨平台兼容性,所以需要包括这部分。 性能测试方面,比如高并发下的支付处理能力,响应时间是否在可接受范围内。支付接口的压力测试,确保系统稳定。引用[1]提到测试计划依据标准,可能包括性能要求,所以需要加入性能测试用例。 还需要考虑第三方支付平台的集成,比如支付宝、微信支付等,测试回调处理是否正确,对账是否准确。比如支付成功后第三方通知是否正常,订单状态同步是否及时。 另外,支付后的业务流程,比如生成订单记录、库存扣减、用户通知等。这部分属于支付后的联动测试,确保整个业务流程正确。引用[2]提到测试用例的八大要素,执行性很重要,所以这些联动测试需要详细说明。 最后,国际支付的考虑,比如多币种处理、汇率转换、跨境支付的手续费等。如果系统支持国际支付,这些测试也是必要的。 现在整理这些测试,按照不同的分类生成测试用例,确保覆盖全面。同时参考用户提供的引用内容,特别是接口测试、测试用例设计要素等方面。需要注意每个测试用例的步骤、预期结果,并且保持结构清晰,方便用户理解和使用。</think>### 支付功能测试用例示例(IT软件质量保证) #### 1. **正常支付流程验证** - **用例1**:用户使用有效支付方式(如支付宝)完成支付 - 步骤:选择商品 → 提交订单 → 输入正确支付信息 → 确认支付 - 预期结果:支付成功,订单状态更新为“已支付”,支付成功通知[^4]。 - **用例2**:支付金额与订单金额一致性验证 - 步骤:订单金额为$100$元 → 发起支付 - 预期结果:支付接口请求金额为$100$元,支付记录与订单金额一致[^4]。 #### 2. **支付接口参数检查** - **用例3**:必填字段缺失(如缺少`order_id`) - 步骤:调用支付接口时不传`order_id` - 预期结果:返回错误码(如`400 Bad Request`),提示“订单号缺失”。 - **用例4**:金额格式异常(如负值、非数字) - 步骤:支付金额传值为`-100`或`abc` - 预期结果:接口拒绝请求,提示“金额格式错误”。 #### 3. **安全性测试** - **用例5**:敏感信息加密传输 - 步骤:抓包检查支付请求中的银行卡号、CVV码 - 预期结果:敏感字段通过HTTPS加密传输,明文不可见。 - **用例6**:重复支付拦截 - 步骤:同一订单号重复发起支付请求 - 预期结果:第二次请求返回“订单已支付,请勿重复提交”。 #### 4. **异常场景处理** - **用例7**:网络中断后支付恢复 - 步骤:支付过程中断网 → 网络恢复后重试 - 预期结果:支持断支付,订单状态最终正确[^2]。 - **用例8**:账户余额不足 - 步骤:使用余额支付时余额为$0$ - 预期结果:提示“余额不足,请更换支付方式”。 #### 5. **第三方支付集成** - **用例9**:支付宝回调处理验证 - 步骤:模拟支付宝异步通知支付成功 - 预期结果:订单状态更新为“已支付”,日志记录完整[^3]。 - **用例10**:微信支付超时处理 - 步骤:支付超时未到微信回调 - 预期结果:系统主动查询支付状态并同步订单。 #### 6. **兼容性与性能** - **用例11**:多浏览器兼容性 - 步骤:在Chrome、Safari、Firefox中完成支付 - 预期结果:支付页面渲染正常,功能无异常[^3]。 - **用例12**:高并发支付压力测试 - 步骤:模拟$1000$用户同时支付 - 预期结果:接口响应时间$<2$秒,无事务锁冲突[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值