Это stderr. Чтобы отключить, нужно в логгере ваших тестов переопределить хэндлер таким образом , чтобы он stdout использовал

То есть ищется в гугле что-то наподобие pytest change logging from stderr to stdout :)

Всем привет.
Когда руководство хочет видеть "А сколько уже функционала у нас покрыто автотестами?", как вы предоставляете данную информацию? Составляете отчет вручную каждый раз? Или есть какие-то удобные инструменты, способы для формирования таких отчетов?

Привет, слишком индивидуальный вопрос. Есть возможность писать скрипты в гуглдоках для формирования отчетов, если совсем поизвращаться - можно реквестами из БТС вытаскивать инфу например по тикетам в статусе дан, но придется повозиться сначала с авторизацией через апи. в целом если нужен хороший отчет, то нужно составлять матрицу покрытия со всем функционалом, каких-то удобных тулзов я не знаю та и слабо представляю себе как это должно выглядеть. Могу только посоветовать сначала с руководством обсуждать что такое «весь функционал», особенно если интересует % покрытия - что считать за 100%, очень часто по итогу разное понимание этого у команды разработки и заказчика.

еще есть тулзы по типу quality center, куда можно руками заносить например все мануальные чек листы и теоретически отмечать что покрыто автотестами, и если тесты бегут на дженкинсе - плагины типа test result analyzer для визуализации, но опять же - целой картины это не даст, сначала обсуждай что они подразумевают под всем функционалом

Берётся условный test management system типа TestRail. Там заводится тестовый сьют с функциональными тестами, например. Дальше в своём коде для автоматизации ты каждый тест помечаешь на test_id тестов из тестрейла, которые они покрывают. После каждого прогона авто тестов у тебя при помощи test rail api проставляются результаты прогона. Те тесты из тест сьюта, которые остались без результата passed / failed — ещё не автоматизированы. Считаешь покрытие автоматизации динамически считая отношение passed + failed / total number of tests

Спасибо. Но в TestRail есть и репорты для этого, чтоб самостоятельно не считать. Но там, к сожалению, можно только сформировать отчет с цифрами сколько тестов: а) автоматизировано, б) не автоматизировано.

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

Планирую средствами API доставать эту информацию из TestRail, а потом средствами api google sheets формировать нужный мне файл-отчет. Просто показалось: А не изобретаю ли я велосипед, когда есть пути попроще...

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

Потом отдельно отметил например какие api, ui и так далее, тоже вынес отдельно в "пирожок". Нам такого хватило.

Звучит как отлично работающее решение. Не вижу с этим проблем

Через апи можете распарсить и аггрегировать тесты по группам, например , используя тэги тесткейсов или ещё какие поля как вам нужно

Приветствую, коллеги.
Был ли у кого то опыт построения архитектуры тестов применяя подход BDD?
Я уже начал писать тесты на Python + Behave (выбора у меня нет, требуют именно такой подход). Сценарии пишу на русском используя Gherkin.
Меня интересует как правильно писать шаги, могут ли они быть переиспользуемыми, из каких источников подставлять локаторы, использовать ли Page Object? Все перемешалось в голове и нет понимания как это все организовывать. Все выглядит очень неконсистентно.
В интернете есть пара примеров, но там очень простые случаи, которые не дают понимания как строить большую тестовую архитектуру. Нужно ли делать шаги уникальными или стоит максимально сделать шаги параметризуемыми? Нужно понять, как лучше все это делать. Нужно уловить суть и начать мыслить в рамках этого подхода. Но пока не получается, т.к. нет понимания в чем его плюсы и как мыслить используя его.
Заранее благодарю откликнувшихся 😊

Один скрипт на питоне который 1) получает из командной строки задачу на то какой репорт сделать 2) получает информацию через апи 3) имеющиеся данные положить в HTML страничку

Показываю code coverage

Построчно и по веткам

Метрика так себе конечно но описывать весь функционал огромного проекта тесткейсами лень, а это еще поддерживать надо, помимо тестов

Это как

Знаешь, мой опыт говорит, что делай как можешь, лишь б это тестировалось, а только потом ты сможешь улучшить, переделать и так далее, все равно паттернами сразу не научишься думать, это нормально, для этого требуется время, осознание, почему так, а не иначе. Чем больше код становится, тем сложнее в нем ковыряться и искать проблемы, но все равно спустя кучи ошибок ты поймёшь картину и сможешь пересмотреть код и начнёшь в свободное время от работы во втором репозитории собирать свой фреймворк, который будет делать тоже самое, что и предыдущий вариант

Qc вроде как сам умеет трейсабилити строить. Но надо туда же и требования заводить