Тестовый контур 1с это
Наша команда разрабатывает модуль интеграции EDI для 1С.
Изначально обработка должна была выполнять 4 действия:
Проблемы предметной области
Почти в каждом IT-проекте встречаются совершенно очевидные предположения, которые разбиваются о суровую реальность. Мне очень нравится пример с именами.
Чем же нас порадовал российский EDI?
Проблемы кода
Изначально весь код обработки был хорошо структурирован, а проблем командной разработки не существовало по причине отсутствия команды. Но в ходе развития каждая из описанных выше ситуаций требовала решения, причем, как обычно для разработки на 1С, срочного. Постепенно набрали команду (в том числе меня).
За плечами у нас были франчи, ИТ-отделы компаний разных масштабов, фриланс. Каждый работал в одиночку, как это обычно и бывает с 1С-никами.
Когда-то стройный код стал обрастать костылями. Методы - непонятными параметрами, о назначении которых мы стали забывать. Тексты запросов становились все запутаннее, они собирались динамически в зависимости от десятков условий, закопанных где-то глубоко. Отладка усложнялась, а количество багов стало плавно, но уверенно расти. Как и их сложность: порой одна ошибка обходилась нам в несколько человекочасов только на ее локализацию. А исправление иногда только усложняло исходный алгоритм.
Общее владение кодом падало.
Параллельно мы развивали версию для конфигураций на управляемых формах. Ее код мы частично скопировали из обработки на ОФ, но дальше развивали независимо. Изменения базовой функциональности (например, работы с API сервиса) приходилось вручную переносить из одной обработки в другую и адаптировать.
Кроме того, у нас иногда появлялись клиенты с полностью самописными конфигурациями. Адаптировать модуль под такие разработки было тяжело: один из разработчиков полностью уходил в эту задачу на 2-3 для, потом еще в течение недели (или больше) занимались отладкой получившегося Франкенштейна. Последующее обновление обработки становилось неоправданно тяжелым. А развитие продукта, естественно, буксовало из-за этого.
В общем, мы столкнулись с тем, с чем ранее не имели дела: с разработкой тиражного продукта (и со всей ответственностью, вытекающей из этого), а также с необходимостью работы в команде.
Средства командной разработки от 1С нам не подошли. “Хранилище Конфигурации” решает другую задачу: оно в буквальном смысле хранит конфигурацию. И все. Ветвление и объединение веток, режим “blame” и возможность построчного комментирования кода отсутствуют. Да, в последних версиях 8.3 разработчики платформы дали возможность разложить конфигурации на исходники в виде текстовых файлов, которые уже можно хранить в современных системах контроля версий. И скомпилировать конфигурацию из этих исходников, разумеется. Нас эти возможности очень радуют, но воспользоваться мы ими не можем. Причина проста - нам приходится поддерживать версию для 8.2.
Итого, мы имели около 85 тысяч строк кода в 2 разных обработках, длинные запутанные методы, проблемы с объединением наработок. Тяжелее всего было объединять изменения двух разработчиков в рамках одной функции.
Как выживать?
Я не открою здесь Америку, многое давным-давно описано в учебниках ООП. Можно почитать Фаулера. Но 1С8 - не совсем ООП, и мы долгое время писали по принципу “лишь бы работало” (и работало, конечно, до поры до времени).
Технические решения
Рефакторинг - наше все
В продуктах подобного масштаба читабельность и структурированность кода становится не эстетическим удовольствием перфекциониста, а необходимым условием выживания проекта вообще. Лучше потратить лишний час на структурирование и подбор говорящих за себя имен методов/переменных, чем заставить своего коллегу потом убить 2 дня на поиск ошибки, оторвав его от текущих задач на развитие.
А еще в сложном, запутанном коде часто водятся баги. Прозрачный и лаконичный код они почему-то не любят.
Например, встречаются такие нагромождения:
КонецЕсли" (несколько экранов спустя).
Если ДальшеДелатьНечего Тогда
И жить стало легче.
Наткнувшись на особо древние костыли, назначение которых уже никто особо не помнит, мы их просто вычищаем, стараясь сделать код красивым изнутри. Потом смотрим, что от этого сломалось, и стараемся сделать код красивым и там тоже. Если совсем без костылей обойтись пока не удается, мы их выделяем, заливаем красной краской и обставляем дорожными конусами, чтобы вернуться впоследствии.
Рефакторинг проводим время от времени, без какого-либо плана, по настроению. А настроение обычно возникает на фоне необходимости добавления какой-либо фичи, затрагивающей запутанные участки кода.
Чем меньше кода, тем лучше
Не в ущерб читабельности, здесь важно вовремя остановиться. Одинаковые или просто похожие куски кода мы стали объединять в новые методы или в циклы. Это типичный прием рефакторинга, но мы пошли чуть дальше.
Мы начали избавляться от функциональности, от которой в принципе можно было избавиться (имелась альтернатива). Это было довольно болезненно: взять и выбросить десятки тысяч строк кода, написанных когда-то совместными усилиями. Скрежет наших зубов раздавался по всему этажу. Самые значимые примеры:
Полтора года назад у нас было 2 обработки и 85 000 строк кода в сумме. Сейчас одна обработка и 70 000 строк кода. Разумеется, эти полтора года мы не только уничтожали код, но и писали много нового.
Декомпозиция методов
Чем меньше разных действий выполняет метод, тем он читабельнее. Например, если в одной процедуре/функции встречается чтение файла с FTP и заполнение какого-либо документа, логичнее разбить его на два разных метода. Методу, который парсит XML, незачем знать, как устроена текущая конфигурация. Еще есть управляемые формы, где интерактивные действия недоступны на сервере.
Это аналог старых добрых классов в ООП и немного закос под mvc.
Мы стали делить длинные портянки кода на логические блоки, и средний размер одного метода упал с 40 до 30 строк кода. Стало гораздо проще объединять код разных веток перед релизом. Вероятность конфликтов свелась к минимуму, а их разрешение упростилось в разы.
Да, у нас еще остаются портянки строк на 300. Придет время - и их по возможности раскидаем.
Автоматизированное тестирование
Мы внедрили 2 системы тестов: сценарные тесты и юнит-тесты на основе xUnitFor1c. Каждый коммит в системе контроля версий подхватывается скриптом и автоматически отправляется на тестирование в нескольких типовых конфигурациях 1С. Релиз не выпускаем до тех пор, пока все тесты не позеленеют, и пока тестировщики не скажут "ок", разумеется. (Да, у нас есть тестировщики, нет, они не программисты).
Первый вариант тестирования (сценарный) выявляет наибольшее количество ошибок. Он похож на этот, только для обычных форм. Для этого нам пришлось встроить в сам код модуля точки входа для скриптов тестирования.
Второй не столько ловит ошибки (да, мы еще ленимся писать новые тесты, типичная проблема), сколько заставляет писать новый код с тем расчетом, чтобы его можно было прогнать через юнит-тесты. То есть его действие пока больше психологическое, но оно помогает более грамотно структурировать код. А значит, избегать появления ошибок еще на этапе разработки.
Стараемся придерживаться такого правила: если в релизной версии более 1-2 раз регистрируются ошибки, возникающие в одном и том же методе, то покрываем этот метод тестами. Чаще всего сначала его приходится потрошить и расчленять подвергать рефакторингу.
Система контроля версий
Изначально использовали SVN с клиентом от Tortoise. Использовали его для блокировки предрелизной версии в момент заливки изменений и для хранения истории коммитов и релизов.
Затем на коленке собрали собственную систему контроля версий на 1С. Выглядит примерно так:
Автотесты интегрированы с этой системой и зеленеют/краснеют прямо на коммитах. Столбец с зелеными кружками и заголовком “U” - юнит-тесты. Столбец правее с заголовком “F” - интеграционные тесты.
Иногда встречаются такие цепочки коммитов:
Сюда же встроен V8Reader с возможностью сравнить 2 произвольных коммита без открытия конфигуратора. Получается очень удобно.
Здесь же автоматизированы действия при выпуске релиза: формирование RSS, закрытие задач в трекере, расчет контрольной суммы файла и т.д.
Почитав статьи про современные системы контроля версий (раз, два), захотели перейти на связку Git+Precommit1c с компиляцией обработки из исходников. Увы, в платформе 8.x есть не очевидная особенность: при сохранении файла внешней обработки некоторые формы (не управляемые) хаотично перекодируются, выдавая совершенно другой файл, даже если вы просто пробел в коде добавили. Мы пытались как-то обмануть платформу, чтобы можно было объединять изменения разных веток и компилировать исходники обратно во внешнюю обработку. В конце концов пришлось смириться с реальностью и оставить эти попытки. Однако используем Git+Precommit1c для “ленивого” Code Review: каждый участник команды получает уведомления о новых коммитах и может оставить комментарии к любой строке изменившегося кода. В precommit1c внесли изменения:
-
После декомпиляции удаляем файлы обычных форм, чтобы не засорять коммиты.
Но делает это более корректно:
Работа в нестандартных конфигурациях
Периодически возникавшая необходимость адаптировать модуль под нетиповую конфигурацию очередного крупного клиента заставила нас задуматься о каком-то инструменте, который позволит выполнять эту работу хотя бы с минимальными усилиями. Мы же программисты, самые ленивые люди в мире. Тем более что для 7.7 такой инструмент уже был готов: у нашего основного разработчика на этой платформе черный пояс по магии.
Изначально модуль 8.х разрабатывался на УТ 10.3. Весь код был пронизан конструкциями вида Заказ = Реализация.Сделка, например.
Мы стали постепенно, от релиза к релизу, абстрагироваться от привязки к конкретной конфигурации (снова немного mvc), загоняя поиск связанных документов в промежуточные функции и параметризуя названия справочников, документов, их реквизитов.
Был период, когда мы целенаправленно брали вне очереди задачи на настройку модуля в самописных конфигурациях и смотрели, в какие участки кода приходится вносить правки. Начинали с простого: с замены конструкций “Заказ = Реализация.Сделка” на функции-обертки: “Заказ = ПолучитьЗаказ (Реализация)”. В итоге получился довольно мощный инструмент, основная идея которого, надеюсь, будет понятна. Большую часть описания конфигураций удалось оформить декларативно (макеты, тексты запросов, без кода).
Получилось примерно так:
(Данные запросы разбираются на части и собираются заново в нужном виде. И не говорите, что СКД для этого не предназначена. Знаю, согласен.)
Эти вещи позволили нам легко выполнять 90% работы по кастомизации обработки.
После этого провели боевой тест на полностью самописной конфигурации, вот фрагмент метаданных для наглядности :
Модуль взлетел быстро, большую часть изменений удалось вынести “сбоку”, что дает возможность с минимальной болью обновляться в будущем.
Так мы очень сильно разгрузили себя от однообразной работы по кастомизации модуля под конфигурации заказчиков и получили возможность больше времени уделять продуктовым задачам.
И еще один побочный эффект от проделанной работы: стало гораздо проще влить в модуль логику работы с 3 основными конфигурациями на управляемых формах.
Организационные решения
Code Review
Очень простой и мощный инструмент. При масштабных изменениях в коде автор кидает клич, желающие изучают diff и дают свои замечания.
Практический эффект: на этом этапе мы действительно иногда находим ошибки в коде, неоптимальные действия, нечитабельные места. Психологический эффект: зная, что твой код будет придирчиво изучать коллега, стараешься писать как можно качественнее и яснее. Плюс повышаем общее владение кодом: напомню, это 70 000 строк.
Пример “ленивого” Code Review:
“Митинги” (Daily Scrum meeting)
Это часть технологии “SCRUM”. Каждый день в 15:45 встаем возле доски и двигаем листочки с задачами, рассказывая друг другу, что сделали и что собираемся делать. Это здорово помогает быть в курсе того, куда вообще двигается продукт, и заодно позволяет избегать проблем с объединением кода.
Циклы разработки
-
Добавили новую фичу
- Набираем задач на ближайшую неделю
- Разрабатываем и тестируем в своих ветках
- Проводим Code Review всех крупных изменений
- Сливаем в предрелизную ветку, она же версия для тестирования
- Тестировщики говорят свое "фи", исправляем баги
- Когда тестировщики говорят "ок", готовим описание релиза для rss, выпускаем релиз (обычно это 2-3 недели от начала итерации, бывает и больше).
- Критичные баги в случае их появления лечим в промежуточных релизах, дублируя фикс в предрелизную ветку.
Работа с багами
Критичные/блокирующие баги исправляются везде и всегда в первую очередь. А мелкие, позволяющие продолжить работу, обычно копятся. Психологически очень тяжело заставить себя потратить час на исправление одной ошибки из известных 46, чтобы их осталось 45.
Однажды мы ввели “день багов”. Это один день в неделю, когда все, преодолев собственное сопротивление, откладывают в сторону все новые фичи и занимаются исключительно исправлением таких вот мелких ошибок. Сейчас их осталось 13, это самые редкие или неуловимые.
Подбор задач из очереди
Были времена, когда мы лихорадочно пытались закрыть как можно больше задач за минимальное время — сказывался опыт работы во франчах и ИТ отделах компаний.
В действительности же самое циничное, что может сделать разработчик с заказчиком, - просто реализовать все его требования без их анализа. Ну а цинизм 80 уровня - реализовать их именно в той постановке, которую дал заказчик.
При работе фрилансом я сталкивался с тем, что клиент настаивал на придуманном им неоптимальном способе решения задачи. Если не удавалось его переубедить, в действие вступал простой алгоритм:
-
Делаю, что попросили.
Зато у нас сформировалось собственное видение стратегии развития модуля. Именно стратегии, а не беспорядочного исполнения желаний. И при отборе задач в очередную итерацию мы определяем их по таким критериям:
-
Потенциальная польза от выполнения задачи.
Что сейчас?
Не скажу, что год-два назад мы прямо ощущали какой-то большой дискомфорт. Нет, мы занимались разработкой в привычном для 1С-ника режиме (ну, вы понимаете, в каком именно). Более того, казалось, что по-другому и не бывает. Это как с курением: пока куришь, не понимаешь что что-то не так. Понимаешь только тогда, когда уже бросил.
Сейчас нам стало гораздо спокойнее выпускать новые релизы. Легче объединять код. Легче его поддерживать, мы больше не боимся через год-два полностью погрязнуть в разборе багов. Мы развиваем модуль по своей стратегии, и нам это нравится. Получаем удовольствие от красиво написанного кода и морщимся, наткнувшись на свои же костыли многомесячной давности. Продолжаем набивать шишки и расти. Наверное, так и выглядит командная разработка в других средах за пределами 1С.
В предыдущей статье я описал проблемы, с которыми мы столкнулись в самом начале становления QA-процессов в нашем хранилище, а также первые шаги по их исправлению. В этой статье расскажу, как мы справлялись с оставшимися проблемами, какие инструменты использовали и какие у нас планы.
Проблемы прошлого
Для начала вспомним, какие же проблемы остались актуальными:
Ручной сбор пакета разработчиками.
Ручное ревью пакета.
Необходимость в синхронизации продуктового и тестового контуров.
Недоступность операций над метаинформацией при возникновении очереди.
Отдельный контур для тестирования интеграции.
Кроме того, из последней проблемы вытекает тот факт, что целых три тестовых контура используются в текущем flow.
Три тестовых контура (vial, live и test)
Я уже писал про vial и live — серверы для проведения модульного и регрессионного тестирования ETL-процессов. Они позволили отделить эти виды тестов, но старый test-контур при этом никуда не делся и использовался для интеграционного тестирования пакета, уже прошедшего модульное тестирование на vial. Кроме того, ряд задач невозможно было протестировать на vial в силу различных обстоятельств, и с ними по-прежнему работали на test.
Было: все тестирование на одном контуре.
Стало: модульное и интеграционное тестирование, а также регресс разнесены по разным контурам.
Распределение этапов тестирования между контурами
тестовых контуров стало больше;
test по-прежнему использовался.
Зачем нужен test?
Во-вторых, ряд задач просто нельзя было на тот момент тестировать на vial по разным причинам. Например, бэкапы для некоторых таблиц нельзя (или очень проблематично) было перенести на vial с prod. Поэтому их тестировали на test.
Хорошо, с важностью и необходимостью test’а разобрались.
А в чем были проблемы с test при текущем flow с тремя тестовыми контурами?
Оказывается, проблем было несколько:
необходимость синхронизаций с продом;
О синхронизации уже говорили, поэтому рассмотрим две оставшиеся проблемы.
При совместном использовании теста многими QA-инженерами время от времени возникали конфликты метаинформации и/или физических данных из-за одновременного использования в разных задачах одинаковых объектов. В этом случае нужен был откат задач и согласование порядка работы с объектами (порядка наката и тестирования).
Давайте рассмотрим решения проблем при помощи наших разработок, и начнем с проблемы ручного сбора пакетов.
Текущие реалии
Настоящее
Мы шаг за шагом улучшали наши процессы и создавали новые инструменты, развивая их. Постепенно переходили к автоматизации. Остановимся на этом подробнее.
Составляющие автоматизации
Про авторелиз уже рассказали в предыдущей статье, поэтому рассмотрим остальные составляющие.
Портал автоматизации
Консольная утилита автонаката задач на разные контуры была очень полезной, но мы не зацикливались на ней, да и, что называется, аппетит приходит во время еды.
Через некоторое время в работу был введен портал автоматизации — это наше внутреннее веб-приложение, которое помогает разработчикам, QA-инженерам, ревьюверам и ребятам, выполняющим релизы задач, вести свою работу с пакетами в одном месте.
Отображение пакета на портале автоматизации
Какие функции предоставляет портал автоматизации?
Автоматический сбор пакета.
Накаты задач на все контуры.
Большой пул работ с метаинформацией.
На портале автоматизации у разработчика появилась возможность собрать свой пакет автоматически. Причем, если задача не содержит специфических объектов и действий, на лету создается пакет с типовым содержимым и сценарием. А если сценарий по данной задаче содержит специфические действия, то на портале есть функционал создания сложного сценария работы с объектами хранилища данных и наката.
А еще у нас появилась загадочная сущность — автотестер, решающая задачи автоматического создания тестовых окружений.
Автотестер
Итак, автотестер — это совокупность нескольких демонов, создающих готовые vial-окружения без каких-либо ручных действий со стороны сотрудников.
Автотестер запускает накаты задач ежедневно в 20:30, поскольку в это время нагрузка на тестовый контур резко снижается и работы автотестера никак не будут блокировать работу сотрудников. Он берет все задачи, которые успешно прошли ревью и по которым в Jira указан уровень тестирования «автоматическое». Такой уровень тестирования проставляется у всех задач, для которых не предполагаются ручные действия во время наката. А далее запускает процесс создания пробирок.
Автотестер создает чат с разработчиком и QA и в случае возникновения ошибок окружения (моргнула база, кончилось место или же в самом пакете вылезли ошибки, которые не были выявлены на ревью) отправляет туда лог ошибки.
После успешного переноса задачи на 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 наращивают техническую экспертизу за счет расширения обязанностей, взятия на себя все большего числа сервисов в поддержку и разработку. У нас много планов, и мы их обязательно реализуем. А о результатах расскажем в новых статьях.
Иногда приходится слышать выражение "тестовый контур" (в контексте какой-либо тестовой программной среды). Интересна история происхождения этого выражения. Википедия по этому вопросу хранит молчание и гугл тоже.
UPD (перенесено из комментариев): довольно много народа употребляет данный термин и никто не может внятно объяснить откуда он взялся. Тем не менее, наверняка у этого "устойчивого выражения" интересная история
скорее всего это выражение с Вашего локального окружения. Не удивлюсь, если придумали люди, которые связаны с электроникой.
@KoVadim, нет, в it'шной среде слышал такое не раз и в совершенно разных компаниях/локациях. Так что точно не "локальное окружение"
@alexanderbarakin довольно много народа употребляет данный термин и никто не может внятно объяснить откуда он взялся. Тем не менее, наверняка у этого "устойчивого выражения" интересная история
Жаргонизм из электроники, ещё с ламповых времен. Поищите в Гугл "гетеродинный контур", "контур с обратной связью", "электронный контур".
@KAGGDesign а какая связь с "тестовый контур"? общее слово "контур" это еще не все, нужно объяснение почему "гетеродинный контур" и "тестовый контур" взаимосвязаны (если это так). Я поискал пересечений не увидел пока .
2 ответа 2
Однозначной терминологии в данном вопросе не существует. Контур может оказаться средой или окружением, вместо теста и продакта официальная документация может ссылаться на контур опытной эксплуатации и контур промышленной эксплуатации.
На терминологию влияет и процесс разработки, которые практикует команда или целая организация. Обычно все программисты разрабатывают и тестируют код на своих компьютерах и имеют всё необходимое окружение для этого, например, локальные версии MySQL, Redis или MongoDB. Если разработка ведётся через Docker, то необходимые сервера запускаются в контейнерах локально.
Этот контур может называться локальным или персональным. Его хватает проверить, что программист, кажется, написал всё так, как предполагалось. Там можно прогнать модульные и интеграционные тесты.
Когда задача завершена программистом, он отправляет код в общий репозиторий, из которого собирается версия проекта, которая на жаргоне называется дев (development). Этот контур позволяет проверить, что программисты ничего не сломали друг у друга, он достаточно нестабилен. Здесь выполняются автоматизированные интеграционные тесты.
Когда программисты считают, что код можно отдавать на тестирование, они переносят изменения на тестовые контур, где можно прогонять ручные тесты. Здесь возникают тонкости, связанные с тем, что тестирование бывает очень разным, например, нагрузочным. Для нагрузочных тестов обычно создают свой собственный контур.
Когда всё готово, проверенная версия попадает на прод (production), он же контур промышленной эксплуатации.
Что такое контур или среда физически? Зависит от средства разработки и от технологий. Часто это Docker-контейнеры, которые разворачиваются на нескольких виртуальных машинах. Для каждого контура мы создаём несколько виртуалок, и запускаем там очередную версию кода.
Если вы работаете в Azure, вы можете сделать несколько серверов БД, каждый для своего окружения. Такие ресурсы можно сгруппировать, назвав группы dev, test и prod.
Если проект разрабатывается давно, и туда уже невозможно внедрить контейнерную разработку, под каждый контур системные администраторы могут выделить несколько разных физических серверов, управляя ими вручную. Трудоёмки, но такие контуры тоже встречаются, потому что некоторые проекты существуют по 15-20 лет.
Что пишут в блогах
Конференции
Heisenbug 2022 Spring
Большая техническая конференция по тестированию
Online — с 30 мая по 1 июня. Offline-день — 21 июня
Профессиональная конференция по автоматизации в тестировании и рядом
27 и 28 июня, Москва, Radisson Slavyanskaya.
Что пишут в блогах (EN)
Разделы портала
Онлайн-тренинги
Автор: Кияшева Екатерина — независимый эксперт в области контроля и обеспечения качества, ekiyasheva. Материал взят из habr, блога ICL Services
В поисках формата для рассказа о практиках тестирования я обратилась к гуглу с запросами “с чего начинать тестирование ПО” и “как подготовиться к тестированию ПО”. И нашла статьи о том, что нужно уточнять требования, применять техники и т. д. Хм… А что, если “составляющими контроля качества ПО” и даже в своем роде глоссариями в том самом поиске и стали стандарты и производные об этапах STLS? Да, все это необходимо – но недостаточно, подумала я.
И если вы, при наличии всех процессов тестирования,
- выводили в PROD не то, что протестировали;
- тестируете не то, что нужно;
- находите баги в PROD, которых точно нет в тесте;
- вынуждены много раз тестировать одно и то же из-за процессных сбоев
– знайте, эта статья для вас.
Велосипед не едет, если у тестирования нет основы. В статье я хочу рассказать, что мы предварительно настраиваем, чтобы тесты были достоверными, эффективными и предсказуемыми.
DISCLAIMER
1. Перечисленное ниже является структурой “предподготовки”, а не готовым шаблоном. Инструменты, подходы, процессы представлены на правах примеров. По уму они должны выбираться исходя из особенностей проекта и продукта. Эти кейсы подходят большой линейке, но не всей (особенно боюсь поднять халивар на тему GIT flow). В любом случае, буду рада обсудить другие кейсы и особенности проектов в комментариях.
2. Наличие “предподготовки” позволяет обеспечить тестирование высокого уровня, но не гарантирует его. Однако при наличии базовых настроек гораздо проще отследить, где проседает тестирование, и принять меры.
3. Я намеренно опустила некоторые преднастройки, которые сильно зависят от принятого на проекте тестирования. Например, если в компании Х принято тестировать продукт серым ящиком, то очевидно, что в качестве преднастройки должен быть организован доступ к тестовым средам. Постаралась выделить самые главные, которые подходят большинству.
Коммуникации
Хорошо выстроенные коммуникации позволяют превратить формальные проверки в клиентоориентированное тестирование.
Роли в проекте
Мы выделяем 5 значимых ролей для тестировщика со следующим предназначением:
- Разработчик – поставляет информацию об алгоритме фичи. Это не вопрос “что тестировать”, его мы не задаем. Знание механизма дает возможность применить техники тест-дизайна на промежуточных шагах и отловить не очевидные дефекты;
- Аналитик/Дизайнер – поставляет информацию о бизнес-процессе пользователя и конкретных требованиях. Является последней инстанцией в спорных вопросах с разработчиком о работе продукта;
- Руководитель продукта/Заказчик – формирует содержание релиза. Лучше всех знает, как должны работать и выглядеть фичи, является последней инстанцией в спорных вопросах о продукте с аналитиком;
- Поддержка – поставляет информацию о качестве выпущенного релиза. Настоящий кладезь знаний о том, как именно используется продукт;
- Руководитель проекта – отвечает за графики работ, балансирует между содержанием, качеством и сроками каждой поставки. От него мы получаем информацию о первостепенных задачах и должны информировать об угрозах поставки: проблемах, блокирующих тестирование, нестабильной версии, критических дефектах. Понятно, чтобы не стать мальчиком, которого съели волки, нужно говорить о реальных рисках.
Тестировщик может хорошо проверять требования и сам продукт на соответствие нуждам конечного пользователя, когда все проектные роли найдены и с ними налажен инфообмен: о бизнес-процессах “как есть” и “как нужно”, алгоритме реализованного, условиях использования продукта и “как получилось”. Сложность поиска ролей в том, что в IT часто Должность не совпадает с Исполняемой ролью. Иногда требуется проявить настойчивость, чтобы найти все, и результаты стоят затраченных усилий.
Инфоканалы
Через инфоканалы тестировщики поддерживают общий контекст с командой и получают существенную часть информации от ролей. По умолчанию, на проектах есть следующие инфоканалы:
- Daily Meeting – на созвонах с командой тестировщик слышит и может сам уточнить что придет в тест, может поднять сложный вопрос сразу к нескольким ролям, например, аналитику, разработчику и руководителю проекта.
- Рабочие чаты – наполняются тематическими каналами. На всех проектах есть канал, в который включена рабочая группа. В него тестировщики дублируют ссылки на заведенные дефекты и решают проблемы, блокирующие тестирование. В случае производственной необходимости вводятся дополнительные каналы, например с аналитиками или дизайнерами. Так тестировщики сокращают длину коммуникаций и вовремя получают актуальную информацию.
- Почтовые пересылки – это регулярные отчеты о событиях на проекте, обычно автоматизированные. В том числе и отчеты о ходе и результатах тестирования.
Признаки хорошо настроенных инфо каналов:
- тестировщик в курсе событий: какие требования актуальны, на каком шаге разработки находится релиз и когда придет в тестирование,
- знает как обсудить оперативные вопросы, чтобы быть услышанным: фичебаги и предложения по улучшению, блокеры в тестировании, требования к продукту со стороны тестирования.
В обратном случае тестировщики превращаются в бук — “почему раньше не сказали!” и “ну я же говорил(а)!”
Среда тестирования
Правильно настроенные среды позволяют обеспечить достоверное тестирование и отсутствие реворков у тестировщиков.
Обычная инфраструктура в 2 тестовых среды – DEV для функционального тестирования и TEST для регрессионного тестирования, и одна боевая для работы конечного пользователя PROD. В этой конструкции есть по крайней мере 4 риска выпускать баги и генерировать реворк тестировщикам вне зависимости от содержания тестирования.
- В DEV environment – попадают изменения ПО, законченные разработчиком. В некоторых случаях в ней можно найти не все фичи текущего релиза, но парочку из будущих. В данной среде тестировщики проверяют релиз пофично и рисков выпустить не то, еще нет. Есть реворк, если разработчики передают в тестирование незавершённые фичи много-много раз (1).
- В TEST environment – должны быть собраны все фичи текущего релиза и ничего лишнего. Здесь тестировщики проверяют релиз целиком, прогоняют регрессионное тестирование. При неправильном устройстве процесса разработки тестировщики встречают ту же картину, что и на DEV сред – это первая угроза срыва сроков релиза, а в запущенных случаях – и качества (2). Не внесли, что планировали, добавили что-то лишнее – регресс начинается со стабилизации релиза, сопровождается серьезным реворком тестировщиков. Если же TEST среда настроена не так, как PROD, возможно столкнуться с ситуацией “баг не воспроизводится в TEST’е” (3).
- В PROD environment — поставляется оттетсированный продукт, в нем должна быть актуальная версия продукта + все изменения, проверенные тестировщиками. Но если PROD за время тестирования обновился, а TEST нет, и процедура деплоя в PROD очень сложная и вся выполняется вручную, то конечные пользователи с большой вероятностью увидят не то, что было проверено тестировщиками (4).
Тестовые контуры
Тестовый контур – программная среда для проведения предварительных испытаний продукта, т. е. тестирования. Дефекты из-за различия в средах встречаются у конечных пользователей не каждый релиз, зато при их появлении команда потратит немало усилий на локализацию, а возможно даже выпустит несколько хотфиксов “вслепую”.
Мы следим за идентичностью следующих характеристик:
- конфигурация интеграций и служебных приложений;
- дистрибутивы ОС, языка разработки, служебных приложений;
- одно-/ многонодность;
- протокол передачи данных;
- авторизация между всеми приложениями.
Правильно настроенная среда для тестирования исключает риск №3, описанный выше.
Модель ветвления: правила обновления и поставки изменений исходного кода
Как было показано, неорганизованная поставка изменений в среды, генерирует реворк в тестировании и непредсказуемые дефекты в PROD. В качестве базовой модели мы используем GIT Flow, адаптированную под реалии проекта. Это исключает риски №1, 2, 4.
Инструменты управления
Любые инструменты управления процессами помогают контролировать и влиять на ход работ без “чайка-менеджмента” и избыточных коммуникаций. В тестировании мы используем оба – систему управления задачами и дефектами (Jira, TFS, RedMine, etc.) и систему управления тестами (Zephyr Scale, TestRail, QASE, TestLink, etc.).
Цель подготовительных работ:
- встроить workflow тестирования в общий производственный процесс в системе управления задачами;
- настроить workflow тест-дизайна и исполнения тестов в системе управления тестами.
WORKFLOW в системе управления задачами
Ниже пример простейшего workflow для выполнения работ по “тестированию изменений” (красный цвет) и “регрессионному тестированию” (серый цвет) в системе управления задачами.
В примере представлено всего 2 типа работ с участием 2 ролей. В тестировании выделяется следующий минимум:
- тестирование изменений
- регрессионное тестирование
- заведение и ретест дефектов
В зависимости от проекта и продукта реестр работ может быть увеличен. Добавлены другие регулярные работы:
- анализ требований;
- модульное тестирование;
- системное тестирование;
- установочное тестирование;
- дымовое тестирование PROD.
Или совсем индивидуальные для проекта, например обработка результатов UAT (Beta- тестирования).
В результате настройки workflow тестировщик в любой момент времени понимает объемы активных и надвигающихся работ, а также их приоритеты. Видит общую картину и может своевременно подготовить вопросы в случае отклонения факта от плана.
WORKFLOW в системе управления тестами
Ниже пример простейшего workflow написания и выполнения тестов в рамках тестирования изменений (красный цвет), организованные в виде тест-кейсов, в команде без выделенного тест-менеджера.
В примере 2 этапа типовой работы “тестирования изменений”, декомпозированные на шаги написания и выполнения тестов. Помимо представленных шагов выделяются:
- ревью тест-кейса тест-менеджером;
- уточнение тест-кейса;
- создание и актуализация прогона;
- выполнение прогона;
- генерация отчета о тестировании.
В результате настройки workflow тестировщик в любой момент времени может сказать, что протестировано и сколько осталось, и какие актуальные проблемы есть на данный момент.
Заключение
Превалирующая доля настроек находится на стороне команды, которая возможно не понимает или не хочет понимать, для чего они нужны. Я видела, как команды проходили 5 стадий принятия при внедрении development workflow. Хотя, казалось бы, уже много лет известно, как утвержденная модель ветвления повышает качество совместной разработки.
Внедрение таких изменений можно поделить на этапы:
- Инициация: найти и убедить главных за коммуникации, тестовые среды, инструменты управления на проекте;
- Разработка: описать изменения, по возможности без сложных терминов и с красочными картинками. Выложить материалы в общий доступ, дальше они будут вспомогательными.
- Внедрение: обеспечить руководителей и, при необходимости, проектную команду консультациями.
- Контроль: дать команде время на формирование привычки. Около месяца контролировать и восстанавливать договоренности в случае отклонений.
Так, у нас в ICL Services на большом количестве проектов, чтобы не преодолевать сопротивление и не растягивать “преднастройку” на каждом из них, перечисленные мною практики выведены на уровень стандартов направления – “Best practices”. Это набор регламентов со ссылками и примерами, приоритизированные по важности. Практики с приоритетом Strongly обязывают руководителей проектов внедрять их сразу, на старте проекта. Все практики, описанные в данной статье относятся именно к этому типу.
Мое мнение – даже если проекту много лет, на нем давно есть тестирование, но хромают — коммуникации, тестовые среды или инструменты управления, не стоит это терпеть. Это хороший повод перетрясти договоренности, потому что потери от плохих условий тестирования измеряются в деньгах, времени, скорости выгорания специалистов и накапливаются каждый день.
Инструкции
Настройка рабочего места
Для настройки интеграции 1с с сервисом ГИИС ДМДК, потребуется:
Обратите внимание, stunnel.x86 — будет работать и на 32 битной и на 64 битной ОС. stunnel.x64 — только на 64 битных системах.
2. Создайте папку на диске C:\ под названием stunnel и скопируйте туда скачанный файл stunnel.x86.exe или stunnel.x64.exe.
3. Запустите командную строку от имени администратора и введите команду: c:\stunnel\stunnel.x64 -install для 64 биных ОС, или c:\stunnel\stunnel.x86 -install для 32 битных.
4. В каталоге c:\windows\system32 создайте или скачайте и скопируйте файл конфигурации stunnel.conf с содержимым:
Вместо порта 1500, можно использовать любой другой свободный порт. В параметре connect — указывается IP адрес интеграционного сервиса, где:
- 195.209.130.9 — для промышленного контура;
- 195.209.130.19 — для тестового контура.
6. Создайте нового пользователя Windows.
7. В сеансе нового пользователя установите (пользовательский) сертификат, выпущенный на информационную систему Участника, в хранилище «Личное».
8. Откройте КриптоПро CSP, выберите вкладку «Сервис», нажмите кнопку «Протестировать», далее кнопку «По сертификату» и выберите личный сертификат. В открывшемся окне введите текущий пароль, обязательно поставив галочку «Сохранить пароль в системе» и нажмите «OK».
9. Откройте диспетчер сертификатов, выполнив команду certmgr.msc. Найдите и откройте личный сертификат, выберите вкладку «Состав», и нажмите кнопку «Копировать в файл». В открывшемся Мастере экспорта, необходимо экспортировать сертификат без закрытого ключа в формате Х.509 (.CER) в кодировке DER и сохранить его с именем clicer.cer в каталоге c:\stunnel.
10. Откройте Службы, выполнив команду services.msc. Выберите службу Stunnel Service и установите для неё тип запуска «Автоматически», на вкладке вход в систему с учетной записью созданного пользователя и запустите службу.
На этом настройка завершена, что бы проверить настройку интеграционного сервиса, перейдите в браузере по адресу: 127.0.0.1:1500 и если все настроено правильно, появится логотип ГИИС ДМДК.
Читайте также: