t.me/atinfo_chat Telegram группа по автоматизации тестирования

Нужна помощь с выполнением тест задания. Очень и срочно! API.

обучение
,
Теги: #<Tag:0x00007fd76d4d7550> #<Tag:0x00007fd76d4d7460>
#1

Привет!
Ребята, очень срочно нужна помощь. Компания, в которую хочу попасть дала задание по API. По иронии судьбы, на практике с ним так и не сталкивалась. Вот сижу и не знаю с какой стороны подойти и с чего начать. Есть ли у кого-то возможность и желание помочь с обучением и выполнением? Буду очень благодарна и в долгу не останусь. Желательно Python. Вот задание: The Problem: The new order API endpoint is described here.
https://docs.gemini.com/rest-api/#new-order
How will you test it?
The Solution:

  • Please code up functional test cases in the language of your choice or pseudocode
  • Include both positive and negative cases
  • Be able to quantify the number of distinct tests run
  • Do not invoke any other API endpoints (e.g., order status)
  • Clearly articulate your assumptions
#2

На Java я бы использовал http://rest-assured.io/. Практически стандарт уже, примеров в инете масса.

1 Симпатия
#3

Там в задании кусок кода на Python, в чем проблема скопипастить его и наплодить тестов? + в задании указано что можно писать на псевдокоде.

#4

Когда-то была похожая тема с решенным заданием, можете сделать по аналогии

#5

вот кстати я писал небольшой пример. если что не ясно то отвечу

1 Симпатия
#6

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

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

Был у нас как-то похожий случай в одной компании, вылетел как пробка человек не пройдя исп. срок.

Вот из-за таких, как ТС - и приходится иногда работать с неквалифицированными коллегами.

11 Симпатий
#7

согласен полностью, каждый инженер должен научиться перед тем как задавать вопрос другим ответить себе на вопрос “What have you tried?”. Что попробовал топикстартер? Ничего? Серьезно? Будь я на месте работодателя и увидел такую постановку вопроса, вообще бы никогда не взял человека. И тут проблема или в мотивации, или в полной неспособности потратить время на самостоятельное изучение вопроса.

Ниже по ссылке 5 минутная статья, которая описывает проблему таких вопросов. После нее ваша жизнь может стать сильно лучше :wink:

6 Симпатий
#8

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

2 Симпатий
#9
  1. абсолютно согласна
  2. сейчас штудирую вот эту статью https://www.smashingmagazine.com/2018/01/understanding-using-rest-api/, потом перейду к ресурсам, которые дали ребята
  3. я просила помочь и обучить, если не знаешь как закипятить воду, то суп как-то сложно сварить.
  4. я первый и, наверное, единственный рекрутер, который сдал ISTQB в Украине и на все 100% воспользовался этим шансом.
  5. До моего прихода, компания 3 года не могла запустить автоматизацию. Через два месяца я запустила первые рабочие тесты на Squish&Jenkins. То и другое, я видела первый раз. Сейчас у меня 4 команды, 3 из которых - международные.
    Что такое учиться и пользоваться шансом - я знаю.
    Спасибо.
1 Симпатия
#10

@Lera, разрешите вас только поздравить и пожелать успеха в новой роли и надеяться что technical gap допустимо мал и вы переквалифицируетесь. почему не хотите прямо перспективному работодателю все это сказать чтобы оправдать его потенциальный disappointment ?

#11

Сообщество, куда ты катишься, остановись…

2 Симпатий
#12

Как бомбануло то а:) Если Вы не сталкивались с тестированием API то автоматизатор из Вас так себе. Т.к, минимум, не соблюдали пирамиду автотестов.

2 Симпатий
#13

Ну с этим можно поспорить.
Всё зависит от компании и от заказчиков.
У меня были случаи, где заказчику нужны только GUI авто-тесты, про api тесты он не слышал и слышать не хочет.
Что предлагаете в этом случае? Если только увольняться и искать другое место :slight_smile:

2 Симпатий
#14

АПИ можно делать как помошники, загрузка тестовых данных, дёрнуть что то на беке по надобности, заменить часть степов на вызовы АПИ что бы увеличить стабильность тестов. Много где можно использовать.

3 Симпатий
#15

Согласен конечно же.
Только дёргать апи и тестировать его - всё-таки разные вещи.

А с этим поспорил бы. Тут как говорится 50 на 50. Может то, что вы сделаете через апи, не будет работать через графический интерфейс, а вам надо проверить именно что оно там работает.

#16

Возьмём пример.
Заплесить ордер посмотреть что он перепроцессился 100500 раз, Прошёл всевозможные статусы и проверки.
Есть тест заплейсить ордер через UI, и тест который проверяет что оредер попал в нужный статус после плейса ордера. Зачем во втором случае опять делать заказ через UI если мы уже это протестировали но нам нужно сделать это как прекондишен.

2 Симпатий
#17

Не, второй раз конечно не надо.
Я имел в виду, что хотя бы одна проверка GUI должна быть.

А так да, эквивалентные классы получаются.

#18

Не всем кейсам нужна проверка по ГУИ, опять же есть подсистема которая не обновлется, но нужна для пользования бекофисом. Опять же что бы не пользоваться нестабильным UI, можно просто дёргать его сервисы.
Так что я хз что там автоматизировал автор если ниразу не стыкался с сервисами.

#19

Я же с самого начала написал:

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

Ясен красен, если вам не нужны проверки GUI - их и не должно быть, это же очевидно. :slight_smile:

А автор да, лукавит, на мой взгляд. Ну да Бог ему судья.