接口验证模式

摘要:接口验证是软件测试中一个重要的方面。本文按被测对象与周边实体的消息处理关系将接口验证方式抽象成几种模式: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/

时间: 2024-10-02 08:41:08

接口验证模式的相关文章

更改 MSDE sa 密码和登录验证模式

更改 MSDE sa 密码和登录验证模式Microsoft SQL Desktop engine 2000 是一个常用的SQL支持数据库,但安装后其 sa 的默认密码为空,这样对数据安全有一定影响.因为MSDE2000是简化版本,无管理控制台,修改密码只能进入命令行方式.步骤:要注意的是要在切换了SQL的身份验证方式后才可以命令行修改密码.默认的SQL身份验证方式是Windows账户模式,要改为采用SQL身份验证. 要Windows账户身份验证模式切换到SQL的身份验证模式,请按以下步骤操作:

修改SQL身份验证模式和系统管理员

  1.如何修改SQL Server 2000身份验证模式和系统管理员? 分析:由于千方百剂软件,在数据库安全方面采用了最安全的方式"混合模式",它主要应用于网络主要是Novell网络或者对等网,使用SPX/IP协议和SQL Server验证模式. 优点如下: 创建了Windows NT/2000之上的另外一个安全层次. 支持更大范围的用户,例如非Windows NT客户.Novell网络等. 一个应用程序可以使用单个的SQL Server登录和口令. 下面以操作系统Windows 2

Windows身份验证模式和混合模式

  某日,A君问起Windows身份验证模式和混合模式验证的区别与优缺时,根据安全性的考虑,按照到了此文作为参考,学习下~ 在安装过程中,必须为数据库引擎选择身份验证模式. 可供选择的模式有两种:Windows 身份验证模式和混合模式. Windows 身份验证模式会启用 Windows 身份验证并禁用 SQL Server 身份验证. 混合模式会同时启用 Windows 身份验证和 SQL Server 身份验证. Windows 身份验证始终可用,并且无法禁用. 配置身份验证模式 如果在安装

服务访问接口验证,怎么将验证密钥放置于Authorization标头,求大神帮忙

问题描述 服务访问接口验证,怎么将验证密钥放置于Authorization标头,求大神帮忙 有请求地址,和验证密钥,就是验证方式不知道怎么操作将验证密钥放置于Authorization标头 .请求方式是GET.求大神呀,公司技术全解决不了... 解决方案 你没说什么语言,以及你在做客户端还是服务器端,自己按照http基本验证这个关键字google下. 比如http://blog.163.com/nice_2012/blog/static/19266614820132245395161/

sqlserver服务器验证改为混合验证模式步骤_MsSql

1.启动SQL Server Management Studio,以Windows身份验证方式登录. 2.在对象资源管理器窗口中,右键单击服务器,选择属性,打开服务器属性对话框. 3.在"安全性"页上的"服务器身份验证"下,选择新的服务器身份验证模式,再单击"确定". 4.重新启动 SQL Server 服务,可以直接通过右件键点击"对象资源管理器"进行启动. 5.使用该语句启用sa用户:alter login sa enab

VPN站点的路由(隧道、接口)模式及策略模式

常接触思科设备的都知道,目前使用IPsec协议建立的VPN站点都是无法使用路由的,要么采用GRE技术,GRE over IPsec可以实现路由,不过那样配置复杂不说,由于2次封装,每个数据包的有效载荷小了很多,效率性就不好了.也只能说目前,看ASA的进化方向,没准不知道什么时候就导入了. 而且目前采用策略模式的是大部分厂家的设备,cisco就不必说了,比如微软的ISA.SonicWall.D-link等:我目前发现支持路由模式的就只有两家,juniper的SSG和fortigate,要说起这两个

What’s popular的交叉验证模式

郑昀 20090919 有很多利用了群众性智慧的机器智能系统是回答 What's popular 这个问题的,比如: 阅读(Reading)领域: techmeme tweetmeme stumbleupon  iGoogle What's Popular gadget Delicious Popular Bookmarks 玩聚SR  事件(Event)领域: ? 趋势(Trend)领域: 搜索引擎搜索词热榜 Google Trends:Hot Trends(以天为单位) Twitter自己的

连接启用网络级身份验证模式的Windows 2008远程桌面

说起远程桌面很多用户都认为是从WIN2000 SERVER才开始引入的,实际上我们可以在WIN98甚至是DOS中看到他的身影.远程桌面采用的是一种类似TELNET的技术,他是从TELNET协议发展而来的. 计算机发展的早期在很多客户机硬件配置不高无法独立运行程序的情况下,TELNET协议应运而生,他是一种C/S模式,客户机可以通过TELNET登录到高配置的服务器上,在服务器上运行程序.当程序运行时所有的运算与存储都是教给服务器来完成的,当运算结束后服务器才把结果反馈回客户机,这样就可以在客户机配

HttpHelpers类普通GET和POST方式,带Cookie和带证书验证模式

最近把上面的方法整理了一下,给大家分享一下吧,不好的地方感谢大家留言指正,不多说了上代码吧! /// <summary> /// 类说明:HttpHelps教程类,用来实现Http访问,Post或者Get方式的,直接访问,带Cookie的,带证书的等方式 /// 编码日期:2011-09-13 /// 编 码 人: 苏飞 /// 联系方式:361983679 Email:sufei.1013@163.com Blogs:http://sufei.cnblogs.com /// </sum