Функциональные схемы автоматизации: ФСА — Функциональная схема автоматизации

ФСА — Функциональная схема автоматизации

Функциональные схемы автоматизации (P&ID Diagram или ФСА), представляют собой основной технический документ, определяющий функционально-блочную структуру отдельных узлов автоматического контроля, управления и регулирования технологического процесса и оснащение объекта управления приборами и средствами автоматизации.

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

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

Функциональные задачи автоматизации, как правило, реализуются с помощью технических средств, включающих в себя:

– отборные устройства;

– средства получения первичной информации;

– средства преобразования и переработки информации;

– средства представления и выдачи информации обслуживающему персоналу и т.д.

Результатом составления функциональных схем автоматизации является:

– выбор метода измерения технологических параметров;

– выбор основных технических средств автоматизации, наиболее полно отвечающих предъявленным требованиям и условиям работы автоматизируемого объекта;

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

– размещение средств автоматизации на щитах и пультах, на технологическом оборудовании или по месту;

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

  #Функциональная, #схема, #автоматизации,#технологический,#процесс

English version

Функциональная схема автоматизации

 Методика составления функционально-технологической схемы автоматизации.

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

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

Пример оформления чертежа функциональной схемы автоматизации приведен на рис. 2.

При оформлении и описании функциональных схем терминология должна соответствовать ГОСТ 17194—71, а условные обозначения приборов и средств автоматизации — ГОСТ 3925—59.

При наличии однотипных технологических объектов (цехов, отделений, установок, агрегатов, аппаратов), не связанных между собой и имеющих одинаковое оснащение приборами и средствами автоматизации, функциональную схему выполняют для одного из них, при этом на чертеже дают пояснение, например «Схема составлена для агрегата 1; для агрегатов 2—5 схемы аналогичны». К этому добавляют пояснения относительно особенностей в позиционных обозначениях (маркировке) и в спецификации. Например, «В спецификации учтена аппаратура для пяти агрегатов. Маркировка приборов и средств автоматизации для агрегатов 2—5 аналогична приведенной для агрегата 1 с изменением цифрового индекса соответственно номеру агрегата».

Для обозначения на схемах запроектированных систем телеуправления (ТУ), телесигнализации (ТС) и телеизмерения (ТИ) в прямоугольниках щитов и (пультов вычерчивают горизонтальные линии с надписями с левой стороны ТУ, ТС, ТИ. Связь этих систем с приборами и средствами автоматизации показывают линиями связи. Технологическое оборудование и коммуникации автоматизированного объекта изображают на функциональных схемах упрощенно, но так, чтобы показать взаимное расположение и взаимодействие их с приборами и средствами автоматизации. Допускается изображение частей объекта в виде прямоугольников с указанием их наименования. На технологических коммуникациях (они изображаются по ГОСТ 3464—63) показывают только те регулирующие и запорные органы, которые участвуют в системе управления процессом.

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

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

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

п. Они располагаются на схеме в один или несколько горизонтальных рядов и условно ограничиваются прямоугольниками.

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

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

Рис.2. Функциональная схема автоматизации (обозначения на рис.3).

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

На схемах всем приборам и средствам автоматизации присваиваются позиционные обозначения.

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

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

Спецификация средств автоматизации.

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

Обозначения основных величин и условные изображения приборов и средств автоматизации в схемах.

ГОСТ 3925—59 установлены обозначения измеряемых и регулируемых величин и условные изображения приборов и устройств автоматизации, применяемые в функциональных схемах. К ним относятся обозначения основных контролируемых и регулируемых величин, наименований основных электроизмерительных приборов, а также изображения приборов измерительных и регулирующих, видов передач дистанционного воздействия, первичных преобразователей, воспринимающих воздействие измеряемых или регулируемых величин, исполнительных механизмов и регулирующих органов, дополнительных устройств и рекомендуемые размеры изображений приборов и средств.

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

 

Функциональные схемы автоматизации в предварительном планировании

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

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

Функциональные схемы автоматизации также часто называются P&ID (англ. Piping and Instrumentation Diagram, технологические схемы трубопроводов и оснащения) или функциональные схемы автоматизации (нем.

Rohrleitungs- und Instrumentierungs-Schema). В EPLAN используется понятие «Функциональная схема автоматизации».

Информация на функциональной схеме автоматизации

Информация на функциональной схеме автоматизации состоит из основной и дополнительной. Основная информация:

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

Кроме того, может содержать следующую дополнительную информацию:

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

Тип страницы «Функциональная схема автоматизации»

Функциональные схемы автоматизации создаются на основе типа страниц «Функциональная схема автоматизации». Нулевая точка страниц находится внизу слева. При изменении стандарта эти страницы никогда не поворачиваются.

См. также

Технологические контуры / функции ТК на функциональной схеме автоматизации (предварительное планирование)

Резервуары / трубопроводы на функциональной схеме автоматизации (предварительное планирование)

Установить функциональную схему автоматизации (предварительное планирование)

Функциональные схемы систем автоматизации технологических процессов

1. ФУНКЦИОНАЛЬНЫЕ СХЕМЫ СИСТЕМ АВТОМАТИЗАЦИИ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ

2. ОБЩИЕ ПОЛОЖЕНИЯ

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

5. ИЗОБРАЖЕНИЕ ТЕХНОЛОГИЧЕСКОГО ОБОРУДОВАНИЯ И КОММУНИКАЦИЙ

Технологическое оборудование и трубопроводы на
функциональной схеме должны соответствовать
технологической схеме и изображаться упрощенно.
Внутренние детали и элементы частей оборудования
показываются только в случае, если они механически
связаны с приборами и средствами автоматизации.
На технологических трубопроводах показываются
только те вентили, задвижки, заслонки, клапаны и
другие запорные органы, которые участвуют в
системе контроля и управления процессами.
Не
рекомендуется
показывать
детали
вспомогательного
назначения
(фильтры,
отстойники и т.п.).
Технологическое
оборудование,
а
также
прямоугольники,
изображающие
блоки,
рекомендуется изображать тонкими линиями.
Необходимые виды, разрезы и сечения
технологического
оборудования
должны
выполняться в соответствии с ГОСТ 2.305-68,
штриховка по ГОСТ 2.306-68
Соединение и пересечение
трубопроводов рекомендуется
функциональной
схеме
обозначениями:
— соединение;
—
— пересечение.
технологических
изображать на
условными
Условные
обозначения
Цвет
—
Красный, черный
—1—1—
Зеленый
Пар
—2—2—
Розовый
Воздух
—3—3—
Голубой
Азот
—4—4—
Темно-желтый
Кислород
—5—5—
Синий
Аммиак
—11—11—
Серый
Кислота (окислитель)
—12—12—
Оливковый
Щелочь
—13—13—
Серо-коричневый
Масло
—14—14—
Коричневый
Жидкое горючее
—15—15—
Желтый
Противопожарный трубопровод
—26—26—
Красный
Вакуум
—27—27—
Светло-серый
Содержимое
трубопроводов
Жидкость или газ,
преобладающие
в данном проекте
Вода

9.

ИЗОБРАЖЕНИЕ ПРИБОРОВ И СРЕДСТВ АВТОМАТИЗАЦИИ Таблица 1 – Буквенные обозначения измеряемых
величин
Измеряемая величина
Обозначение
Основное
значение
первой
буквы
А
В
С
Уточнение
Функции, выполняемые прибором
Отображение
информации
Формирование вых.
сигнала
Сигнализация
Резервная
буква*
Регулирован
ие,
управление
Доп.
значение

10. Продолжение таблицы 1

Измеряемая величина
Обозначение
Основное
значение
первой буквы
D
Плотность
E
Любая
электрическая величина
F
Расход
G
Размер,
положение,
перемещение
Уточнение
Разность,
перепад
Соотношение, доля,
дробь
Функции, выполняемые прибором
Отображение
информации
Формирование вых.
сигнала
Доп.
значе-ние

11. Продолжение таблицы 1

Измеряемая величина
Обозначение
H
Основное
значение
первой буквы
Уточнение
Отображение
информации
Формирование вых.
сигнала
Доп.
значе-ние
Верхний
предел
измеряемой
величины
Ручное
воздействие
I
J
Функции, выполняемые прибором
Показание
Автоматическое
переключение, обегание

12. Продолжение таблицы 1

Измеряемая величина
Обозначение
K
Основное
значение
первой
буквы
Уточнение
Функции, выполняемые прибором
Отображение
информации
Формирование вых.
сигнала
Доп.
значение
Время,
временная
диаграмма
L
Уровень
M
Влажность
N
Резервная
буква*
Нижний
предел
измеряемой
величины

13. Продолжение таблицы 1

Измеряемая величина
Обозначение
Основное
значение
первой
буквы
O
Резервная
буква*
P
Давление,
вакуум
Q
Качество
R
Радиоактивность
Уточнение
Функции, выполняемые прибором
Отображение
информации
Интегрирование,
суммирование по
времени
Регистрация
Формирование вых.
сигнала
Доп.
значение

14. Продолжение таблицы 1

Измеряемая величина
Обозначение
Основное
значение
первой
буквы
S
Скорость,
частота
T
Температура
U
Несколько
разнородных
измеряемых
величин
V
Вязкость
Уточнение
Функции, выполняемые прибором
Отображение
информации
Формирование вых.
сигнала
Включение,
отключение,
переключение
Доп.
значение

15. Продолжение таблицы 1

Измеряемая величина
Обозначение
Основное
значение
первой
буквы
W
Масса
X
Нерекомендуемая
резервная
буква**
Y
Резервная
буква*
Z
Резервная
буква*
Уточнение
Функции, выполняемые прибором
Отображение
информации
Формирование вых.
сигнала
•* Используются для обозначение величин, не предусмотренных
стандартом.
•** Допускается использовать для одноразового применения.
Доп.
значение

16. Таблица 2 — Графические условные обозначения приборов и средств автоматизации

Наименование
Первичный
измерительный
преобразователь
(датчик), устанавливаемый
по месту
Прибор, устанавливаемый
на щите, пульте
Отборное устройство без
постоянно подключенного
прибора
Условное
обозначение
Размеры, мм

17. Продолжение таблицы 2

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

18. Продолжение таблицы 2

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

19.

Продолжение таблицы 2 Наименование
Линии связи
Пересечение линий связи
без соединения друг с
другом
Пересечение линий связи
с соединением между
собой
Условное
обозначение
Размеры, мм
Приборы и средства автоматизации, условные
обозначения которых не представляется
возможным построить с помощью указанного
стандарта, допускается обозначать произвольными
условными обозначениями.
Для обозначения измеряемых величин и
функциональных признаков приборов приняты
прописные буквы латинского алфавита (таблица 1).
При отсутствии необходимых буквенных
обозначений для этой цели используются
резервные буквы, приведенные в этой же таблице.
Примененные резервные буквенные обозначения
должны поясняться на схеме.
• Графические условные обозначения
электроаппаратуры (звонки, гудки, сирены,
сигнальные лампы, табло, электродвигатели),
показываемой на функциональной схеме, которые
заимствованы из стандартов ЕСКД, приведены в
таблице 3.
• Приборы и средства автоматизации,
встраиваемые в технологическое оборудование и
коммуникации, изображаются на схеме в
непосредственной близости к ним. К таким
приборам: термометры расширения, термопары,
термометры сопротивления, сужающие
измерительные устройства, исполнительные
механизмы, регулирующие и запорные органы.

22. Таблица 3 — условные обозначение дополнительных электрических устройств

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

24. ИЗОБРАЖЕНИЕ ЛИНИЙ СВЯЗИ

• Линии связи между, приборами и средствами
автоматизации изображаются на функциональной
схеме однолинейно тонкими линиями независимо
от фактического количества труб и
электропроводок, осуществляющих эту связь.
• Линии связи должны наноситься по возможно
кратчайшему расстоянию с наименьшим
количеством изгибов и пересечений. Допускается
пересечение линиями связи изображений
технологического оборудования и коммуникаций.
• Пересекать условные обозначения приборов и
средств автоматизации не допускается.
• Пример выполнения пересечения линий связи
показан на рисунке
• В случае функционального воздействия (соединения)
линий связи в месте пересечения ставится точка.
• В местах пересечения линии блокировки с линиями
связи параметров ставится точка.
• В случае, когда сигнализация параметров
запроектирована для работы в одной схеме,
допускается в прямоугольниках показывать
горизонтальную линию, соединенную с линиями
связи этих параметров.
• Линии связи должны четко отображать
функциональные связи приборов (элементов) от
начала прохождения сигнала (воздействия) до конца.
• При выполнении сложных функциональных схем
с большим количеством примененных приборов и
средств автоматизации, рекомендуется делать
разрыв этих линий.
• Пример выполнения сигнализации параметров,
запроектированных для работы в одной схеме
показан на рисунке
• Концы обрыва линий связи показываются на
свободном поле чертежа в один горизонтальный
ряд (вверху или внизу от технологического
оборудования).
• Концы обрыва этих же линий связи со стороны
приборов и средств автоматизации,
изображенных в прямоугольниках, показываются
над этими прямоугольниками также в один
горизонтальный ряд. Для удобства пользования
схемой каждый конец (обрыв) линии связи
нумеруется слева направо, строго в порядке
возрастания, одной и той же арабской цифрой.
Пример изображения разрыва линий связи показан
на рисунке
• Допускается комбинированное выполнение линий
связи: непрерывными линиями и адресным
методом для тех участков схемы, где нанесение
непрерывных линий связи затрудняет чтение
схемы.
• На функциональных схемах должны указываться
предельные рабочие (максимальные или
минимальные) значения измеряемых или
регулируемых величин.
Предельные значения указываются:
1) на линиях связи отборных устройств с элементами
средств автоматизации, изображенными в
прямоугольниках, на участках перед
прямоугольниками;
2) для элементов средств автоматизации,
встраиваемых в коммуникации и оборудование и не
имеющих связи с другими элементами – возле
обозначений приборов.
• Значения измеряемых и регулируемых величин
должны проставляться в единицах шкалы
выбираемого прибора или в международной
системе единиц. Разрежение (вакуум)
обозначается знаком минус.
• Делать надписи на линиях связи, идущих к
регулирующим органам, типа «Регулирование»,
«Управление вентилятором» и т. п. не
рекомендуется.

32. ВЫПОЛНЕНИЕ ФУНКЦИОНАЛЬНЫХ СХЕМ

• Для сложной технологической системы, которую
представляется возможным расчленить на
отдельные технологические узлы,
рекомендуется выполнять функциональные
схемы этих узлов отдельными схемами или на
разных листах одной схемы.
• На функциональной схеме дается пояснение, на
основании какого документа она выполнена.
• Для однотипных технологических объектов (цехов,
отделений, установок и т. п.), не связанных между
собой и имеющих одинаковое оснащение средствами
автоматизации и одинаковые отдельные щиты,
функциональная схема изображается только для одного
из них и дается пояснение: «Схема составлена для
агрегата № для агрегатов № № … схемы аналогичны».
• Для однотипных технологических объектов, имеющих
общие для них щиты, пульты и т. п., рекомендуется
показывать на функциональной схеме технологическое
оборудование и коммуникации только одного из них, а
приборы и средства автоматизации, показываемые в
прямоугольниках внизу чертежа – для всех
проектируемых объектов.
В этом случае рекомендуются следующие варианты:
1) однотипные приборы и средства автоматизации,
имеющие одинаковые значения параметров,
показывать в прямоугольниках 1 раз и около их
обозначений проставлять общее количество в штуках;
2) однотипные приборы и средства автоматизации,
имеющие различные значения параметров,
показывать в прямоугольниках для всех объектов.
Линии связи, идущие к неизображенным объектам,
должны вблизи прямоугольников обрываться, а над
ними должна бытьприведена поясняющая надпись
«От агрегата № …»
Пример выполнения функциональной схемы для однотипных
технологических объектов с приборами, установленными
на одном щите:
а – контролируемые параметры имеют одинаковые значения;
б – контролируемые параметры имеют различные значения.
• При выполнении функциональной схемы без
изображения технологического оборудования
рекомендуется вместо технологического
оборудования в верхней части схемы наносить
прямоугольник, разбитый на вертикальные графы.
В каждой графе должно быть указано
наименование технологического оборудования, от
которого воспринимается технологический
параметр, и наименование контролируемого
(регулируемого) параметра.
Пример выполнения функциональной схемы
без изображения технологического оборудования
• Функциональные схемы должны выполняться в
соответствии с ОСТ 36-27-77 двумя способами
построения условных обозначений – упрощенным
и развернутым.
Пример упрощенного
способа построения
условных обозначений
при изображении
приборов и средств
автоматизации на
технологической схеме
Пример
развернутого
способа
построения
условных
обозначений при
изображении
приборов и
средств
автоматизации на
функциональной
схеме
• При упрощенном способе построения условных
обозначений на функциональных схемах не
показываются первичные измерительные
преобразователи, вся вспомогательная аппаратура.
• Упрощенный способ построения условных
обозначений рекомендуется применять в
основном при изображении приборов и средств
автоматизации на технологической схеме.
• При развернутом способе построения условных
обозначений каждый прибор или блок на
функциональной схеме показываются отдельным
обозначением.
• Допускается сложные приборы, выполняющие
несколько функций, изображать несколькими
окружностями, расположенными слитно.

42. ПОЗИЦИОННЫЕ ОБОЗНАЧЕНИЯ ПРИБОРОВ, СРЕДСТВ АВТОМАТИЗАЦИИ И ЭЛЕКТРОАППАРАТУРЫ

Всем приборам и средствам автоматизации,
изображенным на функциональных схемах,
присваиваются позиционные обозначения,
сохраняющиеся во всех документах проекта.
Позиционное обозначение приборов и средств
автоматизации должно состоять из двух частей:
1) цифрового обозначения, присваиваемого
комплекту;
2) буквенных индексов, присваиваемых отдельным
элементам, входящим в комплект.
• Комплектом называется совокупность отдельных
функционально связанных элементов,
выполняющих определенную задачу.
• Цифровые обозначения даются арабскими
цифрами, а буквенные индексы – строчными
буквами русского алфавита.
• Отдельным приборам, не входящим в комплект
(показывающие термометры, манометры и т. п.),
присваиваются позиции, состоящие только из
порядкового номера.
• Во избежание разночтений буквы 3 и О, имеющие
начертание, похожее на начертание цифр,
употреблять не допускается.
• Буквенные обозначения присваиваются каждому
элементу комплекта в порядке алфавита в
зависимости от последовательности прохождения
сигналов.
• Одинаковым комплектам или однотипным
элементам одного комплекта рекомендуется
присваивать одинаковые позиционные
обозначения независимо от места их установки.
Например, нескольким термопарам с
одинаковыми характеристиками,
присоединенным к одному прибору.

45. ГРАФИЧЕСКОЕ ВЫПОЛНЕНИЕ ФУНКЦИОНАЛЬНЫХ СХЕМ

Толщина линий на функциональной схеме
выбирается на основании ГОСТ 2.303-68 и ОСТ 36-2777. Рекомендуется использовать линии следующей
толщины:
а) контурные линии агрегатов, установок,
технологических аппаратов 0,2 – 0,5 мм;
б) коммуникации трубопроводов 0,5 – 1,5 мм;
в) условные графические обозначения приборов и
средств автоматизации 0,5 – 0,6, а разделительная
горизонтальная черта внутри них 0,2 – 0,3 мм;
г) линии связи 0,2 – 0,3 мм;
д) прямоугольники, изображающие щиты, пульты,
агрегатированные комплексы и т. п., 0,5 – 1 мм;
е) линии выносок 0,2 – 0,3 мм.
При одинаковой толщине линий различного
назначения их рекомендуется вычерчивать по
толщине в противоположных (большем или
меньшем) пределах.
Все надписи и цифры на функциональных схемах
должны выполняться по ГОСТ 2.304-68.
Рекомендуется применять следующие размеры
шрифта:
1) для позиций – цифры 3,5, буквы (строчные) 2,5
мм;
2) для позиционных обозначений комплектов
приборов и средств автоматизации – буквы и цифры
3,5 мм;
3) для пояснительного текста и надписей 3,5 – 5 мм.
Прямоугольники рекомендуется вычерчивать
высотой до 30 – 40 мм. Прямоугольники,
изображающие сложные устройства вычерчиваются
высотой произвольных размеров.
• Все приборы и средства автоматизации,
изображаемые в прямоугольниках рекомендуется
вычерчивать с расстояниями между осями 12 мм.
Допускается увеличивать расстояние между осями
в n раз, т. е. 24, 36 мм и т. п.
• Расстояние между параллельными линиями связи
должны быть не менее 3 мм.
• Краткие пояснения функций, выполняемых
аппаратурой, изображаются вблизи аппаратуры на
выносных линиях с полками.
• В надписях и текстах на функциональной схеме не
допускается сокращение слов.
Схема автоматизации функциональная

Функциональные схемы автоматизации

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

предназначена для отображения основных технических решений,

принимаемых при проектировании систем автоматизации технологических

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

процессов является совокупность основного и вспомогательного

оборудования вместе с встроенными в него запорными и регулирующими

органами.

Функциональная схема является техническим документом, определяющим

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

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

оснащения объекта управления приборами и средствами автоматизации. На

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

регулирования, дистанционного управления, сигнализации, защиты и

блокировок.

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

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

В соответствии с ГОСТ 36-27-77 «Приборы и средства автоматизации. Обозначения условные в схемах автоматизации технологических процессов» устанавливаются обозначения измеряемых величин, функциональные признаки приборов, линии связи, а также способы и методика построения условных графических обозначений приборов и средств автоматизации.

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

— задачу получения первичной информации о состоянии технологического процесса и оборудования;

— задачу непосредственного воздействия на ТП для управления им и стабилизации технологических параметров процесса;

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

При разработке функциональной схемы определяют:

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

2) принципы организации контроля и управления технологическим
процессом;

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

4) перечень и значения контролируемых и регулируемых параметров;

5) методы контроля, законы регулирования и управления;

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

7) комплект технических средств автоматизации, вид энергии для передачи информации;

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

Схема автоматизации должна быть составлена таким образом, чтобы из нее легко можно было определить:

1) параметры технологического процесса, которые подлежат автоматическому контролю и регулированию;

2) наличие защиты и аварийной сигнализации;

3) принятую блокировку механизмов;

4) организацию пунктов контроля и управления;

5) функциональную структуру каждого узла контроля, сигнализации, автоматического регулирования и управления;

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

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

Общепринятым являются два варианта представления функциональной схемы:

по ГОСТ 21.404-85 «Автоматизация технологических процессов. Обозначения условные приборов и средств автоматизации в схемах» и ГОСТ 21.408-93 «Система проектной документации для строительства. Правила выполнения рабочей документации автоматизации технологических процессов»;

по Стандарту американского общества приборостроителей ANSI/ISA S5.1. «Instrumetation Symbols and Identification».

Примером применения ГОСТ является схема КИПиА, приведенная в приложении ГОСТа 21.408-93 (рис. 6). На этой схеме показаны:

— канал преобразования информации чувствительного элемента 7а в унифицированный сигнал 7б;

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

— канал сигнализации 7д со световыми сигналами HL1/2.

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

На экранах диспетчерского уровня осуществляется мониторинг, управление и конфигурирование АС (нижняя часть схемы).

Важно для сигналов на схеме указать размерность и пределы измерений физических параметров: мм, ^оС, МПа, м³/час и др.

Рис. 6 Пример функциональной схемы автоматизации по ГОСТ

Функциональные части и связи между ними на схеме изображаются в виде условных графических обозначений, установленных в стандартах Единой Системы Конструкторской Документации. Особую роль при этом занимает семантика абревиатуры КИПиА. Рекомендуемым способом построения системы наименования КИПиА, установленным в ГОСТ, является формирование многобуквенного имени, на первой позиции которого может стоять любая из 20 букв латинского алфавита, на второй — любая из 5 букв, на третьей — любая из 7 и т.д. (например, LIR, где L- уровень; I- показания; R-регистрация).

Примером применения ANSI стандарта является схема КИПиА приведенная на рис. 7.

На этом рисунке можно выделить 4 уровня АС: нижний уровень- это двигатель насоса, уровень щитовых приборов — YSLH и YS, уровень логики блокировок и управления и верхний уровень- сигнализация состояния исполнительных и командных элементов системы автоматизации.

Блок защиты и управления электродвигателем ESD обеспечивает:

— мягкий пуск двигателя;

— реверс двигателя;

— торможение с заданным током в течение заданного времени;

— ограничение токов при пуске, движении и торможении;

— управление по дискретным сигналам, по последовательному интерфейсу, с местного поста управления;

— отключение нагрузки при коротком замыкании;

— отключение по таймеру;

— проверка наличия фаз электродвигателя через заданные промежутки времени и выдача предупреждений в остановленном состоянии;

— определение изменения чередования фаз при включении блока и выдача предупреждений;

— определение провала одной из фаз сети ниже установленного уровня и выдача предупреждения;

— регулирование угла открытия тиристоров с помощью сигнала аналогового входа.

Состояние насоса показывается щитовым прибором YSLH. По этому сигналу формируется логика блокировок YSL, которая отражается затем предупредительной сигнализацией останова YAL и сигнализацией работа YLH.

По состоянию щитового ключа YS формируется логика релейного управления двигателем, которая отражается сигнализацией YL.

По состоянию ключа YS включается дистанционно формирователь напряжения ESD, что подтверждается индикацией «Блокировка сработала» LA. Связь с первичным и вторичными приборами показывается прерывистой линий.

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

Рис.8 Пример щитовой части разнесенного варианта функциональной схемы

комбинированные измерительные и регулирующие приборы,

микропроцессоры, компьютеры, полукомплекты телемеханики и т.п. Такие устройства обозначают прямоугольником произвольных размеров с указанием внутри прямоугольника (рис.8) типа устройства (U- несколько разнородных измеряемых величин; Y- преобразования и вычислительные функции; I- показания; R- регистрация; C- управление; S- включение, отключение, переключение, блокировка; A- сигнализация).

Всем КИПиА, изображенным на функциональной схеме автоматизации, присваиваются позиционные обозначения, состоящие из двух частей: арабских цифр – номера функциональной группы и строчных букв русского алфавита – номера КИПиА в данной функциональной группе (например, 5а, 3б и т.п.).

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

Допускается вместо букв русского алфавита использовать арабские цифры (например, 5-1, 3-2 и т.д.).

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

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

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

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

Основные виды функциональных схем

НАЛАДКА ПРИБОРОВ И СИСТЕМ АВТОМАТИЗАЦИИ

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

Изображение функциональной схемы на чертеже может быть раз­вернутым, упрощенным или комбинированным.

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

Рис. 129. Развернутое (а) и упрощенное (б) изображение АСР на схе­ме (/ = варочный котел)

нием. Рассмотрим функциональную схему АСР температуры котла сульфитной варки целлюлозы, структурная схема которой представ­лена на рис. 65. При развернутом изображении (рис. 129, а) на схе­ме изображены измерительные преобразователи температуры и рас­хода, два регулятора, задающие устройства и сигнальные лампы.

Типовые повторяющиеся системы обычно показывают укрупнен­ными узлами в упрощенном изображении (рис. 129, б). В этом случае схема говорит о том, что для регулирования температуры в котле применена каскадная АСР, состоящая из стабилизирующего регуля­тора расхода и корректирующего — температуры. Так же ясно, что для автоматизации применена пневматическая аппаратура.

Комбинированное изображение применяют, когда наряду с просты­ми системами проектом предусмотрены сложные разветвленные.

В этом случае основную массу систем изображают упрощенно, а наи­более сложные узлы — развернуто.

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

Рис. 130. Функциональная схема автоматизации (а) и пример ее выполнение с разрывом линии связи (б):

/ — нагнетатель, 2 — абсорбер, 3 — насос

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

Рассмотрим выполнение функциональной схемы автоматизации узла адсорбции (рис. 130, а) В адсорбер нагнетателем г. о трубопро­воду газа 20 подают газовую смссь, которая, пробулькивая (барбо — тируя) через жидкость, поступает в головку аппарата. Навстречу газовому потоку по трубопроводу / подают холодную воду, которая поглощает растворимые компоненты газовой смеси. Инертные газы по трубопроводу 6 направляются на переработку, а жидкая фаза по мере накопления удаляется на склад жидких продуктов. Как видно из рисунка, проектом предусмотрено измерение расходов газа, воды и продукта (позиции 2, 6 и 7) и контроль давления ьоды после нагне­тателя и в линии инертных газов (позиции / и 5). Для измерения тем — пературы в зоне поглощения применены многозонный термопреобраьо- натель и измерительный комплект (позиция 3). Для регулирования постоянства уровня применена АСР уровня (позиция 4)

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

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

Для очень сложных технологических процессов применяют сле­дующий способ изображения функциональных схем. Щиты, пульты и помещения преобразователей на чертеже не показывают, а системы автоматизации изображают в упрощенном виде рядом с технологи­ческим аппаратом. Условные изображения приборов или регуляторов помещают в разрезе линий, соединяющих отборное устройство и ис­полнительный механизм (см. рис. 129,6). При известной простоте такой способ изображения имеет ряд недостатков, так как на чертеже отсутствует информация о полном элементном составе системы и его расположении в помещениях. В этом случае первичные и исполнитель­ные устройства нумеруют цифрой, соответствующей порядковому номеру прибора и регулятора, и буквенным индексом. Над основным наименованием чертежа обычно располагают таблицу, куда включают нестандартные условные обозначения, принятые при выполнении проекта. Над таблицей располагают поясняющие схему текстовые надписи, диаграммы и т. П.

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

Рис. 131. Принципиальная электриче­ская схема управления двигателями насоса

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

Принципиальная электричес­кая схема управления (рис. 131). Рассмотрим схему управления двигателем насоса, откачиваю­щего воду из емкости. Все эле­менты рассматриваемой схемы имеют позиционные условные обозначения, которые строят по смысловому принципу. Устройствам присваивается в обозначении буква, например кнопкам — К, а реле — Р. Вторая и третья буквы определяют функциональное назначение устройства: КП — кнопка пуска, РУВ и РУН — соответственно реле верхнего и нижнего уров­ней и т. п.

Присвоенное устройству обозначение остается постоянным и для всех его узлов. Так, обозначение магнитного пускателя ПМ присвое­но на схеме и его блокировочному контакту. Если таких контактов мно­го, то перед обозначением ставят порядковый номер узла: ПМ, 2/7 УМ. Контакты, которые в отключенном состоянии разомкнуты, называются замыкающими (РУВ, ПМ, КП), а замкнутые — размыкающими (РУН, КТЗ, КС).

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

Учитывая изложенное, легко прочитать принципиальную схему.

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

Измерительный преобразователь МП дифтрансформаторной систе­мы подключен к клеммам 26,34 -36 измерительного блока проводами /—4, как показано на схеме. Блок РПИ соединен с переключателем управления ПУ, который в положении А соединяет контакты 2 и 4, 6 и 8, 10 и 12, подавая выходной сигнал регулятора на клеммы 7—9 магнитного усилителя МУ. Сигнал с выхода МУ подается на управле­ние реверсивным двигателем М исполнительного механизма МЭК. Преобразователь положения ДП подает сигнал, пропорциональный перемещению МЭК, на мостовую схему, собранную на элементах R1 и R5 и Д1 Д4. Положение исполнительного механизма определяют по миллиамперметру тА. Для установки заданного значения регули­руемой величины служит задатчик ЗД, подключенный к клеммам 28—30 измерительного блока И—III.

При повороте переключателя ПУ в положение Д замыкаются кон­такты / и 3, 9 и 11 и на вход МУ поступает напряжение от ключа ди­станционного управления КУ. В положении Б напряжение поступает на клемму 7 МУ, а в положении М — на клемму 9. При достижении крайних положений двигатель отключается контактами конечных вы­ключателей КВМ и КВБ.

В коммерческой деятельности электронное оборудование для торговли имеет огромное значение. Необходимость в нем обусловлена требованиями времени и потребностями современного человека в автоматизации объекта торговли.

Производим и продаем стенды для баланскировки коленвалов ДВС легковых и грузовых автомобилей 2,2кВт/220В — 6000грн Контакты для заказов: +38 050 4571330 [email protected] Разрабатываемый стационарный, автоматизированный стенд балансировки коленчатых валов ДВС, …

Принципиальная электриче-| ская схема термокондуктометри — ческого газоанализатора ТКГ представлена на рис. 190. Ана­лизируемая газовая смесь по­ступает к сопротивлениям пле­чей моста R1 и R2. Плечи моста! R3 и R4 омываются …

Систематизация структур функциональных схем систем автоматизации

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

Ключевые слова: структурная схема, функциональная схема, дерево схемотехнических решений.

The systematization algorithm of automation systems functional schemes, built for a number of structural schemes, using a variety of automation means, has been considered. The algorithm efficiency to identify the most common variants of functional schemes and building of automation systems technical solutions has been validated.

Keywords: block scheme, functional scheme, decision-tree schemes model.

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

Разработка систем автоматизации технологических процессов осуществляется на основе нисходящей иерархии схем [1]: структурная => функциональная => электрическая => монтажная. Структурная схема системы автоматизации является ее изображением в виде совокупности звеньев различного типа (датчик, регулятор, исполнительное устройство, интерфейсный преобразователь) с указанием связей между ними [2]. Ее приводят в техническом задании на проектирование (ТЗ). Функциональная схема содержит набор элементов из множества технических средств автоматизации, необходимых для реализации требуемых функций – регулирования, управления и др. Элементы, присутствующие в ней, необходимы для реализации связей, заданных в структурной схеме. Принципиальная электрическая схема (ПЭС) отражает привязку каждой связи элемента к конкретному электрическому контакту. На монтажных схемах изображаются элементы, их соединители, зажимы и подводимые к ним концы проводов и кабелей. В задании на проектирование обязательно должна присутствовать структурная схема [3] системы автоматизации с описанием требуемых функций и блоков, назначенных каждому ее звену.

В [4] описана методика построения деревьев схемотехнических решений (ДСР), на основе анализа которых для заданной структурной генерируются функциональные схемы системы автоматизации. Корневой вершиной каждого ДСР является регулятор. Любая вершина ДСР является отображением какого-либо элемента из набора технических средств автоматизации (ТСА), причем для соответствующих элементов родительской и дочерней вершин ДСР выполняется условие согласованности их функций преобразования и типов и диапазонов используемых сигналов. Каждая ветвь дерева представляет собой фрагмент измерительной, исполнительной или интерфейсной цепи системы автоматизации. На рис.1а представлены ДСР, построенные на микропроцессорном контроллере Ремиконт БК14 и регуляторе Термодат12, на рис. 1б – структурна схема системы автоматизации, на рис 1в — сгенерированный для нее на основе ДСР вариант функциональной.

Рис. 1. Деревья схемотехнических решений (а), структурная (б) и функциональная (в) схема системы автоматизации

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

Более рациональной является систематизация и хранение в компактном виде информации о структуре сгенерированных схем и ее использование для построения функциональных на вновь добавленном в базу данных ТСА регуляторе.

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

K – число входных каналов регулятора Reg_L;

N – число измерительных преобразователей E_j, входящих в состав измерительных цепей, выделенных на множестве функциональных схем на регуляторе Reg_L;

S_IP – множество структур, отражающих состав измерительных цепей;

S_m– цепь, образованная двумя элементами E_m и E_m+1;

P – число измерительных цепей, выделенных на множестве функциональных схем на регуляторе Reg_L, в состав которых входит датчик E_j;

— p-я измерительная цепь, истоком которой является датчик E_j;

Mp – длина p-й цепи, истоком которой является датчик E_j.

Данные о структуре исполнительных цепей систематизируются аналогично.

К примеру, правило if Reg=REG1 then IP1={Id1 (Id2, Id3 or Id4, Id5) or Id6 (null)} говорит о том, что в состав измерительной цепи Z_IP канала номер 1 регулятора REG1 могут входить датчики Id1 или Id6, причем датчик Id1 подсоединяется к регулятору через последовательное соединение элементов Id2 и Id3 или Id4 и Id5, а датчик Id6 – напрямую.

Для построения с использованием указанных правил схем на вновь добавленном в базу данных ТСА регуляторе R из набора присутствующих в правилах регуляторов Reg определяются те, с которыми у R есть сходство по типу входных (выходных) каналов функций преобразования ФП. Для каждого из выбранных регуляторов прочитываются и интерпретируются все правила. В перечень измерительных Z_IP(R) и исполнительных Z_IU(R) цепей регулятора R добавляются те фрагменты цепей из правил, в которых типы выходов (входов) напрямую присоединяющихся к R элементов Id совпадают с типами его входов (выходов).

В указанном выше примере проверяться будут элементы Id3 и Id5, и если тип и диапазон выходного сигнала позволяет подключить их к регулятору R, то в перечень измерительных цепей схемы добавляются цепи Id1-Id2-Id3 и Id1-Id4-Id5. Аналогично с исполнительными цепями.

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

Например, в базу данных добавлен регулятор с тремя каналами регулирования:

Рис.2. Пример внутренней структуры добавляемого регулятора

Ранее были сгенерированы правила с использованием функциональных схем систем регулирования температуры, построенных на регуляторах БК14, ТРМ151, Термодат12 для структурных схем «ИП-РУ-ИУ», «2ИП-РУ-2ИУ», «3ИП-РУ-ИУ» (ИП-измерительный преобразователь, РУ-регулятор, ИУ-исполнительное устройство). Данные правила отображены в таблице.

В ТЗ на проектирование включены ТСМ9620 (id=5), термопара ТХК9414 (id=6), мех. электр. однооб. МЭО40 (id=26), лампа сигн.(id=12) Rule 1. if REG equal БК1 мод.14 then [IP1=5(7,16, or 7,9,) OR 6(10,16, or 10,9,)]; Rule 2. if REG equal Термодат12 then [IP1=5(null,) OR 6(null,)]; Rule 3. if REG equal ТРМ151 then [IP1=5(null,) OR 6(null,)]; Rule 4. if REG equal БК1 мод.14 then [IM1=12(8) OR 26(13,)]; Rule 5. if REG equal Термодат12 then [IM1=12(null,) OR 12(8,)]; Rule 6. if REG equal ТРМ151 then [IM1=26(13,) OR 12(8,)];

В ТЗ на проектирование включены ТСМ9620 (id=5), термопара ТХК9414 (id=6), механизм электрический однооборотный МЭО40 (id=26), лампа сигнальная (id=12) Rule 1. if REG equal БК1 мод.14 then [IP1=5(7,16,or 7,9,) OR 6(10,16, or 10,9,)]; [IP2=5(7,16, or 7,9,) OR 6(10,16,or 10,9,)]; Rule 2. if REG equal Термодат12 then [IP1=5(null,) OR 6(null,)]; Rule 3. if REG equal ТРМ151 then [IP1=5(null,)OR 6(null,)]; [IP2=5(null,) OR 6(null,)]; Rule 4. if REG equal БК1 мод.14 then [IM1=12(8,) OR 26(13,)]; [IM2=12(8,) OR 26(13,)]; Rule 5. if REG equal Термодат12 then [IM1=12(null,)OR12(8,)];[IM2=12(null,)OR 12(8,)] Rule 6. if REG equal ТРМ151 then [IM1=26(13,) OR 12(8,)]; [IM2=26(13,) OR 12(8,)]

В ТЗ на проектирование включены ТСМ9620 (id=5), механизм электрический однооборотный МЭО40 (id=26) Rule 1. if REG equal БК1 мод.14 then [IP1=5(7,16,or 7,9,) OR 6(10,16, or 10,9,)]; [IP2=5(7,16, or 7,9,) OR 6(10,16,or 10,9,)]; [IP3=5(7,16, or 7,9,)]; Rule 2. if REG equal Термодат12 then [IP1=5(null,) OR 6(null,)]; Rule 3. if REG equal ТРМ151 then [IP1=5(null,)OR 6(null,)]; [IP2=5(null,) OR 6(null,)]; Rule 4. if REG equal БК1 мод.14 then [IM1=12(8,) OR 26(13,)]; [IM2=12(8,) OR 26(13,)]; Rule 5. if REG equal Термодат12 then [IM1=12(null,)OR12(8,)];[IM2=12(null,)OR 12(8,)] Rule 6. if REG equal ТРМ151 then [IM1=26(13,) OR 12(8,)]; [IM2=26(13,) OR 12(8,)]

По входным составляющим функций преобразования у данного регулятора есть совпадение с контроллерами БК14 (унифицированный сигнал 0-2В), ТРМ151 и Термодат12 (50М – условное обозначение выходного сигнала термометра сопротивления, Uxk — условное обозначение выходного сигнала термопары). Дискретный выход (0/1) присутствует у всех вышеупомянутых регуляторов. В процессе анализа правил установлено, что измерительную цепь канала 1 можно взять от БК14, а канала 3 – от ТРМ151 или Термодат12. Для формирования измерительной цепи канала 1, согласно сгенерированным правилам, будут проверяться элементы с идентификаторами 16 и 9, и если тип и диапазон выходного сигнала позволит их подсоединить к регулятору, то альтернативами измерительных цепей канала 1 станут последовательные соединения элементов: 5,7,16; 5,7,9; 6,10,16; 6,10,9. Аналогично для измерительного канала 3, только термопара или термометр сопротивления будут присоединяться к регулятору напрямую.

Для указанного регулятора, используя представленные правила, сгенерированы 32 варианта функциональных схем, соответствующих структурной схеме «2ИП-РУ-ИУ»:

Рис. 3. Примеры функциональных схем, сгенерированных на добавленном в базу данных регуляторе

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

Литература:

1. Ахремчик, О.Л. Система проектирования функциональных и принципиальных схем автоматизации / О.Л. Ахремчик, Н.Н. Филатова, Н.И. Бодрина // Труды международного конгресса по интеллектуальным системам и информационным технологиям «AIS-IT’09». М.: Физматлит, 2009. Т.1. С. 73-80.

2. Структурный синтез на элементах с ограниченной сочетаемостью [Электронный ресурс]. – Режим доступа: http://www.metodolog.ru/00562/00562.html. – 2009.

3. Ильин, В.Н. Автоматизация схемотехнического проектирования / В.Н. Ильин, В.Т. Фролкин, А.И. Бутко. – М.: Радио и связь. 1987. – 368 c.

4. Филатова, Н.Н. Автоматическая генерация деревьев схемотехнических решений / Н.Н. Филатова, А.Г. Требухин, О.Л. Ахремчик // Труды международного конгресса по интеллектуальным системам и информационным технологиям «AIS-IT’11». М.: Физматлит, 2011. Т.2. С. 122-130.

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

Ассоциация измерений, управления и автоматизации

% PDF-1.6 % 2021 0 объект > эндобдж 2016 0 объект [/ CalRGB>] эндобдж 2015 0 объект [/ CalGray>] эндобдж 2055 0 объект > эндобдж 2019 0 obj > поток Acrobat PDFWriter 4.0 для Windows 7 июля, 20032003-06-12T18: 57: 14Z2008-03-13T14: 47: 19-04: 002008-03-13T14: 47: 19-04: 00FunctionalDiagramming22-1-1981 — Microsoft Wordapplication / pdf

Ассоциация измерений, управления и автоматизации

Функциональная схема 1

uuid: 53a7d0cb-9482-4d28-99ca-3b78bf94c66buuid: 44b0369b-bf12-463f-88a1-a325b53af677 конечный поток эндобдж 2023 0 объект > / Кодировка >>>>> эндобдж 2014 0 объект > эндобдж 2022 0 объект > эндобдж 2056 0 объект > эндобдж 2057 0 объект > эндобдж 2098 0 объект > эндобдж 2099 0 объект > эндобдж 2100 0 объект > эндобдж 2101 0 объект > эндобдж 2104 0 объект > эндобдж 2102 0 объект > эндобдж 2103 0 объект > эндобдж 2082 0 объект >] / P 2080 0 R / S / Link / Pg 2037 0 R >> эндобдж 2095 0 объект >] / P 2093 0 R / S / Link / Pg 2037 0 R >> эндобдж 2093 0 объект > эндобдж 2037 0 объект > / ColorSpace> / Font> / ProcSet [/ PDF / Text / ImageC / ImageI] / ExtGState >>> / Type / Page >> эндобдж 2047 0 объект [2050 0 R 2048 0 R] эндобдж 2011 0 объект > эндобдж 2046 0 объект > поток HW] | ا: I.BϴŰ pt.Hlvk? \ V) r? M: & F » Oy6UnED, Zg ~ qhznWIs% g0SRF: ܢ {

Функциональная схема автоматизации

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

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

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

Задачи функциональной автоматизации обычно реализуются техническими средствами, в том числе:

— Выбор устройства;

— средства получения первичной информации;

— средства преобразования и обработки информации;

— Средства представления и доставки информации обслуживающего персонала и др.

Автоматизация функциональных схем на основе результатов — это:

— Выбор метода измерения параметров процесса;

— Подбор основных технических средств автоматизации, наиболее соответствующих вашим требованиям и условиям работы пресид объекта;

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

— Размещение средств автоматизации на щитах и ​​консолях, на технологическом оборудовании или месте;

— Определение способов предоставления информации о состоянии процесса и оборудования.

Что такое, инструменты и примеры

Что такое тестирование на основе моделей?

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

Доступно множество моделей, описывающих различные аспекты поведения системы. Примеры модели:

• Поток данных
• Поток управления
• Графики зависимостей
• Таблицы решений
• Машины перехода между состояниями

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

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

В этом руководстве вы изучите

Пример тестирования на основе модели

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

Типы MBT:

Существует два типа инфраструктуры тестирования на основе моделей.

1. Offline / a priori: Создание наборов тестов перед их выполнением. Набор тестов — это не что иное, как набор тестовых примеров.
2. Онлайн / на лету: Создание наборов тестов во время выполнения теста

Различные модели в тестировании:

Чтобы понять MBT, необходимо понять некоторые модели, описанные ниже. Давайте пройдемся по порядку:

Конечные автоматы

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

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

Рассмотрим пример —

Существует система, позволяющая сотрудникам входить в приложение. Теперь текущее состояние сотрудника — «Нет», и оно стало «Входит», когда он входит в систему. В состоянии «в» сотрудник может просматривать, распечатывать и сканировать документы в системе.

Диаграммы состояний

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

Например —

Дефекты возникают в средстве управления дефектами со статусом Новый. После того, как разработчики исправят его, его необходимо изменить на статус «Исправлено».Если дефект не устранен, измените статус на Повторно открыть. Диаграмма состояний должна быть разработана таким образом, чтобы вызывать событие для каждого состояния.

Унифицированный язык моделирования (UML)

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

UML имеет такие обозначения, как:

• Действия
• Участники
• Бизнес-процесс
• Компоненты
• Язык программирования

Проблемы модельно-ориентированного тестирования:

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

• Необходимые навыки, необходимые для тестировщиков
• Время обучения будет больше
• Трудно понять саму модель

Преимущества тестирования модели:

Ниже приведены преимущества MBT:

• Простое обслуживание тестового набора / набора
• Снижение затрат
• Улучшенное покрытие тестами
• Может запускать различные тесты на n машинах
• Раннее обнаружение дефектов
• Увеличение количества дефектов
• Экономия времени
• Повышение удовлетворенности работой тестировщика

Заключение

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

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

Изучение подходов к созданию автоматизированных тестовых случаев с помощью диаграмм UML — IJERT

Н. К. Шарма Дивья Саксена

Тестирование программного обеспечения является решающим этапом жизненного цикла разработки программного обеспечения (SDLC). Тестирование включает выполнение программы на наборе тестовых примеров и сравнение фактических результатов с ожидаемыми.Сценарии тестирования описывают тесты, которые необходимо запустить в программе, чтобы убедиться, что программа работает должным образом. Чтобы сократить затраты времени и сократить расходы на ручное тестирование, исследователи и практики предложили различные инструменты и методы для автоматизации тестирования программного обеспечения, которые увеличивают надежность программного обеспечения. В целом, этап тестирования программного обеспечения занимает около 40-70% времени и затрат в течение жизненного цикла разработки программного обеспечения. Для автоматического тестирования программного обеспечения лучшим способом является создание тестовых примеров.Один из способов создания тестовых примеров — использование диаграмм UML. В этой статье мы изучаем различные подходы, используемые для создания тестовых примеров из диаграмм UML для автоматического тестирования программного обеспечения.

Ключевые слова: тестовый пример, UML, автоматическая генерация тестового примера, тестирование на основе модели.

Введение

Тестирование программного обеспечения — важный вид деятельности в жизненном цикле разработки программного обеспечения. Это исследовательская деятельность, направленная на предоставление всем заинтересованным сторонам информации о качестве данного программного обеспечения или приложений.Организации-разработчики программного обеспечения тратят значительную часть своего бюджета на деятельность, связанную с тестированием. Хорошо протестированная программная система будет проверена заказчиком перед приемкой. При разработке программного обеспечения программные организации тратят около 50% своего бюджета на задачи, связанные с тестированием. Это обеспечивает эффективность программного обеспечения и правильность программного обеспечения. Тестирование можно проводить вручную или автоматически. Автоматическое тестирование — лучший способ тестирования программного обеспечения, поскольку оно занимает меньше времени и дает точный результат, чем ручное тестирование.Тестовый пример в программной инженерии

— это набор условий или переменных, при которых тестировщик определяет, правильно ли работает приложение или программная система. Тестовый пример создается из UML с использованием объектных диаграмм. UML — это унифицированный язык моделирования, который используется для создания визуальных моделей программной системы. Эти модели могут помочь в создании проектов, а также в анализе и обзоре этих моделей. В UML есть различные типы диаграмм, отображающих динамическое поведение объектов в системе.Unified Modeling Language — это широко распространенный набор обозначений для моделирования объектно-ориентированных систем. Используются разные методы, в которых используются разные подходы для создания тестовых примеров из диаграммы объектов.

Обзор литературы

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

Since Unified Modeling Language (UML) — это стандартизированный язык моделирования общего назначения в области разработки программного обеспечения. Диаграммы UML представляют два разных представления модели системы: статическое и динамическое. Статическое (или структурное) представление: подчеркивает статическую структуру системы с использованием объектов, атрибутов, операций и отношений.Структурный вид включает диаграммы классов и диаграммы составной структуры. Динамическое (или поведенческое) представление: подчеркивает динамическое поведение системы, показывая взаимодействие между объектами и изменения внутреннего состояния объектов. Это представление включает последовательность

диаграмм, диаграмм деятельности и диаграмм конечных автоматов. Согласно приведенному ниже жизненному циклу разработки программного обеспечения водопада (SDLC), в основном, в цикле есть пять этапов, а именно:

1. Требования

2. Проект

3. Реализация (также известная как разработка)

4. Проверка (также известная как тестирование программного обеспечения)

5. Техническое обслуживание.

Этап тестирования программного обеспечения — это процесс выполнения программы или системы с целью поиска ошибок. [1]. Он включает в себя любую деятельность, направленную на оценку атрибута или возможности программы или системы и определение того, что она соответствует требуемым результатам [2]. Тестирование программного обеспечения является важным видом деятельности в SDLC. Проще говоря, он обеспечивает контроль качества путем наблюдения за выполнением программной системы, чтобы проверить, ведет ли она себя так, как задумано, и выявить потенциальные неисправности.Более ранние исследования показали, что на тестирование может уйти пятьдесят процентов или даже больше затрат на разработку [3], в то время как подробный опрос в Соединенных Штатах [4] позволил количественно оценить высокие экономические последствия неадекватной инфраструктуры тестирования программного обеспечения. Процесс тестирования программного обеспечения, предоставленный Пэном [5] из Университета Карнеги-Меллона, описывает общий процесс выполнения действий по тестированию программного обеспечения.

1. Анализ требований: тестирование программного обеспечения должно начинаться на этапе требований SDLC.На этапе проектирования инженеры по тестированию программного обеспечения работают с разработчиками, чтобы определить, какие аспекты проекта можно тестировать и с какими параметрами работают эти тесты.

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

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

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

5. Отчет о тестировании: после выполнения тестовых примеров инженеры по тестированию программного обеспечения генерируют метрики и составляют окончательные отчеты о своих усилиях по тестированию, а также о том, готово ли тестируемое программное обеспечение к выпуску.

6. Анализ результатов тестирования (также известный как анализ дефектов): этот шаг выполняется группой тестирования. Обычно это делается вместе с клиентом, чтобы решить, какие дефекты следует обработать, исправить, отклонить (т. Е. Обнаружить, что программное обеспечение работает должным образом) или отложить их исправление на более позднее время.

7. Повторное тестирование устраненных дефектов: Когда дефект был устранен группой разработчиков, тест необходимо запустить снова.

8. Регрессионное тестирование: Обычно небольшая тестовая программа строится на основе подмножества тестов для каждой интеграции нового, модифицированного или фиксированного программного обеспечения, чтобы гарантировать, что последняя поставка ничего не испортила. Кроме того, этот шаг гарантирует, что программный продукт в целом по-прежнему работает правильно.

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

Метод, основанный на модели, идентифицирует соответствующий тестовый пример для программного обеспечения в отношении диаграмм UML, таких как активность, диаграмма состояний, диаграмма объектов и т. Д. Тестирование с ориентацией на пути, основанное на статическом, а также динамическом потоке управления программным обеспечением.Статическое тестирование пути выполняется символьным исполнением, динамическое тестирование пути основано на тесте времени выполнения исполняемой программы. Целенаправленные методы определяют тестовые примеры, охватывающие выбранную цель, такую ​​как утверждение или ветвь, независимо от пройденного пути.

M.Prasanna et al. (2009) показывает, что для тестирования программного обеспечения лучшим способом является создание тестовых примеров. Тестовые примеры получены путем анализа динамического поведения объектов из-за внутренних и внешних стимулов [6]. Исследователи используют подход, основанный на модели, в котором метод кроссовера генетических алгоритмов применяется к диаграмме классов, а обход выполняется с помощью алгоритма поиска в глубину (DFS).Этот подход с древовидной структурой в сочетании с генетическим алгоритмом показывает, что он способен выявить 80% ошибок на уровне единиц и 88% ошибок на уровне интеграции. Они объединяют генетический алгоритм с тестированием на мутации, чтобы проверить эффективность процесса тестирования, который показывает эффективность 80,3%.

A.V.K Shanth et al. (2011) предложили другой подход, основанный на модели, в котором используется концепция интеллектуального анализа данных, в которой метод эволюционного генетического алгоритма применяется к диаграмме классов и генерирует тестовые примеры [7].Они показывают, что эволюционный генетический алгоритм дает оптимальный допустимый тестовый пример, чем только с оператором генетического кроссовера, после применения алгоритма поиска в глубину. Преимущества заключаются в том, что тестирование на основе спецификации использует информацию, полученную из спецификации, для помощи в тестировании, а также для разработки программы.

Исследователи G.Mohan Kumar, A.V.K.Shanthi (2012) использовали некоторые новые подходы для тестирования программного обеспечения на самом начальном этапе, что облегчит тестировщикам программного обеспечения возможность тестирования программного обеспечения на более позднем этапе [8].Вот они берут схему последовательности. Результаты эксперимента показывают, что этот метод более эффективен. Все возможные тестовые примеры генерируются и проверяются с помощью приоритезации.

Sangeeta sabhwal, Ritu sibal, Chayanika Sharma (2011) рассматривают в своей статье другой новаторский подход, в котором эффективность тестирования оптимизируется путем применения генетического алгоритма к тестовым данным. Для изменения требований предлагается подход на основе стека для присвоения весов диаграмме объектов узлов [9].Здесь сначала генерируется диаграмма последовательности, а затем из диаграммы последовательности генерируется граф зависимостей последовательностей, и к нему применяется генетический алгоритм [10].

Ранджит Суэйн, Викас Панти, Дурга Прасад (2012) использовали метод функциональной минимизации для создания тестовых примеров. В этом методе, в котором используется метод STUPEC [11], в котором сначала выбирается предикат, затем предикат преобразуется, а затем генерируются тестовые примеры. Метод минимизации функционала используется для нахождения минимума функции предиката.При таком подходе тестовые примеры генерируются шаг за шагом. Здесь диаграмма объектов, которая используется для создания тестовых примеров, является диаграммой конечного автомата. Этот подход охватывает большую часть покрытия, такое как покрытие состояний, покрытие переходной пары, покрытие действия. Сведено к минимуму количество тестовых примеров, которые обеспечивают покрытие пути перехода путем тестирования границ, определяемых простым прогнозированием.

L.C.Briand et al. (2008) в своей статье предложил метод, поддерживаемый прототипом инструмента, для решения проблемы выбора регрессионного теста на уровне дизайна.Основная цель заключалась в обеспечении безопасности регрессионного тестирования при минимизации усилий по регрессии.

Алессандра Каварра, Тьерри Джерон, Алан Хартман ISSTA (2002) представляет архитектуру для тестирования на основе моделей с использованием профиля унифицированного языка моделирования (UML). Диаграммы классов, объектов и состояний используются для определения основной модели. Для создания тестовых примеров

автоматически, используется инструмент генерации типа AGEDIS test [12]. Инструмент генерации тестов AGEDIS основан на принципах двух существующих инструментов: TVG и GOTCHA.Основным преимуществом инструмента генерации тестовых случаев AGEDIS является его способность комбинировать различные директивы тестирования: критерии покрытия, цели тестирования и ограничения тестирования.

Методы создания тестовых примеров

Создание тестовых примеров всегда было неотъемлемой частью процесса тестирования. Существует много типов методов генерации тестовых примеров [13], таких как методы на основе спецификаций, методы на основе схематических диаграмм и методы на основе исходного кода. Случайные методы определяют набор тестовых примеров на основе предположений о распределении неисправностей.Методы, основанные на исходном коде, обычно используют граф потока управления для определения путей, которые должны быть покрыты, и создания соответствующих тестовых примеров для этих путей. Целенаправленные методы определяют тестовые примеры, охватывающие выбранную цель, такую ​​как утверждение или ветвь, независимо от пройденного пути.

1. Методы, основанные на спецификациях

   Методы, основанные на спецификации, — это методы для генерации набора тестовых примеров из документов спецификации, таких как формальная спецификация требований [14], [15], [16], [17].Спецификация точно описывает, что должна делать система, без описания того, как это делать. Преимущества этого метода заключаются в том, что документ спецификации может использоваться для получения ожидаемых результатов для тестовых данных и что тесты могут разрабатываться одновременно с проектированием и реализацией. Документ технических требований может использоваться в качестве основы для проверки выходных данных, что значительно снижает одну из основных затрат на тестирование. Спецификации также могут быть проанализированы на предмет их проверяемости [18].Более того, методика, основанная на спецификациях, предлагает более простой, структурированный и более формальный подход к разработке функциональных тестов, чем методы тестирования, не основанные на спецификациях. Тесная связь между спецификацией и тестами помогает находить ошибки и может упростить регрессионное тестирование. Процесс создания тестов на основе спецификаций часто помогает инженеру по тестированию обнаруживать проблемы с самими спецификациями. Если этот шаг выполняется на ранней стадии, проблемы могут быть устранены на раннем этапе, что позволяет сэкономить время и ресурсы.

2. Методы построения эскизных диаграмм

   Методы

   , основанные на схематических диаграммах, представляют собой методы для генерации тестовых примеров из модельных диаграмм, таких как диаграмма вариантов использования UML [19], [20], [21], [22] и состояние UML

   .

   диаграмм [23], [24], [25], [26]. Основное преимущество верификации и верификации на основе моделей состоит в том, что ее можно легко автоматизировать, что позволяет экономить время и ресурсы. Другими преимуществами являются перенос действий по тестированию на более раннюю часть процесса разработки программного обеспечения и создание тестовых примеров, которые не зависят от какой-либо конкретной реализации проекта [19].Методы генерации тестовых примеров на основе схематических диаграмм были предложены для традиционных и веб-приложений в течение длительного времени. Джим [20] представил, как использование вариантов использования для создания тестовых примеров может помочь запустить процесс тестирования на ранних этапах жизненного цикла разработки, а также помочь с методологией тестирования. В проекте разработки программного обеспечения варианты использования определяют требования к системному программному обеспечению. Разработка вариантов использования начинается на ранней стадии, поэтому реальные варианты использования ключевых функций продукта доступны на ранних итерациях.Веб-приложения становятся все сложнее, и их правильное тестирование — серьезный бизнес. Маниш

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

3. Методы, основанные на исходном коде

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

   1. ID тестового примера

   2. данные испытаний

   3. тестовая последовательность (также известная как тестовые шаги)

   4. ожидаемый результат

   5. фактический результат и

   6. Pass / Ail статус.

   Методы, основанные на исходном коде, обычно используют информацию о потоке управления, чтобы идентифицировать набор путей, которые должны быть покрыты, и генерировать соответствующие тестовые примеры для этих путей.Эти методы можно дополнительно разделить на статические и динамические. Статические методы часто основаны на символическом исполнении, например. [27], тогда как динамические методы получают необходимые данные, выполняя тестируемую программу

   например [28].

Подходы к созданию тестовых примеров

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

1. Создание тестового набора на основе сценария

   Генерация тестовых случаев на основе сценариев основана на параллельном приложении, используемом в использованных тематических исследованиях. Байкута Нараян Бисвал [23] представил доклад о новом подходе к созданию тестовых примеров на основе сценариев. Они предложили тестирование на основе сценариев, тестовые сценарии используются для создания тестовых случаев.Диаграммы действий UML описывают реализацию операции на этапе проектирования, а также прекрасно поддерживают описание параллельных действий и аспектов синхронизации, задействованных в различных действиях. В данной статье рассматриваются критерии адекватности теста. Тестирование сценариев лучше всего подходит для сложных транзакций или событий, для изучения сквозного предоставления преимуществ программы, для изучения того, как программа будет работать в руках опытного пользователя, и для разработки более убедительных вариантов ошибок, обнаруженных с помощью другие подходы.

   Тестирование параллельных приложений, описанное Чанг-аем Сун [29], также использует диаграмму активности UML для создания тестового примера. В документе «Подход на основе преобразования к созданию сценариев-ориентированных тестовых примеров из диаграмм активности UML для параллельных приложений» продвигается основанный на преобразовании подход к созданию ориентированных на сценарии тестовых примеров для тестирования параллельных приложений, смоделированных с помощью диаграмм активности UML. Параллельное поведение недетерминировано

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

   Генерация тестовых примеров из диаграмм активности UML, представленных Хёнчхолом Кимом [30], также основывается на параллелизме в диаграмме активности, то есть параллельной системе, в которой несколько объектов взаимодействуют друг с другом. Предлагаемый метод генерирует контрольные примеры из диаграмм активности UML, которые минимизируют количество генерируемых контрольных примеров при выводе всех практически полезных контрольных примеров.

   Дизайн тестового примера с использованием условного нарезания диаграммы активности Митрабинды Рэй, Субхагья Санкар Барпанда и Дурга Прасад Мохапатра представляет условное нарезание как общую структуру нарезки для генерации тестового примера из диаграммы активности [31].Метод сначала строит поток

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

2. Генерация тестовых примеров на основе моделей

   Генерация тестовых примеров на основе моделей не менее сложна, и многие исследования также требуют достижения оптимального набора тестовых примеров. Автоматическая генерация тестовых случаев с использованием диаграмм состояний унифицированного языка моделирования (UML) П. Самуэля, Р. Малла и А.К. Ботра опубликовал тестовые примеры на основе модели автоматически. Используется подход, логика управления и потока данных, доступная на диаграмме состояний UML для генерации тестовых данных. Граф конечного автомата просматривается и выбираются условные предикаты для каждого перехода. Затем эти условные предикаты преобразуются, и для создания тестовых примеров применяется метод минимизации функций. Настоящая схема генерации тестовых данных полностью автоматическая, и сгенерированные тестовые примеры удовлетворяют критериям покрытия пути перехода.Сгенерированные тестовые примеры могут использоваться для тестирования поведения классов, а также зависимостей от состояния на уровне кластера [32].

   «Генерация тестовых примеров с помощью диаграмм последовательностей UML и систем помеченных переходов», разработанная Эмануэлой Картаксо, представила диаграмму последовательности UML в области создания тестовых примеров. Функция — это приращение функциональности, обычно имеющее определенную цель, которое добавляется поверх базовой системы. Функции обычно разрабатываются и тестируются отдельно от базовой системы в виде независимых модулей.Процедура основана на методах тестирования на основе моделей с тестовыми примерами, сгенерированными из диаграмм последовательностей UML, переведенными в системы маркированного перехода (LTS) [33]. Идея состоит в том, чтобы повторно использовать диаграммы последовательности, созданные группами разработчиков, для определения вариантов использования с базовыми и альтернативными сценариями. Разработка программного обеспечения на основе моделей основана на настройке моделей системы, которую необходимо построить. Этот подход оказался полезным, потому что он позволяет разработчикам сначала разработать наиболее важные свойства программного обеспечения, прежде чем приступить к реализации.

   В статье «Генерация тестовых примеров из машин состояний UML», представленной Дирком Зайфертом, подробно описаны тестовые примеры, включающие не только стимулы для запуска тестируемой системы, но и возможные правильные наблюдения для автоматической оценки выполнения тестового примера [34].

   Автоматизированное создание тестового примера с использованием диаграмм состояний UML. Авторы Supaporn Kansomkeat и Wanchai Rivepiboon экспериментировали с методом автоматического тестирования, чтобы частично решить процесс тестирования. Этот метод позволяет автоматически генерировать и выбирать тестовые примеры из диаграмм состояний UML.Сначала преобразуйте эту диаграмму в промежуточную диаграмму,

   , называемый Testing Flow Graph (TFG), явно идентифицирует потоки диаграмм диаграмм состояний UML и улучшает их для тестирования. Во-вторых, из TFG сгенерировать тестовый пример с использованием критериев тестирования, то есть покрытия состояния и переходов диаграмм. Наконец, оценка выполняется с помощью анализа мутаций, чтобы оценить способность наших тестовых примеров выявлять ошибки [35].

   Генерация тестовых примеров на основе прецедентов и диаграмм последовательности Сантош Кумар Суэйн, Дурга Прасад Мохапатра и Раджиб Молл иллюстрируют тестовые примеры, полученные на основе артефактов анализа, таких как варианты использования, соответствующие им диаграммы последовательностей и ограничения, указанные для всех этих артефактов.Постройте граф зависимостей вариантов использования (UDG) на основе диаграммы вариантов использования и графа параллельного управления (CCFG) на основе соответствующих диаграмм последовательности для генерации тестовой последовательности. Сосредоточьте тестирование на последовательностях сообщений среди объектов сценариев вариантов использования [36].

3. Генерация тестовых примеров на генетической основе

   Автоматическая генерация тестовых примеров для диаграмм объектов UML с использованием генетического алгоритма, представленная М. Прасанной и К.Р. Чандран использовал для создания оптимальных тестовых примеров, которые также можно рассматривать как подход к интеллектуальному анализу данных.

   Представлена ​​автоматизированная генерация тестовых примеров в объектно-ориентированных системах. Тестовые примеры получены путем анализа динамического поведения объектов из-за внутренних и внешних стимулов. Объем статьи был ограничен диаграммами объектов, взятыми из модели системы Unified Modeling Language. Кроссовер дерева генетических алгоритмов был предложен для выявления всех возможных тестовых примеров данной диаграммы объекта [12]. Экспериментальные результаты показывают, что он способен выявлять 80% отказов на уровне блока и 88% отказов на уровне интеграции.

Заключение

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

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

Список литературы

Майерс, Гленфорд Дж., Искусство тестирования программного обеспечения, Информация о публикации: Нью-Йорк: Wiley. ISBN: 0471043281, 1979.

Хетцель, Уильям К., Полное руководство по тестированию программного обеспечения, 2-е изд. Информация о публикации: Wellesley, Mass .: QED Information Sciences. ISBN: 0894352423, 1988.

Б. Байзер, Методы тестирования программного обеспечения, Van Nostrand Reinhold, Inc, Нью-Йорк, штат Нью-Йорк, 2-е издание. ISBN: 0-442-20672-0, 1990.

NIST, Экономические последствия неадекватной инфраструктуры для тестирования программного обеспечения, 2002.

Пан, Цзяньтао, тестирование программного обеспечения (надежные встроенные системы 18-849b), факультет электротехники и вычислительной техники, Университет Карнеги-Меллона, 1999.

Л. К. Бриан, Ю. Лабиш, С. Хе, Автоматизация выбора регрессионных тестов на основе конструкций UML, Информационные и программные технологии 51 (2009) 16-30.

Сангита Сабхарвал, Риту Сибал, Чаяника Шарма, Применение генетического алгоритма для определения приоритетов сценариев тестовых случаев, полученных из диаграмм UML, Международный журнал компьютерных наук, выпуск 8, выпуск 3, номер 2, май 2011 г., стр. 433-444 .

А.В.К. Шанти, Г. Мохан Кумар, Автоматизированная генерация тестовых примеров из диаграммы последовательности UML, Международная конференция по программному обеспечению и компьютерным приложениям, т.41, 2012, с. 83-89.

Марлон Виейра, Йоханн Ледук, Билл Хаслинг, Раджеш Субраманян, Юрген Казмайер, Автоматизация тестирования графического интерфейса пользователя с использованием подхода модельного драйвера, Материалы международного семинара по автоматизации тестирования программного обеспечения, 2006 г., стр. 9-14.

Филп Сэмюэл, Р. Молл, А. К. Ботра, Автоматическая генерация тестовых примеров с использованием диаграммы состояний UML, Программное обеспечение IET, 2008, стр. 79-93.

А.В.К. Шати, Г. Мохан Кумар, Эвристический подход для автоматизированного создания тестовых примеров из диаграммы последовательностей с использованием алгоритма поиска табу, Европейский журнал научных исследований, т.85, No 4, сентябрь 2012 г., стр. 534-540.

М. Прасанна, К. Р. Чандран, Автоматическая генерация тестовых примеров для объектных диаграмм UML с использованием генетического алгоритма, Int. J. Advance. Мягкий расчет. Appl., Vol.1, no. 1, июль 2009 г., стр. 19-32.

М. Прасанна С.Н. Сиванандам Р. Венкатесан Р. Сундарраджан, Обзор автоматического создания тестовых примеров, Academic Open Internet Journal, 2005.

Хунг Тран, Генерация тестов с использованием проверки моделей, Продолжающаяся конференция по автоматизированной проверке, 2001.

Мяо Хуайкоу и Лю Лин, Структура тестовых классов для создания тестовых случаев из спецификаций Z, 2000.

Перси Антонио, Пари Салас и Бернхард К. Айчерниг, Автоматическая генерация тестовых примеров для OCL: мутационный подход, 2005.

Ричард А. Де Милло и А. Джефферсон Оффатт, Автоматическое создание тестовых данных на основе ограничений, IEEE Transaction on Software Engineering, 1991.

Айнур Абдуразик и Джефф Оффутт, Создание тестовых примеров из спецификаций UML, 1999.

A.Z. Джавед, П.А. Штрупер и Г. Уотсон, Автоматизированное создание тестовых примеров с использованием модельно-управляемой архитектуры, Второй международный семинар по автоматизации тестирования программного обеспечения (AST07), 2007.

Джим Хойман, Создание тестовых примеров из вариантов использования, Rational Software, 2001.

Йоханнес Райзер и Мартин Глинц, SCENT: метод, использующий сценарии для систематического получения тестовых примеров для системного тестирования, 2000.

Маниш Нилавар и д-р.Серджиу Даскалу, подход на основе UML к тестированию веб-приложений, магистр наук со специализацией в области компьютерных наук, Университет Невады, Рино, 2003 г.

Алессандра Каварра, Чарльз Крайтон, Джим Дэвис, Алан Хартман, Тьерри Джерон и Лоран Мунье, Использование UML для автоматического создания тестов, Вычислительная лаборатория Оксфордского университета, Инструменты и алгоритмы для построения и анализа систем, TACAS’2000, 2000.

Аннелиз Эндрюс, Джефф Оффатт и Роджер Т.Александр, Тестирование веб-приложений. Программное обеспечение и моделирование систем, 2004.

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

Дэвид К. Кунг, Чиен-Хунг Лю и Пей Сиа, Модель объектно-ориентированного веб-тестирования для тестирования веб-приложений, В трудах Первой Азиатско-Тихоокеанской конференции по качественному программному обеспечению (APAQS00), стр. 111, Лос-Аламитос, Калифорния, 2000 .

К. Рамамурти, С. Хо и В. Чен, Об автоматизированном создании данных тестирования программ, IEEE Transactions on Software Engineering, SE-2 (4): 293300, 1976.

Богдан Корел, Автоматическое создание тестовых данных программного обеспечения, IEEE Transaction on Software Engineering, 1990.

Чанг-ай Сунь, 2008 IEEE, «Подход на основе преобразования к созданию сценариев тестирования из диаграмм действий UML для параллельных приложений», Ежегодная международная конференция по компьютерному программному обеспечению и приложениям IEEE.

Хёнчул Ким, Сунгвон Кан, Чон Мун Байк, Инён Ко, «Генерация тестовых примеров на основе диаграмм активности UML», Восьмая международная конференция ACIS по разработке программного обеспечения, искусственному интеллекту, сетям и параллельным / распределенным вычислениям.

Митрабинда Рэй, Субхагья Санкар Барпанда, Дурга Прасад Мохапатра, «Разработка тестового случая с использованием условного разделения диаграммы активности», Международный журнал последних тенденций в инженерии, Vol. 1, вып.2 мая 2009 г.

P. Samuel, R. Mall, A.K. Ботра, «Автоматическое создание тестовых примеров с использованием диаграмм состояний унифицированного языка моделирования (UML)», опубликовано в IET Software.

Эмануэла Г. Картаксо, Франсиско Г. О. Нето и Патресия Д. Л. Мачадо, «Генерация тестовых примеров с помощью диаграмм последовательности UML и систем помеченных переходов», IEEE 2007.

Дирк Зайферт, «Генерация тестовых примеров из конечных автоматов UML», inria-00268864, версия 2 — 23 апреля 2008 г.

Супапорн Кансомкит и Санчай Ривепибун, «Автоматическое создание тестового примера с использованием диаграмм состояний UML», SAICSIT 2003.

Сантош Кумар Суэйн, Дурга Прасад Мохапатра и Раджиб Молл, «Создание тестового набора на основе варианта использования и

Sequence Diagram «, Int.J. of Software Engineering, IJSE Vol.3 No. 2 July 2010.

Как использовать пирамиду автоматизации тестирования

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

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

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

Использование пирамиды автоматизации тестирования

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

Пирамида автоматизации тестирования, впервые представленная Коном в Succeeding with Agile , показывает, как следует максимизировать автоматизацию, начиная с модульных тестов на нижнем уровне пирамиды и переходя к тестированию уровня обслуживания.Тестирование пользовательского интерфейса находится на самом верху. Модульные тесты быстрые и надежные. Уровень сервиса позволяет тестировать бизнес-логику на уровне API или сервиса, где вы не обременены пользовательским интерфейсом (UI). Чем выше уровень, тем медленнее и хрупче становится испытание. Наконец, хотя некоторая автоматизация тестирования пользовательского интерфейса должна быть выполнена, такие тесты медленнее, сложнее в обслуживании и легче ломаются. Сведите их к минимуму.

Основа: автоматизация модульного тестирования

Модульное тестирование — важная часть написания высококачественного кода.Когда люди в программных организациях говорят об автоматизации тестирования, они, как правило, думают о таких инструментах, как Unified Functional Testing (UFT) или Selenium, которые предоставляют фреймворки автоматизации тестирования. Однако разработчики должны писать большинство тестов автоматизации на уровне модульного тестирования.

Разработчики могут использовать инфраструктуры модульного тестирования, такие как xUnit или Microsoft Visual Studio Unit Testing Framework, для создания автоматических тестов для небольших единиц кода. Некоторые agile-команды используют разработку через тестирование — технику, при которой вы пишете модульный тест перед кодом, чтобы помочь в разработке кода.Некоторые разработчики сначала пишут код, но не считают его завершенным, пока не разработают связанный автоматизированный модульный тест. Вы можете оценить, был ли протестирован каждый путь кода, с помощью инструмента тестирования покрытия, такого как DotCover.

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

Средний уровень: к вашим услугам

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

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

Вишенка наверху: уровень пользовательского интерфейса

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

Благодаря продуманному дизайну тестов автоматизации, автоматизированные тесты пользовательского интерфейса прекрасно дополнят ваш набор тестов автоматизации. Если вам нужна дополнительная помощь, я рекомендую статью Криса МакМахона «Автоматическое тестирование: семь советов по функциональному дизайну». В нем МакМахон предлагает технические советы по созданию мощных и удобных в обслуживании тестов автоматизации пользовательского интерфейса.

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

Продолжайте изучать

Тестирование API и способы его выполнения

Начало работы с тестированием API

Здесь, в SoapUI.org, мы стремимся сделать тестирование API простым и надежным для всех. Мы считаем, что тестирование API — это важная часть жизненного цикла разработки API, и о нем нельзя забывать.

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

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

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

Что такое тестирование API?

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

Тестирование

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

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

API — это то, что придает ценность приложению. Именно это делает наши телефоны «умными» и упрощает бизнес-процессы. Если API не работает эффективно и результативно, он никогда не будет принят, независимо от того, бесплатный он или нет. Кроме того, если API выходит из строя из-за того, что ошибки не были обнаружены, существует угроза взлома не только одного приложения, но и всей цепочки связанных с ним бизнес-процессов.

Вот некоторые из наиболее частых причин, по которым люди тестируют свои API:

1. Убедитесь, что он выполняет то, что должен делать
2. Убедитесь, что он выдержит нагрузку
3. Найдите все, что пользователи могут испортить
4. Убедитесь, что ваши API-интерфейсы работают на разных устройствах, браузерах и операционных системах
5. Это может быть не дорого до

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

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

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

Что нужно для начала тестирования API

Первая часть тестирования API включает настройку среды тестирования с необходимым набором параметров для API. Это включает настройку базы данных и сервера в соответствии с требованиями приложения.

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

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

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

• Кто ваша целевая аудитория? Кто ваш потребитель API?
• Какую среду следует использовать API?
• Какие аспекты вы тестируете?
• Какие проблемы мы тестируем?
• Каковы ваши приоритеты при тестировании?
• Что должно происходить в нормальных условиях?
• Что потенциально может произойти при нештатных обстоятельствах?
• Что определяется как «прошел» или «не прошел»? Какие данные являются желаемым результатом? Какая цепочка событий?
• С какими еще API может взаимодействовать этот API?
• Кто в вашей команде и что отвечает за тестирование?

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

Какие типы тестирования API я могу проводить?

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

Типы тестов, которые вы будете запускать, будут разными, но это общие примеры тестов API, как вы можете видеть, они очень похожи на причины, по которым вы хотите протестировать свой API:

• Проверка возвращаемых значений API на основе условия ввода
• Проверка, не возвращает ли API вообще ничего или неверные результаты
• Проверка, вызывает ли API какое-либо другое событие или вызывает ли другой API
• Проверка, обновляет ли API какие-либо структуры данных.

Сравнение ручного тестирования и автоматического тестирования

В чем разница между автоматическим и ручным тестированием? Автоматическое тестирование требует, чтобы вы использовали инструмент тестирования, например SoapUI, в то время как ручное тестирование состоит из написания собственного кода для тестирования API. Тестирование API — одна из областей, где настоятельно рекомендуется автоматическое тестирование, особенно в мире DevOps, гибкой разработки и непрерывных циклов доставки.

Вы должны использовать ручное тестирование при выполнении следующих тестов:

• Исследовательские испытания
• Юзабилити-тестирование
• Специальное тестирование

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

• Функциональное тестирование API
• Динамические испытания
• Повторный дизайн испытаний
• Анализ покрытия функциональными тестами, чтобы понять, что вам не хватает
• Тестирование производительности
• Протоколы тестирования в единой унифицированной среде
• Тестирование на основе данных
• Нагрузочное испытание
• Ошибка тестирования
• Тестирование на нескольких языках
• Регрессионное тестирование

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

Тестирование юзабилити

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

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

SoapUI с открытым исходным кодом

• Поддержка тестирования SOAP и REST API.
• Простое переключение в нескольких средах.
• Подробная история тестов и отчет о сравнении тестов.

SoapUI Pro

• Поддержка тестирования API SOAP, REST и GraphQL.
• Простое переключение в нескольких средах.
• Подробная история тестов и отчет о сравнении тестов.

Лучшие практики тестирования API

Прежде чем вы отправитесь в одиночку и начнете собственное тестирование API, вот 10 основных советов, которые мы хотим, чтобы вы запомнили при тестировании API!

1. Сначала проверьте типичные или ожидаемые результаты
2. Увеличьте нагрузку на систему с помощью серии нагрузочных тестов API
3. Тест на отказ.Убедитесь, что вы понимаете, как ваш API откажет. Просто убедитесь, что API не работает последовательно и изящно
4. Группировать тестовые примеры по тестовой категории
5. Расставьте приоритеты для вызовов функций API, чтобы тестировщикам было легко и быстро протестировать
6. Ограничьте тесты по как можно большему количеству переменных, сохраняя их как можно более изолированными
7. Посмотрите, как он справляется с непредвиденными проблемами и нагрузками, вкладывая в него как можно больше
8. Выполните хорошо спланированную последовательность вызовов
9. Для полного покрытия тестами создайте тестовые примеры для всех возможных комбинаций входных данных API
10. Автоматизируйте везде, где только можете

Бонус:

11. Если что-то не так, доверьтесь своему чутью!

Начните тестировать свои API сегодня

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

В нем реализованы передовые технологии и функции, которых нет в других инструментах тестирования. Универсальный автоматический инструмент тестирования SOAP и REST API, единственный в своем роде.

Никто не знает API лучше, чем SmartBear. Узнайте, что наша Pro-версия SoapUI может сделать для улучшения вашего тестирования.

Чтобы начать тестирование API, загрузите SoapUI Pro

Подробнее:

Состояние безопасности API

Вебинар: упрощение тестирования REST

Почему ваши цели тестирования не достигают отметки

5 лучших практик для тестирования на основе данных

Методики тестирования функциональных модулей

для практиков: Краткое руководство

♥ 0

Уважаемое сообщество тестировщиков,

Центр тестирования Sogeti Testlab в Штутгарте хочет дать вам краткое и практическое руководство по стандартным уровням тестирования, используемым в гибких SW-проектах.

Диаграмма 1. Тестовая пирамида — модульное тестирование должно создать прочную основу для всего охвата тестированием

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

Как показано в пирамиде тестов, давайте начнем с основного и базового уровня тестирования — модульного теста.

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

Диаграмма 2: 2 основных типа тестирования модульного тестирования

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

Определение модульного тестирования :

Давайте проследим за Роем Ошеровым, 2015, который определяет модульный тест следующим образом:

Диаграмма 3: Модульный тест в контексте представления пользователя

Модуль test подготовит и будет контролировать тестирование на основе графического интерфейса.

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

Диаграмма 4: Структура функционального модульного теста

Тестовые объекты:

Какие теперь основные тестовые объекты должны быть проверены модульным тестированием?

Для функциональных тестов в основном будут рассмотрены следующие три тестовых объекта:

Классы: вызовы классов (внутренний поток и зависимости)

Методы: тесты элементов (сгенерированные данные как возвращаемые значения)

Объекты: состояния объекта (состояние- на основе тестирования)

Классы будут проверены на предмет их зависимостей вызовов, как это разработано в i.е. Диаграммы последовательности UML. Методы будут проверены на правильность и полноту целевых бизнес-данных. Объекты будут проверены на предмет их правильного содержания, состояний и переходов между состояниями.

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

Общительные или пасьянс-тесты :

Диаграмма 5: Мартин Фаулер

Согласно Мартину Фаулеру, в сообществе программистов вы можете найти две «школы» юнит-тестеров.

Классическая школа :

«Классики» принимают зависимости тестируемых классов от других классов и открывают интерфейсы данных. Таким образом, они не используют t est doubles и работают с тестовыми данными, предоставленными соседними классами. Они делают тестов на общение . (то есть: метод цены вызывает функции из класса продукта и клиента). Предпосылка: ресурс данных должен быть стабильным, чтобы не нарушать определение, данное Роем Ошеровым.

Школа «mockist» :

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

Единичный анализ на основе рисков :

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

Сложность:

Согласно Роберту Биндеру, 2000, сложность класса состоит из

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

• немодальный : методы могут выполняться случайным образом, т.е. Дата и время
• одномодальный : методы могут выполняться только в определенном порядке т.е. TrafficLight
• Квази-модальный : Методы могут выполняться в зависимости от состояния объекта, т.е. Операции стека (Первый пришел, последний ушел)

Пример стека:

• Модальный : Методы могут только выполняться в определенном порядке и в зависимости от состояния объекта i.е. банковский счет

Диаграмма 6: Структура функционального модульного теста

Матрица критичности и рисков:

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

Диаграмма 7: Матрица рисков для оценки критичности

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

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

Хорошие письменные тестовые примеры должны следовать этим основным правилам:

Во время нашего семинара по модульным тестам необходимо выполнить шесть систематических и методических шагов для достижения готовности модульного тестирования для автоматизации доказано как Best Practice Подход:

Диаграмма 8: 6 шагов к автоматизированному функциональному модульному тесту

Требования к использованию или записи…

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

Диаграмма 9: Рабочая книга требований для тестера устройств

Сначала напишите логические тестовые примеры…. Базовый метод тестирования — это метод класса эквивалентности, при котором тестовые данные классифицируются во всех общих случаях, которые должна покрывать система.В одном из наших примеров мы использовали эту технику тестирования, чтобы протестировать обработку файлов данных. Как видно из следующей таблицы, мы определяем 1 плюс 7 логических тестовых случаев, чтобы охватить все сценарии, с которыми должен иметь дело тестовый объект.

Первый тестовый пример (первая строка) содержит действительные тестовые данные («1») 7 различных эквивалентных классов. Остальные семь тестовых случаев недействительны («0»). Недопустимый класс эквивалентности обозначается нулем в строке. Как мы знаем, для проверки недопустимого поведения системы только один класс эквивалентности должен содержать недопустимые тестовые данные.

Диаграмма 10: логический тестовый пример, основанный на методе класса эквивалентности

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

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

Ссылки

1. Биндер, Р .: Тестирование объектно-ориентированных систем: модели, шаблоны и инструменты. Ридинг, Массачусетс: Эддисон-Уэсли, 2000 [ISBN 0-201-74868-1].

2. Снид, Х.М., Винтер, М .: Программное обеспечение для тестирования объектов — Das Praxishandbuch für den Test Objektorientierter Client- / Serversysteme.Карл Хансер Верлаг, Мюнхен 2002 [ISBN 978-3-446-21820-8].

3. Лиггесмайер, Питер: Software-Qualität — Testen, Analysieren und Verifizieren von Software.

4. Spektrum Akademischer Verlag Heidelberg, 2009 [ISBN 978-3-8274-2056-5].

5. Голль, Иоахим, Мюллер-Хофманн, Франк, Хайниш, Корнелия, Ява, а также Programmiersprache-Vom Einsteiger zum Profi, Viehweg + Teubner Verlag, Висбаден, 2011, [ISBN 978-3-8348-0656-7].

6. Бек, Кент: J-unit, Pocket Guide, O‘Reilly Media, Gravenstein Highway North, Севастополь, 2004, [ISBN 978-3-8266-9712-8].

7. Ошеров, Рой: Искусство модульного тестирования — с примерами на C #.