Знакомьтесь, это — Witbe! Заметки об автоматизации контроля Quality of Experience

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

«Сделал свое дело, напиши статью»
Анатолий Пласковский,
Рук. отдела нагрузочного тестирования
«Яндекс.Деньги»

Меня зовут Алексей Чаплиц. Имея за плечами более 20 лет опыта с людьми, я стал тестировщиком ПО три года тому назад. Больше о том, как и почему я стал Software Tester и к чему стремлюсь, можно узнать из моего интервью ведущим подкаста QAGuild.

На написание статьи меня вдохновили:

• Слова А. Пласковского (см. выше)
• Подкаст/видео с создателем инструмента визуального тестирования интерфейсов Павлом Стрункиным
• Затянувшийся вынужденный «отпуск»
• Мой «уникальный» опыт работы с инструментом (поправьте меня, если я ошибаюсь)

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

Краткая предыстория

Меня познакомили с Witbe на пилотном проекте по автоматизации регрессионных тестов ТВ-приложения для приставки мультимедийных потоков (Streaming Media Box). Контекст проекта и пару моих задач я описал в своей статье об исследовательском тестировании.

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

1. Представление инструмента: кто, что, почему и как это работает, включая описание функционала, с которым я работал;
2. Анализ утверждений производителя через призму моего опыта.

В каждом из этих пунктов постараюсь быть исчерпывающим, но и кратким. Эффективность использования инструмента с точки зрения бизнеса я вынес за рамки статьи. Выводы и наблюдения я предлагаю вам сделать самим и поделиться ими в комментариях.

I. Witbe: Кто, что, почему и как это работает

Ниже я приведу краткий обзор основных понятий и справку о производителе. Для любителей «покопаться» скажу: эта информация взята с сайта фирмы и материалов обучения. Вы можете познакомиться с ней, пройдя по ссылкам в тексте.

О производителе

Компания Witbe была основана в 2000 г. во Франции. С помощью их решений более 300 корпоративных клиентов компании могут контролировать качество любого сервиса (IP-телефонии, видеосигнала, веб-приложения), на любом устройстве (компьютере, смартфоне, мультимедийной приставке) и в любой сети (кабельной, сотовой, интернет).

Несколько корпоративных клиентов Witbe

Для этого компания разработала технологии и оборудование автоматизации контроля QoE (см. определение ниже), воспроизводящих реальные действия пользователя. Стоимость лицензии за пользование оборудованием, инфраструктурой и ПО стоит несколько десятков тысяч евро в год. В эту стоимость входит возможность передать их команде создание скриптов и мониторинг результатов тестирования.

Штаб-квартира Witbe находится в Париже, а филиалы в Нью-Йорке, Сан-Хосе, Денвере, Монреале, Лондоне и Сингапуре.

Что такое QoE?

QoE является аббревиатурой Quality of Experience (пер. с англ. «качество опыта») и обозначает некую степень удовлетворения пользователя услугами, предоставленными телеком-провайдером. Для этого существуют определенные параметры (см. ниже).

QoE отличается от QoS, аббревиатуры Quality of Service (пер. с англ. «качество сервиса»), тем, что второй термин обозначает качество производительности сети и измеряется техническими параметрами, т.к. приоритезация трафика и тд.

Почему надо контролировать QoE?

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

Однолинейная доставка видеосигнала по кабельной сети

C развитием интернета количество путей и сетевых мощностей, способных доставить сигнал на различные устройства возросло. Соответственно, появилась необходимость в контроле Quality of Experience в конце каждого такого пути.

Многолинейная доставка видеосигнала по различным сетям

Зачем ещё обращать внимание на QoE? Встать на место потребителя телекоммуникационных услуг необходимо с точки зрения бизнеса, успех которого зависит от того, останется ли клиент с ним или перейдет к другому провайдеру. Как говорится, happy customers — happy business.

Как это работает

Упрощенное представление организации контроля QoE приложений мультимедийных приставок состоит из трех процессов: Setup — Testing — Monitoring.

Setup — Подключение оборудования

Подключение осуществляется в серверной или тестовой лаборатории провайдера для нескольких мультимедийных приставок с разными версиями приложения ПО. Датчики инфракрасного излучения ПУ крепятся прямо на приемник сигнала в приставках, которые по отдельности изолируется от стороннего ИК-сигнала.

Подключение видеоробота Witbe к остальному оборудованию

Подключение тестировщика к тестовой и мониторинговой платформе Witbe, а через нее к видеороботу и приставкам осуществляется с помощью VPN и интерфейса Workbench (см. описание ниже) на лэптопе.

Экосистема для тестирования мультимедийных приставок. Приставка обведена синим кругом (уровень Witbe robots). Красный треугольник представляет зону ответственности тестировщика. Лэптопы с установленным Workbench представлены слева на синем «столе»

Testing — Тестирование ТВ-приложения

Как и какие параметры QoE можно мониторить с помощью Witbe? Платформа позволяет контролировать качество сервиса по трем параметрам:

• Availability — Доступен ли сервис?
• Performance — Возросло ли качество сервиса?
• Integrity — Доступен ли обещанный сервис?

Для этого в скрипты тестов надо встроить соответствующие проверки, Availability и Performance KPIs, VQ-MOS (Video Quality Mean Opinion Score) и VQ-ID (Video Quality Incident Detection) и т.п., данные которых выводятся в Datalab — мониторинговую платформу на основе Grafana. О ней я расскажу ниже. Кроме того, Remote Eye Controller (REC) позволяет визуально контролировать картинку каналов и управлять до 200 приставками одновременно.

Что служило объектами контроля в моем случае? Это были бесплатные и платные ТВ-каналы, онлайн-радио, а также арендуемые фильмы (Video-on-Demand) и стриминговые сервисы (Over-The-Top), например, Netflix. Их контроль я осуществлял с помощью Workbench.

Workbench

Workbench (пер. с англ. «стенд для автоматизации тестирования») — основный интерфейс для создания и запуска автотестов. Далее я коротко опишу четыре основных функционала, с которыми я работал: Script Writer, Resource Manager, Scheduler, а также алгоритмы, которые используются в четвертом функционале Capturer.

Функционал 1: Script Writer

Этот функционал имеет возможности для создания и анализа кода и создания одиночных сценариев или кампаний.

Одиночный сценарий создается с проверками наличия сервисов и их качества, данные которых передаются на панель мониторинга Datalab.

Так выглядят блоки скриптов одиночного сценария в Workbench

Тестовые кампании создаются с помощью блоков уже готовых одиночных сценариев.

Так выглядит тестовая кампания в Workbench

Функционал 2: Resource Manager

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

Интерфейс Resource Manager для конфигурации проверок и окружения

В Resource Manager также можно найти стандартные и «подтянуть» новые библиотеки, функции и модули скриптов на Python, включая модуль введения логина и пароля с виртуальной клавиатуры, имитирующей клавиатуру ПУ.

Подраздел Resource Manager для конфигурации библиотек скриптов, функций и модулей

Функционал 3: Scheduler

C помощью интерфейса Scheduler можно запускать одиночные тесты и кампании.

Интерфейс Scheduler для создания расписания и запуска тестовых кампаний

При их настройке важно давать достаточно времени на прогон теста, правильно стыковать тесты внутри кампании и проверять порядок написания дней недели для запуска тестов в Crontab.

Функционал 4: Capturеr

Capturer используется для покадровой записи и алгоритмического определения визуальных элементов на экране. Его обзор стоит начать с краткого описания алгоритмов распознавания формы, цвета и текста, которые помогают достичь стабильности тестов.

Существует три основных типа алгоритмов:

• Алгоритмы определения формы (shape-based algorithms): Logo, Fuzzy, Blend. Они высчитывают расстояние между пикселями в поле образца, покадрово записанного с помощью Capturer, чтобы затем сравнить его с результатами такого же расчета, но уже во время прогона теста. Алгоритмы проверяют наличие логотипов каналов и т.п. на экране. Установка порога точности определения элемента в диапазоне от 80 до 90% на этапе покадровой записи образца позволяет избежать false positives во время теста.
• Алгоритмы определения цвета (color-based algorithms): Mean Color, Grid и Uniform. Они высчитывают разницу между неким значением цвета поля в кадре образца и цветом поля в кадре во время прогона теста. Алгоритмы проверяют наличие сплошного цвета на участке экрана. Выбор небольших участков со сплошным цветом, отличным от фонового, а также установка порога точности его определения в диапазоне от 45 до 90% позволяет избежать false positives.
• Алгоритмы определения текста (text-based algorithms): OCR и Poster. Первый алгоритм имеет два варианта исполнения: 1) он работает как regular expression, т.е. определяет текст независимо от букв до и после искомого текста, и 2) он высчитывает расстояние между элементами текста. Второй алгоритм работает подобно алгоритмам определения формы, но с тем отличием, что находит и запоминает ключевые точки объекта, например, киноплакат в разделе аренды фильмов. Стабильность тестов можно повысить с помощью бинаризации цвета (ч/б) на этапе покадровой записи образца.

Чаще всего я использовал первый и третий типы алгоритмов для верификации форм и текста в элементах ТВ приложения.

Элементы интерфейса Capturer для покадровой записи образца, определения и проверки наличия текста с помощью алгоритма OCR

Monitoring — Визуализация результатов тестирования

Результаты тестов можно посмотреть в трех местах: Workbench, Datalab и Witbe Portal. Последний является резервной платформой.

На панелях мониторинга в Workbench и с Witbe Portal есть доступ к текстовым и видеологам.

Встроенная в Workbench панель мониторинга результатов. Синие кнопки — линки к текстовым и видеологам тестов

Существует также возможность самостоятельно сформировать «свою» платформу — панель мониторинга на основе Grafana. На ней можно также настроить доступ к видеологам тестов, которые легко скачать и вставить в качестве тестовых артефактов в тикетах в Jira.

Панель мониторинга Datalab с виджетами для визуализации результатов тестов

Виджеты можно создать на основе JSON-файла, которым обеспечивает производитель, а её настройки — с помощью скрипта SQL. Таким образом, можно визуализировать три основных показателя контроля QoE — Service Availability, Service Performance и Service Integrity.

С расширенным описанием технического функционала и его сравнения с функционалом подобных инструментов можно познакомиться здесь.

II. Их «claims» — мои «gains/pains»

В этом разделе я проанализировал 9 утверждений («claims») производителя об инструменте и его окружении (см. больше инфо здесь и здесь). Конечно, я это сделал через призму моего короткого опыта знакомства с инструментом и работы в тестировании. Анализ представлен по схеме их «claim» — мой «pain/gain». Всего вышло 2 pains (что для меня было тяжело), 7 gains (что для меня было просто/полезно).

Анализ первого утверждения

Claim: Witbe разработала масштабируемую и простую технологию для высвобождения времени и энергии тестировщика на другие задачи.

Pain: Здесь у меня смешанные чувства. С одной стороны овладение основными функциями далось относительно легко. С другой стороны поддержка стабильности скриптов тестовых сценариев и визуализация их результатов — непросто.

Анализ второго утверждения

Claim: Технология Witbe позволяет создавать тесты, которые имитируют реальные действия пользователя.

Gain: Правда. Тесты, пусть иногда и громоздкие по размеру и времени создания и доводки до ума, покрывали такие сценарии.

Анализ третьего утверждения

Claim: Интуитивный интерфейс Witbe упрощает написание скриптов автотестов.

Gain: Правда. Графический интерфейс Script Writer — интуитивный. Готовые модули и функции существенно экономят время для создания простых/базовых скриптов.

Анализ четвертого утверждения

Claim: Технология OCR (Optical Character Recognition) от Witbe способна определять текстовые элементы на экране в покадровом режиме для цветных и бесцветных пользовательских интерфейсов ТВ-приложения.

Gain: Да. Бинаризация цвета при покадровой записи в этом сильно помогает. Однако это работает только с тремя языками.

Анализ пятого утверждения

Claim: Видеороботы Witbe собирают и передают в бесперебойном режиме KPI тестов (MOS, Services Availability, Visual Zapping Time и т.п.) на панели мониторинга в Workbench и Datalab.

Gain: Правда. В случае, если Datalab была недоступна, результаты тестов можно было проверить в Workbench или на дополнительной платформе Witbe Portal. Однако текстовые логи были длинными, а аналитика уровня единичных каналов не была востребована менеджерами.

Анализ шестого утверждения

Claim: Witbe имеет возможность настроить систему оповещения перебоев сервисов.

Gain: Да. Для этого было предусмотрено несколько каналов для оповещений.

Анализ седьмого утверждения

Claim: Witbe позволяет прогонять одни и те же тесты на нескольких (макс. кол-во 8 шт) мультимедийных приставках одновременно. Сравнение видеологов «упавшего» и успешного теста на разных приставках с одной и той же версией помогает «вычислить» false positive.

Gain: Да, это в принципе возможно. Однако «ловить» таким образом false positives мне не приходилось из-за ограничения в количестве выделенных приставок.

Анализ восьмого утверждения

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

Gain: Правда. У меня был позитивный опыт сотрудничества, как с тренером-членом команды тестировщиков, так и с консультантом Witbe в формате «лицом к лицу» и удалённо.

Анализ девятого утверждения

Claim: Техподдержка отвечает в режиме реального времени.

Pain: В подавляющем большинстве случаев мои проблемы решались, но с задержкой. Почему служба не реагировала на некоторые тикеты мне не всегда было известно. Однако для самостоятельного решения проблем у меня был доступ к техдокументации «Witbepedia».

В заключение

Я надеюсь, что обзор Witbe, «незнакомого» инструмента автоматизации контроля Quality of Experience, вышел доступным и познавательным. Он был сделан с точки зрения тестировщика. Польза для бизнеса здесь не рассматривалась.

В процессе написания статьи я имел возможность мысленно вернуться к своему опыту и дать положительный ответ на вопрос «Если бы у меня была возможность снова работать с Witbe, согласился бы я на это?».

Мне бы хотелось бы также узнать о вашем опыте работы с подобными инструментами. Спасибо!