Backtest Basics
What a backtest is and what to look at: simulate the strategy on historical data, validate performance and risk; covers the building blocks, core metrics, and the workflow.
A backtest runs a configured strategy + execution config through historical K-line data and produces metrics like return, drawdown, and win rate—use it before paper or live to see whether the strategy actually makes money and surface weak spots in parameters and risk control.
A backtest task uses a two-layer structure: task level (exchange, spot / futures, time range, fees, slippage) + per-pair level (each pair's timeframe, initial capital, leverage, strategy, and execution config). One task can include many pairs and they each run independently.
This page covers backtest purpose, key metrics, data requirements, and how to read results; for hands-on configuration and steps see Run Backtest, Create Backtest, Backtest Config.
What is a backtest
A backtest uses historical market data (K-lines, etc.) and runs strategy signals plus the backtest task's execution config (position size, stop-loss / take-profit, scale-in, max drawdown, etc.) along the timeline to simulate buys and sells, then computes the equity curve and return / risk metrics.
Core elements
-
Strategy
A previously-created strategy that carries buy / long and sell / short conditions—decides when to open and when to close on signal. See Strategy Basics. -
Trading pair and timeframe
Which pair (e.g. BTC/USDT) the backtest runs on and which K-line period (e.g. 1H, 4H) it uses—picked per pair when creating the backtest. See Timeframes. -
Execution config (per pair)
Position size, stop-loss, take-profit, scale-in, max drawdown—configured per pair when creating the backtest. See Execution Config, Risk Management. -
Time range, initial capital, fees, slippage (task level)
The backtest's start / end dates (at least 1 month, ideally 3–6), initial capital (e.g. 10000 USDT), fee rate, and slippage—make results closer to live. -
Historical data
The system pulls K-line and other data based on the selected pair, timeframe, and time range; data quality and length affect backtest credibility, so make sure data is accurate and complete.
Why run a backtest
- Validate the strategy: see whether returns, drawdown, and win rate on history sit in an acceptable range.
- Tune parameters: adjust indicator parameters in the strategy, or execution parameters in the backtest task (position, stops, etc.), and compare combinations across backtests; avoid overfitting—see Optimization.
- Assess risk: under the configured risk constraints, observe max drawdown, Sharpe ratio, etc., to estimate the kind of risk you'd see live.
- Spot problems: use the K-line chart and trade-by-trade view of entries / exits to find logic flaws, bad parameters, or market mismatches.
Element overview
A backtest task's elements split into task level (shared by the whole task) and per-pair level (configured independently per pair):
| Element | Layer | Description |
|---|---|---|
| Exchange | Task | Which exchange's historical data to backtest with—Binance, OKX, etc. |
| Market type | Task | Spot / futures |
| Time range | Task | At least 1 month; 3–6 months recommended |
| Fees / slippage | Task | Optional; setting them makes results closer to live cost and more reliable |
| Trading pair | Per pair | E.g. BTC/USDT; one task can hold multiple pairs running independently |
| K-line timeframe | Per pair | Execution main timeframe (1m / 5m / 1H / 4H / 1D, etc.) |
| Initial capital | Per pair | E.g. 10000 USDT |
| Leverage | Per pair | Used in futures |
| Strategy (signals) | Per pair | The strategy bound to this pair (buy / long & sell / short conditions, indicator parameters) |
| Execution config (risk) | Per pair | Position, stop-loss / take-profit, max drawdown, scale-in—the runtime parameters |
For the actual configuration entry points and steps, see Run Backtest, Create Backtest, Backtest Config.
Metrics overview
Once the backtest finishes, the following kinds of metrics are available (the actual fields and formulas come from the system's report):
| Type | Common metrics |
|---|---|
| Return | Total return, annualized return, monthly / period returns, etc. |
| Risk | Max drawdown, volatility, Sharpe ratio, etc. (the backtest runs under the configured risk constraints, so you can use it to estimate live risk) |
| Trading | Trade count, win rate, P/L ratio, average holding time, etc. |
For interpretation and comparison, see Result Analysis. Look across multiple dimensions: don't just look at returns—watch max drawdown, Sharpe ratio, and win rate too; if results are unsatisfactory, tune the strategy or parameters and re-run.
Workflow overview
Prepare the strategy
Have a strategy ready in the Strategy Library (Create Strategy) with buy / long and sell / short conditions and indicator parameters configured.
Create the backtest task (task level)
In Run Backtest, create a new task and fill in exchange, spot / futures, time range (at least 1 month), fees, and slippage.
Add trading pairs (per-pair level)
Add trading pairs to the task one by one. For each pair, pick K-line timeframe, initial capital, and leverage, and bind a strategy plus execution config (position, stop-loss / take-profit, max drawdown, scale-in, etc.). Multiple pairs in the same task are configured independently.
Run the backtest
Once started, the system simulates execution on historical K-lines and produces a report per pair.
Review and iterate
Look at return, max drawdown, win rate, trade count, etc., and use the K-line chart with entry / exit points for analysis. To improve, tune signals or execution config and re-run, or use Optimization for parameter search.
Things to watch out for
- Data quality: make sure historical data is accurate and complete; gaps or errors will skew results.
- Avoid overfitting: don't over-tune parameters to backtest data; pay attention to out-of-sample behavior, and validate across different time windows or instruments.
- Gap with live: live trading has slippage, fees, liquidity, and latency that backtests can't fully reproduce—results are a reference; after a clean backtest, move through paper trading first before going live.
Best practices
- Time range: at least 1 month, ideally 3–6, and try to cover up, down, and sideways regimes.
- Risk consistency: keep the backtest's execution config (stops, targets, position) close to the bot you plan to run live—makes attribution and comparison easier.
- Read it sober: weigh return and risk together rather than only chasing return; watch max drawdown and Sharpe ratio before deciding to move to paper or live.
Common questions
Backtest looked great, live is bad: backtests can't fully reproduce live slippage, fees, and liquidity—set reasonable fees and slippage in the backtest, and validate via paper trading for a period.
How long should the time range be: at least 1 month, 3–6 months recommended; too short means too little sample, too long means earlier data may not represent today's market well.
Where does the risk control in a backtest come from: from the execution config configured per pair when creating the backtest (position, stop-loss, take-profit, max drawdown). Risk control is no longer read from the strategy. See Execution Config, Create Backtest.
Next steps
- Run Backtest — Pick strategy and instrument and run the backtest
- Create Backtest — Create and configure a backtest task
- Backtest Config — Configuration options explained
- Result Analysis — Read the report and metrics
- Optimization — Parameter tuning