Преподаватель который помогает студентам и школьникам в учёбе.

Отладка и тестирование программ: основные подходы и ограничения (Практический аспект отладки АСУ ТП)

Содержание:

Введение

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

Традиционно в жизненном цикле принято выделять следующие этапы: 1) анализ; 2) проектирование; 3) программирование или, иначе говоря, кодирование функциональных модулей; 4)тестирование и отладка; 5)эксплуатация и сопровождение.

Целью тестирования является обнаружение ошибок в программе. В тестирование входят следующие этапы:

а) постановка задачи для теста,

б) проектирование тестов,

в) написание тестов,

г) тестирование тестов,

д) выполнение тестов,

е) изучение результатов тестирования.

Отладкой называется процесс выявления природы ошибки программы и исправления ошибок, после того, как ошибки были обнаружены в процессе тестирования.

Из всех этапов проектирования логики программных модулей этап отладки является наименее формализованным. В нем выделяют две задачи:

- определение природы ошибки;

- исправление ошибки.

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

Цель данной работы – изучить основные подходы и ограничения в отладке и тестировании программ.

C учетом поставленной цели будут решены следующие задачи:

- рассмотрено понятие и принципы тестирования;

- проанализирована стратегия и методы тестирования;

- проведен анализ принципов и видов отладки программного обеспечения, в т.ч. заповедей отладки;

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

Курсовая работа состоит из введения, трех глав, заключения и библиографии.

Глава 1. Понятие, стратегия и методы тестирования программ

1.1 Определение и принципы тестирования

Тестирование программного средства (ПС) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Тестирование программ является одной из составных частей более общего понятия - «отладка программ». Под отладкой понимается процесс, позволяющий получить программу, функционирующую с требующимися характеристиками в заданной области изменения входных данных.

Тестирование программ является одной из составных частей более общего понятия - «отладка программ»^[1]. Под отладкой понимается процесс, позволяющий получить программу, функционирующую с требующимися характеристиками в заданной области изменения входных данных.

Процесс отладки включает:

 - действия, которые направлены на цели выявить ошибки (т.е непосредственно тестирование);

-  диагностику и локализацию ошибок (т.е определение характера ошибок и их местонахождение);

-  внесение исправлений в программу для целей устранить выявленные ошибки ошибок.

Из вышеперечисленных видов работ самый трудозатратный и достаточно дорогой - тестирование, затраты на него могут приближаться к 45 % общих затрат на разработку программных средств.

Невозможно утверждать что в программе на 100% не будут присутствовать ошибки. Самое оптимальное – можно попробовать продемонстрировать наличие существующих ошибок. В случае когда программа правильно работает для большого набора тестов, то и значит что оснований гарантировать что ошибок здесь не будет, нет. В случае, если предполагать что комплекс конкретных тестов наделен возможностью максимально вероятно найти всевозможные ошибки, можно утверждать о каком-то некотором уже уровне надежности в том, что программа работает правильно.

Обозначим следующее высказывание: если ваша цель - показать отсутствие ошибок, вы их найдете не слишком много. Если же ваша цель - показать наличие ошибок, вы найдете значительную их часть.

Рассмотрим особенности тестирования программного средства^[2]:

-  отсутствие эталона (программы), которому должна соответствовать тестируемая программа;

- высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

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

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

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

2. Необходимой частью тестового набора данных должно быть описание предполагаемых значений результатов тестовых прогонов. Тестирование как процесс многократного выполнения программы проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных в результате очередного тестового прогона данных, необходимо знать ожидаемый результат. Таким образом, тестовый набор данных должен включать в себя два компонента: описание входных данных, описание точного и корректного результата, соответствующего набору входных данных. Этот принцип сложно, а в некоторых случаях и невозможно реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс этот трудоемкий даже для небольших программ, так как он требует ручных расчетов, следуя логике алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует придерживаться логически, вытекает следующий.

3. Необходимо изучить результаты каждого теста. Из практики следует, что значительная часть обнаруженных ошибок могла быть выявлена в результате первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа их результатов.

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

5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она того, чего не должна делать. Это утверждение логически вытекает из предыдущего. Необходимо любую программу проверить на нежелательные побочные эффекты.

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

1.2 Стратегия проектирования тестов

Рассмотрим два самых противоположных подхода к проектированию тестов.

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

Рис. 1. Взаимосвязь процессов проектирования и тестирования

При первом подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных. Следовательно, приходим к выводу, что для исчерпывающего тестирования программы требуется бесконечное число тестов, а значит, построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: во-первых, нельзя создать тест, гарантирующий отсутствие ошибок; во-вторых, разработка таких тестов противоречит экономическим требованиям. Поскольку исчерпывающее тестирование исключается, нашей целью должна стать максимизация результативности капиталовложений в тестирование (максимизация числа ошибок, обнаруживаемых одним тестом). Для этого необходимо рассматривать внутреннюю структуру программы и делать некоторые разумные, но, конечно, не обладающие полной гарантией достоверности предположения.

Сторонник второго подхода использует стратегию "белого ящика", или стратегию тестирования, управляемую логикой программы, которая позволяет исследовать внутреннюю структуру программы. В этом случае тестировщик получает тестовые данные путем анализа только логики программы; стремится, чтобы каждая команда была выполнена хотя бы один раз. При достаточной квалификации добивается, чтобы каждая команда условного перехода выполнялась бы в каждом направлении хотя бы один раз. Цикл должен выполняться один раз, ни разу, максимальное число раз. Цель тестирования всех путей извне также недостижима. В программе из двух последовательных циклов внутри каждого из них включено ветвление на десять путей, имеется 10¹⁸ путей расчета. Причем выполнение всех путей расчета не гарантирует выполнения всех спецификаций. Для справки: возраст Вселенной 10¹⁷с.

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

Последнее утверждение имеет два слабых пункта: во-первых, число не повторяющих друг друга маршрутов — астрономическое; во-вторых, даже если каждый маршрут может быть проверен, сама программа может содержать ошибки (например, некоторые маршруты пропущены).

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

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

1.3 Сравнение методов тестирования

Рассмотрим с позиций надежности программного обеспечении стратегии тестирования и сравним их по семи критериям (табл.1 ).

Таблица 1

Качественная оценка подхода к сборке

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

Итак. Первый критерий - время до момента сборки модулей, - это является важным при обнаружении ошибок в сопряжениях и предположениях модулей о свойствах друг друга.

Второй критерий - время до момента создания первых работающих «скелетных» версий программы, поскольку здесь могут проявиться главные дефекты проектирования.

Третий и четвертый критерии касаются вопроса о том, необходимы ли заглушки, драйверы и другие инструменты тестирования.

Пятый критерий - мера параллелизма, который возможен в начале или на ранних стадиях тестирования (но не концу цикла тестирования).

Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования.

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

Ранняя сборка и раннее получение работающего каркаса программы, а также возможность тестировать любые конкретные условия, представляются наиболее важными, им дается вес 3.

Сложность подготовки заглушек, планирования и управления последовательностью тестов также важны, они получают вес 2.

Третий критерий, необходимость драйверов - вес 1 ввиду доступности общих инструментов тестирования.

Критерий, связанный с параллелизмом работы, имеет вес 1 (он может быть важен по другим причинам, но на надежность сильно не влияет).

Шестой критерий - вес 3.

Седьмой критерий получает вес 2.

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

Таблица 2

Взвешенная оценка подхода к сборке

метод	восхо-дящий	нисхо-дящий	модифицированный нисходя-щий	метод боль-шого скачка	метод сандви-ча	модифицированный метод сандвича
сборка	рано+	рано+	рано+	поздно-	рано+	рано+
время до появления работающего варианта программы	поздно-	рано+	рано+	поздно-	рано+	рано+
нужны ли драйверы или готовые инструменты	да-	нет+	да-	да-	частично	да-
нужны ли заглушки	нет+	да-	да-	да-	частично	частично
параллелизм в начале работы	средний	слабый-	средний	высоки+й	средний	высокий+
возможность тестировать отдельные пути	легко+	трудно-	легко+	трудно-	средне	легко-
возможность планировать и контролировать последовательность	легко+	трудно-	трудно-	легко+	трудно-	трудно-

Глава 2. Понятие, методы, принципы и заповеди программ

2.1 Понятие и методы отладки программы

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

Гораздо сложнее отыскать ошибки, допущенные при составлении алгоритма, которые, в конечном итоге, приводят к неправильной работе программы: отсутствие результата, зацикливание, неверный результат. В этом случае полезен бывает пошаговый контроль выполнения программы.

Наиболее распространенными и наименее эффективными для отладки являются так называемые методы ‘грубой силы’. К ним относят:

1)отладку с использованием дампа памяти;

2)отладку с использованием операторов печати по всей программе;

3)отладку с использованием автоматических средств: наиболее предпочтительно.

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

1. Метод индукции: он включает

1)определение данных тестирования, имеющих отношение к ошибке;

2)анализ от частного к общему позволит выявить закономерности в данных пункта 1);

3)в результате анализа (п.2) выдвигается гипотеза о причине ошибки;

4)для подтверждения гипотезы 3 разрабатывается один или больше тестов, которые должны либо подтвердить, либо опровергнуть гипотезу;

5)если дополнительные тесты подтверждают гипотезу, можно приступать к исправлению ошибки, а вот если не подтверждают, то требуется в лучшем случае возврат к п.3, а в худшем - к п.2.

2.Альтернативный метод дедукции заключается в:

1)перечисление возможных причин или гипотез

2)использование данных тестирования для исключения некоторых возможных причин; 3)уточнение выбранной наиболее вероятной гипотезы, возможно с использованием дополнительных тестов;

4)доказательство выбранной гипотезы совпадает с п.4 и п.5 метода индукции.

2.2 Принципы отладки программного средства

Успешность отладки программного средства в немаловажной степени предопределена рациональной и правильной организацией тестирования.

В процессе отладки программного средства можно отыскать и устранить обычно ошибки, которые появляются в программном средстве при тестировании.^[3] Конечно, процесс тестирования не имеет возможности подтвердить правильность программного средства, максимум что оно может – продемонстрировать что ошибки здесь присутствуют. Вывод: нет никакой гарантии, что в процессе тестирования программного средства на практике выполнимым комплексом тестов в том, что станет возможным установить присутствие каждой имеющейся в программном средстве ошибки.

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

Для целей оптимизировать набор тестов – а именно подготовить такие тесты, при помощи которых стало бы возможным при конкретном заданном числе тестов, либо же при заданном временном отрезке, которое отводят для процесса тестирования – обнаружить максимально возможное количество ошибок в программном средстве. Для этого необходимо: предварительно продумать и подготовить набор тестов, а также применить оптимальную стратегию планирования тестов (проектирования)^[4].

Проектирование тестов целесообразно начать после завершения внешнего описания программного средства. Существуют разные подходы к созданию стратегии (рис. 3)

Рис. 3 Подходы к проектированию тестов

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

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

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

- применять на каждую использованную функцию либо возможность хотя бы один тест;

- применять на каждую конкретную область и на каждую границу изменения какой-либо входной величины также хотя бы один тест;

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

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

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

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

Комплексная же отладка предполагает тестирование программного средства в общем при помощи нахождения и исправления зафиксированных в процессе тестирования ошибок уже во всех документах, даже в текстах программ программного средства, которые относятся к программному средству в целом.

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

2.3 Заповеди отладки программного средства

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

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

Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование.

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Глава 3. Практический аспект отладки АСУ ТП

Для повышения безопасности и производительности работы шахт и рудников в Конструкторско-технологическом институте вычислительной техники СО РАН (КТИ ВТ СО РАН) разрабатываются Автоматизированные системы управления технологическими процессами (АСУ ТП) для подземных выработок шахт и рудников Кемеровской области, опасных по газу, пыли и внезапным выбросам. Одной из основных задач АСУ ТП является эффективное и безопасное управление автоматизированным технологическим оборудованием шахт и рудников. Для решения этой задачи требуется полная комплексная отладка и тестирование программ управления АСУ ТП. При этом важно, чтобы как можно большая часть этой работы была выполнена на инструментальных средствах предприятия-разработчика. Это позволит повысить надежность и безопасность АСУ ТП, сократить время и стоимость пуско-наладочных работ и опытной эксплуатации, облегчить сопровождение, модернизацию и оптимизацию программ управления. Проблема полной комплексной отладки и тестирования программ управления АСУ ТП заключается в сложности подключения полного набора согласованных входных сигналов реального технологического оборудования на инструментальных средствах предприятия- разработчика.

На реальном объекте на этапах пуско-наладки и опытной эксплуатации для полной комплексной отладки и тестирования программ управления невозможно или нецелесообразно искусственное создание полного набора возможных ситуаций, в том числе и аварийных. Наиболее подходящим инструментом для решения этой проблемы является имитационное моделирование. Для автоматизации процесса отладки и тестирования программ управления АСУ ТП имитационная модель должна быть интегрирована с тестируемой системой. Интеграция заключается в генерации в модели входных сигналов в формате тестируемой системы, посылке сигналов в тестируемую систему вместо реальных входных сигналов от технологического оборудования и получения обратной связи от тестируемой системы. Такой подход был успешно опробован при разработке АСУ ТП Северо-Муйского тоннеля [1] и Системы мониторинга технологической инфраструктуры нефтегазодобывающего предприятия [2].

Программы управления, обычно, выполняются в программируемых логических контроллерах (ПЛК), входящих в состав АСУ ТП. Для более полного тестирования АСУ ТП, в том числе, и работы ПЛК не достаточно рабочей станции, на которой работает модель, а требуется дополнительное оборудование: вычислительные средства, на которых работает АСУ ТП, среда передачи данных, устройства ввода/вывода и др. Для проведения такого тестирования в КТИ ВТ СО РАН создан программно- аппаратный отладочный стенд с перечисленным выше оборудованием. Интегрированная модель исполняется на отдельной рабочей станции. Разработка и исполнение модели происходит с использованием визуально-интерактивной системы дискретного имитационного моделирования MTSS [3, 4].

Система MTSS содержит специализированные на конкретные предметные области библиотеки моделей технологического оборудования и интерфейс для графического построения моделей из библиотечных элементов и проведения имитационного © Журавлев С.С., Окольнишников В.В., Рудометов С.В., 2016 г. эксперимента. Система предназначена для быстрого построения с помощью визуально- интерактивного интерфейса моделей специалистами конкретной предметной области, не имеющими опыта использования имитационного моделирования. Профессионалы в области имитационного моделирования или программирования могут разрабатывать более детальные модели, включая в них код на языке Java, и создавать собственные библиотеки по заданной схеме. Библиотечная модель включает в себя: графический образ элемента оборудования (2D или 3D), набор параметров (входных и выходных сигналов, настраиваемых переменных), набор возможных состояний, способы визуализации состояний, список команд управления, логику нижнего уровня (алгоритм функционирования, описывающий зависимости между параметрами). Аналогичный набор атрибутов содержат и образы технологического оборудования в SCADA-системах, используемых для создания АСУ ТП. Такая структура библиотечного элемента выбрана сознательно. Она облегчает создание моделей, интегрированных с АСУ ТП. Редактирование модели происходит в режиме 2D. Визуализация исполнения модели может выполняться как в режиме 2D, так и в режиме 3D.

Визуализация используется для отладки, валидации и презентации модели. Для возможности визуального наблюдения за исполнением модели имеется средство регулирования "скорости" исполнения модели с помощью параметра, задающего соотношение единиц модельного и процессорного времени исполнения модели. В отладочном режиме модель может исполняться пошагово. Во время исполнения модели пользователь может прервать ее исполнение, изменить значения параметров и продолжить исполнение модели. В системе MTSS имеется возможность задания двух уровней логики исполнения модели. Нижний уровень логики исполнения модели встроен в библиотечные модели. На верхнем уровне логики исполнения, может быть определен сценарий исполнения модели, цель моделирования, заданы программы управления, которые, например, при возникновении определенных событий осуществляют перевод группы библиотечных моделей в согласованное состояние с соблюдением технологического регламента. На этом же уровне определяется связь модели с внешними системами. Такая двухуровневая структура модели соответствует общепринятой структуре АСУ ТП. Совместимость структур облегчает создание моделей, интегрированных с АСУ ТП. Для моделирования технологических процессов шахт и рудников в MTSS имеется специализированная библиотека технологического оборудования шахт и рудников [5, 6].

В состав библиотеки входят следующие библиотечные модели: забой, бункер, конвейер, насос, водопровод, резервуар, источник технологических и грунтовых вод, трансформатор, трансформаторная подстанция, источник электропитания АСУ ТП, кабель линии электропередач и др. С использованием библиотеки технологического оборудования разработаны имитационные модели конвейерной системы, системы водоотливной установки и электроснабжения одной из угольных шахт Кузбасса. На рис. 1 представлен фрагмент модели системы водоотливной установки. Эта система предотвращает затопление шахты. В модели имитируется приток технологических и грунтовых вод, работа насосов, потребление электроэнергии.

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

Рис.4 . Фрагмент модели системы водоотливной установки

На рис. 5 представлена типовая структура АСУ ТП. Входные сигналы с датчиков технологического оборудования через устройства ввода поступают на обработку в ПЛК, составляющие нижний уровень АСУ ТП. Состояния объектов технологического оборудования визуализируются на мнемосхемах АРМ оператора. АРМ оператора выполняется на рабочей станции верхнего уровня АСУ ТП. Все вычислительные средства АСУ ТП связаны локальной вычислительной сетью. Команды управления с АРМ оператора в противоположном направлении передаются на исполнительные механизмы технологического оборудования. Ядром АСУ ТП являются программы управления. Как правило, они выполняются в ПЛК. Программы управления обрабатывают и проверяют на совместимость входные сигналы, определяют возможность исполнения команд управления и формируют команды (или последовательность команд) на исполнительные механизмы в соответствии с технологическим регламентом, осуществляют автоматическое групповое управление объектами технологического оборудования в соответствии с заданным алгоритмом. В силу сложности и важности программ управления требуется разработка инструментальных средств для как можно полной их отладки и тестирования. Одним из инструментов для отладки и тестирования программ управления АСУ ТП является имитационная модель, интегрированная с реальной системой управления в рамках программно-аппаратного отладочного стенда. Программно-аппаратный отладочный стенд, представленный на рис. 6., включает в себя рабочую станцию, в которой исполняется модель в среде моделирования MTSS, вычислительные средства, на которых исполняется АСУ ТП, среду передачи данных, устройства ввода/вывода и другое дополнительное оборудование. В процессе выполнения работы были реализованы три варианта использования отладочного стенда на примере реальной системы управления водоотливной установкой. Автономная модель. В этом варианте (рис. 5) модель не связана с реальной системой управления. Но, структура модели соответствует структуре реальной системы управления, что облегчает ее использование в качестве модели, интегрированной с реальной системой. Технологическое оборудование реальной системы управления заменено моделью технологического оборудования. Программы управления в модели являются упрощенной реализацией программ управления реальной системы.

Автономная имитационная модель может быть использована для достижения следующих целей: • Проектирование несуществующей системы; • Решение оптимизационных задач; • Эксперименты с моделью системы, когда эксперименты с моделируемой системой дороги или небезопасны; • Определение граничных условий функционирования моделируемой системы; • Модернизация системы. Информационная интегрированная модель. Информационная интегрированная модель является источником входных сигналов для реальной системы управления вместо реального технологического оборудования. Структура информационной модели представлена на рис. 6, если убрать из рисунка штрихпунктирные стрелки. Информационная модель предназначена для отладки и тестирования всего программного обеспечения реальной системы управления (верхнего и нижнего уровней) за исключением программ управления. Для отладки нижнего уровня реальной системы управления и устройств ввода/вывода часть сигналов, генерируемых моделью, преобразуются к формату сигналов от реальных датчиков технологического оборудования. Для отладки верхнего уровня реальной системы управления часть сигналов, генерируемых Модель оборудования АСУ ТП ПЛК Программы управления АРМ оператора (рабочая станция) Устройства ввода Сигналы Команды Автономная модель (рабочая станция) Программы управления АРМ разработчика Устройства вывода Технологическое оборудование

Рис. 2. Типовая структура АСУ ТП моделью, преобразуется к формату сигналов, передаваемых по локальной вычислительной сети реальной системы управления.

Как дополнительное средство отладки и тестирования нижнего уровня в программно-аппаратный отладочный стенд могут быть включены реальные датчики. Часть сигналов, генерируемых моделью, в соответствующем формате могут быть заведены на датчики для проверки всей связки: датчик, устройство ввода, ПЛК. Некоторые сигналы могут быть заданы на датчиках вручную. Использование информационной интегрированной модели осуществляется по следующей схеме. Разработчик с АРМ разработчика в модели изменяет параметры модели, выполняет команды управления отдельными объектами технологического оборудования или запускает программы автоматического группового управления. Результаты этих действий в объеме реализации в модели программ управления отражаются на АРМ оператора реальной системы управления.

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

Рис. 6. Использование интегрированной модели Управляющая интегрированная модель

Управляющая модель предназначена для тестирования и отладки всего программного обеспечения реальной системы управления (верхнего и нижнего уровней), включая программы управления. Структура управляющей модели представлена на рис. 3. В управляющей интегрированной модели упрощенная реализация программ управления заменяется при исполнении на полную реализацию, которая исполняется в ПЛК реальной системы управления. Программы управления "не знают", в каком окружении они исполняются в реальной системе или в интегрированной модели. Этим достигается адекватность модели. Использование управляющей интегрированной модели осуществляется по следующей схеме. Разработчик с АРМ разработчика в модели изменяет параметры модели, выполняет команды управления отдельными объектами технологического оборудования или запускает программы автоматического группового управления. Результаты этих действий отражаются на АРМ оператора реальной системы управления.

Управляющая интеграционная модель может быть использована для достижения перечисленных выше целей информационной модели, а также для достижения дополнительных целей: • Сопровождение реальной системы управления на всех этапах ее жизненного цикла (проектирование, разработка, отладка, тестирование, пуско-наладка, опытная эксплуатация, оптимизация, развитие); • Предсказание поведения реальной системы управления в зависимости от определенной ситуации и действий (бездействия) оператора; • Использование модели внешней среды.

Опыт разработки и применения модели, интегрированной с АСУ ТП водоотливной установки, может быть использован при разработке новых и модернизации существующих АСУ ТП шахт и рудников, а также может быть использован при разработке систем управления в других отраслях.

Заключение

В данной работе были рассмотрены основные подходы и ограничения к отладке и тестированию программ. Подведем некоторые выводы.

Тестирование программного средства (ПС) - это процесс выполнения программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Тестирование программ является одной из составных частей более общего понятия - «отладка программ». Под отладкой понимается процесс, позволяющий получить программу, функционирующую с требующимися характеристиками в заданной области изменения входных данных.

Процесс отладки включает:

• действия, направленные на выявление ошибок (тестирование);

• диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);

• внесение исправлений в программу с целью устранения ошибок.

Из трех перечисленных видов работ самым трудоемким и дорогим является тестирование, затраты на которое приближаются к 45 % общих затрат на разработку ПС.

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

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

Тестирование оказывается довольно необычным процессом (поэтому и считается трудным), так как этот процесс разрушительный. Ведь цель проверяющего (тестовика) - заставить программу сбиться.

Список использованной литературы

1. Ален И. Голуб. С и С. Правила программирования. - М.: БИНОМ, 1996. - 272 с.

2. Б. Керниган, Р. Пайк. Практика программирования. - СПб.: Невский диалект, 2001. - 381 с.

3. В. Даль, Э.. Дейкстра, К. Хоору. Структурное программирование. - М.: Мир, 1973. - 247 с.

4. Г. С. Иванова. Основы программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 416 с.

5. Г. С. Иванова. Технология программирования: Учебник для вузов. - М.: Изд-во МГТУ им. Н.Э. Баумана, 2002. - 320 с.

6. Д. Ван Тассель. Стиль, разработка, эффективность, отладка и испытание программ. - М.: Мир, 1985. - 332 с.

7. М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - 368 с.

8. Н. Вирт. Систематическое программирование. - М.: Мир, 1977. - 183 с.

9. Э.Дейкстра. Дисциплина программирования. - М.: Мир, 1978. - 275 с.

10. Э.. Йодан. Структурное проектирование и конструирование программ. - М.: Мир, 1979. - 415 с.

11. http://digteh.ru/Progr/otladka.php

. Ален И. Голуб. С и С. Правила программирования. - М.: БИНОМ, 1996. - 272 с. – С. 43. ↑
М. Зелковиц, А. Шоу, Дж. Гэннон. Принципы разработки программного обеспечения. - М.: Мир, 1982. - 368 с. – С. 76. ↑
http://digteh.ru/Progr/otladka.php ↑
В. Даль, Э.. Дейкстра, К. Хоору. Структурное программирование. - М.: Мир, 1973. - 247 с. – С 54-56. ↑