Импортозамещение ПО: полное руководство по тест-кейсам для экспертов

Импортозамещение программного обеспечения — это не просто замена одного продукта на другой с похожим функционалом. Это комплексный процесс миграции, сопряженный с рисками для бизнес-континуитета, безопасности и производительности. Ключевым инструментом минимизации этих рисков является всестороннее тестирование. Данное руководство предлагает экспертный подход к составлению тест-кейсов, который охватывает не только функциональность, но и интеграции, безопасность, производительность и документацию отечественного или opensource-решения.

Фундаментом является функциональное тестирование, но с фокусом на специфику импортозамещения. Тест-кейсы должны быть построены на детальном сравнении функциональных возможностей старого и нового решения. Создайте матрицу соответствия (traceability matrix), где каждой ключевой функции импортируемого продукта ставится в соответствие тест-кейс для проверки аналогичной функции в новом ПО.

Пример тест-кейса для функциональности «Создание отчета» в системе документооборота:

**ID:** FUNC-DOC-001
**Заголовок:** Создание нового документа с типом «Входящее письмо».
**Предусловия:** Пользователь авторизован в системе, имеет роль «Секретарь». Модуль работы с документами активен.
**Шаги:**

• Перейти в раздел «Документы».
• Нажать кнопку «Создать документ».
• В выпадающем списке выбрать тип «Входящее письмо».
• Заполнить обязательные поля: «Регистрационный номер», «Корреспондент», «Дата поступления», «Краткое содержание».
• Прикрепить тестовый файл PDF.
• Нажать кнопку «Сохранить и зарегистрировать».

**Ожидаемый результат:** Документ появляется в журнале входящих документов с присвоенным системным номером, статусом «Зарегистрирован». Прикрепленный файл доступен для скачивания. Уведомление о новом документе отправлено ответственному исполнителю (если настроена маршрутизация). **Критерий приемки:** Все шаги выполнены без ошибок интерфейса или валидации. Данные сохранены корректно.

Однако функциональность — лишь вершина айсберга. Интеграционное тестирование критически важно, так как заменяемое ПО обычно глубоко встроено в экосистему компании. Разработайте тест-кейсы для всех точек интеграции: API, базы данных, очереди сообщений, службы каталогов (LDAP/AD), системы электронной подписи.

Пример тест-кейса для проверки интеграции по REST API:

**ID:** INT-API-001
**Заголовок:** Синхронизация данных о пользователях с каталогом Active Directory.
**Предусловия:** Настроен коннектор к AD, задано расписание синхронизации.
**Шаги:**

• В AD создать нового пользователя в тестовом подразделении.
• Запустить принудительную синхронизацию из админ-панели нового ПО.
• Выполнить запрос к API нового ПО: `GET /api/v1/users?username={new_user_login}`.
• Проверить ответ API и наличие пользователя в веб-интерфейсе.

**Ожидаемый результат:** API возвращает статус 200 и JSON-объект с данными нового пользователя. Пользователь отображается в интерфейсе с корректными атрибутами (ФИО, должность, email, взятыми из AD). **Критерий приемки:** Данные успешно синхронизированы, аутентификация нового пользователя в системе работает.

Безопасность — один из главных драйверов импортозамещения. Тест-кейсы должны включать проверку на соответствие требованиям регуляторов (например, приказу ФСТЭК 17, ГОСТ Р 57580). Фокус на аутентификацию, авторизацию, аудит и шифрование данных.

**ID:** SEC-AUTH-002
**Заголовок:** Проверка защиты от brute-force атак на форму входа.
**Предусловия:** Учетная запись тестового пользователя существует.
**Шаги:**

• С помощью инструментария (например, скрипта на Python) отправить 10 последовательных запросов к эндпоинту `/login` с неверным паролем.
• Попытаться выполнить вход с корректными данными на 11-й попытке.

**Ожидаемый результат:** После 5-й неудачной попытки учетная запись временно блокируется или требуется ввод CAPTCHA. 11-я попытка (с верными данными) без задержки/разблокировки не проходит. **Критерий приемки:** Система детектирует и парирует атаку подбора.

Для автоматизации такой проверки можно использовать простой скрипт:

```
import requests

login_url = "https://new-software.local/login"
credentials = {"username": "test_user", "password": "wrong_password"}
correct_creds = {"username": "test_user", "password": "correct_password"}

# Симуляция неудачных попыток
for i in range(10):
 response = requests.post(login_url, data=credentials)
 print(f"Попытка {i+1}: {response.status_code}")

# Попытка входа с корректным паролем после атаки
response = requests.post(login_url, data=correct_creds)
if response.status_code != 200 or "Неверный логин или пароль" in response.text:
 print("ТЕСТ ПРОЙДЕН: Защита от brute-force работает.")
else:
 print("ТЕСТ ПРОВАЛЕН: Уязвимость к brute-force.")
```

Производительность — частый камень преткновения. Новое решение может быть менее оптимизировано или иметь иные требования к ресурсам. Создайте тест-кейсы, имитирующие типовые и пиковые нагрузки.

**ID:** PERF-LOAD-001
**Заголовок:** Время отклика системы при одновременной работе 100 пользователей.
**Предусловия:** Развернуто production-подобное окружение, настроен скрипт нагрузочного тестирования (например, на JMeter или Locust).
**Шаги:**

• Запустить сценарий, в котором 100 виртуальных пользователей выполняют типовые операции: вход, просмотр дашборда, поиск документа, создание заявки.
• Сбор метрик: среднее время отклика, 95-й перцентиль, количество ошибок.

**Ожидаемый результат:** Среднее время отклика на ключевые операции не превышает 2 секунд. 95-й перцентиль — не более 5 секунд. Количество ошибок HTTP 5xx — 0%. **Критерий приемки:** Система укладывается в SLA по производительности.

Особый блок — те