Автор | Ван Чэнкунь
Планирование | Чу Синцзюань
В контексте универсальной идеологической революции и популярности DevOps модель небольших шагов и быстрого запуска значительно сжимает время деятельности по обеспечению качества, а традиционные инструменты автоматизированного тестирования больше не могут удовлетворить потребности непрерывной доставки. Концепция записи и воспроизведения трафика становится все более популярной в последние годы, начиная с отраслевых конференций и заканчивая форумами сообщества, многие инженеры много размышляли и понимали, и они подтвердили, что запись и воспроизведение API могут эффективно решить основные проблемы. инженеры по тестированию и исследованиям и разработкам в области качества, что приводит к заметному повышению эффективности исследований и разработок. Основная ценность записи и воспроизведения трафика заключается в быстрой проверке возвращаемых значений интерфейса воспроизведения и сравнения и промежуточных ссылок в тестовой среде путем непосредственной записи полученных данных с высокой точностью. Запись и воспроизведение очень популярны, а также достаточно отраслевого образования. Однако создать универсальную готовую платформу сложно, и сцена реализации неясна. Компания ZhongAn Technology вобрала в себя лучшие отраслевые идеи и разработала базовые инфраструктурные решения для основных линий связи, такие как бесшумный ввод зондов и автоматическое шумоподавление. Компания также провела углубленную проверку внедрения в основных направлениях деятельности группы и добилась видимых результатов. В этой статье подробно описывается процесс исследований, разработок и внедрения технологии Чжунган, в надежде вдохновить всех.
Команда центра качества отдела инженерно-технической эффективности Zhongan занимается созданием инфраструктуры основного канала записи и воспроизведения и изучает ценность реализации основного бизнес-сценария. Она провела исследование спроса, проверку выбора технологии, разработку решения, систему версий MVP. и простота использования, проверка стабильности, реализация бизнес-ценности и другие процессы, наконец был сформирован продукт Magic для записи и воспроизведения трафика, который повышает производительность и качество исследований и разработок за счет регрессионной проверки, сбора покрытия, повторного использования трафика и других средств.
Рисунок 1. Основные этапы разработки продукта
Проблема, которую мы хотим решить
С развитием бизнес-систем бизнес-системы становятся все более сложными, и инженеры по качеству заняты работой целый день. Традиционное функциональное тестирование или автоматизированное тестирование больше не могут обеспечить уверенность в обеспечении качества, и болевые точки в деятельности по обеспечению качества встречаются повсюду. Мы грубо резюмируем это следующим образом:
Мы также видели, что эти трудности существуют как внутри группы, так и в отраслевой деятельности по проверке качества. Например, двухнедельная гибкая модель итерации, принятая во внутренних продуктах Zhongan Group, означает, что времени для тестирования качества деятельности студентов очень мало. Студенты-тестировщики практически не могут проверить полное регрессионное покрытие основных функций на каждой итерации.
Мы стремимся решить основные болевые точки студентов в различных сферах бизнеса, освобождая студентов-тестировщиков от повторяющейся работы по сложному регрессионному тестированию и обслуживанию сценариев использования, чтобы каждый мог сосредоточиться на настройке и обдумывании стратегий и планов тестирования. Запись и воспроизведение трафика могут в значительной степени решить эти проблемы.
Далее мы поделимся с вами методами создания платформы записи и воспроизведения трафика ZhongAn Technology, от построения базовой инфраструктуры до реализации основных бизнес-сценариев.
Цели строительства
На раннем этапе создания продуктового проекта мы посетили различные бизнес-направления группы и приняли участие в отраслевых конференциях. После полного понимания болевых точек, упомянутых в главе о коренных причинах рождения продукта в деятельности по обеспечению качества в отрасли, мы разобрались. применимые сценарии применения, определены технические решения и разъяснены. Цель построения — превратить производственные данные высокой точности в многоразовый и исполняемый трафик.
Рисунок 2: Техническое решение
Сценарии применения
Техническое решение
Общая архитектура основана на репликации основного пути устройства записи и воспроизведения, а также задаются частота дискретизации интерфейса, группировка трафика и другие политики. Сторона приложения автоматически регистрируется на сервере, монтируя и внедряя зонд рекордера для формирования трафика записи. перекомпоновывается, и уровень платформы распределяет воспроизведение трафика на устройство воспроизведения, таким образом образуя базовый замкнутый цикл записи и воспроизведения трафика.
Конечно, после завершения основной ссылки для записи и воспроизведения трафика необходимо решить ряд проблем, таких как простота использования процесса, стабильность и шум сравнения, вызванный несогласованностью данных воспроизведения в разных средах. Команда среднего уровня Magic по качеству сосредоточилась на построении базовой инфраструктуры и разработала техническую реализацию трех режимов: имитационное воспроизведение, воспроизведение с автоматическим уменьшением сухости и нормальное воспроизведение.
Рисунок 3: Ссылка на техническую реализацию
Реализация на практике
Зонд воспроизведения записи, бесшумный ввод
Устройство записи и воспроизведения служит базовой опорой. Как элегантно внедрить зонды агента, определяет сложность продвижения продукта. Мы рассмотрели такие варианты, как оркестровка базовых изображений и режим коляски. следующее:
Рис. 4. Схема ввода пробного модуля
Сравнивая преимущества и недостатки различных решений, мы, наконец, выбрали метод внедрения плагинов, чтобы он был готов к использованию «из коробки», без необходимости модификации и адаптации приложения и был прост в использовании для пользователей. Агент автоматически внедряет тестируемое приложение, и пользователи могут свободно его дизассемблировать, свободно выбирая POD:
Целью самостоятельной регистрации агентов является регистрация приложений, которые подключили зонды к уровню платформы, посредством длинных ссылок. Пользователи могут быстро обнаружить эти агенты и начать запись и воспроизведение действий вокруг зондов.
Схема автоматической регистрации агента: зонд обменивается данными с адаптером адаптера по длинному каналу связи и поддерживает контрольные сигналы.
Рисунок 5. Техническое решение автоматической регистрации агентов.
Обнаружение агента: уровень платформы может автоматически идентифицировать зарегистрированного агента, а затем установить план записи и выдать инструкции по воспроизведению.
Рисунок 6: Автоматическая регистрация агента
Группировка трафика
У пользователей, которые производят массовые записи трафика, есть требования к управлению. Пользователям необходимо организовывать данные в соответствии с бизнес-атрибутами, классификацией интерфейса и другими измерениями. Поэтому мы разработали функцию группировки трафика. Пользователи могут группировать интерфейсы, которые необходимо записать в соответствии со сценарием использования, чтобы отмечать собственный трафик, чтобы принимать более обоснованные решения во время воспроизведения и преобразования трафика. Каждая группа группировки трафика включает в себя интерфейс. Белый список и настройки черного списка интерфейса. Интерфейс должен поддерживать правила ввода пути, начиная с корневого каталога /path1/path2, * указывает на подстановочный знак.
Рисунок 7: Конфигурация группы интерфейсов записи.
Частота дискретизации интерфейса
Если записываются все повторяющиеся интерфейсы в одном и том же сценарии, у пользователя возникнут ненужные затраты на идентификацию, а также увеличится потребление недопустимых аппаратных ресурсов для приложения. Частота дискретизации интерфейса направлена на управление частотой дискретизации на уровне интерфейса. , а затем Первый слой служит для удаления дубликатов.
Рисунок 8. Настройка частоты дискретизации на уровне интерфейса.
Десенсибилизация дорожного движения & Удалить дубликаты
С помощью вышеуказанных настроек плана записи и основы проверки агента мы можем фактически включить переключатель записи для записи трафика.
Рисунок 9: Запись трафика
Затем, от производственного записанного трафика до воспроизведения в тестовой среде, нам необходимо деформировать данные с помощью правил десенсибилизации для определенной конфиденциальной информации, чтобы добиться надежной защиты конфиденциальных частных данных.
Когда речь идет о данных безопасности клиента или некоторых коммерчески конфиденциальных данных, реальные данные должны быть преобразованы и предоставлены для тестирования. Личная информация, такая как идентификационный номер, номер мобильного телефона, номер карты, номер клиента и т. д., должна быть десенсибилизирована. Эта десенсибилизация включает десенсибилизацию отображения производственных данных и десенсибилизацию создания данных перед воспроизведением. Мы используем механизм десенсибилизации для разработки общей стратегии десенсибилизации для выявления данных, которые необходимо деформировать.
Поскольку в производственной среде будет много дубликатов и большое сходство,,Чтобы сократить ненужные затраты на хранение и повысить доступность записей.,Мы используем определенные стратегии для проведения частотного скрининга.,Воляпотокруководить Удалить дубликатыиметь дело с。
Что касается расчета сходства, мы используем алгоритм расстояния Левенштейна. После получения сходства строк мы вычисляем сходство тела запроса и тела возврата, а затем объединяем его со стратегией многоуровневого ключевого фактора влияния для расчета сходства. два потока, а затем принимать решения о трафике, который необходимо сохранить.
картина 10: Десенсибилизация & Удалить дубликаты Техническое решение
Фильтр шумоподавления
Записанный трафик воспроизводится. Из-за несогласованности данных в разных средах и разных возвращаемых значений из одного и того же интерфейса легко вызвать сбой при сравнении воспроизведения. Стоимость устранения неполадок для пользователей слишком высока, и они устают. рассмотрения и корректировки данных сравнения. Общий шум В основном включает в себя:
Ручное увеличение шума
Как устранить шум ошибки проверки регрессионного сравнения, вызванный несогласованностью данных во время воспроизведения в разных средах? Мы можем вручную задать точки шума, настроив шумовое поле на глобальном уровне, уровне приложения и интерфейсе, например:
картина 11: Ручное шумоподавление
Автоматическое шумоподавление
Вышеупомянутая предварительная конфигурация может решить некоторые проблемы и подходит для ситуаций, когда имеется мало общих полей, и может использоваться в качестве конфигурации первого уровня для снижения шума. Однако для неизвестных интерфейсов и больших таблиц данных стоимость настройки поля катастрофична. Нам нужна возможность автоматически идентифицировать шум и автоматически фильтровать его во время воспроизведения.
В отрасли также существуют относительно зрелые решения. Opendiffy с открытым исходным кодом Twitter может быть настроен для быстрого сравнения результатов и имеет собственную функцию фильтрации шума. В течение всего процесса тестирования компании Diffy потребовалось развернуть три версии системы для реализации функций фильтрации шума и сравнения. Это:
Как работает OpenDiffy:
Diffy в основном действует как внешний прокси-сервис, который может распределять исходные запросы по разным версиям системы и делать окончательный вывод, сравнивая выходные данные каждой версии системы. Но недостатком является то, что реализация opendiffy требует, чтобы каждое тестируемое приложение развертывало службу diffy отдельно, что недопустимо с точки зрения стоимости машины и стоимости развертывания.
Идею шумоподавления мы почерпнули из opendiffy через разницу между стабильной версией и копией стабильной версии, и сами разработали логику автоматической фильтрации шумоподавления:
картина 12: Принцип автоматического шумоподавления
Логика извлечения шума: используйте извлеченные различия в качестве основы для шума.
картина 13: План внедрения автоматического шумоподавления
Результаты извлечения шума: фильтрация шума во время воспроизведения и предоставление возможности вручную корректировать вторичные результаты.
картина 14: Автоматическое шумоподавление и извлечение шума.
Пробное воспроизведение
Конечно, помимо шума сравнения, вызванного несогласованностью данных, воспроизведение в разных средах также оказывает влияние промежуточных связей, таких как промежуточное программное обеспечение и сторонние вызовы. Воспроизведение в режиме имитации является имитацией для внешних вызовов. Этот процесс фактически не обращается к базе данных или другому промежуточному программному обеспечению. Процесс воспроизведения сравнивает входные параметры подвызова записи и подвызова воспроизведения. будет блокировать Прерывание трафика воспроизведения. Если параметры согласованы, результат подвызова записи будет использоваться для возврата Mock.
Завершение воспроизведения также сгенерирует результат ответа. В это время мы сравним исходный результат записи и результат ответа воспроизведения. На основе результата сравнения и результата сравнения дополнительного вызова мы можем определить правильность. тестируемая система Нам необходимо иметь промежуточное программное обеспечение, которое адаптируется к основному потоку. Возможность отслеживать вызывающую ссылку посредством автоматического мониторинга, автоматически макетировать и отображать воспроизводимую дорожку во время воспроизведения.
Адаптация плагина промежуточного программного обеспечения:
картина 15:Mock Адаптация промежуточного программного обеспечения воспроизведения
Трек воспроизведения ссылки промежуточного программного обеспечения:
картина 16: Сравнение траекторий каналов воспроизведения
Умные рекомендации по вариантам использования
Хотя мы можем группировать по потокам, поток Удалить дубликаты выполняют проверку потока, но записанный производственный поток по-прежнему огромен. Пользователям сложно быстро найти интерфейспоток, необходимый для проведения ежедневных проверок, тестирования интерфейса и других действий по обеспечению качества. С этой целью мы думаем о том, как точно преобразовать огромные объемы данных в многократно используемые и наблюдаемые варианты использования для проверки нормализованной временной регрессии. Это также ценность, которую можно реализовать в процессе продвижения продукта, поэтому умные. рекомендации по вариантам использованияпоявился на свет。
Целью интеллектуальных рекомендаций по вариантам использования является автоматическое соответствие правилам в процессе записи с помощью предустановленного механизма правил преобразования трафика и автоматическое преобразование записанного трафика в варианты использования. На основе этих вариантов использования пользователи могут устанавливать запланированные задачи регрессии, автоматизацию интерфейса. , и нагрузочное тестирование трафика. Цель повторного использования достигнута.
Настройки механизма правил: рекомендуемые настройки правил на основе информации запроса интерфейса.
картина 17: Интеллектуальный механизм правил рекомендаций вариантов использования
При записи правила идентификации автоматически преобразуются в варианты использования: в повторно используемые активы вариантов использования. Настраивайте запланированные задачи для ежедневной регрессионной проверки на основе рекомендуемых вариантов использования, предоставляйте отчеты о сравнительном тестировании регрессионной проверки и предоставляйте наблюдаемые интеллектуальные результаты регрессионной проверки вариантов использования.
картина 18: Автоматическая рекомендация вариантов использования
напиши в конце
Модуль записи и воспроизведения трафика Magic Quality Center использует интеллектуальное мышление тестирования для выполнения многоканальной целевой оптимизации на протяжении всего жизненного цикла трафика, формируя совместные усилия по повышению качества и эффективности тестирования с первого пилотного запуска версии MVP. на данный момент это реализовано внутри группы. Проведите глубокую проверку и убедитесь, что платформа приносит видимую ценность для бизнеса.
Эффект от улучшения качества доставки отражен в: среднесуточный трафик записи и воспроизведения Дивизиона Технологического центра во втором квартале составил 58 000, охват регрессионными тестами увеличился на 35% по сравнению с предыдущим кварталом, время проверки теста сократилось на 66%, а соотношение разработки и тестирования увеличилось с 4,5:1 до 6,6:1, показатель качества H1 увеличился на 37%.
Очевидным изменением после подключения бизнес-команды является то, что она может освободить студентов-тестировщиков от повторяющихся задач, таких как сложное регрессионное тестирование и сопровождение вариантов использования, и сосредоточиться на обдумывании разработки стратегий и планов тестирования, а также на практике самостоятельного тестирования. -улучшение, например, кодирование вспомогательных кодов инструментов и усиление знакомства с бизнесом, чтобы в максимальной степени обеспечить качество бизнес-системы.
Это правда, что мы также надеемся расширить возможности внешнего мира той ценностью, которую мы видим, и повысить производительность.
Об авторе:
Ван Чэнкунь, архитектор качества исследований и разработок компании Zhongan Technology
Рекомендуемые статьи сегодня