Сообщений в теме: 36

[Spock]

что лучше использовать для тестирования REST сервисов?

 

может "Java + JUnit + REST-Assured"?

http://rest-assured.io/

 

а может "Postman + Newman"?

https://www.getpostman.com/apps

 

где какие плюсы/минусы?

 

а может ещё какие тулзы?

[Lzk]

SoapUi?
Jmeter?

[baxatob]

Python + Requests

[Сергей]

Нужен опрос.

[Little_CJIOH]

Голову в опрос добавить не забудьте :)

[Freiman]

Давайте сделаем опрос, надо ли нам больше опросов!

[Spock]

я за опрос!

 

больше интересуют конечно у кого "взрослые" решения, интегрированные с билд/CI серверами

 

 

хотелось бы узнать является ли связка Postman+Newman эффективным решением (например наравне с Java + REST-Assured, и другими программными решениями)

[Little_CJIOH]

я за опрос!
 
больше интересуют конечно у кого "взрослые" решения, интегрированные с билд/CI серверами
 
 
хотелось бы узнать является ли связка Postman+Newman эффективным решением (например наравне с Java + REST-Assured, и другими программными решениями)

Не является. Postman и Newton - это инструмент для ручного тестирования и автозапускалка сохраненных в нем запросов. То есть, если у вас набита коллекция тестовых запросов в Postьan, то вы ее можете прогонять автоматически. Но использовать эту связку для построения автотестов с 0 точно не стоит.

[appmen]

Python + Requests

И это нормально подключается к Дженкинсу.

[Spock]

 

 

Не является. Postman и Newton - это инструмент для ручного тестирования и автозапускалка сохраненных в нем запросов. То есть, если у вас набита коллекция тестовых запросов в Postьan, то вы ее можете прогонять автоматически. Но использовать эту связку для построения автотестов с 0 точно не стоит. 

текущее состояние в нашей компании (и у знакомого похожая ситуация, думаю и у многих других):

 

Postman с хранилищем коллекций в облаке: используется для 

1. ручного тестирования

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

 

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

 

хотя смущает что коллекции надо будет вручную экспортировать/импортировать/коммитить в версионную систему

[Little_CJIOH]

Не является. Postman и Newton - это инструмент для ручного тестирования и автозапускалка сохраненных в нем запросов. То есть, если у вас набита коллекция тестовых запросов в Postьan, то вы ее можете прогонять автоматически. Но использовать эту связку для построения автотестов с 0 точно не стоит. 

текущее состояние в нашей компании (и у знакомого похожая ситуация, думаю и у многих других):
 
Postman с хранилищем коллекций в облаке: используется для 
1. ручного тестирования
2. иногда для удобного выполнения простых задач без использования веб-интерфейса, когда надо например создать пользователя, сделать покупку и т.п.
 
поэтому как-бы выглядит заманчиво прикрутить третьим пунктом автоматизацию используя Newman. Получилось бы типа "один энвайронмент для всех"
 
хотя смущает что коллекции надо будет вручную экспортировать/импортировать/коммитить в версионную систему

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

[Spock]

хм, получается в Postman нет функционального тестирования, когда несколько сервисов используются последовательно?

 

допустим есть сервисы:

1. создать клиента

2. добавить клиента в группу

3. сделать покупку

4. получить список покупок

 

допустим надо написать тест "получить список покупок":

- подготовка теста: "создать клиента", "добавить клиента в группу", "сделать покупку"

- тест: "получить список покупок"

- убрать за собой: "удалить клиента"

 

Но ведь в Postman нет структуры выше простых запросов, чтобы сделать последовательности, типа "собрать дом из кубиков", а есть только кубики

 

единственное что есть - это воркфловс, где можно указать следующий тест - а это аналог GOTO команды o_O, которая только запутает всё

https://www.getpostm.../docs/workflows

 

получается что Postman подходит только для простых систем, без состояний и последовательностей, где существуют только независимые сервисы, типа "сделал один запрос и проверил результаты"?

 

 

прокомментируйте плиз

[Little_CJIOH]

хм, получается в Postman нет функционального тестирования, когда несколько сервисов используются последовательно?
 
допустим есть сервисы:
1. создать клиента
2. добавить клиента в группу
3. сделать покупку
4. получить список покупок
 
допустим надо написать тест "получить список покупок":
- подготовка теста: "создать клиента", "добавить клиента в группу", "сделать покупку"
- тест: "получить список покупок"
- убрать за собой: "удалить клиента"
 
Но ведь в Postman нет структуры выше простых запросов, чтобы сделать последовательности, типа "собрать дом из кубиков", а есть только кубики
 
единственное что есть - это воркфловс, где можно указать следующий тест - а это аналог GOTO команды o_O, которая только запутает всё
https://www.getpostm.../docs/workflows
 
получается что Postman подходит только для простых систем, без состояний и последовательностей, где существуют только независимые сервисы, типа "сделал один запрос и проверил результаты"?
 
 
прокомментируйте плиз

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

[Spock]

спасибо, ситуация прояснилась:

 

использовать нужно чисто программное средство плюс фреймворки для удобства

 

например "Java + Junit + REST-Assured", "Node.js + Mocha + Chai" и т.п.

 

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

 

 

П.С. любое средство с графическим интерфейсом - это зло. Только IDE обладают достаточными способностями для разработки

[baxatob]

 

П.С. любое средство с графическим интерфейсом - это зло. Только IDE обладают достаточными способностями для разработки

 

Любая IDE обладает графическим интерфейсом. 

Зло - это кривые руки.

 

 

 

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

 

Очень спорное утверждение, имхо.

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

Приложение может быть написано на Delphi или C, и что тогда? :)

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

[Spock]

 

Любая IDE обладает графическим интерфейсом. 

Зло - это кривые руки.

я имею ввиду "средство тестирования с юзер-интерфейсом". понятно что у ИДЕ есть юзер-интерфейс

 

 

Очень спорное утверждение, имхо.

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

Приложение может быть написано на Delphi или C, и что тогда? :)

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

вот например авто-тестам понадобилась сложная система аутентификации которая используется в приложении. Если язык тот же - то достаточно скопировать код

 

 

 

 ведь их удел - разработка. 

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

[Freiman]

вот например авто-тестам понадобилась сложная система аутентификации которая используется в приложении. Если язык тот же - то достаточно скопировать код

 
Более чем странное утверждение. Копипаст исходников в тесты? ну я даже не знаю.. 

А вот если тестер будет использовать язык который "вот ему лично нравится" - тогда девы уже не помогут ему

Есть подозрение, что если разработчик может решить проблему только на одном языке - то это не очень хороший разработчик. Синтакисис команды он вам, конечно, не скажет сразу, но вот алгоритм решения проблемы - легко.
А для остального есть stackoverflow :)

Но мы отклонились от темы.

[Spock]

 

 

Есть подозрение, что если разработчик может решить проблему только на одном языке - то это не очень хороший разработчик. Синтакисис команды он вам, конечно, не скажет сразу, но вот алгоритм решения проблемы - легко.
А для остального есть stackoverflow :)

не так давно тестировал гейтвей, для подключения к которому использовался сложный протокол с системой шифрования

 

там кода было на десятки страниц, реально невозможно такое переписать на другой язык, и потом ещё поддерживать

[baxatob]

 

 

Я не спорю, что разработчиков можно заставить и кофе приносить. Но с тем, что это нормально, не соглашусь. Из всего перечисленного нормально только написание девами юнит-тестов. Все остальное либо от нехватки бюджета, либо от неправильного управления проектом.

Тестер должен решать свои задачи без посторонней помощи. Коммуникации между тестерами и разработчиками безусловно нужны, но не на уровне же помощи в написании кода. 

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

[Little_CJIOH]

Есть подозрение, что если разработчик может решить проблему только на одном языке - то это не очень хороший разработчик. Синтакисис команды он вам, конечно, не скажет сразу, но вот алгоритм решения проблемы - легко.
А для остального есть stackoverflow :)

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

Пишется для кода внешний API и хоть из баша курлами его дергайте