Функционал

Часто в разговоре люди упоминаю Функционал в разрезе функциональных требований/ возможностей системы. Это неправильно.

Оставлю эту ссылку здесь.

pytest BVT часть 2

Как и обещал продолжаю цикл статей про pytest и создание фреймворка для организации BVT.

В прошлой части немного разобрались с терминологией, в этой же более детально опишем, что же будем разрабатывать.

BVT - это базовый набор тестов, который проверяет самое основное, очень часто в это набор уносят тесты, которые проверяют, что называется, целостность сборки. Что будет входить в наш тестовый фреймворк:

1. Проверка наличия файлов. Удобно для проверки бинарных файлов, логов, конфигов, раскиданных по ФС и т.д. и т.п.
2. Запрос версии. У каждого исполняемого файла обязательно должна быть версия или подпись. Почему версия удобна и необходима думаю не нужно говорить.
3. Проверка опций в конфигурационных файлах. Эти проверки избавят от проблем протечки в продакшн конфигов с включенным дебагом. 
4. Статусы запущенных/зарегистрированных сервисов.
5. Проверка статусов запущенных программ.
6. Открытые порты.
7. Проверка ответов на http запросы. Бывает в сервисы встраивают возможность проверки состояния сервисов (а-ля /healthcheck, /check). Удобно проверить и данную функциональность.

На Линуксе подобные проверки легко решаются использованием bash, на github есть замечательный проект https://github.com/sstephenson/bats, который представляет эту возможность из коробки.

Т.к. нашей целью является изучение pytest, то в качестве основы предлагаю взять таверн https://github.com/taverntesting/tavern. Чем он хорош с точки зрения донорского проекта?

1. Декларативный конфиг на yaml. Сама по себе декларация очень удобна, она позволит разделить понятия тестового движка и тестов. Соответственно один человек будет заниматься написанием кода, а другой за наполнение тесового плана. Плюс yaml гораздо удобнее и проще относительно json, xml.
2. Написан на pytest. Можно брать много годных идей, например, cli для прогона тестов.
3. Для фреймворка написаны свои тесты. Да,да, именно тесты. Фреймворки имеют тенденцию с годами расширяться и усложняться, соответственно нужны регрессионные автотесты.
4. Ну и куча других плюше - настроенный gitlab-ci, requirements, документация и т.п.

В следующей части набросаем скелет фреймворка и напишем на нем "hello world".

pytest BVT часть 1

Поговорим немного о тестировании. Что такое Build Verification Test (BVT/БВТ)?

Найти общего определения на просторах интеренета мне не удалось, поэтому попробую свормулировать сам. 

BVT - это набор базовых тестовых сценариев, нацеленных на выявление явных ошибок. Часто в литературе также под BVT понимают Смок или Дымовое тестирование.

BVT обладают следующими свойствами:

1. выполнение тестов производится на каждую сборку
2. высокая скорость исполнение
3. высокое покрытие базовой функциональности
4. включают только критичные тестовые сценарии 

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

Что все это значит для автоматизатора?

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

Примеры автоматических BVT.

1. Проверка статусов запущенных сервисов.
2. Наличие в сборке исполняемых и конфигурационных файлов.
3. Отсутсвие критичных сообщений об ошибках в логах.
4. и т.п. и т.д.

Разобравшись немного с BVT в следующих частях попробуем написать на pytest небольшой фремворк для разработки универсальных BVT.