Что такое птк тестирование
Структурные особенности ПТК на базе единой цифровой сети
В статье рассматривается ПТК «Торнадо-N», разработку которого завершила компания «Модульные Системы Торнадо». Описывается технический функционал ПТК, обоснована возможность использования разработки для построения систем автоматизации больших объектов в теплоэнергетике.
ЗАО «МСТ», г. Новосибирск
Основой автоматизированных систем управления технологическими процессами (АСУ ТП) являются программно-технические комплексы (ПТК). ПТК включают в себя следующие основные элементы: контроллеры, серверы, рабочие станции и т. д. Эти элементы составляют разные уровни и подсистемы, при этом связь между элементами на каждом уровне организована, как правило, по-своему. Обмен данными между устройствами в различных подсистемах распределенной АСУ обычно происходит только через сети вышестоящего уровня или другие промежуточные элементы.
Совершенно другие возможности открывает одноуровневая архитектура, при которой все элементы системы, включая и внутренние элементы контроллеров, объединены общей скоростной шиной. Таким образом, элементами ПТК становятся не контроллеры, а их составные части – УСО, процессорные устройства и другие интерфейсные устройства, входившие обычно в состав контроллера. Можно говорить о переходе от системы контроллеров к однородной среде управления. В качестве сетевой среды предлагается использовать локальную сеть Fast Ethernet. Такая структура ПТК позволяет любым устройствам в системе обмениваться данными напрямую, а не через сети вышестоящего уровня, как это организовано в большинстве современных распределенных СУ.
Именно по такому принципу построен новый ПТК «Торнадо-N», разработку которого завершила компания «Модульные Системы Торнадо». ПТК «Торнадо-N» построен на основе моносетевой архитектуры и может быть использован для построения систем автоматизации больших объектов в теплоэнергетике.
Модули MIRage-N используются в качестве УСО в составе ПТК «Торнадо-N» с интерфейсом Ethernet и выполняют следующие функции: электрическое сопряжение с полевыми устройствами посредством полевых кабелей, преобразование аналоговых сигналов в цифровую форму, преобразование управляющих воздействий в физические величины, нормирование и самодиагностику, проверку данных на достоверность и обмен информацией с устройством обработки.
В качестве устройств обработки в больших ПТК используются высокопроизводительные компьютеры, имеющие несколько портов Ethernet. Для построения эффективных, отказоустойчивых и высокопроизводительных структур требуется наличие у устройства обработки не менее четырех портов Ethernet. В ПТК «Торнадо-N» применяется промышленные компьютеры ARK-3382 фирмы Advantech. Устройства обработки в структуре ПТК «Торнадо-N» образуют дублированную структуру: один компьютер является рабочим, второй – резервным. Каждый компьютер имеет четыре независимых интерфейса Ethernet: один только для взаимодействия с УСО, второй для связи с верхним уровнем ПТК, третий из них используются как дублирующий для опроса блоков УСО и связи с верхним уровнем ПТК, четвертый – для обмена данными между рабочим и резервным компьютерами (рис. 2). Компьютеры синхронизированы, переключение с рабочего на дублирующий происходит безударно. Время переключения конфигурируется.
Объединение единой цифровой сетью всех элементов системы – это подлинно инновационный подход к проектированию АСУТП, дающий разработчику новую степень свободы. В результате возникает система, в которой реализованы все достоинства шины Fast Ethernet: универсальность; высокая производительность; малое и предсказуемое время прохождения сигнала; адресность передачи информации; простота настройки. Есть большая вероятность, что в будущем именно такая технология будет применяться наиболее широко для построения ПТК различных промышленных объектов.
Анатомия одного ПТК
Введение
Мы все ежедневно используем электричество, горячую воду и отопление. Но задумываемся о том, как и откуда все эти блага попадают к нам в дом или офис, мы значительно реже. А между тем, тут есть, на что посмотреть и о чем рассказать: ведь электростанции – это одни из самых крупных и сложных механизмов, управление которыми — весьма нетривиальная задача.
Теплоэлектростанции бывают разных типов: ТЭЦ, ГРЭС, ГТЭС и еще много других, но суть их работы от этого не меняется: на входе – полезные ископаемые, на выходе – тепло и электричество.
Вот так выглядит небольшой запас угля для угольной электростанции. Бульдозер время от времени перемешивает его, чтобы он не сильно горел и дымил.
Стоит отметить, что не существует двух абсолютно одинаковых электростанций, даже, если они одного типа и сделаны по одному и тому же проекту. Как следствие — система управления любой электростанции уникальна и выполнена в единственном экземпляре.
Одна из двух десятков московских электростанций — ТЭЦ 21. Видны градирни, от которых валит пар.
Если сильно упрощать, то подавляющее большинство устройств для добычи тепла и электричества состоит из:
Топка, котел, турбина и генератор образуют единый блок, который так и называется — энергоблок. Как правило, на одной электростанции несколько энергоблоков, не обязательно одной мощности.
Одна из частей энергоблока — турбина. Топка вместе с котлом, от которого идут паропроводы, расположены в другом зале.
В задачу автоматизированной системы управления (АСУ) входит как управление одним станционным энергоблоком (блочная АСУ), так и их совокупностью (станционная АСУ).
Зал управления энергоблоком №6 Рязанской ГРЭС. Мощность энергоблока 800 МВт, система управления — ПТК Квинт.
Так как же ПТК превращается в АСУ ТП? Как уже было отмечено, не существует двух одинаковых энергоблоков и, тем более, электростанций. Поэтому, чтобы с помощью универсального ПТК можно было что-либо автоматизировать, необходимо вначале определить его аппаратную конфигурацию и затем написать технологические программы управления объектом автоматизации. Сбором информации от датчиков, ее обработкой и выдачей управляющих воздействий на исполнительные механизмы занимаются программируемые логические контроллеры (ПЛК). Вместе с тем, на контроллерах лежит ответственность по защите оборудования и персонала в случае нештатных ситуаций, взаимодействие с операторами, предоставление всех оперативных данных для последующего архивирования и много чего еще. Этой работой контроллер занимается круглосуточно на протяжении многих лет. Таким образом, хотя контроллер – это лишь один из многих компонентов ПТК, для первого обзора он подойдет как нельзя лучше.
Разбираем ПЛК
Как хороший театр начинается с вешалки, так и хороший контроллер начинается с аппаратного шкафа.
Лабораторный аппаратный шкаф со снятой дверцей. Предназначен для тестирования ПО и оборудования — отсюда и небольшой рабочий беспорядок.
На верхнем этаже размещаются схемы дублированного питания — преобразователи
220 / =24 В. Они выделяют значительную часть тепла и поэтому располагаются как можно ближе к вентиляционному люку шкафа. Ниже располагаются стабилизаторы напряжений и предохранители. Следующий ряд — два процессорных модуля контроллера, включенного по схеме аппаратного дублирования. Один из процессорных модулей находится в активном, а другой в пассивном состоянии. Активный модуль управляет технологическим процессом, а пассивный постоянно следит за действиями активного и контролирует его исправность, всегда готовый принять управление на себя за пару миллисекунд. Между модулями расположен простейший аппаратный блок селекции (зеленый блок посредине), он служит арбитром между ними. Основываясь на состоянии выходов этого блока, модули принимают решение о том, взять ли управление на себя или отдать соседу, причем время принятия такого решения не превышает 1 мс. Еще ниже, расположена дублированная станция УСО. Она представляет собой два аппаратных модуля (на фотографии – это два крайних модуля слева), каждый из которых работает со своим модулем контроллера. Т.к. управляющие воздействия на объект оказывает только активный контроллерный модуль, то и задания для УСО спускает только тот модуль дублированной станции, который связан с активным контроллером. В состав изображенной станции УСО вошли 15 различных модулей УСО, необходимых для проведения испытаний. На стенках шкафа располагается по два ряда вертикальных кабель-каналов, между которыми могут доустанавливаться навесные элементы – клеммные соединения, дискретные переключатели и т.п.
Внешний вид процессорного модуля контроллера со снятой декоративной накладкой.
Контроллер можно настраивать с помощью кнопок и небольшого OLED экрана на 64 знакоместа (4 строки). В реальных условиях этими элементами приходится пользоваться один раз – при первичной конфигурации модуля, например, чтобы задать ему статический IP адрес и тип исполнения (одиночный/дублированный). Как только модуль станет доступен по сети, остальные настройки можно выполнить дистанционно с помощью соответствующего САПРа (разумеется, при наличии необходимых прав). Совсем по-другому обстоят дела на испытательном полигоне – эта часть контроллера наиболее востребована, т.к. чуть ли не ежедневно приходится менять его конфигурацию или блокировать систему безопасного доступа для новых испытаний. Слева на корпусе расположены гнезда разъемов для подключения аппаратного синхроимпульса (обычно он не используется, т.к. время достаточно точно синхронизируется от NTP-сервера), дублированного питания 24 В и сигналов блока селекции. Справа расположены три сетевых порта Ethernet на 100 Мбит/с. Два из них – для подключения дублированной блочной сети, один – для кабеля обмена данными между двумя процессорными модулями дублированного контроллера (соединение точка-точка).
Процессорный модуль, вид снизу.
Внизу расположены три порта для подключения до 3-х различных шин УСО. Физически это порты RS-485, соответственно длина каждой шины определяется ее рабочей частотой и может находиться в пределах от 5 до 1400 м. Каждая шина может обмениваться с УСО либо по внутрифирменному протоколу R-400, либо по протоколу Profibus-DP. В соответствии с этим на шину вешаются либо фирменные станции УСО, либо станции УСО Profibus. В случае, если шина работает по протоколу Profibus-DP, к ней напрямую могут подключаться цифровые устройства локального управления, наподобие интеллектуальных задвижек, двигателей и прочей арматуры.
Приступим к разборке. Вначале нужно освободиться от корпуса. Для этого достаточно снять заднюю крышку; она крепится при помощи шести пластиковых защелок, так что сделать это сравнительно просто.
Процессорный модуль со снятой задней крышкой. Сразу выделяется плата стабилизации с неслабыми конденсаторами по 2200 мкФ.
Теперь можно освободиться от передней крышки. Так как декоративная наклейка на лицевой стороне корпуса отсутствовала изначально, доступ ко всем нужным креплениям свободен, остается отвинтить 8 винтов.
Под передней крышкой расположена плата МБК, к которой припаян OLED дисплей со своим контроллером и фирменной прошивкой, с поддержкой русского шрифта.
Виден весь стек плат, объединенных по шине PC/104+.
Компоновка контроллерного модуля выполнена по стандарту PC/104+. De facto, в отрасли промышленной автоматизации такая компоновка стала стандартной. Соответственно все базовые платы модуля работают в данном стеке, что позволяет сравнительно просто наращивать компоновку контроллера. Все платы крепятся между собой на латунных стойках. Стойки для крепления к передней крышке – пластиковые. Между платами сравнительно немного дополнительных коммуникаций – это провода питания и шлейфы портов. Пойдем дальше и разъединим платы, освободив их от шлейфов.
Все платы одним планом.
Экземпляр, выбранный для обзора, имеет минимальную конфигурацию и укомплектован одним адаптером для фирменной шины УСО, поэтому в стеке не особенно много плат (слева направо, сверху вниз):
Внутренний стабилизатор питания модуля контроллера STB-4100.
STB-4100. Вид со стороны разъемов питания платы процессора и платы MBK-4100
Это простая плата, но она выполняет очень важные функции. Во-первых, стабилизирует и фильтрует выходное напряжение 5 В для процессора, и раздает входные ± 24 В плате MBK-4100. Во-вторых, может обеспечить краткосрочную работу всего модуля при пропадании внешнего питания. Это позволит модулю контроллера проработать достаточное время, чтобы он успел сохранить все оперативные данные в энергонезависимую память и смог достойно завершить работу, с высокой вероятностью восстановления своего состояния после устранения поломки.
Адаптер фирменной полевой шины MIS-4100. Вид со стороны процессора поддержки PC/104+
MIS-4100. Вид со стороны процессора поддержки фирменной полевой шины R400
Следом за стабилизатором в стеке располагается адаптер фирменной полевой шины УСО MIS-4100. На двусторонней плате с каждой стороны располагается по микропроцессору. Процессор Altera Cyclone отвечает за поддержку шины PC/104+, а Atmel запрограммирован как мастер на фирменной шине УСО – R400. Сама шина – это по сути I²C, разогнанная до частоты 10 Мбит/с и реализованная на «физике» RS-485. Шина дублируется путем простого удвоения линий связи. Это хорошо проверенное и зарекомендовавшее себя аппаратное решение, работающее на объектах не один год. Через эту шину контроллерный модуль связывается с фирменными станциями УСО, к которым, в свою очередь, подключены модули УСО. Обмен между станциями и УСО ведется по протоколу Modbus. Такая двухуровневая компоновка позволяет располагать модули УСО в непосредственной близости от объекта в отдельных аппаратных шкафах. При этом расстояние между контроллером и отдельными станциями УСО может превышать километр.
Процессорный модуль Cool SpaceRunner-LX800
Процессор, по нынешним временам, обладает более чем скромными характеристиками:
CPU
Из всех интерфейсов, расположенных на плате процессора, используется только Ethernet адаптер. Через него осуществляется связь между модулями дублированного контроллера. Эта связь служит для быстрой синхронизации накапливаемых данных. При этом данные в пассивном модуле отстают по времени от данных в активном не более чем на несколько миллисекунд. Это позволяет осуществлять автоматическое безударное (в технологическом смысле) переключение активности в случае возникновения неполадок в одном из модулей.
Плата дублированного сетевого Ethernet адаптера Advantech
Для общения со станциями верхнего уровня каждый модуль контроллера снабжается дублированным Ethernet адаптером. Сделано это по тем же соображениям, по которым дублируется шина УСО: все шины данных, что уходят далеко в «поле», обязаны быть продублированными, т.к. вероятность повреждения линии связи прямо пропорциональна ее протяженности. Если контроллер дублированный, то к каждому его модулю будут подключены по паре сетевых «шнурков». Таким образом, дублированный контроллер работает с сетью по четырем независимым линиям связи. Каждый сетевой адаптер, размещенный на плате, поддерживает гигабитный Ethernet. Однако, на практике такая пропускная способность избыточна, т.к. центральный процессор контроллера имеет сравнительно низкую производительность.
Модуль базовый коммутационный – MBK-4100
У этого модуля много разных задач:
Один из типов фирменных модулей УСО – АЦП-4122.
Строго говоря, модули УСО уже не относятся к контроллеру, а являются его периферией. Но, тем не менее, интересно взглянуть и на один из таких модулей. В данном случае это модуль аналого-цифрового преобразователя с настраиваемыми потенциальными входами с индивидуальной гальванической развязкой. Используется для снятия показаний термопар ТХА и ТХK. Конкретный тип термопары, которая будет подключена к одному из восьми каналов модуля, указывается при составлении технологической программы контроллера и спускается контроллером модулю УСО в виде настроек.
Вместо заключения
Контроллеры и УСО — это всего лишь одна из частей ПТК, но именно с них начинается разработка нового проекта для автоматизации электростанции. По началу, определяется объем и типы сигналов, которые нужно получать от датчиков объекта и формировать для исполнительных механизмов. После этого уже можно рассчитать количество необходимых контроллеров и состав УСО в каждом из них. Когда все станет известно, создается полигон, на котором можно реализовать требуемую аппаратную конфигурацию.
Аппаратные стойки на полигоне, предназначены для монтирования и испытаний спроектированной аппаратной конфигурации будущего АСУ ТП.
Эти модули УСО еще только предстоит собрать в станции и разместить их на стойках.
Будущая серверная АСУ ТП.
Монтаж кросс-панели для одного из шкафов с сетевым оборудованием.
Операторские станции. Они так же будут развернуты на полигоне. Этого требуют круглосуточные тесты бесперебойной работы будущего комплекса управления.
После того, как станет известна аппаратная конфигурация ПТК, можно приступать к написанию технологических программ для контроллеров. Для этого с помощью САПРа описывается тип и аппаратный состав контроллера.
В САПРе для программирования ПЛК, описывается аппаратный состав УСО.
Теперь, имея виртуальный образ всей аппаратуры, можно писать технологические программы для управления техпроцессом. В качестве языков для таких программ используются диалекты языков программирования из стандарта IEC 61131-3.
Два программных модуля на языках FBD (слева) и ST (справа). Вид из САПРа ПТК Квинт.
Помимо программирования логики работы контроллеров, так же необходимо запрограммировать операторский интерфейс. Это не менее сложная и ответственная задача, чем программирование контроллеров. Графический интерфейс должен быть легко понятен оператору с первого взгляда, к нему предъявляются жесткие требования эргономичности, т.к. с этим интерфейсом операторам предстоит работать сменами по 12 часов на протяжении длительного времени.
Когда технологические программы и операторские интерфейсы готовы, их разворачивают на полигоне на реальном оборудовании, где они и проходят предварительные испытания. Когда основные ошибки будут устранены, настроенная и запрограммированная аппаратура разбирается, упаковывается и отправляется на объект, где будет работать на протяжении многих лет без перерывов и остановок.
Статья пылилась в черновиках более 6 лет. С тех пор утекло много воды и сгорело много угля. Многое поменялось, что-то исчезло (например, ПТК «Квинт»), но суть самого процесса осталась прежней.
Основные положения тестирования
Области применения, цели и задачи тестирования ПО разнообразны, поэтому тестирование оценивается и объясняется по-разному. Иногда и самим тестировщикам бывает сложно объяснить, что такое тестирование ПО ‘as is’. Возникает путаница.
Для распутывания этой путаницы Алексей Баранцев (практик, тренер и консалтер в тестировании ПО; выходец из Института системного программирования Российской академии наук) предваряет свои тренинги по тестированию вводным видео про основные положения тестирования.
Мне кажется, что в этом докладе лектор смог наиболее адекватно и взвешенно объяснить «что такое тестирование» с точки зрения ученого и программиста. Странно, что этот текст еще не появлялся на хабре.
Привожу здесь сжатый пересказ этого доклада. В конце текста есть линки на полную версию, а также на упомянутое видео.
Основные положения тестирования
сначала попробуем понять, чем тестирование НЕ является.
Тестирование не разработка,
даже если тестировщики умеют программировать, в том числе и тесты (автоматизация тестирование = программирование), могут разрабатывать какие-то вспомогательные программы (для себя).
Тем не менее, тестирование — это не деятельность по разработке программного обеспечения.
Тестирование не анализ,
и не деятельность по сбору и анализу требований.
Хотя, в процессе тестирования иногда приходится уточнять требования, а иногда приходится их анализировать. Но эта деятельность не основная, скорее, это приходится делать просто по необходимости.
Тестирование не управление,
несмотря на то, что во многих организациях есть такая роль, как «тест-менеджер». Конечно же, тестировщиками надо управлять. Но само по себе тестирование управлением не является.
Тестирование не техписательство,
однако тестировщикам приходится документировать свои тесты и свою работу.
Тестирование нельзя считать ни одной из этих деятельностей просто потому, что в процессе разработки (или анализа требований, или написания документации для своих тестов) всю эту работу тестировщики делают для себя, а не для кого-то другого.
Деятельность значима только тогда, когда она востребована, то есть тестировщики должны что-то производить «на экспорт». Что они делают «на экспорт»?
Дефекты, описания дефектов, или отчеты о тестировании? Частично это правда.
Но это не вся правда.
Главная деятельность тестировщиков
заключается в том, что они предоставляют участникам проекта по разработке программного обеспечения отрицательную обратную связь о качестве программного продукта.
«Отрицательная обратная связь» не несет какой-то негативный оттенок, и не означает, что тестировщики делают что-то плохое, или что они делают что-то плохо. Это просто технический термин, который обозначает достаточно простую вещь.
Но эта вещь очень значимая, и, наверное, единственная наиболее значимая составляющая деятельности тестировщиков.
Существует наука — «теория систем». В ней определяется такое понятие как «обратная связь».
«Обратная связь» это некоторые данные, которые с выхода попадают обратно на вход, или какая-то часть данных, которые с выхода попадают обратно на вход. Эта обратная связь может быть положительной и отрицательной.
И та, и другая разновидности обратной связи равноценно важны.
В разработке программных систем положительной обратной связью, конечно же, является какая-то информация, которую мы получаем от конечных пользователей. Это запросы на какую-то новую функциональность, это увеличение объема продаж (если мы выпускаем качественный продукт).
Отрицательная обратная связь тоже может поступать от конечных пользователей в виде каких-то негативных отзывов. Либо она может поступать от тестировщиков.
Чем раньше предоставляется отрицательная обратная связь, тем меньше энергии необходимо для модификации этого сигнала. Именно поэтому тестировать нужно начинать как можно раньше, на самых ранних стадиях проекта, и предоставлять эту обратную связь и на этапе проектирования, и еще, может быть, раньше, еще на этапе сбора и анализа требований.
К слову, отсюда и произрастает понимание того, что тестировщики не отвечают за качество. Они помогают тем, кто за него отвечает.
Синонимы термина «тестирование»
С точки зрения того, что тестирование — это предоставление отрицательной обратной связи, всемирно известная аббревиатура QA (англ. Quality Assurance — Обеспечение качества) синонимом термина «тестирование» уж совершенно точно НЕ является.
Нельзя считать обеспечением качества простое предоставление отрицательной обратной связи, ведь Обеспечение — это некоторые позитивные меры. Подразумевается, что в этом случае мы именно обеспечиваем качество, своевременно предпринимаем какие-то меры для того, чтобы качество разработки ПО повысилось.
А вот «контроль качества» — Quality Control, можно считать в широком смысле синонимом для термина «тестирование», потому что контроль качества это и есть предоставление обратной связи в самых разных ее разновидностях, на самых разных этапах программного проекта.
Иногда тестирование подразумевается как некоторая отдельная форма контроля качества.
Путаница приходит из истории развития тестирования. В разное время под термином «тестирование» подразумевались различные действия, которые можно разделить на 2 больших класса: внешние и внутренние.
Внешние определения
Определения, которые в разное время дали Майерс, Бейзер, Канер, описывают тестирование как раз с точки зрения его ВНЕШНЕЙ значимости. То есть, с их точки зрения, тестирование — это деятельность, которая предназначена ДЛЯ чего-то, а не состоит из чего-то. Все три этих определения можно обобщить как предоставление отрицательной обратной связи.
Внутренние определения
Это определения, которые приведены в стандарт терминологии, используемой в программной инженерии, например, в стандарт де-факто, который называется SWEBOK.
Такие определения конструктивно объясняют, ЧТО представляет из себя деятельность по тестированию, но не дают ни малейшего представления о том, ДЛЯ ЧЕГО нужно тестирование, для чего потом будут использоваться все полученные результаты проверки соответствия между реальным поведением программы и ее ожидаемым поведением.
тестирование — это
Что такое тест
Разработчик тестов занимается тем, что он из огромного потенциально бесконечного набора тестов выбирает некоторый ограниченный набор.
Ну и таким образом мы можем заключить, что тестировщик делает в процессе тестирования две вещи.
1.Во-первых, он управляет выполнением программы и создает эти самые искусственные ситуации, в которых мы собираемся проверять поведение программы.
2.И, во-вторых, он наблюдает за поведением программы и сравнивает то, что он видит с тем, что ожидается.
Если тестировщик автоматизирует тесты, то он не сам наблюдает за поведением программы — он делегирует эту задачу специальному инструменту или специальной программе, которую он сам написал. Именно она наблюдает, она сравнивает наблюдаемое поведение с ожидаемым, а тестировщику выдает только некоторый конечный результат — совпадает ли наблюдаемое поведение с ожидаемым, или не совпадает.
Вот это и есть тестирование.
Другие классификации видов тестирования
Под системным тестированием подразумевается тестирование на уровне пользовательского интерфейса.
Иногда используются также некоторые другие термины, такие, как «компонентное тестирование», но я предпочитаю выделять именно эти три, по причине того, что технологическое разделение на модульное и системное тестирование не имеет большого смысла. На разных уровнях могут использоваться одни и те же инструменты, одни и те же техники. Разделение условно.
Практика показывает, что инструменты, которые позиционируются производителем как инструменты модульного тестирования, с равным успехом могут применяться и на уровне тестирования всего приложения в целом.
А инструменты, которые тестируют все приложение в целом на уровне пользовательского интерфейса иногда хотят заглядывать, например, в базу данных или вызывать там какую-то отдельную хранимую процедуру.
То есть разделение на системное и модульное тестирование вообще говоря чисто условное, если говорить с технической точки зрения.
Используются одни и те же инструменты, и это нормально, используются одни и те же техники, на каждом уровне можно говорить о тестировании различного вида.
То есть, можно говорить о модульном тестировании функциональности.
Можно говорить о системном тестировании функциональности.
Можно говорить о модульном тестировании, например, эффективности.
Можно говорить о системном тестировании эффективности.
Либо мы рассматриваем эффективность какого-то отдельно взятого алгоритма, либо мы рассматриваем эффективность всей системы в целом. То есть технологическое разделение на модульное и системное тестирование не имеет большого смысла. Потому что на разных уровнях могут использоваться одни и те же инструменты, одни и те же техники.
Наконец, при интеграционном тестировании мы проверяем, если в рамках какой-то системы модули взаимодействуют друг с другом корректно. То есть, мы фактически выполняем те же самые тесты, что и при системном тестировании, только еще дополнительно обращаем внимание на то, как именно модули взаимодействуют между собой. Выполняем некоторые дополнительные проверки. Это единственная разница.
Давайте еще раз попытаемся понять разницу между системным и модульным тестированием. Поскольку такое разделение встречается достаточно часто, эта разница должна быть.
И разница эта проявляется тогда, когда мы выполняем не технологическую классификацию, а классификацию по целям тестирования.
Классификацию по целям удобно выполнять с использованием «магического квадрата», который был изначально придуман Брайаном Мариком и потом улучшен Эри Тенненом.
В этом магическом квадрате все виды тестирования располагаются по четырем квадрантам в зависимости от того, чему в этих тестах больше уделяется внимания.
По вертикали — чем выше располагается вид тестирования, тем больше внимания уделяется некоторым внешним проявлениям поведения программы, чем ниже он находится, тем больше мы внимания уделяем ее внутреннему технологическому устройству программы.
По горизонтали — чем левее находятся наши тесты, тем больше внимания мы уделяем их программированию, чем правее они находятся, тем больше внимания мы уделяем ручному тестированию и исследованию программы человеком.
В частности, в этот квадрат можно легко вписать такие термины как приемочное тестирование, Acceptance Testing, модульное тестирование именно в том понимании, в котором оно чаще всего употребляется в литературе. Это низкоуровневое тестирование с большой, с подавляющей долей программирования. То есть это все тесты программируются, полностью автоматически выполняются и внимание уделяется в первую очередь именно внутреннему устройству программы, именно ее технологическим особенностям.
В правом верхнем углу у нас окажутся ручные тесты, нацеленные на внешнее какое-то поведение программы, в частности, тестирование удобства использования, а в правом нижнем углу у нас, скорее всего, окажутся проверки разных нефункциональных свойств: производительности, защищенности и так далее.
Так вот, исходя из классификации по целям, модульное тестирование у нас оказывается в левом нижнем квадранте, а все остальные квадранты — это системное тестирование.