Статья огромная! Видно, что потрачена уйма времени. Уже за это можно дать респект.
Но когда прочитал оглавление, сразу появилось чувство, что одного очень важного момента не хватает. Просмотрел всю статью, но так и не нашёл явных следов.
Зайду издалека: Из чего состоит тест-кейс?
Подавляющее большинство собеседуемых мной кандидатов отвечали: "Действие (список действий), ожидаемый результат, оценка результата". А где предусловия? А ведь это часто критически важный пункт!
Одно и то же действие при разных предусловиях может (и будет) приводить к совершенно разным ожидаемым результатам. И в 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. В любом случае, статья для начинающих тестировщиков отличная!
Статья огромная! Видно, что потрачена уйма времени. Уже за это можно дать респект.
Но когда прочитал оглавление, сразу появилось чувство, что одного очень важного момента не хватает. Просмотрел всю статью, но так и не нашёл явных следов.
Зайду издалека: Из чего состоит тест-кейс?
Подавляющее большинство собеседуемых мной кандидатов отвечали: "Действие (список действий), ожидаемый результат, оценка результата". А где предусловия? А ведь это часто критически важный пункт!
Одно и то же действие при разных предусловиях может (и будет) приводить к совершенно разным ожидаемым результатам. И в 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. В любом случае, статья для начинающих тестировщиков отличная!