FIX API业务消息验证测试：异常分类与处理逻辑问题咨询

针对你遇到的错误分类混淆、处理逻辑颠倒的问题，结合对接交易所撮合引擎的FIX测试经验，分享几个实用思路：

1. 先明确FIX引擎与撮合引擎的校验边界 #

联合开发、产品把两个引擎的校验职责划死：

• FIX引擎只负责协议层校验：包括字段数据类型匹配、必填字段是否存在、字段值是否符合FIX规范格式（如Timestamp格式、枚举值是否在FIX协议定义范围内），这类校验不通过直接返回Session Reject。
• 撮合引擎负责业务规则校验：包括交易所是否支持该订单类型、价格精度是否符合规则、字符串长度是否超出业务限制、账户权限是否允许等，这类校验不通过返回Execution Report(ExecType=Rejected)、CancelReplaceReject或Business Message Reject。
  边界定清楚后，后续所有测试用例的设计和错误判定都以此为基准。

2. 细化错误分类定义，消除模糊地带 #

不用急于新增维度，先把现有三类数据的定义再精准化：

• 有效数据：同时符合FIX协议规范和交易所业务规则的取值。
• 格式错误数据：违反FIX协议规范的取值（不管业务规则是否允许），比如数字字段填了非数字字符、必填字段缺失、Timestamp格式不符合FIX要求。
• 无效数据：符合FIX协议规范，但违反交易所业务规则的取值，比如交易所不支持的订单类型枚举值、价格精度超过交易所规定上限、订单金额超出账户限额。
  如果遇到某字段同时触发两种错误（比如格式错+业务错），按协议优先原则判定，先触发FIX引擎的Session Reject。

3. 构建双引擎覆盖的测试矩阵 #

针对每条入站业务消息，按「字段」「校验引擎」「错误类型」三个维度设计用例：

• 对每个字段，分别设计格式错误用例（验证FIX引擎拦截）和无效数据用例（验证撮合引擎拦截）。
• 增加跨边界场景测试：比如发送一个格式错误且业务无效的消息，验证是否优先被FIX引擎拦截并返回Session Reject；发送格式合法但业务无效的消息，验证FIX引擎放行后被撮合引擎拦截并返回业务类拒绝。

4. 分引擎单独验证，定位问题根源 #

测试时拆分场景，分别验证两个引擎的逻辑：

• 单独测试FIX引擎：屏蔽撮合引擎的业务校验，只发送格式错误消息，确认返回Session Reject；发送格式合法但业务无效的消息，确认消息能正常传递到撮合引擎。
• 单独测试撮合引擎：确保FIX引擎已通过格式校验，只发送业务无效消息，确认返回对应的业务类拒绝；发送有效消息，确认进入正常撮合流程。
  这种拆分能快速定位是哪个引擎的处理逻辑颠倒，方便针对性修复。

5. 谨慎新增分类维度 #

如果确实存在现有分类无法覆盖的场景（比如某枚举值在FIX协议中存在，但交易所和FIX引擎都不支持），再考虑新增「不正确或不支持」维度，但必须明确：

• 该维度的适用范围：仅用于既不完全符合格式错误定义，也不完全符合无效数据定义的场景。
• 对应的处理逻辑：明确由哪个引擎处理，返回哪种拒绝消息，避免再次出现逻辑混淆。

6. 同步更新文档与用例 #

每次修正引擎的校验逻辑后，及时更新测试用例和错误分类文档，确保所有相关人员（测试、开发、产品）的认知一致，避免后续测试出现偏差。

内容的提问来源于stack exchange，提问作者Alex Lyovochkin