交易(订单)类接口测试入门-1.docx

交易(订单)类接口测试总结--skyline一 前言总结这几年测试接口的经验及方法，希望带给新人接口测试的思维，掌握基本的接口测试技术、方法或工具，能够独立完成接口测试用例设计及执行，接口测试用例覆盖率超过95%同时抛砖引玉，希望能带动测试大佬们分享更多精彩的干货总结最后，才学所限难免有所纰漏，如有不正之处，恳请指正相互学习，共同进步二 概述所有的接口测试，逃不出一个模式：请求及响应如文件接口、数据流接口等等，那么接口测试的基本内容就是对接口的入参及出参进行验证针对接口实现不同的功能，则采取不同的测试方法，侧重点也有所不同本文主要针对交易（订单）类接口，此类接口的特点是资金流及信息流的一致性，对处理速度及响应时间要求高，需要具备全链路测试思维交易业务及功能复杂，需要深度掌握支付业务及用户体验，才能设计出优秀的接口测试用例所以，希望大家记住接口测试的要求，努力提高自己的测试水平授课：XXX三 正文交易接口测试具体内容包括：1. 入参、出参字段测试2. 业务功能测试3. 系统功能测试4. 非功能性测试以上，将分章节详细介绍3.1 入参及出参字段测试入参测试的目的是为了验证入参字段的有效性，入参字段的数据类型、条件域、字段功能及要求校验通过，满足需求的规定，具备业务合理性。

入参字段的数据类型一般包括Int、String（128）、Boolean，采用等价类划分有效等价类及无效等价类，基本操作而已在但罗列取值时，有几个特殊值要特别说明0或者0.00、空值或者空格，极小值0.01及极大值999999999等举例，金额字段是整型，整型包含了0但交易金额为0，从业务上不合理，所以需要被拦截空值或者空格，需要过滤，一般不允许通过极小值和极大值，主要是看数据在边界处的处理是否正常极大值也要考虑业务的合理性一笔交易几十个亿显示是不合理的授课：XXX条件域，入参及出参的四种类型：M、C、O、R如图：M：表示该字段必填则测试场景为必填、空、空格、不上送字段即入参中少一个参数，失败C：表示满足条件必填第一，梳理必填的场景，然后同M验证第二，不满足的情况下，不填则验证场景为：任意填写（有效、无效）、空、空格、不上送字段，成功同下面O字段验证O：非必输项则验证场景为：任意填写（有效、无效）、空、空格、不上送字段，成功出参中类型未O，则表示入参如果填写，则有值如果不填写，则无R：原样返回域仅针对出参，响应数据中个某个字段的取值与入参中的一致，即原样返回起始值授课：XXX字段功能，分为显现需求及隐形需求。

如上图，trans_id字段，备注中直接详细描写了字段长度、不可重复条件、有效期等，这些是作为字段功能，必须要充分涉及场景进行测试，验证符合要求难点在字段功能的隐藏需求中还以trans_id为例子说明，备注中说同一天内不可重复，太过简单，仅仅测试成功订单不可重复就行了吗？实际上这句话背后，隐藏了一些潜在需求没有描述即除了成功订单外，不成功的订单怎么处理？这里需求没有说明，需要我们根据业务及实际应用场景合理性进行推断第一，失败的订单余额不足，换卡支付，这个时候订单号实际上没变的，所以失败的订单状态可以重复，减少了用户请求次数，比较合理的第二、处理中订单，因为渠道未返回真实支付结果，所以也不能重复再举一个例子，接口文档中卡类型一般只会列举借记卡、贷记卡，但你要知道还有准贷记卡这个类型通过上面的例子，在设计用例的过程中，明显的需求要覆盖，而隐藏的需求作为必要的补充，才能设计出覆盖度足够高的用例另外，再次说明，对于出参验证，根据需求文档的规定，需覆盖到响应内容中的全部字段，并且校验字段的响应值是否正确对于有多个值的字段，必须覆盖每一个取值比如order_stat字段：I、S、F分别表示处理中、成功、失败。

则测试的时候不能只验证成功、失败，处理中的订单也必须验证授课：XXX3.2 业务功能测试业务功能测试，主要依据需求文档进行支付业务的基本业务功能可以概括为：绑卡、绑卡查询、交易、交易查询、异步通知等这里与其他类型的业务功能测试方法、技术都是通用的，不在赘述结合支付业务，强调一下在做支付类接口的业务功能测试时，需要具备的几个思维第一， 全链路测试思维从前置交易的受理，到网关对订单的业务校验，发往渠道及对渠道返回结果的处理，之后通知清算及会员完成记账，最后同步返回商户结果及异步通知还包括商户前台的订单查询或者运营后台的订单查询等等，这是一条全链路的交易过程，一个完整的业务流程测试某类接口，不管改动的地方是在前置、网关、或者底层清算是，不要只局限在这一个节点，要全链路结合测试，关注当前节点及上下游节点的正确性第二， 信息流与资金流一致性信息流可以理解成数据流，一个请求接口，绑卡或者交易，必然生产一笔订单，或者MQ消息等那么请求完成后，需要找到对应的表，查询订单及关联表落库字段与请求数据是否一致，查询MQ消息是否正确等等，相关字段是否符合业务需求资金流则是资金的变动情况，代收或者代付，一进一出，分录及账户余额变动是否正确。

然后才是更重要的，验证信息流与资金流的一致性代收是先数据流，在资金流代付是先资金流，在数据流，在资金流所以存在相互前、后的对应关系比如，成功的订单对应正确的资金增减失败的订单无资金变动处理中的订单，有明确结果了在进行资金的操作特别的对于代付，处理中的订单资金被冻结，有一个解冻或者对冲的过程授课：XXX不一致的后果是，失败的订单操作了资金，成功的订单不操作资金后果多严重，可曾懂得？？？？第三， 绝对要避开任何短款与长款风险通俗一点的解释，短款是代收时渠道处理失败，但返回宝付成功并且给商户加钱，宝付产生资损或者代付成功的订单渠道返回失败，宝付没有扣商户的钱，宝付产生资损长款是反向理解为了避免这种短款或者长款的生产，交易的时候进行了严格的控制包括商户订单号、宝付订单号、业务流水号等的幂等性验证也包括了对订单状态改变的严格控制所以幂等性、订单状态及金额、清算状态及金额等是业务测试的重中之重第四， 日志的合理利用日志的作用之一，用来确认系统业务处理的是否正确系统与系统之间的传参是否正确接口不仅是黑盒测试，对系统内部的运行，同样要了如指掌才能做好高级测试日志的另一个作用是确保没有异常日志的产生在回归测试或者新业务的时候，有些报错不会体现在响应结果中。

举例，限额获取异常，但订单返回仍然成功这个时候，通过观察异常日志才能发现错过我们要想尽一切办法，确认系统的稳定可靠授课：XXX第五， 业务流程与业务功能分开流程与功能验证多有重叠，但也侧重点也有不同所以最好分开从业务功能中，梳理出主要的基本的业务流程，作为最基本的测试，方便以后自动化针对每个单独的功能点，梳理出足够的验证点比如一个大功能可能包含了100个小得验证点等验证通过了所有功能的时候，基于功能之上的因果关系，前后联系，如一个修改流程就包括了新增、查询、修改等几个操作，多个功能的组合形成了基本的测试流及复杂的分支流程流程关乎业务，业务才是重点，追求100%的覆盖对功能的验证点，要考虑周全，但没必要100%的覆盖比如有些功能有缺陷但是小缺陷，不影响整体业务流程，可以适当放宽3.3 系统功能测试系统功能是隐藏的需求，一般产品需求说明书不会提及需要系统的概要设计、详细设计文档，我这里只总结了一些关键的系统功能，肯定没有全部覆盖要想了解全面，需要文档及代码相结合，进行梳理与归纳如图，支付网关系统的一个大概架构图，从架构图可以大概了解系统的核心功能：授课：XXX第一， 路由功能路由分为验卡及支付路由两大类。

验卡路由功能涉及到循环验卡即第一次验卡失败，自动切换到下一个渠道继续验证支付路由则是二次支付，对于一些支付时返回特定的错误码，自动选择备用路由上述，都是为了提高订单成功率第二， 补单功能渠道掉单后，有两种补单方式自动补单与手动补单自动补单通过系统的自动查询接口，重复查询，直到获取订单终态手动补单，则可以通过ad、bm单条或者批量补单补单结果需要覆盖补单返回成功、补单返回失败的场景第三， 风控及限额功能风控及限额，关乎资金安全，是最基本的验证点之一风控一般包括黑白名单，限额则分为单笔限额、产品限额、渠道限额其中渠道限额取所有渠道能力中最小值min然后三个额度取最大max，作为产品的的最终额度因此要进行边界值测试授课：XXX第四， 异步通知通能异步通知包括支付成功通知及分账成功通知等针对不同的异步通知，需要验证订单在成功、失败、处理中时的通知内容及格式是否正确、符合要求一般自动异步通知，补单功能，也会触发异步通知第五， 解约功能解约是针对签约而言签约分为商户与宝付之间的签约，及宝付与银行或者平台的签约，往往涉及多方商户发起的解绑，仅仅是解除了最外层的与宝付的绑定，而宝付与银行等则需要宝付自己发起，才会解除。

因此，针对某些产品，验证完成签约后，必须验证解约流程是否完善这也是全链路测试思维的提现第六， 基本功能校验如商户及状态，产品及状态、功能及状态、终端及状态等等第七， 缓存测试缓存测试包括验卡缓存及交易订单缓存测试在设计用例的时候，要特别注意如验证验卡缓存，可以设计验卡成功，重复验卡验卡失败，重复验卡，来验证缓存数据是否正确支付时，则通相同订单号重复支付或者超时支付等场景，验证缓存的有效性验证缓存时需要结合日志等观察，缓存数据的是否正确授课：XXX第八， MQ等中间件测试像支付完成发清算、发异步通知等等，都是通过MQ缓存转异步处理MQ第一个需要关注MQ的数据是否正确其次，要关注MQ队列消费是否正常速度消费 以上，列举了八个重要的系统功能点，在新业务测试时必须全盘考虑这些隐藏的需求或者功能点，不能有遗漏除此之外，还包括了其他很多待发掘的功能，需要通过来了解设计文档、走读代码来梳理3.4非功能性测试非功能性测试主要指标是接口并发及响应时间，在一个合理范围另外，针对某些特殊接口，需要考虑带宽占比比如查询接口的并发数、响应时间等等，还比如批量代扣一次上传5000笔订单，需要考虑带宽是否有压力甚至，一些幂等性校验功能，需要并发测试压一压，确保高并发下功能正常。

四 总结以上的经验梳理及总结，带大家入门基本的接口测试特别是支付业务线的新人，能够转变测试思维，获得相关启发，设计出优秀的测试覆盖度高的测试用例最基本的，要有一定的产品思维、全链路测试思维、资金风险思维等具备相关思维的同时，不断的完善业务知识体系，掌握支付相关、行业相关的知识最后给大家介绍三授课：XXX个学习方法第一，多问多思第二，即时总结，第三，向优秀的人学习！五 附录常见字段验证注意点罗列如下：1. 身份证字段验证，需要注意的特殊点：15位身份证长度；末尾包含X，需要验证大小写2. 卡号字段验证：卡类型覆盖：借记卡、贷记卡、准贷记卡3. 姓名验证：少数民族的姓名包含特殊字符 ·4. 短信验证码字段：时效性验证，如超过30分钟验证码失效；及错误次数控制：5次错误验证码失效等5. 订单状态：除了常见的成功、失败、处理中，还包括：未支付、支付超时等状态其中成功、超时订单是终态，其他是中间态中间态最终要变成终态6. 金额字段：负数、0、小数等需要特别注意，极大和极小值需要覆盖7. 商户订单号字段：验证重复时，需要对成功、失败、处理中的订单分别验证；关联订单号验证时效性授课：XXX8. 订单查询：需要验证初始状态、中间态、中间态转终态。