Меня зовут Иванов Александр, я тестирую приёмники цифрового телевидения в GS Labs.
В статье расскажу о том, как наша команда набралась смелости и сменила неудобный и дорогой TestRail на новый инструмент управления тестированием. Статья содержит описание этапов переезда тестов и автотестов, настройку нового инструмента, а также непосредственное описание процессов тестирования ТВ-приемников и их программного обеспечения.
Обо мне: за время работы в компании прошёл путь от тестировщика до ведущего инженера по тестированию. Время от времени выступаю с докладами на конференциях для тестировщиков.
GS Labs — разработчик комплексных решений для формирования экосистем создания и доставки цифровых продуктов на основе собственных технологий. Продуктами GS Labs пользуются более 12 млн. абонентов телеком операторов России, СНГ, странах Восточной и Юго-Восточной Азии.
Объект тестирования
Телевидение появилось в начале XX века и с тех пор непрерывно развивается. С переходом от аналогового вещания к цифровому телевидение открыло для себя новые горизонты. Развитие микропроцессорной техники позволило создавать программно-аппаратные решения для приёма и просмотра цифрового ТВ-контента.
По среде передачи контента цифровое ТВ можно условно поделить на:
Эфирное,
Кабельное,
Спутниковое,
IP-телевидение.
Для приёма, а также для дальнейшего дешифрования контента может использоваться приёмник цифрового телевидения (set-top-box, STB). Для обработки цифрового контента приёмник использует собственное ПО. Сама приставка, а также её ПО являются объектом разработки и тестирования в GS Labs.
Тестирование приставок
Как уже было сказано, современный ТВ приёмник имеет собственное ПО. Главное задачей ПО приёмника является расшифровка контента, передаваемого в зашифрованном виде. Для успешной расшифровки абонент должен приобрести у оператора подписку на соответствующий пакет телеканалов.
Кроме самого контента оператор транслирует рекламу от сторонних клиентов, которая также должна корректно отображаться приёмником. Существует также дополнительная информационная поддержка абонентов, которая время от времени сообщает абонентам о профилактических работах на головной станции, обновлениях приемников и другую информацию в зависимости от нужд оператора.
Как и любое ПО, ПО приёмника тоже необходимо тестировать.
Описание тестового стенда
Для тестирования используется стенд, идентичный тому, что есть у оператора. Тестовые стенды включают головное оборудование, наиболее распространенное в России: Harmonic, Teleste Luminato, WISI, Ericsson, PBI.
Главным элементом стенда является мультиплексор (далее MUX). MUX представляет собой комбинированное цифровое устройство, обеспечивающее поочередную передачу на один выход нескольких входных сигналов. Он нужен для того, чтобы создавать “каналы по своему усмотрению”: добавлять к исходному контенту звуковые дорожки, телетекст, рекламу, а также шифровать средствами системы условного доступа (СУД), которая также заведена на MUX. И сервер СУД, и другие вспомогательные сервера, как правило, представляют из себя виртуальные машины.
Тестовые данные можно условно поделить на:
конфигурации (live emulation). Является эмуляцией ТВ-трансляции;
потоки (stream). Записанная ТВ-трансляция.
Тестирование осуществляется как на потоках, так и на конфигурации. Главный плюс конфигурации — всегда имеем дело с последней версией серверов, однако требуется регулярное их обновление. Главный плюс потоков — простота использования, не требуется настройка серверов, всё уже настроено и может быть переиспользовано бесконечное число раз. Однако в этом случае невозможно использовать последнюю версию передающей части.
Приблизительная схема тестового стенда представлена на рисунке 4. При ручном тестировании приёмник подключаем к источнику сигнала (live emulation или stream), изображение передаётся с приёмника на телевизор, например по HDMI-кабелю. С помощью пульта ищем сигнал, переключаем каналы и проверяем функциональность ПО приставки.
Тест-кейс будет зависеть от функциональности, которую тестируем. Разные команды отвечают за разные функции приёмника. Например, если это тестирование СУД, то кейс, проводимый на потоке, будет выглядеть как на таблице ниже.
Автоматизация тестирования
Как и в любом тестировании ПО, у нас тоже стоит задача автоматизации наших тест кейсов.
Большинство плюсов и минусов автоматизации те же, что и для любой автоматизации, будь то клиент-серверные или мобильные приложения.
Плюсы:
скорость
обеспечение повторяемости
снижение трудозатрат на тестирование
Минусы:
стоимость
эффект “пестицида”
необходимость регулярной поддержки автотестов
Наши автотесты написаны на Python 3 с использованием библиотеки Behave. Для автоматизированного взаимодействия с приёмником используется API (вместо пульта при ручном тестировании), которое регулярно дорабатывается и улучшается.
Для хранения тестов за всё время было перепробовано много вариантов: Excel, Test Log, TestRail. Наиболее удачной системой на тот момент стал TestRail.
Во время выполнения автотестов, их результаты переносились в TMS через поле autofunction_name, вернее через числовой префикс в начале имени (наследие более старых TMS систем). От использования поля name было решено отказаться, т.к. подразумевалось, что название может меняться.
Итого имеем следующие поля (на примере одного из автотестов):
name | Broadcast infocas |
autofunction_name | 01_01_Broadcast infocas |
automated | yes |
Как выглядит соответствующий автотест:
@short_term
Scenario: 01_01_Broadcast infocas
Given we switch to channel "12" on "server"
When we send "broadcast" infocas message "Broadcast Test Infocas" for test "01_01"
Then we "see" infocas message displayed for test "01_01"Как видно из приведённого в качестве примера теста, он написан с использованием BDD. Каждая из строчек, написанных на “естественном” языке, подразумевает под собой некий код, написанный на языке программирования, а значения, взятые в кавычки, передаются в качестве параметров. Таким образом, для написания автотестов не требуется знание языков программирования, главное знать тестируемую функциональность. В целом, встречал неоднозначное отношение к использованию BDD: у подхода есть сторонники и противники. Я себя не причисляю ни к тем, ни к другим, однако отмечу, что в нашем случае подход себя оправдал. Ручные тестировщики принимают активное участие в написании автотестов, т.к. тестируемых функций довольно много и команде автоматизации практически невозможно разобраться в нюансах каждой из них.
По окончании тестирования формировался отчёт средствами TMS.
Смена инструмента для тестирования
Сменить привычный TestRail, перейдя на другую систему управления тестированием, нас побудило простое человеческое “дорого”. В связи с этим мы провели обзор существующих на момент 2019 года систем. По совокупности нескольких факторов выбрали новую российскую разработку Test IT. Начав использовать новую TMS мы обнаружили и другие ее преимущества, например, автоматическое формирование отчетов в дашбордах.
Сам переезд занял около месяца. В 2021 году в Test IT уже все просто: импортируйте тестовую модель в .xls, соотносите любые необходимые поля и тестируйте на здоровье, но в конце 2019 года данная функциональность еще не была реализована.
В несколько этапов мы выгрузили тесты в *.xml и успешно импортировали в Test IT. И тут возник вопрос, как переносить результаты автотестов — при ручном тестировании подобных вопросов не возникало, скорее, были вопросы, как генерировать отчёт и какие поля включать.
Как выяснилось позже, поле autofunction name, которое мы использовали, не может быть перенесено в Test IT для обозначения результатов, но может использоваться uuid автотеста. Решение нашли: зная uuid автотеста, можно получить его имя и использовать для переноса результатов. Числовой префикс переехал в название тест-кейса. Далее к каждому автоматизированному сценарию был прилинкован автотест с аналогичным названием. В итоге сами автотесты остались без изменений, за исключением вспомогательного модуля по переносу результатов в TMS Test IT.
В итоге имеем поля:
name | 01_01_Broadcast infocas |
Сегодня все новые кейсы пишутся в самой TMS. Здесь удалось на практике использовать функциональность общих шагов и возможность указать результат каждого из них в тест кейсе. Это позволило ускорить написание кейсов и облегчить работу с ними для новых сотрудников.
Появилась возможность отследить историю прохождения тест-кейсов, на основании этого можно обнаруживать нестабильные автотесты и иметь представление о возможных багах в ПО приёмников цифрового ТВ.
По завершении тестирования генерируется отчёт, автоматически создаваемый в Test IT, фрагмент которого можно увидеть на рис.5.
Заключение
Смена TMS системы всегда требует определённых трудозатрат. Очень важно, чтобы процесс проходил максимально легко и быстро, и не критично сказался на скорости выпуска релизов и качестве продуктов.
Ещё до начала переезда на новую систему команда разработчика провела несколько обучающих презентаций в нашем офисе, на которых мы заранее задали интересующие вопросы. Считаю, что подобные презентации помогли процессу переезда на новую TMS.
Бесспорно, нам самим тоже пришлось разобраться, изучить API, по необходимости писать в поддержку. Главный итог в том, что нам удалось без особых проблем переехать на новую TMS. Что касается улучшения текущих процессов — для понимания этого в полной мере ещё потребуется время. Но уже можно отметить: новый инструмент помогает быстрее и удобнее создавать тест-кейсы и позволяет наглядно отслеживать историю их выполнения.