接口验证模式

摘要：接口验证是软件测试中一个重要的方面。本文按被测对象与周边实体的消息处理关系将接口验证方式抽象成几种模式：C模式、S模式、C S模式、分发模式、异步模式等。然后按模式从接口契约定义、请求和响应配合等方面，给出接口验证的一般要求。

关键词：接口验证 测试模式 协议一致性

1、相关概念

1.1 接口

这里所说的接口主要是指的是消息接口，是二个部件之间的通信契约，有发送方、接收方等方面的属性，同GUI接口、文件接口一样，它本质上属于一种输入、 输出方式，只是它涉及到2个不同部件/实体，有请求/响应、有连接通道要求，由此带来超时、重发、重连等方面的一系列要求。

1.2 接口、流程、处理的关系

一个流程由一系列的处理、接口调用组成。

一个流程可能涉及多个不同部件，涉及多个不同的接口调用。

一个接口可能服务于多个流程，多个流程共用同一个接口。由此，接口验证里需要对同一个接口遍历不同的流程调用场景。

接口作为数据的一种形式，它影响流程的走向。

接口作为数据的一种形式，它影响流程的结果。

有些接口处理可能是纯接口的、只做中转、协议转换等。例：下面例子中的E部件接口；有些接口处理可能有较强的功能逻辑，根据需要可能还会进一步细化成内部接口。由此，接口验证可能需要针对接口处理作进一步的功能逻辑验证。

2、一个例子

以下为某个处理的简化流程。P部件发出请求，E部件协议转换后转发给M部件，M部件进业务逻辑处理后返回响应给E部件。

接口的测试设计思路：

● 列出与每个部件的交互点。 包括：与P 部件的交互点1.1~1.2；与E 部件的交互点2.1~2.4；与M部件的交互点3.1~3.2

● 对每个部件的每个交互点进行正常与异常方面的验证。

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿 

3、接口验证模式

3.1 基本模式

● C模式：被测对象作为客户端发送请求消息。一般来说，流程起点的接口（例子中的P部件接口）多数为C模式。

基本验证要求：

◇ 发送请求消息正确性。包括：协议、消息格式、各参数验证。

◇ 响应消息字段、错误码遍历。确认根据对端不同响应作了相应的正确处理。比如：根据错误码展示

正确的错误提示也为一种正确处理方式。

进一步验证要求：

◇ 考虑接口请求和响应配合上的异常，包括：

——请求发送异常：发送失败、失败重发。

——响应接受异常：无响应、响应超时、超时重发、收到重复请求 ● S 模式：被测对象作为服务端接收请求，一般来说，流程终点的接口（例子中的M 部件）多数为S模式。

基本验证要求：

◇ 收到的请求消息参数合法性校验。包括：

——协议、消息格式的验证、非系统识别消息、存在非法字段、收到重复消息

——遍历各字段进行参数合法性校验：是否可选、唯一性、类型、取值范围、长度( 、=、 )等

◇ 遍历请求消息的各字段取值及组合，确认根据不同输入返回了不同的结果（可以等价）

◇ 发出响应消息正确性：协议、消息格式、各参数验证等。

S C 模式：被测对象既作为服务端接收请求又作为服务端发送请求。一般来说，流程中点（例子是的E 部件）多数为S C 模式。

如果将周边部件1 作为被测对象一部分，它即是C

如果将周边部件2 作为被测对象一部分，它即是S

基本验证要求：除了C 模式和S 模式的基本验证要求，考虑对不同消息间相关参数一性性进行校验。

例：R1 接口中X 参数取值为1-255，经过转换后的R2 接口中相应的X 参数取值也应为1-255。

进一步验证要求：参见C 模式和S 模式中的进一步验证要求。

3.2 复合模式

● 异步模式：被测对象发出消息后，对端立即响应，对端在处理结束后再发送回执消息给部件，部件根据对端所给出的消息作出相应的处理，流程结束。一般来说，如果对端处理较为复杂、为避免被测对象长时间被阻塞，会采用此通信方式。

对于异步模式，可以拆分为2 对消息，但这2 对消息是基于事务、有状态的。因此，对这类消息的验证除了基本模式C 和S 的验证要求外，还需要考虑2 对消息关系的配合对被测对象的状态影响验证。

以图示为例，被测对象的验证内容包括：

◇ 对A 接口的验证。参见C 模式

◇ 对B 接口的验证。参见S 模式

◇ A 和B 接口的配合：

条件：A 接口处理失败、未收到B 接口消息、B 接口处理失败、B 接口处理成功

结果：被测对象的状态、数据

● 分发模式：需要将消息采用同步方式向其它多个部件进行分发，待消息收齐后才能决定自身的最终状态。例：被 测对象通过分发部件将数据同步分发给不同的部件。需要说明的是：图示中的分发部件，这时从物理上来说，可能看到的只是一个部件，由它统一接受和分发消息， 但从逻辑上来说，它是代表了不同部件的接口处理的。

对于分发模式一般也是基于事务、有状态的，但由于涉及到了2 个以上的周边部件，还需要考虑对不同部件的接口消息处理结果进行结合。

以图示为例，被测对象的验证内容一般包括：

◇ 对A 接口的验证。（参见C 模式）

◇ 对B 接口的验证。（参见C 模式）

◇ 对部件1 和部件2 处理结果结合验证：

条件：1 成功2 成功；1 成功2 失败；1 失败2 成功；1 失败2 失败

结果：被测对象的状态、数据

● 异步分发模式：即采用异步方式进行消息分发，为异步和分发模式的结合。比较 典型的是数据同步异步接口。被测对象 通过分发部件 同时将数据同步消息通知分发给不同的部件，各个不同部件收到通知后再向被测对象请求获取同步数据。如果通知有优先级，例：部件1 部件2，待部件1 处理完再通知部件2，即为异步分发模式1。如果多个部件的分发并行执行（一般来说，部件1 和部件2 可能代表的是同类部件的不同物理实例），即为异步分发模式2。

对于异步分发模式，也即异步+分发模式的组合。此时被测对象涉及到2 种类型的消息配合：同一个部件的通知和回执的组合；不同部件间的消息处理结果的配合。由此，被测对象的状态迁移会更为复杂些。

以图示为例，被测对象的验证内容包括：

◇ 对A 接口的验证。（参见C 模式）

◇ 对B 接口的验证。（参见S 模式）

◇ 对C 接口的验证。（参见C 模式）

◇ 对D 接口的验证。（参见D 模式）

◇ 对A 和B 接口的配合验证。（参见异步模式）

◇ 对C 和D 接口的配合验证。（参见异步模式）

◇ 对部件1 和部件2 处理结果组合验证。（参见分发模式）

4、相关说明

● 参数合法性检验策略

如果业务流程涉及多次转发，原则上由逻辑处理部件进行接口参数的强校验；其它转发部件（例：E部件）进行弱校验。

消息序列验证

如果不同的接口消息之间是基于事务、有状态的，则还需要考虑消息序列异常的问题，无论是何种模式。其验证点包括：消息乱序、少传消息包、多传消息包、传重复消息包、事务超时后收到消息等。

接口可靠性保证

◇ 对于重发的验证，一般来说，重发机制中需要有重发策略、重发次数方面的考虑，不能出现消息反复重发引发消息风暴的问题。

◇ 对于超时的验证，需要考虑各部件超时配置不一致的问题。

◇ 对于处理失败造成双方数据不一致问题，需要有事务号、回滚或补偿机制等方面的设计考虑。

● 接口验证的不同阶段

对于接口验证在单部件测试、点-点接口联调、E2E联合测试等不同阶段都有所涉及。一般来说：

单部件测试：理论上通过测试桩可以模拟对端各种情况，对于真实实体只能通过系统状态预置、输入数据从外部触发。所以，能在单部件测试考虑的尽可能放到单部件去做，至少保证单部件自身是OK的。

点-点接口联调：如果将2个部件看作一个整体的话，则相当于单部件测试。对于部件-部件间的接口无法通过测试桩来模拟，需要通过外部驱动输入。另外还需要关注部件-部件间的网络连接，包括：是否可正常建立连接、连接中断后是否会重连、连接吊死与释放、时断时续等。

E2E联合测试：所有内部部件均为真实实体，对于接口间配合的问题（例：事务或数据一致性问题）可以考虑放到此考虑。除此还需要关注与外部部件间的接口对接测试。

====================================分割线================================

最新内容请见作者的GitHub页：http://qaseven.github.io/

接口参数注解验证案例 写作缘由 写接口的时候经常会有请求体里某字段不为null的需求；也有使用一个dto对象，但是插入和修改都想使用这个dto,那这样的话判断条件就不一样，因为修改操作必须有ID，所以参数验证还是挺麻烦的。所以写个demo记录一下，亲测可用。
服务器sever2008如何取消IE增强安全配置 安装WINDOWS server 系统以后，用浏览器打开网址时，系统总是提示“Internet Explorer 增强安全配置正在阻止下列网站的内容。如果把所有网址添加到信任列表是可以打开网址的，但是用起来很吃力。那么如何解决呢？
【esayui】扩展验证方法，控件验证 基础验证 //页面调用方法$.extend($.fn.validatebox.defaults.rules, { IsPhoneRex: {validator: function (value) {var rex = /^1[3-8]+\d{9}$/;var rex2 = /^((0\d{2,3})-)(\d{7,8})(-(\d{3,}))?$/;if (rex.
用途查询服务器上的自动删除任务。自动删除任务是一种运行在服务器上的服务，按照定义的规则自动删除过期的视频内容。例如，对于监控和视频直播类业务，可以定义一个任务，定期删除某个直播流30天前的录制内容。