金融信息交换协议（FIX）5.0 FIXT1.1（7）

 

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  收到比期望值小的 MsgSeqNum 且 PossDupFlag 不为‘ Y ’   列外： SeqReset-Reset	1.          推荐 FIX 引擎尝试发送一个 Logout ，并带有 Text 的值为“ MsgSeqNum too low ， expecting X but receiced Y ” 2.          （可选）等待 Logout 消息的响应（注意：可能会出现的错误的 MsgSeqNum ）或者等待 2 秒无论什么先到达 3.          断开连接 4.          产生、输出错误报告
				d 收到混乱消息	1.          当做混乱消息并忽略消息（不增加输入 MsgSeqNum ），继续接收消息。 2.          产生并输出“警告”测试信息。 3.          发送 Logout 消息，在其 Text 域填写错误状态。 4.          断开连接。
				e PossDupFlag 值为‘ Y ’； OrigSendingTime 值小于或等于 SendingTime 且 MsgSeqNum 比期望值小。 注意： OrigSendingTime 应遭遇 SendingTime 除非该消息在同一秒内重传。	1.          检查是否该 MsgSeqNum 值消息已经被接收。 2.          如果已经收到，忽略该消息，否则接收并处理该消息。
				f PossDupFlag 值为‘ Y ’， OrigSendingTime 比 SendingTime 大，且 MsgSeqNum 等于期望值 注意： OrigSendingTime 应遭遇 SendingTime 除非该消息在同一秒内重传。	1.          发送 Reject 驳回消息 ， 参照不准确的发送时间 （ >=FIX4.2 ： SessionRejectReason =  “ 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.2 ： SessionRejectReason =  “ tag 丢失”） 2.          增加接收 MsgSeqNum 值
				h 收到在测试Profile中指定的期望的BeginString值，并且匹配发送消息的BeginString值	接受该消息的BeginString
				i收到不是在测试Profile中指定的期望的BeginString值，并且匹配发送消息的BeginString值	1.          发送 Logout 消息参照错误的 BeginString 值。 2.          （可选）等待 Logout 响应消息（注意可能有错误的 BeginString ）或者等待 2 秒无论什么先到达 3.          断开连接。 4.          产生、输出“错误“测试信息。
				j收到在测试Profile中指定的期望的SenderCompID和TargetCompID值	接受该消息的SenderCompID和TargetCompID
				k收到不是在测试Profile中指定的期望的SenderCompID和TargetCompID值	1.          发送 Reject 驳回消息 ， 参照无效的 SenderCompID 和 TargetCompID 。 （ >=FIX4.2 ： SessionRejectReason =  “ CompID 错误”） 2.          增加接收 MsgSeqNum 值。 3.          参照错误的 SenderCompID 或 TargetCompID 值发送 Logout 消息。 4.          （ 可选 ）等待 Logout 响应消息（注意可能有错误的 SenderCompID 或 TargetCompID 值）或者等待 2 秒无论什么先到达 5.          断开连接 6.          产生、输出“错误”测试信息。
				l 收到正确的BodyLength值	接受该消息的BodyLength
				m收到正确的BodyLength值	1.          当做混乱消息并忽略（不增加接收 MsgSeqNum 值），继续接收消息。 2.          产生、输出“警告”测试信息。
				N SendingTime值使用UTC格式并在一个基于原子时间的合理范围内（如，2秒）	接受该消息的SendingTime
				O收到的SendingTime值即不使用UTC格式也不是在一个基于原子时间的合理范围内（如，2秒）	1.          发送 Reject 驳回消息 ， 参照无效的 SendingTim 。 （ >=FIX4.2 ： SessionRejectReason =  “ SendingTime 精确性问题”） 2.          增加接收 MsgSeqNum 值 3.          参照不精确的 SendingTime 发送 Logout 消息。 4.          （ 可选 ）等待 Logout 响应消息（注意可能有不精确的 SendingTime ）或者等待 2 秒无论什么先到达 5.          断开连接 6.          产生、输出“错误”测试消息。
				P 收到有效MsgType值（在规范中定义或用户自定义文档中定义）	接受该消息的MsgType
				收到无效MsgType值（没有在规范中定义或用户自定义文档中定义）	1.          发送 Reject 驳回消息 ， 参照无效的 MsgType 。 （ >=FIX4.2 ： SessionRejectReason =  “无效的 MsgType ”） 2.          增加接收 MsgSeqNum 值 3.          产生、输出“警告”测试消息
				R收到有效MsgType值（在规范中定义或用户自定义文档中定义）但不被测试Profile支持，或没再其中注册。	1.          if < FIX 4.2  参照有效的但不被支持的 MsgType 发送 Reject 驳回消息。 2.          if >=FIX4.2 a)          发送 Business Message Reject 驳回消息，参照有效但不被支持的 MsgType 。（ >=FIX4.2 ： BusinessRejectReason =  “不支持的 MsgType ” 3.          增加接收 MsgSeqNum 值 4.          产生、输出“警告”测试消息
				S 收到的BeginStirng，BodyLength，和MsgType是消息的前三个域	接受该消息
				t 收到的BeginStirng，BodyLength，和MsgType是消息的前三个域	1.          当做混乱消息并忽略（不 增加接收 MsgSeqNum 值 ），继续接收消息。 2.          产生、输出“警告”测试消息
3		接收标准消息尾	强制	a 有效CheckSum	1.          接受消息
				B 无效CheckSum	1.          当做混乱消息并忽略（不 增加接收 MsgSeqNum 值 ），继续接收消息。 2.          产生、输出“警告”测试消息
				C 混乱消息	1.          当做混乱消息并忽略（不 增加接收 MsgSeqNum 值 ），继续接收消息。 2.          产生、输出“警告”测试消息
				D CheckSum为消息的最后一个域，长度为3，并由分界符分隔	接受该消息
				E CheckSum不是消息的最后一个域，长度不为3，或不是由分界符分隔	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.          跟踪确认一个使用 TestReqID 的 Heartbeat 被接收（可以不是下一个消息）。
7		接收Reject驳回消息	强制	有效的Reject消息	1.          增加接收 MsgSeqNum 值 2.          继续接收消息
8		接收Resend Request消息	强制	有效的Resend Request消息	使用应用层消息，和按照“消息恢复”规则在请求范围内使用SequenceReset-Gap Fill消息进行响应
9		同步序列号	可选	应用程序故障	发送Sequence Reset-Reset消息或手动复位
10		接收Sequence Reset（Gap Fill）	强制	A 收到Sequence Reset（Gap Fill）消息，NewSeqNo > MsgSeqNum 且MsgSeqNum > 期望序列号	发送Resend Request，在最后一个期望MsgSeqNum到接收到的MsgSeqNum范围内填冲消息间隙。
				B收到Sequence Reset（Gap Fill）消息，NewSeqNo > MsgSeqNum 且MsgSeqNum = 期望序列号	设置下一个期望序列号为NewSeqNo
				C 收到 Sequence Reset （ Gap Fill ）消息， NewSeqNo > MsgSeqNum  且 MsgSeqNum <  期望序列号 且 PossDupFlag = “Y”	忽略消息
				D 收到 Sequence Reset （ Gap 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 Reset（Gap Fill）消息，NewSeqNo <= MsgSeqNum 且MsgSeqNum = 期望序列号	发送Reject（会话层）驳回消息，携带信息“attempt to lower sequnce number, invalid value NewSeqNum=”
11		接收Sequence Reset（Reset）	强制	A 收到Sequence Reset（Gap Fill）消息，NewSeqNo> 期望序列号	1.          接受该 Sequence Reset 消息，忽略其 MsgSeqNum 2.          将期期望序列号设置为 NewSeqNo
				B收到Sequence Reset（Gap Fill）消息，NewSeqNo= 期望序列号	1.          接受该 Sequence Reset 消息，忽略其 MsgSeqNum 2.          产生、输出“警告”测试信息。
				C收到Sequence Reset（Gap Fill）消息，NewSeqNo< 期望序列号	1.          接受该 Sequence Reset 消息，忽略其 MsgSeqNum 2.          发送 Reject 会话层 驳回消息，参照无效的 MsgType 。（ >=FIX4.2 ： SessionRejectReason =  “ 此 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.2 ： SessionRejectReason =  “ 无效的 tag ”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				B 接收消息中必选Tag丢失	1.          发送 Reject 会话层 驳回消息，参照丢失的必选 tag 。（ >=FIX4.2 ： SessionRejectReason =  “必选 tag 丢失”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				C 接收消息tag在规范文档中定义，但不是为该消息类型定义的	1.          发送 Reject 会话层 驳回消息，参照丢不是为该消息类型定义的 tag 。（ >=FIX4.2 ： SessionRejectReason =  “该消息未定义此 Tag ”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				D 接收消息tag在规范文档中定义，但为空值（如55=）	1.          发送 Reject 会话层 驳回消息，参照已定义但值为空的 tag 。（ >=FIX4.2 ： SessionRejectReason =  “指定的 Tag 值为空”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				E  接受消息特定 tag 值取值、取值范围错误，或不是有效的枚举值。 例外：在测试 Profile 中作为用户自定义的未在规范文档中定义的枚举值	1.          发送 Reject 会话层 驳回消息，参照取值错误的 tag 。（ >=FIX4.2 ： SessionRejectReason =  “ Tag 值错误（超界）”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				F 接受消息特定 tag 值格式（语法）错误	1.          发送 Reject 会话层 驳回消息，参照取值格式错误的 tag 。（ >=FIX4.2 ： SessionRejectReason =  “值格式错误”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				G 消息结构不是和ader+body+trailer	1.          发送 Reject 会话层 驳回消息，参照不正确地消息结构。（ >=FIX4.2 ： SessionRejectReason =  “指定的 Tag 顺序错误”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				H 消息中一个tag不是重复组的组成部分，但被多次指定	1.          发送 Reject 会话层 驳回消息，参照重复的 tag 。（ >=FIX4.2 ： SessionRejectReason =  “ Tag 重复出现”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				I 消息中重复组count域值错误	1.          发送 Reject 会话层 驳回消息，参照错误的 count 域。（ >=FIX4.2 ： SessionRejectReason =  “重复组无效的 NumInGroup 计数”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				J 重复组域顺序未匹配规范	1.          发送 Reject 会话层 驳回消息，参照重复组错误的域顺序。（ >=FIX4.2 ： SessionRejectReason =  “重复组域顺序错误”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				K  域的 tag 标识中含有多个 ( 非域数据 )	1.          发送 Reject 会话层 驳回消息，参照域的含有多个 的 tag 标识。（ >=FIX4.2 ： SessionRejectReason =  “非域数据包含分界符号 (SOH  字符 ) ”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
				L 当应用曾处理或系统无效收到消息	1.          if a)          发送 Reject 会话层 驳回消息，参考应用处理无效。 2.          if >=FIX 4.2 a)          发送 Business Message Reject 消息，参考域参考应用处理无效。（ >=FIX4.2 ： BusinessRejectReason =  “应用程序无效”） 4.          增加接收 MsgSeqNum 。 5.          产生、输出“警告”测试消息
				M 消息中常规必选域丢失	1.          if b)         发送 Reject 会话层 驳回消息，参考丢失的常规必选域。 2.          if >=FIX 4.2 a)          发送 Business Message Reject 消息，参考丢失的常规必选域。（ >=FIX4.2 ： BusinessRejectReason =  “常规必选域丢失”） 3.          增加接收 MsgSeqNum 。 4.          产生、输出“错误”测试消息
				N 在明文中出现的Tag数与密文中出现的相同，但Tag值不同	1.          发送 Reject 会话层 驳回消息，参照明文和密文中具有相 tag 数，但值不同的域。（ >=FIX4.2 ： SessionRejectReason =  “解密问题 / 错误”） 2.          增加接收 MsgSeqNum 。 3.          产生、输出“错误”测试消息
15		发送应用或管理消息以测试正常和异常的行为/响应		发送多个消息同类消息，其头部和数据体域顺序不同，以验证消息接受（排除有顺序限制的）	消息被接受并且其后续消息的MsgSeqNum被接受。
16		排队待发送消息	强制	A 当处于连接断开时待发消息排队	排队待发送消息。注意，有 2 种方法： 1.          排队消息，不考虑 MsgSeqNum a)          存储消息数据。 2.          使用下一个 MsgSeqNum 值，排队每一个消息 a)          采用消耗下一个 MsgSeqNum 值的方式，存储消息数据。 注意： SendingTime （ Tag#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 ’ 注意： SendingTime （ Tag#52 ）：必须包是消息发送的时间，而不是消息进入排队的时间。
17		加密支持	可选	A  接收 Logon 消息，带有有效的北支持的 EncryptMethod	1.          接受该消息 2.          执行适当的解密或加密方法。 3.          使用同一个 EncryptMethod 方法响应 Logon 消息。
				B 收到Logon消息，带有无效的或不支持的EncryptMethod	1.          发送 Reject 会话层 驳回消息，参照无效的或不支持 EncryptMethod 。（ >=FIX4.2 ： SessionRejectReason =  “解密问题”） 2.          增加接收 MsgSeqNum 值。 3.          发送 Logout 消息，参照无效的或不支持 EncryptMethod 4.          （可选）等待 Logout 响应（注意可能有解密问题）或者等待 2 秒无论什么先到达） 5.          断开连接 6.          产生、输出“错误”测试消息。
				C 收到消息，带有SignatureLength和Signature值	接受该消息
				D 收到消息，带有无效的SigntureLength值	1.          发送 Reject 会话层 驳回消息，参照无效的 SignatureLength 值。（ >=FIX4.2 ： SessionRejectReason =  “签名问题”） 2.          增加接收 MsgSeqNum 值。 3.          产生、输出“错误”测试消息。
				E收到消息，带有无效的Signture值	1.          发送 Reject 会话层 驳回消息，参照无效的 Signature 值。（ >=FIX4.2 ： SessionRejectReason =  “签名问题”） 2.          增加接收 MsgSeqNum 值。 3.          产生、输出“错误”测试消息。 或者，考虑解密错误或顺序错误的消息，忽略消息（不增加接收 MsgSeqNum 值）并继续接收消息。
				F 收到消息，有有效的SecureDataLen和SecureData值，且能被解密为有效的，能接戏的明文	接收消息。
				G 接收消息SecureDataLen值无效	1.          当做解密错误或消息顺序错，忽略消息（不增加接收 MsgSeqNum 值）并继续接收消息。 2.          产生、输出“警告”测试消息。
				H 接收消息带有不能被解密为有效、能被解析的明文	1.          发送 Reject 会话层 驳回消息，参照无效的 SecureData 值。（ >=FIX4.2 ： SessionRejectReason =  “解密问题”） 2.          增加接收 MsgSeqNum 值。 3.          产生、输出“错误”测试消息。
				I 接收消息中一个或多个域本应按规范不能被加密的，未出现在非加密部分	1.          发送 Reject 会话层 驳回消息，参照不能加密的丢失域的 Tag 值。（ >=FIX4.2 ： SessionRejectReason =  “解密问题”） 2.          增加接收 MsgSeqNum 值。 3.          产生、输出“错误”测试消息。
				J 接收消息有按照指定的Encryp他Method有错误的“left over”字符处理（如，当密文前的明文长度部位8的倍数时）	1.          发送 Reject 会话层 驳回消息，参照错误的“ left over ”字符处理。（ >=FIX4.2 ： SessionRejectReason =  “解密问题”） 2.          增加接收 MsgSeqNum 值。 3.          产生、输出“错误”测试消息
18		支持第三方寻址	可选	A 接收消带有OnBehalfOfCompI和DeliverToCompID值，同测试Profile中指正确用法相符	接收消息
				B接收消带有OnBehalfOfCompI和DeliverToCompID值，同测试Profile中指正确用法不相符	1.          发送 Reject 会话层 驳回消息，参照无效的 OnBehalfOfCompI 和 DeliverToCompID 。（ >=FIX4.2 ： SessionRejectReason =  “ 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 消息请求丢失消息重发。