Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Автоматизация тестирования: языки, библиотеки, инструменты и ресурсы в 2018 году

trends
Теги: #<Tag:0x00007fedba99eb20>

(Varden) #1

Всем привет,
я начинаю изучение автоматизации тестирование и пока не обладаю достаточными знаниями.
Очень прошу ребят и девчат :slight_smile: работающих в профессии поделиться информацией на темы:

[1] какие языки используют для каких целей и какие предпочтительней в силу разных причин (наличие библиотек, комьюнити, …)?

[2] какие библиотеки и фреймворки используют и для каких видов тестирования лучше использовать тот или иной?

[3] какие инструменты необходимы для написания кода?

[4] какие ресурсы лучше использовать для изучения и поддержания своих знаний на современном уровне? (сайты, школы, курсы)

Спасибо всем неравнодушным и готовым помочь!
С уважением Ден


(Maxim Andryushchenkov) #2

Вообще, таких вопросов было уже 100500, и с годами мало что меняется. Но кратко отвечу со своей колокольни:

  1. Я бы посоветовал язык для быстрого прототипирования - питон, руби(если вы любите смузи и коворкинги), и тд, ибо тест никогда не пишется с первого раза (хотя это зависит от проекта). Легенда AQA гласит, что есть крутые дядьки, которые пишут на Java полностью используемый код (типа написал один раз и работает, и пихаешь его куда угодно), но я таких не видел, только слышал о них.
  2. Тут вам никто не подскажет точно. Все зависит от проекта и требований. Только пожалуй Selenium - для WEB UI, остальные сферы - большая конкуренция
  3. Качественное IDE
  4. Данный сайт. Пользуйтесь поиском, очень много проблем было уже решено до вас, Ден)

(SergejsA) #3

Работал только в Java среде, тестируя в основном бэкенд, вэбсервисы и в меньшей степени фронтэнд. Поэтому советую только исходя из своего опыта и знаний.

  1. Успел пописать на Java, Groovy, Kotlin, немного пощупал питон. Для полноценных тестовых фреймворков, как по мне идеально подходит груви, для скриптов хорош питон. С Джавой все понятно, для тестов мне кажеться слишком много писанины и не обладает всякими крутыми динамическими штучками. Сейчас пишем тестовый фреймворк для вебсервисов на Котлине. Для опыта и получения новых знаний подходит, но переодически сталкиваемся со всякими интересными проблемами на которые трудно найти решение в гугле в связи с отсутствием развитого комьюнити.
    Так-же достаточно мало библиотек. Про UI тесты я вообще молчу.
    Я бы честно мог посоветовать Groovy, очень крутой динамический язык с кучей вкусностей. Разработчики писать на нём продакшн код не любят, но для тестов помоему просто замечательно подходит. Язык уже достаточно старый и вся инфа по нему есть в интернете, есть и куча библиотек, например “GEB” просто офигенная альтернатива Selenium. Да и зная груви с Gradle работать будет легче.
    Вот например отличное видео по Груви. https://www.youtube.com/watch?v=ZdFwId-P_UQ

  2. Я бы посоветовал для UI - Selenide, Geb. Для тестирования REST сервисов - Rest Assured, для assertion’ов Hamcrest, для BDD подхода конечно - Cucumber, для dependency injection - Google guice. В целом конечное зависит от проектов и требований.

  3. Я лично кроме Intellij IDE и хрома ничем особо не пользуюсь, может разве что POSTman для дерганья некоторых Rest запросов, ну и какая-нибудь тула для работы с базой. На винде если то putty для подключения через ssh, на линуксе терминал.

  4. Хрен знает даже, наверное на этом сайте можно много чего узнать. А так гугл. Но львиную долю инфы я всё-таки получаю при общении с коллегами программистами и тестировщиками


(Максим Таран) #4

Поддерживаю. Для тестов Groovy очень хорош.
Geb - замечательная штука!


(Maxim Andryushchenkov) #5

Товарищи, прямо заинтриговали. Что же там такого есть чего нет в связке Python + PyTest с его божественными фикстурами и предтестовой кастомизацией? Гуглить умею, просто интересно пережеванное мнение


(Максим Таран) #6

Как минимум то, что Python - не java. :slight_smile:


(Maxim Andryushchenkov) #7

Локанично, но не по теме


(Максим Таран) #8

Скажем так, groovy взял кое-что от питона. Но по мощности groovy, помимо всего прочего, прозрачно интегрирован с Java в обе стороны. Соответственно, нет проблем ни с многопоточностью, ни с наличием библиотек.
Вопрос не очень корректный. Если у вас система использует java-стек, то зачем использовать питон? Если тестируемая система на Python, то зачем нужна java?
По скорости изучения, мне кажется, языки одинаковые (хотя, лично для меня, код на groovy гораздо очевиднее, чем на питоне). Но, например, по работе с xml, json ничего удобнее groovy я не встречал.


(Женя Воронкин) #9

(rmerkushin) #10

И слава богу! :rofl:


#11

Java + Selenium и да будет тебе счастье. Почему Java - потому что по этому языку море информации в интернете, в отличии от всех остальных.


(Mr Ds Low) #12

Поделитесь, пожалуйста, как у вас реализован процесс автоматизации вообще.
Желательно у кого более менее отлажен уже этот рабочий поток, кто может поделиться опытом.
Допустим, я представляю, что вы написали опрд. (назовем его в текущем контексте) скрипт на Java/Python/др.
Далее? Приспособление через CI? Сборка куда-то через менеджер?
Потом: анализ: Cucumber/Allure/др.?

Можно совсем по-простому: последовательность действий - технология.

Если нужна область, из того, с чем работаете. Отдельно WEB, отдельно mobile и т.п.


(SergejsA) #13

Ну у нас обычно так настроено(всё на JVM):

  • Для каждого продукта есть отдельный тестовый проект в нашем репозитории (допустим сейчас используем GitLab).
  • В тестовом проекте полноценный тестовый фреймворк под тестируемый продукт (Тестовые сценарии на Cucumber’e, вызовы REST API, Web тесты и т.д)
  • В качестве build tool’а долгое время пользуюсь Gradle, поэтому в нем есть таски (методы) для запуска тестов
  • Таск запускается через command line и запускает тесты в нашем случае через Cucumber (‘команда к примеру: ./gradlew runApi -Penv=dev -Ptags=@myTest’)
  • В GitLab есть свой CI, поэтому пишем маленький скрипт в конфигурационном файле для гитлаба и получаем свой пайплайн джоб в котором будет запускаться наша команда.
  • Тесты прогоняются на выделенном серваке и весь результат выводится на консоль GitLaba
    Так как сейчас работаю в полу-стартапе где всего одна команда разработчиков, то с репортами и прочей херней не заморачиваемся.
    Вообщем получается так у нас процесс как-то (к примеру backend):
    1)Программист коммитит в мастер
    2) запускается билд
    3) прогоняются юнит и интегрейшн тесты
    3) деплоится на dev environment
    4) прогоняются наши acceptance тесты против уже задеплоенной полноценной аппликации
    5) если наши тесты прошли то можно деплоить дальше не stage
    Как-то так если вкратце.
    В больших компаниях там уже разные заморочки были, настроенный Jenkins, репорты и всякие другие приколы,

(Алексей) #14

А я один из немногих “хипстеров” здесь, которые пишут на Ruby, и считаю, что это идеальный язык для автоматизации.

З.Ы. сравнить могу только с Java и C# конечно, но вообще на вкус и цвет, как говорится.


(Maxim Andryushchenkov) #15

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


(Алексей) #16

В Ruby больше свободы, и проще наговнокодить, согласен, НО, главное просто определиться с условиями заранее, плюс использование rubocop-а заставляет придерживаться style guide-а.
Ну и само собой, постоянное и тщательное ревью.