Есть у меня баг при создании ивента: если не загрузить картинку для ивента, то ивент не создастся.

Первый раз система мне отказала, я записал данные:

 

Потом система приняла и создала ивент, я записал данные:

После этого, я опять ввел первые даные, которые система сначало не приняля и отказал в создании ивента(из первого спойлера), и в этот раз она их приняла.

Как выследить этот баг?

У меня скоро техническое собеседование по Ресту и Хттп. Какие стандартные и нестандартные вопросы могут задать по эти двух темах?

 

 

GET /api/films/?search=A%20New%20Hope

Спасибо большое. Что это за магия?) Вместо пробелов ставить "%20"?

 

Нормальной доки на русском что-то не гуглится, начните с wiki https://en.wikipedia...ercent-encoding

 

Буду знать, спасибо большое :)

GET /api/films/?search=A%20New%20Hope

Спасибо большое. Что это за магия?) Вместо пробелов ставить "%20"?

Значит играю сo SWAPI(API о вселенной Звездных Войн) и хочу получить фильм по GET-запросу. Вроде бы все просто, в документации написано, что найти фильм можно по атрибуту title. Окей, без проблем. Делаю значит следующий запрос: http://swapi.dev/api/films/?search=A New Hope

Но сервер возвращает мне следующее 

{

Что я делаю не так, подскажите, пожалуйста?

 

Ммммм, а сами-то что? Как процесс гугления, уже не в моде? Что вы уже нашли/узнали/сделали по этим вопросам?

https://www.youtube....естирование api

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

 

Посмотрите видеоролики о тестировании API и тогда более-менее будет понятно.

 

 

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно?

 

 

Давайте еще раз убедимся что понимаем друг друга верно:

1. Ваше внутреннее АПИ - это ендпоинты, предназначенные для работы внутри вашего приложения --- Тестировать важно
   1. Проверяется работоспособность АПИ внутри вашего приложения
2. Ваше внешнее АПИ - это ендпоинты, предназначенные для работы с вашим приложением извне(например, если почта или платежная система, это вы) --- Тестировать очень важно
   1. Проверяется работоспособность АПИ как внутри вашего приложения, так и с приложениями извне. Чтобы системы извне могли успешно работать с вашими "ручками", при этом не имея возможность вам навредить или получить закрытую информацию
3. Публичное АПИ(не ваше, то есть АПИ почты. кинотеатра, платежной системы, и тд, которые вы как-то используете) - это ендпоинты third-part системы, предназначенные для использования в каких-то целях --- Как правило не тестируется
   1. Потому что это third-part система, а их не тестируют. Вы ж Джиру или Гит не тестируете :)

Сложно ли понять на практике, где наш АПИ, а где сторонний?

 

 

Как правило на проектах используется какой-то инструмент для документирования API(такие как Swagger, например), который позволяет увидеть все ваши ендпоинты, их схемы и используемые модели. А сторонний АПИ, ну, он вам не принадлежит, и не входит в список ваших апишек, так что думаю да, разработчики ваши с этим трудностей испытать не должны :)

 

Вы так четко все объясняете. Курсы ведете какие-то?)

 

 

Нет, просто работаю в этой теме и интересуюсь :)

 

 

Когда я вел с вами эту беседу - еще очень мало знал об API.

Сейчас я пересмотрел множество видеоуроков и уже примерно понял что и к чему. Спасибо вам большое за то, что уделили мне своё время :)

а что если пользователь захотел завести несколько аккаунтов на один телефон? 

Хм.. Идея вполне имеет место быть. Но все равно меня что-то тревожит, что в данном сервисе так не должно быть.

Давайте продолжим рассуждать.

А как система должна работать, по вашему мнению?

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

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

И я нашел ошибку в том, что один номер телефона можно подтвердить с нескольких аккаунтов, я же проверил это на трёх аккаунтах.

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

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

То есть, нам не обязательно проводить негативное тестирование внешного АПИ, достаточно удостовериться, что все работает правильно? Сложно ли понять на практике, где наш АПИ, а где сторонний?


Вы так четко все объясняете. Курсы ведете какие-то?)

Привет!

На конференциях часто слышу термин "крутить ручки". Т.е. дергать те или иные АПИшки. Этот оборот очень хорошо раскрывает то, как работает АПИ.

Детальнее: Бэкенды пишут бэк. Фронты пишут фронт. Вторым нужно что-то, через что можно общаться с бэком, т.е. слать/получать/изменять/удалять данные.

Для этого нужен какой-то интерфейс. API(endpoint) - и есть такой интерфейс(Application Programming Interface).

 

Так как все нагляднее на примерах, вот два варианта АПИ с внешними интерфейсами("ручками" торчащими наружу:)

1. Всеми нами любимый пример - автомобиль.

Современные авто - это уже очень серьезные технологические вещи, внутри крепко напичканные самими разными агрегатами и механизмами. Тонкости работы большинства из них нам не неведома, да и не должна быть. Так вот все, что происходит условно "под капотом" - это бэкенд. Фронт - это красивая приборная панель, которую видит водитель. АПИ в этом случае - это точки под капотом, куда подключаются провода, идущие на приборку.

 

Но это закрытое АПИ. Что тогда тут будет внешний интерфейсом?

В любом современном авто есть специальный разъем(ODB), куда можно подключить внешние системы диагностики, или другие приборы, получающие информацию "из под капота" в обход приборной панели. И получить можно куда больше информации.

 

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

 

2. Интеграция почтовых сервисов и онлайн магазинов(по аналогии с кинотеатром и платежкой).

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

 

У почты есть сайт(бэк + фронт), и бэк дает пользоваться определенными интерфейсами кому угодно. Такими интерфейсами может быть как раз та самая информация о почтовых отделениях, их адресах, названиях, актуальном списке. Онлайн магазины просто используют АПИ почты в рамках сотрудничества. Более продвинутые почтовые сервисы делают целые виджеты, которые может добавить себе на сайт кто угодно, чтобы упростить работу с оформлением доставки. Почему это выгодно? Онлайн - магазин решает проблему доставки товара, Почта - имеет площадку для рекламы и распространяет свои услуги. По этому очень важно поддерживать внешние АПИ в актуальном состоянии, если от этого зависит бизнес.

 

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

 

Зачем нам тестировать АПИ?

Чтобы удостовериться, правильно ли работают "ручки", используемые внешними модулями. Так как АПИ - это по сути JSON схемы, они должны быть правильно описаны. Если схема говорит, что поле принимает int или bool, значит нужно проверить, что это так и есть. Это очень кратко. Тема тестирования АПИ это совсем отдельный разговор :)

 

 

Что касается интеграционного тестирования.

Википедия гласит - "это одна из фаз тестирования программного обеспечения, при которой отдельные программные модули объединяются и тестируются в группе."
Есть по сути тестирование АПИ - это НЕ интеграционное тестирование, но тестирование конкретного модуля, которому принадлежит это АПИ. Интеграцию мы тестируем, когда есть несколько модулей, общающихся посредством АПИ, а мы при этом получаем информацию через их общее АПИ или другие интерфейсы, отображающие их комплексную работу.

Окей, тогда тестирование АПИ ( как я понял ) - тестирование конкретного модуля и, в каком-то роде, это тестирование бэкэнда.

То есть, если брать к примеру автомобиль, то тут будет два тестирования АПИ - АПИ двигателя и АПИ всего остального.

В случае онлайн-магазинов это будет тестирование АПИ подсказок адресов, тестирование АПИ платежной системы и тестирование АПИ конкретно нашего сайта.

Верно?

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

Как пользователь скажу, что это крайне неудобно.

Что делать в таком случае, как отследить такого рода баг, почему он случается и как его воспроизвести?

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

В моем понимании, API - это набор функций. Апи может быть как одно, так и несколько, в каждом Апи есть n-ное количество функций. 

То есть, получается, что тестирование API - это, в каком-то роде, интеграционное функциональное тестирование(или просто функциональное тестирование(если рассматривать функционал в одном Апи)? 

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

Am i right?

Ну вы не расстраивайтесь, я видел только процентов 5 таких;) Обычно останавливаются на отрезке от 0 до 100, который любят давать на курсах и на всеми любимом Савине

(Не сочтите глупым, пожалуйста)
Таких - это каких? Которые не много тест-кейсов придумывают?
И про отрезок от 0 до 100 не понял. Отрезок- путь к завершению обучения?

С Савина все и началось, друг мой :)
По поводу книг: я не могу читать литературные книги, мне попросту не интересно. Я когда-то взял у крестного 2 тома "Граф Монте-Кристо". Первый не дочитал, прочел всего лишь 500 страниц, ибо перестало быть интересно. Начинал читать Дойля "Собака Баскервилей" - зевал почти всегда, забросил на 30 странице. За то "Богатый папа, бедный папа" и Савина прочел, как на одной дыхании, было крайне интересно читать :)

Как рассширить кругозор и заставить мозг генерировать больше тест-кейсов(к определенному функционалу)? Ибо у меня не много получается... Теории не мало знаю, а практики так почти и нету.

P.S. Василий, когда там уже новый цикл Хомячков? :)

Помню, у Портнова на курсе был такой вопрос, создать 3 или более тестовых случаев.
Я запомнил только два: ввод корректного логина и пароля(что в принципе естевественно) и то, что пароль должен быть закрыт звездочками (или чем-то еще).
А какие вы придумаете позитивные тестовые случаи к полям логин и пароль?

Ну так, что такое сценарий использования простыми словами?

А там вообще есть стажировка? Точно будет набор?

Не знаю, хочу спросить)

4 марта нас и паралельную группу ведут в крупную компанию Viseven (одна из крутейших в городе).

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

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

(Не смейтесь, если что, мне 17 всего)

Кста, я не знаю, будут ли там конкретно QA-щики на той встрече.

Вопрос для тех, кто давно в тестировании. Какие методологии вы используете для написания тест-кейсов, какими глазами смотрите на ПО, что бы придумать тест-кейс?

(Не смейтесь, если что, пожалуйста.)

Прочитал я значит статтейку такую: https://searchsoftwa...nition/use-case , и не знаю, правильно ли я понял.

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

Если нет, то расскажите, пожалуйста, как правильно, и желательно простыми словами. Спасибо.

Молодое поколение подтягивается))

Так я в деле?)

Что дальше-то?)

Приветствую. Мое имя Максим, мне 17 лет.

•  Почему вы выбрали именно тестирование?

Я учусь на специальность "Компьютерные науки" или же как говорят в народе, на "программиста". Но с программированием у меня дело не сложилось. Я немного шарю в этом, но сложные задачи решать не могу. На пол года было забросил своё саморазвитие, но потом вспомнил, как к нам в колледж приходил Senior QA и проводил лекцию о тестировании. Оставил нам ссылку на книг Савина "Тестирование дот ком" и укатил в столицу делать деньги.  Я, конечно же, как и остальные 30 человек (половин из моей, половина из параллельной группы) почитали пару страниц и забросили это дело. Перед зимней сессией 2019 мой друг программист сказал, что к ним в компанию приходит много тестировщиков на стажировку и сказал мне тоже попробовать. И я взялся за книгу Савина. Буду максимально откровенен: я захотел дальше развиваться в этом плане не потому что чувствую, что это мое призвание, а потому что мне было интересно читать книгу и я очень сильно заинтересовался. Да и к тому же, надо как-то в будущем на хлеб зарабатывать)

•  Какие книги/курсы по тестированию вы изучили?

Р.Савин "Тестирование дот ком".

Курс по от Технострим Mail.ru.

Завтра-послезавтра загляну на курс Портнова(многие рассказывают о нем(сегодня поздно, пишу это в 22:00)).

•  Какие области вы изучили самостоятельно?

HTML,CSS, изучаю веб тестирование.