На что обратить внимание при тестировании мод файла
Обновлено: 04.07.2024
Вы, как создатель своего продукта или услуги, понимаете как он работает, какие связи между процессами и чего хотят клиенты. Поэтому при тестировании хорошо определяете ошибки и недочеты.
Конечно, ваши возможности ограничены — как знаниями и навыками, так и техническим оснащением. Вы не сможете проверить работу приложения на разных устройствах или его безопасность, наличие ошибки в коде. Но вам подвластно проверить, как работает функционал и какие упущения во внешнем виде, удобство приложения.
Сценарии тестирования
Ваша задача — встать на место пользователя и пройти его путь от входа в приложение до закрытия, при этом выполнить все действия, которые ему доступны. В ходе прохождения выявить проблемы, с которыми пользователь не должен сталкиваться, или найти изъяны в дизайне, которые водят его в заблуждение. В профессиональной среде такие сценарии называются «функциональное тестирование» и «тестирование удобства пользования». Для каждого мы написали принципы и основные моменты, на которые нужно обратить внимание.
Функциональное тестирование
Обязательно нужно тестировать приложение на пограничных состояниях.Мы разработали веб-приложение для сервиса грузоперевозок Shustrikoff. Стоимость доставки зависит от удаленности от центра города, поэтому при тестировании проверяли адреса на границе Казани и другого района. Также можно проверить заявки в разных районах города, заказ назначенный на границе дневного и ночного тарифа и т.п.
Тестирование удобства пользования
- Как обозначены обязательные и необязательные поля для заполнения? Можно ли их отличить друг от друга?
- Понятно ли, как действовать дальше и куда нажимать? Если вы всматриваетесь в экран в поисках следующего шага или кнопки, зафиксируйте этот момент. Интерфейс должен быть интуитивно понятен, вести пользователя по конкретному маршруту в назначенную точку. Важную роль в этом играют как расположение элементов на экране, так и их стиль.
- Можно ли продолжить работу в приложении после того как свернул и обратно развернул его? Не выкидывает ли пользователя?
- Цвет кнопок с одинаковой функцией совпадает.
- Как воспринимается текст на экране: заголовок заметнее всех, шрифт не напрягает, текст читается легко, смысл понятен, поля учтены.
- Звук в приложении: что с ним происходит и как он звучит в разных состояниях приложения. Например, как работает приложение, когда подключена гарнитура или включается сторонний проигрыватель либо при сворачивании приложения.
- Сколько времени и шагов понадобилось для завершения основных задач приложения? Можно ли упростить этот путь?
Оформляем и передаем информацию разработчикам
Включаем режим «бюрократии», потому что правильно оформленная ошибка сэкономит вам и разработчикам часы работы.
Представьте: разработчики не будут уточнять детали каждой ошибки, переспрашивать, для разъяснений не понадобятся эти звонки по телефону, которые мало кто любит (Привет миллениалам!). В ваших отношениях с командой будет процветать гармония и полное взаимопонимание.
- Дайте название ошибке. Будет легче ориентироваться по списку и в разговоре с командой.
- Опишите ошибку. Что конкретно не так? Как задумывалось и должно быть?
- Приложите скриншот или запись экрана, если ошибка происходит при конкретной последовательности действий.
- Какая версия: десктоп или мобильная?
- Какая платформа: iOS или Android?
- Какой браузер и какая версия браузера?
- Дайте подробный путь к странице/экрану с ошибкой.
Скорее всего команда уже использует определенный сервис для работы с задачами, где и собирает всю информацию по приложению. Поэтому они могут дать внешний доступ, чтобы вы в этом же пространстве вносили информацию по результатам своего тестирования. Собирайте все в единой структуре в одном месте.
В этой статье мы рассмотрим тестирование веб приложений и сайтов. Она довольно длинная, поэтому усаживайтесь по удобнее.
Основные виды тестирования сайта (веб-приложения)
- Тестирование функциональности;
- Тестирование удобства использования;
- Тестирование интерфейса;
- Тестирование совместимости;
- Тестирование производительности и скорости загрузки сайта;
- Тестирование безопасности.
Тестирование функциональности
Проверьте все ссылки, присутствующие на веб-странице, а также ссылки на базы данных, формы, используемые для подтверждения действий и получения информации от пользователей, файлы Cookie и т.д.
Проверьте все ссылки
- Проверьте ссылки, исходящие от всех страниц к конкретному домену.
- Внутренние ссылки.
- Ссылки на другие элементы, расположенные внутри страниц.
- Ссылки для отправления электронной почты администратору или другим пользователям веб-страниц.
- Проверьте, нет ли ссылок на изолированные страницы.
Проверьте формы
Формы используются для получения информации от пользователей и взаимодействия с ними.
Что нужно проверить в формах:
- Правильность работы валидации в каждом поле формы.
- Значения полей, используемые по умолчанию.
- Опции для создания форм, удаления, просмотра и редактирования форм ( если такие имеются ).
Рассмотрим пример проекта поисковой системы, над которым я сейчас работаю. В проекте есть этапы регистрации рекламодателей и партнеров. Каждый шаг регистрации отличается от других, но зависит от остальных этапов. Поэтому весь процесс регистрации должен проходить правильно.
Есть различные виды валидации, например, проверка электронной почты, финансовой информации пользователя и т.д. Все поля с валидацией нужно протестировать в ручном или автоматическом режиме.
Тестирование файлов cookie
Проверьте, шифруются ли Cookie перед записью на компьютере. Протестируйте сеансы регистрации и статистику пользователя, когда сеанс посещения сайта закончится. Проверьте, влияет ли на безопасность приложения удаление файлов cookie .
Проверьте HTML/CSS
Если вы оптимизируете сайт для поисковых систем, то валидация HTML/CSS особенно важна. Первым делом проверьте сайт на наличие синтаксических ошибок в HTML-коде . Проверьте, доступен ли сайт для различных поисковых систем.
Тестирование базы данных
Взаимодействие веб-приложения с базой данных является очень важным моментом. Проверьте целостность данных и проведите тестирование сайта на наличие ошибок при редактировании, удалении, изменении форм или других действиях, имеющих отношение к базе данных.
Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.
При тестировании функциональности сайтов нужно проверить:
Ссылки
- Внутренние ссылки;
- Внешние ссылки;
- Ссылки на электронную почту;
- Битые ссылки.
Формы
База данных
Следует проверить целостность базы данных.
Тестирование удобства использования (юзабилити сайта)
Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.
При этом проверяется:
- Легкость обучения;
- Навигация;
- Субъективная удовлетворенность пользователей;
- Общий вид.
Проверка навигации
Под навигацией подразумеваются средства для просмотра страниц пользователем. Это кнопки, блоки. А также то, как посетитель сайта использует ссылки на другие страницы.
- Сайт должен быть простым в использовании;
- Инструкции должны быть очень четкими;
- Проверьте, достигают ли предоставленные инструкции поставленной цели;
- Главное меню должно быть доступно на каждой странице;
- Главное меню должно быть построено в логической последовательности.
Проверка контента
Контент должен быть логичным и простым для понимания. Проверьте текст на наличие ошибок. Применение темных цветов раздражает пользователей, не нужно использовать их в теме оформления.
Для контента и фона страницы лучше применять общепринятые стандарты, чтобы цвет шрифта, рамок и т.д. не раздражал пользователей.
Контент должен быть содержательным, ссылки работать надлежащим образом, изображения соответствующего размера. Это основные стандарты, соблюдаемые при веб-разработке. Ваша задача — проверить все в рамках тестирования пользовательского интерфейса.
Другая информация для пользователей
Варианты поиска, карта сайта, справочные материалы и т.д. Проверьте работу всех ссылок в карте сайта. Функция « Поиск по сайту » должна помогать легко находить нужный контент.
Тестирование пользовательского интерфейса
Нужно проверить, правильно ли осуществляется связь с сервером. Следует проверить совместимость сервера с используемым программным обеспечением, аппаратными средствами, сетью и базой данных.
- Интерфейсы веб-сервера и приложения.
- Интерфейсы сервера базы данных и сервера приложения.
Проверьте, что происходит, когда пользователь прерывает какое-либо действие. А также, что происходит при повторном подключении к серверу в ходе выполнения какой-либо операции.
Проверка совместимости
- Совместимость с браузерами;
- Совместимость с операционными системами;
- Просмотр на мобильных устройствах;
- Параметры печати.
Совместимость с браузерами
Работа некоторых веб-приложений зависит от типа браузера. Сайт должен быть совместим с различной конфигурацией и параметрами разнообразных браузеров.
Верстка сайта должна быть кроссбраузерной. При использовании Java-скриптов и AJAX , обеспечивающего функциональность пользовательского интерфейса, проверки безопасности или валидации создают большую нагрузку на систему.
Проверьте работу веб-приложения в браузерах Internet Explorer , Firefox , Netscape Navigator , AOL , Safari , Opera разных версий.
Совместимость с операционными системами
Некоторые функции веб-приложения могут быть несовместимы с определенными операционными системами. Не во всех из них поддерживаются новые технологии, используемые в веб-разработке. Поэтому проверьте работу приложения в Windows , Unix , MAC , Linux , Solaris и их различных версиях.
Просмотр на мобильных устройствах
Проведите тестирование сайта на мобильных устройствах и проверьте, как просматриваются веб-страницы с помощью мобильных браузеров. Проблемы с совместимостью также могут возникнуть из-за мобильных устройств. Также не стоит забывать о тестировании сайта на разных разрешениях.
Параметры печати
Тестирование производительности сайта
Тестирование производительности сайта или веб-приложения должно включать в себя:
- Нагрузочное тестирование.
- Стрессовое тестирование.
Проверьте производительность приложения на различной скорости интернета.
Нагрузочное тестирование сайта ( веб-приложения ) — это тестирование, при котором большое количество пользователей одновременно выполняют запрос к одной и той же странице. Выдерживает ли система пиковые нагрузки?
Стрессовое тестирование — нагрузка системы, выходящая за пределы установленных лимитов. Стрессовое тестирование выполняется с целью достичь сбоя в работе сайта или веб-приложения путем увеличения нагрузки. А также проверить, как система реагирует на стресс, и как она восстанавливается после сбоев. Стрессовой нагрузке подвергают поля для ввода информации, входа и регистрации.
ab тестирование функциональности также включает в себя проверку на ошибки, связанные с оперативной памяти.
Тест производительности можно применять для проверки масштабируемости сайта или оценки продуктивности при использовании стороннего программного обеспечения.
Скорость соединения
Сплит тестирование сайта при использовании различных вариантов интернет-соединения: через модем, ISDN и т.д.
Нагрузка
- Количество пользователей, одновременно посещающих сайт;
- Проверьте работу системы при пиковых нагрузках;
- Пользователь осуществляет доступ к большому количеству данных.
Стрессовая нагрузка
- Непрерывная нагрузка;
- Производительность памяти, процессора, обработки файлов и т. д.
Тестирование безопасности
Ниже приведены некоторые наборы для тестирования веб-безопасности:
Основной причиной тестирования безопасности сайта является поиск потенциальных уязвимостей и их последующее устранение.
- Сетевое сканирование;
- Сканирование уязвимостей;
- Возможность потенциального взлома паролей;
- Обзор журнала;
- Средства для проверки целостности;
- Обнаружение вирусов.
Моменты, которые следует учитывать при тестировании сайта
Следует обратить внимание на взаимодействие HTML-страниц , интернет-подключение, брандмауэры, приложения, запускаемые на веб-страницах ( апплеты, JavaScript , модульные приложения ), а также приложения, работающие на стороне сервера ( скрипты CGI , интерфейсы баз данных, генераторы динамических веб-страниц ).
Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.
Пример сценариев тестирования сайта
Дополнительные факторы, которые следует учесть при тестировании сайта:
- Какова ожидаемая нагрузка на сервер ( например, количество запросов за единицу времени )?
- Какая производительность требуется при различных видах нагрузки ( время ответа веб-сервера, время отклика базы данных на запрос )?
- Какие инструменты потребуются для тестирования производительности?
- Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
- Какую производительность ожидает получить клиент ( насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск )?
- Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
- Какие средства безопасности требуются ( файерволы, шифрование, пароли и т.д. ), и какую работу они будут выполнять? Как их можно проверять?
- Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
- Как будет выполняться управление обновлением контента сайта?
- Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
- Какая спецификация HTML будет соблюдаться? Насколько точно?
- Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
- Как будет происходить управление и проверка CGI апплетов, сценариев JavaScript , компонентов ActiveX и т.д.?
- Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
- Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
- Отображение веб-страниц должно быть независимо от типа браузера.
- На каждой странице следует указать ссылку для связи.
Пожалуйста, опубликуйте ваши отзывы по текущей теме статьи. За комментарии, отклики, дизлайки, лайки, подписки огромное вам спасибо!
Дайте знать, что вы думаете по этой теме материала в комментариях. За комментарии, подписки, дизлайки, отклики, лайки огромное вам спасибо!
Сразу оговорюсь, всё нижеописанное почерпнуто мною исключительно из своего небольшого по объёму затраченного времени (но большого по количеству авралов, злоключений и прочих баттхёртов) опыта. Оговорка номер до: эти принципы применимы только к мобильному ПО. Как там у других — я не знаю и гадать не хочу. И последнее, пожалуй, самое важное. Данные принципы лишь задают направление, а потому будут полезны в основном новичкам (хотя вы, конечно, можете написать о бесполезности сей статьи в комментариях).
Итак, когда я только начинал заниматься тестированием, прочитал доступную теорию, начальник начал второе собеседование с простого вопроса – в чём особенность мобильного тестирования по отношению к другим видам тестирования? Тогда я лишь приблизительно смог ответить на этот вопрос. Сейчас я выделяю для себя следующие принципы:
Принцип 1: Постоянная мобильность
Главное отличие мобильного от десктопного ПО заключается в том, что с айфоном вы передвигаетесь, тщетно ловите вайфай в столовых ваших вузов (совершая характерные движения руками), бегаете и вообще по максимуму загружаете все возможные сенсоры движений, что китайские умельцы встроили в него. Забывать об этом смерти подобно. Кто-то может сказать, что глупо бегать по офису, меняя ориентации экрана и теряя-восстанавливая коннект. На это у меня есть 2 контр-примера из жизни:
- Крэш в приложении при попытке восстановить приложение из бэкграунда с предварительной сменой ориентации экрана;
- Крэш в приложении при “потряхивании” девайса в момент совершения этим девайсом фотосъёмки (приложение изначально создавалось для создания фото).
Принцип 2: Ловля вай-фая на живца
Большая часть современных приложений, так или иначе, использует сеть. Далеко не всегда это “полный коннект”. Поэтому обязательно необходимо тестировать приложение как минимум 4-мя способами:
- Позитивный кейс (наличие отличной постоянной связи);
- Наличие постоянной неотличной связи;
- Отсутствие связи;
- Потеря связи.
Принцип 3: Прерывания
По-хорошему, этот принцип должен стоять во главе всего списка. Ведь прерывания наносят самый существенный вред приложению, при этом являясь одним из основополагающих принципов самих мобильных систем. Во время использования вашего приложения, пользователь может
- Неожиданно получить звонок (смс, напоминание, нотификацию и т.д.);
- Закрыть приложение для того, чтобы открыть какое-то другое на некоторое время и вернуться к вашему приложению позже;
- Послать девайс в сон на некоторое время.
Принцип 4: Особенности операционных систем и железа
Данный принцип находится тут с явной натяжкой, но всё же, я считаю, что ОС и железо, установленное в мобильных устройствах, сказывается на производительности ПО намного сильнее, чем в десктопах. Почему?
- Андроид и ЯблокоОсь существенно отличаются от десктопных систем. Активности (и их стэк), интенты, броадкаст ресиверы, манифест файл (с указанием permissions и user features), доступ к ресурсам, кэш и данные приложений – всё это и многое другое нужно хотя бы бегло изучить для того, чтобы понимать, как ваше приложение работает в данной конкретной среде, что может привести к его (приложения) отказу или потере данных. Отсюда вытекает тестирование перехода между состояниями, тестирование для нахождения утечек памяти и прочее. Всё это необходимо для полноценного обеспечения качества приложения.
- Прогресс не стоит на месте, но железо смартфонов всё ещё сильно ограничено по сравнению с настольными системами. Особенно важно то, сколько ваше приложение занимает оперативной памяти, при каких условиях система автоматически “выпилит” его из этой самой памяти, как приложение будет себя вести в этой ситуации.
Принцип 5: Человеческий фактор
Если приложение рассчитано на широкую аудиторию, будьте готовы к тому, что куча людей, бесконечно далёких от разработки ПО, будет вести себя совершенно по-разному с вашим приложением. Тут важно понимать, что мы не можем просчитать все возможные случаи использования приложения всеми криворукими пользователями. Но проверить, что приложение корректно выполняет весь свой функционал на основных юз-кейсах мы обязаны. Неплохо также обезопасить себя, пробежавшись по приложению в качестве пользователя-дурачка, тыкая во всё подряд, открывая и закрывая активности, не дожидаясь загрузки данных и т.д. Проблема с “замыленным глазом” решается путём привлечения в процесс ваших девушек, друзей и родственников. Просто дайте им приложение в руки и посмотрите, как они будут им пользоваться. Это даст вам примерную (насколько примерную зависит, конечно, от величины выборки) картину того, что следует тестировать в первую очередь и на что обратить внимание.
Вместо заключения
Конечно, в определённой степени эта подборка принципов субъективна и спорна и, возможно данная статья покажется надуманной или некорректной (как мне, так и вам). С другой стороны, я надеюсь, что статья всё же окажется полезной и поможет вам конкретизировать и не забывать вещи, наиболее важные при тестировании мобильных приложений. Ну и напоследок хотелось бы обменяться опытом:
В условиях современного трейдинга использование в торговле форекс советников уже давно не выглядит какой-то экзотикой. Практически каждый день появляются новые платные и бесплатные торговые роботы, которые впечатляют доходностью и вызывают желание быстренько заработать. Однако, ставить эксперта на торговый счет без проверки – сомнительная затея, ведущая к «неожиданным» потерям в потенциале. Поэтому рекомендуем начать работу с роботом с тестирования.
Все, что нужно знать о том, как правильно тестировать торгового советника в тестере стратегий терминала MetaTrader 4 – в инструкции от экспертов журнала Фортрейдер.
С чего необходимо начинать тестирование советника?
Торговый робот проверяют на истории, поэтому в первую очередь необходимо скачать котировки нужной вам валютной пары. Для этого следует в меню «Сервис» найти вкладку «Архив котировок» или просто нажать клавишу F2.
Рис. 1. Архив котировок в меню «Сервис» терминала MetaTrader 4.
Далее выбираем необходимую валютную пару и таймфрейм, кликаем по ним два раза левой кнопкой мышки и нажимаем «Загрузить».
Рис. 2. Выбор валютной пары и таймфрейма.
Обратите внимание, что качество истории котировок у разных форекс брокеров отличаются, что может вызвать серьезные расхождения в результатах тестирования одного советника на счетах от разных брокеров.
Выбираем в тестере стратегий торгового робота (1), валютную пару (2), тип моделирования (3), таймфрейм (4), спред (5) и настройки советника (6).
Рис. 3. Настройка тестера стратегий для тестирования.
Не забудьте о размере спреда, который установлен для валютной пары вашим брокером. Дело в том, что в тестере стратегий по умолчанию установлен текущий спред. Если вы этого не сделаете, то можете получить совершенно фантастические результаты, особенно, если тестируете эксперта в выходной день.
Какой тип моделирования выбрать?
Тестер стратегий предлагает на выбор три типа моделирования:
- Все тики;
- Контрольные точки;
- По ценам открытия.
«Все тики» — самый точный из стандартно-доступных типов моделирования, но он же и самый долгий. Некоторые советники можно тестировать без потери точности по контрольным точкам или по ценам открытия. Для этого в алгоритме должны быть заложены условия открытия сделки, начиная с нового бара.
Если вы не сильно разбираетесь в советнике, который тестируете, то имеет смысл подойти к вопросу экспериментальным путем. Тестируете по всем тикам, потом по контрольным точкам, потом по ценам открытия и смотрите разницу. Если она небольшая, то можно оптимизировать советник наиболее быстрым методом, а потом проверять по всем тикам. Если разница существенная, то можно грубую оптимизацию проводить быстрым методом, а тонкую — по всем тикам. Если разница совсем большая, то делать нечего, и придется оптимизировать долго и упорно по всем тикам.
Есть класс советников, в которых рабочий таймфрем прописан в настройках, у них результаты тестирования не зависят от выбранного периода в тестере. Такие роботы, как правило, можно тестировать практически без потери точности на контрольных точках. Получается намного быстрее, чем по всем тикам, а результат практически тот же самый.
Опять-таки, оптимизируем быстрым методом, найденный лучший вариант проверяем по всем тикам и убеждаемся, что все в порядке.
На какие параметры нужно обратить внимание при оптимизации советника?
Количество сделок
В первую очередь обращаем внимание на количество сделок. Желательно, чтобы их было не менее 150, иначе оптимизация теряет всякий смысл, поскольку возникает эффект «подгонки» результатов.
Если же сделок меньше 150, то необходимо увеличить промежуток времени тестирования, чтобы получить полную картину.
Прибыль и просадка
Во вторую очередь нас будет интересовать соотношение прибыли к просадке.
Популярным параметром для отбора результатов оптимизации является коэффициент восстановления, который представляет собой простое отношение: прибыль / максимальная просадка. Его несложно вычислить, поделив столбец «Прибыль» на столбец «Просадка» в долларах. Но вот отсортировать результаты оптимизации по этому параметру тестер так просто не позволяет.
double GetRecoveryFactor( void )
double MaxDD = TesterStatistics(STAT_EQUITY_DD);
Res = TesterStatistics(STAT_PROFIT) / MaxDD;
double OnTester( void )
и перекомпилировать его. После этого при оптимизации в тестере появится новая колонка «Результат OnTester». Она будет содержать коэффициент восстановления. Щелкнув по шапке этой колонки, можно отсортировать результаты оптимизации по данному параметру.
Рис. 4. Сортировка результатов оптимизации по коэффициенту восстановления.
Что делать с ошибками рассогласования?
Часто случается, что в отчете о тестировании торгового эксперта тестер стратегий в строке «Качество моделирования» указывает значение n/a и сообщает об ошибках рассогласования графиков.
Рис. 5. Ошибки рассогласования графиков.
Откуда берутся эти ошибки? Самой распространенной причиной является расхождение между котировками, которые получены от брокера напрямую, и котировками, загруженными из архива.
Рис. 6. Удаление файла с архивом котировок.
После удаления файлов перезапускаем терминал и загружаем котировки заново, как это было описано выше.
После проделанных процедур в большинстве случаев ошибки рассогласования графиков исчезают, а качество моделирования вырастет до 90%.
Итого
Таким образом, тестирование и оптимизация торговых советников – дело совсем несложное, хотя требует больших временных затрат и знания тонкостей. Надеемся, что эта статья позволит вам быть с тестером стратегий «на ты», эффективно тестировать форекс экспертов и получать прибыль на валютном рынке.
Похожие статьи
Комментарии (2)
А ничего что котировки после удаления будут загружены с сервера метаквот и будут очень сильно отличаться от данных полученных от брокера и после перезалива этот тестер можно смело выкинуть в ведро? вы этот момент почему-то упускаете.
Здравствуйте! Спасибо Вам за информацию о тиковом тестировании робота. Но у меня вопрос такого плана. Если я скачаю тики из архива котировок MQL4 и провожу тестирование в таймфрейме H1(часовом), то не будет ли отличаться время открытия бара от серверного времени брокера? Мне это важно знать, так как открытие ордера в моём роботе привязано ко времени открытия бара и со временем начала торговых сессий.
Заранее благодарен, если получу от Вас разъяснение по моему вопросу.
PS: может у Вас есть описание кода, который можно будет внести в тело советника для устранения проблемы, если она, конечно, существует.
Всем привет! Механические торговые системы так же стары, как и рынки. С развитием в 20 веке компьютерных технологий и сети интернет стало возможным торговать не выходя из дома, а в начале 21 века, с появлением платформы MetaTrader, еще и в автоматическом режиме. Ресурсы современного настольного компьютера позволяют воплощать в жизнь любые, даже самые сложные алгоритмы, а встроенный в терминал MetaTrader редактор MetaEditor дает возможность написать робота даже человеку, мало знакомому с программированием. В результате околофорексовый рынок заполнен различными предложениями купить чудо-советники и некоторые из них действительно достойны внимания. Но как же понять, стоит ли применять на реальных счетах тот или иной форекс советник? Сегодня я расскажу, как тестировать торгового робота на исторических данных при помощи программы MetaTrader 4.
Подготовка к тестированию
Мы не будем сегодня разбирать, как установить советник в терминал – для этого есть соответствующая статья в блоге. Будем считать, что советник мы уже установили. Теперь необходимо подумать о котировках, которые вы будете использовать. Большинство брокеров не имеют собственной исторической базы, исключение составляют Alpari и Ducascopy, остальные же используют котировки, предоставляемые компанией MetaQuotes. Сказать, что эти котировки вообще годятся для тестов я не берусь – они очень низкого качества (много пробелов, ошибок и неточностей). Как скачивать котировки от компании Ducascopy – тема отдельной статьи, к тому же это не так просто сделать новичку. Поэтому для тестов советников мы скачаем именно терминал от компании Alpari. Внимание! Чтобы получить доступ к исторической базе котировок Альпари, в терминале вы должны быть подключены именно к реальному счету! С недавних пор этот брокер не предоставляет свою базу котировок для владельцев демо-счетов.
Именно из-за различий в котировках тесты одного и того же советника по одной и той же паре с теми же настройками и при прочих равных скорее всего будут отличаться, иногда очень сильно.
Для начала нам нужно кое-что настроить, для чего идем во вкладку Сервис -> Настройки или жмем Ctrl+O
Появится окно с настройками терминала:
Выбираем вкладку «Графики» и в графах «Макс. баров истории» и «Макс. баров в окне» и заполняем как у меня на рисунке вверху (по умолчанию там стоит 65000 баров).
Для того, чтобы котировки по нужной нам паре стали доступны в терминале для проведения по ним теста, открываем вкладку Сервис -> Архив котировок или жмем F2.
Открывается следующее окно:
Тестер терминала. Основной функционал
Итак, чтобы приступить к тестированию советника открываем тестер стратегий или нажимаем Ctrl+R.
Снизу в терминале появится вот такая панель:
Давайте остановимся на каждой функции поподробнее.
Первое, что вы увидите слева вверху панели – переключатель советник-индикатор:
В новых билдах терминала появилась возможность посмотреть на работу индикатора в визуальном режиме (о котором речь пойдет ниже). Надо сказать, что такая возможность была и раньше, но неофициально. Теперь же под тестирование индикаторов отведена отдельная кнопочка.
Итак, выбираем советник.
Далее правой кнопкой мыши кликните прямо в окне навигатора и нажмите «Показать все символы»:
На пункте 3 остановимся немного подробнее. Тут мы можем выбрать необходимую нам модель тестирования. Для качественного тестирования торговой стратегии важно выбрать адекватный способ моделирования развития ценовых баров. Всего доступны три варианта:
Метод моделирования контрольных точек предназначен для грубой оценки экспертов, торгующих внутри бара. Для этого метода необходимо наличие исторических данных ближайшего меньшего таймфрейма. В некоторых случаях имеющиеся данные меньшего таймфрейма не полностью покрывают временной диапазон тестируемого таймфрейма. При отсутствии данных меньшего таймфрейма развитие бара генерируется на основе предопределенных волновых шаблонов.
Как только появляются исторические данные меньшего таймфрейма, интерполяция применяется уже к этим данным. Однако точно существующие цены OHLC меньшего таймфрейма выступают в качестве контрольных точек. В большинстве случаев результаты тестирования экспертов по методу контрольных точек могут приниматься во внимание только как оценочные, а не как окончательные. Такие результаты имеют промежуточный оценочный характер.
При тестировании по всем тикам объём сгенерированных тиков может быть довольно большим, поэтому терминал может потреблять довольно много ресурсов.
Для тестирования советника всегда выбираем метод все тики. Да, это самый медленный, но и самый надежный метод. Многие применяют в своих советниках контроль закрытия бара, то есть специально выжидают момент открытия новой свечи и открытие ордеров совершается только в этот момент. Но часто советники используют стопы, тейки, тралы, которые могут сработать в любой момент внутри свечи. Применять метод по ценам открытия можно только для советников, которые не используют трейлинг стоп, стоплосс и тейк профит, а открывают и закрывают позиции в момент открытия новой свечи, а таких советников крайне мало.
Пункт 4 – использовать дату. Ставим галочку и выбираем желаемые даты начала и окончания тестирования. Если галочка не проставлена, тестирование проводится по всей истории котировок, загруженных в терминал. Тестер не сможет провести тестирование на периоде, по которому нет котировок в архиве котировок, то есть вы не сможете сделать тест с 1300 года, если у вас нет котировок за этот период.
Пункт 5 – визуализация, о которой мы поговорим позже.
Настройки на панели тестера справа:
Период – выбор периода для тестирования советника. Доступны периоды вплоть до D1. W1 и MN1 недоступны для тестирования. Кроме того, если у вас не загружена история котировок нужного периода, тест вы выполнить не сможете.
Спред – можно задать любое значение или же использовать текущий спред по паре. Сделано это для удобства – например, по ночам и на выходных текущий спред обычно завышен и если вы тестируете советник в это время есть смысл задать спред вручную. Если у вас выбран текущий спред, результаты тестов могут сильно отличаться в зависимости от времени суток и дня недели, особенно при тестировании по всем тикам.
Кнопка «Изменить эксперта» доступна только если у вас есть исходный код советника (файл с расширением mq4). Она открывает редактор кода советника, где вы сможете внести в советник необходимые изменения.
Кнопка «Открыть график» открывает график с нанесенными на него индикаторами и сделками, совершенными советником во время теста (нажать можно после того, как тест выполнен).
Кнопка «Свойства символа»
Поменять здесь ничего нельзя, это просто справочная информация по используемой валютной паре.
Кнопка «Свойства эксперта»
Тут вы можете ввести используемый для теста депозит и валюту депозита. Также при желании можно выбрать направление сделок, например разрешить эксперту торговать только в покупки или только в продажи. Настройки оптимизации в рамках данной статьи рассматриваться не будут. Также как и вкладки «Оптимизация».
Тут находятся все управляющие переменные самого эксперта, его настройки. Кстати, окно масштабируемо – если вы потянете мышкой за нижний правый угол, можно увеличить или уменьшить его в размерах. Вместе с экспертами как правило обычно поставляются файлы с настройками, имеющие расширение *.set. Причем чаще всего для каждой пары свой файл с настройкой. Чтобы загрузить правильные настройки для нужной пары нажимаем кнопку «Загрузить» и выбираем нужный файл. Часто после установки эксперта в терминал они оказываются не в нужной папке. После нажатия на кнопку «Загрузить» мы оказываемся в папке тестера (у меня это C:UsersSilentspecAppDataRoamingMetaQuotesTerminalFE03BE71CD8F9E8F4C70E0FDAFC997E5 ester). Если нужных файлов там не оказалось, идем в папку FE03BE71CD8F9E8F4C70E0FDAFC997E5MQL4Presets, скорее всего файлы там. Итак, выбираем и загружаем нужный настроечный файл. После загрузки нам нужно найти параметры манименеджмента советника и выставить фиксированный лот 0.1 – в этом случае каждый доллар прибыли или убытка будет равен 1 старому пункту. Для чего это – я расскажу ниже.
Тестирование советника. Результаты теста
Теперь у нас все готово для теста. Проверьте еще раз настройки и нажимайте кнопку «Старт». Спустя некоторое время тест будет выполнен, о чем нас известит звуковой сигнал, похожий на издаваемый резиновой детской игрушкой с пищалкой.
Настало время взглянуть в нижний левый угол тестера:
Тут мы можем заметить вкладки «Настройки», «Результаты», «График», «Отчет» и «Журнал».
Во вкладке «Результаты» доступен список всех сделок, совершенных советником за время теста.
На вкладке «График» можно полюбоваться кривой доходности советника.
Если советник не совершил ни одной сделки, стоит заглянуть во вкладку «Журнал». В ней вы найдете описание всего, что случилось во время теста. Вполне вероятно, что в советнике какая-нибудь ошибка. Расшифровку номера ошибки можно посмотреть в разделе Коды ошибок.
Во вкладке «Отчет» доступна вся статистика работы эксперта на выбранном отрезке времени:
Панелька с сигнализатором качества котировок (у меня она зеленая, поэтому для примера нашел в интернете):
Серым цветом – отсутствующие котировки, красным – котировки только текущего периода, зеленым – котировки доступны и предыдущих периодов, при этом чем ярче зеленый цвет, тем более младшие периоды доступны. При доступности периода М1 индикатор будет как у меня – ярко зеленый.
Начальный депозит – депозит, с которым проводилось тестирование.
Спред – спред, с которым проводилось тестирование.
Общая прибыль – сколько всего было заработано во время работы советника
Общий убыток – сколько всего было потеряно.
На следующем рисунке цифрами показаны основные стадии изменения величины максимальной просадки в процессе тестирования. Итоговое значение максимальной просадки выделено утолщенными стрелками.
Относительная просадка показывает отношение максимальной просадки к значению соответствующего локального верхнего экстремума.
Думаю, остальные данные теста, такие как средняя прибыльная сделка, максимальное количество непрерывных проигрышей и так далее, вполне понятны и объяснения тут не нужны.
Если кликнуть по отчету правой кнопкой мышки, можно сохранить этот отчет в виде html файла:
Сверху отчета располагаются основные данные об условиях проведения теста – период, валютная пара, модель тестирования, параметры советника и прочее. Ниже – статистические данные теста и график кривой доходности. Далее в виде таблицы следует список всех совершенных сделок.
Режим визуализации
Этот режим обеспечивает возможность буквально увидеть в ускоренном режиме как в прошлом отработал бы советник при тех изменениях котировок, которые имели место. Например, если сигналы на вход и выход советника основаны на сигналах какого-нибудь индикатора, то на график визуализации можно установить нужный индикатор и тогда появление сделок и закрытие сделок будет еще нагляднее.
Другими словами, визуализация помогает понять и прочувствовать логику алгоритма советника, так как все будет происходить у вас перед глазами.
Кроме того, визуализацию также применяют, когда хотят увидеть природу происхождения какого-нибудь конкретного участка в прохождении советника (момент начала слива или же, наоборот, самого профитного периода).
Прогнав робота в режиме визуализации вы можете понять принцип его работы и будете знать, чего можно ожидать от него в будущем. Это очень полезный инструмент, особенно для разработчиков советников.
Заключение
В этой статье был рассмотрен основной функционал тестера стратегий терминала MetaTrader 4 и особенности закачки котировок. Также мы познакомились с результатами теста советника и визуальным режимом тестирования. Хочу обратить внимание, что это лишь основы работы с советниками. Способ тестирования советника, рассмотренный в статье, подойдет для советников на периодах от Н1 и выше. Для скальперов, работающих на более мелких периодах, такой способ тестирования подходит условно, он носит чисто информативный характер. Если вы собрались зарабатывать при помощи советников, необходимо также освоить оптимизацию советников. Также нелишним будет получить более глубокие знания о тестировании и оптимизации советников с более высоким качеством моделирования, недоступным, к сожалению, в стандартном исполнении терминала.
Читайте также: