Документ описывает процесс тестирования API дизайна, начиная от определения API и его аспектов до стратегии тестирования и валидации данных. Основные элементы включают создание четкой документации, обработку ошибок, безопасность и управление версиями. В документе также рассматриваются примеры валидации данных, способы тестирования и различные аспекты взаимодействия с API.

1. Тестирование API дизайна
Web Test Framework с нуля [PRO]
NoBugs

2. С чего начинается любое
API тестирование?
2

3. С проведения
тестирования
API дизайна!
3

4. 4
ШАГ 1: ЧТО ТАКОЕ API ДИЗАЙН?
API дизайн -
это процесс разработки API,
который позволяет разным
программным продуктам
взаимодействовать друг с
другом

5. 5
ШАГ 1: ЧТО ТАКОЕ API ДИЗАЙН?
я
доставляю
еду
я
готовлю
еду
Какие блюда
у нас есть?
Сейчас
отправлю
API дизайн задает способ
передачи информации

6. 6
ШАГ 2: АСПЕКТЫ API ДИЗАЙНА
● Определение ресурсов:
Чётко определите объекты или сущности, к которым API
предоставляет доступ.
● Методы и операции:
Разрабатывайте методы (GET, POST, PUT, DELETE) для
манипуляции ресурсами.
● Стандартизация интерфейсов:
Используйте стандартные протоколы, такие как REST или
GraphQL.
● Обработка ошибок: Чётко определяйте методы сообщения
об ошибках через статус-коды и структурированные
сообщения.
● Безопасность: Внедряйте механизмы аутентификации и
авторизации для защиты данных.

7. 7
ШАГ 2: АСПЕКТЫ API ДИЗАЙНА
● Версионирование: Предусматривайте механизмы
для управления версиями API.
● Масштабируемость: Разрабатывайте API с учётом
возможного увеличения нагрузки.
● Ограничение частоты запросов: Устанавливайте
ограничения на количество запросов для
предотвращения злоупотреблений.
● Документация: Обеспечивайте чёткую и полную
документацию для упрощения интеграции и
использования API.
● Отзывчивость и производительность:
Оптимизируйте время ответа и управление
ресурсами для улучшения пользовательского
опыта.

8. 8
ШАГ 3: ТЕСТИРОВАНИЕ API ДИЗАЙНА
Зачем?
сервис
#1
сервис
#2
Создай заказ
на пиццу “пепперони”
Ответ: 500
Создай заказ
на пиццу “тип 1”
Ответ: 201

9. 9
ШАГ 3: ТЕСТИРОВАНИЕ API ДИЗАЙНА
Реализация
Ожидание
API пользователи (UI и сервисы) должны попасть сюда

10. 10
ШАГ 4: ИССЛЕДОВАНИЕ ВОПРОСАМИ
Техника “6 ключевых слов”:
кто; что; где; когда; почему; как.
1. Кто? Кто будет использовать этот API?
2. Что? Что делает этот API?
3. Где? Где этот API будет использоваться?
4. Когда? Когда будет использоваться этот API?
5. Почему? Почему этот API нужен?
6. Как? Как этот API будет работать?

11. 11
ШАГ 4: ИССЛЕДОВАНИЕ ВОПРОСАМИ
Техника “ЕЩЕ”:
Добавляем ЕЩЕ
к изначальному вопросу.
1. Кто еще будет использовать этот API?
2. Что еще делает этот API?
3. Где еще этот API будет использоваться?
4. Когда еще будет использоваться этот API?
5. Почему еще этот API нужен?
6. Как еще этот API будет работать?

12. 12
ШАГ 4: ИССЛЕДОВАНИЕ ВОПРОСАМИ

13. 13
ШАГ 5: СТРАТЕГИЯ
ТЕСТИРОВАНИЯ API ДИЗАЙНА
Обязательный анализ
каждого значения:
● Поля тела запроса
● Параметра запроса
● Хедера

14. 14
ШАГ 6: ВАЛИДАЦИЯ ДАННЫХ
Тестирование на корректные
типы данных:
Проверка, что API корректно
принимает и обрабатывает допустимые
типы данных (например, числа,
строки, булевы значения).
Тестирование на некорректные
типы данных:
Отправка недопустимых типов данных
для каждого параметра API для
проверки обработки ошибок и
возвращаемых кодов состояния.

15. 15
ШАГ 6: ВАЛИДАЦИЯ ДАННЫХ
Тестирование
граничных значений:
Проверка реакции API на минимальные
и максимальные возможные значения, а
также на значения, выходящие за
пределы ожидаемого диапазона.

16. 16
ШАГ 7: ФОРМАТ ДАННЫХ
Соответствие формату:
Убедиться, что API строго соблюдает
требования к форматированию данных,
как в запросах, так и в ответах.
Тестирование
сериализации и
десериализации:
Проверка, что данные корректно
преобразуются в требуемый формат при
отправке и корректно интерпретируются
при получении.

17. 17
ШАГ 8: АНАЛИЗ ТИПА ДАННЫХ
Длина строки: Тестирование строк минимальной,
максимальной и превышающей максимальную длины.
Специальные символы: Включение спецсимволов,
таких как символы новой строки, табуляции, кавычки.
Форматирование: Строки с форматами данных,
например, JSON, XML, чтобы проверить корректность их
обработки.
Unicode и кодировки: Строки на разных языках и с
различными кодировками.
Пустые строки и строки только с пробелами:
Проверка обработки таких строк.Длина строки:
Тестирование строк минимальной, максимальной и
превышающей максимальную длины.
Cтроки (Strings)

18. 18
ШАГ 8: АНАЛИЗ ТИПА ДАННЫХ
Граничные значения: Минимальные,
максимальные и выходящие за пределы
значений числа.
Отрицательные значения и ноль:
Проверка реакции API на отрицательные
числа и ноль.
Нецелые числа: Для float — проверка
точности и обработки дробных значений.
Формат числа: Например, числа с
ведущими нулями или в научной нотации.
Числа (Integers)

19. 19
ШАГ 8: АНАЛИЗ ТИПА ДАННЫХ
● True и False: Проверка обработки и возвращаемых
результатов для обоих логических значений.
● Неявные логические значения:
Такие как 1 и 0 вместо true и false.
Логические значения (Boolean)
● Форматы даты и времени:
Проверка соблюдения разных стандартов
форматирования (ISO 8601, RFC 2822).
● Часовые пояса:
Обработка дат/времени в различных часовых поясах.
● Некорректные даты:
Несуществующие даты (например, 31 февраля).
Даты и время

20. 20
ШАГ 8: АНАЛИЗ ТИПА ДАННЫХ
● Пустые и заполненные структуры: Проверка
реакции API на пустые массивы или объекты, а также
на массивы/объекты с данными.
● Несоответствие типов внутри: Массивы или
объекты, содержащие элементы неправильного
типа.
● Вложенные структуры: Объекты или массивы,
вложенные друг в друга, для проверки глубины
обработки.
Составные типы (Arrays, Objects)
● Поле с null-значением: Проверка на корректную
обработку полей, содержащих значение null.
Null значения

21. 21
ШАГ 8: АНАЛИЗ ТИПА ДАННЫХ

22. 22
ШАГ 8: АНАЛИЗ ТИПА ДАННЫХ

23. ШАГ 9: API ДОКУМЕНТАЦИЯ
23
СПЕЦИФИКАЦИЯ OPEN API 3

24. ШАГ 9: API ДОКУМЕНТАЦИЯ
24
GET https://example.com/api/users
[
{
"id": 1,
"name": "John Doe"
},
{
"id": 2,
"name": "Jane Doe"
}
]
получить список пользователей

25. ШАГ 9: API ДОКУМЕНТАЦИЯ
25
openapi: '3.0.0' # Указывает версию спецификации OpenAPI
info: # Блок информации о документе
title: 'Simple User API' # Название API
version: '1.0.0' # Версия API
servers: # Список серверов, на которых доступен API
- url: 'https://example.com/api' # Базовый URL сервера
paths: # Определения путей (endpoints) API
/users: # Путь к ресурсу пользователей
get: # HTTP метод для получения данных о пользователях
summary: 'List all users' # Краткое описание метода
operationId: 'listUsers' # Уникальный идентификатор операции
responses: # Возможные ответы на запрос
'200': # HTTP статус код 200 ОК
description: 'A list of users' # Описание ответа
content:
application/json: # MIME тип содержимого ответа
schema: # Схема данных, ожидаемая в ответе
type: array # Тип данных - массив
items: # Элементы массива
$ref: '#/components/schemas/User' # Ссылка на описание
структуры данных пользователя

26. ШАГ 9: API ДОКУМЕНТАЦИЯ
26
components: # Компоненты, используемые в API
schemas: # Схемы данных
User: # Определение схемы пользователя
type: object # Тип данных - объект
properties: # Свойства объекта
id:
type: integer # Свойство id типа integer
format: int64 # Формат данных - 64-битное целое число
name:
type: string # Свойство name типа string
required: # Список обязательных свойств объекта
- id
- name

27. ШАГ 9: API ДОКУМЕНТАЦИЯ
27
Песочница: https://app.swaggerhub.com

28. 28
ШАГ 9: API ДОКУМЕНТАЦИЯ

29. 29
ПРИМЕР В СТУДИЮ
Покажите
пример!
Все примеры основаны
на реальных событиях

30. 30
тип пиццы
пепперони
моцарелла
адрес
ЗАКАЗАТЬ
ШАГ 10: РАЗБОР ПРИМЕРА

31. 31
ШАГ 10: РАЗБОР ПРИМЕРА
Метод: POST /order
{
"pizzaId": 1 | 2, // 1 для Pepperoni, 2 для Mozzarella
"address": "string"
}
Ответы:
201 Created: Заказ успешно создан.
В ответе может быть ID созданного заказа или
подтверждение.
400 Bad Request: Некорректный запрос, например,
если pizzaId не равен 1 или 2.
500 Internal Server Error: Проблемы на сервере.

32. 32
ШАГ 9: РАЗБОР ПРИМЕРА
Какие дополнительные параметры заказа нужны?
Какие правила валидации данных мы применяем?
Что делать при неверном pizzaId?
Какие меры защиты данных пользователя
используем?
Как обрабатывать системные ошибки?
Как настроено логирование действий и ошибок?
Техника “6 вопросов к API”

33. 33
ШАГ 9: РАЗБОР ПРИМЕРА
Что ещё мы можем добавить в опции
заказа для улучшения пользовательского опыта?
Что ещё можно сделать для ускорения обработки заказов?
Что ещё может повысить безопасность транзакций через API?
Что ещё мы можем предложить
для повышения лояльности клиентов?
Что ещё можно оптимизировать
в инфраструктуре для обеспечения масштабируемости?
Техника “ЧТО ЕЩЕ”

34. 34
ШАГ 9: РАЗБОР ПРИМЕРА
Валидация pizzaId
Проверка наличия:
pizzaId должен присутствовать в каждом запросе.
Проверка типа данных:
pizzaId должен быть целым числом.
Проверка допустимых значений:
pizzaId должен быть либо 1 (для пепперони),
либо 2 (для моцареллы).
Проверка на отрицательные значения:
pizzaId не должен быть отрицательным.

35. 35
ШАГ 9: РАЗБОР ПРИМЕРА
Валидация address
Проверка наличия:
Адрес должен быть предоставлен в каждом запросе.
Проверка типа данных:
Адрес должен быть строкой.
Проверка минимальной длины:
Длина адреса должна быть не менее 5 символов, чтобы исключить
неполные или ошибочные адреса.
Проверка максимальной длины:
Длина адреса не должна превышать 100 символов
для избежания ошибок в базе данных или системе доставки.
Проверка содержимого:
Адрес не должен содержать специальные символы или неподходящие
выражения, которые могут вызвать ошибки при обработке.

36. 36
ШАГ 9: РАЗБОР ПРИМЕРА
Негативные проверки для pizzaId
Отсутствие pizzaId:
Ответ: 400 Bad Request
Сообщение: "Поле 'pizzaId' обязательно для
заполнения."
Некорректный тип данных pizzaId:
Ответ: 400 Bad Request
Сообщение: "Поле 'pizzaId' должно быть целым числом."
Недопустимое значение pizzaId:
Ответ: 400 Bad Request
Сообщение: "Значение 'pizzaId' недопустимо. Доступные
значения: 1 для пепперони, 2 для моцареллы."

37. 37
ШАГ 9: РАЗБОР ПРИМЕРА
Негативные проверки для address
Отсутствие address:
Ответ: 400 Bad Request
Сообщение: "Поле 'address' обязательно для
заполнения."
Некорректный тип данных address:
Ответ: 400 Bad Request
Сообщение: "Поле 'address' должно быть строкой."
Слишком короткий или длинный address:
Ответ: 400 Bad Request
Сообщение: "Длина адреса должна быть от 5 до 100
символов."
Содержание недопустимых символов в address:
Ответ: 400 Bad Request
Сообщение: "Адрес содержит недопустимые символы."

38. 38
ШАГ 9: РАЗБОР ПРИМЕРА
Взаимодействие с командами
А как вы планируете
использовать API?

39. Web API best practices
39
МАТЕРИАЛЫ
К
ЧТЕНИЮ
https://learn.microsoft.com/en-us/azure/architecture
/best-practices/api-design

40. Тестирование API дизайна:
40
СЕГОДНЯ
МЫ
УЗНАЛИ
Шаг 1: Что такое API дизайн?
Шаг 2: Аспекты API дизайна
Шаг 3: Тестирование API дизайна
Шаг 4: Исследование вопросами
Шаг 5: Стратегия тестирования API дизайна
Шаг 6: Валидация данных
Шаг 7: Формат данных
Шаг 8: Анализ типа данных
Шаг 9: API документация
Шаг 10: Разбор примера

41. ГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ
ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛ
АЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПО
ГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ
И ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГН
НАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ П
ОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ
ГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ
АЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПО
ГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ
ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛ
АЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПО
ГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ
И ПОГНАЛИ ПОГНАЛИ ПОГНАЛИ ПОГН
ПОГНАЛИ!