Protocollo di test della strategia — backtest e forward test

Questo protocollo compilabile ti accompagna dall'ipotesi e dalle regole congelate ai risultati e alla decisione su ulteriori test. Compila le sezioni 1–5 prima del test e le sezioni 6–8 dopo. Conserva un'esportazione di ogni versione insieme ai dati e ai risultati, affinché lo studio possa essere riprodotto.

Protocollo di test della strategia — flusso di backtest e forward test

Il modulo non esegue backtest e non si collega a un broker. Documenta test svolti nell'ambiente scelto. Le versioni polacca e inglese usano lo stesso schema JSON, versione 1, e gli stessi 22 campi. I contenuti dei campi vengono trasferiti senza traduzione. Questa versione accetta file fino a 2.000.000 di byte, come l'importatore PL aggiornato. Conserva intatti i backup più grandi e aprili in una versione aggiornata: non cancellare registrazioni dello studio per rientrare nel limite di 600.000 byte di una precedente versione EN.

Per prima cosa salva ed esporta le sezioni 1–5. Dopo lo studio aggiungi i risultati nelle sezioni 6–8, conservando la copia precedente. Tutti i campi sono descrittivi: il modulo non valuta la validità dell'ipotesi e non verifica le metriche inserite. Ogni campo contiene fino a 12.000 caratteri secondo il conteggio del browser (alcuni simboli occupano due unità). JSON serve per la reimportazione; TXT e stampe per la lettura. Il pulsante di importazione non può caricare dati da file TXT o PDF.

Il salvataggio si esegue tramite il pulsante e rimane in questo browser, separatamente per ogni versione linguistica. Non è automatico e non è sincronizzato tra dispositivi; chi usa lo stesso profilo del browser può leggere i dati. La cancellazione dei dati del sito lo elimina. L'esportazione JSON consente di conservare un backup o trasferire il documento. Il modulo non invia i dati inseriti a un server.

1. Ipotesi e ambito

Descrivi il meccanismo che dovrebbe produrre un vantaggio e le condizioni in cui prevedi che scompaia. Definisci mercato, timeframe e sessione prima di esaminare i risultati. Usa lo stesso identificativo dello studio nel piano, nei file di dati e nel diario.

Per esempio, FX-TEST-001; iniziali; data di inizio.
Che cosa dovrebbe funzionare, perché e quale risultato osservabile contraddice l'ipotesi?
Elenca simboli, specifiche degli strumenti, timeframe del segnale e dell'esecuzione e orari.
2. Regole congelate e versione

Le regole devono consentire di riprodurre ogni decisione. Dire semplicemente «entrare su un breakout» non basta: registra fonte dei prezzi, momento della decisione e metodo di esecuzione. Conserva una copia delle regole o del codice precedente al test. Una modifica dopo aver visto il risultato crea una nuova versione; non migliora la valutazione storica di quella precedente.

Versione, data con UTC o scostamento, nome del file / commit / checksum; software di test, sua versione e impostazioni di randomizzazione, se applicabili.
Condizione, momento in cui i dati diventano disponibili, tipo di ordine, SL, TP, uscita temporale, gap e tocchi simultanei di SL/TP.
Dimensione della posizione, esposizioni combinate, limiti, costi massimi, pubblicazioni, dati mancanti e ingressi vietati.
3. Dati, tempo e costi

Registra fonte e copertura dei dati e indica se rappresentano prezzi bid, ask o mid. Adegua la risoluzione alle regole di esecuzione. Non trattare un valore futuro di un indicatore o una revisione successiva di un dato pubblicato come informazione disponibile al momento del segnale. Una barra che comprende sia SL sia TP richiede una regola esplicita per determinare l'esito oppure dati più dettagliati.

Fornitore, data del download, copertura, risoluzione, bid/ask/mid, lacune e metodo di validazione; identificativo o checksum della copia dei dati conservata e descrizione della pulizia dei dati.
Timestamp UTC; fuso orario del server di origine; sessione, per esempio Europe/London con GMT/BST; regola dell'ora legale.
Spread, commissioni, swap, slippage, conversione valutaria e fonti delle ipotesi; registra ciò che è già incluso nel prezzo di esecuzione.
Suddivisione dei dati in-sample e out-of-sample e architettura del forward test
Suddivisione dei dati in-sample e out-of-sample e architettura del forward test
4. Suddivisione del campione e piano di forward test

Separa il campione usato per sviluppare le regole (in-sample, IS) da quello usato per valutarle (out-of-sample, OOS). Registra date e metodo di suddivisione. Esaminare ripetutamente l'OOS e adattarvi le regole ne compromette l'indipendenza. Esegui il forward test su dati che arrivano dopo il congelamento delle regole, documentando tutti i segnali e le omissioni; un ambiente demo non riproduce completamente l'esecuzione su un conto reale.

Date IS; elenco di prove, filtri e parametri, compresi quelli scartati; metodo di selezione.
Date OOS; cronologia della suddivisione; regole per le posizioni che attraversano il confine e per il riscaldamento degli indicatori. Non contare la stessa operazione su entrambi i lati; i dati di riscaldamento possono provenire dal passato, ma non devono introdurre informazioni future nelle regole.
Inizio, ambiente demo/paper, versione delle regole, data di revisione, orizzonte e numero di osservazioni con motivazione; se terminare a una data o a un numero di operazioni e cosa fare se il campione è più piccolo. Registra anche le sessioni senza segnali.
5. Criteri registrati prima dei test

Definisci le metriche e la regola decisionale prima di vedere il risultato. Nessun singolo numero di operazioni o soglia di profit factor conferma un vantaggio per ogni strategia. Lunghezza del campione, dipendenza tra osservazioni, eventi rari e numero di varianti testate influenzano l'interpretazione. Separa i criteri di valutazione della strategia dai controlli sulla corretta esecuzione del test. Decidi in anticipo come considerare incertezza e dipendenza tra risultati e quando terminare lo studio. Non fermare il test al primo risultato favorevole e non prolungarlo fino alla soglia desiderata; queste decisioni richiedono un metodo pianificato di valutazione sequenziale oppure il riconoscimento esplicito che l'analisi successiva è esplorativa.

Aspettativa netta in R; definizione di R e dell'unità operazione; PF in R o in valuta (specificare); drawdown con relativa serie, unità e punto di partenza; numero di osservazioni, costi, dispersione e metodo di valutazione dell'incertezza.

Per coerenza con il diario F, definisci l'R-multiple di un'operazione come il risultato netto diviso per l'importo di rischio positivo pianificato prima dell'ingresso. La somma di questi R-multiple con importi di rischio variabili non è il risultato espresso nell'R base del piano. La curva R cumulata parte da 0; il drawdown è la discesa dal massimo precedente, quindi una perdita iniziale di −1 R produce un drawdown di 1 R. Per equity o saldo, specifica capitale iniziale, flussi di cassa e trattamento delle posizioni aperte: non iniziare un calcolo percentuale da capitale zero. PF senza perdite ha denominatore zero: indicalo come non definito, anziché considerarlo una conferma del vantaggio. Considera le uscite parziali usando un'unica definizione documentata di operazione.

I tuoi criteri: continuare i test / raccogliere dati / rifiutare l'ipotesi. Che cosa significa un risultato inconcludente?
Variazioni dei costi, sottoperiodi, parametri vicini; condizioni di interruzione per errori nei dati o nella procedura.
6. Risultati e scostamenti

Registra separatamente i risultati di IS, OOS e forward test. Includi il numero di segnali, operazioni ed esclusioni, con le motivazioni. Conserva il percorso dei risultati, non solo il totale. I risultati netti conteggiano i costi una sola volta: se spread e slippage sono già riflessi nei prezzi di esecuzione, non sottrarli di nuovo. Indica i dati mancanti come mancanti, non come zero.

Date, numero di osservazioni, metriche, dispersione, file dei risultati e limiti.
Le stesse metriche e unità dell'IS; confronto con i criteri registrati in anticipo.
Risultati, segnali omessi, differenze di esecuzione, interruzioni e relativo effetto sulla confrontabilità.
7. Registro delle modifiche

Distingui la correzione di un errore di implementazione da una modifica dell'idea. In entrambi i casi conserva il risultato precedente e identifica i dati già visti. Non sovrascrivere la vecchia versione del protocollo quando cambi le regole. Un'esportazione documenta lo stato a un dato momento; il file o il salvataggio locale da soli non costituiscono una prova indipendente della data di congelamento.

Una modifica per voce: che cosa è cambiato, perché e quali risultati erano già noti.
Quali risultati devono essere ricalcolati? Come valuterai la modifica senza usare lo stesso campione come nuovo OOS?
Protocollo decisionale per la valutazione oggettiva della strategia
Protocollo decisionale per la valutazione oggettiva della strategia
8. Conclusione e ulteriori test

Confronta il risultato con i criteri della sezione 5. Registra sia le evidenze a sostegno dell'ipotesi sia i fatti che la contraddicono. La conclusione «servono più dati» richiede un piano concreto. Questo documento organizza lo studio; non autorizza il trading con denaro reale e non garantisce risultati futuri.

Continuare i test / rivedere l'ipotesi / rifiutare / inconcludente; identifica evidenze e limiti.
Quali dati o test, chi svolgerà il lavoro e quando verrà riesaminato?

Esempio: stesso risultato, conclusioni diverse

Esempio illustrativo: supponi che la versione 1.0 abbia prodotto +8 R nell'OOS. Se, dopo aver esaminato quel campione, escludi due sessioni in perdita e presenti +12 R come «conferma indipendente», stai mescolando sviluppo delle regole e valutazione. Registra il nuovo filtro come versione 1.1, conserva il risultato di +8 R e identifica i dati già visti. La differenza di +4 R deriva qui dalla rimozione di sessioni con un risultato complessivo di −4 R, non da nuove osservazioni. Il risultato di +12 R descrive la nuova variante adattata a un campione noto; per valutarla in modo indipendente serve un ulteriore test correttamente pianificato.

Fonti e ambito della verifica

  • Bailey, Borwein, López de Prado, Zhu, The Probability of Backtest Overfitting, versione di febbraio 2015: selezionare ripetutamente varianti sugli stessi dati può gonfiare la valutazione di una strategia. Lo studio sostiene la registrazione dei tentativi; non stabilisce una soglia universale del numero di operazioni per questo modulo.
  • MDN — localStorage: ambito dello spazio di archiviazione del browser e possibilità di accesso negato. Un backup JSON è indipendente dal salvataggio locale del sito.

Fonti verificate il 21 settembre 2026. I capitoli collegati 15.4 e 15.9 approfondiscono le definizioni delle metriche e la procedura di studio; il modulo registra contenuti, non calcola un vantaggio.

Jarosław Wasiński

Caporedattore, ForexMechanics.com • Analista macro e FX

Analista indipendente e professionista con oltre 20 anni di esperienza nei mercati finanziari. Attivo nel Forex dal 2004, con un focus sull'analisi fondamentale, la struttura del mercato OTC e la gestione disciplinata del rischio di capitale.

  • Fondatore e caporedattore di MyBank.pl, che offre formazione finanziaria affidabile dal 2004.
  • Autore di centinaia di commenti di mercato approfonditi, analisi strutturali e materiali didattici per trader e investitori.
  • Sostenitore della trasparenza del mercato, promuovendo una formazione basata su dati concreti e report istituzionali (BIS, ESMA, CFTC).

Tutti i contenuti hanno carattere esclusivamente didattico e informativo – non costituiscono consulenza di investimento né alcuna raccomandazione. Ricorda: il trading con leva (Forex/CFD) comporta un elevato rischio di rapida perdita del capitale.