Введение
Здравствуй Хабр, меня зовут Сергей, я работаю в компании РЕД СОФТ в отделе разработки операционной системы РЕД ОС. Сегодня расскажу про автоматизацию процессов тестирования дистрибутива РЕД ОС. Для автоматизации таких задач мы создали систему Tooster. О том, какие задачи она помогает нам решать и как упрощает жизнь тестировщику, читайте в статье.
Для начала рассмотрим, какие этапы проходит дистрибутив перед тем, как попасть к пользователю.
Этапы сопровождения дистрибутива
Все процессы можно разделить на следующие основные этапы:
Создание дистрибутива
Тестирование:
– Автоматизированное
– Ручное
Выпуск релиза
Обновление
Создание и дальнейшее сопровождение дистрибутива на протяжении всего жизненного цикла является трудоемкой задачей со множеством рутинных операций. Автоматизация процессов экономит временные ресурсы и сокращает количество ошибок, вызванных человеческим фактором.
1. Создание дистрибутива
Процесс создание дистрибутива:
Сборка бинарных пакетов из исходного кода
Формирование репозитория
Создание установочного образа
На первых двух пунктах процесса создания дистрибутива останавливаться не буду. Эти задачи в полном объеме решаются на стороне сборочного кластера.
В этой статье коснемся именно сборки образа операционной системы и его тестирования. Эти задачи автоматизирует Tooster.
Создание установочного образа
Основной задачей Tooster на данном этапе является создание единого интерфейса для конфигурирования параметров и запуска сборки установочного образа.
Что делает система Tooster:
Подключается к сборочному хосту;
Управляет comps и variants файлами;
Создает и редактирует шаблон настроек для инструмента создания установочного образа (pungi);
Запускает и контролирует состояние процесса сборки образа.
Общую информацию о запусках можно найти в подразделе с данными о запущенных процессах по созданию образа.
Здесь также можно посмотреть подробную информацию о том, кто и когда запустил сборку, текущий статус, прогресс, а также лог-процесс сборки.
2. Тестирование
2.1 Автоматизированное тестирование
Проверяемые программные окружения
Успешно созданный образ попадает в модуль по развертыванию шаблонов тестировочных машин различных окружений. Под окружением подразумеваются вариации программных окружений пользователей внутри системы, которые задаются при установке операционной системы.
Сам процесс развертывания шаблонов выглядит следующим образом.
На основании comps файла образа определяется, какие программные окружения доступны для данного установочного образа.
На данный момент мы выпускаем несколько конфигураций РЕД ОС, в каждом по два варианта программного окружения:
Рабочая станция
– минимальный набор пакетов
– максимальный набор пакетов
Минимальный сервер (без графики)
– минимальный набор пакетов
– максимальный набор пакетов
Графический сервер
– минимальный набор пакетов
– максимальный набор пакетов
На основании того, какое программное окружение выбрано, генерируется конфигурационный файл для системы быстрой установки kickstart.
После завершения генерации в LibVirt создаётся виртуальная машина. В качестве параметров загрузки с образа операционной системы передается исполняемый файл ядра (vmlinuz), образ файловой системы initrd.img, а также сгенерированный kickstart-файл, осуществляется запуск процесса установки операционной системы.
Далее от системы создается шаблон (virt-sysprep), копии от которого в последующем будут использоваться в автоматических тестах в качестве первоначального состояния системы.
После создания всех необходимых шаблонов начинается процесс автоматического тестирования.
Тестирование собранного образа
Суть процесса тестирования операционной системы заключается в проверке соответствия поведения ее компонентов заданным условиям. В частности, осуществляется контроль соответствия системы требованиям безопасности ФСТЭК России.
Даже при малейших изменениях в пакетной базе образа важно относительно быстро протестировать всю систему и на 100% быть уверенным в том, что это изменение не влияет на работоспособность системы и не нарушает требований к безопасности. Внося изменения в один компонент системы, не всегда можно предусмотреть, как оно повлияет на другой компонент. Делать это быстро помогает система автоматизированного тестирования. Также автоматизация позволяет избежать ошибки, вызванной человеческим фактором – пропуск тест-кейсов, неверный запуск или интерпретация результатов.
Функциональное тестирование дистрибутива проходит ряд этапов:
развертывание тестируемой среды
запуск процессов тестирования
выявление ошибок
обработка результатов
Для реализации описанного функционала не было найдено подходящих готовых решений, поэтому мы решили разработать собственный инструмент – Tooster.
Согласно заданию по безопасности и тестовой документации, на каждое функциональное требование безопасности используется отдельный тест-кейс. Тест-кейс проверяет,обеспечивается ли выполнение требования в установленной операционной системе. В настоящий момент все требования по безопасности тестируются (разработанного на основе профиля защиты операционных систем типа «А» четвертого класса защиты ИТ.ОС.А4.ПЗ). Также выполняется значительная часть дополнительных проверок по нашей базе знаний. Осуществляется комплексная проверка работоспособности системных и прикладных приложений.
Что входит в файл тест-кейса?
Файл тест-кейса включает в себя следующие блоки.
Блок инициализации. Он несет в себе информацию о количестве и наименовании программного окружения виртуальных машин, необходимых для проверки функционала по конкретному тест-кейсу.
Блок предварительных условий. В нём описан порядок действий, который необходимо выполнить до запуска основного процесса тестирования – осуществляется преднастройка системы.
Алгоритм тестирования. Последний блок – это блок самого процесса тестирования, который представляет из себя описание порядка действий и предполагаемый отклик на каждое из этих действий.
Схема тестирования
Сам процесс тестирования происходит следующим образом.
Первым делом осуществляется анализ файла тест-кейса. В частности, блока инициализации, который несёт информацию о количестве и наименовании программного окружения виртуальных машин, необходимых для проверки функционала.
На основании этой информации осуществляется поиск и создание копий от предварительно развернутых шаблонов виртуальных машин.
После того как машина скопирована и запущена — делается снимок чистой системы. В случае ошибки, он позволит вернуться и посмотреть отклик того или иного компонента на чистой системе.
Далее осуществляется порядок действий по обеспечению предварительных условий внутри системы, здесь также делается снимок.
Дальше запускается блок самого процесса тестирования.
Если где-то в ходе тестирования отклик системы не соответствует ожидаемому, это также фиксируется, а тест отмечается не пройденным. Образ отправляется на доработку.
После завершения тестирования формируется отчет, который содержит информацию и статусы по различным группам тестирования. Тестировщик также сможет посмотреть информацию по каждой из групп тестирования по отдельности и оценить состояние системы по ходу прохождения теста.
В Tooster реализована система логирования. В системе отображаются команды, отправляемые на виртуальную машину, их отклик. В случае неудачного тестирования, покажется конкретная строка файла тест-кейса, код и содержание ошибки.
2.2 Ручное тестирование
После успешного выполнения всех автоматических тестов, образ передается в команду ручного тестирования. В ряде случаев дополнительно привлекаем сторонних экспертов для проведения тестирования на проникновение и поиск уязвимостей.
После успешного прохождения всех этапов тестирования, образ передается для проверки внесенных изменений испытательной лаборатории для проверки и сертификации ФСТЭК России.
3. Релиз
Стандартная редакция без сертификации отправляется в публичные репозитории и становится новым релизом операционной системы.
РЕД СОФТ разрабатывает долгосрочный продукт. Для сертифицированной редакции поставляем обновления, связанные с устранением обнаруженных уязвимостей. Для стандартной редакции – обновления, связанные с функционалом прикладного ПО.
Все тестирование и запуск процессов обновления пакетов в репозитории осуществляется через Tooster в автоматическом режиме. Ни один пакет без полной проверки в репозиторий не уйдет.
Заключение
Об оперативной доставке обновлений и их тестировании читайте в следующей статье!
