Релиз — это выпуск новой версии программного обеспечения.
В релизную поставку включается конечный набор доработок и исправлений.
Прежде чем релиз становится доступен конечному пользователю, он проходит через этапы жизненного цикла программного обеспечения, последний из которых — тестирование.
Разберём:
Код, написанный разработчиками, собирается в архив или исполняемый файл. Нумерация получившейся сборки позволяет отслеживать изменения.
Версию принято указывать в формате major.minor.patch, где:
major — значительные изменения, которые могут нарушить совместимость
minor — изменения, совместимые с предыдущими версиями
patch — исправление ошибок и незначительные изменения
Стабильную сборку, которая будет выпущена для использования конечным пользователем называют релизной сборкой.
Код должен попасть с локальной машины разработчика на стенд для этого:
Девопсы пишут джобы, используя скриптовые языки и визуальный интерфейс приложений для автоматической сборки и развертывания CI/CD (continuous integration/continuous delivery): Jenkins, Teamcity.
Наконец-то релизная сборка была развернута на стенд, и тестировщики могут приступить к тестированию.
Обычно поэтапно проводится:
| Тип тестирования | Описание |
|---|---|
| Дымовое | Проверка, что сборка встала корректно и основные функции приложения работают как ожидалось. |
| Функциональное | Детальная проверка функциональных возможностей приложения на соответствие требованиям. |
| Нефункциональное | Проверки производительности, безопасности и удобства использования системы. |
| Регрессионное | Проверяется, что новые изменения и исправления не привели к нарушению работы уже существующего функционала. |
Параллельно с этим проводится нагрузочное тестирование, часто отдельной выделенной командой тестирования.
Каждый из типов тестирования рассмотрим подробно и попрактикуемся далее.
Разработчики добавили номер версии сборки на сайт кота-астронавта. Таким образом, тестировщики теперь точно могут определить развернутую версию.
Уровень повышен!