Join Yalantis and get a $1000 sign-in bonus! React.js, React Native, Python, Java, DevOps, BА. Apply now!
×Закрыть

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

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

Меня зовут Алексей Чаплиц. Имея за плечами более 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, согласился бы я на это?».

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

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на тему «тестирование»
LinkedIn

Похожие статьи

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Интересный обзор, спасибо

Спасибо вам, Дмитрий.

— Почём апельсины?
— Ответила в личку

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

Алексей, сорри, а этот комментарий к моей статье?

Ага. Прайсинга на сайте нет, зато есть «оставьте заявочку»

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

В переводе с русского на русский это значит, что первый же конкурент, предложивший цену, окажется в более выгодной ситуации. Почему так: всё познаётся в сравнении. А любое сравнение с null завсегда даёт false.

В основном согласен с вашей аргументацией. Отсутствие «открытой» цены служит определенным фильтром. Однако, как показывает 300+ корпоративных клиентов фирмы, на любой товар есть свой покупатель.

Как вы думаете, почему у них такой подход к маркетингу, если в результате эффект отторжения?

Я не спорю, что есть покупатель. Но к такому покупателю придётся идти самому, и тут уже предлагать цену. И не факт, что удастся получить адекватную — обычно покупатель платит выше если считает что инициатива всё же его.

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

Спасибо, за комментарий, Anre. Я допускаю, что мало кто в Украине работал с этим инструментом. Поэтому я решил написать про мой опыт. Может кому-то в будущем пригодится.

Автоматической интеграции с Jira, которую вы описали я не имел. Делал все вручную. Информации (время, частота, видео) было достаточно для разработчиков.

Еще вопрос, если говорить о VOD, то там все более-менее ясно, потому как все можно сказать статично. И настроив тест единожды на нужное видео можно его юзать до бесконечности пока доступен файл. А как обстояли дела с проверкой Live-стримов, там же невозможно предугадать какие параметры будут у потока?

И еще в догонку я так понимаю тул годится только для тестирования SetTopBox, как насчет web и mobile?

Да. Web и mobile тоже можно тестировать с помощью Witbe.

Я проверял наличие графических элементов и функциональные части UI приложений во время стримов. К сожалению, алгоритмы распознавания (см. функционал № 4) не всегда справлялись с этим. Кроме того, эти и UI элементы меняли свое положение.

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

То есть выходит что против лайва он почти бесполезен. Я тестил схожий проект, у нас там была целая армия мануальщиков, все быловручную, хотя команда автоматизации что-то тоже писала на Python, но в осноаном они были заняты фиксацией самих тестов)

Что вы имеете ввиду под «тестированием лайв-стрима»?

Если вы имеете ввиду то, что показывается на экране, то инструмент отслеживал появление логотипа канала, а также проверку «живого» стрима (покадровое изменение изображение) во время теста.

Если вы имеете ввиду зависание картинки или черный экран, то это делалось на этапе «горячего» рестарта приставки перед каждым тестом, наподобие запуска браузера в тестировании вебприложений. Особенный тест на переключение каналов тестировал появление видео- и аудиосигнала.

Если вы имеете ввиду вход и выход из стиминговых сервисов вроде Ютюба или Нетфликса с проверкой живой картинки, то инструмент это делал. Тоже самое работало для онлайн-радио и тизеров для VoD и самих фильмов.

Цель проекта была автоматизировать регрессионные кампании, которые гонялись руками два раза в после релиза и его хот-фикса. Те тесты, которые нельзя было автоматизировать, тестировали руками.

П.С. Вы правы в вашем наблюдении о том, что много времени уходит на поддержании тестов в рабочем состоянии. Об этом я упомянул в моем анализе утверждений производителя 1 и 2.

Тестов было вагон и маленькая тележка, стратегии что автоматизировать особой не было, сперва 1 автоматизатор варился в отдельном котле на С#, затем его сменили на целую команду пайтоновцев, но тоже отдельно и все было исключительно в среде разработки. Замена профита особого не принесла. Релизились приблизительно 1 в месяц, с такой же периодичностью полная регрессия, потому ручники бы были благодарны за автоматизацию хотя бы части, но увы этого так и не случилось. А под тестированием лайв-стрима кроме перечисленного что сложно предугадать это к примеру ввод PIN для родительского контроля — в случае с VOD фильмом или каналом 18+ это можно сделать, но как предугадать какой будет возрастной ценз у передачи которая вот только что появилась в программной сетке. Или другой пример как узнать разрешен или нет у этой передачи софт и хардзаппинг? Как узнать будут или нет доступны для лайва субтитры? При переключении языка как убедится что аудиопоток действительно переключился на лету? Да наверняка это можно все автоматищировать подобными тулами, но учитывая цену на лицензию, возможно поэтому это и было передано на аутсорс (собственно как и сама разработка) в восточную Европу, пока что естественный интеллект обходится дешевле искуственного)

Anre, I feel your pain. Насчет «предугадать»... Думаю, секрет, как вы правильно заметили, в анализе, отборе и дизайне тестов как части стратегии автоматизации.

А «непредвиденные» моменты — это unknown known риск. Я озадачился тогда тем же и сделал анализ по рискам. Как? Посмотрите мою статью по exploratory testing. Риски, которые вы назвали, не оказались ни на одном из радаров стейкхолдеров. Причина? За контент и за субтитры отвечали поставщики этого сервиса — третья сторона. У нас были с этим иногда проблемы, но они сразу решались менеджерами продукта. Так, что меня миновали эти переживания.

Подписаться на комментарии