fbpx
Какой язык выбрать для тестирования?

языки программирования

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

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

1. Наличие надежной и хорошо поддерживаемой версии инструмента для тестирования.

Этот пункт недаром стоит на первом месте. Инструменты и фреймворки действительно появляются как грибы после дождя каждый день. Но при этом некоторые из них регулярно выпускают обновления, поддерживаются большим сообществом и постоянно развиваются. А другие просто опубликованы автором как результат эксперимента или локальной разработки. В качестве примера приведу PHP клиента для WebDriver – существует несколько реализаций, ни одна из которых “не признана официально”. Все они гораздо сложнее своих аналогов в других языках программирования и развиваются независимо. Поэтому PHP не стоит использовать для тестирования с WebDriver напрямую (есть библиотеки, которые содержат свои прослойки над WebDriver API).

2. Знание языка членами команды.

В этом пункте речь идет не только о тестировщиках, но и обязательно о разработчиках. У них должна быть возможность поправить тесты в случае изменения деталей реализации приложения (расположение элементов, тип элементов, переходы между страницами и т.д.). Иначе успешной автоматизации вам не видать – скоро все время тестировщиков будет уходить на поддержку тестов в рабочем состоянии. Причем, это должно быть достаточно легкая операция с точки зрения знаний языка. И вовсе необязательно это должен быть тот язык, на котором разрабатывается само приложение. Если все члены команды разбираются в синтаксисе Python, а приложение пишется на Java, то можно выбрать любой из этих языков.

3. Наличие хорошего IDE.

Этот пункт особенно важен для тех команд, где работать с автотестами будут даже неопытные с точки зрения программирования тестировщики. Хорошее IDE помогает многие вещи генерировать вместо того, чтобы набирать руками. Также гораздо ниже вероятность допустить ошибку, потому что IDE подсвечивает потенциальные проблемы и контролирует код по мере его появления. В этом пункте также стоит подумать над вопросом динамических и статических языков. У динамических обычно код тестов гораздо более читабельный и простой. У статических более громоздкий, но зато меньше подвержен “неожиданным” ошибкам начинающих тестировщиков. Хорошим примером являются Groovy и Java. Оба языка позволяют писать код с привычным Java синтаксисом, но многие вещи можно сделать значительно проще на уровне языка Groovy (работа с коллекциями, файлами, базой данных и т.д.).

4. Наличие готовых решений для вашего контекста тестирования.

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

5. Опыт использования в компании.

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

6. Простота изучения языка.

Этот пункт я поставил последним, потому что для автоматизации тестирования достаточно очень узкого подмножества возможностей языка. Изучаются они обычно недолго, особенно под присмотром разработчиков. Процесс обязательного ревью кода тестов также помогает в короткие сроки распространить знания об основах языка. Поэтому на первое место выходят возможности писать читабельные и хорошо структурированные тесты. В этом снова может сильно помочь готовое решение с установленными правилами. Например, в Thucydides есть четкое разделение между частями тестов, благодаря которому тяжелее сделать плохо структурированные тесты (при большом желании конечно все возможно).

А на что обращаете внимание вы при выборе языка? Были ли ситуации, в которых выбор был сделан неверно и привел к нежелательным результатам?

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (
Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280

Warning: A non-numeric value encountered in /sata1/home/users/xpinjecti/www/www.xpinjection.com/wp-includes/pomo/plural-forms.php on line 280
9)

Не стоит. И для рубей и для питона море всего уже есть.

Возможно стоит уточнить, что под Java имеется ввиду не язык, а платформа. Тогда многие фишки, такие как testNG, Thucydides становятся доступными для Ruby и Python. Хотя стоит ли такая игра свеч – тот ещё вопрос. А так мой опыт одобряет данное перечесление по важности 🙂

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

У тестировщика который занимается автоматизацией и должен быть солидный технический багаж знаний. Иначе получим то что видим в 90% проектов – кривая архитектура, кривые тесты, кривое все и учеба на шишках. Учитывая, что проблемы с автоматизацией выплывают хорошо если через год – усаживать за это дело wannbe-автоматизаторов себе дороже. Это примерно как брать проект и садить за него команду студентов. Они еще и без особых проблем свалить могут как раз к этому времени – такой уж рынок труда автоматизаторов сейчас.

Ну и насчет архитектуры: если с ней швах, то какой бы язык не выбирали все равно не поможет. Просто вместе с тестировщиками в этом фарше еще и разработчики потонут.

Ты снова берешь в рассмотрение тестировщиков с серьезным техническим багажом знаний, которым интересно и хватает времени опускаться на уровень реализации – Software Engineer in Testing. Таких очень и очень немного (и речь не об аутсорсинге, а вообще о рынке тестирования Украины, России и Беларуси). Для среднестатистического тестировщика это задачи далеко не “на коленку” и не на пару часов, а на недели работы. 🙂

Ой, ну вот чего-чего, а SoapUI пишется на коленке без проблем. К тому же он далеко не для всех сервисов нужен – REST на том же requests заворачивается менее чем за сутки. Ну а если у меня thrift на thrift’е и thrift’ом погоняет, то все равно придется самим писать (тоже быстро делается).

Плюс я не считаю что стоит автоматизацию тестирования ограничивать только API/GUI/Unit тестами. Можно делать сильно больше в том числе для упрощения ручного тестирования. Например пишем маленький питоний скриптик крутящийся на андроиде и я уже знаю когда у меня софт сбоит с геолокацией, а когда это реально проблема железа. Работы меньше чем на час, а профита море.

Холиварить не буду, но из твоей последней фразы про Vim мне многое стало понятно. 😉

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

По поводу нормальной тестовой архитектуры – она есть у 10% проектов (видел я уже перевидел этих проектов). 🙂 Но остальным же тоже жить надо и задача выбора языка перед ними тоже стоит. А в том же самом Thucydides все равно технические детали есть, только они хранятся в Page Object-ах и шагах.

По первому пункту добавлю что зачастую язык программирования и есть инструмент автоматизации. Но тут мы переходим к п.4, где по большей части вопросов примерно одно и то же. Парсить xml в Ruby приятнее, но можно практически везде. Работа со многими базами данных примерно везде одинаковая. HTTP-запросы лично мне в том же Python’е составлять проще, но requests lib уже начал и в другие языки расползаться.

п.2 обязан (!никак иначе!) лечиться хорошими тестами и фреймворком (не тот что xUnit, а тот из которого мы реально тесты собираем). Никаких “расположение элементов, тип элементов, переходы между страницами и т.д.” в тестах быть не должно и при нормальной тестовой архитектуре такие движения вообще не должны требовать никаких особых знаний. Фактически нормально допиленный py-saunter или Thucydides (или сотни блестящих Ruby-поделок) эту проблему решают.

Ну и пункты 3 и 6 они таки холиварные. Лично для меня Vim единственно возможная на данный момент IDE.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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

принять
Pkv Games BandarQQ Online Terbaik Dengan Deposit Super Modern permainan paling populer di situs poker online terbaik di indonesia di situs bukaqq Poker Online Aman dan Terpercaya slot online