Блог компании Os_Engine | Погрешности тестирования во время тестов в OsEngine и других платформах.

Проведение тестов на роботах зачастую вызывает у нас ожидание достоверных результатов. Однако, их достоверность зависит от различных факторов, и ошибки в тестах неизбежны.

Вы должны понимать, что любое тестирование имеет погрешность. На итоговые результаты тестов может влиять торговая платформа, в которой написан робот, например, одна и та же торговая стратегия, реализованная в разных платформах, может дать разные результаты.

От чего может возникать погрешность в тестах:

• Торговая логика робота, генерирующая логические нонсенсы.
• Условности в исполнении ордеров.
• Данные для тестирования.
• Методы работы модуля для тестирования (векторный/событийный).

Торговая логика робота, генерирующая логические нонсенсы.

 Сразу рассмотрим пример. Вводные:

• Тестируем на часовых свечках.
• Позиция открывается отложенным ордером типа BuyAtStop. То есть по пробою какого-то уровня.
• В логике робота мы подписаны на событие открытия позиции.
• В логике открытия позиции одновременно выставляем стоп и профит.

Непонимание работы тестера может привести к иллюзии успеха, если не учитывать особенности тестирования.

Что в примере будет происходить на самом деле:

• В робота будут подаваться свечи один раз в час.
• В робота будут подаваться данные в виде ленты сделок по OHLC, четыре трейда, по которым будут определяться исполнение стоп-приказов и профит-приказов.
• В итоге, внутри свечи, когда будет сообщение о том, что позиция у нас открылась, робот мгновенно выставит профит-приказ и стоп-приказ на этой же свече. И тестер/оптимизатор попробует исполнить данный приказ также внутри этой свечи.
• Может быть, профит будет исполняться чаще просто потому, что у Вас в логике тестера сначала идёт сравнение именно профита у позиции по OHLC, а не стопа.
• В итоге мы получаем в тестере эквити, идущую вертикально вверх. Только из-за логических ошибок, рождённых неправильным применением стоп/профит-приказов внутри тестирования робота на данных, для этого не предназначенных.

Внимание!

В данном примере, подписываясь на событие открытия позиции и выставляя в нём профит/стоп-приказы, для отсутствия погрешностей и логических ошибок тесты должны проводиться НА ТИКОВЫХ ДАННЫХ. Либо следует изменить Вашу логику, чтобы робот совершал какие-то действия с профитами и стопами по завершению свечи. Одновременно с этим выставлял ТОЛЬКО СТОП или ТОЛЬКО ПРОФИТ.

Логические нонсенсы – самое частое и опасное применение тестера/оптимизатора, которое только может быть. В рамках него, не разбираясь во внутреннем устройстве тестера, пользователь может НАРИСОВАТЬ себе прибыль.

Условности в исполнении ордеров.

Рис. 1. Настройки исполнения ордеров.

В целом, лимитные ордеры могут быть исполнены следующим образом:

• По пересечению цены ордера с ценой инструмента.
• По прикосновению цены ордера с ценой инструмента.
• 50 на 50 %. Из первых двух вариантов делается исполнение сначала одним, потом другим способом.

Маркет ордеры могут быть исполнены следующим образом:

• По закрытию текущей свечи.
• По открытию следующей свечи.
• По цене самого маркет ордера без оглядки на цену свечей.

Данные для тестирования.

Свечи имеют в себе всего четыре значения. Если тесты идут на них, некоторые типы заявок на свечном тестировании вносят существенную долю ошибки:

• Маркет ордера.
• Стоп и профит ордера, выставленные одновременно.

Тиковые данные в целом дают результат лучше, если использовать вышеописанные ситуации, но также не являются 100% гарантией того, что Ваши ордеры исполняются именно там, где это было бы в реальной торговле.

Проблемы тиковых данных:

• Исполнение по трейдам, а не по стакану не даёт 100 % точности определения точки входа как в реале.
• Тестирование больших объёмов данных за год, два или 10, невозможно или близко к невозможному. Что делает невозможными некоторые виды тестирования, такие как Walk-Forwards или Cross-Tests на достаточно глубоких данных, чтобы понять робастность стратегии.

Архитектура работы модуля для тестирования (векторный/событийный).

Векторная архитектура тестирования – способ проведения тестов, при котором данные берутся сразу за весь период, а торговый алгоритм бежит по этим данным в цикле, совершая какие-то торговые действия.

Особенности:

• Скорость. Это быстрее событийной архитектуры.
• Заглядывание в будущее. Это страшная вещь при тестах на таком типе архитектур. Очень опасная.
• Сложности при переносе в боевые торги, ибо логика робота не описывает их так, как это будет в реале.

Событийная архитектура тестирования – способ проведения тестов, когда создаётся, так называемый, эмулятор биржи. Он старается на основе имеющихся данных, выдавая их последовательно, сделать так, чтобы робот не понимал, торгует он в тестере или в реале.

Особенности:

• Низкая скорость.
• Отсутствие заглядывания в будущее.
• Простота при переносе в боевые торги.

Так что же делать?

Принять эту данность, как она есть. Понимать, что погрешность в любом случае будет. И для массовых тестов всё равно придётся применять свечи, допуская, что результаты тестирования могут отличаться от того, что будет в реальности на какую-то погрешность.

Удачных алгоритмов!

Комментарии открыты для друзей!

OsEngine: https://github.com/AlexWan/OsEngine
Поддержка OsEngine: https://t.me/osengine_official_support

Регистрируйся в АЛОР и получай бонусы: https://www.alorbroker.ru/open
Сайт АЛОР БРОКЕР: https://www.alorbroker.ru
Раздел «Для клиентов»: https://www.alorbroker.ru/openinfo/for-clients
Программа лояльности от АЛОР БРОКЕР и OsEngine: https://smart-lab.ru/company/os_engine/blog/972745.php