Опыт участников Netflix основан на архитектуре микросервисов и персонализирован для каждого из более чем 80 миллионов наших участников.
Сервисы принадлежат разным командам (группам), каждая из которых имеет свой цикл разработки и выпуска.
Это означает наличие штатной компетентной группы интеграционного тестирования, которая обеспечит соблюдение сквозных стандартов качества в ситуации, когда микросервисы развертываются децентрализованно каждый день.
Как команда тестирования интеграции продуктов, мы обязаны идти в ногу с новыми инновациями, обеспечивая при этом контроль качества и быструю обратную связь с разработчиками.
Каждая команда разработчиков несет ответственность за качество поставляемого продукта.
Наша цель — беспрепятственно работать с различными техническими командами, уделяя особое внимание сквозной функциональности и координации команды.
Мы — небольшая команда специалистов по интеграционному тестированию в организации, насчитывающей более 200 разработчиков.
Быстрое внедрение новых разработок при обеспечении необходимого качества ставит перед нашей командой интересные задачи.
В этой статье мы рассмотрим три таких задачи: 1. Тестирование и мониторинг высокорейтинговых показов (High Impact Title = HIT = hit) 2. А/Б-тестирование 3. Глобальный запуск Тестирование и мониторинг высокорейтинговых показов Есть много шоу с высоким рейтингом, например телесериал.
«Оранжевый — новый черный» , которые регулярно появляются на Netflix. Форма и размер этих дисплеев очень разные.
Некоторые из них — сериалы, некоторые — отдельные фильмы; есть ориентированные только на детей; некоторые выпускают сразу все серии сезона, а другие выпускают по несколько серий каждую неделю.
Некоторые из этих шоу проводятся с использованием сложных A/B-тестов, в которых каждый элемент теста по-разному взаимодействует с участником.
Эти шоу пользуются большой популярностью среди наших участников и поэтому должны подвергаться тщательному анализу.
Тестирование начинается за несколько недель до запуска и продолжается постепенно до самого запуска.
После запуска мы отслеживаем эти показы на нескольких аппаратных платформах во всех странах.
Стратегия тестирования зависит от его фазы.
На разных этапах используются разные стратегии продвижения, что делает задачу тестирования/автоматизации довольно сложной.
В принципе, можно выделить два этапа: 1. Перед началом шоу.
Перед запуском необходимо убедиться, что метаданные дисплея находятся в нужном месте, чтобы в день запуска все прошло безупречно.
Поскольку в запуске хита участвует множество групп (команд), необходимо убедиться, что соединение всех внутренних (серверных) систем друг с другом и с клиентской частью пользовательского интерфейса происходит безупречно.
Шоу продвигается через Spotlight (большое окно в виде доски объявлений в верхней части главной страницы Netflix), тизеры и трейлеры.
Но поскольку персонализация существует на каждом уровне Netflix, необходимо создавать сложные наборы тестов, чтобы убедиться, что тип показа соответствует профилю участника.
Поскольку система постоянно меняется, автоматизация становится затруднительной.
Основное тестирование на этом этапе выполняется вручную.
2. После начала шоу.
Наша работа не заканчивается в день запуска.
Мы должны постоянно следить за ходом показов, чтобы впечатления участников никогда не ухудшались.
Шоу становится частью расширенного каталога Netflix, и это само по себе создает проблему.
Теперь мы должны написать тесты, которые проверят, продолжает ли шоу постоянно находить свою аудиторию и поддерживается ли целостность данных этого шоу (например, некоторые проверки проверяют, изменилось ли общее количество эпизодов с момента запуска; другая проверка проверяет продолжают ли результаты поиска возвращать шоу в правильные строки поиска).
Но только в этом году на Netflix было транслировано 600 часов оригинальных программ, а также лицензионный контент, поэтому мы не можем полагаться на ручное тестирование.
Кроме того, когда шоу запускается, мы можем сделать о нем общие предположения, поскольку данные для этого шоу и логика продвижения не изменятся - например, количество серий больше 0 для телевизионных серий, шоу с возможностью поиска (действительно, как для фильмов, так и для сериалов) и т. д. Это позволяет нам автоматически отслеживать, продолжают ли корректно работать те или иные операции, связанные с каждым показом.
Тестирование хитов является сложной задачей и требует времени.
Но участвовать в запуске шоу и следить за тем, чтобы все связанные с шоу функции и логика сервера работали правильно во время запуска, — это волнующий опыт. Просмотр фильмов знаменитостей и крутых рекламных материалов от Netflix также станет приятным дополнением.
:) А/Б тестирование Мы проводим множество A/B-тестов .
В любой момент времени проводится множество A/B-тестов с разным уровнем сложности.
Раньше большая часть проверки в A/B-тестах представляла собой комбинацию автоматического и ручного тестирования: автоматизация использовалась для отдельных компонентов (тестирование «белого ящика»), а сквозное тестирование (тестирование «черного ящика») в основном выполнялось вручную.
Когда у нас значительно увеличился объем A/B-тестов, вручную проводить все необходимые сквозные тесты стало невозможно, и мы начали повышать автоматизацию.
Одной из основных проблем при внедрении сквозной автоматизации A/B-тестирования было огромное количество компонентов, которые необходимо обрабатывать автоматически.
Наш подход заключался в том, чтобы рассматривать автоматизацию тестирования как поставляемый продукт и сосредоточиться на создании минимально жизнеспособного продукта (MVP), состоящего из частей многократного использования.
Нашим требованием к MVP было предоставить доказательство базового взаимодействия с участником путем проверки правильности данных из конечных точек REST различных микросервисов.
Это дало нам возможность итеративно двигаться к решению вместо того, чтобы искать лучшее решение сразу в начале.
Важнейшей отправной точкой для нас было создание общей библиотеки, которая позволила бы повторно использовать и перепрофилировать модули для любого автоматического теста.
Например, у нас был A/B-тест, который изменил «Мой список» участника; при автоматизации мы написали скрипт, который добавлял показы в «Мой список» участника или удалял показы из этого списка.
Эти сценарии были параметризованы таким образом, чтобы их можно было повторно использовать в любом будущем A/B-тестировании, связанном с «Мой список».
Такой подход позволил нам быстрее автоматизировать A/B-тесты с использованием большего количества повторно используемых строительных блоков.
«Эффективность работы была повышена за счет максимального использования существующей автоматизации.
Например, вместо того, чтобы писать собственную программу автоматизации пользовательского интерфейса, мы смогли использовать Тестовая студия Netflix переключаться между сценариями тестирования, требующими действий пользовательского интерфейса для разных устройств.
При выборе языка/платформы для реализации нашей автоматизации мы руководствовались необходимостью обеспечить быструю обратную связь с командами разработки продуктов.
Это требовало очень быстрой работы набора тестов — выполнение буквально за секунды.
Мы также стремились сделать наши тесты максимально простыми в реализации и распространении.
Учитывая эти два требования, мы отказались от нашего первого выбора — Java. Наши тесты будут зависеть от использования нескольких взаимосвязанных файлов JAR и потребуют управления зависимостями, контроля версий и воздействия изменений в различных версиях формата файла JAR. Все это позволило бы существенно увеличить продолжительность испытаний.
Мы решили внедрить автоматизацию путем доступа к микросервисам через их конечные точки REST, чтобы мы могли настроить использование файлов jar и не писать никакой бизнес-логики.
Чтобы обеспечить простоту внедрения и распространения нашей автоматизации, мы решили использовать комбинацию параметризованной оболочки и скриптов Python, которые можно запускать из командной строки.
Это должен быть отдельный сценарий оболочки для управления выполнением тестового сценария, который будет вызывать другие сценарии оболочки и сценарии Python, которые будут действовать как утилиты многократного использования.
У такого подхода есть несколько положительных сторон:
1. Нам удалось получить продолжительность теста (включая время установки и отключения) 4-90 секунд; среднее время работы 40 секунд. При использовании автоматизации на основе Java расчетное среднее время выполнения может составлять 5–6 минут.
2. Непрерывная интеграция упрощена.
Все, что нам было нужно, — это система заданий Jenkins, которая загружала бы сверху из нашего репозитория, выполняла необходимые скрипты и записывала результаты.
Консольного анализа записей, встроенного в Jenkins, оказалось достаточно для получения статистики для теста «пройден/не пройден».
3. Легкий старт. Для запуска нашего набора тестов стороннему специалисту достаточно доступа к нашему git-репозиторию и терминалу.
Глобальный запуск Одним из наших крупнейших проектов в 2015 году было обеспечение достаточного количества интеграционных тестов для обеспечения плавного одновременного запуска Netflix в 130 странах.
Фактически нам нужно было автоматизировать хотя бы общий набор тестов производительности для каждой страны и языковой комбинации.
Это существенно усложнило функциональность нашего продукта автоматизации.
Наши тесты проходили довольно быстро, поэтому мы изначально решили, что будет достаточно запустить тестовую программу в цикле для каждой страны и языковой комбинации.
В результате тесты, занимавшие около 15 секунд, начали выполняться в течение часа и более.
Необходимо было найти более приемлемый подход к этой проблеме.
Кроме того, каждый протокол испытаний увеличился примерно в 250 раз, что усложнило анализ отказов.
Чтобы справиться с этими проблемами, мы сделали две вещи: 1. Для распараллеливания наших тестов мы использовали плагин Jenkins Matrix, благодаря чему тесты для каждой страны стали запускаться параллельно.
Нам также пришлось настроить наши подчиненные устройства Jenkins на использование разных исполнителей, чтобы другие задания не становились в очередь, когда наши тесты обнаруживали какие-либо состояния гонки или бесконечные циклы.
Для нас это было осуществимо, поскольку наша автоматизация включала только затраты, связанные с запуском сценариев оболочки, и не было необходимости предварительно загружать двоичные файлы.
2. Мы не хотели проводить рефакторинг каждого теста, написанного до этого момента, и мы не хотели, чтобы каждый тест работал с каждой комбинацией страны и языка.
В результате мы решили использовать модель по требованию, в которой мы могли бы продолжать писать автоматические тесты так, как мы это делали раньше, и к ней будет добавлено дополнение, чтобы сделать ее глобальной готовой.
Это дополнение должно содержать идентификатор тестового примера и комбинацию страны и языка в качестве параметров, а затем должно выполнить тестовый пример с этими параметрами, как показано ниже: 
В настоящее время автоматизированные тесты выполняются по всему миру, закрывая все высокоприоритетные интеграционные тестовые сценарии, в т.ч.
мониторинг посещений во всех регионах, где такое отображение доступно.
Проблемы будущего Темпы появления новых дополнений в Netflix не замедляются, а только увеличиваются.
Вот почему наш продукт для автоматизации продолжает развиваться.
Вот некоторые из проектов в нашей дорожной карте: 1. Потоковые тесты.
Они должны включать представление тестового примера в виде рабочего процесса или серии шагов для моделирования потока данных через сервисную воронку Netflix. Мотивацией для этого является снижение затрат на анализ неудачных тестов за счет простого определения шага, на котором тест не удался.
2. Встраивание предупреждений.
У Netflix есть несколько систем оповещения.
Но включение определенных предупреждений иногда оказывается не имеющим отношения к выполнению соответствующих наборов тестов.
Это связано с тем, что тесты зависят от сервисов, которые могут работать не на 100% и даже быть неисправными, что приводит к непригодным для использования результатам.
Вам необходимо создать систему, которая сможет анализировать эти предупреждения, а затем определять, какие тесты следует запустить.
3. Учет беспорядка.
В настоящее время наши тесты предполагают, что среда Netflix на 100% функциональна, но это не всегда так.
Команда специалистов по надежности постоянно выполняет тесты на расстройства для проверки общей целостности системы.
В настоящее время результаты автоматизации тестирования в деградированных средах показывают уровень отказов более 90%.
Мы должны улучшить нашу автоматизацию тестирования, чтобы обеспечить соответствующие результаты при работе в ухудшенной среде.
Теги: #тестирование #интеграционное тестирование #интеграция #netflix #хит #A/B-тестирование #стратегия тестирования #микросервис #Системный анализ и проектирование #отладка #Тестирование веб-сервисов
-
Сухая Вода И Море По Колено
19 Oct, 24 -
Last.fm Оффлайн
19 Oct, 24
