Comments 17
вот всегда интересовало - какой мозг придумал термин "негативный тест". Если на сервер отправляется некорректный запрос, то как бы ожидается, что сервер не дрогнет (500) и даст разумный ответ. Так чем этот тест негативнее теста, где ожидается 200?
Мне сложно ответить на то, кто был первоисточником. Но есть "позитивные" сценарии, когда пользователь идет по задуманной ветке использования, и есть "негативные", когда он попадает в условный эксепшен. Но вообще это не строго "это всегда позитив, а это негатив", это всегда просто градация "что в данном случае позитивныее" https://okiseleva.blogspot.com/2018/12/blog-post_24.html
Если на сервер отправляется некорректный запрос, то как бы ожидается, что сервер не дрогнет (500) и даст разумный ответ.
ИМХО, это тест исключительных ситуаций, что сервер выдаст понятную ошибку в таких случаях.
Ну а 500 это как раз не разумный ответ. Таких ответов в идеале быть не должно. На некорректный запрос должен быть ответ 4хх.
Где-то на середине был превышен лимит несогласия с автором и прекратил читать.
Я вообще не специалист по тестированию, но даже мне показалось, что как-то все на коленке, без объяснений причин, много частностей (какого-то проекта?) и личных предпочтений (наверное, опыт).
К сожалению, очень сложно ответить что-то на абстрактное "без объяснения причин" — где нет причин? Много примеров, есть истории из жизни "почему это надо проверять", что как раз поясняет.
"Много частностей" — каких? Есть теория, есть практика, на примере конкретного метода конкретного проекта. Я считаю, что так лучше усваивается материал, но если не хочется погружаться в конкретный пример, то можно просто пропускать все блоки "Практика на примере Users"
Как всегда отличный материал, спасибо!
>ВСЕГДА сначала позитивное тестирование
Если задача вернется в редев несколько раз - придется столько же раз делать и позитивное тестирование - и чаще всего совершенно безосновательно. С современными средствами разработки, даже у джуна редко получается сделать не то, "что надо", да и, в общем-то, это плохой тон, отдать задачу в тестирование, вообще не проверяя, что ты сделал. Проблемы начинаются, когда мы делаем шаг (а может даже и шажок) в сторону от того, "как надо". Поэтому сначала - если уж задача дошла до тестирования - те кейсы, которые вероятнее всего найдут ошибку. Да, это вполне могут быть и позитивные тесты - но, в них ошибки все-таки попадаются реже. А вот после того, как все баги исправлены, перед тем, как двинуть задачу в деплой - да, вот здесь проверка основного сценария просто обязательна
Ага, а потом придет менеджер и скажет "да пофиг на эту ошибку, надо срочно накатывать". Разработчик сидит исправляет финтифлюшки, а основной сценарий при этом до сих пор не проверен...
Не очень понятно, откуда такие крайности — то есть или тестировать N раз (сколько вернули в редев) одни и те же сценарии, или не проверять их вообще. Что мешает проверить в первый раз и потом после окончательных правок?
А если редева очень много, то тут скорее с ним разбираться надо. Или тестировщик отвлекает разработчика на каждое "о, я нашел странное поведение", или разработчик слишком уж косячит...
>Что мешает проверить в первый раз и потом после окончательных правок?
Например то, что основной сценарий могут сломать во время правок
>а потом придет менеджер и скажет "да пофиг на эту ошибку, надо срочно накатывать"
тогда тестирование здесь лишнее. Пусть катят :)
"Создание уверенностей в работоспособности ПО", как артефакт тестирования - это миф. У тестирования может быть только один артефакт - найденный баг, что кстати, написано в основных принципах
Например то, что основной сценарий могут сломать во время правок
Могут, да. Но чем лучше его вообще не тестировать 5 раз, чем протестировать 1 раз и потом после всех правок проверить, что не сломалось? Ведь ваш вариант как раз "вообще забить до того, как всякие баги починят"
У тестирования может быть только один артефакт - найденный баг,
А, для вас тестирование — это чисто поиск багов... Ну тогда да, надо "крушить и ломать"...
Могу посоветовать такую штуку как dredd, особенно если rest api как-то описан, например, в openapi формате. Сэкономит часть времени, а бонусом можно в ci/cd добавить.
Статья огромная! Видно, что потрачена уйма времени. Уже за это можно дать респект.
Но когда прочитал оглавление, сразу появилось чувство, что одного очень важного момента не хватает. Просмотрел всю статью, но так и не нашёл явных следов.
Зайду издалека: Из чего состоит тест-кейс?
Подавляющее большинство собеседуемых мной кандидатов отвечали: "Действие (список действий), ожидаемый результат, оценка результата". А где предусловия? А ведь это часто критически важный пункт!
Одно и то же действие при разных предусловиях может (и будет) приводить к совершенно разным ожидаемым результатам. И в API-тестировании предусловий масса. И все они, как правило, скрываются где-то в глубине.
==================
Второй момент -- это НТТР-коды.
HTTP-400 -- это Bad Request, по сути, это запрос, тело которого сервер не смог обработать. А вот всё (или почти всё), что в статье попадает под НТТР-400 -- это логические ошибки. Сервер принял запрос, обработал, увидел фигню в данных одного из 4 классов:
обязательность параметра
отсутствует строго-обязательный параметр
отсутствует параметр, являющийся обязательном при отсутствии другого
отсутствует параметр, являющийся обязательным при наличии другого
отсутствует параметр, являющийся обязательным в списке "обязательно один из..."
тип данных (нужна строка, а пришло число)
регулярка
длина
множество допустимых значений
связь между значениями параметров в запросе (например, start_date > end_date)
А дальше выходим на уровень взаимодействия с базой (если такое есть / будет)
duplicate key (для уникальных индексов)
использование несуществующих значений foreign key
какие-либо другие конфликты с существующими данными в базе (обычно в триггерах проверяется)
Либо наш API-метод выполняет какое-то другое действие. Всё зависит от "выходов" (куда данные, полученные в метод, "выходят"):
либо проксируются синхронно в другой API-метод
либо данные попадают в базу (реляционную / нереляционную; REDIS в данном контексте я также с натяжкой называю базой)
либо данные попадают в очередь (любая MQ-платформа = Rabbit, Kafka, WebSphere, ...)
либо данные попадают в файловую систему (напрямую или через любой протокол, типа FTP)
либо данные попадают в память сервиса (нелюбимый с точки зрения тестирования вариант)
Все описанные выше проверки -- сервер принял запрос на обработку. Ни о каком Bad Request тут речи быть не может.
HTTP-400 "Bad Request" -- это, например, если пришёл битый JSON, который нельзя смаршаллить.
Если же с базой или с каким-либо другим компонентом произошла непредвиденная ситуация (Uncatched Exception) -- тогда HTTP-500 "Internal Server Error"
Ребята, писавшие RFC для HTTP-протокола, всё-таки были прошаренными -- постарались продумать возможные варианты.
P.S. все описанные мной проверки, если посмотреть под призмой данной статьи, относятся к негативным кейсам. Но, во-первых, я не утверждал, что их надо проверять до "позитивов". Во-вторых, все эти проверки проводит код дисциплинированного разработчика ровно в том порядке, что я назвал. Причина указанного порядка = стоимость проверки со стороны кода в случае негатива. Например, если отсутствует хотя бы обязательный параметр, нет смысла проверять все параметры даже на тип данных.
P.P.S. В любом случае, статья для начинающих тестировщиков отличная!
Боже, какой херней занимаются тестировщики, а потом еще пишут портянки статей для легитимизации своего существования.
Значит, метод не идемпотентный… Нельзя просто взять пример из ТЗ и отправить не глядя.
Не значит. В данном случае он идемпотентный. Надо же читать статью целиком, а не только первый абзац. Хотя, и в приведённом первом обзаце написано же "не изменяющий состояние сервера". Разве при повторном запросе добавился пользователь?
Как тестировать методы REST API