支付测试场景设计

最新推荐文章于 2023-06-06 20:45:07 发布
最新推荐文章于 2023-06-06 20:45:07 发布
阅读量683 收藏 2
点赞数
分类专栏： 积累 文章标签： 用例设计
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/kairui_guxiaobai/article/details/122662761
版权

题目：支付界面一个金额输入框，一个提交按钮。
首先分析这个需求，输入金额后点击提交按钮，订单完成。
在这里插入图片描述

$团长$
关注
  • 0
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
毕业设计：基于SpringBoot的网上订餐系统，前后端分离，含支付功能-1.zip
08-03
该项目都是测试过了的，真实可靠，请放心使用。Spring Boot 是伴随 Spring 4 而产生的技术框架，具备良好的技术基因。在继承 Spring 框架所有优点的同时，它也为开发人员带来了巨大的便利。与普通的 Spring 项目相比，Spring Boot 可以简化项目的配置和编码，使项目部署更方便，而且它还为开发人员提供了“开箱即用”的良好体验，可以进一步提升开发效率。 Spring Boot 正在成为越来越流行的开发框架。从 Spring Boot 词条的百度指数可以确切地看出，开发人员对 Spring Boot 技术栈的关注度越来越高。Spring Boot 集成的技术栈丰富，不同公司使用的技术框架大部分可以无配置集成，即使不行，也可以通过自定义 spring-boot-starter 进行快速集成。这就意味着 Spring Boot 的应用场景非常广泛，包括常见的 Web、SOA 和微服务等应用。 在 Web 应用中，Spring Boot 提供了 spring-boot-starter-web 来为 Web 开发予以支持。spring-boot-starter-web 为开发人员提供了嵌入的 Tomcat 和 Spring MVC 的依赖，可以快速构建 MVC 模式的 Web 工程。 在SOA和微服务中，用 Spring Boot 可以包装每个服务。Spring Cloud 即是一套基于 Spring Boot 实现分布式系统的工具，适用于构建微服务。Spring Boot 提供了 spring-boot-starter-websocket 来快速实现消息推送，同时也可以整合流行的 RPC 框架，提供 RPC 服务接口（只要简单加入对应的 starter 组件即可）。
测试用例设计-支付功能
weixin_43461852的博客
10-26 6560
1.支付金额： 金额的最小值 金额的最大值 无对应订单 金额格式错误 金额数字错误（负数） 超限金额：设置的支付最高金额上限 余额不足 当日消费金额或次数超限 2.支付接口 修改用户发过去的数据 产品ID和金额不一致 提交不存在的订单/支付订单，篡改用户支付金额 3.支付操作 指纹支付 免密支付 账号+密码支付 动态获取支付验证码 银行卡号+密码 信用卡支付码 4.产品的容错性（异常处理） 退款-提交不存在的订单号 退款-提交不存在的支付订单号 退款-退款金额大于实际
基于SpringBoot开发的支付系统（包括支付宝支付，微信支付，订单系统）.zip
最新发布
08-03
该项目都是测试过了的，真实可靠，请放心使用。Spring Boot 是伴随 Spring 4 而产生的技术框架，具备良好的技术基因。在继承 Spring 框架所有优点的同时，它也为开发人员带来了巨大的便利。与普通的 Spring 项目相比，Spring Boot 可以简化项目的配置和编码，使项目部署更方便，而且它还为开发人员提供了“开箱即用”的良好体验，可以进一步提升开发效率。 Spring Boot 正在成为越来越流行的开发框架。从 Spring Boot 词条的百度指数可以确切地看出，开发人员对 Spring Boot 技术栈的关注度越来越高。Spring Boot 集成的技术栈丰富，不同公司使用的技术框架大部分可以无配置集成，即使不行，也可以通过自定义 spring-boot-starter 进行快速集成。这就意味着 Spring Boot 的应用场景非常广泛，包括常见的 Web、SOA 和微服务等应用。 在 Web 应用中，Spring Boot 提供了 spring-boot-starter-web 来为 Web 开发予以支持。spring-boot-starter-web 为开发人员提供了嵌入的 Tomcat 和 Spring MVC 的依赖，可以快速构建 MVC 模式的 Web 工程。 在SOA和微服务中，用 Spring Boot 可以包装每个服务。Spring Cloud 即是一套基于 Spring Boot 实现分布式系统的工具，适用于构建微服务。Spring Boot 提供了 spring-boot-starter-websocket 来快速实现消息推送，同时也可以整合流行的 RPC 框架，提供 RPC 服务接口（只要简单加入对应的 starter 组件即可）。
测试面试题-测试场景设计
03-12
# 测试场景设计 ## 扫码付款场景 【扫码支付验证场景】 1.二维码 　　二维码是否可扫描，扫描弹出页面是否正确 　　扫描弹出是固定金额还是需要手动输入金额 　　二维码时长有效性 　　过期二维码扫描 　　模糊二维码扫描 　　保存图片后扫描 2.扫码 　　多用户对同一个订单进行扫描，只能被付款一次 　　扫码过程中断验证，有来电等 　　扫码后切回其他程序，切回后页面状态 3.支付 　　对接不同三方平台支付 　　同一笔订单重复支付 　　金额验证 　　　　输入单笔金额的最大、最小值 　　　　金额限定小数点最后2位 　　　　支付金额不能为空、0、负数 　　单日成交最大限额 　　如果是固定金额支付，验证篡改金额是否能成功支付（一般支付接口有签名验证，防止篡改） 　　支付后验证付款方金额是否扣减 　　支付成功金额是否立即到账/按约定延时到账 　　支付后是否返回支付信息给用户及收款方 　　支付结果
软件测试测试点汇总（不含支付测试）
04-25
这个是我整理的软件测试测试点，包含接口测试，界面测试等内容，需要要xmind打开
支付功能测试用例
software_test010的博客
06-06 5038
支付功能测试非常重要，因为支付是涉及到用户资金安全的重要功能，如果支付功能存在问题，可能回导致用户资金或平台损失或者其他安全问题。同时，支付功能也是一个网站或应用的核心功能之一，如果支付功能存在问题，可能会影响用户体验和信任度，甚至会影响到业务的正常运营。因此，进行支付功能测试是非常重要的。 首先，我们列举一下支付功能测试点有哪些。
支付用例设计
m0_47215407的博客
05-05 715
功能测试 性能测试 安全测试 兼容性测试 可靠性测试 注意点
【设计模式】【第一章】【支付场景】【策略模式 + 工厂模式 + 门面模式 + 单例模式】
Java程序员廖志伟
09-25 1536
【设计模式】【支付场景】【策略模式 + 工厂模式 + 门面模式 + 单例模式】
支付场景的测试用例
didi1663478999的博客
09-19 6386
功能测试： 1.是否可以正常支付 2.支付金钱的最大值，最小值，错误金额 3.支付中断继续支付是否成功 4.支付中断后结束支付 5.支付中断结束后再一次支付 兼容性 1.pc端，手机端，平板电脑 安全性： 1.姓名会不会显示给对方 2.对方账户异常，会不会提示 支付接口 1.pose端，银行卡网银 容错性： 1.支付失败后怎么进行退单 ...
二维码支付场景测试用例
tuery1314的专栏
04-26 2292
总的来说，二维码支付场景中可能出现的异常情况相当多，因此需要在测试前完成充分的场景规划及测试用例设计，并对异常情况进行系统分类和处理，以保证二维码支付系统的安全性、稳定性和可靠性。- 使用已过期的支付账号进行支付，提示账号已过期，请重新绑定或使用其他支付账号。- 使用非本人支付账号进行支付，提示账号不一致，请使用正确的支付账号进行支付。- 使用已注销或冻结的支付账号进行支付，提示账号状态异常，请联系客服处理。- 使用不支持的支付渠道进行支付，提示不支持该支付渠道。
非常好的某网站性能测试用例
04-27
某网站性能测试用例 某网站提供会员模板下载、上传、购买、支付等功能，目前进入性能测试阶段，通过性能需求可以了解到主要有以下几个性能指标需要进行测试： 　　● 产品页面刷新性能 　　● 产品上传性能 　　● 产品下载性能 　　目前给出的指标为： 　　延迟： 　　测试项 响应时间 抖动 备注 　　产品页面刷新 <5秒 <2秒 　　产品下载相应时间 <4秒 <2秒 　　吞吐量： 　　编号 项 吞吐量 　　Perf.T.1 所有登录用户在线状态更改频率 每10分钟1次 　　Perf.T.2 每日页面平均访问量 60000次 　　Perf.T.3 每日下载量 50000 　　Perf.T.4 平均每日新增会员数量 500 　　Perf.T.5 高峰同一模板下载量 100用户并发下载 　　Perf.T.6 高峰不同模板下载量 150用户并发下载 　　容量： 　　编号 项 容量 　　Perf.C.1 用户数 <=100万 　　Perf.C.2 活动用户数 10000 　　Perf.C.3 模板中心总用户数 <=25万 　　根据如上性能需求及数据我们该如何设计性能测试用例及场景呢？（可以说给出的性能需求很垃圾，没有丝毫价值，但没办法还是点做啊） 　　首先，我不去在乎它要求的性能是什么，我只需要去做在一定的测试环境下对系统进行压力测试，找到各个性能指标的临界点就好了，至于是否达到性能指标，在和性能需求对照编写测试报告即可。 　　所以，针对这几个需要进行性能测试的页面，我们做一下分析，如何设计场景才能尽可能准确地体现出系统的性能： 　　先说一下搜索页面 　　搜索页面根据对项目的了解，搜索后，将所有符合条件的结果遍历出来，显示在前台，每页的显示数量是一定的，超出的部分分页显示。根据上面的描述我们可以看出搜索结果是在将符合条件的所有结果集均发送到前台页面，对于页面显示对性能的消耗我们可以忽略不计，主要的压力来自数据的传输、sql的执行及应用服务器的处理过程，所以我可以从两个方面设计场景： 　　a、虚拟用户一定，不同数据库数量级的情况下，搜索的性能 　　如何确定虚拟用户的数量成为一个关键，我们可以让客户提供一个常规情况下每天访问用户数（如果没有实际数据可参考，可以根据产品方案中期望的用户数来代替），我们就用这个用户数来进行测试；再来分析一下不同的数据库数量级，如果系统运营1年的产品数据量是5万条，那么我们就根据这个值分别取1W条、3W 条、5W条、10W条、20W条数据量来进行测试（具体的分法可以根据实际情况而定），所以对于这个测试目标，我们可以设计5个场景进行： 　　虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间 　　100 10000 搜索页面 随机产生 30分钟 加入思考时间 　　100 30000 搜索页面 随机产生 30分钟 加入思考时间 　　100 50000 搜索页面 随机产生 30分钟 加入思考时间 　　100 100000 搜索页面 随机产生 30分钟 加入思考时间 　　100 200000 搜索页面 随机产生 30分钟 加入思考时间 　　b、一定数据库数量级，不同量虚拟用户的情况下，搜索的性能 　　我们定下来一个常规的数据库数据量，在数据量不变的情况下逐步增加虚拟用户数，测试一下不同虚拟用户压力下系统的性能 　　虚拟用户数 数据库数量级 录制页面 并发用户数执行时间思考时间 　　50 50000 搜索页面 随机产生 30分钟 加入思考时间 　　80 50000 搜索页面 随机产生 30分钟 加入思考时间 　　100 50000 搜索页面 随机产生 30分钟 加入思考时间 　　120 50000 搜索页面 随机产生 30分钟 加入思考时间 　　150 50000 搜索页面 随机产生 30分钟 加入思考时间 　　产品上传 　　影响上传性能的主要因素有上传文件的大小和上传的请求数，所以我们就从这两个方面设计用例。 　　a、虚拟用户数一定，上传不同大小的文件 　　虚拟用户数 上传文件大小 录制页面 并发用户数 执行时间 思考时间 　　50 100k 上传页面 随机产生 30分钟 取消思考时间 　　50 300k 上传页面 随机产生 30分钟 取消思考时间 　　50 500k 上传页面 随机产生 30分钟 取消思考时间 　　50 800k 上传页面 随机产生 30分钟 取消思考时间 　　50 1M 上传页面 随机产生 30分钟 取消思考时间 　　b、上传文件大小一定，不同量的虚拟用户 　　虚拟用户数 上传文件大小 录制页面 并发用户数执行时间思考时间 　　20 300k 上传页面 随机产生 30分钟 取消思考时间 　　50 300k 上传页面 随机产生 30分钟 取消思考时间 　　80 300k 上传页面 随机产生 30分钟 取消思考时间 　　100 300k 上传页面 随机产生 30分钟 取消思考时间 　　产品下载 　　影响下载性能的主要因素有下载文件的大小和下载的请求数，所以我们就从这两个方面设计用例 　　a、虚拟用户数一定，下载不同大小的文件 　　虚拟用户数 下载文件大小 录制页面 并发用户数执行时间思考时间 　　50 100k 下载页面 随机产生 30分钟 取消思考时间 　　50 300k 下载页面 随机产生 30分钟 取消思考时间 　　50 500k 下载页面 随机产生 30分钟 取消思考时间 　　50 800k 下载页面 随机产生 30分钟 取消思考时间 　　50 1M 下载页面 随机产生 30分钟 取消思考时间 　　b、下载文件大小一定，不同量的虚拟用户 　　虚拟用户数 下载文件大小 录制页面 并发用户数 执行时间 思考时间 　　20 300k 下载页面 随机产生 30分钟 取消思考时间 　　50 300k 下载页面 随机产生 30分钟 取消思考时间 　　80 300k 下载页面 随机产生 30分钟 取消思考时间 　　100 300k 下载页面 随机产生 30分钟 取消思考时间
第三方支付系统如何做软件测试？案例分析
03-04
此外，还存在转出账户处于异常状态、转出账户余额不足、转入账户处于异常状态、转账金额超过交易限额、转账支付撤销等异常情况，如图2所示。图2该系统转账流程综合以上情况，整个转账过程包含很多事件，将登录作为起始事件，登录后的不同操作会进一步触发不同的事件，这些事件在被触发时形成了不同的场景，因此我们可以采用场景法，将正常的转账过程作为基本流，将特殊情况和异常情况的处理过程作为备份流，根据确定的基本流和备份流形成不同场景并设计相应的测试用例，最后通过执行测试用例完成测试。2、退款流程测试退款业务属于异常交易处理范畴，本系统提供的退款方式较多包括单笔退款、批量退款、多次退款、人工退款等，此外由于退款还涉
【转】支付宝的性能测试
08-13
2013年双11过程当中，促销开启的第一分钟内支付宝的交易总额就突破了一亿元，短时间内大量用户涌入的情况下，如何保证用户的支付顺畅，是对支付宝应用系统的一个极大的挑战。 　　一、性能测试支付宝场景介绍 　　2013年双11过程当中，促销开启的第一分钟内支付宝的交易总额就突破了一亿元，短时间内大量用户涌入的情况下，如何保证用户的支付顺畅，是对支付宝应用系统的一个极大的挑战。 　　支付宝的性能测试场景分为性能基线测试，项目性能测试。 　　任意一笔交易过来，我们都需要对交易进行风险扫描，对于有可能是账户盗用的交易，我们会把这笔支付直接拒绝掉，或者通过手机校验码等方式进行风险释放。 　　我们有一个老的扫描平台A，现在需要构建一个新的扫描平台B，对A中关键技术进行升级，并增加额外的功能。扫描的策略是存储在DB中的，需要通过发布来更新到应用服务器的内存中。。。。。
收钱吧支付测试点.xmind
09-03
公司支付对接收钱吧测试点整理，由于业务不一样，开发设计不一样，不一定是通用，但可以提供测试思路
【更新】互联网公司可投之参考
热门推荐
许嵩不爱吃土豆的博客
10-17 3万+
【更新】互联网公司可投之参考以下内容收集于网络资料，仅供参考。如有误请指正~，未经允许，禁止转载。不介意的话，放个自己的字节内推，投递链接https://jobs.toutiao.com/s/dp5bxEK，内推码：AJCWZR2北京公司上海公司广州公司深圳公司武汉公司杭州公司成都公司成都公司长沙公司...小伙伴们觉得有用的话可以关注点赞收藏，后面持续更新~ 以下内容收集于网络资料，仅供参考。如有误请指正~，未经允许，禁止转载。 #目前已更新：北京、上海、广州、深圳、武汉、杭州、成都、南京、长沙… 不介意的
金额输入框校验
weixin_46745445的博客
01-19 1137
金额校验 input框输入金额范围，查找内容；校验金额合法性，保留两位小数 效果： 实现步骤： xx.html <input type="text" id="startMoney" name="startMoney" onkeyup="verify(this)" style="width:100px" /> <span>~</span> <input type="text" id="endMoney" name="endMoney" onkeyup="verify
发红包的测试用例设计点
weixin_45819693的博客
11-23 1240
发红包的测试用例设计点 功能测试 红包金额输入框是否只能输入数字和小数点，小数位数是否有限制，如果直接输入点，点前是否有0 红包个数输入框中是否只能输入数字 红包金额框输入的数字，最多200，最少0.01，如果不在该范围内是否有提示 红包个数框输入的数字，最多100，最少1，如果不在该范围内是否有提示 红包的描述框是否可以输入英文、中文、符号、数字、特殊字符、表情等，他们是否可以搭配使用，是否可以删除 以上提及的输入框是否允许复制粘贴操作 是否可以再普通红包和拼手气红包之间进行切换 按返回键是否可以取消发
微信发红包测试用例
快乐的大儿童附体
09-08 204
如何测试支付宝手机充值的这个功能，写出测试用例
m0_58079308的博客
11-29 5582
有人在面试软件测试的时候，被问到如何测试支付宝手机充值的这个功能，写出测试用例。 其实无论测试什么，我们首先的需要梳理软件业务的流程，来看看支付宝充值都有哪些流程？ 首先，面试官如果给出的是这样一个场景就不应该从支付宝的注册开始，注册之后的登录 而是直接可以按照下面的流程开始进行： 第一步：点击充值页面，检查页面是否可以正常的进入充值页面 进入充值页面之后，检查整个页面的布局是否合理，显示简洁和整洁。 第二步：检查手机号是否显示自己常用的充值号码，并且是否支持修改为其他人的手机号充值
什么是场景设计法测试方法，并举例说明
07-14
场景设计法测试方法是一种测试用例设计方法，它基于系统的实际使用场景，通过模拟用户的真实操作和交互来设计测试用例。场景设计法测试方法着重于测试系统在不同场景下的功能、性能和用户体验。 举个例子来说明场景设计法测试方法：假设有一个电子商务网站系统，其中包含用户注册、商品浏览、购物车管理、下单和支付等功能。 我们可以使用场景设计法测试方法设计测试用例。首先，我们需要识别系统的不同使用场景，并根据这些场景来设计测试用例。 以一个购物场景为例，假设用户在网站上购买商品的过程如下： 1. 用户注册并登录。 2. 用户浏览商品，筛选并选择感兴趣的商品。 3. 用户将商品添加到购物车。 4. 用户管理购物车，包括增加、删除和修改商品数量。 5. 用户提交订单并选择支付方式。 6. 用户完成支付。 基于这个购物场景，我们可以设计一些测试用例： 1. 正常购买流程： - 用户注册并登录。 - 用户浏览商品，选择一件商品。 - 用户将商品添加到购物车。 - 用户提交订单并选择支付方式。 - 用户完成支付。 - 预期结果：订单成功生成，支付成功。 2. 购物车管理： - 用户注册并登录。 - 用户浏览商品，选择多件商品。 - 用户将商品添加到购物车。 - 用户修改购物车中某个商品的数量。 - 用户删除购物车中某个商品。 - 用户提交订单并选择支付方式。 - 用户完成支付。 - 预期结果：订单成功生成，支付成功。 通过设计这些测试用例，我们模拟了用户在实际场景中的操作和交互，测试了系统在不同场景下的功能、性能和用户体验。场景设计法测试方法有助于发现系统在实际使用中可能出现的问题，并提高测试的实用性和可靠性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

$团长$

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值