- •1 Объект испытаний
- •1.1 Наименование системы и её условное обозначение
- •1.2 Назначение и область применения
- •2 Цель испытаний
- •3 Требования к системе
- •3.1 Требования к системе в целом
- •3.1.1 Требования к структуре и функционированию системы
- •3.1.2 Требования к показателям назначения
- •Требования к технической интеграции
- •Требования к эргономике и техническому интерфейсу
- •Требования к защите информации от несанкционированного доступа.
- •Требования по сохранности информации при авариях
- •3.2 Требования к функциям
- •3.3 Требования к видам обеспечения
- •3.3.1 Требования к лингвистическому обеспечению системы
- •3.3.2 Требования к программному обеспечению системы
- •3.3.3 Требования к техническому обеспечению системы
- •4 Требования к программной документации
- •5 Средства и порядок испытаний
- •5.1 Технические средства
- •5.2 Программные средства
- •5.3 Порядок проведения испытаний
- •5.4 Особые требования к испытаниям
- •6 Методы тестирование
- •6.1 Метод функционального тестирования
- •6.1.1 Тестирование базовой подсистемы
- •6.1.2 Тестирование подсистемы шаблонов
- •6.1.3 Подсистема хранения и защиты данных
- •6.1.4 Тестирование подсистемы работы с документами
- •6.1.5 Тестирование подсистемы авторизации и администрирования
- •6.2 Метод нагрузочного и производительного тестирования
- •6.3 Метод тестирования безопасности
- •6.4 Метод тестирования удобства использования и эргономики
- •6.5 Метод тестирования надежности и восстановления
- •6.6 Метод визуальной проверки комплектности пакета документов
- •6.7 Фиксирование результатов
- •Список ипользуемых источников
- •Список ипользуемых источников
- •Приложение а
- •Приложение б Группа 1 – тестирование восстановления после сбоя
- •Шаблон акта проведения испытаний
3 Требования к системе
3.1 Требования к системе в целом
3.1.1 Требования к структуре и функционированию системы
Система должна быть построена по модульному принципу и включать следующие функциональные подсистемы:
Базовая подсистема.
Обеспечивает приём входящих событий, их предварительную обработку, нормализацию и маршрутизацию. Реализует единый пользовательский интерфейс, рабочие области операторов и администраторов, а также общий механизм аутентификации компонентов системы.
Подсистема хранения данных.
Предназначена для централизованного и защищённого хранения событий, инцидентов, документов, служебных журналов и результатов реагирования. Обеспечивает контроль целостности, резервное копирование, восстановление данных и применение сертифицированных механизмов защиты информации.
Подсистема авторизации.
Отвечает за идентификацию и аутентификацию пользователей, управление ролями и правами доступа, контроль соблюдения политик безопасности, ведение журналов действий и обеспечение многофакторной аутентификации (MFA).
Подсистема работы с документами.
Обеспечивает создание, редактирование, хранение, версионирование и архивирование документов. Поддерживает формирование отчётных файлов и экспорт данных в форматы PDF, DOCX, XLSX.
Подсистема шаблонов.
Реализует механизмы подготовки, редактирования и исполнения сценариев обработки инцидентов. Поддерживает условия запуска, последовательности действий, правила эскалации и тестирование шаблонов в изолированной среде.
Система должна обеспечивать круглосуточный режим работы (24/7) с минимальными регламентными окнами обслуживания.
Архитектура должна поддерживать горизонтальное и вертикальное масштабирование всех компонент без необходимости остановки системы.
Взаимодействие между подсистемами должно выполняться через защищённые внутренние API с использованием структурированных форматов обмена данными (JSON, XML) и обязательным применением шифрования TLS 1.3.
3.1.2 Требования к показателям назначения
Пользовательский интерфейс системы должен обеспечивать высокую интерактивность и стабильную работу при стандартных и пиковых нагрузках:
Производительность интерфейса.
Время отклика интерфейса для 95% операций (открытие разделов, карточек инцидентов, фильтрация данных) – не более 2 секунд;
время генерации и загрузки сложных отчётов или сводных аналитических панелей – не более 10 секунд.
Пользовательская нагрузка.
Минимальное число одновременных активных пользователей – до 100 человек (операторы, администраторы, аналитики, руководители);
общее количество зарегистрированных учётных записей – не менее 1000.
Обработка событий и инцидентов.
Система должна устойчиво работать при поступлении:
до 800–1000 событий в секунду при штатной эксплуатации;
до 3000 событий в секунду при пиковых нагрузках.
При превышении нагрузки система обязана:
переводить входящие данные в защищённую очередь;
обрабатывать их по мере высвобождения ресурсов;
не допускать потери данных.
Регистрация и обработка инцидентов.
Система должна обеспечивать выполнение не менее 150-200 операций с инцидентами в секунду, включая:
создание новых записей;
изменение статусов;
добавление комментариев;
фиксацию результатов обработки;
закрытие инцидентов.
Требования к хранилищу данных.
Объём основной базы данных (инциденты, события, пользователи, документы) – не менее 5-10 ТБ;
файловое хранилище (журналы, вложения, отчёты, экспортируемые данные) – не менее 20-50 ТБ.
Масштабируемость.
Расширение дисковых массивов и увеличение производительности базы данных должно выполняться без остановки системы;
время выполнения административных операций по масштабированию – не более одного рабочего дня.