Чем ручками)

Нет, не лучше.

Ручное тестирование и автотестирование не имеют полной взаимозаменяемости.

Это инструменты, которые в зависимости от случая и цели выгоднее использовать.

Я столкнулась с тем, что автотесты не могут покрыть полностью функционал и применения ручного прогона необходим. Именно подумываю ручной прогон смоук- тестами

смоук могут быть и ручными и авто

Это нормально.

Чтобы написать регресс-тест, нужно написать его так, чтобы он падал при малейшем изменении любой части функционала. Обычный же тест должен падать только при изменении максимально узкой части функционала.

что простите?

Кто пользуется инструментом TestRail, поделитесь опытом :) можно созданные раны считать этапом регресс тестирование ? То есть собираем кейсы старого функционала для проверки нового функционала

Почему нет?

Ну, можно, но зачем?

Проще хранить отдельный regression suit, по которому делать раны.

что простите?

Регрессионный тест диалога с 10 элементами должен падать при изменении в поведении любого элемента. Функциональные тесты так дизайнить нельзя. Они должны покрывать максимально узкий функцонал, иначе слишком дорого будет их поддерживать.

Если у вас есть ресурсы на создание и поддержку регрешн паков, состоящих из функциональных тестов, то вам очень повезло.

Кто пользуется инструментом TestRail, поделитесь опытом :) можно созданные раны считать этапом регресс тестирование ? То есть собираем кейсы старого функционала для проверки нового функционала

Там у каждого кейса есть тип. Те которые регресс выставляй соответствующий

Потом легко прогоны создавать / планировать

подробными тест кейсами кто-то пользуется до сих пор?

Регрессионный тест диалога с 10 элементами должен падать при изменении в поведении любого элемента. Функциональные тесты так дизайнить нельзя. Они должны покрывать максимально узкий функцонал, иначе слишком дорого будет их поддерживать.

Но ведь при изменении любого элемента диалога упадет тот узкий функциональный тест который мы написали. Это и есть регрессия.

кто нибудь использовал в автотестах доступ до нетворка у хром девтулс? хочу читать содержимое нетворка после действий пользователя

https://github.com/bayandin/devtools-proxy поможет?

Но ведь при изменении любого элемента диалога упадет тот узкий функциональный тест который мы написали. Это и есть регрессия.

Создание функциональных тестов на все элементы - непозволительная роскошь для интерпрайза

Ага

А как тогда написать такой чудо-регресс чтобы он при малейшем изменении падал?

Цеплять по максимуму все элементы минимумом кейсов

делайте скрины и все %)

и сравнивайте

Если поля друг с другом не связаны, можно, к примеру, проверять их параллельно

помоему всегда стараются чтобы минимальные изменения не повергали тесты в падение

кто нибудь использовал в автотестах доступ до нетворка у хром девтулс? хочу читать содержимое нетворка после действий пользователя

в проде нет, просто посмотреть – использовал

коллеги, а по Rest-Assured кто-то из присутствующих может проконсультровать? а то я уже тупым себя чувствую

Полезная штука? https://medium.com/@aandryashin/selenium-done-in-60-seconds-176796f8bdc7

помоему всегда стараются чтобы минимальные изменения не повергали тесты в падение

Так стараются только там, где точность не критична.

в проде нет, просто посмотреть – использовал

и что скажешь? можно получить данные из нетворка?

коллеги, а по Rest-Assured кто-то из присутствующих может проконсультровать? а то я уже тупым себя чувствую

я курлом запрос делаю, а библиотечкой не получается

точнее 404 -я прилетает

и что скажешь? можно получить данные из нетворка?

можно, вопрос зачем

у нас события отсылаются на разные пользовательские действия, и что то этих событий стало очень много

А чем лучше организовать процесс скриншот-тестов для web? 1. Генерация скриншотов (например, BrowserStack) 2. Сохранение их куда-нибудь на SFTP или другой локальное хранилище 3. Сравнение с эталоном и показ "разницы", процентов и т.д. 4. По запросу - замена эталонов на последний снимок

вот вроде хороший инстумент https://tech.yandex.ru/gemini/

ага, офигенный инструмент

Вот "вроде" - это одно, а у кого на деле этот workflow работает по схеме выше?

у яндекса!

у нас события отсылаются на разные пользовательские действия, и что то этих событий стало очень много

а зачем вам это отлавливать в автомейшене, а не руками? то есть как ты будешь в тестах чекать количество исходящих запросов? :)

смотреть тело запросов

наверно

зачем - потому что много ручного труда

так ты все равно потом глазами их пойдешь смотреть

какая разница? :)

зачем - потому что много ручного труда

Бред

?

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

Давайте ещё мердж конфликты веток автоматически разруливать

Всегда

я бы заплатил много денег за такую тулу)))

вот вроде хороший инстумент https://tech.yandex.ru/gemini/

О, спасибо !) надо изучить ...

Ui тесты это бизнес требования. Запросы - это вайтбокс. Зачем одно в другое мешать

Нормальный разработчик сам должен отдебажить кол-во запросов

его это тоже уже достало

Это его работа, сорян

его это тоже уже достало

нехрен писать что-то, чью работу чел не контролирует)

Есть browsermob proxy

есть nginx

browsermob proxy тоже хотел попробовать

Ui тесты это бизнес требования. Запросы - это вайтбокс. Зачем одно в другое мешать

а если я хочу проверить что на фронте отрисовалось ровно то что с бэка прилетело? или фронт отфильтровал правильно?

Я в таких случаях селениум юзаю, отлично считает что нужно

а с чем сравнивать?)

Давайте ещё мердж конфликты веток автоматически разруливать

Давно пора.

а с чем сравнивать?)

что значит с чем сравнивать. Пример: тестирую рендер постов в фиде. исходное состояние: посчитал кол-во эл-тов сообщений на странице: 10 Прокручиваю вниз страницу: на бек улетает запрос на получение постов, с лимитом в 5: автотест прокручивает методом до конца (по сути - имитация End клавиши) - ждем, что после отрендера кол-во эл-тов стало 15. Профит.

ERROR: S client not available

а если я хочу проверить что прилетело ровно то что я просил? например сообщения по теме или за дату, и я хочу не 5, а за последние сутки и число их разное

для проверки кол-ва запросов есть консоль хрома, Кибана, что угодно. Если гоняете тесты локально, то можете хоть логи nginx парсить . Но мой опыт подсказывает, что если фроненд разработчик не может разрулить, на какие ивенты у него что шлется и сколько, то это очень печально :) обычно, это единоразовый чек-фикс.

а если я хочу проверить что прилетело ровно то что я просил? например сообщения по теме или за дату, и я хочу не 5, а за последние сутки и число их разное

есть тестирование по контракту

я только тулы не помню(

если он пишет на дефолтной рельсе или джанге или Ларавел - он уже при большом желании в себе в ногу не стрельнет идиотским запросом - орм не должен позволить. Прочекать как он засирает и бомбит бэк запросами с фронта - его обязанность. Ты можешь проверить, но рука от этого имхо не отвиснет пару раз проверить в консоли что по ТЗ 1 запрос улетел

а если я хочу проверить что прилетело ровно то что я просил? например сообщения по теме или за дату, и я хочу не 5, а за последние сутки и число их разное

Count в базу) и сравнить

если мы говорим про get запросы, проще логи нжинкса смотреть

Тоже вариант) грепом достать все)

а если я хочу проверить что прилетело ровно то что я просил? например сообщения по теме или за дату, и я хочу не 5, а за последние сутки и число их разное

это api тест больше

если конечно у приложения есть api слой

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

Ок. Давайте пойдем по обратному пути :) Скажи как ты в коде бы хотел чтобы выглядела проверка

напишешь псевдокод?

if type == 'blabla' {выбрасываем из выборки}

или ты хочешь мою проверку увидеть?

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

ну например

Язык Kotlin для автотестов кто использовал? (Позвольте вернуть вас на стезю обсуждения языков и фреймворков автотестирования.) Kotlin совместим с Java - т.е можно писать в любом джавовсвком фреймворке. Но у котлина отсутствуют все эти нелепые церемонии, за которую не любят джаву. Синтаксис Котлина существенно проще и прозрачнее. Плюс kotlintest есть.

# где-то в тесте results_page.apply_filters(['blabla']) # в этом месте ты уже должен знать что ты хочешь assert len(search_results) == 4 for result in search_results: assert result.text == 'blabla_type'

не вижу проблемы, вся инфа страницы хранится в css атрибутах, в тексте, в классе, в чем угодно - во что ее решает положить разработчик

по факту ивента можно это прочекать и поассертить

ну вот я эту четверку тоже хочу динамически получать

но другим путем

как это динамически?

ну вот сегодня было 10 таких транзакций, а завтра 150

и я не хочу проверку переписывать

что общего у этих транзакций?

дата, тип...

тип? где он лежит в html

видит его пользователь?

мы в мобилке)

что значит мы в мобилке. Мы в мобильном браузере? или это нативное приложение?