Опрос: Какие языки программирования и подходы Вы используете для автоматизации ваших тестов? 2017

StackOverflow говорит что #python рулит The Incredible Growth of Python | Stack Overflow. Так ли это касательно автоматизации? Имхо я вижу в последнее время, что очень много людей стало писать автоматизацию на #python. Давайте это проверим опросом

Мы проводили серию опросов по автоматизации тестирования. Хотелось бы обновить статистику по состоянию на 2017 год. Варианты для следующих опросов пишите в эту тему

Первый вопрос, на каких языках программирования Вы реализуете текущие проекты по автоматизации тестирования ПО? (можно выбирать несколько)

  • ruby
  • c#
  • java
  • kotlin
  • c \ c++
  • python
  • php
  • javascript
  • perl
  • objective-c
  • swift
  • groovy
  • visual basic
  • sql
  • xml \ xslt
  • другие, напишу с комментариях

0 участников

Второй вопрос, какие подходы автоматизации тестирования Вы реализуете на текущих проектах? (можно выбирать несколько)

  • record & playback
  • functional decomposition
  • data driven
  • keyword driven
  • hybrid (data + keyword)
  • model based
  • image recognition
  • dsl
  • attd и bdd
  • свой самописный подход
  • другой подход, напишу с комментариях

0 участников

Ставим лайки и делимся наблюдениями в комментариях!

2 лайка

Результаты 2016 года

Оверфлов не совсем то говорит. Он ещё добавляет, что применяемые языки колеблются. Например джаваскрипт, руби, джава и пхп очень популярны в странах 3-го мира, тогда как питон вышел на первое место в странах первого мира.

2 лайка

Да да я это видел, контекст есть и причем очень интересный. Богатые страны делают одно, а страны 3го мира другой. Вопрос почему?

Это просто ) Зарплата в странах третьего мира маленькая, если они будут делать свой продукт, то программистам придется платить зарплату третьего мира. Зарплата в странах первого мира высокая. Платить зарплату первого мира программисту, который просто сделает вебморду продукту для рекламы не выгодно. Проще заауттсорсить в страну третьего мира за половину зарплаты первого мира.
В итоге - превый мир сконцентрирован на производстве самих продуктов непосредственно.
Третий мир клепает в аутсорсе то, в чем первому миру качество не так важно и на что времени не хватает, но сделать надо.
А программисты третьего мира в свою очередь чем работать за зарплату третьего мира предпочтут что-то заделать за четверть американской зарплаты для американского заказчика.

3 лайка

Все верно все так, только как помогает #python им сконцентрироваться только на развитии своего продукта ?! Мне кажется это больше относиться к проникновению информатизации во все сферы жизни и скоро программирование будет обычный навык как владение компьютером. А так как в развитых странах с жизнью все хорошо, они развиваются и в том числе в сторону программирования и выбирают #python язык как easy to learn

1 лайк

Machine Learning, Data Science - два мейнстрима на сегодня, где работают в основном ученые, которым не хочется долго постигать сложности управления памятью С++ или черезчур витееватую структуру программ Java с её кривой многопоточностью. Питон - 5-часовое видео на ютубе и ты программист. И основные С++ библиотеки по обеим предметам уже давно получили свои питоновские обертки.

4 лайка

А точнее го***кодер, за которым придется убираться в репозитории, писать коменты на ревью и тд. Не согласен что какого то видео хватит для осознанного программирования. Да, легче чем некоторые другие языки, но сейчас кто-то прочитает это ваше сообщение и поймет что он уже аж целую неделю учит питон и выставит сейчас себе зарплату $3k на HH))

1 лайк

Вот кстати, раз уж тема такая поднялась:
мое видение ситуации таково: скриптовые языки позволяют писать АТ в 1,5-2 раза быстрее чем на яве, например (естесственно, предполагается автоматизатор с хорошим знанием языка, а не после видео на ютубе). Рост библиотек, технолигий вокруг тех же питона и яваскрипта стремителен.
Но у нас в России (как в мире просто не знаю) безумно доминирует ява (смотри опрос), которая развивается гораздо медленнее, разработка требует больше времени и памяти. при этом никто с нее уходить не хочет.
Когда я пытаюсь у себя в фирме продвигать идеи, мол, “а давайте попробуем питон!”; “смотрите, дж-эс поднимается!”. это все не встречает энтузиазма руководства. “все привыкли, зачем нам что-то новое, неизведанное, да и где мы людей найдем, а на ява-проект всегда найдется спрос”.
вот, объясните, пожалуйста, может, я не прав со своей жаждой экспериментов, использования чего-то нового. я всегда думаю о time-to-market, а большинству вокруг на него плевать, как будто.
или я прав, и надо продолжать пробивать? может, даже втихаря затаскивать на проекты всякие такие штуки (хотя это и не просто)?

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

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

Да, втихаря, если результат будет, менеджменту будет чем похвастаться перед вышестоящим менеджментом, типа это их идея

И много у нас таких? :slight_smile: Тут, опять-таки, следует уточнить, а что значит “хорошее знание языка”?

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

Тогда вы наверное понимаете, что это понятие зависит не от одного человека, а от всей команды (зачастую, даже не одной). Потому оценивать влияние какого-то абстрактного автоматизатора на разрабатываемый продукт не имеет никакого смысла.

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

Когда вы закинули идею - “а давайте учить Python” в Java-ориентированную среду, подумали ли вы, сколько убытков понесет компания на переучивании людей, которые неплохо кодят на Java, прежде чем они начнут приносить реальный профит на Python? Составили ли вы стратегию миграции? Предоставили ли цифры выхода на прежний уровень производительности? Оценили ли риски, целесообразность? А главное - когда компания начнет получать с этого хоть какой-то профит? Стоит ли оно вообще затраченных усилий?

В общем, пока ваша идея не имеет под собой никакой материальной выгоды, которую можно ощутить в обозримом будущем, руководство никогда под этим не подпишется.

Ну а в целом, к подобным идеям будут прислушиваться только тогда, когда ваше слово в компании будет иметь существенный вес. Хотя, бывают и исключения.

4 лайка

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

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

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

Это не серьезное заявление, просто не солидно так говорить не имея цифр. Чисто эмпирически, я могу сказать что пускай на JS кода нужно писать и несколько меньше - даже банальное объявление метода в Java сильно размашистей чем в JS, но, несмотря на это, я бы не сказал что работая на JS есть какой-то выигрыш в скорости написания тестов. Есть очень большая проблема в автоматизации на JS - это асинхронность и соответственно дебаг, он очень сильно усложнён по сравнению с такими языками как Java и C#, особенно если говорить о промисах, а о них только и будет идти речь, т.к. что WebDriverJS, что Protractor через них работают. В итоге, что бы продебажить код нужно не просто точки останова расставлять, а нужно писать дополнительный код, разворачивать промисы, consol.log-и лепить, а потом стирать всё это и приводить к нормальному виду. Это порой много времени забирает. Поэтому я едва ли могу представить себе прямо таки существенный перевес в скорости написания автотестов на JS.

Не правы, конечно. Речь ведь о деньгах, а не о фане и экспериментах. Бизнес очень прагматичен, если в применении какой-то новой технологии нет какого-то профита, который можно измерить в деньгах, то какой смысл применять это?

Это нивелируется низким их качеством и нередко отсутствующей документацией, особенно это касается node.js.

3 лайка

Я заметил по бирже фриланса, где-то как около года уже, там преобладают задания на Питоне, мне со своей Явой даже как-то обидно, и всё руки чешутся осваивать и его.
Или просто студентота его так осваивает…
Не забывайте ещё что Питон используется админами и девопсами часто.

Пишу и на Java и на Python и на JavaScript(TypeScript), мой выбор сейчас - TypeScript для автоматизации.

Но засматриваюсь на возможности функциональных языков (elm, elixir) в автотестировании

В чем преимущества функциональных языков в автотестировании? Это не троллинга ради, правда интересно)

1 лайк

Незнаю, самому интересно что из этого выйдет.

Мне кажется паралелизация тестов на функциональных языках может выйти на новый уровень. Но пока целостной картины в голове нет.