Об авторе

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

1. Предыстория

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

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

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

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

2. Исследование: исследование и практика автоматического регрессионного тестирования.

Чтобы решить эти проблемы, мы постоянно проводим исследования в области качества и тестирования:

1) Платформа автоматического тестирования: обычная программируемая платформа для управления проектированием и выполнением сценариев использования.

2) Тестирование записи и воспроизведения. Преимущество внедрения TCP Replay для тестирования воспроизведения заключается в упрощении конструкции теста. Недостаток заключается в том, что нет ожидаемых результатов тестирования и требуется рабочая сила, чтобы обратить внимание на результаты анализа.

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

4) Платформа данных MOCK. Создайте несколько платформ MOCK для разных сценариев для решения проблем с тестовыми данными.

5) Различные платформы покрытия: измерьте объем и рабочую нагрузку тестирования.

6) Оптимизация тестовой среды. Создайте тестовую среду и подсреды для эталонного тестирования, чтобы обеспечить потребности в непрерывной отладке и тестировании.

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

Проблемы, возникшие во время разведки

Вышеупомянутые различные исследования достигли определенных результатов, но все еще остаются две проблемы:

1) Автоматизированное тестирование ориентировано на автоматическое выполнение, работы по обслуживанию по-прежнему выполняются «вручную», а коэффициент производительности не очень оптимистичен.

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

новые цели строительства

Поэтому команда исследований и разработок предложила нам цели строительства：«Качество необходимо улучшать и обеспечивать. Можно тратить электроэнергию впустую, но мы не можем тратить зря людей».

На основе вышеизложенного опыта исследований и новых целей родилась идея реализации «использования реального производственного трафика и данных для регрессионного тестирования». Наконец, мы преобразовали эту идею в конкретные идеи и реализовали ее, создав платформу автоматизированного тестирования, сочетающую в себе запись + воспроизведение + сравнение. AREX,Сейчас Открытый исходный код（Открытый исходный кодадресhttps://github.com/arextest）。

• Запись: не просто записывайте производство по запросам,Также участвует в записи обработки изданных запросов.
• Повтор: не просто запросы на воспроизведение, также включатьизданныеMOCKв приложение。
• Сравнение. Замените тестовые утверждения сравнениями различий записанного воспроизведения.

3. Знакомство с платформой AREX

3.1 Что такое АРЕКС

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

Логика регрессионного тестирования AREX

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

целевой сценарий

• Необходимо часто создавать большое количество тестовых сценариев;
• Сценарии, требующие большого количества регрессионных тестов бизнеса;
• Сценарии разработки тестов при нехватке человеческих ресурсов;
• Частые выпуски и частые сценарии регрессионного тестирования;

Далее давайте объясним, как работает AREX с точки зрения рабочего процесса.

На рисунке ниже показана цепочка вызовов приложения, не подключенного к AREX.

При подключении к AREX, как показано на рисунке ниже, вверху находится процесс записи трафика. Во время обычного процесса обработки вызова Java-агент AREX перехватывает данные по каналу вызова и сохраняет их в базе данных AREX.

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

После выполнения тестового примера воспроизведения AREX AREX вызывает SDK сравнения для сравнения, выводит результаты различия и генерирует отчет о тестировании.

4. Внедрение и оптимизация технологии AREX.

Хотя концепция записи и воспроизведения трафика уже стала клише,Но реализовать это на практике не так-то просто.,Есть много проблем, которые необходимо решить。Ниже мы подробно представим нашу команду.Технические трудности, возникшие при внедрении платформы AREX и как мы их решили.

4.1 Принцип записи и воспроизведения AREX gent

Ниже используется простая функция, иллюстрирующая принцип записи и воспроизведения AREX Agent:

Левая часть — это функция до преобразования, а правая — функция после преобразования.

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

Часть выхода функции принимает решение о записи. Если запись требуется, промежуточные данные, которые необходимо сохранить приложению, сохраняются в базе данных AREX.

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

4.2 Технические проблемы AREX

Технологический стек AREX AGENT

Из-за хорошей производительности и простоты чтения и понимания кода мы используем библиотеку ByteBuddy для реализации модификации байт-кода.

Кроме того, используется SPI (интерфейс поставщика услуг), который представляет собой набор API-интерфейсов, предоставляемых Java для расширения. Его можно использовать для включения расширений платформы и замены компонентов. Наш компонент внедрения реализован посредством этого режима плагина.

Внедрить ТРЕЙСИНГ

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

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

Решить проблему отсутствия цепочки вызовов

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

для Решить проблему отсутствия цепочки проблема с вызововизом, мы ее реализовали Runnable,Callable,ForkJoinTask,Async Client Инкапсуляция этих классов.

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

Советы：Wrapper(Упаковка) ключевое слово, поиск по базе кода Wrapper можно увидеть все AREX Реализация инкапсулированных классов.

Реализация внедрения записи и воспроизведения

Ниже приведен пример кода для реализации записи и воспроизведения.

@Override
public List<MethodInstrumentation> methodAdvices() {
    ElementMatcher<MethodDescription> matcher = named("doFilter")
            .and(takesArgument(0, named("javax.servlet.ServletRequest")))
            .and(takesArgument(1, named("javax.servlet.ServletResponse")));


    return Collections.singletonList(new MethodInstrumentation(matcher, FilterAdvice.class.getName()));
}

Когда нам нужно внедрить новую зависимую библиотеку, как нам реализовать этот плагин?

Сначала мы используем три элемента для поиска внедренной функции:

• Модуль (ModuleInstrumentation: FilterModuleInstrumentationV3): Концепция управления логикой заключается в помещении нескольких классов внедрения или классов инкапсуляции в один модуль.
• Тип (TypeInstrumentation: FilterInstrumentationV3): это класс, в котором мы хотим найти внедренный объект, то есть внедренный класс приложения.
• Функция (MethodInstrumentation): эта функция должна располагаться в функции, в которую вносится модификация.

Как и в приведенном выше примере, класс, который мы хотим внедрить, — это класс CacheAspectSupport, модуль, в котором он находится, — это модуль CacheModuleInstrumention, а функция, которую мы хотим внедрить и изменить, — это функция doFilter.

Затем реализуйте функцию кода внедрения функций в три этапа. Давайте более интуитивно посмотрим, как агент AREX реализует внедрение кода с помощью функции Mybatis Query():

Шаг 1. Свяжите функцию с именем METHOD_NAME_Query (строка «Query») с классом QueryAdvice, который реализует функцию внедрения.

Шаг 2. Класс QueryAdvice реализует функцию OnMethodEnter() и аннотирует аннотацию ByteBuddy.

Шаг 3. Класс QueryAdvice будет добавлен в начало и конец функции Query.

Если требуется воспроизведение, запрошенные данные сохраняются в локальной переменной, если воспроизведение не требуется, выполнение продолжается;

Ниже приведен код внедрения функции Query перед выходом:

• если MOCK Если результат соответствует условиям, верните MOCK данные；
• если текущий статус — запись, то запрос будет SQL+ Исходные данные результата запроса сохраняются в AREX изданные Библиотека。

Внедрить управление версиями

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

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

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

Реализация изоляции кода

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

Основной JAR-файл AREX загружается в независимый ClassLoader и несовместим с кодом приложения пользователя. Чтобы обеспечить корректный доступ к внедренному коду во время выполнения, ClassLoader просто модифицируется, как показано на рисунке ниже.

решить проблему времени

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

Мы используем нашу собственную реализацию currentTimeMillis() для проксирования исходного Java-вызова currentTimeMillis(). Запись и воспроизведение времени будут выполняться в соответствии со сценой во время записи, таким образом реализуя имитацию времени.

Этот сценарий подробно описан в AREX Agent №182:

Исправить проблемы с кэшированием

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

AREX предоставляет функцию динамического класса Mock. Метод реализации заключается в настройке метода доступа к локальному кешу в динамическом классе. Это эквивалентно настройке этого метода для Mock. Данные настроенного вами метода динамического класса будут записаны. и воспроизводится в производственной среде. Возвращаются соответствующие соответствующие данные.

Конечно, у этого подхода есть и недостатки:

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

4.3 Другие преимущества AREX

Поддержка написания тестирования интерфейса

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

В ответ на это AREX также предоставляет идеальную поддержку для написания тестов интерфейса.

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

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

Быстрое обнаружение производственных проблем

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

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

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

5. Внедрение и перспективы автоматизированного тестирования AREX.

5.1 Эффект внедрения AREX в Ctrip

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

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

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

5.2 Оптимизация AREX

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

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

В настоящее время мы концентрируемся на оптимизации конфигурации AREX и возможностях сравнения.

Улучшение конфигурации

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

• Визуально продемонстрировать различия
• Ручные операции маркировки повышают удобство использования.
• Обновления конфигурации можно пересчитать и выполнить повторно.

гомогенная агрегация

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

Алгоритмическое шумоподавление

1) Снижение шума перед анализом

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

2) Сравните базу знаний

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

Точное тестирование

Точное Целью обсуждения является сужение объема тестирования, и в будущем в AREX также будет введено Точное. Сегодня основная цель — четко сравнить источники различий.

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

После сравнения и оптимизации результатов различий можно эффективно снизить затраты на настройку НИОКР и повысить точность результатов различий. В этом и состоит реальная ценность автоматического регрессионного тестирования AREX.

6. Напишите в конце

Благодаря постоянной оптимизации AREX постепенно достигла цели использования реального трафика и данных для регрессионного тестирования, снизила затраты, повысила качество и достигла целей, поставленных на ранних этапах строительства.

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