core/api_test_specification.md

Тестовая спецификация API

Содержание

1. GET /account/get
2. POST /account/create
3. DELETE /account/delete
4. GET /accounts
5. GET /privilege/{userId}
6. DELETE /account/{userId}
7. POST /account/manualdone
8. POST /account/leadtarget
9. PUT /account/leadtarget
10. DELETE /account/leadtarget/{id}
11. GET /account/leadtarget/{quizID}
12. POST /question/create

1. GET /account/get

1.1 Описание

Получение информации о текущем аккаунте пользователя.

1.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Возвращает детальную информацию об аккаунте в формате JSON
• Поддерживает стандартные HTTP коды ответа: 200, 401, 404, 500

1.3 Тестовые сценарии

1.3.1 Успешное получение информации об аккаунте

Предусловия:

• Пользователь авторизован
• Аккаунт существует и активен
• JWT токен валиден

Входные данные:

• Метод: GET
• URL: /account/get
• Headers:
  • Authorization: Bearer {valid_jwt_token}

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит объект Account со следующими полями:
  • id (string)
  • user_id (string)
  • created_at (date-time)
  • privileges (object)

Проверки:

1. Все обязательные поля присутствуют в ответе
2. Формат даты created_at соответствует ISO 8601
3. Структура privileges соответствует схеме ShortPrivilege
4. Значения полей соответствуют данным в базе

1.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

1.3.3 Проверка существования аккаунта

Сценарий 3.1: Аккаунт не найден

• Предусловие: Аккаунт удален или не существует
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

Сценарий 3.2: Аккаунт деактивирован

• Предусловие: Аккаунт помечен как deleted=true
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

1.3.4 Проверка привилегий

Сценарий 4.1: Аккаунт без привилегий

• Предусловие: Аккаунт существует, но не имеет привилегий
• Ожидаемый результат: 200 OK
• Проверка: privileges = {}

Сценарий 4.2: Аккаунт с множеством привилегий

• Предусловие: Аккаунт имеет несколько активных привилегий
• Ожидаемый результат: 200 OK
• Проверка структуры и содержимого privileges

1.3.5 Проверка производительности

Сценарий 5.1: Время ответа

• Проверка: время ответа < 500ms
• Проверка: стабильность времени ответа при повторных запросах

Сценарий 5.2: Нагрузочное тестирование

• Проверка: система выдерживает 100 последовательных запросов
• Проверка: отсутствие утечек памяти

1.3.6 Проверка безопасности

Сценарий 6.1: XSS уязвимости

• Проверка: экранирование специальных символов в ответе
• Проверка: корректные заголовки безопасности

Сценарий 6.2: CSRF защита

• Проверка: наличие и валидность CSRF токена
• Проверка: корректная обработка невалидного CSRF токена

1.3.7 Граничные случаи

Сценарий 7.1: Очень длинные значения полей

• Проверка: обработка полей с максимально допустимой длиной
• Проверка: корректное обрезание/валидация длинных значений

Сценарий 7.2: Специальные символы в данных

• Проверка: корректная обработка Unicode символов
• Проверка: обработка специальных символов в именах полей

1.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

1.4 Особые моменты для тестирования

1. Валидация JWT токена:

   • Проверка подписи токена
   • Проверка срока действия
   • Проверка структуры claims

2. Кэширование:

   • Проверка правильности кэширования ответов
   • Проверка инвалидации кэша при изменении данных

3. Логирование:

   • Проверка записи всех важных событий
   • Проверка корректности логов

4. Мониторинг:

   • Проверка метрик производительности
   • Проверка алертов при ошибках

1.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время ответа соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно

2. POST /account/create

2.1 Описание

Создание нового аккаунта пользователя.

2.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Создает новый аккаунт в системе
• Поддерживает HTTP коды ответа: 200, 401, 409, 500

2.3 Тестовые сценарии

2.3.1 Успешное создание аккаунта

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• Аккаунт с таким user_id еще не существует

Входные данные:

• Метод: POST
• URL: /account/create
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит объект Account со следующими полями:
  • id (string)
  • user_id (string)
  • created_at (date-time)
  • privileges (object)

Проверки:

1. Аккаунт успешно создан в базе данных
2. Все обязательные поля присутствуют в ответе
3. Формат даты created_at соответствует ISO 8601
4. Значения полей соответствуют переданным данным

2.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

2.3.3 Проверка конфликтов

Сценарий 3.1: Создание дублирующегося аккаунта

• Предусловие: Аккаунт с таким user_id уже существует
• Ожидаемый результат: 409 Conflict
• Проверка сообщения об ошибке

Сценарий 3.2: Попытка создания аккаунта с существующим ID

• Предусловие: Передан ID существующего аккаунта
• Ожидаемый результат: 409 Conflict
• Проверка сообщения об ошибке

2.3.4 Проверка валидации данных

Сценарий 4.1: Отсутствие обязательных полей

• Входные данные: пустой JSON объект
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 4.2: Некорректный формат данных

• Входные данные: неверный формат полей
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

2.3.5 Проверка безопасности

Сценарий 5.1: SQL-инъекции

• Входные данные: SQL-инъекция в полях
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 5.2: XSS-атаки

• Входные данные: XSS-код в полях
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

2.3.6 Проверка производительности

Сценарий 6.1: Время создания

• Проверка: время создания аккаунта < 1s
• Проверка: стабильность времени при повторных запросах

Сценарий 6.2: Нагрузочное тестирование

• Проверка: система выдерживает создание 100 аккаунтов подряд
• Проверка: отсутствие утечек памяти

2.3.7 Граничные случаи

Сценарий 7.1: Очень длинные значения полей

• Входные данные: поля с максимально допустимой длиной
• Ожидаемый результат: 200 OK
• Проверка: данные сохранены корректно

Сценарий 7.2: Специальные символы

• Входные данные: Unicode символы в полях
• Ожидаемый результат: 200 OK
• Проверка: данные сохранены корректно

2.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

2.4 Особые моменты для тестирования

1. Валидация данных:

   • Проверка всех обязательных полей
   • Проверка форматов данных
   • Проверка уникальности user_id

2. Транзакционность:

   • Проверка атомарности операции создания
   • Проверка отката при ошибках

3. Логирование:

   • Проверка записи создания аккаунта
   • Проверка аудит-логов

4. Мониторинг:

   • Проверка метрик создания аккаунтов
   • Проверка алертов при ошибках

2.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время создания аккаунта соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно

3. DELETE /account/delete

3.1 Описание

Удаление текущего аккаунта пользователя.

3.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Удаляет текущий аккаунт пользователя
• Поддерживает HTTP коды ответа: 200, 401, 500

3.3 Тестовые сценарии

3.3.1 Успешное удаление аккаунта

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• Аккаунт существует и активен

Входные данные:

• Метод: DELETE
• URL: /account/delete
• Headers:
  • Authorization: Bearer {valid_jwt_token}

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит объект с полем accountId (string)

Проверки:

1. Аккаунт успешно удален из базы данных
2. Все связанные данные аккаунта удалены или помечены как удаленные
3. Поле accountId в ответе соответствует ID удаленного аккаунта
4. Последующие запросы к аккаунту возвращают 404

3.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

3.3.3 Проверка состояния аккаунта

Сценарий 3.1: Удаление уже удаленного аккаунта

• Предусловие: Аккаунт уже помечен как удаленный
• Ожидаемый результат: 200 OK
• Проверка: повторное удаление не вызывает ошибок

Сценарий 3.2: Удаление несуществующего аккаунта

• Предусловие: Аккаунт не существует
• Ожидаемый результат: 200 OK
• Проверка: операция завершается успешно

3.3.4 Проверка каскадного удаления

Сценарий 4.1: Удаление связанных данных

• Проверка: все связанные квизы удалены или помечены как удаленные
• Проверка: все связанные вопросы удалены или помечены как удаленные
• Проверка: все связанные результаты удалены или помечены как удаленные

Сценарий 4.2: Сохранение статистики

• Проверка: статистические данные сохранены для аналитики
• Проверка: исторические данные доступны для отчетов

3.3.5 Проверка безопасности

Сценарий 5.1: Попытка удаления чужого аккаунта

• Предусловие: Попытка удаления аккаунта другого пользователя
• Ожидаемый результат: 401 Unauthorized
• Проверка: операция отклонена

Сценарий 5.2: Проверка CSRF защиты

• Проверка: наличие и валидность CSRF токена
• Проверка: отклонение запросов без валидного CSRF токена

3.3.6 Проверка производительности

Сценарий 6.1: Время удаления

• Проверка: время удаления аккаунта < 2s
• Проверка: стабильность времени при повторных запросах

Сценарий 6.2: Нагрузочное тестирование

• Проверка: система корректно обрабатывает множественные запросы на удаление
• Проверка: отсутствие утечек памяти при массовом удалении

3.3.7 Граничные случаи

Сценарий 7.1: Удаление аккаунта с большим количеством данных

• Предусловие: Аккаунт имеет множество связанных данных
• Ожидаемый результат: 200 OK
• Проверка: все данные успешно удалены

Сценарий 7.2: Удаление во время активных операций

• Предусловие: Активные операции с аккаунтом
• Ожидаемый результат: 200 OK
• Проверка: корректная обработка конкурентных запросов

3.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

3.4 Особые моменты для тестирования

1. Транзакционность:

   • Проверка атомарности операции удаления
   • Проверка отката при частичном удалении
   • Проверка целостности данных после удаления

2. Логирование:

   • Проверка записи операции удаления
   • Проверка аудит-логов
   • Проверка логов связанных операций

3. Мониторинг:

   • Проверка метрик удаления аккаунтов
   • Проверка алертов при ошибках
   • Проверка мониторинга связанных операций

4. Восстановление:

   • Проверка возможности восстановления данных
   • Проверка периода хранения удаленных данных

3.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время удаления аккаунта соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Каскадное удаление работает корректно
7. Данные успешно удаляются или помечаются как удаленные

4. GET /accounts

4.1 Описание

Получение списка аккаунтов с поддержкой пагинации.

4.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Поддерживает пагинацию через параметры limit и page
• Поддерживает HTTP коды ответа: 200, 400, 401, 500

4.3 Тестовые сценарии

4.3.1 Успешное получение списка аккаунтов

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• В системе есть несколько аккаунтов

Входные данные:

• Метод: GET
• URL: /accounts
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json
• Body:

  {
    "limit": 10,
    "page": 1
  }
  

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит объект со следующими полями:
  • count (integer) - общее количество аккаунтов
  • items (array) - массив объектов Account

Проверки:

1. Количество возвращаемых элементов не превышает limit
2. Все обязательные поля присутствуют в каждом объекте Account
3. Значение count соответствует общему количеству аккаунтов
4. Элементы отсортированы по дате создания (новые первые)

4.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

4.3.3 Проверка пагинации

Сценарий 3.1: Корректные параметры пагинации

• Входные данные: limit=10, page=1
• Ожидаемый результат: 200 OK
• Проверка: возвращается корректное количество элементов

Сценарий 3.2: Некорректные параметры пагинации

• Входные данные: limit=0, page=0
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Превышение максимального лимита

• Входные данные: limit=1000
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

4.3.4 Проверка фильтрации

Сценарий 4.1: Пустой результат

• Предусловие: Нет аккаунтов в системе
• Ожидаемый результат: 200 OK
• Проверка: count=0, items=[]

Сценарий 4.2: Последняя страница

• Входные данные: page с большим номером
• Ожидаемый результат: 200 OK
• Проверка: items=[]

4.3.5 Проверка безопасности

Сценарий 5.1: Проверка прав доступа

• Проверка: пользователь видит только разрешенные аккаунты
• Проверка: конфиденциальные данные скрыты

Сценарий 5.2: CSRF защита

• Проверка: наличие и валидность CSRF токена
• Проверка: отклонение запросов без валидного CSRF токена

4.3.6 Проверка производительности

Сценарий 6.1: Время ответа

• Проверка: время ответа < 500ms
• Проверка: стабильность времени при повторных запросах

Сценарий 6.2: Нагрузочное тестирование

• Проверка: система выдерживает 100 последовательных запросов
• Проверка: отсутствие утечек памяти

4.3.7 Граничные случаи

Сценарий 7.1: Большое количество аккаунтов

• Предусловие: В системе 1000+ аккаунтов
• Ожидаемый результат: 200 OK
• Проверка: корректная работа пагинации

Сценарий 7.2: Специальные символы в данных

• Проверка: корректная обработка Unicode символов
• Проверка: корректное отображение специальных символов

4.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

4.4 Особые моменты для тестирования

1. Кэширование:

   • Проверка правильности кэширования результатов
   • Проверка инвалидации кэша при изменении данных

2. Логирование:

   • Проверка записи запросов к списку аккаунтов
   • Проверка аудит-логов

3. Мониторинг:

   • Проверка метрик производительности
   • Проверка алертов при ошибках

4. Оптимизация:

   • Проверка эффективности запросов к БД
   • Проверка использования индексов

4.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время ответа соответствует требованиям
3. Пагинация работает корректно
4. Обработка ошибок соответствует спецификации
5. Безопасность соответствует стандартам
6. Логирование и мониторинг работают корректно
7. Кэширование работает эффективно

5. GET /privilege/{userId}

5.1 Описание

Получение списка привилегий для указанного пользователя по его ID.

5.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Требуется передача userId в теле запроса
• Поддерживает HTTP коды ответа: 200, 400, 401, 500

5.3 Тестовые сценарии

5.3.1 Успешное получение привилегий

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• Указанный пользователь существует
• У пользователя есть привилегии

Входные данные:

• Метод: GET
• URL: /privilege/{userId}
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json
• Body:

  {
    "userId": "valid_user_id"
  }
  

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит массив объектов ShortPrivilege со следующими полями:
  • id (string)
  • privilege_id (string)
  • privilege_name (string)
  • amount (integer)
  • created_at (date-time)

Проверки:

1. Все привилегии пользователя возвращены
2. Все обязательные поля присутствуют в каждом объекте
3. Формат даты created_at соответствует ISO 8601
4. Значения полей соответствуют данным в базе

5.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

5.3.3 Проверка входных данных

Сценарий 3.1: Отсутствие userId

• Body: пустой JSON объект
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Невалидный userId

• Body: { "userId": "invalid_id" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Несуществующий userId

• Body: { "userId": "non_existent_id" }
• Ожидаемый результат: 200 OK
• Проверка: возвращается пустой массив

5.3.4 Проверка прав доступа

Сценарий 4.1: Запрос привилегий другого пользователя

• Предусловие: Запрос привилегий пользователя с другим ID
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

Сценарий 4.2: Запрос привилегий с недостаточными правами

• Предусловие: У запрашивающего пользователя нет прав на просмотр привилегий
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

5.3.5 Проверка безопасности

Сценарий 5.1: SQL-инъекции

• Body: { "userId": "1' OR '1'='1" }
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 5.2: XSS-атаки

• Body: { "userId": "" }
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

5.3.6 Проверка производительности

Сценарий 6.1: Время ответа

• Проверка: время ответа < 300ms
• Проверка: стабильность времени при повторных запросах

Сценарий 6.2: Нагрузочное тестирование

• Проверка: система выдерживает 100 последовательных запросов
• Проверка: отсутствие утечек памяти

5.3.7 Граничные случаи

Сценарий 7.1: Пользователь с большим количеством привилегий

• Предусловие: У пользователя 100+ привилегий
• Ожидаемый результат: 200 OK
• Проверка: все привилегии возвращены корректно

Сценарий 7.2: Пользователь без привилегий

• Предусловие: У пользователя нет привилегий
• Ожидаемый результат: 200 OK
• Проверка: возвращается пустой массив

5.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

5.4 Особые моменты для тестирования

1. Кэширование:

   • Проверка кэширования результатов запроса
   • Проверка инвалидации кэша при изменении привилегий

2. Логирование:

   • Проверка записи запросов к привилегиям
   • Проверка аудит-логов доступа

3. Мониторинг:

   • Проверка метрик производительности
   • Проверка алертов при ошибках

4. Безопасность:

   • Проверка контроля доступа
   • Проверка валидации входных данных

5.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время ответа соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Кэширование работает эффективно
7. Контроль доступа работает корректно

6. DELETE /account/{userId}

6.1 Описание

Удаление аккаунта пользователя по его ID.

6.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Требуется передача userId в теле запроса
• Поддерживает HTTP коды ответа: 200, 400, 401, 500

6.3 Тестовые сценарии

6.3.1 Успешное удаление аккаунта

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• У запрашивающего пользователя есть права на удаление аккаунтов
• Удаляемый аккаунт существует и активен

Входные данные:

• Метод: DELETE
• URL: /account/{userId}
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json
• Body:

  {
    "userId": "valid_user_id"
  }
  

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит объект с полем userId (string)

Проверки:

1. Аккаунт успешно удален из базы данных
2. Все связанные данные аккаунта удалены или помечены как удаленные
3. Поле userId в ответе соответствует ID удаленного аккаунта
4. Последующие запросы к аккаунту возвращают 404

6.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

6.3.3 Проверка входных данных

Сценарий 3.1: Отсутствие userId

• Body: пустой JSON объект
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Невалидный userId

• Body: { "userId": "invalid_id" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Несуществующий userId

• Body: { "userId": "non_existent_id" }
• Ожидаемый результат: 200 OK
• Проверка: операция завершается успешно

6.3.4 Проверка прав доступа

Сценарий 4.1: Удаление без необходимых прав

• Предусловие: У пользователя нет прав на удаление аккаунтов
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

Сценарий 4.2: Попытка удаления системного аккаунта

• Предусловие: Попытка удаления системного аккаунта
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

6.3.5 Проверка каскадного удаления

Сценарий 5.1: Удаление связанных данных

• Проверка: все связанные квизы удалены или помечены как удаленные
• Проверка: все связанные вопросы удалены или помечены как удаленные
• Проверка: все связанные результаты удалены или помечены как удаленные

Сценарий 5.2: Сохранение статистики

• Проверка: статистические данные сохранены для аналитики
• Проверка: исторические данные доступны для отчетов

6.3.6 Проверка безопасности

Сценарий 6.1: SQL-инъекции

• Body: { "userId": "1' OR '1'='1" }
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 6.2: XSS-атаки

• Body: { "userId": "" }
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

6.3.7 Проверка производительности

Сценарий 7.1: Время удаления

• Проверка: время удаления аккаунта < 2s
• Проверка: стабильность времени при повторных запросах

Сценарий 7.2: Нагрузочное тестирование

• Проверка: система корректно обрабатывает множественные запросы на удаление
• Проверка: отсутствие утечек памяти при массовом удалении

6.3.8 Граничные случаи

Сценарий 8.1: Удаление аккаунта с большим количеством данных

• Предусловие: Аккаунт имеет множество связанных данных
• Ожидаемый результат: 200 OK
• Проверка: все данные успешно удалены

Сценарий 8.2: Удаление во время активных операций

• Предусловие: Активные операции с аккаунтом
• Ожидаемый результат: 200 OK
• Проверка: корректная обработка конкурентных запросов

6.3.9 Обработка ошибок

Сценарий 9.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 9.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

6.4 Особые моменты для тестирования

1. Транзакционность:

   • Проверка атомарности операции удаления
   • Проверка отката при частичном удалении
   • Проверка целостности данных после удаления

2. Логирование:

   • Проверка записи операции удаления
   • Проверка аудит-логов
   • Проверка логов связанных операций

3. Мониторинг:

   • Проверка метрик удаления аккаунтов
   • Проверка алертов при ошибках
   • Проверка мониторинга связанных операций

4. Восстановление:

   • Проверка возможности восстановления данных
   • Проверка периода хранения удаленных данных

6.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время удаления аккаунта соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Каскадное удаление работает корректно
7. Данные успешно удаляются или помечаются как удаленные
8. Контроль доступа работает корректно

7. POST /account/manualdone

7.1 Описание

Ручная пометка аккаунта как завершенного.

7.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Требуется передача id пользователя в теле запроса
• Поддерживает HTTP коды ответа: 200, 400, 401, 404, 500

7.3 Тестовые сценарии

7.3.1 Успешная пометка аккаунта как завершенного

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• У запрашивающего пользователя есть права на пометку аккаунтов
• Аккаунт существует и активен

Входные данные:

• Метод: POST
• URL: /account/manualdone
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json
• Body:

  {
    "id": "valid_user_id"
  }
  

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json

Проверки:

1. Аккаунт успешно помечен как завершенный
2. Статус аккаунта обновлен в базе данных
3. Все связанные операции завершены
4. Последующие запросы к аккаунту показывают обновленный статус

7.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

7.3.3 Проверка входных данных

Сценарий 3.1: Отсутствие id

• Body: пустой JSON объект
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Невалидный id

• Body: { "id": "invalid_id" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Несуществующий id

• Body: { "id": "non_existent_id" }
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

7.3.4 Проверка прав доступа

Сценарий 4.1: Отметка без необходимых прав

• Предусловие: У пользователя нет прав на пометку аккаунтов
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

Сценарий 4.2: Попытка пометки системного аккаунта

• Предусловие: Попытка пометки системного аккаунта
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

7.3.5 Проверка состояния аккаунта

Сценарий 5.1: Пометка уже завершенного аккаунта

• Предусловие: Аккаунт уже помечен как завершенный
• Ожидаемый результат: 200 OK
• Проверка: повторная пометка не вызывает ошибок

Сценарий 5.2: Пометка удаленного аккаунта

• Предусловие: Аккаунт помечен как удаленный
• Ожидаемый результат: 404 Not Found
• Проверка: операция отклонена

7.3.6 Проверка безопасности

Сценарий 6.1: SQL-инъекции

• Body: { "id": "1' OR '1'='1" }
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 6.2: XSS-атаки

• Body: { "id": "" }
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

7.3.7 Проверка производительности

Сценарий 7.1: Время выполнения

• Проверка: время выполнения операции < 1s
• Проверка: стабильность времени при повторных запросах

Сценарий 7.2: Нагрузочное тестирование

• Проверка: система корректно обрабатывает множественные запросы
• Проверка: отсутствие утечек памяти

7.3.8 Граничные случаи

Сценарий 8.1: Пометка аккаунта с большим количеством данных

• Предусловие: Аккаунт имеет множество связанных данных
• Ожидаемый результат: 200 OK
• Проверка: все данные успешно обработаны

Сценарий 8.2: Пометка во время активных операций

• Предусловие: Активные операции с аккаунтом
• Ожидаемый результат: 200 OK
• Проверка: корректная обработка конкурентных запросов

7.3.9 Обработка ошибок

Сценарий 9.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 9.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

7.4 Особые моменты для тестирования

1. Транзакционность:

   • Проверка атомарности операции пометки
   • Проверка отката при частичном выполнении
   • Проверка целостности данных после пометки

2. Логирование:

   • Проверка записи операции пометки
   • Проверка аудит-логов
   • Проверка логов связанных операций

3. Мониторинг:

   • Проверка метрик выполнения операций
   • Проверка алертов при ошибках
   • Проверка мониторинга связанных операций

4. Восстановление:

   • Проверка возможности отмены пометки
   • Проверка истории изменений статуса

7.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время выполнения операции соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Транзакционность работает корректно
7. Статус аккаунта успешно обновляется
8. Контроль доступа работает корректно

8. POST /account/leadtarget

8.1 Описание

Добавление целевого адреса для отправки клиентских запросов.

8.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Обязательные поля в теле запроса: type, quizID, target
• Поддерживает HTTP коды ответа: 200, 208, 400, 401, 404, 500

8.3 Тестовые сценарии

8.3.1 Успешное добавление целевого адреса

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• У пользователя есть права на добавление целевых адресов

Входные данные:

• Метод: POST
• URL: /account/leadtarget
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json
• Body:

  {
    "type": "mail",
    "quizID": 123,
    "target": "example@mail.com",
    "name": "Example Channel"
  }
  

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json

Проверки:

1. Целевой адрес успешно добавлен
2. Данные корректно сохранены в базе
3. Все обязательные поля присутствуют
4. Значения полей соответствуют переданным данным

8.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

8.3.3 Проверка входных данных

Сценарий 3.1: Отсутствие обязательных полей

• Body: { "type": "mail" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Невалидный тип

• Body: { "type": "invalid", "quizID": 123, "target": "example@mail.com" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Невалидный формат target

• Body: { "type": "mail", "quizID": 123, "target": "invalid_email" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

8.3.4 Проверка дублирования

Сценарий 4.1: Добавление существующего target

• Предусловие: Target уже существует
• Ожидаемый результат: 208 Already Reported
• Проверка сообщения об ошибке

Сценарий 4.2: Добавление с разным регистром

• Предусловие: Target существует с другим регистром
• Ожидаемый результат: 208 Already Reported
• Проверка сообщения об ошибке

8.3.5 Проверка безопасности

Сценарий 5.1: SQL-инъекции

• Body: { "type": "mail", "quizID": "1' OR '1'='1", "target": "example@mail.com" }
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 5.2: XSS-атаки

• Body: { "type": "mail", "quizID": 123, "target": "" }
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

8.3.6 Проверка производительности

Сценарий 6.1: Время выполнения

• Проверка: время выполнения операции < 1s
• Проверка: стабильность времени при повторных запросах

Сценарий 6.2: Нагрузочное тестирование

• Проверка: система корректно обрабатывает множественные запросы
• Проверка: отсутствие утечек памяти

8.3.7 Граничные случаи

Сценарий 7.1: Максимальная длина полей

• Body: { "type": "mail", "quizID": 123, "target": "very_long_email@domain.com", "name": "very_long_name" }
• Ожидаемый результат: 200 OK
• Проверка: данные сохранены корректно

Сценарий 7.2: Специальные символы

• Body: { "type": "mail", "quizID": 123, "target": "special!@#$%^&*()@domain.com", "name": "Special Name!" }
• Ожидаемый результат: 200 OK
• Проверка: данные сохранены корректно

8.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

8.4 Особые моменты для тестирования

1. Валидация данных:

   • Проверка форматов email, телефона, ID канала
   • Проверка уникальности target
   • Проверка допустимых значений type

2. Транзакционность:

   • Проверка атомарности операции добавления
   • Проверка отката при ошибках

3. Логирование:

   • Проверка записи операции добавления
   • Проверка аудит-логов

4. Мониторинг:

   • Проверка метрик добавления target
   • Проверка алертов при ошибках

8.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время выполнения операции соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Валидация данных работает корректно
7. Дублирование target обрабатывается корректно

9. PUT /account/leadtarget

9.1 Описание

Обновление существующего целевого адреса.

9.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• Обязательные поля в теле запроса: id, target
• Поддерживает HTTP коды ответа: 200, 400, 401, 404, 500

9.3 Тестовые сценарии

9.3.1 Успешное обновление целевого адреса

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• У пользователя есть права на обновление целевых адресов
• Целевой адрес существует

Входные данные:

• Метод: PUT
• URL: /account/leadtarget
• Headers:
  • Authorization: Bearer {valid_jwt_token}
  • Content-Type: application/json
• Body:

  {
    "id": 123,
    "target": "new_target@mail.com"
  }
  

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json

Проверки:

1. Целевой адрес успешно обновлен
2. Данные корректно сохранены в базе
3. Старое значение target заменено на новое
4. Остальные поля остались без изменений

9.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

9.3.3 Проверка входных данных

Сценарий 3.1: Отсутствие обязательных полей

• Body: { "id": 123 }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Невалидный id

• Body: { "id": "invalid", "target": "example@mail.com" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Невалидный формат target

• Body: { "id": 123, "target": "invalid_email" }
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

9.3.4 Проверка существования

Сценарий 4.1: Обновление несуществующего target

• Body: { "id": 999999, "target": "example@mail.com" }
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

Сценарий 4.2: Обновление удаленного target

• Предусловие: Target помечен как удаленный
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

9.3.5 Проверка безопасности

Сценарий 5.1: SQL-инъекции

• Body: { "id": "1' OR '1'='1", "target": "example@mail.com" }
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 5.2: XSS-атаки

• Body: { "id": 123, "target": "" }
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

9.3.6 Проверка производительности

Сценарий 6.1: Время выполнения

• Проверка: время выполнения операции < 1s
• Проверка: стабильность времени при повторных запросах

Сценарий 6.2: Нагрузочное тестирование

• Проверка: система корректно обрабатывает множественные запросы
• Проверка: отсутствие утечек памяти

9.3.7 Граничные случаи

Сценарий 7.1: Максимальная длина target

• Body: { "id": 123, "target": "very_long_email@very_long_domain.com" }
• Ожидаемый результат: 200 OK
• Проверка: данные сохранены корректно

Сценарий 7.2: Специальные символы

• Body: { "id": 123, "target": "special!@#$%^&*()@domain.com" }
• Ожидаемый результат: 200 OK
• Проверка: данные сохранены корректно

9.3.8 Обработка ошибок

Сценарий 8.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 8.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

9.4 Особые моменты для тестирования

1. Валидация данных:

   • Проверка форматов email, телефона, ID канала
   • Проверка уникальности нового target
   • Проверка существования id

2. Транзакционность:

   • Проверка атомарности операции обновления
   • Проверка отката при ошибках

3. Логирование:

   • Проверка записи операции обновления
   • Проверка аудит-логов
   • Проверка истории изменений

4. Мониторинг:

   • Проверка метрик обновления target
   • Проверка алертов при ошибках

9.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время выполнения операции соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Валидация данных работает корректно
7. Обновление target выполняется корректно
8. История изменений сохраняется

10. DELETE /account/leadtarget/{id}

10.1 Описание

Удаление целевого адреса по его ID.

10.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• ID целевого адреса передается в пути URL
• Поддерживает HTTP коды ответа: 200, 400, 401, 500

10.3 Тестовые сценарии

10.3.1 Успешное удаление целевого адреса

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• У пользователя есть права на удаление целевых адресов
• Целевой адрес существует и активен

Входные данные:

• Метод: DELETE
• URL: /account/leadtarget/{valid_id}
• Headers:
  • Authorization: Bearer {valid_jwt_token}

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json

Проверки:

1. Целевой адрес успешно удален
2. Данные корректно удалены из базы
3. Последующие запросы к этому ID возвращают 404
4. Все связанные данные обработаны корректно

10.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

10.3.3 Проверка входных данных

Сценарий 3.1: Невалидный ID

• URL: /account/leadtarget/invalid_id
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Отсутствующий ID

• URL: /account/leadtarget/
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Несуществующий ID

• URL: /account/leadtarget/999999
• Ожидаемый результат: 200 OK
• Проверка: операция завершается успешно

10.3.4 Проверка прав доступа

Сценарий 4.1: Удаление без необходимых прав

• Предусловие: У пользователя нет прав на удаление целевых адресов
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

Сценарий 4.2: Попытка удаления чужого целевого адреса

• Предусловие: Целевой адрес принадлежит другому пользователю
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

10.3.5 Проверка состояния целевого адреса

Сценарий 5.1: Удаление уже удаленного целевого адреса

• Предусловие: Целевой адрес уже помечен как удаленный
• Ожидаемый результат: 200 OK
• Проверка: повторное удаление не вызывает ошибок

Сценарий 5.2: Удаление активного целевого адреса

• Предусловие: Целевой адрес активен и используется
• Ожидаемый результат: 200 OK
• Проверка: все связанные операции обработаны корректно

10.3.6 Проверка безопасности

Сценарий 6.1: SQL-инъекции

• URL: /account/leadtarget/1' OR '1'='1
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 6.2: XSS-атаки

• URL: /account/leadtarget/
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

10.3.7 Проверка производительности

Сценарий 7.1: Время выполнения

• Проверка: время выполнения операции < 1s
• Проверка: стабильность времени при повторных запросах

Сценарий 7.2: Нагрузочное тестирование

• Проверка: система корректно обрабатывает множественные запросы на удаление
• Проверка: отсутствие утечек памяти

10.3.8 Граничные случаи

Сценарий 8.1: Удаление целевого адреса с большим количеством связанных данных

• Предусловие: Целевой адрес имеет множество связанных данных
• Ожидаемый результат: 200 OK
• Проверка: все данные успешно удалены

Сценарий 8.2: Удаление во время активных операций

• Предусловие: Активные операции с целевым адресом
• Ожидаемый результат: 200 OK
• Проверка: корректная обработка конкурентных запросов

10.3.9 Обработка ошибок

Сценарий 9.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 9.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

10.4 Особые моменты для тестирования

1. Транзакционность:

   • Проверка атомарности операции удаления
   • Проверка отката при частичном удалении
   • Проверка целостности данных после удаления

2. Логирование:

   • Проверка записи операции удаления
   • Проверка аудит-логов
   • Проверка логов связанных операций

3. Мониторинг:

   • Проверка метрик удаления целевых адресов
   • Проверка алертов при ошибках
   • Проверка мониторинга связанных операций

4. Восстановление:

   • Проверка возможности восстановления данных
   • Проверка периода хранения удаленных данных

10.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время выполнения операции соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Транзакционность работает корректно
7. Целевой адрес успешно удаляется
8. Контроль доступа работает корректно

11. GET /account/leadtarget/{quizID}

11.1 Описание

Получение целевого адреса по ID квиза.

11.2 Базовые требования

• Требуется JWT токен авторизации (bearerAuth)
• ID квиза передается в пути URL
• Поддерживает HTTP коды ответа: 200, 400, 401, 404, 500

11.3 Тестовые сценарии

11.3.1 Успешное получение целевого адреса

Предусловия:

• Пользователь авторизован
• JWT токен валиден
• У пользователя есть права на просмотр целевых адресов
• Квиз существует и имеет связанный целевой адрес

Входные данные:

• Метод: GET
• URL: /account/leadtarget/{valid_quiz_id}
• Headers:
  • Authorization: Bearer {valid_jwt_token}

Ожидаемый результат:

• HTTP Status: 200 OK
• Content-Type: application/json
• Тело ответа содержит объект LeadTarget со следующими полями:
  • id (integer)
  • accountID (string)
  • type (string)
  • target (string)
  • quizID (integer)
  • inviteLink (string, опционально)
  • deleted (boolean)
  • createdAt (date-time)

Проверки:

1. Все обязательные поля присутствуют в ответе
2. Формат даты createdAt соответствует ISO 8601
3. Значения полей соответствуют данным в базе
4. Тип целевого адреса соответствует ожидаемому

11.3.2 Проверка авторизации

Сценарий 2.1: Отсутствие токена

• Headers: без Authorization
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.2: Невалидный токен

• Headers: Authorization: Bearer invalid_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

Сценарий 2.3: Истекший токен

• Headers: Authorization: Bearer expired_token
• Ожидаемый результат: 401 Unauthorized
• Проверка сообщения об ошибке

11.3.3 Проверка входных данных

Сценарий 3.1: Невалидный quizID

• URL: /account/leadtarget/invalid_id
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.2: Отсутствующий quizID

• URL: /account/leadtarget/
• Ожидаемый результат: 400 Bad Request
• Проверка сообщения об ошибке

Сценарий 3.3: Несуществующий quizID

• URL: /account/leadtarget/999999
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

11.3.4 Проверка прав доступа

Сценарий 4.1: Просмотр без необходимых прав

• Предусловие: У пользователя нет прав на просмотр целевых адресов
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

Сценарий 4.2: Попытка просмотра чужого целевого адреса

• Предусловие: Целевой адрес принадлежит другому пользователю
• Ожидаемый результат: 401 Unauthorized
• Проверка: доступ запрещен

11.3.5 Проверка состояния целевого адреса

Сценарий 5.1: Получение удаленного целевого адреса

• Предусловие: Целевой адрес помечен как удаленный
• Ожидаемый результат: 404 Not Found
• Проверка сообщения об ошибке

Сценарий 5.2: Получение активного целевого адреса

• Предусловие: Целевой адрес активен
• Ожидаемый результат: 200 OK
• Проверка: все данные возвращены корректно

11.3.6 Проверка безопасности

Сценарий 6.1: SQL-инъекции

• URL: /account/leadtarget/1' OR '1'='1
• Ожидаемый результат: 400 Bad Request
• Проверка: инъекция не выполнена

Сценарий 6.2: XSS-атаки

• URL: /account/leadtarget/
• Ожидаемый результат: 400 Bad Request
• Проверка: XSS-код не выполнен

11.3.7 Проверка производительности

Сценарий 7.1: Время выполнения

• Проверка: время выполнения операции < 300ms
• Проверка: стабильность времени при повторных запросах

Сценарий 7.2: Нагрузочное тестирование

• Проверка: система выдерживает 100 последовательных запросов
• Проверка: отсутствие утечек памяти

11.3.8 Граничные случаи

Сценарий 8.1: Получение целевого адреса с большим количеством данных

• Предусловие: Целевой адрес имеет множество связанных данных
• Ожидаемый результат: 200 OK
• Проверка: все данные возвращены корректно

Сценарий 8.2: Получение во время активных операций

• Предусловие: Активные операции с целевым адресом
• Ожидаемый результат: 200 OK
• Проверка: корректная обработка конкурентных запросов

11.3.9 Обработка ошибок

Сценарий 9.1: Внутренняя ошибка сервера

• Предусловие: Имитация сбоя базы данных
• Ожидаемый результат: 500 Internal Server Error
• Проверка: информативное сообщение об ошибке

Сценарий 9.2: Таймаут соединения

• Предусловие: Имитация таймаута
• Ожидаемый результат: 500 Internal Server Error
• Проверка: корректная обработка таймаута

11.4 Особые моменты для тестирования

1. Кэширование:

   • Проверка правильности кэширования результатов
   • Проверка инвалидации кэша при изменении данных
   • Проверка TTL кэша

2. Логирование:

   • Проверка записи запросов к целевым адресам
   • Проверка аудит-логов
   • Проверка логов доступа

3. Мониторинг:

   • Проверка метрик производительности
   • Проверка алертов при ошибках
   • Проверка мониторинга доступа

4. Безопасность:

   • Проверка контроля доступа
   • Проверка валидации входных данных
   • Проверка защиты от атак

11.5 Критерии приемки

1. Все тестовые сценарии пройдены успешно
2. Время ответа соответствует требованиям
3. Обработка ошибок соответствует спецификации
4. Безопасность соответствует стандартам
5. Логирование и мониторинг работают корректно
6. Кэширование работает эффективно
7. Контроль доступа работает корректно
8. Данные возвращаются в корректном формате

13. POST /question/create

Description

Creates a new question in the system. The endpoint requires authentication and accepts a JSON payload with question details.

Request

• Method: POST
• Path: /question/create
• Authentication: Required (Bearer Token)
• Content-Type: application/json

Request Body Schema

{
  "quiz_id": "integer (required)",
  "title": "string (required, max 512 chars)",
  "description": "string (optional)",
  "type": "string (required, enum)",
  "required": "boolean (optional)",
  "page": "integer (optional)",
  "content": "string (optional, JSON)"
}

Response

• Content-Type: application/json

Success Response (200)

{
  "id": "integer",
  "quiz_id": "integer",
  "title": "string",
  "description": "string",
  "type": "string",
  "required": "boolean",
  "deleted": "boolean",
  "page": "integer",
  "content": "string",
  "version": "integer",
  "parent_ids": ["integer"],
  "created_at": "string (date-time)",
  "updated_at": "string (date-time)"
}

Error Responses

• 400 Bad Request
• 401 Unauthorized
• 406 Not Acceptable
• 422 Validation Error
• 424 Failed Dependency
• 500 Internal Server Error

Test Cases

TC1: Create Basic Question

Objective: Verify that a question can be created with minimal required fields Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Send POST request with minimal required fields:

{
  "quiz_id": 1,
  "title": "Test Question",
  "type": "text"
}

Expected Results:

• Status Code: 200
• Response contains created question with all fields
• Question ID is generated
• Created_at and updated_at timestamps are set

TC2: Create Question with All Fields

Objective: Verify that a question can be created with all possible fields Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Send POST request with all fields:

{
  "quiz_id": 1,
  "title": "Comprehensive Test Question",
  "description": "This is a detailed question description",
  "type": "variant",
  "required": true,
  "page": 1,
  "content": "{\"options\": [\"Option 1\", \"Option 2\"]}"
}

Expected Results:

• Status Code: 200
• Response contains all provided fields
• Question is properly created with all attributes

TC3: Create Question with Different Types

Objective: Verify that questions can be created with all supported types Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Create questions with each type:
   • text
   • variant
   • images
   • select
   • varimg
   • emoji
   • date
   • number
   • page
   • rating
   • result
   • file Expected Results:

• Status Code: 200 for each type
• Questions are created successfully
• Type-specific content is properly stored

TC4: Invalid Quiz ID

Objective: Verify error handling for non-existent quiz ID Preconditions:

• Valid authentication token Test Steps:

1. Send POST request with invalid quiz_id:

{
  "quiz_id": 999999,
  "title": "Test Question",
  "type": "text"
}

Expected Results:

• Status Code: 400 or 424
• Error message indicates invalid quiz ID

TC5: Missing Required Fields

Objective: Verify validation of required fields Preconditions:

• Valid authentication token Test Steps:

1. Send POST request without quiz_id
2. Send POST request without title
3. Send POST request without type Expected Results:

• Status Code: 400
• Error message indicates missing required fields

TC6: Invalid Question Type

Objective: Verify validation of question type Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Send POST request with invalid type:

{
  "quiz_id": 1,
  "title": "Test Question",
  "type": "invalid_type"
}

Expected Results:

• Status Code: 400 or 422
• Error message indicates invalid question type

TC7: Title Length Validation

Objective: Verify title length constraints Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Send POST request with title exceeding 512 characters
2. Send POST request with empty title Expected Results:

• Status Code: 400 or 422
• Error message indicates title length violation

TC8: Invalid Content Format

Objective: Verify content JSON format validation Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Send POST request with invalid JSON in content field
2. Send POST request with content not matching type requirements Expected Results:

• Status Code: 400 or 422
• Error message indicates invalid content format

TC9: Unauthorized Access

Objective: Verify authentication requirement Preconditions: None Test Steps:

1. Send POST request without authentication token Expected Results:

• Status Code: 401
• Error message indicates authentication required

TC10: Rate Limiting

Objective: Verify rate limiting behavior Preconditions:

• Valid authentication token
• Quiz exists in the system Test Steps:

1. Send multiple POST requests in quick succession Expected Results:

• Status Code: 429 (if rate limited)
• Error message indicates rate limit exceeded

Special Testing Considerations

Content Validation

• Verify that content JSON matches the expected format for each question type
• Test with various content structures for each type
• Validate that content is properly stored and can be retrieved

Type-Specific Requirements

• Each question type may have specific content requirements
• Test creation with valid and invalid content for each type
• Verify that type-specific validation rules are enforced

Quiz Relationship

• Verify that questions are properly associated with the quiz
• Test creation of questions for different quizzes
• Verify that quiz_id references are properly validated

Version Control

• Check if version tracking is implemented
• Verify that new questions start with appropriate version numbers
• Test version incrementing if applicable

Performance

• Test creation of multiple questions in sequence
• Monitor response times for different question types
• Verify system behavior under load

Security

• Verify that questions can only be created by authorized users
• Test access control for different user roles
• Verify that sensitive data is properly handled

Data Integrity

• Verify that all fields are properly stored
• Test creation with special characters in text fields
• Verify that timestamps are properly set
• Check that required fields are properly enforced