Comment le Testeur télécharge les données historiques

Chargement des données historiques, préparation des tests et ajustement de la date de début des tests

Le Testeur de Stratégie crée une simulation de marché très réaliste. Pour cela, il précharge suffisamment de données historiques pour le symbole sélectionné.

Avant d'effectuer un test, la plateforme synchronise les données historiques :

• Depuis le serveur de trading, les barres M1 et les données des ticks pour le symbole sélectionné sont téléchargées sur le terminal. Lors du premier lancement du testeur, le terminal télécharge tout l'historique disponible pour le symbole.
• À partir du terminal, l'historique est copié sous forme comprimée vers l'agent de test. L'agent génère alors des ticks localement ou utilise les données des ticks réels (s'ils sont disponibles).
• Dans les tests multi-devises, lorsque la stratégie accède pour la première fois à un nouveau symbole ou à une nouvelle période, le test est interrompu pendant que les données manquantes sont téléchargées. Le système télécharge également une mémoire tampon supplémentaire de données afin que les indicateurs puissent calculer les valeurs à partir de la toute première barre.

Exigences minimales en matière de données historiques

Pour garantir la stabilité des calculs, le testeur charge toujours une "mémoire tampon de l'historique avant le démarrage" :

• D1 et moins – à partir du début de l'année civile précédente. Cela permet de disposer d'un historique d'au moins 1 an. Exemple : si la date de début du test est le 01/03/2023, le terminal téléchargera depuis le terminal les données depuis le 01/01/2022. Cela équivaut à 14 mois avant le début du test.
• W1 – au moins 100 barres hebdomadaires (~2 ans).
• MN1 – au moins 100 barres mensuelles (~8 ans).

Si l'historique disponible est insuffisant, le testeur avance automatiquement la date de début réelle au point le plus proche répondant aux exigences.

Dans ce cas, les tests commencent plus tard que la date spécifiée par l'utilisateur. Le journal du testeur affichera un message correspondant, par exemple :

Il ne s'agit pas d'une erreur mais d'un mécanisme intégré pour garantir des calculs corrects.

Pour les tests multi-devises, chaque fois que la stratégie accède à un nouveau symbole ou à une nouvelle période, le testeur fait une pause pour charger un historique supplémentaire. Cela comprend également le téléchargement d'une mémoire tampon supplémentaire pour les calculs d'indicateurs et les recalculs de marges.

Le Testeur de Stratégie enregistre l'historique de chaque symbole de manière centralisée, accessible à tous les agents locaux. Exemple (EURUSD) :

L'historique des ticks est stocké de la même manière :

Comment réduire ou éviter le décalage de la date de début des tests ?

Utilisez une période de temps inférieure.

Le testeur a besoin d'au moins 100 barres sur la période sélectionnée avant de commencer la modélisation.

Cela permet de garantir la stabilité des calculs de l'indicateur et une initialisation correcte.

• Si vous effectuez un test sur D1, au moins 100 barres quotidiennes (~5 mois) sont nécessaires.
• Sur H1 ou M15, seules 100 barres horaires ou de 15 minutes sont nécessaires. Cette quantité de données est presque toujours disponible, même si l'historique est limité.
• Par conséquent, lorsque les données historiques sont insuffisantes, le décalage de la date de début est plus faible pour les périodes inférieures que pour les périodes supérieures.

Historique minimum en fonction de la période et du décalage potentiel du début du test

Comment lire le tableau

• Sur D1, le testeur avancera toujours la date de début jusqu'à ce qu'au moins 100 barres quotidiennes soient disponibles.
• Pour H1 ou M15, seuls quelques jours de données sont nécessaires, qui sont généralement disponibles, de sorte que le test commence beaucoup plus près de la date choisie.
• Sur des périodes plus longues (W1 et MN1), le décalage peut être très important, puisque des années d'historique sont nécessaires.

Caractéristiques supplémentaires du Testeur

• Modes de génération des ticks :
  • Every Tick (Chaque Tick) – les ticks sont générés à partir des barres M1, pour un maximum de réalisme. Il s'agit du mode de test le plus gourmand en ressources et en temps.
  • OHLC 1 minute – plus rapide mais moins réaliste. Les séquences de ticks sont construites uniquement à partir des prix OHLC M1. Le nombre de points de contrôle générés est considérablement réduit, ce qui raccourcit la durée du test. La fonction OnTick() est déclenchée à tous les points OHLC.
  • Open Prices Only (Prix d'Ouverture Uniquement) – utilise uniquement les prix d'ouverture des barres sur la période sélectionnée. Très rapide mais moins précis, et nécessite une certaine prudence dans les tests multi-devises. OnTick() n'est appelé qu'au début de chaque barre au prix d'ouverture. Pour cette raison, les niveaux d'arrêt et les ordres en attente peuvent ne pas se déclencher à des prix exacts (en particulier sur les périodes plus élevées). Cependant, ce mode est préférable pour les tests préliminaires rapides d'un Expert Advisor. Il s'agit du type de test le plus rapide et le moins précis.
  • Chaque tick est basé sur des ticks réels – précision maximale. Au lieu de générer des séquences de ticks, le testeur utilise les données des ticks fournies par le courtier. Les barres M1 sont également utilisées en mode tick réel. Les barres sont utilisées pour vérifier et corriger l'historique des ticks. Cela permet également d'éviter les divergences entre le testeur et les graphiques des terminaux en temps réel.

• Temps de la simulation :
  • TimeLocal(), TimeTradeServer() et TimeGMT() renvoient des valeurs identiques lors des tests.

• OnTimer et Sleep :
  • Ces fonctions sont prises en charge pendant les tests. Les minuteurs (timers) ralentissent la simulation, alors que Sleep() simule des pauses (mais les boucles infinies provoquent des erreurs).

Cache des agents et réutilisation

• Les données historiques sont stockées sous forme comprimée et réutilisées si l'intervalle de test et les paramètres restent inchangés.
• Les processus des agents locaux restent actifs pendant environ 5 minutes après la fin d'un test, ce qui permet un démarrage plus rapide des tests suivants.