Тестирование решения от команды проходит без проблем к доступу. И даже стиль фронтовой части веб-приложения выглядит более современным. Не исключаю, что баги, принесенные с бэка заказчика, появились и на нашей стороне, но это уже совсем другая история, так как цель проекта – перенести фронт. Чтобы создать ещё один GET-запрос, данные для авторизации и проверку на код ответа 200 нужно продублировать. Чтобы сэкономить время, внесём эти данные на уровень всей коллекции. Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет.
По итогу написала шаблоны, которые осталось лишь заполнить, как только появится доступ к эталонной программе. И вот «прилетели» ко мне первые задачи – составить стратегию тестирования ПО и план демонстрации программы. В этой статье хочется поднять наболевшую для большинства тестировщиков тему – это доступы к тестируемым программным продуктам. Не всегда доступы к ПО предоставляют тестерам здесь и сейчас.
Следовательно, даже в том случае, если на вашем проекте пока не используется тестирование на уровне API, вам имеет смысл присмотреться к возможностям, которые оно предоставляет. Не теряйте надежды, потому что вы можете протестировать очень много. Внизу пример простенькой формы с образцом разговора, в результате которого вам придется протестировать что-то, не имея под рукой требований.
Смотрим на то, что все поля из требований вернулись, и что в них правильное значение. А то вдруг я сохраняю имя “Оля”, а там всегда сохраняется “Тестовый”… Очень удобно сразу автотесты писать в том тестирование api же постмане, если отдельного фреймворка нет — идем по ТЗ и каждое поле выверяем. Самое простое, что можно сделать — дернуть пример из документации, чтобы посмотреть, как метод вообще работает.
Сначала отправляем базовый запрос и там, и там, как в документации. Но уже по документации мы можем заметить, что набор поле в ответах разный. В SOAP перечислены все поля юзера, включая кличку кошечки, собачки итд… В REST же несколько базовых полей, и всё. Если в ответе сообщение об ошибке, то внимательно его изучаем.
Казалось бы, программные интерфейсы – это территория разработчиков. Ниже мы рассмотрим выгоды использования тестирования API. Включаю запись, смотрю каждый шаг, который показал стейкхолдер, и по этим действиям составляю тест-кейсы с ожидаемым результатом. Таски усложняются именно тем, что доступ к исходному веб-приложению ограничен, а возможность выполнения задач принимают статус «Заблокирован».
Если же это апи другое (например, это библиотека на каком то языке програмирования), то тут вариантов не много – писать тесты на этом языке и планомерно покрывать все варианты. Если же swagger нет, тогда можно написать ручками. Тут ничего сложного нет и зависит только от Ваших возможностей и того, что есть в компании.
Самый основной, все ответвления можно отладить позже. Я не вижу особой проблемы в текущем описании, это не повод ставить баг на документацию. А если принесет головную боль поддержке, тогда и замените. Значит, метод не идемпотентный… Нельзя просто взять пример из ТЗ и отправить не глядя.
Использование Postman
И именно поэтому сотрудники вынуждены ждать начало этапа STLC, относительно к этапам работ проекта именно из-за такой проблемы. Укажем значение Iterations равным 10 и пройдём наши тесты. Мы познакомились с отправкой и параметризацией запросов, а когда же приступим к тестированию? Мы на пороге написания первого теста в Postman. Теперь создадим другое окружение, с другими URL и token, и поменяем их с помощью переключения в выпадающем списке. Протестируем продукт на двух разных окружениях, используя одну коллекцию запросов.
Или вот описание Jira Cloud REST API, выберем в левом навигационном меню какой-нибудь метод, например «Delete avatar». Там есть описание метода, а потом в блоке Responces переключалки между кодами ответов. Настало время приступить к написанию автотестов! Давайте попробуем сделать что-то посложнее, применив метод вложенных условий. Для улучшения структуры и оптимальности кода, а также сокращения времени на анализ ошибок FAIL, я хочу предложить вам использование двух методов – вложенных условий и assert’ов. С другой стороны, механизм авторизации бывает достаточно сложным, его не всегда легко пройти только с помощью запросов.
Здесь команда path(«results.total») позволяет извлечь значение, используя JsonPath либо XPath (в зависимости от того, в каком формате предоставлен ответ). Обратите внимание, что вызываемый метод postRequest определен в моем фреймворке, а не в библиотеке rest-assured. Для работы с языком Python используется популярная библиотека requests. Проанализируйте приходящие ответы (вкладка Response) и их коды.
- Но нам нужно проверить, что запрос отрабатывает при самом банальном позитивном тесте.
- Если требуется создание нового объекта, то используется POST-запрос, который может быть быстрее, если передача данных в теле запроса не занимает много времени.
- Если трудно «выловить» нужный запрос в общей массе (а запросов к API тоже может быть немало) – очистите историю запросов перед совершением интересующего вас действия.
- Оптимальность кода достигается тщательным продумыванием каждой строчки и отсечением всего лишнего; при этом алгоритм должен выполняться за минимальное число шагов.
Если у вас в системе два интерфейса — SOAP и REST, нужно проверить оба. Да и в коде это обеспечивается условно говоря двойной аннотацией “сделай и cleaning soap, и relaxation сгенери”, разработчик не дублирует всю функциональность дважды, а просто “включает” API. А ещё может показаться, что игнорирование ошибок пользователя — это хорошо.
Статус-коды
Окончила бакалавриат в УрФУ в 2016 году по специальности “Фундаментальная информатика и информационные технологии”. В настоящее время продолжает обучение в УрФУ в магистратуре по специальности “Инженерия программного обеспечения”. В сентябре 2017 года прошла стажировку в “Лаборатории качества”. Любимая цитата “Работать надо не eight https://deveducation.com/ часов, а головой”.
После запуска в Postman стоит создать папку с коллекцией запросов. Для этого нужно во вкладке Collections нажать на New Collection. В примерах рассмотрим статус 200 ОК, который информирует об успешности выполнения операции, т.е.
Получаем от сервера в ответ статус 204 No Content, информирующий об успешности запроса, но без содержимого, т. Базовый тест тщательно выверяет каждое поле из “корректного” ответа. Проверяет, как вызов API-метода влияет на отображение в GUI… Поэтому его пропишем текстом, а остальные тесты соберем в табличку. Это постман мне настойчиво подсвечивает красным лишнюю запятую, а если вызов идет из кода и там подсветки нет, то как понять, что пошло не так?
Этот метод будет имитировать работу assert, так как в JavaScript нет этой встроенной функции или ключевого слова. Для понимания способа реализации этого метода на практике я расскажу о том, как assert работает в других языках программирования. Нельзя недооценивать скорый дедлайн, проблемы сервера с API, проблемы с интернетом и внезапное изменение API. Недостаток опыта тестирования и знаний JavaScript приведет к увеличению времени на написание автотестов. Таким образом, закладывая время на разработку тестов, старайтесь все это учесть для точной оценки сроков и качественного тестирования. Наконец, еще раз хочу напомнить, что тестирование API становится особенно востребованным в свете растущей популярности микросервисной архитектуры.
Конечно, для понимания проще «parsed»/«pretty print», но в том случае, когда вам необходимо скопировать часть запроса, лучше переключиться в режим «source». Кроме того, скорость запроса также зависит от факторов, таких как скорость сети, загруженность сервера и оптимизация кода API. Поэтому важно проводить тестирование производительности API и выбирать оптимальные методы запросов в каждой конкретной ситуации.
Да, doregister без заголовков работает, всё ок. Это те заголовки, что генерирует сам постман. По сути постман — это клиент, помогающий нам отправить запрос на сервер. И у него есть какие-то свои фишечки, ограничения, заголовки опять же. В общем, если есть отдельно про ошибки — класс, проверяем по ТЗ. А потом ещё думаем сами, что там могло быть пропущено.
Ведь потом изменится входной запрос и у нас вся интеграция сломается! А это нехорошо… Так что смотрим как система реагирует на перестановки. Так что прячем hidden-заголовки и проверяем без них в этом пункте.
С бизнесовой точки зрения очень удобно, когда все ошибки прописывают прямо в ТЗ. Это можно быть разделение на «Особенности использования» и «Исключительные ситуации», как в Folks (логин для входа тут). Тогда тестируем блок «Исключительные ситуации».
При написании же автотеста без этих методов вы будете вынуждены выполнить его до конца со всеми проверками, которые можно было бы и не делать из-за уже найденных ошибок. Стоит отметить, что и Java, и Python имеют средства работы с http в числе стандартных возможностей, но я неоднократно сталкивался с мнением, что они не слишком удобны. Просмотрите внимательно оставшиеся после применения фильтра запросы и постарайтесь выявить те, которые относятся именно к логике действий. В случае необходимости обратитесь за разъяснениями к разработчикам.