close

Вход

Забыли?

вход по аккаунту

?

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

код для вставкиСкачать
ОРГАНИЗАЦИЯ ТЕСТОВОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
ВСТРОЕННЫХ СИСТЕМ
А.Н. Лукичев, А.О. Ключев
Рассмотрены некоторые типовые варианты организации и даны рекомендации по созданию
программного обеспечения для тестирования встроенных вычислительных систем различной сложности:
от простых контроллеров с ограниченной вычислительной мощностью (тестовое меню, простейший
интерпретатор) до сложных распределенных информационно-управляющих систем (вложенное
тестирование).
Введение
При создании встроенных вычислительных систем возникает проблема их
отладки на разных этапах разработки. Для каждого этапа существуют свои методы
решения проблемы отладки, т.е. выявления, локализации и исправления ошибок. Эти
методы, в общем, зависят от сложности системы, ее структурных и функциональных
особенностей.
По завершении разработки и при производстве неизбежна проблема создания
системы контроля качества выпускаемых изделий. Особенно остро эта проблема встает
при серийном производстве. Разработка системы автоматизированного тестирования –
зачастую довольно сложный и трудоемкий (а значит, и дорогостоящий) процесс.
В данной работе внимание будет уделено организации тестирования встроенных
систем на этапах разработки и производства [1]. Будут рассмотрены несколько типовых
вариантов организации тестового программного обеспечения и их особенности, а также
проанализирована оправданность их выбора. Вопросы аппаратного обеспечения
процесса тестирования, а также разработки методов тестирования конкретных
механизмов данная работа затрагивать не будет.
Под системой тестирования (или тестовой системой) будем понимать
программное обеспечение тестирования встроенных систем, ориентированное на
проверку качества их работы, а также на обнаружение ошибок (и до некоторой степени
точную их локализацию).
Обзор вариантов построения тестовых систем
Простейшим вариантом тестовой системы является набор тестовых модулей в
виде отдельных независимых программ.
Инструментальный
компьютер
Тестируемое
изделие
Память
Тест 1
Тест 2
Инструментальный
канал связи
Тест 3
...
Тест N
Рис. 1. Простейший вариант организации тестирования
Модули поочередно доставляются в тестируемое изделие (контроллер) с
помощью средств ICP (In-Circuit Programming, программирование на борту системы):
либо
аппаратно
предусмотренных,
либо
обеспечиваемых
резидентными
95
инструментальными программами [2]. После того, как тест пройден, на его место в
памяти записывается новый.
Этот вариант, очевидно, является самым дешевым и наименее трудоемким в
изготовлении. Его целесообразно использовать при начальной отладке опытного
образца изделия на этапе разработки. Однако очевидным его недостатком является
высокая трудоемкость тестирования при большом количестве тестов (и/или
тестируемых подсистем).
Выходом в данном случае является тестовая система, объединяющая в себе все
разработанные тесты и доставляемая в тестируемое изделие в виде единой программы
(загрузочного модуля). При запуске этой программы на исполнение в
инструментальный канал связи из изделия выдается список тестов, и оператор
проводит тестирование, выбирая из этого списка нужные ему. Вся информация о
процессе тестирования передается в инструментальный канал связи.
Тестируемое
изделие
1. Тесты 1-10
2. Тесты 11-20
[Главное меню] 1
Память
Тест 1
Тест 2
...
Тест N
Инструментальный
канал связи
1. Тест 1
2. Тест 2
3. Тест 3
...
[Тесты 1-10]
...
Рис. 2. Программа, объединяющая тесты в систему меню
Тесты можно сгруппировать по различным признакам в отдельные подменю
(например, по тестируемым подсистемам: "Тестирование последовательных каналов",
"Тесты подсистемы контроля питания", "Тесты управления дискретными выходами" и
т.д.). Процесс тестирования сводится к выбору категории тестов, выполнении всех
тестов из выбранной категории и переходу к следующей категории. Такой подход, по
сравнению с предыдущим вариантом, немного более трудоемок в изготовлении, однако
помогает систематизировать тестирование и существенно упрощает сам процесс.
Область его применения также существенно ограничена, т.к. не позволяет
автоматизировать процесс тестирования: для проведения тестов требуется оператор,
выбирающий тесты из списка.
Однако для того, чтобы в такой системе изменить или дополнить набор тестов или
изменить логику работы какого-либо из них, необходимо будет заново скомпилировать
программу и получить из нее загрузочный модуль. Затем нужно будет доставить этот
новый модуль в память тестируемого изделия. Этот существенный недостаток присущ
и первому рассмотренному варианту построения тестовой системы. Хотелось бы иметь
систему, которая позволяет изменять процесс тестирования без перекомпиляции всей
программы. В этом случае можно описать тестовую систему в виде интерпретатора
языка сценария экспериментов, принимающего команды с различными параметрами
через инструментальный интерфейс. В качестве вызываемых интерпретатором при
исполнении команды функций можно описать как специально разработанные тесты,
так и отдельные функции системного API (Application Program Interface; здесь под API
96
понимается набор низкоуровневых сервисов, позволяющих прикладным программам
использовать аппаратные возможности контроллера).
Инструментальный
Тестируемое изделие
компьютер
Память
Интерпретатор
Тесты
Инструментальный
Инструментальная
канал связи
система
Скрипт-файл
API
Рис. 3. Система с интерпретатором тестовых команд
На инструментальном компьютере составляется сценарий эксперимента, а затем
последовательно, команда за командой, пересылается на резидентную консоль тестовой
системы. Чтобы изменить или дополнить ход эксперимента, достаточно просто
изменить тестовый сценарий, как правило, представляющий собой обычный текстовый
файл. Такой подход можно использовать как при тестировании работоспособности
подсистем изделия, так и при тестировании системного API (например, на
устойчивость при различных наборах входных данных, на качество работы при
повышенной нагрузке на систему). Также этот подход целесообразно применять для
тестирования партии изделий, т.к. тестирование здесь в некоторой степени
автоматизировано: достаточно подготовить один сценарий тестирования и запускать
его, подключая изделия из партии к инструментальному компьютеру. Целесообразно
при этом реализовать автоматическое составление отчетов для каждого экземпляра на
инструментальном компьютере.
При таком варианте организации тестовой системы существенным недостатком
является то, что сценарий тестирования обычно представляет собой линейную
программу, т.е. набор команд без возможности ветвления. Что если потребуется
изменить ход теста в зависимости от результата исполнения предыдущей команды?
Или использовать этот результат в виде аргументов последующих команд? В этом
случае необходимо усовершенствовать резидентный интерпретатор, предусмотрев
возможность промежуточного сохранения данных, а также возможность условного
исполнения блоков команд. Простейшим решением, на наш взгляд, является
организация интерпретатора в виде стековой виртуальной машины. При исполнении
какой-либо команды часть ее аргументов может помещаться в стек, результат также
помещается в стек. Условные операторы извлекают значение из стека и, в зависимости
от результата проведенного сравнения, исполняют или не исполняют следующий блок
команд.
97
В случае использования пакетных интерфейсов в качестве инструментальных
каналов связи с тестируемым контроллером (таких как Ethernet или CAN),
целесообразно кодировать команды интерпретатора числами из фиксированного
набора. Это значительно упростит процедуру их интерпретации и перенесет процесс
синтаксического анализа команд сценария на инструментальный компьютер. То же
самое касается и числовых аргументов команд. При этом существенно расширяется
область применения такой тестовой системы, т.к. для специализированных
процессоров с ограниченными ресурсами (вычислительная мощность, память) иногда
довольно сложно разработать синтаксический анализатор. При тестировании таких
систем целесообразно минимизировать вычислительную нагрузку на контроллер.
При пакетной передаче можно также в одном пакете пересылать целый блок
команд сценария, если используемый интерфейс предусматривает достаточный для
этого размер пакетов. Можно вообще передавать на борт изделия целиком весь
сценарий для исполнения. Это может быть особенно важным, когда инструментальный
канал связи имеет малую скорость передачи, а скорость выполнения тестового
сценария критична.
Рассмотренные варианты организации тестового программного обеспечения
рассчитаны на случаи, когда инструментальный интерфейс изделия является
доступным для компьютера, с которого проводится тестирование. А как быть, когда
внешним интерфейсом изделия является другой интерфейс, недоступный для
инструментального компьютера? Или в случае многопроцессорного контроллера, когда
тест требуется провести на процессоре не связанном непосредственно с внешними
интерфейсами, а только через другой процессор (или их цепочку)? В этом случае
необходимо организовать транзитную пересылку команд сценария через
дополнительный контроллер или коммуникационный процессор (в случае
многопроцессорной системы). При этом необходимо предусмотреть возможность
адресации тестируемого объекта, так как промежуточный узел может быть связан еще с
несколькими объектами. Архитектура такой системы, обеспечивающей так называемое
вложенное тестирование, представлена на рис. 4.
Объект N
Монитор
пакетов
Интерпретатор
Объект 2
Интерфейс N-1
...
Монитор
Инструментальный
компьютер
Объект 1
Интерфейс 1
Монитор
пакетов
пакетов
Интерпретатор
Интерпретатор
Инструментальный
канал
связи
Инструментальная
система
Скрипт-файл
Рис. 4. Система, обеспечивающая вложенное тестирование компонентов
контроллерной сети
Каждый из объектов, изображенных на рис. 4 (Объект 1, …, Объект N), может
быть доступен для тестирования с инструментального компьютера через другие.
Резидентный монитор пакетов на каждом из них обеспечивает транзитную пересылку
команд на другие объекты или передачу управления собственному интерпретатору [3].
Изготовление такой системы представляется более трудоемким и дорогим по
сравнению с предыдущими рассмотренными вариантами, однако это оправдывается
более высокой стоимостью тестируемых объектов: сложных многомодульных и/или
многопроцессорных систем.
98
Заключение
Коллектив лаборатории микропроцессорной техники кафедры ВТ СПб
ГИТМО (ТУ) занимается данной тематикой уже много лет. Все рассмотренные выше
подходы к организации тестового программного обеспечения для встроенных систем
опробованы на практике в рамках достаточно большого количества НИР. Информацию
о некоторых из них можно получить в публикациях [4–6].
Наилучшие результаты с точки зрения качества тестирования были получены при
использовании технологии вложенной отладки (рис. 4) и удаленного исполнения
команд (рис. 3). Практика показывает, что применение этих двух технологий дает
положительный
эффект
при
тестировании
сложных
многопроцессорных
распределенных встроенных систем.
Простейшие системы тестирования (система меню, простой текстовый
интерпретатор) хорошо вписываются во встроенные системы на базе 8-ми разрядных
однокристальных микро-ЭВМ, таких как Intel MCS51, Atmel AVR, Microchip PIC, и с
точки зрения бюджета разработки и с точки зрения ресурсоемкости тестового ПО.
В настоящее время коллективом лаборатории производятся работы по
совершенствованию средств тестирования встроенных систем широкого спектра
сложности. В работе над новыми технологиями преследуются следующие цели и
задачи:
• уменьшение трудоемкости и увеличение качества тестирования за счет
автоматизации максимального количества этапов и исключения человеческого
фактора;
• построение
комплексных
систем
автоматизированного
тестирования
(функциональное, климатическое, механическое, электромагнитное тестирование);
• создание и исследование гомогенной инструментальной среды на базе
инструментальных серверов для распределенных многопроцессорных встроенных
систем.
Литература
1. Распределенные системы управления / Ключев А.О., Кустарев П.В., Платунов А.Е.
// СПб.: Сб. тезисов ДИМЭБ-97, 1997
2. Использование интерфейса JTAG для отладки встраиваемых систем / Ключев А.О.,
Коровьякова Т.А., Платунов А.Е. // Изв. вузов. Приборостроение. 1998. Т. 41. № 5
3. Инструментальный сервер / Ключев А.О., Платунов А.Е. // СПб.: Сб. тезисов
ДИМЭБ-96, 1996
4. Механизмы
обеспечения
функциональной
безопасности
транспортных
информационно-управляющих систем / Гавриков В.О., Платунов А.Е., Шубинский
И.Б. // СПб.: Тез. VII Международной конференции "Региональная информатика
2000". Часть 1. СПб, СПОИСУ, 2000. С. 121.
5. Микропроцессорная система диспетчерской централизации “Тракт” нового
поколения. / Гавриков В.О. Григорьев В.В. Платунов А.Е. Шубинский И.Б. //
Тезисы докладов конференции "Информационные технологии на железнодорожном
транспорте". Санкт-Петербург, 1997, с.163-173.
6. Восьмиразрядные микроконтроллеры в системах автоматического управления / А.
Ключев, П. Кустарев, А. Платунов // Компоненты и технологии. 2001. №1. С.23–24.
99
Документ
Категория
Без категории
Просмотров
4
Размер файла
2 408 Кб
Теги
тестового, обеспечение, встроенных, система, организации, программного
1/--страниц
Пожаловаться на содержимое документа