API — это один из наиболее ключевых и системообразующих компонентов любого программного обеспечения.
Своего рода это отдельно сформированный веб-продукт, поломка которого рискует «положить» не одно взаимосвязанное приложение, которые выстроены вокруг него.
Это значит, что тестировать подобные компоненты необходимо с особой тщательностью.Далее как раз и проанализируем какие базовые принципы и методы проверки необходимо использовать при работе с API.
- Базовые позитивные тесты (выполнение успешного сценария по умолчанию);
- Расширенные положительные проверки с применением дополнительного набора параметров;
- Негативные тесты с корректными входными данными;
- Негативные проверки с невалидными входными данными;
- Процесс деструктивного тестирования;
- Проверка безопасности, доступности и авторизации.
В будущем можно расширять группу положительных тестов, дабы включать дополнительные параметры и вспомогательный функционал.
Затем следует группа тестов — под негативные проверки, при исполнении которых пользователь может ожидать, что ПО будет «правильно» взаимодействовать с проблемными сценариями как с валидным вводом пользователя (к примеру, попытка добавления уже существующего имени пользователя), так и с некорректным вводом пользовательских данных (потенциальная возможность добавить имя пользователя, которое содержит значение null).
Набор деструктивных тестов — это очень глубокий вид негативного тестирования, когда QA-специалист целенаправленно желает «поломать» API, дабы протестировать его надежность (к примеру, отправляя заведомо очень большое тело запроса, с целью переполнить систему и попытаться ее сломать).
Использование тестовых потоков
Далее стоит разобрать три базовых типа потоков тестирования, которые в обязательном порядке стоит использовать при проверке API:
- Изолированная проверка запросов — старт одного запроса API и соответствующий тест ответа. Подобные базовые тесты — это своего рода классические «строительные элементы», с которых следует начинать тестирование API. И нет никакого смысла продолжать проверки, если подобные тесты не буду выполняться;
- Многоступенчатый поток с двумя и более запросами — проверка серии запросов, являющих собой классические действия пользователя, так как одни запросы могут системно зависеть друг от друга. К примеру, нам нужно выполнить запрос POST, который, в свою очередь, создает ресурс и возвращает созданный ID в теле ответа. Потом мы берём данный ID, дабы протестировать, есть ли данный ресурс в перечне составляющих, которые мы получили с помощью запроса GET. Далее мы берём PATCH для процедуры обновления новой информации и заново создаем запрос GET для тестирования этого обновления. И, в конце концов, необходимо удалить данный ресурс и по новой использовать GET, чтобы быть уверенным, что используемой в тесте записи больше нет;
- Комбинированные проверки API и тесты графического веб-интерфейса — это, в большей степени, ручные проверки, при которых необходимо обеспечить целостность информации и согласованность между GUI и API.
Нефункциональные подходы к тестированию качества API
Процесс авторизации и системная безопасность:
- Стоит проверить, что API корректно отвечает на правильную авторизацию всеми реализованными способами: файлы cookie, token auth 2.0 и дайджест;
- Проверьте, что API может отклонять все несанкционированные вызовы;
- Протестируйте, что в проверяемом API содержится безопасное падение сервиса, все невалидные данные отклоняются в запросе, а также есть отказ по умолчанию.
Нагрузочные проверки и стресс-тестирование:
- Протестируйте время отклика API и его задержки;
- Отыщите точки ограничения производительности и проверьте, что ПО работает корректным образом при достаточной нагрузке и «боеспособно» выходит из под нагрузки.
Оставить комментарий