@loly

Правильно ли покрывать каждый параметр JSON REST api тестами?

Кратко вопрос:
Есть JSON API с 30 параметрами. Если применить пограничное значение на каждое поле + тесты на отсутствие каждого обязательного поля + 1 тест на только обязательные поля + 1 тест на все поля сразу, то получится больше 100 тестов.
1) Нормально ли это при ручном тестировании? Если нет, то как лучше ограничить? К сожалению, выбор тут зависит не от меня.
2) Нормально ли это при автоматизированном тестировании?
3) Не упустил ли я чего то?

Подробно с примером и описанием тестов:
Спойлер
Предусловие:
Что используется на сервере - неизвестно. Известен лишь формат и ограничения запроса/ответа.

К сожалению, тестированием API я раньше не занимался, по этому у меня есть 1 глобальный вопрос - "Что значит "достаточное" покрытие тестами JSON REST API запроса? Дальше я приведу пример запроса и попунктно свое видение тестов, не будет ли оно являться избыточным?"

Вопрос:
Необходимо обеспечить достаточное покрытие тестами.

Запрос (примерный, выдуманный, полей таких около 30:
{
"key1" : "String", // Длинна от 5 до 10 (обязательное поле)
"key2" : "String", // Длинна от 1 до 2
"key3" : "Array", // От 3 до 5 элементов, value:string от 2 до 4 (обязательное поле)
"key4" : "String", // Могут принимать значение лишь "CAR" и "MOTO"
"key5" : "boolean", // true или false (обязательное поле)
"key6" : "integer", // от 49 до 176 (обязательное поле)
"key7" : "Array" // длинна каждой строки от 3 до 10
}

Как я считаю необходимо протестировать:
Тест кейс 1: Полностью все поля присутствуют с корректными значениями;
Тест кейс 2: Только обязательные пол с корректными значениями;
Тест кейс 3-6: Отсутствие обязательных полей (по 1 тесту на каждое поле);
Тест кейс 7-10: Пограничное значение для key1;
Тест кейс 11-14: Пограничное значение для key2;
Тест кейс 15-18: Пограничное значение для key3;
Тест кейс 19-22: Пограничное значение для key3:value;
Тест кейс 23-26: Пограничное значение для key6;
Тест кейс 27-30: Пограничное значение для key7:string;
Тест кейс 31-33: Протестировать оба возможных и 1 невозможное значение;

Учитывая что полей в запросе около 30 - эти 33 кейса превратятся во все 100. Нормально ли это? Проблема в том, что на начальном этапе планируется ручное тестирование (не я принимаю такие решения и повлиять никак не могу).

Остальные вопросы:
1) На key7 количество элементов не ограничивается. Нормально ли это? Полагаю стоит сделать на это тесты в таком случае (еще 2, без элементов и большим их количеством);
2) Нужно ли тестировать каждое обязательное поле по отдельности?
3) Упустил ли я что то?
  • Вопрос задан
  • 1084 просмотра
Пригласить эксперта
Ответы на вопрос 3
  • 27cm
    @27cm
    TODO: Написать статус
    1) Нормально ли это при ручном тестировании? Если нет, то как лучше ограничить? К сожалению, выбор тут зависит не от меня.

    Все возможные кейсы вручную не проверяют, обычно ограничиваются только критичными случаями (проверяют обязательные поля и пограничные значения для наиболее важных параметров). Всё зависит от требований к тестированию и сроков. Если нужно, можно и все 100 тестов вручную сделать.

    2) Нормально ли это при автоматизированном тестировании?

    Да. В автотестах, как правило, проверяют все возможные ошибки.

    3) Не упустил ли я чего то?

    Тесты можно писать бесконечно, это опять же зависит от требований заказчика и сроков. Можно проверить отправку невалидного JSON-а, отправку запросов с некорректным HTTP методом: GET, POST, HEAD, PATCH... и т. д.

    Не стоит ограничиваться только сценариями на проверку ошибок. В зависимости от разных комбинаций входных параметров в API может быть реализовано разное поведение. Желательно проверить все принципиально разные успешные сценарии. Например, если в API есть boolean параметр, то необходимо проверить поведение при значении true и значении false.

    2) Нужно ли тестировать каждое обязательное поле по отдельности?

    В идеале да. На практике так мало кто делает, тем более при ручном тестировании, особенно если параметров очень много. Как правило хорошее API в ответе всегда сообщает какие из обязательных полей не указаны, их список и проверяют в ответах. Проверяют три случая: все обязательные поля не указаны в запросе, пара-тройка обязательных полей не указаны, все обязательные поля указаны в запросе.
    Ответ написан
  • xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.ru
    1. Для каждого метода подготавливаются и проверяются все regex-выражения на корректность работы выборки для ожидаемых входных данных по "белому" списку (это не только к API относится, а ко всему):
    параметр1 -> regex-выражение1
    параметр2 -> regex-выражение2
    и т.д.
    2. Добавляются эти выражения в свои методы, согласно таблице соответствий.
    3. Проверяется каждый метод, что ответ при неверных входных данных содержит всю нужную информацию для понимания происходящего.
    4. Затем 2-3 раза прогоняете весь процесс работы бизнес-логики с этим API.
    5. Всё ОК - можно "болтить".
    Ответ написан
  • qmax
    @qmax
    программер
    Написать более 100 тестов не такая уж и проблема, если сами тесты структурировать, типа там сделать базовые/производные тесты, итп.

    Правда, если увлечся, может понадобиться тестировать сами тесты.
    Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы