Добро пожаловать на борт нашего корабля. Сегодня отправляемся в небольшой круиз по загадочным водам тестирования в телекоме. Мы бросим якорь в самых интересных местах, чтобы изучить глубоководный мир, а также закинем сети в поисках самых интересных артефактов, созданных QA-инженерами. Ну а перед тем как сойти на берег — проведем короткую тренировку по карате прямо на палубе.

На связи Иван Политов и мой коллега Антон Васин, инженеры из департамента разработки и проектирования опорной 5G-сети в YADRO. В статье мы подробно расскажем о подходах к тестированию телеком-продуктов в нашей компании и инструментах — как сторонних, так и собственных.

 Наш дивизион Телеком разрабатывает:

• базовую станцию и контроллер базовых станций стандарта GSM,

• базовую станцию стандарта LTE,

• опорную сеть пятого поколения (5GC),

• систему управления сетью (NMS).

Разберемся, как устроен процесс создания телеком-продуктов. Схематично его можно показать так:

Как и в случае с любым другим продуктом, все начинается с требований. В нашем случае они поступают от заказчиков — операторов связи. В требованиях описывается, какой функционал должен выполнять тот или иной продукт. Затем менеджеры по продукту совместно с архитекторами обсуждают эти требования и формируют дорожную карту, в которой описаны сроки поставки продукта или отдельной функциональности.

Следующий этап — декомпозиция верхнеуровневых требований на пользовательские сценарии (user scenarios), в которых функциональность описывается с точки зрения пользователя. В процессе участвуют системные аналитики, которые фиксируют низкоуровневые требования. Также в проработке требований участвует QA-команда.

Для некоторых продуктов, таких как базовая станция, необходимо решать нетривиальные алгоритмические задачи. Один из характерных примеров — процесс выделения радиоресурсов. За него отвечает планировщик (scheduler), который реализуется каждым производителем по-своему. В решении таких задач участвуют инженеры-исследователи из департамента алгоритмов и моделирования.

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

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

Как устроено тестирование в дивизионе Телеком

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

• Контроль качества (Quality Control, QC) — совокупность действий, проводимых над продуктом в процессе разработки, для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску», «соответствие зафиксированным требованиям», «соответствие заявленному уровню качества продукта».

• Обеспечение качества (Quality Assurance, QA) — совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения нужного качества выпускаемого продукта. 

Эти понятия часто путают, хотя между ними есть принципиальное различие. QA охватывает процессы и практики разработки, а QC — результат разработки, то есть готовый продукт. 

Об эволюции подходов к тестированию за 70 лет и работе тестировщиков в телекоме читайте в статье Алексея Нелюбова, старшего консультанта по гибким методам разработки в YADRO.

Есть множество видов тестирования, их классифицируют по различным признакам: уровню, целям, степени автоматизации, знаниям о системе, а также типу проверяемых сценариев (функциональные и нефункциональные):

При разработке базовых станций GSM/LTE тестирование проводится на нескольких уровнях.

Расскажем подробнее о реализации разных видов тестов, которые проводятся в лабораторных условиях: 

• Модульные (unit) и компонентные (component) тесты реализуют сами разработчики. Они позволяют проверить корректность работы отдельных модулей и компонентов на ранней стадии.

• Бокс-тестирование предполагает интеграцию нескольких компонентов базовой станции в рамках единой среды. В этом режиме используются симуляторы пользовательских устройств и ядра сети. 

• Системное тестирование охватывает проверку сквозных (end-to-end) сценариев на реальной аппаратной платформе. В отличие от бокс-тестов, здесь задействуются реальные пользовательские терминалы и максимально приближенная к коммерческой опорная сеть.

• Нагрузочное тестирование и тестирование стабильности позволяют оценить работу системы под высокой нагрузкой в течение длительного времени. Это важно для подтверждения отказоустойчивости и стабильной производительности.

Выделим полевое тестирование. Оно позволяет проверить поведение базовой станции в реальных радиоусловиях. В рамках таких испытаний выполняются drive-тесты, снимаются замеры уровня сигнала, а также тестируются сценарии переключения абонентских устройств между различными базовыми станциями (handover).

Для проведения лабораторных испытаний используется специализированный тестовый стенд. Он включает в себя:

• BBU (Baseband Unit) — «мозг» базовой станции: обрабатывает цифровые сигналы, управляет радиоресурсами и координирует протоколы мобильной связи. 

• RRU (Radio Remote Unit) — выносной радиомодуль, который принимает и передает радиосигналы,

• симуляторы пользовательского терминала и опорной сети.

Базовая станция — один из самых сложных компонентов в телеком-оборудовании. Особенно это касается реализации и тестирования механизмов выделения ресурсов и реализации процедур мобильности. Один из ярких примеров — процедура handover, то есть переключение  пользовательского устройства между базовыми станциями без потери сеанса связи.

Наши коллеги из команды тестирования базовой станции LTE написали подробную статью о нюансах и сложностях при тестировании процедуры handover. 

Важный аспект работы мобильной сети — взаимодействие между технологиями радиодоступа (3G, 2G, LTE). Пример — процедура CSFB (Circuit Switched Fallback), которая перенаправляет телефон, подключенный к 4G-сети, в 2G- или 3G-сеть для звонка. 

Полевое тестирование — одно из самых интересных видов тестирования. Оно позволяет в реальных радиоусловиях с реальными абонентскими терминалами протестировать описанные выше процедуры. Для такого тестирования используется специальный автомобиль, в котором установлено оборудование для проведения drive-тестов.

Во время drive-тестов используются разные модели пользовательских устройств. Это важно для нормализации результатов и получения объективной оценки поведения системы при работе с многообразием смартфонов.

Как мы тестируем «Якорь»

При чем тут какой-то «якорь»? YACORE — это наше название опорной сети пятого поколения, сокращение от YADRO 5G Core Network. Вот его упрощенная схема:

Основные компоненты, участвующие в обработке пользовательского трафика и управлении сессиями:

• AMF (Access and Mobility Function) — отвечает за процедуры, связанные с регистрацией и мобильностью абонентов в сети.

• SMF (Session Management Function) — занимается процедурами управления абонентских сессий.

• UPF (User Plane Function) — обеспечивает обработку и маршрутизацию абонентского трафика.

• AUSF (Authentication Server Function) — отвечает за аутентификацию абонентов в сетях 5G.

• UDM (Unified Data Management) — управляет данными профилей абонентов.

• UDR (Unified Data Repository) — отвечает за хранение абонентских данных.

• UDSF (Unstructured Data Storage Function) — хранит неструктурированные данные, которые генерируют сетевые функции. Например, хранение сессионных контекстов SMF для обеспечения непрерывности обслуживания в случае выхода из строя одной сетевой функции из группы сетевых функций (SMF set, AMF set, NRF set).

• PCF (Policy Control Function) — занимается политиками и правилами тарификации абонентских сессий.

• CHF (Charging Function) — отвечает за тарификацию потребленного абонентом трафика и управление выделяемыми квотами.

• NRF (NF Repository Function) — отвечает за хранение профилей сетевых функций, развернутых в сети оператора.

• SCP (Service Communication Proxy) — выступает посредником в коммуникации между сетевыми функциями. 

Читайте подробнее о том, как мы в YADRO разрабатываем опорную сеть 5G.

При разработке опорной сети пятого поколения тестирование также проводится на нескольких уровнях (разработки, продукта и конкретной функции продукта):

• Модульные тесты пишут сами разработчики. Их цель — оперативная проверка работоспособности разрабатываемых модулей.

• Компонентное тестирование выполняют инженеры по тестированию. В нашем случае объектом тестирования выступает конкретная сетевая функция, например AMF, NRF или SMF.

• Бокс-тестирование — это проверка взаимодействия нескольких сетевых функций между собой. В тестах используются симуляторы пользовательских устройств и базовых станций. 

• Системное тестирование охватывает сквозные (end-to-end) сценарии с использованием реальных устройств. Оно позволяет проверить корректность работы всей системы в условиях, максимально приближенных к боевым, и работу с сетевыми функциями других производителей с реальными gNB и мобильными станциями, а также взаимодействие с системой управления сетью (NMS).

Как каратисты яхту строили

Раз уж есть YACORE — должен быть и корабль. Так родился проект YACTA — сокращение от YACORE Test Automation. Как и многие команды, мы любим звучные названия-аббревиатуры, особенно с отсылками к морской тематике.

YACTA — это сервис, включающий в себя фреймворк для автоматизации тестирования и набор инструментов. В него входят:

• образ Docker с набором необходимых внешних зависимостей,

• скрипты для запуска в разных режимах и пайплайнах,

• вспомогательные утилиты для управления и диагностики YACORE,

• инструменты для работы с VPP в условиях Docker и для микроразработки внутри него,

• инструменты для микроразработки внутри Docker,

• непосредственно код тестов (feature-файлы),

• все, для чего не нашлось подходящего места в других сервисах.

По всем правилами судоходства на яхте обязан быть капитан. Так появился YATI (Yacore Test Interface) — веб-сервис, разработанный на Python 3.11 с использованием Fast API. Его основная цель — облегчить работу с опорной сетью 5G в рамках автоматизированного тестирования и иметь возможность обращаться к ней как к HTTP REST API. 

YATI поддерживает массу функций, включая:

• работу с интерфейсами N2/N3,

• выполнение команд на удаленной машине,

• сбор трейсов, логов и метрик,

• преобразование (relay) http v1 ↔ http v2,

• phonebook training (он же — тренажер для Karate),

• управление симуляторами. 

В качестве инструмента исследовательского тестирования мы достаточно долго использовали Postman — это гибкий инструмент с удобным интерфейсом, который позволяет удобно работать с REST API. 

Когда мы приступили к выбору фреймворка для автоматизации, то протестировали Karate, который оказался таким же удобным и простым как Postman. 

Karate — фреймворк для автоматизации тестирования, который позволяет создавать тесты для API и веб-приложений. Его основное преимущество — простота. Фреймворк использует язык описания тестовых сценариев Gherkin, но при этом расширяет его функционал и позволяет «поиграть» в разработчиков: заводить переменные и вызывать функции. Преимущества Karate:

• синтаксис понятен даже людям без технического бэкграунда,

• легко отправлять запросы, проверять ответы и выполнять валидацию данных,

• простая интеграция с популярными инструментами для CI/CD,

• поддерживает тестирование веб-приложений с использованием встроенных возможностей для работы с Selenium.

В итоге мы получили весь набор возможностей, которые нужны уважающему себя AQA-инженеру.

Очередной новый фреймворк — это прекрасно, но когда же его учить? Мы понимаем, что каждый новый фреймворк требует времени для освоения. Поэтому в рамках YATI мы разработали небольшой тренажер для Karate — учебный веб-сервис, который имитирует телефонный справочник (тот самый phonebook из списка выше) со стандартными CRUD-операциями. Новый сотрудник получает задание автоматизировать тестирование этого сервиса и в понятном интерфейсе учится работать с фреймворком Karate. 

Как взаимодействуют YATI, YACTA и YACORE

После подробного описания отдельных компонентов вернемся к общей схеме архитектуры:

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

• взаимодействие YACTA и YACORE происходит через YATI,

• YATI предоставляет REST-интерфейс,

• при необходимости поднимаются моки для сервисов.

Без Docker — никуда

Все окружения работают в Docker, что обеспечивает воспроизводимость и масштабируемость тестов. Благодаря контейнеризации мы можем создавать изолированные среды (environments) индивидуально под каждого тестировщика. Каждому из них доступна собственная среда, в которой развернуты:

• YACORE,

• вспомогательные тестовые сервисы: YACTA и YATI,

• при необходимости, конкретная ветка, с которой работает тестировщик (для разработки, отладки или исследований).

Ранее для управления этим процессом мы использовали Jenkins. Были настроены job'ы для сборки контейнеров и запуска sanity-проверок. Однако со временем мы столкнулись с ограничениями Jenkins: жесткая структура конфигурации, сложность масштабирования, ограниченные возможности для кастомизации.

Так у нас появился собственный инструмент — TEM (Test Environment Manager). Это внутренняя альтернатива Jenkins, которая со временем выросла в полноценную систему. TEM управляет Docker-контейнерами, собирает окружение из нужных git-веток, а также позволяет просматривать список доступных контейнеров и их состояние.

Приходите на тренировку

Надеемся, что вам понравился небольшой круиз по телеком-тестированию с капитаном YATI на YACTA. Если остались вопросы — пишите в бортовой журнал комментариях или присоединяйтесь к нашей команде, будем вместе оттачивать технику карате:

→ QA Automation 
→ Test Engineer Manual 
→ Field Test Engineer (LTE/GSM)
→ SDET в 5G Core (Python)