Добрый день. Коллеги, нужен ваш совет.
Компания решила сделать автоматизацию функционального тестирования через UI. В результате, тестов становится больше, а сам процес автоматизации тяжелеет. Подскажите, пожалуйста:
Зависит от того, что хочется проверить.
Если надо проверить, что увидит пользователь - работаем с UI. если надо проверить форматы передаваемых и получаемых данных, ответы от сервисов и т.д. - проверям бэкэнд.
Логично,что тестов становится больше. Так и должно быть. Когда их станет слишком много - будете учиться параллелизации 
Пример, у нас есть форма с десятком разных полей, всякие списки, чекбоксы и т.д. и кнопка “отправить”. При нажатии на кнопку данные с формы улетают на бэкенд, там обрабатываются и мы получаем какой-то ответ. В этом случае нет смысла делать кучу UI тестов с перебором параметров. Надо сделать несколько UI тестов с корректным заполнением и несколько тестов с некорректным. Конкретное кол-во зависит от конкретного кейса. А все остальные комбинации тестировать на более низком уровне, например просто посылая HTTP запрос и проверяя ответ.
Спасибо за ответы и за подсказки с параллелизацией, будуьначинать изучать.
Идея и преимущества backend понятны. Встречались ли вам статьи на похожую тематику? и желательно на англ. Начальство англоговорящие, надо грамотно донести инфу. Гугл не очень помог, или гуглила не то( .
Ищи про ice-cream cone (anti-pattern)
http://googletesting.blogspot.ru/2015/04/just-say-no-to-more-end-to-end-tests.html
https://watirmelon.com/2012/01/31/introducing-the-software-testing-ice-cream-cone/
Интересная тема конечно, я вот тоже хочу лучше понять, где и что использовать. По пирамиде автоматизации “API level” - должен быть больше по тестам, чем “UI-тесты”. Но вот если у тебя, по сути, проверив UI - достаточно сказать, что данная фича работает правильно, то выходит API, бекенд вообще не тестируешь… Разве что только если надо проверить кучу разных всяких данных на ответ от сервера…
Правильность работы бывает разная. Встречал случаи, когда две ошибки в двух различных подсистемах приводили систему к правильному состоянию работы.
Тестировать API - проще, быстрее и дешевле + дает возможность проверять вещи, которые через GUI сделать невозможно/сложно. А также при тестировании GUI довольно удобно использовать подготовку данных и состояний системы через вызовы API, а не делать все через интерфейс пользователя. Это экономит много времени и стабилизирует тесты.
При этом про GUI тестирование забывать тоже не стоит.
По поводу главного вопроса топик-стартера - то эффективность в чем хотите оценивать? Могу сказать, что дешевле и проще покрывать нижние уровни (Unit, API), а верхние можно и руками смотреть. Да, собственно их и придется в любом случае хоть раз, но глазами живого человека проверить, потому что роботам тут доверять не стоит. Тесты так же как и обычное ПО может содержать ошибки и зеленые тесты, еще не означают безошибочное ПО. Главная проблема авто-тестов - это правильность построения тестовой модели, а это уже не в области автоматизации. Автоматизация тут всего лишь инструмент, сокращающий ручную работу людей, точнее переводящий её на другой уровень (часто автоматизация сжирает усилий не меньше, чем ручное тестирование).
Но в этом случае следует учесть, если есть валидация пользовательских значений с двух сторон, и на клиенте и на сервере. Если и там и там есть валидация, то стоит всё таки 1 - клиентскую валидацию с соответствующими сообщениями о невалидности проверять 2 - проверять ответ от сервера по аналогичным правилам валидации.
Ну, а если валидация выполняется только на сервере, а на клиенте нет, то тогда и только тогда для UI должно быть несколько тестов 1 валидный и пару не валидных если ответы от сервера специфические бывают.
На моей практике валидация пользоватлеьских значений выполняется и на клиенте и на сервере, при этом валидация на клиенте выполняется дважды при потере фокуса и при сабмите формы, после чего выполнятеся на сервере. И для привинтирования проблем дублировал проверки, т.к. аналитики могут забыть с двух сторон корректировать правила валидации.
Это верно, если не рассматривать влияние третьих систем. Вызывающих систем может быть несколько. И значения они могут по разному отсылать и не все будут валидировать. Так что API нужно проверять тщательнее, чем клиента.
Простите, а как еще можно тестировать функциональность классического сайта, исходя из того что видят пользователи, не прибегая к использованию UI?
Можно вручную тестировать, без автоматизации 
Если компания решила применить автоматизацию, то видимо видит в ней выгоду для себя (и она правда есть, хоть и не всегда)
Автоматизация backend vs UI, что эффективнее?
Я наверно что то не так прочитал. О ручном тестировании речи не шло, а татл-топик вообще пестрит чем то “интересным”
Ну, ок. Для тестирования сайта можно написать сценарии, которые дергают API и на них проверить сотни бизнес-сценариев, а вот уже через UI делать меньшее число сценариев, где не перебирать различные состояния объектов, а смотреть на переходы. В итоге UI проверит корректность вызовов API и переходов, отрисовку элеметнов. А при проверке API будут более глубоко проверены сценарии с различными состояниями (разные дни, разные типы клиентов и т.д.)
Не хочу показаться каким то грубым, но таким “сценариям” грош цена, если это не какое либо паблик API для сервисов вторых лиц, а нормальный сайт, насколько мне известно, как раз проверяется методами и органами управления, которые доступны юзеру-обывателю. [quote=“Mihail_Bratuhin, post:13, topic:10166”]
а вот уже через UI делать меньшее число сценариев, где не перебирать различные состояния объектов, а смотреть на переходы
[/quote]
ага, а валидаторы, а степ-хелперы, как вы проверять будете? ответ - вводя корректные данные. А как вы реакицию системы будетет тестить на не корректные данные? - ломая бизнес логику. Так в чем тогда прелесть слать реквестером GET/POST если это же будет дублированно в UI сценариах?
Подходы разные бывают. Есть плюсы и минусы у всех. API можно применять хотя бы для того, чтобы не скакать по сотне ссылок через GUI и заполнять анкетки, а придти к нужно странице с нужным состоянием и там уже проверить что нужно.
Видел доклады, где у людей десятки тысяч тестов и каждый тест = одной проверке. А кто-то делает множество проверок в одном тесте. У всех свои подходы и вкусы. Сказать что одно однозначно лучше другого тут нельзя.
Еще кто-то чистит все при запуске каждого теста, а кто-то наоборот не чистит. Кто-то ищет в БД данные, а кто-то создает для теста. И это на самом деле два различных теста. Просто один проверяет работу с новыми созданными сущностями, а второй с уже имеющимися в БД и т.д. И эти тесты ловят разные классы ошибок.
Для того что бы придти к нужной странице, необходимо использовать фикстуры, которые тестируются в первую очередь.
Делать множество проверок в одном тесте это не очень хороший написания тестов.
Вы путаете реализацию тестов, и сам процесс тестирования, если следовать вашей трактовке, то хватит API заглушек на стороне сервера (аля юнит тестов которые сразу подергают нужные классы) - и процесс тестирования выполнен, если пользователю предоставлен UI управления, то его и нужно тестить, а если вас интересует красивый ли JSON передается от клиента к серверу - то это малость другая парафия, да и, будь он не красивый сервер бы его не распарсил)
Подходы бывают разные. Вот тут недавно перевод статьи был про развитие автоматизации - Автоматизация тестирования – это ваш огород
Там есть пункт в самом начале
С чего начать?
Налаживая автоматизацию, вы должны выяснить, какие тесты вы хотите
автоматизировать и почему. Примите во внимание корпоративную культуру,
доступность инструментов, контекст, и особенности продукта, которые
повышают долгоиграющую ценность вашего бизнеса.
Если вы у себя применили один подход и он работает, то это не означает, что не бывает других подходов и они не работают. В некоторых компаниях вообще нет выделенной роли тестировщика и ничего, как-то выпускают релизы и даже почти без багов. Были доклады от команды Badoo по-моему и там они рассказывали, что у них для тестирования мобильных платформ используется отдельное тест-апи и еще специальный мониторинг и т.д. Они выбрали для себя вот такой подход.
Если вы приминили работающий для вас подхот, то это не значит что концептуально он верный. Спагетти-код ведь тоже работает как-то, и все такое.
Дело в том, что стандарты как раз и приняты объеденить общие для данной отрасли идеи и практики, что бы любой человек, который прикрепится к данной области мог сразу понять о чем идет речь
Ведь гвозди можно забивать плостогубцами, ну вот - у меня ведь получается и все окей - гвозди в досках, ну это ниче, что новый чувак прийдет и такой:
ЗЫ. Как то так вот Суровый IT Продакшн | VK
Посмеялся с этой заметки.
Но как говорится: все аналогии лживы.
Если честно, то мне все равно на спагетти, если оно работает. Вот есть такая замечательная социальная сеть Google+, которую писали лучшие инженера в количестве over 500 человек в течении двух лет из самой технологичной ИТ-компании мира и что в итоге? Зато фэйсбук написан тремя подростками в течении лета на php.
Мы тут можем сколь угодно спорить об этой философии, но на это еще товарищ Джугашвили как-то сказал “Других писателей у меня для вас нет”.
Очень часто приходится выбирать из того что есть, а не того что написано в правильных книгах и рассказывается на курсах о правильной методологии. Я не говорю, что это правильно или хорошо. Просто так есть. А вообще тестирование, в том числе и его автоматизация - это всего лишь локальная оптимизация. И она не даст сама по себе результата без правильного управления всем процессом разработки.
Если я говорю, что можно применять такой или другой подход, то нужно понимать и то в каких случаях он приемлем и его ограничения. Это инженерный подход. Просто часто люди берут первое попавшееся без осмысления плюсов и минусов, а потом удивляются почему что-то пошло не так.
testomat.io управление авто тестами