Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Автоматизация backend vs UI, что эффективнее?

backend
squish
gui
python
Теги: #<Tag:0x00007f7b62e9dd08> #<Tag:0x00007f7b62e9dbc8> #<Tag:0x00007f7b62e9d808> #<Tag:0x00007f7b62e9d678>

(Lera) #1

Добрый день. Коллеги, нужен ваш совет.
Компания решила сделать автоматизацию функционального тестирования через UI. В результате, тестов становится больше, а сам процес автоматизации тяжелеет. Подскажите, пожалуйста:

  1. эффективность функциональных тестов лучше через UI или backend?
  2. автоматизация через backend “легче” и быстрее? или нет?
  3. стоит ли вообще заморачиватся backend тестированием?
    Спасибо.


(Дмитрий Мирошник) #2

Зависит от того, что хочется проверить.
Если надо проверить, что увидит пользователь - работаем с UI. если надо проверить форматы передаваемых и получаемых данных, ответы от сервисов и т.д. - проверям бэкэнд.
Логично,что тестов становится больше. Так и должно быть. Когда их станет слишком много - будете учиться параллелизации :slight_smile:


(Artem Nikitin) #3
  1. зависит от проекта\продукта
  2. да
  3. да

Пример, у нас есть форма с десятком разных полей, всякие списки, чекбоксы и т.д. и кнопка “отправить”. При нажатии на кнопку данные с формы улетают на бэкенд, там обрабатываются и мы получаем какой-то ответ. В этом случае нет смысла делать кучу UI тестов с перебором параметров. Надо сделать несколько UI тестов с корректным заполнением и несколько тестов с некорректным. Конкретное кол-во зависит от конкретного кейса. А все остальные комбинации тестировать на более низком уровне, например просто посылая HTTP запрос и проверяя ответ.


(Lera) #4

Спасибо за ответы и за подсказки с параллелизацией, будуьначинать изучать.
Идея и преимущества backend понятны. Встречались ли вам статьи на похожую тематику? и желательно на англ. Начальство англоговорящие, надо грамотно донести инфу. Гугл не очень помог, или гуглила не то( .


(HaraD) #5

Ищи про 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/


(Eugene Moskalenko) #6

Интересная тема конечно, я вот тоже хочу лучше понять, где и что использовать. По пирамиде автоматизации “API level” - должен быть больше по тестам, чем “UI-тесты”. Но вот если у тебя, по сути, проверив UI - достаточно сказать, что данная фича работает правильно, то выходит API, бекенд вообще не тестируешь… Разве что только если надо проверить кучу разных всяких данных на ответ от сервера…


(Михаил Братухин) #7

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

Тестировать API - проще, быстрее и дешевле + дает возможность проверять вещи, которые через GUI сделать невозможно/сложно. А также при тестировании GUI довольно удобно использовать подготовку данных и состояний системы через вызовы API, а не делать все через интерфейс пользователя. Это экономит много времени и стабилизирует тесты.

При этом про GUI тестирование забывать тоже не стоит.

По поводу главного вопроса топик-стартера - то эффективность в чем хотите оценивать? Могу сказать, что дешевле и проще покрывать нижние уровни (Unit, API), а верхние можно и руками смотреть. Да, собственно их и придется в любом случае хоть раз, но глазами живого человека проверить, потому что роботам тут доверять не стоит. Тесты так же как и обычное ПО может содержать ошибки и зеленые тесты, еще не означают безошибочное ПО. Главная проблема авто-тестов - это правильность построения тестовой модели, а это уже не в области автоматизации. Автоматизация тут всего лишь инструмент, сокращающий ручную работу людей, точнее переводящий её на другой уровень (часто автоматизация сжирает усилий не меньше, чем ручное тестирование).


(Roma Marinsky) #8

Но в этом случае следует учесть, если есть валидация пользовательских значений с двух сторон, и на клиенте и на сервере. Если и там и там есть валидация, то стоит всё таки 1 - клиентскую валидацию с соответствующими сообщениями о невалидности проверять 2 - проверять ответ от сервера по аналогичным правилам валидации.
Ну, а если валидация выполняется только на сервере, а на клиенте нет, то тогда и только тогда для UI должно быть несколько тестов 1 валидный и пару не валидных если ответы от сервера специфические бывают.
На моей практике валидация пользоватлеьских значений выполняется и на клиенте и на сервере, при этом валидация на клиенте выполняется дважды при потере фокуса и при сабмите формы, после чего выполнятеся на сервере. И для привинтирования проблем дублировал проверки, т.к. аналитики могут забыть с двух сторон корректировать правила валидации.


(Михаил Братухин) #9

Это верно, если не рассматривать влияние третьих систем. Вызывающих систем может быть несколько. И значения они могут по разному отсылать и не все будут валидировать. Так что API нужно проверять тщательнее, чем клиента.


(Goshko Nazar) #10

Простите, а как еще можно тестировать функциональность классического сайта, исходя из того что видят пользователи, не прибегая к использованию UI?


(Михаил Братухин) #11

Можно вручную тестировать, без автоматизации :wink:
Если компания решила применить автоматизацию, то видимо видит в ней выгоду для себя (и она правда есть, хоть и не всегда)


(Goshko Nazar) #12

Автоматизация backend vs UI, что эффективнее?
Я наверно что то не так прочитал. О ручном тестировании речи не шло, а татл-топик вообще пестрит чем то “интересным”


(Михаил Братухин) #13

Ну, ок. Для тестирования сайта можно написать сценарии, которые дергают API и на них проверить сотни бизнес-сценариев, а вот уже через UI делать меньшее число сценариев, где не перебирать различные состояния объектов, а смотреть на переходы. В итоге UI проверит корректность вызовов API и переходов, отрисовку элеметнов. А при проверке API будут более глубоко проверены сценарии с различными состояниями (разные дни, разные типы клиентов и т.д.)


(Goshko Nazar) #14

Не хочу показаться каким то грубым, но таким “сценариям” грош цена, если это не какое либо паблик API для сервисов вторых лиц, а нормальный сайт, насколько мне известно, как раз проверяется методами и органами управления, которые доступны юзеру-обывателю. [quote=“Mihail_Bratuhin, post:13, topic:10166”]
а вот уже через UI делать меньшее число сценариев, где не перебирать различные состояния объектов, а смотреть на переходы
[/quote]

ага, а валидаторы, а степ-хелперы, как вы проверять будете? ответ - вводя корректные данные. А как вы реакицию системы будетет тестить на не корректные данные? - ломая бизнес логику. Так в чем тогда прелесть слать реквестером GET/POST если это же будет дублированно в UI сценариах?


(Михаил Братухин) #15

Подходы разные бывают. Есть плюсы и минусы у всех. API можно применять хотя бы для того, чтобы не скакать по сотне ссылок через GUI и заполнять анкетки, а придти к нужно странице с нужным состоянием и там уже проверить что нужно.
Видел доклады, где у людей десятки тысяч тестов и каждый тест = одной проверке. А кто-то делает множество проверок в одном тесте. У всех свои подходы и вкусы. Сказать что одно однозначно лучше другого тут нельзя.

Еще кто-то чистит все при запуске каждого теста, а кто-то наоборот не чистит. Кто-то ищет в БД данные, а кто-то создает для теста. И это на самом деле два различных теста. Просто один проверяет работу с новыми созданными сущностями, а второй с уже имеющимися в БД и т.д. И эти тесты ловят разные классы ошибок.


(Goshko Nazar) #16

Для того что бы придти к нужной странице, необходимо использовать фикстуры, которые тестируются в первую очередь.
Делать множество проверок в одном тесте это не очень хороший написания тестов.
Вы путаете реализацию тестов, и сам процесс тестирования, если следовать вашей трактовке, то хватит API заглушек на стороне сервера (аля юнит тестов которые сразу подергают нужные классы) - и процесс тестирования выполнен, если пользователю предоставлен UI управления, то его и нужно тестить, а если вас интересует красивый ли JSON передается от клиента к серверу - то это малость другая парафия, да и, будь он не красивый сервер бы его не распарсил)


(Михаил Братухин) #17

Подходы бывают разные. Вот тут недавно перевод статьи был про развитие автоматизации - Автоматизация тестирования – это ваш огород
Там есть пункт в самом начале

С чего начать?
Налаживая автоматизацию, вы должны выяснить, какие тесты вы хотите
автоматизировать и почему. Примите во внимание корпоративную культуру,
доступность инструментов, контекст, и особенности продукта, которые
повышают долгоиграющую ценность вашего бизнеса.

Если вы у себя применили один подход и он работает, то это не означает, что не бывает других подходов и они не работают. В некоторых компаниях вообще нет выделенной роли тестировщика и ничего, как-то выпускают релизы и даже почти без багов. Были доклады от команды Badoo по-моему и там они рассказывали, что у них для тестирования мобильных платформ используется отдельное тест-апи и еще специальный мониторинг и т.д. Они выбрали для себя вот такой подход.


(Goshko Nazar) #18

Если вы приминили работающий для вас подхот, то это не значит что концептуально он верный. Спагетти-код ведь тоже работает как-то, и все такое.

Дело в том, что стандарты как раз и приняты объеденить общие для данной отрасли идеи и практики, что бы любой человек, который прикрепится к данной области мог сразу понять о чем идет речь
Ведь гвозди можно забивать плостогубцами, ну вот - у меня ведь получается и все окей - гвозди в досках, ну это ниче, что новый чувак прийдет и такой:

  • “WTF - вы чо гвозди пласкобубцам ибьете?”
  • “ну а чо, забиты ведь, ну да, остаются вмятины на досках, ну может кому то не удобно, но ведь привыкнешь и все такое”
    Забавно когда приходит “правильный человек”, у него тогда вообще стоит ужас в глазах.

ЗЫ. Как то так вот https://vk.com/chayproduction?w=wall-41291113_4317


(Михаил Братухин) #19

Посмеялся с этой заметки.
Но как говорится: все аналогии лживы.

Если честно, то мне все равно на спагетти, если оно работает. Вот есть такая замечательная социальная сеть Google+, которую писали лучшие инженера в количестве over 500 человек в течении двух лет из самой технологичной ИТ-компании мира и что в итоге? Зато фэйсбук написан тремя подростками в течении лета на php.

Мы тут можем сколь угодно спорить об этой философии, но на это еще товарищ Джугашвили как-то сказал “Других писателей у меня для вас нет”.

Очень часто приходится выбирать из того что есть, а не того что написано в правильных книгах и рассказывается на курсах о правильной методологии. Я не говорю, что это правильно или хорошо. Просто так есть. А вообще тестирование, в том числе и его автоматизация - это всего лишь локальная оптимизация. И она не даст сама по себе результата без правильного управления всем процессом разработки.

Если я говорю, что можно применять такой или другой подход, то нужно понимать и то в каких случаях он приемлем и его ограничения. Это инженерный подход. Просто часто люди берут первое попавшееся без осмысления плюсов и минусов, а потом удивляются почему что-то пошло не так.