То, что всё это мы упоминали на нашем ежегодном митапе для 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, чтобы ничего не пропустить и успеть зарегистрироваться.