Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование типа запросов)
Что будет, если мы “подменим” тип запроса?
POST → GET (совсем разные типы запросов)
POST → PUT (похожие типы)
Как система отреагирует? Она может или отработать “словно так и надо”, или выдать ошибку. И тут следим за тем, чтобы ошибка была внятной и понятной.
Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование URL)
Казалось бы, что тестировать в URL? Ведь нам просто дают URL, который мы дергаем, а меняем уже заголовки, тело... Но в URL тоже могут быть параметры. Обычно это в методе GET делается, прямо в параметры URL зашивается какая-то информация. Например, идентификатор элемента, который мы хотим получить.
Тестируем точно также, как если бы параметр был в теле:
Правильный параметр (из примера)
Обязательность (что, если параметр не указать?)
Бизнес-логика (тест-дизайн)
Регистрозависимость (если параметр текстовый)
Что мы тут тестируем:
Правильное тело (пример)
Различные параметры (обязательность, работа параметров)
Бизнес-логика
Ошибки: бизнес-логика
Перестановка мест слагаемых
Регистрозависимость
Ошибки: не well formed xml / json
Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование заголовков)
Заголовки должны где-то обрабатываться:
— на сервере;
— на клиенте;
Иначе они не нужны, только лишний трафик гонять. Мы ведь передаем сообщение по сети, если интернет плохой, то каждый байт на счету. Зачем отправлять информацию, которую никто не использует?
Так что разработчики используют «Принцип меньшего зла»: заголовок или кем-то обрабатывается, или он вообще не нужен.
Если заголовка нет:
— используется дефолтный, прописанный в коде;
— он вообще не нужен;
Школу для начинающих тестировщиков я обновляю постоянно. Но обычно это какие-то минорные правки. Тут добавили доп материал, там изменили условие ДЗ... Курс ведь уже обкатан в течение 6 лет, поэтому глобально там менять особо нечего.
Но иногда бывает! Вот в прошлый раз я разбила лекцию про тест-кейсы и чек-листы на две, потом вообще переделала все ДЗ и добавила везде тесты. А теперь я сократила время курса на неделю, но не выкинув темы, а... Добавив!
7.5 недель лекций + 1.5 недели на хвосты
Под конец идут простенькие темы, которые нужны для того, чтобы ребята успели сдать свои хвосты. Это темы без ДЗ или с 1-2 небольшими дз:
Уже опубликовано видео моего доклада с SQA Days 30!
Напомню его аннотацию =)
Телеграм-бот как помощь в воспроизведении багов
Что делать, если заказчик нашел ошибку в системе? Воспроизвести локально, написать автотест, отдать разработчику. Вроде несложно. Но что, если у заказчика ошибка есть, а у нас нет? То есть проблема кроется в хитрой комбинации исходных данных. Нужно разбираться, что именно могло повлиять.
Мы прошли длинный путь такой диагностики. Сначала собирали данные через SQL-скрипты, потом автоматизировали их и даже внедрили в систему. А потом упростили задачу разворачивания билда, делегировав это… Телеграм-боту!
Допустим, мы вызываем метод doRegister в Users (для просмотра ТЗ использовать эти данные). Так как ФИО и email должны быть уникальными, используем динамические переменные из Postman. Получается такой запрос:
На как понять, что при этом уйдет на сервер? Какое именно число?
Можно нажать на кнопку code справа
