现货连接器 QA 检查清单
在批准新的连接器之前，Hummingbot 基金会质量保证 (QA) 团队将进行测试拉取请求，以确保其按预期工作。以下是用于现货连接器的测试模板。
| 标题 | 步骤 | 预期结果 |
|---|---|---|
| 连接 API 密钥 | 运行 connect name-of-connector 示例： connect binance |
1. 添加有效 API 密钥时能够成功连接。 2. 如果 API 密钥无效、已过期或存在其他问题，则应抛出错误或警告。 3. 同一个 API 密钥可以在多个机器人中使用，除非特别说明只能在一个实例中使用。 |
| 获取余额 | 运行 balance 命令 |
1. 显示当前可用余额，并且应与交易所显示的余额一致。 2. 每当有挂单时，分配金额应相应更新。 |
| 策略创建期间的市场可用性 | 在设置策略时，系统会提示： 请输入您想在 name-of-connector 上交易的代币交易对（例如 ZRX-ETH）>>> |
1. 在策略创建过程中设置市场时，应提供自动补全列表。 2. 所有市场在启动所创建的策略时都应正常工作。 |
| 与可用策略的兼容性 | 在不同的 Hummingbot 策略上创建简单的配置 | 1. 该连接器应能在客户端中所有可用策略上运行，除非该连接器专为特定策略设计。 2. 连接器应同时支持作为做市商和吃单方交易所使用（仅限现货连接器） |
| 价格和余额更新 | 运行 status 或 status --live 命令 状态命令快捷键：ctrl+s |
1. 在状态窗口中，订单簿发生变动时价格应持续更新。 2. 每当创建或取消订单时，可用余额应随之更新。 3. 创建的订单数量应保持一致，除非有多个机器人使用同一资产、存在挂单，或因特定参数导致订单被移除。 |
| 订单提交与取消 | 设置一个简单的做市策略并启动机器人 | 1. 创建的订单必须包含带有经纪商前缀的订单 ID（如果有）。 2. 订单在客户端中提交时无任何错误。 3. 提交的订单信息应与交易所在挂订单信息一致。 4. 订单可以无错误地取消。 5. 订单不应卡住或遗漏，手动下单的情况除外。 6. 客户端不应取消非本实例创建的订单，例如手动订单、其他实例创建的订单或第三方机器人的订单。 7. 对于不符合交易所规则的订单，应优雅地拒绝或取消。 |
| 快速刷新频率 | 1. 创建一个纯做市策略，并设置较快的订单刷新时间，同时禁用订单刷新容差 - 禁用方法： config order_refresh_tolerance -1 2. 运行 status 或 status --live 命令 3. 核对客户端与交易所在挂订单的一致性。 - 若有成交订单，请核对交易所在交易历史以及客户端的 history 或 history --verbose 命令输出 注意：请确保在具有稳定网络连接的设备上运行客户端。理想情况下，应在 Linux 云服务器上进行此测试 |
1. 优雅地取消订单：无卡住或丢失的订单 2. 余额相应更新 3. 快速取消期间日志中不应出现错误 4. 如果发生成交事件，已成交订单会被跟踪并保存 5. 当请求接近达到允许上限时，应抛出速率限制警告 6. 达到速率限制时停止下单，但保持与交易所的连接。 |
| 长刷新频率 | 1. 创建一个纯市价做市策略，并设置较快的订单刷新时间，禁用订单刷新容差 - 禁用方法： config order_refresh_tolerance -1 2. 运行 status 或 status --live 命令 注意：请确保在具有稳定网络连接的机器上运行客户端。理想情况下，应在 Linux 云服务器上进行测试 |
1. 存在未成交订单时保持连接性。 2. 若订单未成交，则优雅地取消该订单。 3. 订单打开期间不应出现任何错误（网络问题导致的异常除外） 4. 若发生网络问题，在连接恢复后应能追踪到未成交订单。 5. 断线期间可能发生的成交事件应被追踪和保存。 |
| 多个订单 | 创建支持多层订单的做市策略 - 设置 config order_level |
1. 能够同时提交多个订单且无任何错误。 2. 能够同时取消所有订单且无任何错误。 3. 可用余额和分配额度相应调整。 4. 订单数量和层级根据可用余额相应调整。 |
| 挂单 | 创建支持挂单的做市策略并设置取消百分比 - 设置 config hanging_orders_enabled - 设置 config hanging_orders_cancel_pct |
1. 持续追踪实例内生成的挂单。 2. 追踪并保存已成交的挂单。 3. 当策略停止或达到取消百分比时，挂单应被取消。 4. 当非挂单订单刷新时，挂单应保持未取消状态。 5. 不应出现挂单重复。 |
| 多个机器人 | 1. 使用同一交易所（相同账户和 API 密钥）设置多个测试机器人 2. 启动所有测试机器人。最好使用 docker 构建进行设置 3. 设置较窄的价差，以触发其中一个测试机器人的成交事件 4. 查看日志面板 5. 通过运行 history 或 history --verbose 命令、CSV 或 sqlite 文件以及交易所交易历史来比较所有测试机器人的数据 |
1. 每个机器人的未成交订单不应受其他机器人取消事件的影响。 2. 不应出现订单 ID 冲突。 |
| 数据完整性 | 1. 运行 status --live 2. 运行 order_book --live - 可添加参数如 order_book --live --line 10，表示每侧订单簿显示 10 笔订单 3. 运行 ticker --live |
1. 客户端中的订单簿与交易所的订单簿保持同步。 2. 当交易所数据发生变化时持续更新。 3. 当交易所数据变化时，价格持续更新（状态和行情）。 |
| 成交事件 | 设置一个挂单做市机器人，价差要足够小以确保成交。 1. 在没有挂单时运行 history 命令2. 成交后运行 history 或 history --verbose 命令- 可通过设置 history --verbose --precision 5 来增加小数位数，其中 5 是额外增加的小数位数3. 查看 history --verbose 命令、CSV 或 sqlite 文件以及交易所的成交历史 |
1. 完全成交和部分成交均被正确跟踪和记录。 2. 成交订单信息应与交易所在其成交历史中的记录一致。 |
| 历史 | 在有或没有成交的情况下运行 history 命令 |
1. 正确显示成交订单信息 - 无重复订单 - 保存部分成交记录 - 仅显示本实例创建的订单 2. 正确显示资产信息 |
| 交易手续费 | 客户端产生交易后： 1. 运行 history --verbose 命令2. 记录总手续费 3. 登录交易所网站并查看成交历史 4. 手动计算机器人完成的所有已成交交易的手续费 |
1. 如果有实际交易手续费，则应使用实际费用，否则使用估算费用。 2. 客户端中记录的交易手续费（CSV 或 SQLite）应与交易所在其成交历史中显示的手续费一致。 |
| 数据聚合 [仅限 QA 基础团队] | 1. 设置较窄的价差以便快速成交，并在 15 分钟后检查 Datadog 中 hummingbot 的 USDT 成交量指标 - 可在 conf/config_client.yml 中将 anonymized_metrics_interval_min 设置为更短的时间间隔2. 设置极窄的价差以立即成交，然后停止机器人，无需等待心跳间隔完成。 |
1. 启用后，所有成交交易将在 Datadog 中进行聚合 |