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

## Содержание
1. [GET /account/get](#1-get-accountget)
2. [POST /account/create](#2-post-accountcreate)
3. [DELETE /account/delete](#3-delete-accountdelete)
4. [GET /accounts](#4-get-accounts)
5. [GET /privilege/{userId}](#5-get-privilegeuserid)
6. [DELETE /account/{userId}](#6-delete-accountuserid)
7. [POST /account/manualdone](#7-post-accountmanualdone)
8. [POST /account/leadtarget](#8-post-accountleadtarget)
9. [PUT /account/leadtarget](#9-put-accountleadtarget)
10. [DELETE /account/leadtarget/{id}](#10-delete-accountleadtargetid)
11. [GET /account/leadtarget/{quizID}](#11-get-accountleadtargetquizid)
13. [POST /question/create](#13-post-questioncreate)

## 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:
  ```json
  {
    "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:
  ```json
  {
    "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": "<script>alert('xss')</script>" }
- Ожидаемый результат: 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:
  ```json
  {
    "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": "<script>alert('xss')</script>" }
- Ожидаемый результат: 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:
  ```json
  {
    "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": "<script>alert('xss')</script>" }
- Ожидаемый результат: 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:
  ```json
  {
    "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": "<script>alert('xss')</script>" }
- Ожидаемый результат: 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:
  ```json
  {
    "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": "<script>alert('xss')</script>" }
- Ожидаемый результат: 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/<script>alert('xss')</script>
- Ожидаемый результат: 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/<script>alert('xss')</script>
- Ожидаемый результат: 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
```json
{
  "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)
```json
{
  "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:
```json
{
  "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:
```json
{
  "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:
```json
{
  "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:
```json
{
  "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