Тестирование

Главная идея

Все функциональные тесты создаются в виде DirAAP.
Распространяются и обновляются, как git или как app соответствующей платформы.
Тесты ставятся рядом с рабочим продуктом.
Желательно, ставиться и обновляться той же схемой, что и основной продукт.
Колво объектов в тестовой БД должно быть в 10 раз больше от реальных условий.
Обязательно проводим тесты ускоренного или сдвигаемого времени, для отлова ошибок перехода через 00 часов или 1 число месяца или 1 ое число года.
Тестовые виртуалки есть у каждого разработчика.
Есть тестовая вирталка для тестировании ветки testing где есть все коммиты всех разработчиков.

TODO причесать.

- тесты делятся на группы тестов (test_se_auto, test_api, test_cabinet и прочие)
- тесты деляется на быстрые (fast) и медленные (slow); рекомендуется соответствующие тесты располагать в подкаталогах <группа_тестов>/fast/ и <группа_тестов>/slow/
- придерживаемся directory as service, максимально все, необходимое для работы теста, должно располагаться внутри каталога с группой тестов; ислючения: устанавливаемые приложения (jenkins, firefox, selenium) - ставятся прямо в систему и конфигурируются скриптами, возможно использование общих библиотек для разных групп тестов
- в каждоый группе тестов в корне должно быть 2 файла: slow_test.sh и fast_test.sh, которыми запускается группа тестов; должны быть bash-скриптами, по-умолчанию содержат 1 строку с запуском внутреннего фреймворка/обходчика тестов данной группы тестов

Правила тестов:
- если тесту нужно запустить скрипт изнутри чрута (например, asr_billing), то он копирует нужный скрипт внутрь перед запуском и запускает
- для быстрых тестов действует ограничение: максимум 1 минута на выполнение для одной группы тестов; чтобы 1 прогон занимал минут 5-10, а разработчик попил чай/проверил почту, но сильно не отвлекся

Апп:
- тесты поставляются в аппе /app/tests_$PROFILE
- собирается и ставится с makedistro и или updater
- является directory-app и одновременно чрутом(для селениум файрфокс и тп)
- конфигурируются в /app/test_CRB-Billing/cfg/config
- запускаются /app/test_CRB-Billing/service fast_test и /app/test/service slow_test
- в аппе содержатся тесты для всех продуктов, располагаются:
/app/test_CRB-Billing/test_group1/fast/
/app/test_CRB-Billing/test_group2/fast/
/app/test_CRB-Reductor/test_group1/fast/
/app/test_CRB-Reductor/test_group1/slow/
/app/test_CRB-Reductor/test_group2/fast/
- если для аппа нужно будет устанавливать приложения (jenkins, selenium), скрипт запуска тестов должен будет это делать сам, makedistro в апп приложения не устанавливает, в аппе только скрипты запуска тестов и сами тесты - весь енвайромент должен поставляться в чруте в готовом виде, на хост ничего не ставим

Главный обходчик:
- запускается из крона и или руками
- конфигурируется через config
- для запуска тестовых групп использует jenkins (как сделано в makedistro)
- несет ответственность за блокировку/разблокирочку обновления

Тестовая сборка, бранч test:
- в него мержатся все бранчи разработчиков
- на него настроена виртуалка с тестированием

/app/tests_CRB-Reductor/service
/app/tests_CRB-Reductor/src.list
 
/app/tests_CRB-Reductor/tests_reductor/.git
/app/tests_CRB-Reductor/tests_reductor/fast_test
/app/tests_CRB-Reductor/tests_reductor/fast/
/app/tests_CRB-Reductor/tests_reductor/slow_test
/app/tests_CRB-Reductor/tests_reductor/slow/
 
/app/tests_CRB-Reductor/tests_reductor_satellite/.git
/app/tests_CRB-Reductor/tests_reductor_satellite/slow_test
/app/tests_CRB-Reductor/tests_reductor_satellite/slow/
 
/app/tests_CRB-Reductor/tests_bgp_blackhole/.git
/app/tests_CRB-Reductor/tests_bgp_blackhole/fast/
/app/tests_CRB-Reductor/tests_bgp_blackhole/fast_test
/app/tests_CRB-Reductor/tests_bgp_blackhole/slow/
/app/tests_CRB-Reductor/tests_bgp_blackhole/slow_test

Дополнение1

/app/tests_crb-billing5 тоесть имя профиля /app/tests_$PROFILE
внутри есть полный енвайромент-чрут для запуска firefox selenium и тд
тесты в виде каталогов с .git подкаталогом чтоб можно было сразу разрабатывать и править
/app/tests_crb-billing5 является и чрутом и не чрутом, чтоб можно было от корня запускать
Отдельный профайл tests_crb-billing5, в идеале он имеет туже версию что и продукт, и лежит в апдейтерАХ на мейкдитрах(в будущем на update5) как продукт, и ставится с апдейтера тулзой можно в стиле rsync.

TODO обновить эту статью по данным совещания

Krat NikolayKrat Nikolay, 15.12.2017 09:54

Я бы добавил уточнение про поставку утилит тестирования в продукт. Например, юнит-тесты, для простоты, могут поставляться вместе с кодом, но спец. утилиты (например, для сдвига времени, для проведения тестов) - должны поставляться в комплекте тестирующего сервиса и доустанавливаться им. Создание особой тестовой сборки я считаю нерациональным, т.к. по pl7 мы поставляем приложения с максимальнымы возможностями отладки на месте и нужды в пересборке/перекомпиляции быть не должно.

Связано это с локальностью тестирующих скриптов и технологий тестирования, а также с отключением возможности запустить деструктивный скрипт на продакшене по ошибке.

adminadmin, 15.01.2018 15:55

добавил дополнение и todo по резалтам нового совещания

Сергей ТрошинСергей Трошин, 18.01.2018 01:42

Поддержу Николая. Основной код тестов, который может работать внутри продукта, имеет смысл внутри продукта и держать. Снаружи только системные вещи, которые на ОС влияют.

Krat NikolayKrat Nikolay, 18.01.2018 08:59

Я немного неправильно выразился. Говоря про юнит-тесты, я имело в виду код, который можно выполнить при сборке а-ля make build test install. А вот итеграционные тесты, либо тесты которые завязаны на окружение (а также скрипты настройки этого окружения) - я бы предпочел держать и распространять отдельно от основного продукта (в тестовом аппе).

Anton KlinskihAnton Klinskih, 23.01.2018 03:22

(jenkins, firefox, selenium) в итоге в чуруте или нет?

Олег СтрижеченкоОлег Стрижеченко, 24.01.2018 01:51

Да, в чруте

Anton KlinskihAnton Klinskih, 13.06.2018 04:32

Тогда они не смогу запускать тесты находящиеся в окружении контейнера, например биллинга

Сергей ТрошинСергей Трошин, 05.09.2018 09:13

Можно тестам обеспечить доступ к app через ssh 169.254.хх.хх Но ключи для авторизации должен какой-то хук прописывать из корня. Тогда тесты даже не обязательно будет на той-же ВМ держать.

adminadmin, 09.09.2018 13:24
Тогда они не смогу запускать тесты находящиеся в окружении контейнера, например биллинга

Предполагается, что тесты запускаются от корня.
А если надо протестировать вебку то test.sh запустит chroot $test selenium+firefox, а firefox'у не нужен доступ к другим чрутам.

Подробнее работа идет здесь https://wika.carbonsoft.ru/проект_reductor:документация_проекта:тестирование:autotests-and-ci

TODO перенести сюда обсуждение?

Anton KlinskihAnton Klinskih, 12.09.2018 04:34
Предполагается, что тесты запускаются от корня.

Но если это делает jenkins и он в chroot, то как он запустить тесты от корня? Хотя для биллинга это уже не актуально т.к. выяснилось что запуск тестов из jenkins на самой виртуалки каким то образом замедляет время выполнения аж в 8 раз, разбираться в чем дело было не рентабельно т.к. за пару часов не разобрались и решено было перенести запуск тестов на makedistro который эту ветку собирает, так что как будет свободное время соберу апп где будут все тесты и необходимое окружение

adminadmin, 14.09.2018 08:58 (14.09.2018 08:59)
Но если это делает jenkins

предполагается, что это делает bash обходчик, а не дженкинс.

если баш обходчик в одной из групп тестов должен запустить корневой jenkins, то нужно сделать чтоб такой дженкинс работал как dirapp без чрута(или хотябы скрипт по его установке).

adminadmin, 04.09.2018 09:49

прочитал

Anton KlinskihAnton Klinskih, 26.11.2018 04:26

Вынесли тесты в chroot, только поскольку тестируем питоном то поставляются они в виде python пакетов с соответствующим путем, запускаем их из makedistro т.к. перед тестированием надо запустить обновление и оно убьет апп в котором мы обновление запустим, если это делать из chroot, плюс jenkins/java жрет много ресурсов.

adminadmin, 04.12.2018 07:11

если честно я не понял, возможно стоит показать визуально или на совещании

Ваш комментарий. Вики-синтаксис разрешён: