52
отвечает за SecurityID, а значение содержит тикер (идентификатор ценной
бумаги). [28]
Чаще всего тело сообщения состоит из заголовка, тела, и трейлера
(завершающего элемента). Первым полем сообщения всегда является
обозначение начала строки (BeginString, тег #8), после этого указывается
полная длина тела сообщения (BodyLength тег #9), затем указывается тип
сообщения (MsgType, тег #35). Завершающим символом трейлера всегда
является контрольная сумма (тег #10). На рисунке 9 приведен пример
сообщение Execution Report посылаемого системой в FIX формате.
Рисунок 8 – Пример сообщение Execution Report в FIX формате
Каждое FIX сообщение состоит из обязательных, необязательных и
условно обязательных полей. Часто сообщения могут содержать как
зашифрованную часть, так и данные в текстовом виде. Теги содержащие
данные в зашифрованном виде чаще всего используются для валидации и
верификации данных. Для обеспечения большей гибкости FIX протокол
содержит пользовательские поля - User Defined Fields, которые используются
при передачи рыночных данных между сотрудничающими компаниями,
организациями. При реализации протокола разработчики той или иной
торговой системы (брокер, биржа, любая другая электронная торговая
53
площадка) имеют возможность добавлять свои дополнительные теги (custom
tags), переопределять значение существующих и роль некоторых
второстепенных тегов, требовать наличия определенных тегов, которые в
спецификации определены как необязательные. В этом случае разработчики
предоставляют свою документацию, в которой описывают особенности своей
реализации FIX протокола, чтобы клиенты могли настроить свои клиентские
программы под эти особенности.
ITCH - direct data-feed protocol - протокол прямого доступа к рыночным
данным, который позволяет подключаться к серверами данных при помощи
TCP (Transmission Control Protocol) и UDP (User Datagram Protocol)
протоколов. ITCH был создан в 90-ые годы, и в свое время был одним из
самых продвинутых протоколов передачи рыночных данных. Этот протокол
используется крупнейшими биржами мира, такими как NASDAQ и LSE.
[17][15]
В ходе торгов на бирже, при совершении любой транзакции всегда
задействуются два типа данных - входящие сообщения и исходящие
сообщения. Для каждого типа сообщения используются свои протоколы.
ITCH протокол относиться к протоколам передачи данных, что
подразумевают передачу данных связанных с приказом, отправленным на
биржу, а также служебные сообщения. Торговые операции протоколом не
поддерживаются.
Таблицы 6 - Сообщение о добавлении обезличенного приказа
Field Offset Length Type Description
Length
0
1
UInt8
Length of message including this
field.
54
Message
Type
1
1
Byte
Hex - 0x41. Meaning - Add Order.
Nanosecond
2
4
UInt32
Nanosecond since last Time message,
accurate to the nearest microsecond.
Order ID
6
8
UInt64
Unique identifier of the order
Side
14
1
Byte
B – Buy Order
S – Sell Order
Quantity
15
4
UInt32
Displayed quantity of the order
Instrument
ID
19
4
UInt32
Instrument identifier
Price
23
8
Price
Limit price of the order
Flags
31
1
Bit Field
Bit – 4
Name – Market Order
Meaning – 0:No, 1:Yes
Тестирование рыночных данных применительно к фондовым биржам
имеет свою яркую специфику. Данные от клиента к бирже, и от биржи к
клиенту должны поступать корректные, в полном объеме, и с минимальной
временной задержкой. В свете скоростей, с которыми происходит торговля,
любая ошибка в передаче данных, за несколько минут, может обернуться
многомиллионными убытками, как для клиентов, так и для фондовой биржи.
Ещё одним нюансом является большая вариативность данных. Одно и
то же сообщение, приходящее по одному и тому же протоколу, может иметь
большое количество вариантов реализации. [17] В большинстве случаев,
вариативность сообщения и поведения системы зависит от настроек
(reference data) выставленных владельцами программного обеспечения
55
фондовой биржи на уровне сервера, уровне шлюза или уровне настроек
системы.
В данном параграфе были рассмотрены протоколы передачи рыночных
данных. Основываясь именно на данных этой главы, в дальнейшем, будут
строиться автоматизация регрессионной библиотеки.
3.2 Пример реализации автоматизированного тестирования
применительно к функциональному тестированию рыночных данных
В компании Exactpro, регрессионное тестирование представляет собой
полное или частичное выполнение тестов с использованием фреймворка
Sailfish. В связи с особенностями архитектуры фреймворка и сложностью
распараллеливания прогона тестов, тестирование происходит в 5-7 потоков и
занимает по времени от 2 до 12 часов. Так же присутствуют тесты, который
тестировщик обязан выполнить руками, т.к. Sailfish не имеет возможность
протестировать некоторые аспекты взаимодействия пользователя с данными
или не имеет доступа для изменения каких либо настроек. Общая пропорция
выглядит таким образом: 70% автоматических тестов, 30% ручных тестов.
Применительно к рыночным данным, многие тесты выполняемые
сотрудником в ручном режиме представляют собой анализ файлов
протоколирования системы с рабочей информацией после закрытия торгов и
выключения системы. Общая логика таких тестов заключается в выполнения
сотрудником каких-либо действий, пока система находится в рабочем
режиме, и анализе информации пришедшей в конце дня (цена закрытия по
инструменту, разнообразные заказы которые были перенесены на
следующий день и т.п.).
56
Рабочая информация представляется в виде файлов с логами. Лог
файлы представляют собой бинарные файлы чтение которых производится
определенными программными продуктами. В случае рыночных данных
предоставляемых биржей, чтение лог файлов будет происходить с
использованием инструмента анализа Shsha.
Представим, что у нас имеется ряд шагов, которые позволяют нам
протестировать какую-либо определенную функциональность:
- запуск автоматических тестов с использование Sailfish
- получение корректных лог файлового
- чтение лог файлов с использованием Shsha
- анализ тестировщиком результата вывода Shsha
Фактически, после определенных действий, у нас есть данные в виде
лог файлов и их нужно сравнить с эталонными данными, которые есть у
тестировщика. Статистика компании Exactpro показывает, что большая часть
ошибок пропускается именно на последнем шаге - анализе логов
тестировщиком. Логично, что возникает идея, переложить анализ логов на
специализированное ПО, что позволит значительно уменьшить возможность
появления ошибки.
Программное обеспечение Sailfish и Shsha написаны на языке
программирования Java. Данный язык широко используется в автоматизации
тестирования. Но при сборе данных о тестироващиках, занимающихся
тестированием рыночных данных, выяснилось, что количество знающих
язык java слишком мало для эффективной работы с тестами написанными на
java, зато язык программирования python, в той или иной степени, был
освоен многими. Плюсом к выбору языка python послужило также то, что все
исполняемые скрипты, которые работают в тестовом окружении (запуск и
57
выключение программного обеспечения биржи, автоматический запуск
Sailfish и т.п.), были написаны с использованием python.
После непродолжительного анализа предустановленного на серверах
программного обеспечения, для автоматизации было решено взять
определенную связку python+pytest+allure+hamcrest:
• pytest - фреймворк для написания тестов, на основе которого
будут писаться тесты. [38]
• hamcrest - фреймворк упрощающий написание различных
сравнений/сопоставлений, будет использоваться для увеличения
вариативности при написании сравнений конкретных данных. [37]
• allure - библиотека для визуализации отчетов, будет
использоваться для удобного анализа тестов и предоставления заказчикам
отчетности по произведенным работам. [36]
Итоговый вариант реализации автоматического регрессионного
тестирования с использованием python представляет собой структуру из
нескольких скриптов. На данный момент, реализовано два варианта
тестирования: первый - когда проводится регрессионное тестирование с
использованием всех тестов всех команд в отдельном тестовом окружении;
второй - когда проводиться регрессионное тестирование отдельной
командой, каких либо конкретных тестов, в своем личном окружении.
58
Рисунок 9 – Блок-схема реализации автоматического регрессионного
тестирования с использованием python
Рассмотрим первый вариант - полного регрессионного тестирования,
системы более подробно. Автоматическое регрессионное тестирование в
Exactpro можно разделить на 2 этапа: прогон тестов в Sailfish и валидация
данных с помощью Python.
1. Прогон тестов в Sailfish. В наличии имеется какое либо тестовое
окружение, на котором установлено программное обеспечение фондовой
биржи (с корректными данными по инструментам и фирмам), Sailfish и
Shsha, python (с нужными библиотеками) и другое сопутствующее ПО. В
строго заданный момент времени, начинается запуск ПО фондовой биржи.
59
Запуск длиться ограниченное время, которое прописано в настройках ПО.
Спустя 20 минут после старта, скрипт запускает тестовый фреймворк. В
Sailfish уже прописан путь к папке с тестами, которые подгружаются в
фреймворк сразу же после его активации. Фреймворк начинает выполнять
тестовую библиотеку в несколько потоков. Все сообщения, которые идут по
всем протоколам, записываются в специальный лог файл. После прогона всей
тестовой библиотеки Sailfish генерирует общий отчет по всем тестам,
который будет доступен в виде html. (см. приложение Б)
2. Валидация данных с помощью Python. Как только наступает триггер
(выключение ПО фондовой биржи после прогона тестовой библиотеки),
отдельным скриптом выполняется запуск Shsha (консольный вариант). В
настройках Shsha заранее прописано откуда программа должна брать лог
файлы. После запуска Shsha считывает лог файлы и загружает их в базу
данных. Следующим шагом в скрипте подается команда на запуск тестов
реконселяции (с англ. reconciliation - сверка). Тесты выполняются
относительно базы данных, в которой находиться вся информация из лог
файла. Обращение к базе данных происходит посредством SQL запросов. [2]
После выполнения реконселяционных тестов, с помощью python библиотеки
Allure, формируется отчет, в виде html. (см. приложение В)
Как было сказано в предыдущей главе все регрессионное тестирование
в Exactpro можно разделить на 2 этапа. Реализация тестов в Sailfish уже была
ранее автоматизирована и вся программная часть была настроена. Оставалось
только реализовать и настроить второй шаг - пост валидацию данных с
помощью Python.
На основе написанных, за время прохождения практики тестов, в
команде, которая тестирует рыночные данные, были созданы шаблоны для
дальнейшего создания реконселяционных тестов.
60
С учетом, того что многие работники в команде тестировщиков, имеют
малый опыт программирования на каком либо языке, был выбран вариант с
блочной структурой. Под блочной структурой подразумевается, какой либо
шаблон теста, который имеет строго типизированные блоки и работа, с
которым заключается в минимальных изменениях конкретных блоков под
определенные тесты.
В итоговом варианте примерный шаблон теста имел вид:
1. Блок импорта - происходит импортирование нужных для работы python
скрипта библиотек и классов
2. Блок определения - определяется категория и подкатегория теста, его
название, вносится краткое описание теста
3. Блок запроса к базе данных - происходит запрос к базе данных для
получения нужной нам информации
4. Блок валидации данных - валидация полученных данных
61
Рисунок 10 - Пример валидации сообщения Symbol Directory
Разберем каждый блок теста немного подробнее.
1. Блок импорта. В первых строчках скрипта происходит
импортирование нужных нам библиотек pytest, allure, hamcrest.[36][37][38]
MyTest - подключение к базе данных вынесено в отдельный метод класса.
Counting_value - часто используемое сравнение тоже вынесено в отдельный
класс.