There are lots of cool testing frameworks for different programming languages. Unfortunately only few of them can provide good representation of test execution output. Yandex testing team is working on Allure http://allure.qatools.ru/ - an open-source framework designed to create test execution reports clear to everyone in the team.
Если хотите добавить ссылку, доклад, видео, и все что считаете нужным, просто комментируйте эту тему, а модераторы будут выносить полезные информацию в тело этой темы.
Эта тема прилеплена. Она будет всегда отображаться первой в списке тем своей категории, пока не будет отлеплена модератором, или сброшена вниз, когда каждый пользователь нажмет кнопку «Отлепить»
@polusok как и обещал - @vania_pooh - один из команды разработки allure. Думаю Ваня сможет немного информации добавить на эту страничку. @vania_pooh - тебе отдельное спасибо
Отсутствие колонки Passed на табе xUnit - это баг или фича?
Фильтр у сьютов на этом табе вообще какой-то невнятный: фильтрует тесты, но находится на странице сьютов, причем эти тесты могут быть и не открыты, а если какой-либо сьют открыт - получаем два фильтра, которые дублируют друг-друга.
Также жутко не хватает тотала. В совокупности в нормальным фильтром по сьютам можно было бы собирать интересную статистику: например, сколько отняли времени зафейленные тесты.
Кастомизации, я так понимаю, нету никакой?
Разделение дефектов на product defects и test defects тоже довольно жесткое. Если в юнит-тестах оно и приемлемо, то в интеграционных - однозначно нет.
Попробую ответить.
Как мне видится - колонка passed - не особо и нужна. В принципе понятно, что все, что не попадает в другие колонки - passed. Да и кажется, что самая важная информация в отчете - это все таки ошибки и проблемы, если таковые есть.
Фильтры - это достаточно удобно, что можно на вкладке сьютов сразу отсортировать, чтобы ненужная информация не “мозолила” глаз, а отображалась только нужная информация.
По поводу времени - я согласен. Было бы интересно - если выбираешь только failed тесты - чтобы время тоже пересчитывалось. Надо предложить такое разработчикам.
Разделение дефектов - почему не применимо?
Сейчас как я понимаю считается, что если тест свалился с эксепшном - то значит он как-то неучтен, и значит тест написан плохо. Данное разделение как раз кажется нормальным.
Попробую возразить. Отчеты без “зелени” - это бред. Отчеты такого уровня “красивости” в первую очередь нужны для интеграционных авто-тестов и предназначаются, в первую очередь, не для самих писателей тестов, а для тиммейтов/менеджеров/заказчика. А для них, как правило, важно не сколько тестов “упало”, а сколько прошло. А наличие в фильтре “Passed”, и отсутствии соответствующей колонки вводит в когнитивный диссонанс.
Отчетность всегда строится по схеме Passed-Failed-Total, даже в ручном тестировании. Проделывать до четырех арифметических операций, что бы получить “базовую” цифру - это нонсенс.
[quote=“sidelnikovmike, post:11, topic:4983”]
Фильтры - это достаточно удобно, что можно на вкладке сьютов сразу отсортировать
[/quote]Согласен. Но… При данном функционале они совершенно бесполезны, да и в придачу изрядно путают. Вот зашел я на саммари, вижу фильтр по “Broken”, выключаю тесты со статусом “Broken”,и… ничего, ничего не изменилось. Хотя я ожидал, что эти гадкие желтые квадратики исчезнут
[quote=“sidelnikovmike, post:11, topic:4983”]
Разделение дефектов - почему не применимо?
[/quote]Я уже писал, для юнит-тестов этот подход - ок. Для UI тестов, помимо ассертов, слишком много вариантов падения тестов, что бы сразу это списывать на broken. А делать ассерты перед каждым экшеном никто не будет. Поэтому и нахожу эту фичу довольно спорной и непродуманной.
[quote=“sidelnikovmike, post:12, topic:4983”]
А вообще - все идеи можно писать на allure@yandex-team.ru
[/quote]Имхо, комьюнити лучше чем тет-а-тет. Может и в моих рассуждениях есть некоторые заблуждения. Вдруг меня поправят
testomat.io управление авто тестами
