meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
blog:2022:12:20 [2022/12/20 17:48] – created mchusblog:2022:12:20 [2022/12/20 20:07] (current) – mchus
Line 1: Line 1:
 ====== 2022-12-20 ====== ====== 2022-12-20 ======
 +Я знаю 4 подхода к составлению программы и методики тестирования программно-аппаратных комплексов: 
 +  - "Зеленые лампочки" - методика которая включает в себя только проверку индикации на оборудовании и индикации в интерфейсе ПО или управления. Для солидности в такое ПМИ можно добавить испытание вида "проверить что все оборудование смонтировано с использованием штатного крепежа" и "каждое устройство, оснащенное двумя блоками питания должно быть подключено к двум разным модулям распределения питания". Данный подход отлично подходит для проектов где необходимо сдать легко и быстро и особенные, какие то проверки не требуются. Подходит либо когда сдаётся только одна подсистема или для автономных испытаний. 
 +  - "ПМИ по ТЗ" - метод которому меня научил Центробанк. Каждому пункту технического задания должно быть подготовленно испытание. Это отличный метод, которым я до сих пор стараюсь пользоваться. В начале документа вставляется таблица, включающая столбец с требованием ТЗ и столбец с соответствующей методикой проверки. Каждому функциональному пункту технического задания должна соответствовать методика, которая позволяет проверить данный функционал. Например требование "возможность одновременного функционирования нескольких виртуальных машин на одном физическом сервере" проверяется заданием "создание виртуальной машины" и заданием "клонирование виртуальной машины". Данный подход отлично работает если техническое задание в проекте является важным документом, к созданию которого заказчик приложил непосредственное участие. Но иногда можно столкнуться с отношением "показывайте все что я хочу, мне плевать на ТЗ вы его сами написали".  
 +  - "ПМИ с подвохом" - заказчик хорошо знаком с внедряемой системой и имеет опыт эксплуатации её на других своих объектах и требует включения проверки функционала настройка которого не требуется в ТЗ. Цель включения таких испытаний кроется в желании заказчика увидеть систему удовлетворяющую его представлению о целевой конфигурации а не полное соответствие проекту. 
 +  - "ПМИ для обучения" - новый для меня интересный подход. Суть состоит в следующем: Премо-сдаточные испытания должны не только послужить основанием для принятия системы заказчиком но и демонстрацией работы, обучения базовым навыкам администрирования системы. В данном режиме критично чтобы заказчик сам выполнял подготовленные испытания и таким образом получил базовые навыки работе с системой. Данный подход наверняка будет самым объемным потому что включает в себя основные задачи администрирования, которые не всегда можно связать с техническим заданием. При возникновении неисправностей подрядчик должен суметь устранить их на месте или снизить их влияние на прохождение следующих заданий, поэтому сильно откланяться от текста испытаний не стоит. Данное испытание возможно должно готовиться как учебно-методический материал.