1. Общие сведения

1.1 Знакомство с Пандорой

Что такое запись и воспроизведение трафика? Запись и воспроизведение трафика означает, что сторона приложения автоматически регистрируется на стороне сервера путем установки зонда записи впрыска для формирования обратного потока трафика записи и полностью записывает содержимое ответа, от которого зависят все внешние вызовы (например, базы данных, распределенные кэши, внешние ответы сервисов и др.). Платформа распределяет инструкции по воспроизведению трафика на устройство воспроизведения. Его основная ценность заключается в прямой записи реальных производственных данных, преобразовании реальных производственных данных в многоразовый и исполняемый трафик, а также в быстром выполнении возвращаемых значений интерфейса сравнения воспроизведения и проверке промежуточного соединения в тестовой среде.

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

1.2 Сравнение рыночных инструментов

Большинство известных в настоящее время на рынке платформ записи и воспроизведения трафика являются вторичной разработкой и преобразованием на базе Jvm-Sandbox-Repeater, и большинство из них поддерживают только язык Java. Основной принцип также заключается в проверке правильности логики кода путем записи реального онлайн-трафика и последующего воспроизведения его в тестовой среде.

2.Практика внедрения

2.1 Модель сотрудничества

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

2.2 Этап применения

Идеальные приложения для реализации воспроизведения трафика на различных этапах:

Проблемные моменты на этапе тестирования: сосредоточьтесь на основных сценариях и проверьте влияние каждого теста на основные сценарии при небольших затратах;

Проблемные точки на этапе регрессионного тестирования: полные сценарии с упором на всесторонний охват сценариев и проверкой влияния новых функций на исторические функции;

Возвращение предварительной версии: в настоящее время предварительная версия и рабочая версия находятся в одной библиотеке.,В будущем мы будем продвигать внедрение на основе предварительных версий.&производственная средапоток Воспроизведение,Сделайте разницу моделирования между средой записи и средой воспроизведения как можно более близкой.,Тем самым уменьшая шумовое воздействие на этапе воспроизведения;

В общей системе контроля качества Dewu воспроизведение трафика направлено на возврат к чистой прибыли в краткосрочной перспективе.

2.3 Реализация на практике

С момента запуска воспроизведения трафика он постепенно перешел от этапа исследования и испытания к этапу расширения сценариев применения в этой области.

Режим воспроизведения потока заказов

После периода исследований был разработан набор шаблонов, подходящих для итерации в этой области.

Часть1. Попробуйте получить доступ.

После того, как команда приступила к реализации специального проекта воспроизведения трафика, путем исследования 40% сервисов были выбраны для приоритетного доступа.

1. Цель этапа

• Заполнено 30% заявок P0 top10 интерфейс100% охват сцены,Формирование застрявшей точки качества приземления итерации,Полный анализ применимости и эффективности;
• Увеличение порядка ввода потока воспроизведения кадров,Проблемы с качеством посадки,Охватывает 5% сценариев регрессии;

1. План реализации

• Возможности исследовательского приложения,Попробуйте получить доступ к записи и воспроизведению потока;
• Интерфейс P0 и варианты использования сервиса кардинга, соответствующие теги интерфейса и вариантов использования Конфигурации;
• Варианты использования автоматически помещаются в наборы вариантов использования.,Попробуйте воспроизведение потока во время фазы регресса.

1. Результаты выгоды

• Заканчивать30%формирование заявки Проблемы с качеством посадки,Реализация сценариев регрессии вариантов использования 15%.,Проверка осуществимости решения и простоты использования,Изучите и разработайте механизм сотрудничества.

Часть 2, исследуйте и улучшайте

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

1. Цель этапа

• Приложение: доступное приложение передается соответствующему ответственному лицу по обслуживанию.,Отвечает за техническое обслуживание, эксплуатацию, анализ и устранение неполадок соответствующих служб;
• Варианты использования: попробуйте изучить новые методы анализа вариантов использования.,Дальнейшее расширение количества вариантов использования,Увеличить сумму покрытия;
• Устранение неполадок: в зависимости от количества случаев использования услуги и времени доступа.,Улучшение возможностей устранения неполадок при тестировании,В конце Фазы 2 тестирование и отладка достигли уровня 50-50;

2. Результаты доходов

• От пилотного проекта к тупиковой точке приложения,Накопленные варианты использования также начали обновляться после применения решения по потоку в горячих точках. Число подключенных приложений также превысило первоначальную цель на 50%, и все они достигли серьезных точек застоя.
• Применение стратегий интеллектуального анализа дает очевидные результаты повышения эффективности.,Число ожидаемых вариантов использования увеличивается в геометрической прогрессии,Покрытие интерфейса P0 приложениями доступа достигает 100%.
• Улучшенные возможности устранения неполадок при тестировании,Количество ошибок, обнаруживаемых на каждой итерации воспроизведения, также увеличивается.,Реализуемость и возможность обобщения нового плана в основном соответствуют ожиданиям.

Часть 3, специальное увеличение скорости

Исходя из того, что количество заранее запланированных вариантов использования значительно увеличилось, а скорость выделения вариантов использования была значительно улучшена, воспроизведение трафика выявило больше дефектов в итеративных приложениях и планирует расширить приложения, к которым осуществляется доступ, и объем охватываемых интерфейсов.

1. Цель этапа

• Доступ к приложениям: 40% доступа к новым приложениям, что составляет в общей сложности 90% приложений доступа;
• Устранение неполадок: Улучшите возможности тестирования по устранению неполадок.,Отладка новой версии перенесена из отдела исследований и разработок платформы в отдел исследований и разработок бизнеса.,тест Соотношение разработки и отладки 50/50;
• Объем вариантов использования: ускорить выделение вариантов использования и расширить охват. По крайней мере, 65 % приложений завершили выделение полных вариантов использования;
• Точки зависания: приложения Access достигают 100% зависаний, что повышает скорость устранения неполадок, а некоторые приложения преобразуются из рабочих точек зависания в предварительно выпущенные точки зависания;
• Уровень покрытия интерфейса приложения глобального доступа составляет более 98%.,интерфейс Конфигурация Полнота98%Вот и все,Полный охват пути варианта использования составляет более 60%.

1. Результаты выгоды

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

• доступ к потоковому воспроизведению 90% приложений,Расширьте доступ к приложениям и отслеживание случаев,Достигайте целей, превосходящих ожидания,Количество случаев внесения осадков в 3 раза превышает первоначальный план.,Совокупное количество дефектов, обнаруженных на этом этапе, составляет 45% от количества ошибок, обнаруженных при воспроизведении глобального потока.,Полностью проверена эффективность стратегии внедрения;
• Судя по статистике дефектов, обнаруженных в этой области на этапе 3, ошибки регрессии составили 38%, собственные/скрытые онлайн-проблемы составили 8%, а проблемы с кодом (ошибки журнала) и проблемы спецификации кода в процессе итерации составили 46%, проблемы с производительностью составляют 8%;
• Полнота конфигурации интерфейса 100%; охват измерения интерфейса 96,49%; полный охват пути варианта использования 79,32%;,Средний уровень покрытия кода составляет 39,8%;

3. Сводный анализ

3.1 Анализ классификации проблем

3.1.1 Классификация обнаруженных накопившихся дефектов:

3.1.2 Классификация источников обнаруженных накопленных дефектов:

3.1.3 Типичные случаи:

• Система работает ненормально во время воспроизведения. После устранения неполадок это определяется как проблема NPE, например:

• Сравнение различий в бизнес-полях, возвращаемое ответом, противоречиво, например:

В классификации дефектов и их источниках нетрудно разобраться:

• Воспроизведение потока показало, что почти половина проблем перехвата вызывает ошибки производственного бизнеса.,К ним относятся такие проблемы, как неправильные суммы, влекущие за собой капитальные потери, неправильный перенос значений полей, неправильные типы перечисления и т. д. как одна из последних линий защиты перед выпуском продукции;,Это полностью демонстрирует важность записи и воспроизведения потоков в качестве дополнения к возможностям сокрытия теста.
• Около 45% проблем — это скрытые проблемы на уровне кода, которые сложно обнаружить при ручной обработке.,Например, отчеты об ошибках NPE, поля входных и выходных параметров не сериализуются и т. д.,Если эти проблемы решать только через фронтенд-тест или интерфейстест без просмотра логов и сравнения всех полей по одному, проблемы неизбежно перенесут в производственную среду.,В конечном итоге это влияет на стабильность производственной среды.
• Около 6% проблем с производительностью,Например, есть повторяющиеся подвызовы,ВлияниеинтерфейсRT,Если не найдено и не устранено до производственного выпуска,Это обязательно создаст определенные проблемы для пользовательского опыта.
• От источника дефекта,Источники обнаруженных дефектов по-прежнему сосредоточены на требованиях к итерации проекта и технической оптимизации.,В полной мере проверена эффективность общего ускорения воспроизведения потока и дополнения способности теста перекрывать низ.
• Собирайте и делитесь обучением посредством устранения неполадок и анализа неудачных вариантов использования.,Общий технический уровень команды тестировщиков, участвовавшей в спецпроекте, был значительно улучшен в технической атмосфере за счет специального увеличения скорости воспроизведения потока.,Развил способность чтения кода у многих студентов для реализации модулей, за которые они отвечают.,И код, который глубоко углубляется в недостатки, дает возможность дифференциации.

3.2 Анализ применимости

Применимые сценарии

• Подходит для больших объемов возвращаемых данных и крупных бизнес-операций.,И сценарии, в которых чтение бизнеса составляет значительную долю,Например, продукты ToC.

Нет Применимые сценарии

• Включение записи после подключения песочницы приведет к мгновенному скачку RT, что повлияет на стабильность производственных сервисов.
• Асинхронные сцены в настоящее время не поддерживаются платформой потокового воспроизведения.
• Необходимо проверить реализацию базы данных,Ссылка на проверку циркуляции узла,Автоматизация необходима.

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

Может ли воспроизведение трафика полностью заменить ручную регрессию и автоматизацию?

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

1. Неполное покрытие интерфейса. Итерация требует нового интерфейса, связанная с ним запись не настроена и не входит в диапазон записи воспроизведения трафика.

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

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

4. Проблемы с платформой. Сравнение различий является ненормальным и показывает, что воспроизведение прошло успешно. Воспроизведение асинхронных потоков — трудная задача, которую необходимо преодолеть.

3.3 Проблемы, с которыми пришлось столкнуться

3.3.1 Эффективность устранения неполадок

После записи трафика и его воспроизведения я обнаружил, что многие результаты воспроизведения не совпадают. После расследования и анализа причин сбоев некоторые сбои вызваны ошибками в коде, но большинство сбоев не обязательно являются ошибками в коде. К частым ошибкам в основном относятся:

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

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

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

3.3.2 Проблемы асинхронной потоковой записи и воспроизведения

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

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

4.мировоззрение&планы на будущее

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

Предварительная версия интерфейса только для чтения без имитации воспроизведения

Предварительная версия Dewu представляет собой базу данных и последующее приложение производственной среды China Unicom. Таким образом, воспроизведение предварительной версии без имитации, особенно воспроизведение интерфейса только для чтения без имитации, может быть выполнено на заключительном этапе. прежде чем пройти онлайн-тест. Самая сложная проблема, которую нужно решить, заключается в том, что текущий интерфейс только для чтения не может гарантировать, что последующие изменения не приведут к операциям записи. Открытие этой функции на текущем этапе приведет к дополнительному риску потери капитала.

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

Вариант 1 — Одиночное воспроизведение (воспроизведение в квазиреальном времени)

Проблемы, возникшие при реализации Варианта 1:

1. Данные в центре конфигурации противоречивы и зашумлены.

2. Проблема своевременности: разница во времени составляет 10 секунд, и некоторые предприятия предъявляют относительно высокие требования к своевременности.

Вариант 2 — Двойное воспроизведение (воспроизведение в реальном времени)

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

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

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