Тебеньков Flashcards
Что такое тестирование ПО
Теория тестирования
Проверка ПО на соответствие требованиям - явным или неявным
Цель тестирования (зачем тестировать?)
Теория тестирования
- Проверка на соответствие требованиям
- Выявление ошибок в коде и требованиях
- Предоставление актуальной информации о состоянии продукта на данный момент.
Какие проверки нужны при тестировании API?
- Авторизация
- Генерация токена
- Доступ с токеном
- Доступ без токена
- Истечение токена
- Отзыв токена
- Бизнес требования позитивные и негативные
- Технические требования позитивные и негативные
- Доступные методы через OPTIONS - Header
Allow
- Время отклика (например 1000мс, когда в среднем запрос проходит за 100-300мс)
- Позитивные и негативные явные - при отправке соответствующих данных по документации получаем ожидаемый код
- Без тела
- Неверный метод (заменить get на post) - ошибка 405 method not allowed
- Обязательные поля (по 3 кейса на каждое поле):
- Тело может быть пустое
- Неверное значение
- Поле отсутствует
- Неправильные типы данных (на string отправить int)
- query параметры (если обязательный):
- Пустой
- Неверное значение
- Отсутствует
- Заголовки важные
- Нет заголовка
- Пустой заголовок
- Неверный заголовок
Проверки авторизации при тестировании API
- Авторизация
- Генерация токена
- Доступ с токеном
- Доступ без токена
- Истечение токена
- Отзыв токена
Нужно ли проверять все негативные сценарии для API? И если нужно, то когда?
На каждый метод может выходить по 30 проверок, а методов может быть 50 штук и это очень большой проект
В случае публичных API требуется проверка всех сценариев.
В случае внутренних API - такая тщательная проверка не требуется.
Можно ли отправлять тело с get запросом?
Можно, но это не принято для этого метода. Результат зависит от того, как бэк обработает
Заголовок keep-alive
Заголовок Keep-Alive в HTTP используется для управления поведением соединений, которые поддерживаются активными (persistent connections) между клиентом и сервером. Он работает в паре с заголовком Connection: keep-alive и помогает избежать закрытия соединения после каждого запроса, что снижает нагрузку на сервер и улучшает производительность за счет повторного использования одного и того же соединения для нескольких запросов.
Если отправляя на запрос POST мы отправим GET и получим на 3-х независимых API ошибки 200, 400 и 500 - что делать?
И как они располагаются по критичности?
Ожидаем 405 - method not allowed.
Исследуем по логам сервера причины.
Критичность:
1. 200 - обработано успешно - очень плохо
2. 500 - обработало и упало в ошибку - плохо
3. 400 - отвергнуто - минорно
Заголовок Content type
Информация о формате запроса
Например application json - мы говорим серверу, что отправляем json и он обрабатывает это как json
* xml
* plain text
Зависит как реализовано на бэке - он может всегда ожидать json
Заголовок Accept
Какой формат ответа ожидаем
Т.е. если отправили json серверу, то и ожидаем json в ответ
Без этого заголовка может вернуть plain text
Какие порты по умолчанию используют HTTP и HTTPS
80 и 443
JSON
JavaScript Object Notation текстовый формат обмена данными (JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript
Формат: ключ-значение
Что используется в качестве значений в JSON?
Сам JSON это объект и внутри него могут быть объекты (в фигурных скобках)
- JSON-объект
- Массив
- Число (int, float)
- Литералы True, False и null
- Строка (string)
Каким может быть корневой элемент в JSON?
Корневой элемент может быть объектом, а может быть массивом:
{} и [] - массив объектов
JSON схема
Описание тела документа JSON