交易(订单)类接口测试入门-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：表示该字段必填。则测试场景为必填、空、空格、不上送字段即入参中少一个参数，失败。

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.订单状态：除了常见的成功、失败、处理中，还包括：未支付、支付超时等状态。其中成功、超时订单是终态，其他是中间态。中间态最终要变成终态。

6.金额字段：负数、0、小数等需要特别注意，极大和极小值需要覆盖

7.商户订单号字段：验证重复时，需要对成功、失败、处理中的订单分别验证；关联订单号验证时效性

8.订单查询：需要验证初始状态、中间态、中间态转终态、终态的查询，都确保查询状态正确

9.异步通知，需要特别关注订单状态、金额等字段，验证成功、失败、处理中的异步通知内容及格式正确

10.补单功能，新业务需要验证补单功能是否正常。包括自动补单、手动补单等，并且要关注补单成功后的异步通知内容是否正常