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

Question

[loly]

Кратко вопрос:
Есть 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) Упустил ли я что то?

Answer 1

[Котик Антон]

1) Нормально ли это при ручном тестировании? Если нет, то как лучше ограничить? К сожалению, выбор тут зависит не от меня.

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

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

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

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

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

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

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

В идеале да. На практике так мало кто делает, тем более при ручном тестировании, особенно если параметров очень много. Как правило хорошее API в ответе всегда сообщает какие из обязательных полей не указаны, их список и проверяют в ответах. Проверяют три случая: все обязательные поля не указаны в запросе, пара-тройка обязательных полей не указаны, все обязательные поля указаны в запросе.

Comments

[loly]

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

Интересный кейс, а можно продолжить список "и т.д."?)

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

а по какому принципу можно выделить "важные" поля?

Спасибо за ответ!

[Котик Антон]

Интересный кейс, а можно продолжить список "и т.д."?)

Можно.

Отправка параметра, отсутствующего в списке допустимых входных параметров. Хорошее API должно вернуть ошибку или хотя бы предупреждение.

Проверяем различные варианты URL при обращении к методу API:

http://domain.com/api/method
http://domain.com/api/method/
http://domain.com/api/METHOD
http://domain.com/api/METHOD/
https://domain.com/api/method
https://domain.com/api/method/
https://domain.com/api/METHOD
https://domain.com/api/METHOD/

Смотрим спецификацию JSON (www.json.org/) и проверяем разные валидные и невалидные варианты, на сколько хватит фантазии:

{"param":"""}
{'param':'test'}
{"param":"\u03C6"}
{"param":-10E+8}

Если что-то ещё вспомню, допишу сюда.

а по какому принципу можно выделить "важные" поля?

При принципу здравого смысл. Например, возьмем API платежной системы и с двумя полями amount (сумма счета, целое положительное число от 0 до 100 000) и description (описание платежа, строка, максимум 500 символов). Поле amount можно считать более важным, чем description. Если API примет описание из 501 символа, то это не так страшно, как если будет принят платеж с отрицательной суммой счета.

Answer 2

[xmoonlight]

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

Answer 3

[Максим Васильев]

Написать более 100 тестов не такая уж и проблема, если сами тесты структурировать, типа там сделать базовые/производные тесты, итп.

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