金融信息交换协议(FIX)5.0 FIXT1.1(7)

原创 2007年10月08日 10:31:00
 
7.3 Test cases applicable to all FIX systems
Ref ID参考号
Pre-
Condi-
tion
前置
条件
Test
case
测试
用例
Mandaory
/Optional
强制
/可选
 
Condition
/Stimulus
状态
/激发
Expected Beheavior期望行为
2
 
收到消息标准头
Mandatory
强制
A收到期望的MsgSeqNum
接受该消息的MsgSeqNum
 
 
 
 
b 收到比期望值大的MsgSeqNum
Resend Request消息作为响应
 
 
 
 
c 收到比期望值小的MsgSeqNumPossDupFlag不为‘Y
 
列外:SeqReset-Reset
1.         推荐FIX引擎尝试发送一个Logout,并带有Text的值为“MsgSeqNum too lowexpecting X but receiced Y
2.         (可选)等待Logout消息的响应(注意:可能会出现的错误的MsgSeqNum)或者等待2秒无论什么先到达
3.         断开连接
4.         产生、输出错误报告
 
 
 
 
d 收到混乱消息
1.         当做混乱消息并忽略消息(不增加输入MsgSeqNum),继续接收消息。
2.         产生并输出“警告”测试信息。
3.         发送Logout消息,在其Text域填写错误状态。
4.         断开连接。
 
 
 
 
e PossDupFlag值为‘Y’;OrigSendingTime值小于或等于SendingTimeMsgSeqNum比期望值小。
注意:OrigSendingTime应遭遇SendingTime除非该消息在同一秒内重传。
1.         检查是否该MsgSeqNum值消息已经被接收。
2.         如果已经收到,忽略该消息,否则接收并处理该消息。
 
 
 
 
f PossDupFlag值为‘Y’,OrigSendingTimeSendingTime大,且MsgSeqNum等于期望值
注意:OrigSendingTime应遭遇SendingTime除非该消息在同一秒内重传。
1.         发送Reject驳回消息参照不准确的发送时间>=FIX4.2SessionRejectReason = SendingTime 准确性问题”)
2.         增加接收MsgSeqNum
3.         可选:
a)         发送Logtout消息,参照不准确的SendingTime
b)        (可选)等待Logout响应(注意有可能有不准确的SendingTime)或者等待2秒无论什么消息先到达。
c)        断开连接。
产生、输出一个“错误”测试信息。
 
 
 
 
g PossDupFlag值为‘Y’,OrigSendingTime没有指定
注意:在响应Resen Request消息时,始终将OrigSendingTime设置为消息最开始发送的时间,不是当前SendingTime时间,并且PossDuFlag=Y
1.         发送Reject驳回消息参照不准确的发送时间>=FIX4.2SessionRejectReason = tag丢失”)
2.         增加接收MsgSeqNum
 
 
 
 
h 收到在测试Profile中指定的期望的BeginString,并且匹配发送消息的BeginString
接受该消息的BeginString
 
 
 
 
i收到不是在测试Profile中指定的期望的BeginString,并且匹配发送消息的BeginString
1.         发送Logout消息参照错误的BeginString值。
2.         (可选)等待Logout响应消息(注意可能有错误的BeginString)或者等待2秒无论什么先到达
3.         断开连接。
4.         产生、输出“错误“测试信息。
 
 
 
 
j收到在测试Profile中指定的期望的SenderCompIDTargetCompID
接受该消息的SenderCompIDTargetCompID
 
 
 
 
k收到不是在测试Profile中指定的期望的SenderCompIDTargetCompID
1.         发送Reject驳回消息参照无效的SenderCompIDTargetCompID>=FIX4.2SessionRejectReason = CompID错误”)
2.         增加接收MsgSeqNum值。
3.         参照错误的SenderCompIDTargetCompID值发送Logout消息。
4.         可选)等待Logout响应消息(注意可能有错误的SenderCompIDTargetCompID值)或者等待2秒无论什么先到达
5.         断开连接
6.         产生、输出“错误”测试信息。
 
 
 
 
l 收到正确的BodyLength
接受该消息的BodyLength
 
 
 
 
m收到正确的BodyLength
1.         当做混乱消息并忽略(不增加接收MsgSeqNum值),继续接收消息。
2.         产生、输出“警告”测试信息。
 
 
 
 
N SendingTime值使用UTC格式并在一个基于原子时间的合理范围内(如,2秒)
接受该消息的SendingTime
 
 
 
 
O收到的SendingTime值即不使用UTC格式也不是在一个基于原子时间的合理范围内(如,2秒)
1.         发送Reject驳回消息参照无效的SendingTim>=FIX4.2SessionRejectReason = SendingTime精确性问题”)
2.         增加接收MsgSeqNum
3.         参照不精确的SendingTime发送Logout消息。
4.         可选)等待Logout响应消息(注意可能有不精确的SendingTime)或者等待2秒无论什么先到达
5.         断开连接
6.         产生、输出“错误”测试消息。
 
 
 
 
 
P 收到有效MsgType值(在规范中定义或用户自定义文档中定义)
接受该消息的MsgType
 
 
 
 
收到无效MsgType值(没有在规范中定义或用户自定义文档中定义)
1.         发送Reject驳回消息参照无效的MsgType>=FIX4.2SessionRejectReason = “无效的MsgType”)
2.         增加接收MsgSeqNum
3.         产生、输出“警告”测试消息
 
 
 
 
R收到有效MsgType值(在规范中定义或用户自定义文档中定义)但不被测试Profile支持,或没再其中注册。
1.         if < FIX 4.2 参照有效的但不被支持的MsgType发送Reject驳回消息。
2.         if >=FIX4.2
a)         发送Business Message Reject驳回消息,参照有效但不被支持的MsgType。(>=FIX4.2BusinessRejectReason = “不支持的MsgType
3.         增加接收MsgSeqNum
4.         产生、输出“警告”测试消息
 
 
 
 
 
S 收到的BeginStirngBodyLength,和MsgType是消息的前三个域
接受该消息
 
 
 
 
t 收到的BeginStirngBodyLength,和MsgType是消息的前三个域
1.         当做混乱消息并忽略(不增加接收MsgSeqNum),继续接收消息。
2.         产生、输出“警告”测试消息
 
3
 
接收标准消息尾
强制
a 有效CheckSum
1.         接受消息
 
 
 
 
B 无效CheckSum
1.         当做混乱消息并忽略(不增加接收MsgSeqNum),继续接收消息。
2.         产生、输出“警告”测试消息
 
 
 
 
 
C 混乱消息
1.         当做混乱消息并忽略(不增加接收MsgSeqNum),继续接收消息。
2.         产生、输出“警告”测试消息
 
 
 
 
 
D CheckSum为消息的最后一个域,长度为3,并由分界符<SOH>分隔
接受该消息
 
 
 
 
E CheckSum不是消息的最后一个域,长度不为3,或不是由分界符<SOH>分隔
1.         当做混乱消息并忽略(不增加接收MsgSeqNum),继续接收消息。
2.         产生、输出“警告”测试消息
 
4
 
发送Heartbeat消息
强制
A 当前心跳时间间隔内无数据发送(HeartBearInt域)
发送Heartbeat消息
 
 
 
 
B接收到一个Test Request消息
发送Heartbeat消息,附带Test Request消息的TestReqID
5
 
接收Heartbeat消息
强制
有效的Heartbeat消息
接受Heartbeat消息。
6
 
发送Test Request
强制
当前心跳时间间隔+某个时间周期(20%HeartBeatInt值)内无数据接收
1.         发送Test Request消息
2.         跟踪确认一个使用TestReqIDHeartbeat被接收(可以不是下一个消息)。
7
 
接收Reject驳回消息
强制
有效的Reject消息
1.         增加接收MsgSeqNum
2.         继续接收消息
8
 
接收Resend Request消息
强制
有效的Resend Request消息
使用应用层消息,和按照“消息恢复”规则在请求范围内使用SequenceReset-Gap Fill消息进行响应
9
 
同步序列号
可选
应用程序故障
发送Sequence Reset-Reset消息或手动复位
10
 
接收Sequence ResetGap Fill
强制
A 收到Sequence ResetGap Fill)消息,NewSeqNo > MsgSeqNum MsgSeqNum > 期望序列号
发送Resend Request,在最后一个期望MsgSeqNum到接收到的MsgSeqNum范围内填冲消息间隙。
 
 
 
 
B收到Sequence ResetGap Fill)消息,NewSeqNo > MsgSeqNum MsgSeqNum = 期望序列号
设置下一个期望序列号为NewSeqNo
 
 
 
 
C收到Sequence ResetGap Fill)消息,NewSeqNo > MsgSeqNum MsgSeqNum < 期望序列号
PossDupFlag = “Y”
忽略消息
 
 
 
 
D收到Sequence ResetGap Fill)消息,NewSeqNo > MsgSeqNum MsgSeqNum < 期望序列号
没有PossDupFlag = “Y”
1.         如果可能,在断开FIX会话前,发送带有Text域为“MsgSeqNum too low, expecting X received Y,”的Logout消息
2.         (可选)等待Logout响应(注意可能有不精确的MsgSeqNum)或者等待2秒无论什么先到达)
3.         断开连接
4.         产生、输出“错误”测试信息。
 
 
 
 
E收到Sequence ResetGap Fill)消息,NewSeqNo <= MsgSeqNum MsgSeqNum = 期望序列号
发送Reject(会话层)驳回消息,携带信息“attempt to lower sequnce number, invalid value NewSeqNum=<x>
11
 
接收Sequence ResetReset
强制
A 收到Sequence ResetGap Fill)消息,NewSeqNo> 期望序列号
1.         接受该Sequence Reset消息,忽略其MsgSeqNum
2.         将期期望序列号设置为NewSeqNo
 
 
 
 
 
B收到Sequence ResetGap Fill)消息,NewSeqNo= 期望序列号
1.         接受该Sequence Reset消息,忽略其MsgSeqNum
2.         产生、输出“警告”测试信息。
 
 
 
 
C收到Sequence ResetGap Fill)消息,NewSeqNo< 期望序列号
1.         接受该Sequence Reset消息,忽略其MsgSeqNum
2.         发送Reject会话层驳回消息,参照无效的MsgType。(>=FIX4.2SessionRejectReason = tag值错误超界)”)
3.         不增加接收MsgSeqNum
4.         产生、输出“错误”测试消息。
5.         不能减小序列号。
 
12
 
发起注销过程
强制
发起Logout
1.         发送Logout消息
2.         10秒内等待Logtout响应(注意,可能由于出现的通信问题不能收到)。如果没有收到,产生输出“警告”测试消息
3.         断开连接。
13
 
接收Logtout消息
强制
A 收到有效的Logout消息作为请求注销处理过程的响应
断开连接,不发送消息。
 
 
 
 
B 接收到有效的非请求的Logout消息
1.         发送Logout响应消息。
2.         10秒内等待对端断开连接。如果超过等待时间,断开连接,产生输出“错误”测试消息
14
 
接收应用消息或管理消息
强制
A收到的域识别符(tag值)未在规范文档中定义
例外:未在规范文档中定义,但在测试Profile中作为用户定义的tag
1.         发送Reject会话层驳回消息,参照无效的tag。(>=FIX4.2SessionRejectReason = 无效的tag”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
B 接收消息中必选Tag丢失
1.         发送Reject会话层驳回消息,参照丢失的必选tag。(>=FIX4.2SessionRejectReason = “必选tag丢失”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
 
C 接收消息tag在规范文档中定义,但不是为该消息类型定义的
1.         发送Reject会话层驳回消息,参照丢不是为该消息类型定义的tag。(>=FIX4.2SessionRejectReason = “该消息未定义此Tag”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
 
D 接收消息tag在规范文档中定义,但为空值(如55=<SOH>
1.         发送Reject会话层驳回消息,参照已定义但值为空的tag。(>=FIX4.2SessionRejectReason = “指定的Tag值为空”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
 
E 接受消息特定tag值取值、取值范围错误,或不是有效的枚举值。
例外:在测试Profile中作为用户自定义的未在规范文档中定义的枚举值
1.         发送Reject会话层驳回消息,参照取值错误的tag。(>=FIX4.2SessionRejectReason = Tag值错误(超界)”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
 
F接受消息特定tag值格式(语法)错误
 
1.         发送Reject会话层驳回消息,参照取值格式错误的tag。(>=FIX4.2SessionRejectReason = “值格式错误”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
G 消息结构不是和ader+body+trailer
1.         发送Reject会话层驳回消息,参照不正确地消息结构。(>=FIX4.2SessionRejectReason = “指定的Tag顺序错误”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
H 消息中一个tag不是重复组的组成部分,但被多次指定
1.         发送Reject会话层驳回消息,参照重复的tag。(>=FIX4.2SessionRejectReason = Tag重复出现”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
I 消息中重复组count域值错误
1.         发送Reject会话层驳回消息,参照错误的count域。(>=FIX4.2SessionRejectReason = “重复组无效的NumInGroup计数”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
J 重复组域顺序未匹配规范
1.         发送Reject会话层驳回消息,参照重复组错误的域顺序。(>=FIX4.2SessionRejectReason = “重复组域顺序错误”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
K 域的tag标识中含有多个<SOH>(非域数据)
 
1.         发送Reject会话层驳回消息,参照域的含有多个<SOH>tag标识。(>=FIX4.2SessionRejectReason = “非域数据包含分界符号(SOH 字符)”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
 
 
 
 
L 当应用曾处理或系统无效收到消息
1.         if <FIX 4.2
a)         发送Reject会话层驳回消息,参考应用处理无效。
2.         if >=FIX 4.2
a)         发送Business Message Reject消息,参考域参考应用处理无效。(>=FIX4.2BusinessRejectReason = “应用程序无效”)
4.         增加接收MsgSeqNum
5.         产生、输出“警告”测试消息
 
 
 
 
 
M 消息中常规必选域丢失
1.         if <FIX 4.2
b)        发送Reject会话层驳回消息,参考丢失的常规必选域。
2.         if >=FIX 4.2
a)         发送Business Message Reject消息,参考丢失的常规必选域。(>=FIX4.2BusinessRejectReason = “常规必选域丢失”)
3.         增加接收MsgSeqNum
4.         产生、输出“错误”测试消息
 
 
 
 
N 在明文中出现的Tag数与密文中出现的相同,但Tag值不同
1.         发送Reject会话层驳回消息,参照明文和密文中具有相tag数,但值不同的域。(>=FIX4.2SessionRejectReason = “解密问题/错误”)
2.         增加接收MsgSeqNum
3.         产生、输出“错误”测试消息
15
 
发送应用或管理消息以测试正常和异常的行为/响应
 
发送多个消息同类消息,其头部和数据体域顺序不同,以验证消息接受(排除有顺序限制的)
消息被接受并且其后续消息的MsgSeqNum被接受。
16
 
排队待发送消息
强制
A 当处于连接断开时待发消息排队
排队待发送消息。注意,有2种方法:
1.         排队消息,不考虑MsgSeqNum
a)         存储消息数据。
2.         使用下一个MsgSeqNum值,排队每一个消息
a)         采用消耗下一个MsgSeqNum值的方式,存储消息数据。
注意:SendingTimeTag#52):必须包是消息发送的时间,而不是消息进入排队的时间。
 
 
 
 
B 带有排队消息的重连。
1.         完成登陆过程(连接,交换Logon消息)
2.         如可能,完成MsgSeqNum恢复过程。
3.         推荐短暂延迟或使用TestRequest/Heartbeat确认MsgSeqNum恢复完成。
4.         注意,这里有2种有效的排队方法:
a)         排队消息,不考虑MsgSeqNum
                         i.              使用新MsgSeqNum发送排队消息(大于Logon消息的MsgSeqNum)。
b)        使用下一个MsgSeqNum值,排队每一个消息
                         i.              (注意,)Logon消息的MsgSeqNum大于排队消息的MsgSeqNum
                       ii.              对端将发起ResendRequest请求这个范围内丢失的消息
                      iii.              重发每个排队消息,将PossDupFlag设置为‘Y
注意:SendingTimeTag#52):必须包是消息发送的时间,而不是消息进入排队的时间。
17
 
加密支持
可选
A 接收Logon消息,带有有效的北支持的EncryptMethod
 
1.         接受该消息
2.         执行适当的解密或加密方法。
3.         使用同一个EncryptMethod方法响应Logon消息。
 
 
 
 
B 收到Logon消息,带有无效的或不支持的EncryptMethod
1.         发送Reject会话层驳回消息,参照无效的或不支持EncryptMethod。(>=FIX4.2SessionRejectReason = “解密问题”)
2.         增加接收MsgSeqNum值。
3.         发送Logout消息,参照无效的或不支持EncryptMethod
4.         (可选)等待Logout响应(注意可能有解密问题)或者等待2秒无论什么先到达)
5.         断开连接
6.         产生、输出“错误”测试消息。
 
 
 
 
C 收到消息,带有SignatureLengthSignature
接受该消息
 
 
 
 
D 收到消息,带有无效的SigntureLength
1.         发送Reject会话层驳回消息,参照无效的SignatureLength值。(>=FIX4.2SessionRejectReason = “签名问题”)
2.         增加接收MsgSeqNum值。
3.         产生、输出“错误”测试消息。
 
 
 
 
E收到消息,带有无效的Signture
1.         发送Reject会话层驳回消息,参照无效的Signature值。(>=FIX4.2SessionRejectReason = “签名问题”)
2.         增加接收MsgSeqNum值。
3.         产生、输出“错误”测试消息。
或者,考虑解密错误或顺序错误的消息,忽略消息(不增加接收MsgSeqNum值)并继续接收消息。
 
 
 
 
F 收到消息,有有效的SecureDataLenSecureData值,且能被解密为有效的,能接戏的明文
接收消息。
 
 
 
 
G 接收消息SecureDataLen值无效
1.         当做解密错误或消息顺序错,忽略消息(不增加接收MsgSeqNum值)并继续接收消息。
2.         产生、输出“警告”测试消息。
 
 
 
 
H 接收消息带有不能被解密为有效、能被解析的明文
1.         发送Reject会话层驳回消息,参照无效的SecureData值。(>=FIX4.2SessionRejectReason = “解密问题”)
2.         增加接收MsgSeqNum值。
3.         产生、输出“错误”测试消息。
 
 
 
 
I 接收消息中一个或多个域本应按规范不能被加密的,未出现在非加密部分
1.         发送Reject会话层驳回消息,参照不能加密的丢失域的Tag值。(>=FIX4.2SessionRejectReason = “解密问题”)
2.         增加接收MsgSeqNum值。
3.         产生、输出“错误”测试消息。
 
 
 
 
J 接收消息有按照指定的EncrypMethod有错误的“left over”字符处理(如,当密文前的明文长度部位8的倍数时)
1.         发送Reject会话层驳回消息,参照错误的“left over”字符处理。(>=FIX4.2SessionRejectReason = “解密问题”)
2.         增加接收MsgSeqNum值。
3.         产生、输出“错误”测试消息
18
 
支持第三方寻址
可选
A 接收消带有OnBehalfOfCompIDeliverToCompID值,同测试Profile中指正确用法相符
接收消息
 
 
 
 
B接收消带有OnBehalfOfCompIDeliverToCompID值,同测试Profile中指正确用法不相符
1.         发送Reject会话层驳回消息,参照无效的OnBehalfOfCompIDeliverToCompID。(>=FIX4.2SessionRejectReason = CompID问题”)
2.         增加接收MsgSeqNum值。
3.         产生、输出“错误”测试消息
19
 
测试PossResend处理
强制
A 接收消息带有PossResend=Y’且应用层消息ID检查显示其已经在本次会话中出现过
1.         忽略该消息
2.         产生、输出“警告”测试消息。
 
 
 
 
B接收消息带有PossResend=Y’且应用层消息ID检查显示其已经在本次会话中没有出现过
接受并正常处理该消息。
20
 
同时Resend 请求测试
强制
当已经发送和等待一个Resend Request消息的所有响应后,接收到一个Resend Request消息
1.         执行请求被请求消息的重传。
2.         发送Resend Request消息请求丢失消息重发。
 
 
 
 
 
 
 
 

金融信息交换协议(FIX)5.0 FIXT1.1(7)

金融信息交换协议(FIX)5.0 FIXT1.1
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:35
  • 609

金融信息交换协议(FIX)5.0 FIXT1.1(1)

本博客suoyouSongzhang
  • u012398613
  • u012398613
  • 2014年10月19日 20:07
  • 740

金融信息交换协议(FIX)v5.0读书笔记(2)

金融信息交换协议(FIX)
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:07
  • 729

金融信息交换协议(FIX)5.0 FIXT1.1(4)

金融信息交换协议(FIX)5.0 FIXT1.1
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:30
  • 612

金融信息交换协议(FIX)5.0 FIXT1.1(2)

下一篇金融信息交换协议(FIX)5.0 FIXT1.1
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:17
  • 508

金融信息交换协议(FIX)5.0 FIXT1.1(5)

金融信息交换协议(FIX)5.0 FIXT1.1
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:32
  • 495

金融信息交换协议(FIX)5.0 FIXT1.1(6)

金融信息交换协议(FIX)5.0 FIXT1.1
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:34
  • 662

金融信息交换协议(FIX)5.0 FIXT1.1(3)

金融信息交换协议(FIX)5.0 FIXT1.1
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:27
  • 555

金融信息交换协议(FIX)5.0 FIXT1.1(1)

下一篇金融信息交换协议(FIX)
  • AAA123524457
  • AAA123524457
  • 2016年02月01日 11:15
  • 667

金融信息交换协议(FIX)

原文地址: http://blog.csdn.net/great3779/article/details/8585518 随着网络的使用,目前所有大型的金融机构都已经实现了自动...
  • Sherlockdove
  • Sherlockdove
  • 2015年08月14日 13:34
  • 428
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:金融信息交换协议(FIX)5.0 FIXT1.1(7)
举报原因:
原因补充:

(最多只允许输入30个字)