Тестування критично важливих систем C2: стратегії QA для оборонного ПЗ

Тестування системи C2 принципово відрізняється від тестування комерційного ПЗ. У комерційному ПЗ відмова означає погіршення UX або втрату даних. У системі C2 відмова під час живої операції може означати, що оператори втрачають видимість дружніх сил у критичний момент, вогневе завдання передається не тому підрозділу, або звіт про втрати затримується через перевантаження шини повідомлень. Стратегія тестування повинна відображати цей оперативний контекст.

QA оборонного ПЗ для систем C2 ЗСУ охоплює п'ять категорій: юніт- та інтеграційне тестування окремих компонентів, системне тестування інтегрованої платформи, тестування продуктивності під оперативним навантаженням, тестування стійкості в деградованих умовах та приймальне тестування за вимогами.

Юніт- та інтеграційне тестування компонентів C2

Юніт-тестування для компонентів C2 слідує стандартним практикам — ізолювати кожен компонент, мокувати зовнішні залежності, верифікувати поведінку проти специфікації. C2-специфічна проблема полягає в тому, що багато компонентів взаємодіють з чутливими до часу зовнішніми даними: GPS-позиціями, радіоповідомленнями, потоками з датчиків. Тестові фікстури повинні генерувати реалістичні часові ряди з відповідними частотами оновлення, форматами міток часу та структурами повідомлень.

Парсери CoT-повідомлень, наприклад, вимагають тестових фікстур, що охоплюють весь діапазон типів подій, деформований XML, відсутні обов'язкові атрибути та застарілі мітки часу. Парсер, що мовчазно відкидає деформовані повідомлення, функціонально правильний в ізоляції, але оперативно небезпечний: позиція дружніх сил може тихо зникнути з COP без жодного сповіщення оператору.

Інтеграційне тестування перевіряє, що компоненти правильно функціонують у зв'язку. Критичні точки інтеграції в системі C2 ЗСУ: конвеєр прийому даних (датчик → брокер повідомлень → сховище треків), шлях реального часу (сховище треків → WebSocket → рендерер карти) та командний шлях (дія оператора → командний сервіс → зовнішня система).

Тестування продуктивності: пропускна здатність треків, FPS та затримка повідомлень

Тестування продуктивності для системи C2 визначає конкретні кількісні порогові значення — не «система повинна бути швидкою», а «система повинна підтримувати ≥30 FPS на картографічному дисплеї при 2 000 одночасних треків, що оновлюються з частотою 0,1 Гц кожен, із затримкою оновлення позиції від джерела даних до картографічного дисплея ≤500 мс на 95-му перцентилі.»

Пропускна здатність треків. Максимальна кількість треків, яку система може прийняти та обробити на секунду без накопичення черг. Вимірюється шляхом ін'єкції CoT-повідомлень зі зростаючою швидкістю до моменту, коли внутрішні черги системи починають рости необмежено. Для системи рівня бригади ЗСУ пропускна здатність треків повинна перевищувати 200 оновлень/секунду.

FPS рендерингу карти. Кадрів на секунду на картографічному дисплеї при максимальній кількості оперативних треків. Вимірюється за допомогою API продуктивності браузера з синтетичним генератором треків, що штовхає оновлення позицій через WebSocket. Ціль: ≥30 FPS при максимальній оперативній кількості треків.

Наскрізна затримка. Час від оновлення позиції, що входить у систему, до відображення оновленої позиції на дисплеї оператора. Вимірюється шляхом ін'єкції тестових повідомлень з мітками часу та порівняння мітки часу ін'єкції з міткою часу рендерингу. Ціль: ≤500 мс на 95-му перцентилі при нормальному навантаженні.

Час оберту команди. Час від подачі команди оператором до появи підтвердження в системі. Ціль: ≤2 секунди на 95-му перцентилі.

Chaos Engineering для деградованих мережевих умов

Системи C2 ЗСУ функціонують у оспорюваних електромагнітних середовищах, де мережева з'єднуваність переривчаста, пропускна здатність обмежена, а втрата пакетів є нормальною. Тестування лише в ідеальних мережевих умовах виробляє ПЗ, що працює в казармах, але відмовляє в полі.

Втрата мережевих пакетів (10–40%). При 30% втраті пакетів перевірте, що: картографічний дисплей продовжує оновлюватись (зі збільшеною затримкою), система не зависає, та застарілі треки правильно закінчуються, а не зберігаються як трек-примари, коли оновлення перестають надходити.

Розділення мережі (повне відключення на 30–300 секунд). Коли розділення мережі відновлюється, система повинна звірити свій стан треків з поточним станом з вищих джерел даних. Перевірте, що: повторне з'єднання є автоматичним, треки, що зникли під час розділення, закінчуються, а стан треків після відновлення з'єднання відповідає авторитетному стану вищого рівня протягом одного циклу оновлення.

Відмова вузла (вбивство екземпляра сервісу). У кластерному розгортанні вбивство вузла застосунку не повинно призводити до видимого відключення з точки зору оператора. Перевірки стану Kubernetes та маршрутизація сервісної сітки повинні перенаправляти трафік на справні вузли протягом 5 секунд.

Спуфінг GPS / пошкодження позиційних даних. Ін'єкція треків з неправдоподібними позиціями або швидкостями. Рівень валідації треків повинен виявити та відфільтрувати їх, реєструючи аномалії для перевірки безпеки.

Red Team тестування безпеки

Red team тестування — структуроване змагальне тестування, де окрема команда намагається скомпрометувати систему — необхідне для систем C2 ЗСУ перед оперативним розгортанням. Red team цілює:

Обхід автентифікації. Спроба доступу до API-ендпоінтів без валідних токенів, з простроченими токенами або токенами, виданими неавторизованим провайдером ідентичності.

Підвищення привілеїв. Автентифікація як низькопривілейований користувач та спроба доступу до ресурсів, що вимагають вищих рівнів допуску. Тестування рівня застосування політики ABAC на прогалини.

Шляхи ексфільтрації даних. Спроба вилучення секретних даних треків через функції експорту звітів, пагінацію API або повідомлення про помилки, що ненавмисно повертають дані, до яких абонент не авторизований.

Атаки ін'єкцією. SQL-ін'єкція через параметри фільтра, командна ін'єкція через поля оперативних даних та CoT XML-ін'єкція через деформовані повідомлення подій.

Тестування відповідності STANAG

Системи C2, інтегровані в навчання НАТО або багатонаціональні програми, повинні відповідати відповідним STANAG (угодам про стандартизацію). Найбільш релевантні для тактичної сумісності C2:

STANAG 5522 визначає протокол обміну повідомленнями для тактичного каналу передачі даних Link 16. Системи C2, що відображають треки Link 16, повинні правильно декодувати J-серійні повідомлення.

STANAG 4677 охоплює NFFI (NATO Friendly Force Information) — стандарт обміну позицією підрозділів НАТО через національні кордони. Тестування відповідності NFFI верифікує правильне форматування звітів про позицію та стабільність ідентифікаторів треків.

APP-6 (Військові символи НАТО) тестування відповідності перевіряє, що картографічний дисплей правильно рендерить символи військових підрозділів відповідно до APP-6D з правильними кольорами приналежності, позначками ешелону та полями модифікаторів.

Приймальне тестування в польових умовах

Польове приймальне тестування є фінальною верифікацією перед оперативним розгортанням. Воно відбувається в середовищі, що наближається до оперативного — польові навчання з реальними радіомережами, реальними GPS-приймачами та реальними операторами, що виконують репрезентативні завдання.

План приймального тестування визначає конкретні сценарії: рух на рівні роти з 20 пішими солдатами з ATAK, вогневе завдання від запиту до виконання з повним трасуванням повідомлень, сценарій з деградованими комунікаціями, де батальйонний TAK-сервер втрачає з'єднання з бригадою на 10 хвилин. Кожен сценарій має визначені критерії прийнятності.