Что же тестировать с помощью Selenium'а?!

webdriver
,
#1

Здравствуйте!
Дамы и господа, если не жалко поделитесь опытом…
Ну что же все таки нужно и можно тестировать при помощи Selenium WD?! Как в реальности обстоят дела?
Есть webApp(singlePage). Задача после реализации тестируется вручную, после чего пишутся сценарии.
А вопросы вот такие:

  • Нужно ли повторять в Selenium тестах то, что и без того проверено в unit’ах + проверяется полностью руками перед написанием?

например, валидация поля цена, писать ли тесты на все граничные значения и области эквивалентности, или достаточно будет одного негативного теста(проверить, что поле краснеет при неверном вводе) и одного позитивного.
Еще часто аргументируют следующим: “Отдельно модули конечно работают а вот в связке для конечного пользователя это отработает”?

  • Нужно ли писать сценарии на абсолютно все возможные варианты негативных end-to-end сценариев для провеврки функционала? Перебрать все варианты которые могут привести к ошибкам. Или достаточно одного позитивного. Для регрессии конечно все варианты будут хорошим покрытием, но вот простота их поддержки сомнительна…

  • Какой из статического контента стоит проверять? Например, сообщения об ошибках, заголовки форм, название кнопок и тд.

Может поделитесь статьями или личным опытом или еще чем…
Всем заранее спасибо!

#2

Привет!
Кортокий ответ - нет, дублировать не нужно. Юнит-тестов должно быть много, UI-тестов должно быть мало.

Длинный ответ: всё, что только можно, нужно тестировать юнит-тестами. Включая юнит-тесты на серверном стороне (Java или что там у вас) и юнит-тесты на клиентской стороне (JavaScript) - том числе валидация в JS, граничные значения, подсветка полей и т.д.

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

Хороший доклад на эту тему: Экономически эффективный процесс тестирования :slight_smile:

2 лайка
#3

Unit tests не покрывают e2e сценарии. Единоразовая ручная проверка не избавляет вас от регрессии.

Exhaustive testing is impossible. © Foundations of Software Testing

Техники equivalence partitioning / boundary values analysis / pairwise testing вам в помощь.

Только тот, который является критически важной частью бизнес сценария. В конце концов, вы занимаетесь functional или usability testing?!

#4

Позволю себе не согласится.
Юнит тесты проверяют крайне ограниченную часть приложения
Можно переложить большую часть забот на тесты интеграции.API тесты+БД
Но только юриты и немного UI - плохое решение
Стандартная пирамида
10-ки UI тестов
100-ни API тестов
1000-чи Unit тестов

При этом польза для бизнеса зачасую обратно пропорциональна количеству. И реальной пользы от 50-100 UI тестов Может быть гораздо больше чем от 5000-10000 unit тестов

#5

Да, я неточно выразился.
Я имел в виду не только юнит-, но и интеграционные и БД тесты. Т.е. пирамида в силе, да.

И реальной пользы от 50-100 UI тестов Может быть гораздо больше чем от 5000-10000 unit тестов

А вот это проблема! Надо задаться вопросом, почему пользы от юнит-тестов мало? Значит, плохо написанные юнит-тесты. Надо всерьёз задуматься и начать их писать так, чтобы была польза.

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

См.

  1. Beware the Integrated Tests Scam (was Integrated Tests Are a Scam) - The Code Whisperer
  2. J.B. Rainsberger - Integrated Tests Are A Scam on Vimeo
1 лайк
#6

Unit tests не покрывают e2e сценарии. Единоразовая ручная проверка не избавляет вас от регрессии.

Полностью с вами согласен. Возможно вы меня не так поняли, или я не так выразился… Я имел ввиду следующее: ну честное слово не понимаю зачем проверять все значения поля если есть юнит тесты, ведь проверка поля это не e2e, не так ли? А придется тратить время на такой тест и их много ибо полей хватает… Здесь полностью соглашусь с asolntsev.

В конце концов, вы занимаетесь functional или usability testing?!
Вот в том

В том и беда, что как я понял, от меня хотят и того и другого… И похоже, что понимания о том как найти грань где заканчивается один вид и начинается другой у нас маловато…

#7

Можно переложить большую часть забот на тесты интеграции.API тесты+БД

А разве нельзя сказать что SWD тесты интеграционные(ну хотя бы отчасти)? Разве они не проверят связь модулей и тот факт, что они верно взаимодействуют? Скажем взять тот же интернет магазин, нужно проверить след. функц.:пользователь может совершить покупку. Прошлись селениумом протыкали контроллы, заполнили все поля, сделали покупку проверили бд и тд. - не проверили связь модулей разве?

#8

А что значит “от меня хотят”? Кто хочет? Как аргументируют? Может вам пора предоставить свое собственное мнение на сей счет, чтобы немного усмирить хотелки остальных? :slight_smile: А если бездумно выполнять любые прихоти руководства, вы же потом и окажетесь виноватым в том, что якобы ваша автоматизация - неэффективна.

Это системная интеграция, а не компонентная (если говорить об уровнях тестирования).

e2e тесты далеко не факт, что покроют взаимосвязи всех компонентов. Точнее, факт, что не покроют.

#10

А можно сказать, что если мы будем писать unit’ы в которых есть проверки взаимодействия модулей, работа с БД и т.п., то это уровень компонентной интеграции??

#11

unit и integration - 2 разных типа тестов. Я не понимаю, что значит писать unit’ы с проверкой взаимосвязей модулей. По какому критерию они будут именоваться unit?

#12

Прошу простить, что с терминологией так небрежно…я имею ввиду, например, на JUnit или TestNG можно писать только модульные тесты, и разве их взаимодействие не проверить?
Или эти библиотеки для обоих уровней тестирования?..Просто дело будет в том, к какому уровню мы их отнесем на словах, в зависимости от того, что в них накодено будет (или разделим по пакетам или еще что)?
С помощью чего тогда мы можем писать компонентную интеграцию если не с помощью этих библиотек?
Кажется я совсем запутался…

#13

кажется я тут что-то не то сморозил…)

#14

Всё верно, JUnit и TestNG подходят для любых видов тестов, не только для юниоров-тестов.

1 лайк
#15

Всем огромное спасибо!

#16

Недавно читал по данному поводу пару статеек, опыта мало, но прикинул себе некую стратегию.

У нас есть разные уровни тестирования. Также у нас есть пирамида тестирования, как выше правильно написали:

  • 10-ки UI тестов
  • 100-ни API тестов
  • 1000-чи Unit тестов

Пример возьмем - покупку в интернет-магазине, выше уже приводили в пример…

По итогу получаем:

  • разработчик на бекенде пишет множество юнит тестов, в которых будут корректные и некорректные данные, ввод полей, форм (пример), на уровне бекенда
  • фронтенд-разработчик возможно также пишет юнит тесты на валидацию полей, но уже на стороне JS
  • затем происходит ручное тестирование, после чего тестировщик пишет кейсы, производит тест-дизайн, и пишет UI автотесты для регрессии, для той функциональности, которая будет постоянно меняться или имеет высокий приоритет (там всякие покупки и т.д.). Скорее всего это и есть тот уровень тестирования, когда проверяется, как все компоненты работают в целом. Тут уже можно не делать 100500 валидаций для автотестов, только проверка, что при валидных данных осуществляется покупка в интернет-магазине, а при не валидных показывается какой-то поп-ап или сообщение пользователя с правильным цветом сообщения

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

Где, кто и как тестирует, попадают ли данные в БД, тут не совсем пока понимаю… Но на уровне UI тестов, думаю стоит проверить попала ли покупка в кабинет пользователя и кабинет администратора, и правильные ли данные она получила после сценария покупки.

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

Чтобы получить наименьшее количество больших и сложных в поддержке UI тестов - люди пишут API тесты и UNIT тесты. Также еще UI тесты можно использовать для всяких там дропбоксов, загрузки файлов и т.д, что собственно и происходит во время написания автотестов для покупки на стороне пользователя… Но их получается очень незначительно количество, из-за того, что на более низком уровне мы покрыли уже часть сценариев с валидацией и тем, что отдает нам сервер.

Ручное же тестирование проверяет, правильно ли работает фича, но к сожалению не полностью проверяет, корректно ли написаны юнит-тесты и API тесты, собственно поэтому ручное тестирование наверное и проводят полностью, согласно ранее проделанного тест-дизайна…

По итогу получим протестированный продукт на разных уровнях + наименьшее количество UI тестов для наиболее приоритетных вещей и постоянной регрессии + резолюцию тестировщика, что все работает согласно заявленным требованиям… Тоесть, не надо пихать в UI тесты 100500 разных данных на проверку корректности и что же там произойдет дальше.

1 лайк