Как стать автором
Обновить

Не можете измерить — не сможете улучшить: как мы используем метрики в разработке автотестов

Уровень сложностиПростой
Время на прочтение8 мин
Количество просмотров4.5K
Всего голосов 24: ↑24 и ↓0+24
Комментарии13

Комментарии 13

Этот инструмент позволяет автоматически назначать исполнителя

А почему только одного? Почему не некий стандартный список людей? Было бы еще быстрее.

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

Как говорится, если за что-то отвечает группа людей, то за это не отвечает никто :) (конечно далеко не всегда так, но)

Кстати, на гитхабе эта задача решается штатными средствами: code owners + настройки автоназначения в команде овнеров (можно даже выбрать алгоритм распределения), автоматически перестает назначать на участника, если у него выставлен статус "недоступен" на гитхабе (но жаль конечно, что нет интеграции ни с какими календарями)

Здравствуйте, спасибо за ваш комментарий, хотел добавить, что у нас есть проекты, где используется механизм code owners (об этом можно почитать тут: https://habr.com/ru/company/wrike/blog/532508/) для разметки кода и статический анализатор. Это позволяет назначать ревьюеров из списка ответственных за код, и такой подход также реализован в JiGit. Однако, во многих проектах это не работает по ряду причин:

  1. Разметки code owners не было, а заводить и поддерживать её дорого.

  2. В QAA команде принято cross-ревью. Любой инженер из команды может ревьюить любую часть кода (с учетом его экспертизы и капасити).

  3. code owners не просто сынтегрировать с календарем, а учитывать отпуска и тд необходимо для ускорения ревью.

а откуда JiGit может брать календарь отпусков? (что-то сходу не гуглится)

Здравствуйте , у нас есть спредшит с расписанием дежурств по деплою + отпуска у ребят, оттуда и берет, но при желании можно заинтегрировать с чем угодно.

А что используете для сбора/визуализации метрик?

Здравствуйте, спасибо за вопрос, данные собираем в бд(postgres), визуализируем через графану.

Про 5 ретраев тема интересная (хоть и спорная). Мы пока что боремся с флаки тестами автозаведением задач на стабилизацию (и/или ускорение) на ответственных.

Здравствуйте, спасибо за ваш комментарий, хотел добавить:

  1. Ретраи - вершина айсберга процесса работы с флаки тестами и больше про лечение симптомов проблем, которые мы решаем под капотом с одной стороны и с другой- для некоторых бизнес процессов существуют жесткие временные ограничения по прогону тестов и разбору рез-ов, в 99% случаев флаки возникает по причине инфра проблем и нет смысла тратить время на ручные/автоматические проверки сейчас, когда проблему можно решить ретраем, в стату положить кейс и в спокойном режиме с ним разобраться после;

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

  3. Постоянная работа с причесыванием/улучшением кода/фреймворка тестов;

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

https://habr.com/ru/company/wrike/blog/588873/

https://habr.com/ru/company/wrike/blog/574320/

https://youtu.be/kubqCb_7cxc

Спасибо за ссылки, понравилась идея проверять чекстайлом только измененные с последнего коммита файлы.

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

Здравствуйте, спасибо за обратную связь, попробуйте заиспользовать в вашем проекте эту идею, возможно по ходу что-то еще улучшите или добавите, ну и если будет еще обратная связь- you're welcome!

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

  1. Maven Modules Merger - позволяет оптимизировать запуск тестов в многомодульном проекте мавен https://habr.com/ru/company/wrike/blog/703986/

  2. Параллельные ретраи - статья должны выйти в ближайшем будущем.

Надеемся данный материал будет Вам полезен!Спасибо!

попробуйте заиспользовать в вашем проекте эту идею

Практически сразу же, как прочитал, заметно помогло, спасибо! :)

У нас пока политика "если тест есть для сервиса, то он запускается", так что я все-таки пробую схему с уплощением хвоста, в целом цифры по сравнению с рандомным распределением очереди получаются приятные (экономия чуть больше 10% времени).

1 видел, но для нас не актуально, 2 у нас, вероятно, уже есть, если это то, о чем я думаю (но я подписался и жду)).

Спасибо вам за развернутые ответы!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий