Тестовые сценарии для служб REST с полезной нагрузкой JSON - PullRequest
0 голосов
/ 07 июня 2018

Я ищу рекомендации / лучшие практики для тестирования услуг REST.Например, если у меня есть следующая полезная нагрузка JSON в запросе REST:

{
    "maxActiveBadges": "1",
    "photoUrl": "https://someurl/?employeeId=12345",
    "employeeId": "12345"
}

Я подошел к тестированию, очевидно, это номер 1, чтобы протестировать сценарий «счастливого пути», чтобы убедиться, что я получаю код ответа 200,Тогда есть много негативных сценариев, которые я могу охватить:

пропущенные поля ввода, поля ввода с ошибками, неправильное форматирование полей ввода (например, строка вместо int), неверный json и превышение длины поля ввода.

Мой вопрос: насколько обширным должно быть отрицательное тестирование?Должен ли я разумно предположить, что служба будет корректно обрабатывать любые входные данные, возвращая соответствующий код ошибки и сообщение в теле ответа?

Дополнительный вопрос - существуют ли определенные символы, которые служба никогда не должна принимать, например \?<> по соображениям безопасности?

1 Ответ

0 голосов
/ 07 июня 2018

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

это зависит от того, какую платформу вы используетеи что они пишут в руководстве.это также зависит от того, правильно ли вы настроили и правильно ли указаны все правила проверки

Мой вопрос: насколько обширным должно быть отрицательное тестирование?

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

Так что на самом деле вы и ваша команда - единственные, кто может ответить на этот вопрос

Обычно в реальных системах вы используете один фреймворк, который предоставляет остальные конечные точки.Это работа, чтобы проверить одну из таких конечных точек, чтобы проверить все неправильно сформированные входные данные (неправильный json, неправильный метод и т. Д.), Просто чтобы проверить, правильно ли проверена валидация платформы, а затем вы тестируете каждую отдельную конечную точку, чтобы проверить валидацию, специфичную для этой конечной точки.Параметризованные тесты и сборщики запросов обычно позволяют добавлять такие тесты как однострочные

Дополнительный вопрос - существуют ли определенные символы, которые служба никогда не должна принимать, например, \? <> По соображениям безопасности?

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...