То, что всё это мы упоминали на нашем ежегодном митапе для QA-специалистов — Bugs Busters. ? Было много интересного:
Мы искали злодея, из-за которого произошла деградация времени обработки очереди — после того, как переключили режим работы пула.
Разбирались с создателем Allure Reports, чем покрытие требований лучше покрытия кода и как визуализировать автотесты.
Выясняли, сколько нужно автотестов и почему 100-процентное покрытие — это не всегда хорошо.
Смотрим доклады и пополняем копилку знаний обо всех видах тестовых покрытий. ?
Ложка дёгтя в транзакционном режиме пуллинга. Дмитрий Карманов, ЮMoney
Это был обычный, не предвещающий беды день: конвейер выкладки релизов работал как часы — таска прилетала и автоматически выкладывалась на прод. Но внезапно после выкатки задачи, в которой менялась конфигурация pgBouncer и приложения, что-то пошло не так — сработали триггеры, загорелась тревога. Из-за новой конфигурации к базе данных увеличилось количество активных соединений, а в самой БД — количество активных блокировок. При этом утилизация CPU со стороны базы выросла в целых пять раз! Конфигурацию спешно откатили обратно, выдохнули и стали разбираться, кто виноват: приложение, баунсер или база. Казалось, что проблема — со стороны приложения, в самой задаче, которая берётся из очереди, однако было непонятно, как именно её обработка деградирует. Начали воспроизводить проблему на различных конфигурациях приложения и pgBouncer и в итоге поняли, что:
Режим работы пула не влияет на нашу проблему.
Зато на неё влияют подготовленные операторы.
И хоть мы сами не создаём подготовленных операторов (считается, что это антипаттерн разработки), оказалось, что PG JDBC Driver делает это за нас, «под капотом», выступая одновременно в роли помощника, который ускоряет наши однотипные запросы, и в роли злодея, из-за которого мы можем получить деградацию производительности при ограничении использования.
Когда мы нашли нашего злодея-помощника, начали думать, как решить проблему. Для этого нам понадобилось ещё несколько экспериментов:
Мы пытались заменить тяжёлый и страшный SELECT на представление.
Переписать его, а перед этим максимально упростить и использовать хранимые функции.
Даже попробовали патч от комьюнити для pgBouncer, который решает проблему использования подготовленных операторов в транзакционном режиме. И хотя патч был хорош, он тоже оказался неидеальным.
В итоге мы остановились на втором варианте и усвоили урок:
большое количество экспериментов + внимательное чтение документации
=
успешное решение проблемы
Таймкоды:
03:14 Как нам прилетела обычная таска, которая потянула за собой ряд проблем
05:13 Пошли разбираться, кто в этом виноват, и решили, что это очередь
06:24 Как наше приложение работает с PostgreSQL и как подружить PostgreSQL с Java App с помощью JDBC Driver
08:21 Как настроить пул HikariCP, чтобы не возникала очередь ожидания между потоками
09:04 Что такое JOOQ и для чего он нужен
09:53 Почему новые соединения для PostgreSQL могут сильно нагружать CPU и как эту проблему решает пул соединений pgBouncer
11:56 Какие бывают режимы работы pgBouncer: session transaction и statement
13:38 Что происходит при переключении сессионного режима пулинга в транзакционный
16:46 Что такое сильно нагруженная для финтеха очередь и как мы поняли, что она не виновата
18:17 Как мы воспроизвели задачу нагрузки очереди и увидели разницу между режимами
21:00 Что такое партицированные таблицы
24:26 Что такое подготовленные операторы и как посмотреть, существуют они или нет
28:47 Два эксперимента, которые показали, что вызывает проблему в задаче
32:04 Как работает PG JDBC Driver
32:53 Ещё три эксперимента, которые показали, как решить проблему
34:18 Что делает патч и какие у него проблемы
36:16 Чтобы получить полное понимание картины, нужно читать документацию и проводить эксперименты
36:27 Какой результат мы получили и на каком варианте остановились
Визуализация покрытия веб-автотестами. Артём Ерошенко, независимый консультант
Когда я пришёл в автоматизацию тестирования, коллеги занимались разработкой автотестов. Каждый писали по несколько дней. Я мог тратить на один длинный автотест по три часа, было очень тяжело. Сейчас обратная ситуация: автоматизируют все — разработчики продукта, ручные тестировщики, инженеры по автоматизации, а контролируют их менеджеры. И эти менеджеры задают много вопросов о том, что тестируется, а что нет, что проверяется, а что нет. Такие вопросы нужны, ведь база тестов огромная: если раньше на одном проекте было около 40 автотестов, то сегодня на старте их может быть 500, а в крупных компаниях их десятки тысяч. К тому же у всех экспертов и команд, что пишут автотесты, разные роли, уровни и языки, которые они используют при написании.
В своём докладе я предлагаю погрузиться в покрытие автотестами и разобраться:
Как его оценить. Здесь мы изучим плюсы и минусы двух подходов: покрытия кода продукта и покрытия требований. Также мы выясним, почему второй метод — это Rolls-Royce в мире покрытий.
В чём особенность автотестов для Web. Как визуализировать автотесты и внедрить Allure-отчётность.
Какой профит мы получаем от всего этого. Например, начинаем понимать, что проверяется в тестах и насколько мы их «сломаем», если поменяем структуру элементов.
Таймкоды:
06:29 Что такое дыра в покрытии и какие вопросы задают менеджеры тестировщикам
09:07 Как оценить покрытие кода продукта и как оно выглядит
10:29 Как снимается покрытие
11:30 Какие плюсы и минусы у покрытия кода продукта
13:45 Как выглядит покрытие требований: инструменты для работы, плюсы и минусы подхода
19:14 Как взять лучшее от каждого из подходов
19:27 В чём особенность Web
23:30 Как визуализировать автотесты
31:54 Какой профит мы от этого получаем
34:15 Какие ещё есть идеи: поддержка Playwright, сценарий теста в плагине и отдельный таб в Allure
36:24 Подведём итоги
Как понять, что тестов достаточно. Филипп Степаненко, ЮMoney
Однажды менеджер спросил меня, достаточно ли у нас командных автотестов. Я задумался. В отделе тестирования мы разработали инструмент Metric Reporter, который позволяет следить за метриками, в том числе за процентом автоматизированных тест-кейсов. Потом мы придумали ещё одну метрику с привязкой к бизнес-процессам. Но со временем стало понятно, что информации, которую мы получаем из метрик, недостаточно. Порой для анализа и оценки покрытия командных процессов тестами требовалось большое количество ручных действий. Хотелось это автоматизировать. В итоге мы стали генерировать матрицу трассировки процессов и тестов, за счёт которой:
получили статистику по покрытию бизнес-процессов тестами в команде;
подсветили все бизнес-процессы без тест-кейсов и тестов;
завели задачи на написание тест-кейсов и тестов, начали улучшать покрытие;
привязали к бизнес-процессам часть тест-кейсов, которые не были привязаны.
Мы добавили матрицу трассировки в Metric Reporter, и теперь командам видно на одной странице, сколько тест-кейсов, в том числе автоматизированных, по каждому бизнес-процессу. Если нужно, можно получить более подробную статистику там же. Доступ к инструменту дали всем командам — не только тестировщикам, но и менеджерам.
Для развития и поддержания Metric Reporter нужны ресурсы, поэтому мы смотрим и на альтернативные инструменты. Но пока нет подходящего варианта, мы хотим развивать свой инструмент, совершенствуя интерфейс, расширяя функциональность и выстраивая работу дальше.
Таймкоды:
03:19 Вводная часть: про компанию, команды и зоны ответственности
04:35 Что такое регрессионное и приёмочное тестирование
06:24 Достаточно ли нашей команде автотестов и почему много не значит хорошо
08:23 Как мы работали раньше: что содержат тест-кейсы, как выглядят автотесты и как мы считаем покрытие тест-кейсов автотестами
10:22 Про внутренний инструмент Metric Reporter, метрику Coverage и её ограничения
12:52 Про бизнес-процессы и из чего они состоят
13:37 Связь бизнес-процессов и тест-кейсов, метрика US и её ограничения
16:34 Идея генерации матрицы трассировки
20:49 Matrix MVP: знакомство с API, написание техзадания, реализация
23:53 Итоги Matrix MVP
25:00 Добавление матрицы трассировки в Metric Reporter
26:38 Итоги внедрения фичи в Metric Reporter
27:35 Как будем развивать этот инструмент
33:50 Сколько тестов достаточно: рекомендации
Надеемся, доклады с Bugs Busters 2023 оказались для вас интересными и полезными. Если у вас остались вопросы к докладчикам, пишите в комментариях. Мы свяжемся со спикерами и передадим каждый вопрос, ответ появится в вашей ветке.
Впереди у ЮMoney много интересных мероприятий, в том числе для IT-специалистов. Следите за нашими новостями на канале ЮMoney Tech, чтобы ничего не пропустить и успеть зарегистрироваться.
