О методах тестирования программ отладки систем управления технологическими процессами

Основные концепции тестирования систем управления технологическими процессами. В качестве основных концепций тестирования выдвигаются полнота, надежность и действенность (обосно­ванность). Тест является полным, если положительные результаты его применения гарантируют отсутствие ошибок в тестируемой программе для всего набора ее входных данных. Надежный тест должен обеспечивать регулярность в обнаружении ошибок систем управления технологическими процессами. Тест является обоснованным, если каждая ошибка в программе обнаруживается посредством этого теста. Если тест является полным, надежным, обоснованным и результаты его приме­нения положительны, то тестируемая программа является корректной. Методы тестирования, основанные на прохождении всех операторов про­граммы, неадекватны методам, основанным на прохождении всех контроль­ных путей.

Один из подходов генерирования входных тестовых данных систем управления технологическими процессами основан на разбиении программы на стандартные классы путей. Класс путей назы­вается реализуемым, если существует набор входных данных, вызывающий прохождение какого-либо из путей, принадлежащих классу. Полная система тестов в данном случае содержит по одному тесту на каждый из реализуе­мых классов путей.

Методика построения такой системы тестов систем управления технологическими процессами состоит в следующем:

• на основе анализа программы выделяют классы программных путей;
• строят описание тестовых данных, обеспечивающих прохождение пу­тей из данных классов;
• преобразовывают не доопределённые на предыдущем этапе описания входных наборов в определенную форму;
• доопределяют те наборы, которые не удалось доопределить на предыду­щем этапе;
• вырабатывают входные значения, удовлетворяющие окончательному описанию входных наборов.

После определения наиболее полный набор тестовых данных программы сопоставляют с набором функциональных спецификаций программы систем управления технологическими процессами. Воз­можны следующие результаты сопоставления:

• если набор функциональных тестовых данных соответствует набору функциональных спецификаций, то программа будет практически проверена;
• если существует функциональное тестовое данное, для которого нет соответствующего функционального требования, то существует код, который может привести к ошибке;
• если существует некоторая функциональная спецификация, для кото­рой не существуют тестовые данные, то ПО программируемых логических контроллеров (ПЛК) имеет недостаток в каком-либо варианте.

Восходящее тестирование систем управления технологическими процессами (снизу—вверх). Так названа классическая схема тестирования программ, состоящая из трех этапов: тестирования модулей, тестирования подсистем и тестирования системы.

Тестирование модулей или автономная проверка подразумевает проверку модуля при отсутствии других модулей системы. При восходящем тестировании полная и тщательная проверка моду­лей является ключом к успеху. На этом уровне выявляются ошибки кодирования.

Тестирование подсистем заключается в проверке сопря­жения между различными модулями программы. На этом этапе обнаружи­вают логические ошибки и ошибки сопряжения.

Тестирование системы- это проверка системы в целом. На этом этапе выявляют наиболее тонкие ошибки: сопряжения; сложные-управления и логики; восстановления; быстродействия и емкости; временные.

После проверки системы в искусственных условиях необходима проверка в реальных промышленных условиях, для этого проводятся приемосдаточные или эксплуатационные испытания.

Нисходящее тестирование систем автоматизации. При этом подходе к тестированию программы приступают еще до того, как завершено проектирование. Основная идея нисходящего тестирования базируется на нисходящей схеме в согласии с нисходящим проектированием и кодированием. При этом вначале тестируют модуль главной программы и модули одного или двух более низких уровней. После достаточных испытаний и убеждения правильности реализации основных интерфейсов присоединяют сле­дующие уровни логической структуры программы. При попол­нении самым нижним уровнем задача тестирования оказывается эффективно решенной, т. е. на этой стадии не требуется тестирования всей системы.

Фиктивные модули, используемые при описываемом подходе, можно представлять одним из следующих способов: прямой передачи управления на выход из модуля; выдачи постоянного значения выходных данных; вы­дачи случайного значения выходных данных; печати отладочного сообщения о получении модулем управления; упрощения окончательной версии модуля.

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

Нисходящее тестирование обладает рядом преимуществ перед класси­ческим, так как благодаря первоочередному испытанию основных интер­фейсов, серьезные ошибки выявляются уже на ранних стадиях, поскольку обеспечивается реальная тестовая обстановка испытаний модулей более низких уровней. Кроме того, появляется возможность ознакомить заказ­чика с предварительной версией системы уже на ранней стадии разработки (еще до окончания проекта появляется возможность завершений некоторой, допускающей независимое использование части программного обеспече­ния). Существенно разгружаются и пиковые нагрузки на вычислительные центры и полигоны, на которых происходит отработка программных средств в силу равномерного распределения затрат машинного времени на протяжении всей разработки.

Другие методы повышения надежности систем автоматизации.

Избыточное програм­мирование автоматизированных систем основано на том, что для конкретного приложения неза­висимо разрабатывают две (и более) программы.

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

Моделирование системы до ее практической реализации позволяет выявить ошибки быстродействия и емкости. При этом важную роль играет имитационное моделирование, при котором имитационные входные сигналы и данные используются для тестирования реальной системы.

Математическое моделирование автоматизированных систем надежности программ применяют для количественной оценки надежности программного обеспечения. На основе статистических данных, собираемых в процессе тестирования, надежностная модель должна позволить предсказать с достаточной вероятностью следующее:

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

Метод независимого тестирования и анализа автоматизированных систем. Основным фактором этого метода является независимость выполнения функций анализа и тестирования ПО программируемых логических контроллеров (ПЛК). Суть метода заключается в том, что эти функции выполняет коллектив, единственной целью которого является обнаружение ошибок в создаваемом ПО, при этом ответственности за разработку коллектив не несет.

Метод независимого тестирования и анализа автоматизированных систем (НТА) дает наибольший эффект при использовании на всех этапах разработки. С точки зрения разработки процесс создания ПО программируемых логических контроллеров (ПЛК) является последовательным с частыми итерационными петлями между смежными этапами. Посторонний специалист, выбранный для независимого тестирования, не включен в эту цепь событий. Он анализирует выход каждой фазы на соответствие входным требованиям, т. е. соответствие структурных схем спецификациям, программ на машинном языке (или языке, с которого на выбранной для реализации промышленным компьютером есть транслятор) структурным схемам и т. п.; выполняет эти функции для всех этапов по мере их окончания и появления соответствующих документов с и единственной целью — обнаружение ошибок. При этом могут быть найдены ошибки, с трудом обнаруживаемые при обычном тестировании, осуществляемом авторами разработки. Ошибки, обнаруженные при независимом анализе, разделяют на катастрофические, серьезные, средние и тривиальные. При этом катастрофическими считают ошибки, приводящие к прекращению вы­полнения программы; серьезными — ошибки, которые нарушают выполнение существенного влияния на выполнение программы, и, наконец, тривиальные ошибки не отражаются на выполнении, например, несоответствие структурной схемы языковой записи программы, хотя последняя верна.

Многие ошибки, рассматриваемые как тривиальные, при их не обнаружении на ранних стадиях проектирования автоматизированных систем могут приводить в дальнейшем к серьезным последствиям. Тривиальными эти ошибки считаются из-за легкости исправления.  Нижняя часть таблицы демонстрирует перераспределение 1202 «оставленных» ошибок после завершения всех стадий проектирования. Число три­виальных ошибок уменьшилось до 408 за счет перевода в более серьезные категории. 31 % нетривиальных ошибок был допущен в спецификациях. Тот факт, что при анализе спецификаций разработчики не обнаружили ошибок, подтверждает плодотворность метода НТА. Очевидно, что исправление ошибки, допущенной в спецификациях по отношению к требованиям, предъявляемым к системе, стоит тем меньше, чем раньше она обнаружена. По этой причине независимый анализ следует начинать на ранних стадиях проектирования (по крайней мере до начала коди­рования.

Атмосфера соревнования, устанавливаемая при использовании метода НТА, обеспечение более высокого уровня проверки специализированными коллективами, оснащенными современными методами и средствами проверки ПО, независимость их работы от сроков разработки — все эти преимущества делают метод НТА (несмотря на определенное повышение стоимости разра­ботки, так как затраты на НТА составляют от 30 до 60 % стоимости разработ­ки) эффективным средством повышения надежности ПО.