交易(订单)类接口测试入门-1
接口测试进阶知识
接口测试进阶知识摘要：1.接口测试基础知识2.接口测试工具及技术3.接口测试的高级概念4.实践中的接口测试策略5.总结与展望正文：随着软件开发和测试的不断迭代，接口测试越来越受到关注。
本文将从五个方面介绍接口测试的进阶知识，帮助读者提升接口测试能力。
一、接口测试基础知识1.接口定义：接口是不同系统或模块之间进行交互的通道，通常包括输入和输出。
2.请求方法：HTTP请求方法有GET、POST、PUT、DELETE等，不同请求方法对应着不同的接口操作。
3.数据格式：接口测试中，常见的数据格式有JSON、XML等。
4.状态码：接口响应状态码表示接口处理的成功与否，常见的状态码有200（成功）、400（错误请求）、500（服务器内部错误）等。
二、接口测试工具及技术1.Postman：一款常用的接口测试工具，支持创建、调试、发送HTTP请求，并查看响应结果。
2.JMeter：Apache开源的性能测试工具，可用于测试接口的并发性能和压力测试。
3.自动化测试框架：如Selenium、PyTest等，可用于实现接口测试的自动化。
4.代码注入：利用代码注入技术，在测试过程中实时修改接口响应，提高测试覆盖率。
三、接口测试的高级概念1.接口契约测试：通过定义接口契约（如Swagger），实现对接口的规范管理和自动化测试。
2.微服务架构下的接口测试：针对微服务架构的特点，采用灰度测试、AB 测试等方法进行接口测试。
3.接口安全测试：检测接口是否存在安全漏洞，如SQL注入、跨站脚本攻击等。
四、实践中的接口测试策略1.制定测试计划：明确测试范围、测试目标、测试方法等。
2.创建测试用例：根据接口文档，编写正常场景和异常场景的测试用例。
3.执行测试：利用测试工具进行自动化测试，提高测试效率。
4.缺陷管理：对发现的问题进行跟踪、整改和验证。
5.持续集成与持续部署：将接口测试融入持续集成流程，确保代码质量。
五、总结与展望接口测试是软件开发过程中不可或缺的一环。
订单查询接口文档
1.1.订单状态查询[OM1]1.1.1.功能描述此接口用于根据订单号查询订单当前状态。
如果订单已经出票，则返回结果会包含票号。
1.1.2.接口地址Webservice方式：测试地址：:55779/ltips/services/getOrderStatusService1.0?wsdl正式地址：:8000/ltips/services/getOrderStatusService1.0?wsdlPost方式：测试地址：:55779/ltips/services/getOrderStatusServiceRestful1.0/getOrderStatus 正式地址：:8000/ltips/services/getOrderStatusServiceRestful1.0/getOrderStatus 1.1.3.方法名称getOrderStatus1.1.4.参数说明GetOrderStatusRequest(请求参数)GetOrderStatusReply(返回结果)1.2.订单取消[OM2]1.2.1.功能描述此接口用于通过订单号取消当前订单，且可同时取消PNR。
1.2.2.接口地址Webservice方式：测试地址：:55779/ltips/services/cancelOrderService1.0?wsdl 正式地址：:8000/ltips/services/cancelOrderService1.0?wsdlPost方式：测试地址：:55779/ltips/services/cancelOrderServiceRestful1.0/cancelOrder 正式地址：:8000/ltips/services/cancelOrderServiceRestful1.0/cancelOrder 1.2.3.方法名称cancelOrder1.2.4.参数说明CancelOrderRequest(请求参数)CancelOrderReply(返回结果)1.3.订单详情查询[OM3]1.3.1.功能描述此接口用于通过订单号查询订单详情。
API接口测试方法
API接口测试方法在软件开发中，API（应用程序编程接口）的测试是一个关键的环节，它确保了不同软件组件之间能够顺利地进行数据交换和功能调用。
本文将介绍几种常见的API接口测试方法，帮助开发者提高测试效率与准确性。
单元测试单元测试是针对API接口中的最小可测试部分进行验证的过程。
通过编写测试用例，可以检查单个函数或方法是否按照预期工作。
使用框架如JUnit、pytest等，可以自动化这些测试过程，快速发现和修复问题。
集成测试集成测试关注的是多个API接口之间的交互。
这种测试方法验证不同模块或服务组合在一起时的行为是否符合预期。
例如，一个订单处理系统可能需要集成产品目录、库存管理、支付网关等多个API。
端到端测试端到端测试（E2E测试）模拟真实用户操作场景，从用户界面开始，经过所有后端API，直到最终结果。
这要求测试环境尽可能地接近生产环境，以确保测试结果的有效性。
工具如Selenium、Cypress可用于自动化这一过程。
性能测试性能测试评估API在高负载或高并发条件下的表现。
这包括响应时间、吞吐量、资源利用率等指标。
使用工具如Apache JMeter、LoadRunner可以进行压力测试和负载测试。
安全测试安全性是API测试中不可忽视的方面。
安全测试旨在发现潜在的安全漏洞，如SQL注入、跨站脚本攻击（XSS）、身份验证和授权缺陷等。
OWASP ZAP、Burp Suite等工具可以帮助进行自动化的安全扫描。
回归测试每当API发生更改时，都需要进行回归测试，以确保新改动没有破坏现有功能。
自动化测试在这里发挥重要作用，它可以快速运行大量预先编写好的测试用例。
监控与日志分析在API投入生产后，持续的监控和日志分析对于维护其健康状态至关重要。
工具如Prometheus、ELK Stack（Elasticsearch, Logstash, Kibana）可以用来收集、存储和分析日志数据，及时发现并解决问题。
接口测试案例
接口测试案例接口测试是软件测试中的一个重要环节，通过对接口的测试可以验证系统各个模块之间的通信和数据传输是否正常，以保证系统的稳定性和可靠性。
下面我们将介绍一些接口测试案例，以便更好地理解接口测试的重要性和具体操作方法。
1. 接口协议测试。
在进行接口测试时，首先需要验证接口的协议是否符合标准规范，包括请求和响应的数据格式、传输协议、安全认证等方面。
通过构造不同的请求数据，测试接口是否能够正确解析和处理，并能够按照规定的协议返回相应的响应数据。
例如，针对RESTful接口，可以测试GET、POST、PUT、DELETE等不同的请求方法，验证接口是否能够正确响应。
2. 参数完整性测试。
接口通常会有各种参数，包括必填参数、可选参数、默认参数等。
在接口测试中，需要验证接口对各种参数的处理是否正确，包括参数的完整性、合法性、范围等。
例如，对于一个查询接口，可以测试不同的查询条件，验证接口是否能够正确返回符合条件的数据。
3. 异常情况测试。
在实际使用中，接口可能会出现各种异常情况，如网络超时、服务器错误、参数错误等。
接口测试需要针对这些异常情况进行测试，验证系统是否能够正确处理异常情况并给出合适的响应。
例如，可以模拟网络超时、服务器宕机等情况，验证系统的容错能力。
4. 并发性能测试。
接口在实际使用中可能会面临并发请求的情况，因此需要进行并发性能测试，验证接口在高并发情况下的稳定性和性能表现。
例如，可以通过压力测试工具模拟大量并发请求，观察系统的响应时间、吞吐量等指标。
5. 接口安全性测试。
接口中可能涉及用户身份认证、数据加密等安全机制，需要进行接口安全性测试，验证接口是否能够有效防范各种安全威胁。
例如，可以测试接口对于非法访问、SQL注入、跨站脚本攻击等安全漏洞的防护能力。
6. 接口集成测试。
在实际系统中，不同的模块之间会有各种接口交互，需要进行接口集成测试，验证各个模块之间的接口通信是否正常。
例如，可以测试订单模块与支付模块之间的接口交互，验证订单支付流程是否顺畅。
交易(订单)类接口测试入门-1
交易(订单)类接口测试总结--skyline一前言总结这几年测试接口的经验及方法，希望带给新人接口测试的思维，掌握基本的接口测试技术、方法或工具，能够独立完成接口测试用例设计及执行，接口测试用例覆盖率超过95%。
同时抛砖引玉，希望能带动测试大佬们分享更多精彩的干货总结。
最后，才学所限难免有所纰漏，如有不正之处，恳请指正。
相互学习，共同进步。
二概述所有的接口测试，逃不出一个模式：请求及响应。
如文件接口、数据流接口等等，那么接口测试的基本内容就是对接口的入参及出参进行验证。
针对接口实现不同的功能，则采取不同的测试方法，侧重点也有所不同。
本文主要针对交易（订单）类接口，此类接口的特点是资金流及信息流的一致性，对处理速度及响应时间要求高，需要具备全链路测试思维。
交易业务及功能复杂，需要深度掌握支付业务及用户体验，才能设计出优秀的接口测试用例。
所以，希望大家记住接口测试的要求，努力提高自己的测试水平。
三正文交易接口测试具体内容包括：1.入参、出参字段测试2.业务功能测试3.系统功能测试4.非功能性测试以上，将分章节详细介绍。
3.1 入参及出参字段测试入参测试的目的是为了验证入参字段的有效性，入参字段的数据类型、条件域、字段功能及要求校验通过，满足需求的规定，具备业务合理性。
入参字段的数据类型一般包括Int、String（128）、Boolean，采用等价类划分有效等价类及无效等价类，基本操作而已。
在但罗列取值时，有几个特殊值要特别说明。
0或者0.00、空值或者空格，极小值0.01及极大值999999999等。
举例，金额字段是整型，整型包含了0。
但交易金额为0，从业务上不合理，所以需要被拦截。
空值或者空格，需要过滤，一般不允许通过。
极小值和极大值，主要是看数据在边界处的处理是否正常。
极大值也要考虑业务的合理性。
一笔交易几十个亿显示是不合理的。
条件域，入参及出参的四种类型：M、C、O、R。
如图：M：表示该字段必填。
订单状态测试用例
订单状态测试用例概述订单状态是指在购物过程中，订单所处的不同阶段或状态。
对于一个电商平台来说，订单状态的正确性和可靠性非常重要，它直接关系到用户购物体验的好坏和交易流程的顺畅与否。
因此，为了确保订单状态的准确性和稳定性，需要进行订单状态测试。
本文将从订单状态的定义、测试目标、测试策略、测试用例设计、执行与管理等方面进行详细介绍，以帮助测试人员全面了解和掌握订单状态测试。
定义订单状态是指在电商平台上用户购买商品后，从下单到交付之间经历的一系列阶段或状态。
常见的订单状态包括待支付、待发货、已发货、已签收等。
测试目标1.验证订单状态在不同操作下是否正确变更。
2.验证订单状态变更是否及时。
3.验证订单各个环节之间是否协调一致。
4.验证系统能够正确处理异常情况下的订单状态变更。
测试策略1.根据业务流程确定主要测试点：根据电商平台的业务流程，确定主要涉及到订单状态变更的环节和操作，并将其作为主要测试点。
2.划分测试阶段：将订单状态测试分为下单前、下单后、交付前和交付后四个阶段进行测试，以确保订单状态在不同阶段的正确性。
3.设计典型用例：根据主要测试点和业务流程，设计一系列典型的测试用例，覆盖各种常见和异常情况。
4.结合其他功能测试：订单状态变更通常涉及到其他功能模块（如支付、库存管理等），需结合其他功能测试进行综合验证。
测试用例设计下单前1.未登录用户无法下单：–输入商品信息，点击购买按钮。
–预期结果：系统提示“请先登录”。
2.已登录用户可以正常下单：–登录账号，输入商品信息，点击购买按钮。
–预期结果：订单状态变为“待支付”。
下单后1.支付成功后订单状态变更：–下单并支付成功。
–预期结果：订单状态变为“待发货”。
2.取消订单后订单状态变更：–下单后取消订单。
–预期结果：订单状态变为“已取消”。
交付前1.发货成功后订单状态变更：–确保有待发货的订单。
–点击发货按钮。
–预期结果：订单状态变为“已发货”。
2.退款成功后订单状态变更：–确保有已发货的订单。
接口测试知识点
接口测试知识点一、知识概述《接口测试知识点》①基本定义：接口测试嘛，简单说就是测试系统之间交互的接口，就像查两个小伙伴之间的传话筒能不能好好工作那样。
接口就是不同软件组件或者系统之间沟通的桥梁，我们要看看这个桥梁在数据传递、功能调用等方面有没有问题。
②重要程度：在软件测试里它可很重要哦。
就像一个大厦，接口就是连接各个房间（不同模块）的通道，通道要是出问题，那大厦可就乱套了。
它能比只测单个功能更早地发现问题，在系统集成之前就把潜藏的风险挖出来。
③前置知识：先得对软件开发的基础流程有了解，像什么需求分析、设计、开发的基本概念。
而且对于HTTP这些常见协议也要有点儿概念，因为很多接口都是基于HTTP协议工作的。
④应用价值：实际中很多软件都不是一个整体动起来的，都是不同部分组合起来的。
比如电商系统，库存系统、订单系统、支付系统之间要有接口互通。
接口测试好了，能保证这些系统对接顺畅，避免数据错误、功能缺失、性能低下等问题。
二、知识体系①知识图谱：在软件测试学科里，接口测试和单元测试、集成测试都有关系。
单元测试像是检查细胞（独立的功能模块）健康不健康，接口测试就在单元测试和集成测试之间，确保细胞之间传递信息的时候没有错。
然后集成测试就像把各个健康的器官（集成好的多个模块）组合起来看整个身体（完整系统）能不能工作。
②关联知识：和协议知识关联很大，像HTTP或者RPC协议等。
还和数据库知识有关联，因为接口有时候需要操作数据库。
也跟自动化测试知识有关，很多接口测试现在都自动化了。
③重难点分析：- 掌握难度：有点难哦。
要理解接口文档就不容易，那里面有各种字段的定义、接口的调用规则。
而且还得处理各种数据格式，像JSON 和XML。
- 关键点：关键就是要把接口文档读明白喽。
还有处理好接口之间的依赖关系。
④考点分析：- 在考试中的重要性：如果是软件测试相关的考试，这是挺重要的一部分。
能考查你对系统交互理解和测试的能力。
- 考查方式：可能会让你根据一个接口文档写测试用例，或者给出一个接口出错的情况让你分析原因。
接口测试基础
接口测试基础接口测试基础是软件测试中非常重要的一个领域，它主要负责对软件的接口进行测试，通过检查接口的输入输出和相应的状态码，来保证软件的可靠性和稳定性。
那么，我们该如何进行接口测试呢？下面我就为大家简单介绍一下接口测试的基础步骤：第一步，了解接口的基础信息。
在进行接口测试之前，我们需要先了解被测系统的接口信息，包括接口的协议类型、地址、请求方法、参数、返回值等等。
这些基础信息可以通过查看接口文档或者与开发人员沟通来获得。
第二步，准备测试环境。
接下来，我们需要准备相应的测试环境，包括搭建被测系统，安装接口测试工具，设置测试数据等等。
同时，也需要保证测试环境的稳定性和可靠性，以避免测试数据被污染或者丢失。
第三步，编写测试用例。
接下来，我们需要根据接口的参数和返回值，编写相应的测试用例。
测试用例应该覆盖所有的输入参数组合和预期结果，以保证接口的完整性和准确性。
第四步，执行测试用例。
接下来，我们需要执行测试用例，并记录测试结果。
在执行测试用例的过程中，需要注意接口的相应时间、返回值的正确性、错误处理等等。
第五步，对测试结果进行分析。
最后，我们需要对测试结果进行分析，提取有用的信息，识别潜在的问题，并将测试报告提交给相关部门。
如果发现了问题，我们需要及时与开发人员进行沟通，并跟踪问题的解决过程。
以上就是接口测试的基础步骤。
需要注意的是，接口测试需要仔细地分析接口的返回结果和状态码，并与开发人员进行沟通，以确保测试过程中的准确性和完整性。
同时，也需要对测试结果进行分析和总结，以识别潜在的问题，并提供有关改进的建议。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
交易(订单)类接口测试总结--skyline一前言总结这几年测试接口的经验及方法，希望带给新人接口测试的思维，掌握基本的接口测试技术、方法或工具，能够独立完成接口测试用例设计及执行，接口测试用例覆盖率超过95%。
同时抛砖引玉，希望能带动测试大佬们分享更多精彩的干货总结。
最后，才学所限难免有所纰漏，如有不正之处，恳请指正。
相互学习，共同进步。
二概述所有的接口测试，逃不出一个模式：请求及响应。
如文件接口、数据流接口等等，那么接口测试的基本内容就是对接口的入参及出参进行验证。
针对接口实现不同的功能，则采取不同的测试方法，侧重点也有所不同。
本文主要针对交易（订单）类接口，此类接口的特点是资金流及信息流的一致性，对处理速度及响应时间要求高，需要具备全链路测试思维。
交易业务及功能复杂，需要深度掌握支付业务及用户体验，才能设计出优秀的接口测试用例。
所以，希望大家记住接口测试的要求，努力提高自己的测试水平。
三正文交易接口测试具体内容包括：1.入参、出参字段测试2.业务功能测试3.系统功能测试4.非功能性测试以上，将分章节详细介绍。
3.1 入参及出参字段测试入参测试的目的是为了验证入参字段的有效性，入参字段的数据类型、条件域、字段功能及要求校验通过，满足需求的规定，具备业务合理性。
入参字段的数据类型一般包括Int、String（128）、Boolean，采用等价类划分有效等价类及无效等价类，基本操作而已。
在但罗列取值时，有几个特殊值要特别说明。
0或者0.00、空值或者空格，极小值0.01及极大值999999999等。
举例，金额字段是整型，整型包含了0。
但交易金额为0，从业务上不合理，所以需要被拦截。
空值或者空格，需要过滤，一般不允许通过。
极小值和极大值，主要是看数据在边界处的处理是否正常。
极大值也要考虑业务的合理性。
一笔交易几十个亿显示是不合理的。
条件域，入参及出参的四种类型：M、C、O、R。
如图：M：表示该字段必填。
则测试场景为必填、空、空格、不上送字段即入参中少一个参数，失败。
C：表示满足条件必填。
第一，梳理必填的场景，然后同M验证。
第二，不满足的情况下，不填。
则验证场景为：任意填写（有效、无效）、空、空格、不上送字段，成功。
同下面O字段验证。
O：非必输项。
则验证场景为：任意填写（有效、无效）、空、空格、不上送字段，成功。
出参中类型未O，则表示入参如果填写，则有值。
如果不填写，则无。
R：原样返回域。
仅针对出参，响应数据中个某个字段的取值与入参中的一致，即原样返回起始值。
字段功能，分为显现需求及隐形需求。
如上图，trans_id字段，备注中直接详细描写了字段长度、不可重复条件、有效期等，这些是作为字段功能，必须要充分涉及场景进行测试，验证符合要求。
难点在字段功能的隐藏需求中。
还以trans_id为例子说明，备注中说同一天内不可重复，太过简单，仅仅测试成功订单不可重复就行了吗？实际上这句话背后，隐藏了一些潜在需求没有描述。
即除了成功订单外，不成功的订单怎么处理？这里需求没有说明，需要我们根据业务及实际应用场景合理性进行推断。
第一，失败的订单余额不足，换卡支付，这个时候订单号实际上没变的，所以失败的订单状态可以重复，减少了用户请求次数，比较合理的。
第二、处理中订单，因为渠道未返回真实支付结果，所以也不能重复。
再举一个例子，接口文档中卡类型一般只会列举借记卡、贷记卡，但你要知道还有准贷记卡这个类型。
通过上面的例子，在设计用例的过程中，明显的需求要覆盖，而隐藏的需求作为必要的补充，才能设计出覆盖度足够高的用例。
另外，再次说明，对于出参验证，根据需求文档的规定，需覆盖到响应内容中的全部字段，并且校验字段的响应值是否正确。
对于有多个值的字段，必须覆盖每一个取值。
比如order_stat字段：I、S、F。
分别表示处理中、成功、失败。
则测试的时候不能只验证成功、失败，处理中的订单也必须验证。
3.2 业务功能测试业务功能测试，主要依据需求文档进行。
支付业务的基本业务功能可以概括为：绑卡、绑卡查询、交易、交易查询、异步通知等。
这里与其他类型的业务功能测试方法、技术都是通用的，不在赘述。
结合支付业务，强调一下。
在做支付类接口的业务功能测试时，需要具备的几个思维。
第一，全链路测试思维。
从前置交易的受理，到网关对订单的业务校验，发往渠道及对渠道返回结果的处理，之后通知清算及会员完成记账，最后同步返回商户结果及异步通知。
还包括商户前台的订单查询或者运营后台的订单查询等等，这是一条全链路的交易过程，一个完整的业务流程。
测试某类接口，不管改动的地方是在前置、网关、或者底层清算是，不要只局限在这一个节点，要全链路结合测试，关注当前节点及上下游节点的正确性。
第二，信息流与资金流一致性。
信息流可以理解成数据流，一个请求接口，绑卡或者交易，必然生产一笔订单，或者MQ消息等。
那么请求完成后，需要找到对应的表，查询订单及关联表落库字段与请求数据是否一致，查询MQ消息是否正确等等，相关字段是否符合业务需求。
资金流则是资金的变动情况，代收或者代付，一进一出，分录及账户余额变动是否正确。
然后才是更重要的，验证信息流与资金流的一致性。
代收是先数据流，在资金流。
代付是先资金流，在数据流，在资金流。
所以存在相互前、后的对应关系。
比如，成功的订单对应正确的资金增减。
失败的订单无资金变动。
处理中的订单，有明确结果了在进行资金的操作。
特别的对于代付，处理中的订单资金被冻结，有一个解冻或者对冲的过程。
不一致的后果是，失败的订单操作了资金，成功的订单不操作资金。
后果多严重，可曾懂得？？？？第三，绝对要避开任何短款与长款风险。
通俗一点的解释，短款是代收时渠道处理失败，但返回宝付成功并且给商户加钱，宝付产生资损。
或者代付成功的订单渠道返回失败，宝付没有扣商户的钱，宝付产生资损。
长款是反向理解。
为了避免这种短款或者长款的生产，交易的时候进行了严格的控制。
包括商户订单号、宝付订单号、业务流水号等的幂等性验证。
也包括了对订单状态改变的严格控制。
所以幂等性、订单状态及金额、清算状态及金额等是业务测试的重中之重。
第四，日志的合理利用。
日志的作用之一，用来确认系统业务处理的是否正确。
系统与系统之间的传参是否正确。
接口不仅是黑盒测试，对系统内部的运行，同样要了如指掌才能做好高级测试。
日志的另一个作用是确保没有异常日志的产生。
在回归测试或者新业务的时候，有些报错不会体现在响应结果中。
举例，限额获取异常，但订单返回仍然成功。
这个时候，通过观察异常日志才能发现错过。
我们要想尽一切办法，确认系统的稳定可靠。
第五，业务流程与业务功能分开。
流程与功能验证多有重叠，但也侧重点也有不同。
所以最好分开。
从业务功能中，梳理出主要的基本的业务流程，作为最基本的测试，方便以后自动化。
针对每个单独的功能点，梳理出足够的验证点。
比如一个大功能可能包含了100个小得验证点。
等验证通过了所有功能的时候，基于功能之上的因果关系，前后联系，如一个修改流程就包括了新增、查询、修改等几个操作，多个功能的组合形成了基本的测试流及复杂的分支流程。
流程关乎业务，业务才是重点，追求100%的覆盖。
对功能的验证点，要考虑周全，但没必要100%的覆盖。
比如有些功能有缺陷但是小缺陷，不影响整体业务流程，可以适当放宽。
3.3 系统功能测试系统功能是隐藏的需求，一般产品需求说明书不会提及。
需要系统的概要设计、详细设计文档，我这里只总结了一些关键的系统功能，肯定没有全部覆盖。
要想了解全面，需要文档及代码相结合，进行梳理与归纳。
如图，支付网关系统的一个大概架构图，从架构图可以大概了解系统的核心功能：第一，路由功能。
路由分为验卡及支付路由两大类。
验卡路由功能涉及到循环验卡。
即第一次验卡失败，自动切换到下一个渠道继续验证。
支付路由则是二次支付，对于一些支付时返回特定的错误码，自动选择备用路由。
上述，都是为了提高订单成功率。
第二，补单功能。
渠道掉单后，有两种补单方式。
自动补单与手动补单。
自动补单通过系统的自动查询接口，重复查询，直到获取订单终态。
手动补单，则可以通过ad、bm。
单条或者批量补单。
补单结果需要覆盖补单返回成功、补单返回失败的场景。
第三，风控及限额功能。
风控及限额，关乎资金安全，是最基本的验证点之一。
风控一般包括黑白名单，限额则分为单笔限额、产品限额、渠道限额。
其中渠道限额取所有渠道能力中最小值min。
然后三个额度取最大max，作为产品的的最终额度。
因此要进行边界值测试。
第四，异步通知通能。
异步通知包括支付成功通知及分账成功通知等。
针对不同的异步通知，需要验证订单在成功、失败、处理中时的通知内容及格式是否正确、符合要求。
一般自动异步通知，补单功能，也会触发异步通知。
第五，解约功能。
解约是针对签约而言。
签约分为商户与宝付之间的签约，及宝付与银行或者平台的签约，往往涉及多方。
商户发起的解绑，仅仅是解除了最外层的与宝付的绑定，而宝付与银行等则需要宝付自己发起，才会解除。
因此，针对某些产品，验证完成签约后，必须验证解约流程是否完善。
这也是全链路测试思维的提现。
第六，基本功能校验。
如商户及状态，产品及状态、功能及状态、终端及状态等等第七，缓存测试。
缓存测试包括验卡缓存及交易订单缓存测试。
在设计用例的时候，要特别注意。
如验证验卡缓存，可以设计验卡成功，重复验卡。
验卡失败，重复验卡，来验证缓存数据是否正确。
支付时，则通相同订单号重复支付或者超时支付等场景，验证缓存的有效性。
验证缓存时需要结合日志等观察，缓存数据的是否正确。
第八，MQ等中间件测试。
像支付完成发清算、发异步通知等等，都是通过MQ缓存转异步处理。
MQ第一个需要关注MQ的数据是否正确。
其次，要关注MQ队列消费是否正常速度消费。
以上，列举了八个重要的系统功能点，在新业务测试时必须全盘考虑这些隐藏的需求或者功能点，不能有遗漏。
除此之外，还包括了其他很多待发掘的功能，需要通过来了解设计文档、走读代码来梳理。
3.4非功能性测试非功能性测试主要指标是接口并发及响应时间，在一个合理范围。
另外，针对某些特殊接口，需要考虑带宽占比。
比如查询接口的并发数、响应时间等等，还比如批量代扣一次上传5000笔订单，需要考虑带宽是否有压力。
甚至，一些幂等性校验功能，需要并发测试压一压，确保高并发下功能正常。
四总结以上的经验梳理及总结，带大家入门基本的接口测试。
特别是支付业务线的新人，能够转变测试思维，获得相关启发，设计出优秀的测试覆盖度高的测试用例。
最基本的，要有一定的产品思维、全链路测试思维、资金风险思维等。
具备相关思维的同时，不断的完善业务知识体系，掌握支付相关、行业相关的知识。
最后给大家介绍三个学习方法。
第一，多问多思。
第二，即时总结，第三，向优秀的人学习！五附录常见字段验证注意点罗列如下：1.身份证字段验证，需要注意的特殊点：15位身份证长度；末尾包含X，需要验证大小写2.卡号字段验证：卡类型覆盖：借记卡、贷记卡、准贷记卡3.姓名验证：少数民族的姓名包含特殊字符·4.短信验证码字段：时效性验证，如超过30分钟验证码失效；及错误次数控制：5次错误验证码失效等5.订单状态：除了常见的成功、失败、处理中，还包括：未支付、支付超时等状态。