что такое тестовый контур
Что такое «тестовый контур» и откуда взялось это словосочетание?
Иногда приходится слышать выражение «тестовый контур» (в контексте какой-либо тестовой программной среды). Интересна история происхождения этого выражения. Википедия по этому вопросу хранит молчание и гугл тоже.
UPD (перенесено из комментариев): довольно много народа употребляет данный термин и никто не может внятно объяснить откуда он взялся. Тем не менее, наверняка у этого «устойчивого выражения» интересная история
2 ответа 2
Однозначной терминологии в данном вопросе не существует. Контур может оказаться средой или окружением, вместо теста и продакта официальная документация может ссылаться на контур опытной эксплуатации и контур промышленной эксплуатации.
На терминологию влияет и процесс разработки, которые практикует команда или целая организация. Обычно все программисты разрабатывают и тестируют код на своих компьютерах и имеют всё необходимое окружение для этого, например, локальные версии MySQL, Redis или MongoDB. Если разработка ведётся через Docker, то необходимые сервера запускаются в контейнерах локально.
Этот контур может называться локальным или персональным. Его хватает проверить, что программист, кажется, написал всё так, как предполагалось. Там можно прогнать модульные и интеграционные тесты.
Когда задача завершена программистом, он отправляет код в общий репозиторий, из которого собирается версия проекта, которая на жаргоне называется дев (development). Этот контур позволяет проверить, что программисты ничего не сломали друг у друга, он достаточно нестабилен. Здесь выполняются автоматизированные интеграционные тесты.
Когда программисты считают, что код можно отдавать на тестирование, они переносят изменения на тестовые контур, где можно прогонять ручные тесты. Здесь возникают тонкости, связанные с тем, что тестирование бывает очень разным, например, нагрузочным. Для нагрузочных тестов обычно создают свой собственный контур.
Когда всё готово, проверенная версия попадает на прод (production), он же контур промышленной эксплуатации.
Что такое контур или среда физически? Зависит от средства разработки и от технологий. Часто это Docker-контейнеры, которые разворачиваются на нескольких виртуальных машинах. Для каждого контура мы создаём несколько виртуалок, и запускаем там очередную версию кода.
Если вы работаете в Azure, вы можете сделать несколько серверов БД, каждый для своего окружения. Такие ресурсы можно сгруппировать, назвав группы dev, test и prod.
Если проект разрабатывается давно, и туда уже невозможно внедрить контейнерную разработку, под каждый контур системные администраторы могут выделить несколько разных физических серверов, управляя ими вручную. Трудоёмки, но такие контуры тоже встречаются, потому что некоторые проекты существуют по 15-20 лет.
Как QA в управлении хранилища данных эволюционировал. Часть 2
В предыдущей статье я описал проблемы, с которыми мы столкнулись в самом начале становления QA-процессов в нашем хранилище, а также первые шаги по их исправлению. В этой статье расскажу, как мы справлялись с оставшимися проблемами, какие инструменты использовали и какие у нас планы.
Проблемы прошлого
Для начала вспомним, какие же проблемы остались актуальными:
Ручной сбор пакета разработчиками.
Ручное ревью пакета.
Необходимость в синхронизации продуктового и тестового контуров.
Недоступность операций над метаинформацией при возникновении очереди.
Отдельный контур для тестирования интеграции.
Кроме того, из последней проблемы вытекает тот факт, что целых три тестовых контура используются в текущем flow.
Три тестовых контура (vial, live и test)
Я уже писал про vial и live — серверы для проведения модульного и регрессионного тестирования ETL-процессов. Они позволили отделить эти виды тестов, но старый test-контур при этом никуда не делся и использовался для интеграционного тестирования пакета, уже прошедшего модульное тестирование на vial. Кроме того, ряд задач невозможно было протестировать на vial в силу различных обстоятельств, и с ними по-прежнему работали на test.
Было: все тестирование на одном контуре.
Стало: модульное и интеграционное тестирование, а также регресс разнесены по разным контурам.
Распределение этапов тестирования между контурами
тестовых контуров стало больше;
test по-прежнему использовался.
Зачем нужен test?
Во-первых, test был нужен для проведения интеграционного тестирования. Успешное прохождение модульного тестирования не означало, что пакет полностью корректен и никак не сломает остальные объекты хранилища. Например, разработчик мог, скажем, поправить длину какого-то поля в таблице и в метаинформации, и на этапе модульного тестирования это никак бы не отразилось, а зависимый ETL-процесс мог быть завязан на старое значение и при изменениях падал. Это можно отловить только при интеграционном тестировании.
Во-вторых, ряд задач просто нельзя было на тот момент тестировать на vial по разным причинам. Например, бэкапы для некоторых таблиц нельзя (или очень проблематично) было перенести на vial с prod. Поэтому их тестировали на test.
Хорошо, с важностью и необходимостью test’а разобрались.
А в чем были проблемы с test при текущем flow с тремя тестовыми контурами?
Оказывается, проблем было несколько:
необходимость синхронизаций с продом;
О синхронизации уже говорили, поэтому рассмотрим две оставшиеся проблемы.
При совместном использовании теста многими QA-инженерами время от времени возникали конфликты метаинформации и/или физических данных из-за одновременного использования в разных задачах одинаковых объектов. В этом случае нужен был откат задач и согласование порядка работы с объектами (порядка наката и тестирования).
При этом могла возникнуть ситуация, что из-за нехватки места на тестовом контуре или из-за ошибки были удалены бэкапы по задаче. В этом случае тестовое окружение на test-контуре было сломано, и все исправить могла только синхронизация. То есть мы получали много рисков и проблем.
Давайте рассмотрим решения проблем при помощи наших разработок, и начнем с проблемы ручного сбора пакетов.
Текущие реалии
Мы шаг за шагом улучшали наши процессы и создавали новые инструменты, развивая их. Постепенно переходили к автоматизации. Остановимся на этом подробнее.
Составляющие автоматизации
Про авторелиз уже рассказали в предыдущей статье, поэтому рассмотрим остальные составляющие.
Портал автоматизации
Консольная утилита автонаката задач на разные контуры была очень полезной, но мы не зацикливались на ней, да и, что называется, аппетит приходит во время еды.
Через некоторое время в работу был введен портал автоматизации — это наше внутреннее веб-приложение, которое помогает разработчикам, QA-инженерам, ревьюверам и ребятам, выполняющим релизы задач, вести свою работу с пакетами в одном месте.
Отображение пакета на портале автоматизации
Какие функции предоставляет портал автоматизации?
Автоматический сбор пакета.
Накаты задач на все контуры.
Большой пул работ с метаинформацией.
На портале автоматизации у разработчика появилась возможность собрать свой пакет автоматически. Причем, если задача не содержит специфических объектов и действий, на лету создается пакет с типовым содержимым и сценарием. А если сценарий по данной задаче содержит специфические действия, то на портале есть функционал создания сложного сценария работы с объектами хранилища данных и наката.
А еще у нас появилась загадочная сущность — автотестер, решающая задачи автоматического создания тестовых окружений.
Автотестер
Итак, автотестер — это совокупность нескольких демонов, создающих готовые vial-окружения без каких-либо ручных действий со стороны сотрудников.
Автотестер запускает накаты задач ежедневно в 20:30, поскольку в это время нагрузка на тестовый контур резко снижается и работы автотестера никак не будут блокировать работу сотрудников. Он берет все задачи, которые успешно прошли ревью и по которым в Jira указан уровень тестирования «автоматическое». Такой уровень тестирования проставляется у всех задач, для которых не предполагаются ручные действия во время наката. А далее запускает процесс создания пробирок.
Автотестер создает чат с разработчиком и QA и в случае возникновения ошибок окружения (моргнула база, кончилось место или же в самом пакете вылезли ошибки, которые не были выявлены на ревью) отправляет туда лог ошибки.
Пример slack-канала и сообщения об ошибке в нем
После успешного переноса задачи на vial запускаются автотесты и сравнения текущих и предыдущих версий целевых таблиц, а также чекеры целостности данных. Результаты всех этих проверок автотестер отправляет в тот же slack-канал.
Результаты автопроверок в slack-канале
С появлением авторелиза, а затем и портала автоматизации перенакаты задач перестали требовать множества ручных действий! Это стало огромным стимулом для дальнейшего развития наших процессов и инфраструктуры.
Авторевью
Давайте вспомним, какие проблемы были при проведении ревью вручную:
занимает много времени;
невозможно отследить глазами выполнение абсолютно всех требований.
Меню запуска ревью на портале автоматизации
Большое количество проверок было просто вынесено в отдельный сервис, который запускается для проверки созданного пакета и выдает свой вердикт о его качестве. Далее ревьюверу остается проверить логи с результатами авторевью и самые критичные требования к объектам из задачи. То есть ревью стало двухфакторным и проходит гораздо быстрее.
Например, на этапе авторевью можно быстро отловить использование в ETL-процессах хардкода вместо макропеременных или же увидеть, что ETL-процесс работает очень долго, поэтому необходимо его оптимизировать.
Рассмотрим основные категории проверок в рамках ревью.
Meta-review
Работа с метаданными объектов хранилища осуществляется в SAS Data Integration Studio. Метаданные физически хранятся на SAS-сервере и представляют собой таблицы атрибутов и таблицу связей — их используем для автоматизации. После внесения разработчиком изменений в метаданные, происходит запрос на SAS-сервер по объектам, которые были затронуты доработкой.
По названию объектов выстраиваются связи и находятся необходимые для анализа атрибуты в виде таблиц, которые, в свою очередь, подвергаются проверкам на предмет соответствия стандартам разработки. Под стандартами разработки в данном случае можно понимать соответствие объектов внутренним соглашениям по разработке, особенности работы с GP, особенности работы связанных систем. В результате работы авторевью пользователь получает отчет со списком выявленных проблем.
Package-review
Результат разработки — опубликованный в VCS релиз-пакет, который содержит в себе все файлы, необходимые для установки задачи, а также файлы, свидетельствующие о корректности разработки.
Package-review запускается для проверки наполнения релиз-пакета. Проверяется наличие всех необходимых файлов, соответствие конфига и содержания пакета, корректность создания или изменения физической структуры объектов, производится парсинг скриптов, сопоставление объектов, дорабатываемых в скриптах, с объектами метаданных. В результате работы package-review пользователь получает отчет со списком объектов релиз-пакета, не прошедших проверки, и рекомендации по устранению проблем.
Diff-review
Запускает python-скрипт, выполняющий сравнение деплоев джобов до и после разработки и создающий diff-файлы.
Log-review
Выполняет проверку логов в пакете.
Автотесты
На крупных проектах в целях автоматизации тестирования пишутся собственные тестовые фреймворки, и наш проект не исключение. На связке python + pytest создан наш тестовый фреймворк, позволяющий:
Запускать автотесты на всех объектах по задаче.
Выполнять часть тестовых проверок на лету, запуская самописные тестовые функции.
Формировать итоговый отчет с результатами тестирования в Allure.
У запуска автотестов есть особенность: их перечень зависит от объектов тестовой задачи. Например, при создании нескольких абсолютно новых ETL-процессов интеграционные проверки запускаться не будут, поскольку в хранилище еще нет никаких зависимостей от этих процессов. И наоборот: при доработке существующих процессов будут запускаться интеграционные проверки.
Какие виды тестов во фреймворке существуют?
Static — включают проверки хардкода, корректности метаинформации и настроек инкрементальной загрузки ETL-процесса.
BI — проверяют зависимости в SAP BO юниверсах.
Интеграционные тесты — проверяют возможные ошибки в зависимых ETL-процессах хранилища и в важных отчетах.
Work — проверяют что корректно отработала инкрементальная загрузка новых/измененных данных из источников, обновились данные и так далее.
Интеграционное тестирование
В этом направлении мы совершили огромный прорыв и очень им гордимся.
Итак, интеграционное тестирование прошло следующие этапы:
Ручной запуск всех зависимых процессов на тестовом контуре.
Вынесение части проверок в авточекер и выполнение их автоматически.
Расширение перечня автопроверок и переход к накату на тест только метаинформации.
Апогеем этой эволюционной лестницы стал полный отказ от интеграционного контура. Почему это удалось?
Вместо инстанса тестового контура для подтягивания всех зависимостей стали использовать специальную платформу MG (наша внутренняя разработка), содержащую метаданные хранилища, а также описывающую логическую и концептуальную модели хранилища.
Интеграционные тесты стали отрабатывать уже во время наката задачи на vial, то есть на более раннем этапе мы можем посмотреть на итоги интеграционных проверок и обнаружить ошибки.
Так мы победили ненавистные синхронизации и избавились от теста, тем самым чуть разгрузили тестовый контур (привет нашим DB-админам и спасибо им за терпение), сделали тестовое окружение более доступным — нет больше потерянных дней тестирования из-за проблем с синхронизацией.
Попутно были достигнуты следующие результаты:
Влияние человеческого фактора на итоги интеграционного тестирования уменьшилось в разы.
Время интеграционного тестирования сократилось на 80—90%.
Качество самих интеграционных проверок улучшилось за счет максимально актуальных данных.
Качество проверок улучшилось, потому что на тесте не всегда были актуальные данные, да и зависимости в BI и важных стратегических отчетах ранее мы не могли проверить, а с приходом автоматизации это стало реальным.
Выполнение проверок на лету
Кроме автотестов, написанных на python, мы также используем набор самописных SQL-функций, позволяющих быстро и эффективно проводить самые важные проверки качества данных.
Какие функции у нас есть?
ddl(‘имя_таблицы’) — возвращает DDL-скрипт создания таблицы, используемый для проверки корректности метаинформации и соответствия ее ТЗ.
profile(‘имя_таблицы’) — сводный отчет наполняемости таблицы (насколько заполнено каждое поле таблицы, какие уникальные значения есть в различных полях и т. д.).
dq_check(‘имя_таблицы’, ‘ключ’) — позволяет определить, сколько дублей и NULL есть в ключевых полях таблицы, а также выявить проблемы версионности.
compare_(‘таблица1’, ‘таблица2’, ‘ключ’) — самый основной инструмент, выдающий результаты сравнения двух таблиц.
Compare() показывает, сколько столбцов и строк в каждой таблице, сколько строк сджойнилось и в каких столбцах были обнаружены расхождения для сджойненных записей.
Ниже показано, что все записи из первой и второй таблицы (12 987 767 234 строки) сджойнились, но по полю order_id были обнаружены расхождения в 9 458 234 строках.
Пример результата функции compare()
Если такое расхождение и предполагалось получить в результате доработки ETL-процесса — все хорошо, если же оно неожиданно — это повод для обсуждения с аналитиком и разработчиком.
При помощи функций compare() выполняются сравнения с прототипом и бэкапом. Они позволяют сравнить: полностью все таблицы, только актуальные версии записей или же отдельные партиции (для больших партицированных таблиц).
Тест-кейсы в Allure
В Allure тест-кейсы создаются автоматически и динамически, отталкиваясь от особенностей проверяемых объектов, так же, как тесты, о которых я писал выше. Кроме того, ряд проверок выполняется на лету в процессе наката задачи на vial, а их результаты сразу записываются в тест-кейсы.
Пополнение базы автотестов
Наша база автотестов постоянно расширяется, в том числе за счет обнаруженных при тестировании дефектов. У нас выстроен процесс заведения и анализа багов с дальнейшим созданием задач как на написание автотестов, так и на добавление проверок в авторевью. Дефекты для удобства анализа и получения статистики делятся на несколько категорий: на каком этапе процесс дал сбой, какие объекты были с дефектом и т. д.
Разработка собственных допсервисов
Помимо написания самих автотестов наша команда разрабатывает различные сервисы на python, поддерживающие общую QA-инфраструктуру и позволяющие сделать процесс автоматизации более гибким, удобным и прозрачным.
Разработка
Ранее в статье я упомянул проблему блокировки всех пользователей при выполнении операций с метаинформацией. Все такие операции выстраивались в очередь, и пока очередь не опустеет — пользователи с метой работать не смогут.
Эта проблема затрагивала не только QA-инженеров, но и самих разработчиков. И для ее решения было предложено использовать отдельные метасерверы. На них с помощью плейбуков разработчики готовят окружение, разрабатывают свои задачи и проводят первичную проверку результата.
Далее задача отправляется согласно установленному flow.
Проблемы на данном этапе
Из оставшихся проблем были решены:
Необходимость в синхронизации продуктового и тестового контуров — отпала после перехода на vial и автоматизацию интеграционного тестирования.
Ручное ревью пакета — решено после введения авторевью. Полностью избавиться от ручного ревью не получится, но механизм авторевью значительно разгрузил сотрудников.
Имеется целых три тестовых контура — теперь для тестирования используется только связка vial/live, причем live — лишь для некоторых задач.
Для тестирования интеграции требуется отдельный контур — контур больше не используется.
Недоступность операций с метаинформацией при возникновении очереди (изначально выделена не была, но по ходу статьи упоминалась) — к сожалению, пока не решена.
Таким образом, из списка проблем, которые упоминались в самом начале статьи и добавлялись по ходу, осталась нерешенной только одна — блокировка меты при одновременной работе.
Но разработчики уже решили эту проблему в своем окружении, а в планах — решить ее и применительно к QA.
Дорога к светлому будущему
Мы уже многое сделали для улучшения нашей работы, но нам еще многое предстоит.
Будущее — прекрасное далеко
Какие же наши основные задачи?
Переход авторевью в разработку и поддержку на стороне QA.
Тестовые контуры переходят в зону ответственности QA — в команду QA нанимается SRE.
Тестирование на отдельных метасерверах.
Разработка новых сервисов автоматизации.
Тестирование на отдельных метасерверах позволит избавить от зависаний меты на vial, но не все сразу. Впрочем, мы обязательно это сделаем.
А что касается новых сервисов автоматизации, то сейчас мы занимаемся написанием статистического анализатора результата регресса, анализатора корректности эталонного SQL-кода (этот код поддерживает в актуальном состоянии системный аналитик), на основе которого разработчики создают ETL-процессы, а также автоматизацией тестирования инкрементальной загрузки.
Заключение
Непрерывное улучшение качества продуктов, данных и процессов очень важно для нашей группы компаний. И на примере управления хранилища данных была показана эволюция QA в срезе автоматизации процессов и инструментов.
Шаг за шагом мы двигались в сторону автоматизации, целью было уменьшение количества ручных действий в процессах и фокусирование внимания сотрудников на анализе ошибок, сложных кейсах тестирования и повышении собственной экспертизы.
В самом начале своего пути мы делали вручную практически все: от разворачивания тестового окружения и до интеграционного тестирования. Но со временем на каждом этапе процесса появлялась возможность ускорить работу и повысить ее эффективность за счет использования новых инструментов.
Слаженная работа команд разработки и тестирования в DWH позволила уверенно двигаться в сторону автоматизации, и со временем процессы внутри управления кардинально поменялись.
Вот что было сделано:
Автоматизировано большое количество действий, выполняющихся ранее вручную: сбор пакетов, накат/откат задач, ревью, большая часть тестов и т. д.
Разработаны внутренние сервисы для ускорения и повышения эффективности работы с хранилищем: портал автоматизации, авторевью, автотесты и т. д.
Процессы непрерывно улучшаются за счет пополнения базы тестов, повышения стабильность автотестов.
Результаты показывают, что наша экспертиза позволяет нам и дальше двигаться в сторону повышения эффективности рабочих процессов.
Кроме того, QA наращивают техническую экспертизу за счет расширения обязанностей, взятия на себя все большего числа сервисов в поддержку и разработку. У нас много планов, и мы их обязательно реализуем. А о результатах расскажем в новых статьях.
Спасибо, заходите почитать про наше хранилище!
Что такое тестовый контур
Дата публикации 13.11.2020
Использован релиз 11.4.13
Возможности тестового контура
При работе в тестовом контуре можно протестировать:
Ограничение : нельзя протестировать передачу маркируемых товаров по ЭДО.
Порядок подключения к тестовому контуру ЦРПТ
Для подключения к тестовому контуру необходимо иметь (получить) действующую электронную подпись руководителя предприятия.
На компьютере, где планируется работа необходимо установить программу-криптопровайдер и установить сертификат электронной подписи.
В браузере необходимо установить плагин для работы криптопровайдера. Порядок настройки электронной подписи и криптоправайдера описан здесь.
Далее необходимо зарегистрироваться в личном кабинете тестового контура. Регистрация в личном кабинете тестового контура аналогична регистрации в рабочем контуре.
Описание продукции в национальном каталоге тестового контура
Маркируемая продукция должна быть описана в национальном каталоге. Это можно сделать используя сервис 1С:Номенклатура в тестовом режиме (подробнее) или непосредственно в личном кабинете «Честного знака» в разделе национальный каталог (рис. 1), следуя инструкции.
При описании через сервис 1С:Номенклатура GTIN будет сформирвоан автоматически, однако автоматически в базе пользователя он не прописывается. Это сделано намеренно, чтобы не засорять базу пользователя тестовыми штрихкодами. Модерация на тестовом контуре национального каталога осуществляется только по письменному запросу в поддержку ЦРПТ.
Для опиания в личном кабинете нужен корректный, но не используемый в реальной маркировке код GTIN. Например, можно взять код, который начинается не с цифр «46», с упаковки (этикетки) от личных вещей, которые уже выведены из продажи.
В любом случае карточка товара поступет на моерацию и нужно написать в поддержку ЦРПТ запрос на добавление товара в национальный каталог в тестовом контуре (рис. 2).
Состояние модерации можно отследить в списке товаров. После публикации этих товаров можно будет заказывать коды маркировки с указанием этого GTIN.
Настройка программы для работы с тестовым контуром ЦРПТ
Порядок настройки на примере ERP описан здесь на ИТС.
Также рекомендуем ознакомиться с видео по подключению к тестовому контуру ГИС МТ.