实时警报通知：微信告警通知的重要性解析
989
2023-01-31
关于支付系统性能测试的信息
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
本篇文章给大家谈谈支付系统性能测试，以及对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
今天给各位分享支付系统性能测试的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
1、从功能方面考虑支付系统性能测试：
1）、用户支付系统性能测试的使用场景支付系统性能测试：包括正常完成支付的流程；
支付中断后继续支付的流程；
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；未绑定银行卡；密码错误；密码错误次数过多；找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：
包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，
(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试
二.购物车怎么测试？
1.功能测试
a）、未登录时：
将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。
b）、登录后：
所有链接是否跳转正确；
商品是否可以成功加入购物车；
购物车商品总数是否有限制；
商品总数统计是否正确；
全选功能是否可用；
删除功能是否可用；
价格总计是否正确；
商品文字太长时是否显示完整；
购物车中下架的商品是否有标识，是否还能支付；
新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
是否支持快TAB、ENTER等快捷键；
商品删除后商品总数是否减少；
收藏功能是否可用；
购物车结算功能是否可用。
2.兼容性测试：
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等
3.用户体验测试：
删除商品是否有提示；
是否支持快捷键功能；
是否有回到顶部的功能；
商品过多时结算按钮是否可以浮动显示；
购物车有多个商品时，能不能只对单个商品结算；
界面布局、排版是否合理；
文字是否显示清晰；
不同卖家的商品是否区分明显。
4.性能测试：
打开购物车页面要多长时间.
输入框怎么测试？
1、长度：例如输入框支持100字符， 那需要测试100字符、101字符，最大长度的显示是否正常；
2、哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符；
3、是否支持换行；
4、字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
5、全角半角的字母、数字
6、快捷键：能不能全选，部分选择，复制剪切粘贴是否可用，粘贴超过最大长度的字符串怎么显示，table键盘是否可用；
7、不同终端的兼容性
三.登陆功能怎么测试？
功能方面的测试：
1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确 的页面
2.输入错误的用户名, 验证登录失败，并且提示相应的错误信息
3.输入错误的密码, 验证登录失败，并且提示相应的错误信息
4.用户名为空, 验证登录失败，并且提示相应的错误信息
5.密码为空, 验证登录失败，并且提示相应的错误信息
6.用户名和密码都为空，点击登陆
7.用户名和密码前后有空格的处理
性能方面的测试
1.打开登录页面，需要多长时间
2.输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间.
安全性方面的测试
1.密码是否在前端加密，在网络传输的过程中是否加密
2.用户名和密码的输入框，能否防止SQL注入攻击
3.用户名和密码的输入框，能否防止XSS攻击
4.错误登陆的次数限制（防止暴力破解）
5.是否支持多用户在同一机器上登录
6.一个用户在不同终端上登陆
7.用户异地登陆
用户体验测试：
1.页面布局是否合理，输入框和按钮是否对齐
2.输入框的大小和按钮的长度，高度是否合理
3.是否可以全用键盘操作，是否有快捷键
4.输入用户名，密码后按回车，是否可以登陆
5. 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
兼容性测试
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等
四.支付功能怎么测试？
1、从功能方面考虑：
1）、用户的使用场景：包括正常完成支付的流程；
支付中断后继续支付的流程；
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；未绑定银行卡；密码错误；密码错误次数过多；找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：
包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，
是否防止SQL注入，XSS攻击(跨站脚本攻击)。
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试 .
五.还款怎么测试？
功能上：
1.不同的还款方式：等额本息，等额本金还款，一次性还本付息。
2.逾期，提前还款和第三方还款。
3.不同账户的还款。
4.余额不足的还款，.
5.金额输入错误，不输入。
6.弱网状态下连续点击还款按钮或者系统不问题情况下，支付方未把支付结果返回给下单发起方。
从性能方面考虑：
还款的响应时间；
从安全性方面考虑：
是否防止SQL注入，XSS攻击(跨站脚本攻击)。
还款金额是否被拦截，还款密码等敏感信息是否加密。
从用户体验方面考虑
系统界面是否容易理解。
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
兼容性：
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试 .
《附》
支付流程：
用户发送下单请求-平台后台查看订单并制作支付请求后将请求传给第三方（银行）-银行将支付的信息反馈给客户，客户核对后输入支付密码--银行成功划账后将支付成功信息告知给平台后台和用户--平台确认支付信息反馈给第三方并发货.
退款流程：
用户提交退款申请给平台，平台后台通过审核后将退款信息告知给第三方（银行），第三方将钱退到用户绑定的银行账户中并告知平台处理结果。平台确认结果后并结束用户退款申请。
六.电梯如何测试？
需求测试：
查看电梯使用说明书、安全说明书等
界面测试：
查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4.报警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按支付系统性能测试了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
可靠性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层号码。
4.多次点击同一楼层的号码等等。
5.同时按上键和下键会怎样。
易用性：
1.电梯的按钮的设计符合一般人使用的习惯吗．
负载/压力测试：
1.看电梯的最大限度的承受重量．在负载过重时是否有提醒。
2.在一时间内不断的让电梯上升，下降。
稳定性测试：
1.最大负载下平稳运行的最长时间。
文档测试：
1.使用手册是否对电梯的用法、限制、使用条件等有详细描述.
广义：建立基准线，当系统软硬件环境发生变化之后再进行一次基准测试以确定变化对性能的影响。
1.概念：通过逐步增加系统负载，确定在满足性能指标的情况下，找出系统所能承受最大负载的测试。
作用：系统最大负载量达到用户要求时，系统才能正式上线。
注意：①通过负载测试，可以确定系统的最大负载量和极限负载量
②系统对外宣称的最大负载量
③负载测试的时间一般为1-2小时
1.概念：在服务器稳定运行（用户正常业务负载下）的情况进行长时间测试（1天-一周等），并最终保证服务器能满足线上业务需求。
2.系统在用户需求的业务负载下运行达到规定的时间时，系统才能正式上线使用。
1.概念：在强负载下的测试，查看系统在峰值下是否功能隐患、系统是否具有良好的容错能力和可恢复的能力。
2.测试场景：高负载下的长时间稳定性压力测试 （如：B-C区间内进行24/3*24小时长时间测试）极限负载下的破坏性压力测试（如：C-D区间内进行测试）
1.概念：在极短时间内，发送多个请求，来验证服务器对并发的处理能力。
2.应用场景：特定的活动场景：抢红包、秒杀、抢购等。
3.与负载测试对比：
负载测试：主要目的是测试高负载情况下，对系统资源的消耗，是否会耗尽的问题（双11活动）
并发测试：主要目的是测试极短时间内，并发请求时，系统资源争抢的问题（抢红包、秒杀）
1.指从客户端发起请求开始，到客户端接收到结果的总时间
2.包括：服务器处理时间 + 网络传输时间
某一时刻同时向服务器发送请求的用户数
1.概念：单位时间内处理客户端的请求数量，直接体现软件系统的承载能力。
2.吞吐量单位分类
QPS：每秒查询数，即控制度服务器每秒处理的指定请求数量。
TPS（Transaction Per Second）每秒事务数，即控制服务器每秒处理事务请求的数量。
如：支付请求事务=查询用户余额请求+校验支付安全请求+发送支付请求
每秒处理查询用户余额15请求，每秒处理校验支付安全15个请求，每秒处理发送支付15个请求
支付tsp为15
所有的页面元素（如：图片、链接、框架等）的请求总数 量
注意：点击数是请求数，不是页面上的一次点击
指系统在负载情况下，失败业务的概率
注意：
①.错误率是性能指标，是高负载下的失败业务的概率
②.随机bug是功能bug，先解决随机bug才能进行性能测试
1.概念：系统各种资源的使用情况，率=资源使用量/总资源可用量x100%
常见资源指标：
CPU使用率：不高于75%-85%
内存大小使用率：不高于80%
磁盘IO（速率）：不高于90%
网路（速率）：不高于80%
本文目录一览：
各种功能测试点步骤
一.支付功能怎么测试？1、从功能方面考虑支付系统性能测试：
1）、用户支付系统性能测试的使用场景支付系统性能测试：包括正常完成支付的流程；
支付中断后继续支付的流程；
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；未绑定银行卡；密码错误；密码错误次数过多；找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：
包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，
(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试
二.购物车怎么测试？
1.功能测试
a）、未登录时：
将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。
b）、登录后：
所有链接是否跳转正确；
商品是否可以成功加入购物车；
购物车商品总数是否有限制；
商品总数统计是否正确；
全选功能是否可用；
删除功能是否可用；
价格总计是否正确；
商品文字太长时是否显示完整；
购物车中下架的商品是否有标识，是否还能支付；
新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
是否支持快TAB、ENTER等快捷键；
商品删除后商品总数是否减少；
收藏功能是否可用；
购物车结算功能是否可用。
2.兼容性测试：
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等
3.用户体验测试：
删除商品是否有提示；
是否支持快捷键功能；
是否有回到顶部的功能；
商品过多时结算按钮是否可以浮动显示；
购物车有多个商品时，能不能只对单个商品结算；
界面布局、排版是否合理；
文字是否显示清晰；
不同卖家的商品是否区分明显。
4.性能测试：
打开购物车页面要多长时间.
输入框怎么测试？
1、长度：例如输入框支持100字符， 那需要测试100字符、101字符，最大长度的显示是否正常；
2、哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符；
3、是否支持换行；
4、字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
5、全角半角的字母、数字
6、快捷键：能不能全选，部分选择，复制剪切粘贴是否可用，粘贴超过最大长度的字符串怎么显示，table键盘是否可用；
7、不同终端的兼容性
三.登陆功能怎么测试？
功能方面的测试：
1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录，能否能跳转到正确 的页面
2.输入错误的用户名, 验证登录失败，并且提示相应的错误信息
3.输入错误的密码, 验证登录失败，并且提示相应的错误信息
4.用户名为空, 验证登录失败，并且提示相应的错误信息
5.密码为空, 验证登录失败，并且提示相应的错误信息
6.用户名和密码都为空，点击登陆
7.用户名和密码前后有空格的处理
性能方面的测试
1.打开登录页面，需要多长时间
2.输入正确的用户名和密码后，登录成功跳转到新页面，需要多长时间.
安全性方面的测试
1.密码是否在前端加密，在网络传输的过程中是否加密
2.用户名和密码的输入框，能否防止SQL注入攻击
3.用户名和密码的输入框，能否防止XSS攻击
4.错误登陆的次数限制（防止暴力破解）
5.是否支持多用户在同一机器上登录
6.一个用户在不同终端上登陆
7.用户异地登陆
用户体验测试：
1.页面布局是否合理，输入框和按钮是否对齐
2.输入框的大小和按钮的长度，高度是否合理
3.是否可以全用键盘操作，是否有快捷键
4.输入用户名，密码后按回车，是否可以登陆
5. 牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
兼容性测试
BS架构：不同浏览器测试，比如：IE，火狐，谷歌，360这些。
APP：在主流的不同类型，不同分辨率，不同操作系统的手机上测试，华为，vivo，oppo等
四.支付功能怎么测试？
1、从功能方面考虑：
1）、用户的使用场景：包括正常完成支付的流程；
支付中断后继续支付的流程；
支付中断后结束支付的流程；
单订单支付的流程；
多订单合并支付的流程；
余额不足；未绑定银行卡；密码错误；密码错误次数过多；找人代付；
弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：
包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：银行卡网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，
是否防止SQL注入，XSS攻击(跨站脚本攻击)。
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试 .
五.还款怎么测试？
功能上：
1.不同的还款方式：等额本息，等额本金还款，一次性还本付息。
2.逾期，提前还款和第三方还款。
3.不同账户的还款。
4.余额不足的还款，.
5.金额输入错误，不输入。
6.弱网状态下连续点击还款按钮或者系统不问题情况下，支付方未把支付结果返回给下单发起方。
从性能方面考虑：
还款的响应时间；
从安全性方面考虑：
是否防止SQL注入，XSS攻击(跨站脚本攻击)。
还款金额是否被拦截，还款密码等敏感信息是否加密。
从用户体验方面考虑
系统界面是否容易理解。
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
兼容性：
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试 .
《附》
支付流程：
用户发送下单请求-平台后台查看订单并制作支付请求后将请求传给第三方（银行）-银行将支付的信息反馈给客户，客户核对后输入支付密码--银行成功划账后将支付成功信息告知给平台后台和用户--平台确认支付信息反馈给第三方并发货.
退款流程：
用户提交退款申请给平台，平台后台通过审核后将退款信息告知给第三方（银行），第三方将钱退到用户绑定的银行账户中并告知平台处理结果。平台确认结果后并结束用户退款申请。
六.电梯如何测试？
需求测试：
查看电梯使用说明书、安全说明书等
界面测试：
查看电梯外观
功能测试：
1.测试电梯能否实现正常的上升和下降功能。
2.电梯的按钮是否都可以使用。
3.电梯门的打开，关闭是否正常。
4.报警装置是否可用。
5.与其他电梯之间是否协作良好。
6.通风状况如何。
7.突然停电时的情况。
8.上升途中的响应。
1）电梯本来在1楼，如果有人按18楼，那么电梯在上升到5楼的时候，有人按支付系统性能测试了10楼，这时候是否会在10楼先停下来；
2）电梯下降到10层时显示满员，此时若8层有人等待电梯，是否在8层停。
可靠性：
1.门关上的一刹那出现障碍物。
2.同时按关门和开门按钮。
3.点击当前楼层号码。
4.多次点击同一楼层的号码等等。
5.同时按上键和下键会怎样。
易用性：
1.电梯的按钮的设计符合一般人使用的习惯吗．
负载/压力测试：
1.看电梯的最大限度的承受重量．在负载过重时是否有提醒。
2.在一时间内不断的让电梯上升，下降。
稳定性测试：
1.最大负载下平稳运行的最长时间。
文档测试：
1.使用手册是否对电梯的用法、限制、使用条件等有详细描述.
性能测试的分类以及性能测试的指标
狭义：单用户测试广义：建立基准线，当系统软硬件环境发生变化之后再进行一次基准测试以确定变化对性能的影响。
1.概念：通过逐步增加系统负载，确定在满足性能指标的情况下，找出系统所能承受最大负载的测试。
作用：系统最大负载量达到用户要求时，系统才能正式上线。
注意：①通过负载测试，可以确定系统的最大负载量和极限负载量
②系统对外宣称的最大负载量
③负载测试的时间一般为1-2小时
1.概念：在服务器稳定运行（用户正常业务负载下）的情况进行长时间测试（1天-一周等），并最终保证服务器能满足线上业务需求。
2.系统在用户需求的业务负载下运行达到规定的时间时，系统才能正式上线使用。
1.概念：在强负载下的测试，查看系统在峰值下是否功能隐患、系统是否具有良好的容错能力和可恢复的能力。
2.测试场景：高负载下的长时间稳定性压力测试 （如：B-C区间内进行24/3*24小时长时间测试）极限负载下的破坏性压力测试（如：C-D区间内进行测试）
1.概念：在极短时间内，发送多个请求，来验证服务器对并发的处理能力。
2.应用场景：特定的活动场景：抢红包、秒杀、抢购等。
3.与负载测试对比：
负载测试：主要目的是测试高负载情况下，对系统资源的消耗，是否会耗尽的问题（双11活动）
并发测试：主要目的是测试极短时间内，并发请求时，系统资源争抢的问题（抢红包、秒杀）
1.指从客户端发起请求开始，到客户端接收到结果的总时间
2.包括：服务器处理时间 + 网络传输时间
某一时刻同时向服务器发送请求的用户数
1.概念：单位时间内处理客户端的请求数量，直接体现软件系统的承载能力。
2.吞吐量单位分类
QPS：每秒查询数，即控制度服务器每秒处理的指定请求数量。
TPS（Transaction Per Second）每秒事务数，即控制服务器每秒处理事务请求的数量。
如：支付请求事务=查询用户余额请求+校验支付安全请求+发送支付请求
每秒处理查询用户余额15请求，每秒处理校验支付安全15个请求，每秒处理发送支付15个请求
支付tsp为15
所有的页面元素（如：图片、链接、框架等）的请求总数 量
注意：点击数是请求数，不是页面上的一次点击
指系统在负载情况下，失败业务的概率
注意：
①.错误率是性能指标，是高负载下的失败业务的概率
②.随机bug是功能bug，先解决随机bug才能进行性能测试
1.概念：系统各种资源的使用情况，率=资源使用量/总资源可用量x100%
常见资源指标：
CPU使用率：不高于75%-85%
内存大小使用率：不高于80%
磁盘IO（速率）：不高于90%
网路（速率）：不高于80%
性能测试-概念篇（三）
通过分析业务逻辑和技术架构，创建性能模型，制定性能方案，准备应用环境，设计并实施性能部署监控，实现符合真实业务逻辑的压力，通过监控手段获取各组件的性能计数器，分析计数器采集出的数据，查找出性能瓶颈的根本原因并优化，最后通过环比生产环境的性能数据修正场景。
2.2.1、时间指标
2.2.2、容量指标
2.2.3、资源利用率指标
2.3.1、业务模型
2.3.2、监控模型
2.4.1、测试环境
2.4.2、测试数据
2.4.3、测试模型 - 基于业务模型构造测试数据
2.4.4、性能指标
2.4.5、压力测试-阶梯压力测试高并发压力测试
2.4.6、准入准出
2.4.7、进度风险
2.5.1、软硬件环境（包括压力机）
2.5.2、应用版本
2.5.3、基础设施
2.5.4、网络结构
2.5.5、基础数据
2.5.6、压力工具
2.6.1、系统监控
2.6.2、中间件监控
2.6.3、缓存监控
2.6.4、队列监控
2.6.5、负载均衡监控
2.6.6、熔断限流
2.6.7、链路监控
2.7.1、基准场景
2.7.2、容量场景
2.7.3、稳定性场景
2.7.4、异常场景
2.8.1、场景结果整理
2.8.2、监控结果整理
2.8.3、性能整体分析
2.8.4、性能结论
2.8.5、优化建议
2.8.6、运维建议
性能验证：验证系统是否达到指定的指标。 举例：RT是300ms,QPS/TPS是否可以达到800。
性能调优：验证是否达到系统的最大容量。 举例：限制或者不限制RT、内存水位、CPU水位，QPS/TPS可以达到多少。
容量验证：需要多少台机器。 举例：50 w UV,需要配置多少台机器。
1000万的用户，在场景A中，业务1占比10%，业务2占比20%，业务3占比30%；
1000万的用户，在场景B中，业务1占比20%，业务2占比30%，业务3占比40%；
1000万的用户，在场景C中，业务1占比30%，业务2占比40%，业务3占比50%。
包括接口响应时间+业务响应时间
参考：
互联网企业：500ms以下，例如淘宝业务10ms左右。
金融企业：1s以下为佳，部分复杂业务3s以下。
保险企业：3s以下为佳。
制造业：5s以下为佳。
包括接口容量+业务容量
如果是接口层性能测试，TPS中的T 可以直接定义为接口级；
如果业务级性能测试，TPS中的T 可以直接定义为每个业务步骤和完整的业务流；
举例：
start事务（接口1）
商品详情页接口A
end事务（接口1）
start事务（接口2）
商品详情页接口B
end事务（接口2）
start事务（业务A）
加入购物车（接口1）-下单（接口2）-支付（接口3）
end事务（业务A）
start事务（业务A）
点击-加入购物车（接口1）-下单（接口2）-支付（接口3）
end事务（业务A）
a、操作系统：CPU、Memory、Network、IO、System、Swap
b、JVM：GC、classes
...
对于长连接来说，最大并发用户数即系统的并发接入能力。实际上，就算是长连接，如果实际业务已经丢掉了异常的请求，那么最大并发用户数不等于系统的并发接入能力。
对于短连接来说，最大并发用户数并不等于系统的并发接入能力。
并发是在单位时间内完成的事务（T）的个数。
在线用户数和压力线程之间的关系：
从以上的计算逻辑中，我们可以看到，这其中有几个关键数据：
举例：
1) 在线用户数：1个用户，100个请求，响应时间是250s
用户数：1个
响应时间：250s
请求数：100
tps计算： 1*100/250=0.4（请求数/秒）
在线用户数（有停顿时间）：100000个用户，100个请求，响应时间是3600s
用户数：100000个
响应时间：3600s
请求数：100
tps计算：100000100/3600=2777.8 tps
2) 并发用户数（无停顿时间）：1个用户，100个请求，响应时间是6s
用户数：1个
响应时间：6s
请求数：100
tps计算：1*100/6=16.67 tps
3） 压力线程=(在线用户数×单用户请求数)/峰值采样时间段÷一个压力线程的请求级TPS
压力线程 = 2777.8（100000在线用户的请求级TPS）/16.67（1个压力线程的请求级TPS）=167
4） 并发用户数=在线用户数×有停顿时间的单线程TPS÷无停顿时间的单线程TPS
并发用户数 = 100000（在线用户数）*0.4（有停顿时间的单线程TPS）/16.67（无停顿时间的单线程TPS）=2399
5） 并发度=在线用户÷并发用户×100%（取值要在同一时间段）
并发度 = 100000/2399*100%=41.68%
参考：高楼老师的课程
关于支付系统性能测试和的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 支付系统性能测试的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于、支付系统性能测试的信息别忘了在本站进行查找喔。
相关文章
发表评论
暂时没有评论，来抢沙发吧~