Перейти к основному содержимому

ПМИ по ГОСТ 19.301-79

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Руководителю Аналитику Техническому писателю
Теория данных (раздел 3)

ERD и словарь сущностей — Entity Relationship, нормализация, SQL. Карта — о разделе.

Программа и методика испытаний​

ПМИ (ГОСТ 19.301) описывает, как доказывают соответствие ТЗ — сценарии, среда, критерии, протоколы. Каждый важный пункт ТЗ должен иметь проверку в ПМИ (таблица трассировки) — иначе при сдаче спорят о формулировках, а не о фактах.

В рабочем проекте ПМИ отвечает на вопрос "как именно проверяем готовность" — кто запускает проверку, в каком окружении, каким инструментом и какой результат считается успешным.

ГОСТ

Основано на ГОСТ 19.301-79.

ПМИ - это документ, в котором написано, как будут проверять, работает ли программа так, как надо.

Что-то вроде инструкции для экзаменатора, который принимает у программистов экзамен перед сдачей заказчику.

Нужна, чтобы:

  • испытания были честными и воспроизводимыми;
  • заказчик и исполнитель говорили на одном языке;
  • в суде и перед проверяющими было что предъявить.

1. Краткий обзор стандарта ГОСТ 19.301-79​

1.1. Официальное название​

ГОСТ 19.301-79
Единая система программной документации
Программа и методика испытаний

1.2. Назначение документа​

Программа и методика испытаний (ПМИ) — это нормативно-технический документ, определяющий:

  • цели, задачи и объекты испытаний;
  • условия и порядок проведения испытаний;
  • методы, средства и критерии оценки результатов;
  • состав и порядок оформления отчётности.

📌 Ключевое отличие от "тест-плана" (IEEE 829, ISTQB):
ПМИ — юридически значимый документ, используемый в приёмке ПО в госсекторе, ОПК, АСУ ТП. Он регламентирует "как тестировать" и "как доказать соответствие требованиям" перед заказчиком/надзорным органом.

1.3. Область применения​

Стандарт применяется при разработке программных средств, включённых в состав:

  • автоматизированных систем управления (АСУ);
  • систем документооборота;
  • встраиваемых систем (в т.ч. критичных к безопасности);
  • программ для государственных информационных систем (ГИС), ЕГАИС, ЕГРН и пр.

✅ Современный контекст:
Даже в коммерческих IT-проектах ПМИ может требоваться, если:

  • продукт сертифицируется (ФСТЭК, ФСБ, Минцифры);
  • заключается госконтракт (44-ФЗ, 223-ФЗ);
  • используется в инфраструктуре критически важных объектов (КВО).

1.4. Структура документа по ГОСТ 19.301-79​

№Наименование разделаОбязательность
1Введение✓ (рекомендуется)
2Основание для разработки✓
3Назначение разработки✓
4Требования к программе (объекту испытаний)✓
5Требования к программной документации✓
6Технические требования✓
7Требования к технологичности✓
8Требования к программе испытаний✓
9Условия испытаний✓
10Методы и средства испытаний✓
11Состав и порядок выполнения испытаний✓
12Документация по результатам испытаний✓
13Технико-экономические показатели× (рекомендуется)
14Стадии и этапы испытаний✓ (часто объединяется с п.11)
15Порядок контроля и приёмки✓

⚠ Важно:

  • Разделы 2–12 и 14–15 — обязательные согласно п. 2.1 ГОСТ.
  • Раздел 13 — необязательный, но часто включается в госзаказах.
  • Пункты могут группироваться (например, "Технические требования" = совокупность требований из ТЗ, СТО, ГОСТ).

2. Пошаговое руководство по составлению ПМИ​

Ниже — практическая последовательность действий, рекомендованная для подготовки документа, совместимого с ГОСТ 19.301 и пригодного для аудита.

Шаг 1. Подготовка исходных материалов​

Перед началом написания ПМИ необходимо собрать:

ДокументЗачем нужен
Техническое задание (ТЗ) по ГОСТ 19.201Источник требований к функциональности и ограничениям
Спецификация программного обеспечения (СП) по ГОСТ 19.202Детализация архитектуры, интерфейсов, данных
Описание применения (ОП) по ГОСТ 19.502Сценарии использования — основа для тестовых кейсов
Документы по стандартизации (ГОСТ, ОСТ, СТО, ТУ)Источник требований к надёжности, безопасности и т.п.
План качества (QA Plan)Для согласования метрик дефектов, покрытия, SLA

🔍 Совет: Используйте traceability matrix (таблицу трассировки требований), чтобы не упустить ни одного пункта из ТЗ.

Шаг 2. Формирование структуры документа​

Создайте каркас документа по приведённой выше таблице. Рекомендуется использовать шаблон в Confluence / Word с автоматической нумерацией и стилями.

🛠 Инструментарий:

  • Docusaurus + remark-gfm — для Markdown-публикаций (как в IT Universe);
  • Sphinx + sphinxcontrib-gost — для официальных сборок в PDF;
  • PlantUML / Mermaid — для диаграмм этапов испытаний;
  • ReqIF / Polarion — для управления требованиями (если проект крупный).

Шаг 3. Заполнение обязательных разделов​

✅ Раздел 2. Основание для разработки​

Укажите:

  • номер и дату договора/заказа;
  • ссылки на распоряжения, приказы, протоколы;
  • наименование заказчика и разработчика.

📝 Пример:
"Разработка ПМИ производится в соответствии с договором № 45-П/2025 от 05.03.2025 между АО „Информтех“ (заказчик) и ООО „60 имён“ (исполнитель), на основании технического задания ТЗ-2025-ИТ-018."

✅ Раздел 3. Назначение разработки​

Кратко опишите:

  • для чего создаётся ПО;
  • какие задачи решает;
  • кто является конечным пользователем.

📝 Пример:
"Система „Xenon“ предназначена для автоматизации учёта лабораторных исследований в клинических центрах. Целевая аудитория — лаборанты, врачи-исследователи, администраторы ЛИС."

✅ Раздел 4–6. Требования к программе и документации​

Сведите в таблицы:

ID требования (из ТЗ)КатегорияТекст требованияИсточникПроверяемость
F-101ФункциональноеСистема должна позволять вводить результаты анализа крови в течение ≤ 2 сТЗ, п. 4.2.1Да (time-tracking)
SEC-07БезопасностьВсе данные передаются по TLS 1.3+; аутентификация по ГОСТ Р 34.10-2012ТЗ, п. 8.3; СТО-12-2024Да (Wireshark + сертификаты)

🔒 Важно:
Требования должны быть SMART:

  • Specific — конкретные, без "взаимодействует с другими системами" → "осуществляет обмен по REST API (POST /v1/results) в формате JSON, совместимом со схемой XSD-2024";
  • Measurable — измеримые (время, объём, частота);
  • Achievable — достижимые при имеющихся ресурсах;
  • Relevant — привязанные к бизнес-цели;
  • Testable — проверяемые без субъективных интерпретаций.

✅ Раздел 8. Требования к программе испытаний​

Определяет критерии допуска к испытаниям и критерии завершения:

КритерийУсловиеОтветственный
Допуск к этапу "Приёмочные испытания"- Пройдены все модульные и интеграционные тесты (покрытие ≥ 85%) - Устранены все блокирующие (Blocker) и критические (Critical) дефекты - Утверждена документация пользователюТехлид / QA-менеджер
Завершение испытаний- Выполнены 100% тестовых сценариев - Не выявлено дефектов Severity ≥ Major - Подписан акт приёмкиЗаказчик + Представитель НИИ

✅ Раздел 9. Условия испытаний​

Опишите:

  • Аппаратные требования:
  - Сервер: 4 ядра CPU (Intel Xeon E-2334), 32 ГБ RAM, 500 ГБ SSD (RAID-1)
  - Клиент: Windows 10/11, Chrome ≥ v115, разрешение ≥ 1920×1080
  • Программные требования:
  - ОС: Ubuntu 22.04 LTS (сервер), Windows 10 21H2 (клиент)
  - СУБД: PostgreSQL 14.5 + PostGIS 3.3
  - Среда: .NET 6.0, Node.js 18.x LTS
  • Окружение:
    • Стенд должен быть изолирован от Интернета (кроме доступа к ГИС через шлюз);
    • Используется тестовая БД, идентичная prod-схеме (без персональных данных);
    • Наличие лицензий: BPM-система, Keycloak (Open Source).

🌐 Современный подход:
Для CI/CD используйте docker-compose.yml как неотъемлемую часть ПМИ — это обеспечивает воспроизводимость.

Пример фрагмента:

Код ITЗагрузка примера кода…

✅ Раздел 10. Методы и средства испытаний​

Классифицируйте по типам:

Тип испытанияМетодСредствоАвтоматизация
ФункциональноеЧёрный ящик (use-case testing)Postman + Newman, Selenium✅ (70% сценариев)
НагрузочноеСтресс-тестирование (step-up)k6, Grafana + Prometheus✅
БезопасностьСтатический анализ + fuzzingSonarQube, OWASP ZAP✅ (частично)
ЮзабилитиОценка по ISO 9241-11Наблюдение + опросник SUS❌
СовместимостьКросс-платформенное тестированиеBrowserStack, Sauce Labs✅ (mobile)

📊 Метрики качества (включить в ПМИ):

  • Покрытие кода (line/branch): ≥ 80% (unit), ≥ 60% (E2E);
  • Время отклика: ≤ 1.5 с (95-й перцентиль);
  • MTBF ≥ 500 ч;
  • Количество дефектов на KLOC ≤ 0.5.

✅ Раздел 11. Состав и порядок выполнения испытаний​

Представьте как поэтапный план:

ЭтапНаименованиеДлительностьУчастникиРезультат
IПодготовка стенда2 дняDevOps, QAУтверждённый docker-compose.test.yml, тестовые данные
IIМодульное тестирование5 днейРазработчикиОтчёт unit-report.html, покрытие ≥ 85%
IIIИнтеграционное тестирование4 дняQA, BackendОтчёт int-test.log, API-контракты валидированы
IVПриёмочное тестирование3 дняЗаказчик, ТестировщикиАкт приёмки (форма ПМИ-Акт-01)
VИспытания на совместимость2 дняQA, Внешние экспертыПротокол совместимости с ЛИС "Арго"

💡 Совет: Используйте диаграмму Ганта (в Mermaid):

✅ Раздел 12. Документация по результатам испытаний​

Перечень форм:

  • Форма ПМИ-Отч-01 — Протокол испытаний (на каждый этап);
  • Форма ПМИ-Акт-01 — Акт приёмки (по ГОСТ 19.104);
  • Форма ПМИ-Деф-01 — Журнал дефектов (с кодом, severity, статусом);
  • Форма ПМИ-Метр-01 — Сводная таблица метрик качества.

📁 Структура архива отчётов (рекомендуется):

/xenon_pmi_results/
├── 01_setup/
│   ├── docker-compose.test.yml
│   └── test_data_sample.csv
├── 02_unit/
│   ├── coverage.xml
│   └── unit-report.html
├── 03_integration/
│   ├── api-contract-validation.json
│   └── postman_collection_run.json
└── final/
    ├── PMI_AKT_01_signed.pdf
    └── defects_log_20251130.xlsx

Шаг 4. Согласование и утверждение​

  • ПМИ проходит внутреннюю экспертизу (тест-менеджер, архитектор, юрист по compliance);
  • Затем — внешнее согласование с заказчиком (часто — по форме рецензии);
  • Утверждается приказом руководителя или протоколом приёмочной комиссии.

⚖️ Юридический нюанс:
В госконтрактах ПМИ является неотъемлемым приложением к ТЗ. Изменение ПМИ после утверждения требует дополнительного соглашения.

3. Типичные ошибки и как их избежать​

ОшибкаПоследствияКак избежать
❌ Неуказание критериев прохождения тест-кейса ("должно работать")Споры при приёмке, "договорняки"Каждый тест-кейс — с ожидаемым результатом в цифрах: "время ≤ 1.2 с", "ошибка 500 — не допускается"
❌ Отсутствие traceability к ТЗНевозможно доказать соответствиеИспользуйте ID-теги (REQ-AUTH-04) и таблицу трассировки
❌ Описание методов без указания версий средств ("тестировали в Postman")НевоспроизводимостьУказывайте: Postman v10.18.5 (Desktop), Newman v6.2.1, node v18.17.1
❌ Игнорирование нефункциональных требованийРиск отказа на приёмке (особенно в госсекторе)Выделите отдельные подразделы: Надёжность, Безопасность, Эргономика — и привяжите к ГОСТ (напр., ГОСТ Р ИСО/МЭК 25010)
❌ ПМИ составлена после начала разработкиРиск непроверяемых требованийПМИ должна быть готова до старта coding phase — это часть плана качества (QA Plan)
❌ Использование "плавающих" сроков ("примерно 3 дня")Нарушение графика, штрафыУказывайте даты с привязкой к календарю и резервом на ретест (±20%)

🛑 Красный флаг в аудите:
Фраза "тестирование будет проведено в соответствии с утверждённым планом" без приложения самого плана — грубое нарушение ГОСТ 19.301, п. 2.3.

4. Пример — вымышленная система "Xenon — Лабораторная Информационная Система"​

Система предназначена для автоматизации учёта биоматериалов, назначений и результатов анализов в сети клиник "МедСтандарт".
Технологический стек — BPM, PostgreSQL 15, React + TypeScript, Keycloak для SSO.

Ниже — фрагменты реального ПМИ-документа (заполненный пример). Полный документ занимал бы ~40 страниц — здесь приведены ключевые части.

📄 Раздел 2. Основание для разработки​

Разработка Программы и методики испытаний системы "Xenon" осуществляется в соответствии с:

  • Договором № МС-2025/ИТ-44 от 10.10.2025 между ООО "МедСтандарт" (заказчик) и ООО "60 имён" (исполнитель);
  • Техническим заданием ТЗ-ЛИС-2025-Р1, утверждённым протоколом № 7 от 12.10.2025;
  • Требованиями к информационной безопасности, установленными СТО МС-001-2024.

📄 Раздел 4. Требования к программе (фрагмент таблицы)​

IDТребованиеКатегорияПроверяемость
F-203Система должна генерировать PDF-отчёт по результатам анализа с логотипом клиники, ФИО врача и электронной подписью (ЭП) в формате CAdES-BES по ГОСТ Р 34.10-2012ФункциональноеАвтоматизированный тест: сравнение хэша PDF с эталоном (SHA-256), проверка наличия подписи через КриптоПро CSP
NFR-SEC-11Время блокировки аккаунта после 3 неудачных попыток входа — не более 15 секундБезопасностьЗамер через curl + таймер; логи Keycloak (events.log)
NFR-PERF-05Среднее время формирования отчёта по 100 пробиркам — ≤ 3.0 с (на стенде Spec-B)Производительностьk6-скрипт: xenon_perf_report.js; метрика: p(95) < 3.0s

📄 Раздел 10. Методы и средства испытаний (фрагмент)​

10.1. Функциональное тестирование​

  • Метод: Сценарное тестирование на основе use-case из Описания применения (ОП-ЛИС-01).
  • Средства:
    • Postman Collection v3.2 (с переменными окружения {{env}} = test);
    • Newman CLI v6.2.1 + --reporters cli,junit;
    • Test Runner (встроенный в платформу).
  • Критерий прохождения:

    100% тест-кейсов в коллекции "Xenon_Functional_v4.postman_collection.json" завершились со статусом 2xx и валидным JSON-ответом (schema validation via AJV).

10.2. Тестирование ЭП (электронной подписи)​

  • Метод: White-box + black-box; сравнение с эталонной подписью, сгенерированной КриптоПро CSP 5.0.
  • Средства:
    • КриптоПро CSP 5.0 R5 (лицензия № CP-7788-2025);
    • Утилита cpverify.exe для валидации CAdES;
    • Python-скрипт ep_validator.py (см. Приложение Б).
  • Образец кода валидации:

Код ITЗагрузка примера кода…

📄 Раздел 11. Порядок выполнения испытаний (фрагмент протокола)​

№Наименование испытанияДатаРезультатПодпись
3.7Формирование PDF-отчёта с ЭП (сценарий F-203)2025-11-28✅ Пройден: хэш совпадает (SHA256: a1b2…f9), подпись валидна (cpverify OK)Тагиров Т.В.
3.8Блокировка аккаунта после 3х попыток (NFR-SEC-11)2025-11-28⚠ Частично: время блокировки — 16.2 с (требуется ≤15.0 с). Дефект DEF-2025-SEC-45 заведён.Петров А.С.

📄 Раздел 12. Акт приёмки (фрагмент формы ПМИ-Акт-01)​

Акт приёмки результатов испытаний
Система: Xenon v1.2.0
Дата испытаний: 15–28 ноября 2025 г.
Стенд: Тестовый стенд Spec-B (см. Приложение А)

Комиссия установила:

  • Выполнено 142 из 145 функциональных тест-кейсов;
  • 3 дефекта категории Major устранены в течение 48 ч;
  • Все нефункциональные требования выполнены (см. Приложение В — метрики);
  • Документация соответствует ТЗ и ГОСТ 19.100–19.521.

Решение комиссии:
Система Xenon рекомендована к приёмке.

Председатель комиссии: ___________ / Иванов И.И. /
Представитель заказчика: ___________ / Сидорова О.В. /
Представитель разработчика: ___________ / Тагиров Т.В. /

6. После испытаний — сертификация и приёмка​

ПМИ описывает как проверить продукт. Приёмка — организационный и юридический финал — комиссия, протоколы, акт; в ряде отраслей — сертификация по регламенту (ФСТЭК, медицина, ОПК).

ЭтапЧто фиксируется
Испытания по ПМИПротоколы, дефекты, метрики NFR
Удостоверение качестваОтчёты, traceability к ТЗ, ISO/IEC 25010
ПриёмкаАкт комиссии, решение заказчика
Сертификация (при необходимости)Независимая оценка → сертификат

Подробный разбор отличий "испытания / удостоверение / сертификация", CMMI, ISO 9001 и образца акта — Сертификация и приёмка заказных продуктов. Версии ПМИ, стендов и скриптов на приёмке — управление конфигурацией.

5. Проверочный чек-лист по заполнению ПМИ​

✅ Используйте этот список до отправки на согласование.

№Пункт проверкиДа/НетКомментарий
1Все разделы 2–12, 14–15 присутствуют?☐
2Каждое требование из ТЗ имеет уникальный ID и отражено в ПМИ?☐Проверьте traceability matrix
3Для каждого испытания указаны: метод, средство, критерий прохождения?☐Должно быть измеримо!
4Указаны точные версии ПО/ОС/средств тестирования?☐Postman v10.18.5, не "Postman"
5Есть ссылки на приложения (стенд, скрипты, схемы)?☐Приложения — часть документа
6Критерии допуска и завершения сформулированы однозначно?☐Нет "и т.д.", "по усмотрению"
7Указаны ответственные за каждый этап?☐ФИО + должность/роль
8Есть дата утверждения и подпись руководителя?☐Без неё — не документ
9Все формы (акты, протоколы) соответствуют приложениям ГОСТ?☐Сверьтесь с Приложением 1 ГОСТ 19.301
10Документ прошёл внутреннюю экспертизу (QA, Безопасность, Compliance)?☐Обязательно до заказчика

🟢 Если все пункты — "Да", документ готов к согласованию.

Дополнение — как сделать ПМИ рабочим документом​

Короткая матрица трассировки​

ID требованияПункт ТЗТест-кейсКритерий прохождения
REQ-AUTH-014.1.2TC-AUTH-001Токен валиден, код 200
REQ-PERF-034.2.4TC-PERF-014P95 <= 1.5s

Даже короткая таблица снимает споры на приемке и фиксирует связь с требованиями.

Что полезно добавить в ПМИ​

  • перечень тестовых данных с владельцем и датой обновления;
  • правила повторного запуска проваленных сценариев;
  • шаблон дефекта с полями "шаги", "фактический результат", "ожидаемый результат".

Внутренние ссылки​

Содержание