4 е/аЬ. В.Ляпаев
ТЕСТИРОВАНИЕ
ПРОГРАММ
^!LGSL7
Москва
«Радио и связь»
1986
ЗАС ьМ. С.-ХлБудеИЯ^гц ..
ББК 32.973
Л 61
УДК 681.326.74.06
Рецензент д-р техн, наук А. М. Растрелли
Редакция литературы по кибернетике и вычислительной технике
Липаев В. В.
Л 61 Тестирование программ. — М.: Радио и связь,
1986. — 296 с. ил.
Рассматриваются методы тестирования программных модулей и слож-
ных комплексов программ Анализируются эффективность методов а так-
же средства, автоматизирующие процесс тестировании Даются рекомен-
дации по эффективному применению тестирования иа разных этапах про-
ектирования и сопровождения комплексов программ тестирования
Для инженерно-технических работников занимающихся проектирова-
нием и эксплуатацией программного обеспечения. Полезна аспирантам н
студентам вузов соответствующих специальностей
2405000000-069
Л 046(01 )-86
142-86
ББК 32.973
© Издательство «Радио и связь», 1986
ПРЕДИСЛОВИЕ
В последние годы принципиально изменилась роль про-
грамм для ЭВМ, что позволило их квалифицировать как про-
дукцию производственно-технического назначения. Это при-
вело к необходимости создания эффективных методов дости-
жения заданного качества комплексов программ (КП) и его
оценки.
Высокое качество программ может достигаться безошибоч-
ным проектированием («пассивными» методами) и выявлением
и устранением ошибок («активными методами»). Методы без-
ошибочного проектирования, точнее предотвращения оши-
бок, основываются на применении организационных и методо-
логических правил проектирования КП, а также языков про-
граммирования высокого уровня. Эти правила определяют ор-
ганизацию технологического процесса проектирования, струк-
турное построение КП и его компонент, методологию прове-
дения системного анализа, подготовку спецификаций тре-
бований и т. д. Однако эти методы, способствуя значительному
повышению качества программ, не могут гарантировать удов-
летворение всех заданных требований к КП, а главное, не
полностью предотвращают ошибки.
Активные методы поиска и устранения ошибок дополняют
пассивные в процессе достижения заданного качества КП и
позволяют оценивать ряд показателей качества. Основным ак-
тивным методом является тестирорание, которое состоит в про-
верке программ на соответствие заданным правилам построе-
ния и конкретным результатам их исполнения. На проведение
тестирования при создании сложных КП требуется до 30—40 %
полных трудовых затрат и от эффективности его выполнения
в значительной степени зависят трудоемкость и сроки созда-
ния программ.
Современная практика тестирования программ базирует-
ся, в основном, на квалификации и интуиции специалистов,
что приводит к различию трудоемкости создания программ и
достигаемого их качества. Из-за «оптимизма» многих програм-
мистов и пренебрежения планомерным, систематическим тести-
рованием в программах остаются ошибки, выявляемые впо-
следствии при завершении отладки или в процессе эксплуата-
3
ции. Внедрение в практику методик и средств автоматизации
систематического тестирования сопряжено с большими не толь-
ко техническими, но и психологическими трудностями. По-
следние особенно ощутимы в коллективах опытных программи-
стов, выработавших за многие годы собственные приемы тести-
рования программ.
Для эффективного тестирования программ необходима ме-
тодологическая и инструментальная (средства автоматиза-
ции) база. В настоящее время наиболее развиты теоретические
основы тестирования и определения качества программных мо-
дулей. Теория тестирования групп и комплексов программ по-
ка представлена только отдельными работами, в которых из-
ложены некоторые частные методы и в основном без оценки их
эффективности. Это объясняется, в частности, трудностями
обобщения методов тестирования, оценки их эффективности и
анализа достигаемой корректности программ из-за сложности
современных КП.
Быстро развиваются практические методы и средства ав-
томатизации тестирования. Накапливается опыт планирова-
ния тестирования программных модулей на базе средств ав-
томатизации статического контроля, структурного тести-
рования и анализа потока данных. Автоматизированное пла-
нирование тестирования упорядочивает этот процесс, что поз-
воляет достигать заданное качество программ независимо от
интуиции и индивидуальных особенностей специалистов, про-
водящих эту работу. Значительную помощь оказывают ком-
плексные автоматизированные системы тестирования, создан-
ные в ряде организаций. Широко применяются также отдельные
средства автоматизации, которые в некоторых случаях име-
ют достаточно высокую эффективность.
Цель данной книги — изложить для создателей КП основ-
ные методы и средства автоматизации систематического тести-
рования программ, освоение которых должно способствовать
достижению заданного их качества, что является определяю-
щим для программ, рассматриваемых как промышленная про-
дукция. Значительная часть материала представляет собой
оригинальные результаты. Они содержатся в разделах, по-
священных систематизации и анализу эффективности методов
и средств тестирования, структурному тестированию програм-
мных модулей, тестированию при испытаниях н сопровожде-
нии сложных КП реального времени.
Отзывы на книгу просим направлять по адресу: 101000
Москва, Почтамт, а/я 693, издательство «Радио и связь».
4
A
ГЛАВА 1
ОБЩИЕ ПРИНЦИПЫ И МЕТОДЫ ТЕСТИРОВАНИЯ
ПРОГРАММ
1.1. ПРОГРАММЫ КАК ОБЪЕКТЫ ТЕСТИРОВАНИЯ
Особенности тестирования программ. Тесты и тестирова-
ние широко используются в технике для установления соот-
ветствия изделий заданным правилам построения, техниче-
ским условиям или заданиям на них и для определения до-
стигнутых показателей качества. В технической диагностике
тестом называется последовательность наборов сигналов (ис-
ходных данных), которые подаются на вход изделия, и соот-
ветствующие им наборы эталонных правильных сигналов (ре-
зультирующих данных), которые должны быть получены на
выходе [45, 511. Для каждого тестового набора указываются
координаты (точки) ввода исходных данных и координаты
(точки) контроля результатов.
Во всех случаях должны быть известны и, желательно,
формализованы эталонные правила или значения результатов,
которым должен соответствовать тестируемый объект. Основ-
ная задача тестирования— выявить отклонения в схеме изде-
лия или результатах его функционирования от эталонов, оце-
нить степень и причины таких отклонений. Отклонения полу-
чаемых результатов от эталонов используются для оценки ка-
чества изделий и соответствия их техническим требованиям.
Программы как объекты тестирования имеют ряд особен-
ностей, которые отличают процесс тестирования от традицион-
ного, применяемого для проверки аппаратуры и Других тех-
нических изделий. С этой позиции основными особенностями
программ являются:
отсутствие полностью определенного эталона (программы),
которому должны соответствовать все результаты тестирова-
ния проверяемой программы;
высокая сложность программ и принципиальная невозмож-
ность построения тестовых наборов, достаточных для их ис-
черпывающей проверки;
5
относительно невысокая степень формализации критериев
качества процесса тестирования и достигаемого при этом ка-
! чества объектов тестирования;
наличие в программах вычислительных и логических ком-
понент; а также компонент, характеризующихся стохастиче-
ским и динамическим поведением.
Для сложных программ практически всегда о т с у т с т -
. в у е т полностью определенный и т о ч.н ы,й. эта л о н
для всех тестовых наборов: В аппаратных изделиях на эт^пе
тестового контроля обычно имеется эталонный образен,' по
которому могут быть определены все эталонные результаты
.. тестовых наборов. Благодаря этому при тестировании могут
быть выявлены отклонения серийно изготавливаемых изделий
от эталонного изделия. Для программ на этапах проектиро-
вания, когда проводится основное тестирование, отсутствуют
. такие эталонные изделия. Поэтому для тестирования исполь-
зуются в качестве эталонов косвенные данные, которые ие
полностью отражают функции и характеристики программ.
По мере возрастания сложности любых изделий увеличи-
ваются трудности их ’тестирования и необходимые затраты на
его выполнение. Комплексы программ, используемые для уп-
равления и обработки информации; являются одними из самых
сложных изделий, создаваемых человеком {251. При сущест-
вующей сложности программ не достижимо и-счерпы-
-в а ю щ се их тестирование, гарантирующее Аб-
солютно полную проверку. Поэтому принципиально изме-
нился подход к оценке объема тестирования. Тестирование
проводится в объемах, минимально необходимых для провер-
ки программ в некоторых ограниченных пределах изменения
параметров и условий функционирования. Ограниченность
ресурсов тестирования привела к необходимости тщательно-
го упорядочения Применяемых методов и конкретных значе-
ний параметров с целью получения при тестировании- наи-
большей глубины проверок программ. Это определяет необ-
ходимость применения экономичных и эффективных методов
тестирования.
Показатели качества сложных комплексов программ
трудно формализуются и еще более трудно из-
меряются (11, 371. Вследствие этого качество процесса тести-
рования программ и достигаемая при этом их корректность
остаются весьма неопределенными и незарегистрированными,
.Оценки полноты тестирования и достигаемого при этом ка-
чества программ обычно получаются в процессе испытаний и
сопровождения программ. Их трудно получать поэтапно в
процессе разработки компонент.
6
• в сложных КП Практически всегда имеются компоненты,
осуществляющие преобразования данных и вычисления функ-
ций. Кроме того, значительную часть программ составляют
схемы принятия логических решений, обработки логических
и символьных переменных. В ряде случаев процесс исполне-
ния программ и получаемые результаты зависят от случай-
ного изменения входных и промежуточных данных, а также От
реального времени. Поэтому невозможно создать единствен-
ный универсальный метод тестирования и приходится приме-
нять ряд значительно различающихся категорий тес-
тов (см. § 1.3). Каждая категория тестов отличается целевы-
ми задачами тестирования, проверяемыми компонентами про-
грамм и методами оценки результатов. Только совместное н
систематическое применение различных методов тестирования
и категорий тестов позволяет достигать высокого качества
функционирования сложных КП.
Жизненный цикл программ (13, 57] включает все этапы раз-
вития от возникновения потребности в программе определен-
ного целевого назначения до полного прекращения ее исполь-
зования вследствие морального старения. Программы можно
разделить на два класса: с кратковременной эксплуатацией и
длительной. Этим классам программ соответствует гибкий
. (мягкий) подход к нх созданию и использованию как к объек-
там научного творчества или произведениям «искусства»,
и жесткий подход, в основе которого лежит регламентирован-
ное проектирование и эксплуатация программ, как продукции
производственно-технического назначения. Оба подхода рас-
пространены более или менее одинаково. В научных органи-
зациях и вузах преобладают разработки программ первого
класса, а в промышленных и проектных организациях —
второго. Все последующее изложение в данной монографии
ориентировано на промышленную разработку сложных про-
граммных комплексов с длительным периодом эксплуатации и
сопровождения (см. гл. 5).'
Сложные программные изделия с большой длительностью
эксплуатации создаются для регулярной обработки инфор-
мации и управления в процессе функционирования вычис-
лительных систем. Размеры программ могут изменяться в
широких пределах (103—10е команд), однако ко всем предъяв-
ляются требования познаваемости и возможности модифика-
ции в процессе длительного сопровождения и использования
различными специалистами. Программы этого класса допус-
кают тиражирование, обеспечиваются документацией как
промышленные изделия и предётавляют собой отчуждаемый
от разработчика программный продукт. Проектированием и
7
эксплуатацией программ могут заниматься большие коллекти-
вы специалистов, поэтому необходима формализация требуе-
мых технических характеристик комплексов программ и.их
компонент, четкая технология их создания, а также формали-
зованные испытаний и определение достигнутых показателей
качества программ. Жизненный цикл такйх программ состав^
ляет 10—20 лет, 'из которых 70—90 % приходится на эксплу-
, Ятацию и сопровождение. При массовом тиражировании про-
грамм и длительном сопровождении совокупные затраты мо-,
гут значительно превышать затраты на первичное проекти-
рование.	'	.	1
Модульно-иерархическое построение сложных комплексов
программ. При анализе и синтезе сложных систем широко ис-
пользуются понятия и методы теории многоуровневых иерар-
хических систем 147, 21J. Иерархия представляет собой свой-
ство упорядоченного множества компонент, между которыми
.установлено отношение приоритетов. Компоненты, между ко-
торыми отсутствует предпочтительность, образуют один иерар-
хический уровень. Иерархия комплексов программ предпола-
гает наличие уровней абстрагирования и подчиненности ком-
понент следующих типов:
иерархия целей КП и его составляющих, при которой их
зачастую противоречивые частные цели должны способствовать
достижению основной цели функционирования всего комплек-
са;
иерархия задач и поведение программ (функциональная
иерархия), обеспечивающая концептуальное единство КП и.
возможность последовательной функциональной детализации
комплекса;
иерархия взаимодействия программ (структурная иерар-
хия), отражающая декомпозицию конкретных компонент ком-
плекса и оформление реализуемых связей между программами
и их группами, а также используемыми данными.
Эти иерархии с различных позиций отражают сущность
КП и могут быть слабо связаны между собой при их конкрет-
ной реализации. Наиболее специфичной по существу и по
методам представления является иерархия целей прог-
рамм Разнообразие назначений и областей применения слож-
ных- программных комплексов затрудняют разработку общи^
методов декомпозиции целей и их анализа. Поэтому ниже
подразумевается наличие иерархии целей программ, но кон-
кретно она не рассматривается.
Иерархия з а д .а ч связана с иерархией целей КП и корре-
лируется с иерархией ее структурного построения. Структу-
рирование функциональных задач и их иерархического вза-,
имоДействия в значительной степени «гфажается на реалид^
ций иерархической' структуры КП в целом й на его структур,,
ной декомпозиции.	...
Структуры а я! иерархия программ и данных наибо-
лее доступна для изученйя и играет важную роль при проекту
ровании, тестировании и анализе показателей качества'сложп
ных КП. Она в значительной степени инвариантна к целевому
назначению в пределах’ классов программ. Поэтому- нИже
основное внимание уделяется принципам структурного по-,
строения КП и в меньшей степени — иерархии задач и функ-
циональному взаимодействию программных компонент.
Многоуровневое иерархическое построение сложных КП
позволяет ограничить и локализовать на каждом из уровней
соответствующие ему компоненты, вследствие чего облегчается
анализ и синтез компонент более высоких уровней и комплек-
са в целом. Для компонент значительно различающихся иерар-
хических уровней могут Использоваться специфические для
них концепции и принципы построения, языки описания ком-
понент и Их функционирования. Компоненты, расположенные
структурно на одном уровне, могут значительно различаться
по функциональным уровням иерархии. При проектировании
КП сверху вниз функциональная иерархия является домини-
рующей и значительно Определяет структурную иерархию.
Всем иерархическим системам присущ ряд существенных
признаков, важнейшими из которых являются (471:
вертикальная с о п б д ч.и н е н н о с т ь, за-
ключающаяся в последовательном упорядоченном расположе-
нии взаимодействующих компонент, составляющих данную
систему;	-	’
право вмешательствам приоритетного воздей-
ствия на компоненты любых уровней со стороны компонент бо-
Лее высоких иерархических уровней;
взаимозависимость действий компонент
верхних уровней от реакций на воздействия, и от функциони-
рования компонент нижних уровней, информация о которой
передается верхним'уровням.
В результате в иерархических системах образуется два по-
тока взаимодействий между - компонентами разных уровней
(рис. 1.1): сверху Вниз — координирующие и управляющие
воздействия верхних уровней и снизу вверх—информация от-
стоянии и реализации предписанных функций компонентами,
нижних уровней. Координация предполагает выбор способа
координации и реализацию координирующих алгоритмов с
выработкой соответствующих воздействий. Координируемые
компоненты обычно имеют некоторую автономность поведения
9
Парры й
уровень —
Центральный
диспетчер
Второй
уровень -
местные
диспетчеры
Третий
уровень -
функционапъ-
Г л обельные
переменные
Рис. 1.1. Модульно-иерархическая структура комплексов программ
•—► связи по управлению.------- связи по информации. Зп — запись пере-
менных. Сч — считывание переменных
и подготовки локальных решений. Степень автономности ком-
понент и интенсивность координирующих воздействий устанав-
ливается в результате компромисса при выделении иерархи-
ческих уровней. Взаимодействие компонент в пределах уров-
ня целесообразно максимально ограничивать, что позволяет
упростить общее' координирование компонент и проводить его
только по вертикали. В процессе координации возможно изме-
нение (перестройка) структуры . КП или непосредственное уп-
равление компонентами при фиксированной структуре. Для
упрощения и повышения устойчивости функционирования ком-
плекса желательно уменьшать жесткость управления и при-
менять слабое координирование в максимальной степени авто-
номных компонент нижних уровней, так как при жестком уп-
равлении любая аномалия воздействий вызывает нарушение
функционирования всей системы.
Компоненты нижних уровней влияют непосредственно на
вышестоящие, поставляя информацию о своем состоянии и ре-
10
зультатах функционирования, а также косвенно, подготавли-
вая возможные решения для их выбора на более высоких уров-
нях. Информация о результатах функционирования верхних
уровней может учитываться компонентами нижних уровней
для улучшения собственных решений и для косвенной коорди-
нации. Таким образом, нижние иерархические уровни являют-
ся основными компонентами, обрабатывающими информацию
и подготавливающими данные для выдачи за пределы анали-
зируемой программной системы..
Иерархический подход отражается на проектирований
сложных КП по принципу сверху вниз с позиций учета назна-
чения и наилучшего решения целевой Задачи всей системы.
Это обеспечивает концептуальное единство алгоритмов и про-
грамм и возможность рационального распределения ограни-
ченных ресурсов проектирования по мере декомпозиций ком-
понент. Хотя разделение на иерархические уровни требует до-
полнительных затрат, в целом, как, правило, ресурсы исполь-
зуются более эффективно, чем при отсутствии четкой иерар-
хии, прежде всего за счет экономного построения и упроще-
ния компонент на каждом уровне.
При этом важное значение имеет объем и сложность ком-
понент для каждого уровня иерархии и соответственно коли-
чество иерархических уровней для определенных классов КП.
Ограничение размеров и функциональных возможностей ком-
понент при увеличении суммарной сложности КП произво-
дится путем поиска компромисса между затратами на взаимо-
действие компонент и затратами на создание каждой из них.
Оформление правил проектирования компонент (модулей)
разных уровней является существенным этапом определения
иерархической структуры КП. Структура непосредственно вли-
яет на процесс тестирования и на основные показатели ка-
чества программ. Возможность автономного функционирова-
ния компонент способствует упрощению и повышению каче-
ства их тестирования.
Компонентам верхний уровней подчинены наиболее круп-
ные подсистемы, определяющие разнообразие поведения КП
в целом. В результате возрастают специализация компонент
верхних уровней, трудности количественной формализации
их характеристик и растет сложность их тестирования. Не-
определенность поведения и характеристик сложных много-
уровневых КП в ряде случаев является существенной особен-
ностью и требует стохастического подхода при их анализе
и синтезе.
Стохастический характер поведения сложных многоуровне-
вых программ проявляется также в специфике временного вза-
11
имодеДствия между уровнями. Управляющие воздействия от
вышестоящих компонент не могут следовать чаще, чем мнфор-
мания от нижних уровней, так как в противном случае верх-
ние уровни не будут успевать оценивать достигаемый эффект
координации. Несинхронность воздействий как сверху вниз,
так и снизу вверх приводит, в совокупности к случайным по-
токам воздействий* которые дополнительно усложняют стог
. хастйческое поведение многоуровневых. КП и увеличивают ид
.время реакции на входную информацию. В результате верхние
иерархические уровни имеют дело с более медленными аспекг '
тами поведения всего комплекса и период принятия решения
для них больше, чем для компонент нижних уровней. .
 Четкое иерархическое многоуровневое построение КП зна-
чительно облегчает организацию их проектирования н экс-
плуатации, положительно влияет на длительность и стоимость
тестирования. Имеется возможность рационально распреде-
лять усилия разработчиков на решение частных задач в соот- ,
ветствни с их важностью для основного целевого назначения
- программ с учетом квалификации каждого специалиста. По
количеству компонентна разных уровнях с учетом сложности
связей можно оценивать объем выполняемой работы и прогио-'
зировать ее перспективы по срокам и трудоемкости, вследствие
чего повышается достоверность контроля состояния и процес-
са проектирования.
В сложных КП по принципам построения, объему и мето-
дам тестирования наиболее четко можно выделить следующие
иерархические уровни 146, 57J:
программные модули, оформляемые как законченные ком-
поненты программы (см. гл. 3);
функциональьЛые группы программ и пакеты прикладных
программ;
комплексы программ, оформляемые как завершенный про-
граммный продукт определенного целевого назначения
(см. гл. 4).
Повышение иерархических уровней отражается на увели-
чении числа машинных команд ЭВМ, реализующих компонен-
ты каждого уровня и количества обрабатываемых данных. Од-
новременно увеличивается уникальность совокупности ко-
манд и они все более специализируются: т. е. снижается воз-
можность применения компонент в различных комбинациях
для решения аналогичных задач.
, Программные модули решают небольшие функциональные
задачи и реализуются 10—100 операторами языка програм-
мирования высокого уровня или 100—1000 операторами авто-
12
кода-ассемблера. В результате программа'модуля имеет обыч-
но 100—1000 команд в объектном (машинном) коде. Каждый мо-
дуль может использовать на входе около Десятка типов пере-
менных, однако встречаются программные модули, обрабаты-
вающие несколько десятков типов операндов. Каждый модуль
имеет имя и описание функций. При построении КП важно стаи'-
дартизировать правила взаимодействия модулей и структуру
межмодульного интерфейса.-Обобщенное содержание модулей
формализуется иа языке программных спецификаций, графовы-
ми моделями программ (блок-схемами), ШРО-диаграммймй
или иным способом, исходные и результирующие данные обыч-
но описываются на языке программирования;	' " -
Функциональные группы программ и; пакеты прикладных
программ формируются на базе нескольких или, десяткой мо-
дулей и решают сложную автономную функциональную зада-
чу. На их реализацию в ЭВМ-моЖет использоваться около де-,
сити тысяч команд. Соответственно возрастает количество ис-
пользуемых типов переменных и разнообразие выходных дан-
ных, которое практически полностью определяется особенно-
стями функциональной Задачи группы программ. Связи между
модулями могут приводить к сложным структурным схемам,
содержащим около десяти иерархических уровней. Содержа-
ние пакетов или групп программ формализуются техниче-
скими заданиями или спецификациями требований на их раз-
работку. Разнообразие функционального назначения, слож-
ности и технологических методов проектирования затрудняют
унификацию языков, и методов обобщенного описания на этом
уровне. Тем не менее все более широкое применение находят
методы формализованных спецификаций, аналогичные ис-
пользуемым при описании модулей.
Комплексы программ создаются для решения особенно слож-
ных задач управления и обработки информации. В комплексу
объединяются несколько или десятки групп программ на ос-
нове единой базы данных для решения общей целевой задачи.
Размеры КП исчисляются сотнями модулей' и сотнями тысяч
машинных команд. Встречаются'комплексы программ, содер-
жащие до двух-трёх десятков структурных иерархических уров-
ней, построенных из модулей. Между модулями и группами
программ устанавливается сложное Информационное взаимо-
действие через переменные, которые могуТ содержать тысячи
имен. Формализация описаний комплексов программ еще слож-
нее, чем Групп программ. Увеличивается неопределенность
функций и критериев качества, что отражается на снижении
степени формализации как формы, так и содержания техниче-
ских заданий и спецификацйй. Многие разработки проходят
19
итерационный путь с последовательным расширением функ-
ций КП, уточнением их целей и структуры.
Важнейшими компонентами КП являются данные различ-
ных типов. Описание данных й их структурное построение мо-
жет быть независимым от структуры взаимодействия
программных модулей. Для переменных может быть установ-
лена собственная структурная и функциональная иерархия.
Структурная иерархия данных определяет правила групци-
'рования переменных в зависимости от типов. Наиболее чет-
ко можно выделить простые переменные и, массивы перемен-
ных. Простые переменные представляют собой минимальную
компоненту данных , имеющую имя и описание. Описание пере-
менной должно быть полным и исключающим неопределен-
ность при любом использовании его значений. Из простых пе-
ременных по некоторым правилам упорядочения образуются
массивы. Мощность массива характеризуется количеством
различных значений простых переменных, составляющих дан-
ный массив. Разработан ряд типовых структур массивов 1221,
каждая из которых выбирается на основе компромисса между
емкостью памяти для хранения конкретного массива и затра-
тами производительности ЭВМ, необходимой для выборочно-
го поиска данных в массиве. Описание массивов переменных
содержит имя массива, назначение и формуляр, отражающий
структуру массива и полные характеристики каждой простой
переменной, размещенной в массиве.
Функциональная иерархия данных отражает расстояние
между расчетом переменной и ее использованием или условную
длительность хранения значений переменной без применения
или изменения. Переменные или массивы, которые рассчиты-
ваются внутри программного модуля, т. е. являются резуль-
татами промежуточных расчетов, называются локальны-
м и. Взаимодействие двух модулей может осуществляться так,
что некоторые переменные используются только этими моду-
лями. Такие переменные имеют более широкую область при-
менения и должны храниться все время, пока-будут взаимо-
действовать модули, их называют обменными.
Наконец, ряд переменных и массивов используется мно-
гими модулями и группами программ в комплексе — гло-
бальные переменные. Они соответствуют высшим иерар-
хическим уровням среди данных. Такие переменные в основ-
ном определяют сложные связи внутри комплекса или группы
Программ по получению, применению и преобразованию ин-
формации. Функциональная иерархия программ может влиять
на структурное построение массивов данных и нх иерархию.



I





14
1.2. ОСНОВНЫЕ ПОНЯТИЯ СИСТЕМАТИЧЕСКОГО ТЕСТИРОВАНИЯ
ПРОГРАММ И ХАРАКТЕРИСТИКИ ВЫЯВЛЯЕМЫХ ОШИБОК
Общие принципы тестирования программ. Для создания
любых изделий применяются соответствующие технологии.
При этом в понятие те хнология включаются совокуп-
ность производственных процессов, методов и. средств, пред-'
назначенных для создания определенных видов изделии с за-
данными показателями качества. Одним из самых сложных и
трудоемких этапов технологического процесса разработки про*
грамм является их отладка. На отладку приходится около 50 %
трудоёмкости из общих затрат на создание сложных комплек-
сов-программ. Под отладкой понимается процесс, позволяющий
получить программу, функционирующую с требующимися
характеристиками в заданной области изменения входных дан-
ных. Таким образом, в. результате отладки программа должна
соответствовать некоторой фиксированной совокупности пра-
вил и показателей качества, принимаемой за эталонную для
данной программы.	. -
Процесс отладки программ включает (рис.. 1.2);
создание совокупности тестовых эталонных значений и пра-
вил, которым должна соответствовать программа по выпол-
няемым функциям, структуре, правилам описания, значениям
исходных и соответствующих им результирующих данных;
статическое тестирование текстов разработанных программ
и данных на выполнение всех заданных правил построения и
описания без исполнения объектного кода;
тестирование программы с ее исполнением в объектном ко-
де и с разными уровнями легализации: детерминированное,
стохастическое и тестирование в реальном масштабе времени;
диагностику и локализацию причин отклонения результа-
тов тестирования от заданных эталонных значений и правил;
разработку изменения программы с целью исключения
причин отклонения результатов от эталонных;
реализацию корректировки программы, обеспечивающую
соответствие программы заданному эталону.
Контроль правил построения и описания программ и дан-
ных предполагает точную формализацию этих правил и про-
верку степени их выполнения. Относительно небольшое чис-
ло используемых правил описания и построения программ и
данных, а также четкая их формализация позволяют построить
высокоавтоматизированные методы и средства контроля, и ав-
томатически выявлять отклонения от таких эталонов [2, 61).
Эти методы включают синтаксический и семантический конт-
роль текстов программ и данных, которым посвящена доста-
точно обширная литература (21, 24, 81, 91). I
----1	15
Основным методом обнаружения ошибок при отладке про-/
грамм является их те с т и р.о в а н и е. При этом затраты иа )
тестирование.для обнаружения ошибок являются наибольши- '
ми, достигают 30—40 % общих затрат на разработку программ ‘i
и в значительной степени определяют качество созданного про- I
граммного продукта. Высокая доля затрат на тестирование
приводит к необходимости создания методов и средств, позво- ?
лающих достигать максимального качества программ при ре- у
альных ограничениях на длительность тестирования и на свя- J
фарные с этим, затраты. Эффективность тестирования является J
важнейшим фактором, определяющим стоимость и длитель- ’
ность разработки сложных КП с заданным качеством..Вследст- !
вне этого создаются различные методы систематического н ре- !
гдаментированного тестирования, обеспечивающие, наилучшее !
использование ресурсов проектирования с учетом особенностей i
создаваемых программ.	т . '
. Т «стировмие программ
де
Имеются некоторые трудности 114. 451 определения сути
и задач тестирования программ. Эти трудности связаны с Из-
менением задач тестирования иа разных стадиях отладки про-
грамм (см. рис. 1.2) И С попытками дать короткое единое опре-
деление, пригодное для всех стадий. Для определения задач
тестирования целесообразно выделить три стадии:
тестирование для обнаружения ошибок в программе;
тестирование для диагностики ;й локализаций причин обна-
руженных искажений результатов;
тестирование для контроля выполненных корректировок
программ и данных.
Основной целью тестирования для обнаружения
о ш и б о к' является выявление всех отклонений результатов
функционирования реальной программы от заданных эталон-
ных значений/ При этом задача состоит в обнаружении макси-
мального числа ошибок, в качестве которых принимается лю-
бое отклонение от эталонов. На этой стадии успешным являет-
ся тестирование, которое приводит к обнаружению ошибок.
- Если в результате тестирования ошибки не выявлены, то про-
веденные операции не дали сведений, позволяющих повысить
Диагностика	Корректировка
и локализация ошибок тестируемых программ
; Рис. 1.2. Общая схема откладки программ

качество программ и тем самым не оправдали затрат. Таким,
образом, эффективными являются операции-‘тестирования,
обладающие высокой способностью по обнаружению ошибок
в программе. Чем больше? ошибок выявляется-на этой стадии
при каждой' операции тестирования, тем ’выше их эффектив-
ность и обоснованность затрат на их выполнение. С этих пози-
ций тесты, не способствующие обнаружению ошибок > и только
подтверждающие корректность функционирования программ,
являются неэффективными, так как приводят к'бесполезным
затратам. Например, можно многократно подтверждать пра-
вильность исполнения программы при всех промежуточных
значениях переменных, когда проверены предельные и особые
значения. Одиако такое тестирование характеризуется прак-
тически нулевой обнаруживающей способностью, и поэтому
бесполезно.
После тестирования для обнаружения ошибоктфименяет-
ся. тестирование для их диагностики и лока ли-
зации. Его цели и методы несколько отличаются от тех,
которые соответствуют первой стадии тестирования. На этой
стадии важнейшая задача — точно установить место искаже-
ния программы или данных, явившегося причиной отклонения
результатов от эталонных при тестировании для обнаружения
ошибок. Тем самым определяется часть программы, подлежа-
щая корректировке. Эффективными являются тесты, способст-
вующие быстрой и точной локализации первичных ошибок;
На этой стадии затраты оправданы и тестирование'можно Счи-
тать успешным, если оно приводит к полной локализации
ошибки, подлежащей исправлению
После локализации и устранения обнаруженных ошибок
применяется контрольное тестирование, задача кото-
рого состоит в подтверждении правильности выполненной кор-
ректировки программы и в отсутствии проявления ранее об-
наруженных ошибок. В этом случае успешность тестирования
определяется отсутствием проявления ранее обнаруженной,
локализованной и устраненной ошибки, а также отсутствием
вторичных ошибок, которые могут появиться при корректиров-
ке.
Упорядочение при тестировании. Для тестирования при-
меняются методы, предусматривающие упорядочение и систе-
матизацию тестов по различным стратегиям и параметрам, и
методы неупорядоченного тестирования При неупорядочен-
ном тестировании исходные данные, имитирующие внешнюю
среду, случайным образом генерируются во всем диапазоне
возможного изменения параметров, производится случайный #
перебор значений в произвольных сочетаниях различных ве*
18
личин. При этом многие значения, исходных данных характе-
ризуются малой вероятностью обнаружения ошибок и не,оп-
равдывают затраты на выполнение тестирования. Кроме того,
Возможно появление данных, логически противоречивых. В
то же время данные, наиболее важные с позиции реального ис-
пользования программ и возможности обнаружения ошибок,
могут оказаться не охваченными в процессе тестирования.
При реально существующих ограничениях на объемы тести-
рования его неупорядоченное применение оказывается мало-
эффективным и почти не находит применения.
Стремление к рациональному использованию ограничен-
ных ресурсов приводит к систематизаций процес-
са и методов т е с т и р о в а ни я. Методы, упоря-
доченного тестирования базируются на выделении факторов и
параметров, позволяющих эффективно распределять ресур-
сы тестирования с учетом их влияния на качество программ.
Систематизация может значительно изменяться в зависимости
от этапов тестирования, однако можно выделить несколько
общих принципов, на базе которых строятся основные методы
тестирования. Для упорядочения операций тестирования ис-
пользуется информация о структуре программы и процессе
обработки информации, о характере изменения и взаимосвя-
зи переменных, о наиболее вероятных и важных сочетаниях ис-
ходных данных, о характеристиках ошибок и вероятности их
проявления и т. д. В- результате ограниченные ресурсы тес-
тирования используются прежде всего для обнаружения наи-
более опасных ошибок в наиболее важных режимах функцио-
нирования программ. С этой целью последовательно приме-
няются методы тестирования: статический, детерминирован-
ный, стохастический и в реальном масштабе времени.
Статическое тестирование является наиболее формали-
зованным и автоматизируемым методом проверки корректно-
сти программ. В качестве эталонов применяются правила
структурного построения программных модулей и обработки
данных, конкретизированные для проекта КП в целом. Кро-
ме того, могут использоваться некоторые частные правила об-
работки данных, зафиксированные в спецификациях на от-
дельные компоненты программ. Проверка степени выполнения
этих правил проводится без исполнения объектного кода про-
граммы путем формального анализа текста программы на язы-
ке программирования. Операторы и операнды текста программ
при этом анализируются в символьном виде, поэтому такой ме-
тод называют также символическим тестированием [6, 81].
Развитие и углубление символического тестирова-
ния может доводиться до уровня формальной верификации
• 19
программы на соответствие ее текста детальной спецификации
совокупности утверждений, полностью определяющей связи
между входными я выходными данными этой программы.
Наиболее трудоемкими и детализирующими являются ме-
тоды детерминированного тестирования. При детерминирован-:
ном тестировании контролируется каждая комбинация исход-
ных эталонных данных и соответствующая ей комбинация ре-
’ зультатов функционирования программы. Это  позволяет вы-
являть отклонение  результатов от эталона с конкретным ,
фиксированием всех значений исходных и результирующих,
данных, при которых, это отклонение обнаружено.
В сложных программах невозможно перебрать все комби-
нации исходных данных и проконтролировать результаты функ-
ционирования программы на каждой из них. В таких случаях '
применяется стохастическое, тестирование, при котором, ис-
ходные тестовые данные задается множествами случайных
величии с соответствующими распределениями и для сравнения'
. полученных результатов используются также распределения
случайных величин. В результате при стохастическом тести-,
ровании возможно более широкое варьирование исходных дан- •’
ных, хотя отдельные ошибки могут быть не обнаружены, если 1
они мало искажают средние статистические значения или рас-
пределения. Стохастическое тестирование применяется в ос-
новном для обнаружения ошибок, а для диагностики и локали-
зации ошибок приходится переходить к детерминированному
тестированию с ’использованием конкретных значений пара-
метров из области изменения ранее . использовавшихся ''слу-
чайных величин.	•		• /
Последующее расширение области изменения исходных дан-
ных возможно при применении тестирования в реальном мас-
штабе времени. В процессе такого тестирования проверяется
исполнение программ и обработка исходных данных с. учетом
времени их поступления, длительности и приоритетности Об-
работки, динамики использования памяти и взаимодействия с
другими программами и т. д. При обнаружении.отклонений ре-
зультатов исполнения программ от Предполагавшихся эталон-
ных для локализации ошибки приходится фиксировать: вре-
мя и; НерехОдить к детерминированному тестированию.
Основное внимание при упорядоченном тестировании сос-
редоточивается на обнаружений ошибок при исходных данных
и "условиях функционирования, заданных требованиями тех-
нического задания. Одиако в реальных условиях на вход про-
граммы могут попадать сильно искаженные иди ложные дан-
ные. Программы должны сохранять свою работоспособность
после поступления таких данных или: восстанавливать работо-
, <	:	' -кЮ
20












>





I
способность при последующем поступлении данных, изменяю-
щихся в заданных пределах. Для этого тестирование необ-
ходимо проводить не только при корректных исходных дан-
ных, но и при искаженных. В связи с этим упорядоченный под-
ход к тестированию может базироваться на критериях дости-
жения максимальной корректности или мак-
симальной надежности программ.
На этапе комплексной отладки и испытаний доминирующим
может стать критерий надежности функционирования.' Прй
этом в максимальной степени учитывается статистика внеш-1
них ситуаций исходных данных и статистика исполнения ком-
понент программы. Основное внимание сосредоточивается на
обнаружении ошибок,' нарушающих работоспособность про-
грамм, и могут ие выявляться ошибки, искажающие результа-
ты, но не вызывающие отказовые ситуации; Переход на кри-
терий обеспечения надежности функционирований подготав-
ливается при тестировании модулей и-групп программ, дЛя'
чего используются характеристики динамики их функций-’
пирования.	.'
Данные: о вероятности или частости исполнения маршру-
тов Или операторов помогают выделить интенсивно используеУ
мые компоненты программ, которые целесообразно подвергать,
наиболее тщательной проверке'. Априорно иа базе представ-
лений разработчика о динамике функционирования создавае-
мой программы или по характеристикам,, полученным в про-
цессе, рабочего функционирования, может быть составлен
профиль программ 114, 78, 821. В профиле программы
обычно содержится информация о частости и длительности вы-
полнения каждого оператора, вероятность выполнения каж-
дого логического условия, предельные значения некоторых'
переменных, количество итераций в циклах нт. д. Эти данные
для каждой программы могут получаться автоматически в
процессе ее исполнения или обобщаться и уточняться по мере
развития тестирования программ, в результате чего:
выделяются наиболее активные компоненты программы, про-
шедшие тщательную проверку, а также компоненты, требую-
щие повышенного внимания, с малой или нулевой частотой про-
верки исполнения, подлежащие дополнительному тестирова-
нию;	.	'	,	’
статистика условных переходов и итераций циклов дает
информацию для обнаружения некоторых типов ошибок;!
длительность исполнения маршрутов позволяет оценивать
длительности исполнения модулей или. групп программ, что
особенно важно для систем реального времени.
21
Данные о профиле программы способствуют прежде всего
достижению высокой надежности функционирования про-
грамм. Этому также способствует тестирование, средств по-,
мехозащиты, оперативного контроля и восстановления;
(см. гл. 4). При этом надежность программы может возрастать;
значительно быстрее, чем корректность.
Увеличение числа охватываемых компонентов процессу
тестирования возможно в двух направлениях. При система?^
ческом восходящем тестировании прежде всего проде-'
ряются модули нижних иерархических уровней, к которым по-;
степенно подключаются вызывающие их модули. При
обеспечивается работоспособность вызываемых,, компонент и;
функции, группы программ проверяются в их естественном ис-
полнении. Основные трудности состоят в необходимости пол-,
ного. обновления тестовых наборов при подключении каждой!
новой программы более высокого, у ровня, Однако все участ-д
вующие в тестировании модули нижних иерархических уров-
ней тестируются детально и независимо, что обеспечивает ид:.
Высокую корректность, при подключении к вызывающим моду а ;
лям.
При нисходящем тестировании проверки начинают^
ся с программ управления и организации вычислительного
процесса. Первоначально тестируется управляющее ядро ком-
плекса программ и программы решения функциональных за- I
дач, размещенных, на высших иерархических уровнях. К ним
постепенно подключаются для тестирования программы после- ,
дующих более низких иерархических уровней. Если програм-
мы нижи их уровней не разработаны или не протестированы, 1
то вместо них включаются программные имитаторы — «за- !
глущки». В результате при тестировании осуществляется про-
верка некоторой модели группы программ с имитаторами ид
нижних иерархических уровнях. Преимуществом такого ме-
тода является возможность сохранения и развития наборов
тестовых исходных данных по мере подключений программ
нижних уровней. С самого начала тестирования могут исполь-
зоваться исходные данные, соответствующие реальному функ-
ционированию КП, с последовательно снимаемыми ограниче-
ниями. При этом наиболее полно и на ранних этапах проверя-
ется межмодульный интерфейс. Однако тестирование групп .
программ с заглушками может требовать больших затрат иа ’
обнаружение простейших ошибок в модулях нижних иерархи-
ческих уровней по мере их подключения, если они до этого не ,
тестировались.
На практике оба метода используются совместно с, учетом
сложности тестируемых групп программ и реальных планов
22
Проектирований" КП. Модули и группы Программ" многократ-
ного использования'Преимущественно тестируются по восходя-
щему Методу, а управляющие й уникальные модули с Малым
числом вызываемых Программ при небольшом числе иерархиче-
ских уровней целесообразнее- тестировать по нисходящему
методу.	"
Программы условно Можно разделить на д в а класса:
"программы, содержащие преимущественно вычисления и пре-
образования квазинепрёрывных переменных, и программы,
характеризующиеся выработкой логических решений и обра-
боткой кодовых или символьных переменных.’Отнесение ре-
альной программы к вычислительной или логической зависит
от преобладающего вида содержащихся,в ней переменных. Для
программ с большой долёй вычислений в первую очередь це-
лесообразно тестировать модули и их части, содержащие наи-
более сложные или важные вычисления. При этом в тестах
варьируются значения квазинепрерывных переменных в со-
ответствии с диапазонами их изменения, а логические условия
и Логические переменные фиксируются для выбора основных
вычислительных маршрутов. После проверки маршрутов с
основной частью вычислений производится варьирование ло-
гических условий и тестирование остальных маршрутов ис-
полнения программ.
В логических программах с большой долей операторов при-
нятия решений тестирование должно начинаться с наиболее
длинных или наиболее вероятно исполняемых Маршрутов.
В этом случае в составе тестов изменяются значения перемен-
ных, влиящщих на выбор маршрутов исполнения программ,
а переменные, подлежащие преобразованиям и вычислениям,
первоначально фиксируются. Методы планирования тестиро-
вания базируются на упорядочении проверяемых маршрутов
по степени их влияния на корректность структуры программ
(убывание длительностей и числа условий в маршрутах) или
по степени их влияния на надежность функционирования про-
грамм (убывание вероятностей исполнения маршрутов). Вы-
числительная часть в таких программах тестируется после
завершения тестирования основной части логики.
Значительное повышение корректности и надежности про-
грамм достигается применением двойного или N-к рат-
ного программирования [50]., При этом методе по одинако-
вой спецификации, но, возможно, при разных алгоритмах И на
. разных языках программирования создаются несколько вари-
антов программы. Эти варианты реализуют одни и те же функ-
ции и при определенных тестовых данных должны выдавать
тождественные результаты. Различие результатов при тестй-
23
рованин указывает йа наличие ошибок, nd крайней мере, в'
одном из вариантов, который подлежи? локализаций путейК
анализа промежуточных данных. Если для проверки коррект-
ности сравнивать результаты функционирования' более двуМ
вариантов программ, то методом голосования возможно выде-
лить вариант, содержащий ошибку. '-'	1Л
'  Обычно при разработке вариантов программы иСпользу-'
ется один и тот же алгоритм, но программы создаются на paW
вых языках и разными.программистами. Один из вариантов**
считается контролируемым и подлежащим отработке дляпд^
следующего практического применения. К этому варианту*
предъявляются дополнительные требования по эффективности
использования вычислительных ресурсов ЭВМ, поэтому мо<
жет оказаться необходимым применение языков программй- V
рования типа ассемблера. Другие варианты той же программ1
мы применяются как контрольные и создаются на языках про*
граммирования высокого уровня. Это позволяет несколько со-
кращать затраты, одиако в целом М-кратное программирование ;
увеличивает затраты-иа написание программ почти в соот-<
ветствующее'число раз. По существу, создаваемые варианты
являются моделями рабочей программы и служат для получе-
ния достоверных эталонных тестовых значений. Эти варианты
программы могут иметь более высокую точность вычислений,
однако содержать некоторые технические упрощения, недопу-
стимые в контролируемой программе. При сравнении результа-
тов тестирования вариантов программ должны учитываться
допуски и различия в точности вычислений, а также отклоне-
ния. в алгоритмах.
Повышение затрат на разработку вариантов программ ком-
пенсируется снижением затрат на тестирование каждой из
них, а главное, повышением достигаемой корректности. На-
личие вариантов программы облегчает получение результатов
тестирования, которые можно рассматривать как эталонные,
тем более, что программирование на языках высокого уровня
исключает некоторые типы ошибок. На Практике применяет-
ся'программирование с N С 2. Практически неизвестны слу-
чаи, когда реальная программа создавалась в трех и более ва-
риантах Имеются примеры 1751 успешного применения Двой-
ного программирования на алгоритмическом языке АПЛ при
подготовке тестов для программ на Фортране. Исследованы
преимущества моделирования алгоритмов на АПЛ по срав-
нению с языками ПЛ/Г и Паскаль. Однако пока отсутствуют
оценки эффективности этого метода. '
Перечисленные методы систематического тестирования на-
правлены на обеспечение выполнения программами основных
24
функций, определенных техническим заданием. Каждый из;
методов позволяет обнаруживать ошибки определенных клас-
сов и наиболее полезен при некоторых условиях/Ни один иа
методов не может обеспечить "эффективное тестирование всех,
классов программ:в любой области их применения. Для оценки
эффективности методов и рационального ИХ применения целе-
сообразно изучать характеристики ошибок, выявляемых каж-
дым из них. Базируясь на статистике обнаружения ошибок'
в некоторых КП, можно создать методики упорядоченного
тестирования для выявления такого же числа ошибок каждо-.
го типа во вновь создаваемых программах при минимальных •
суммарных затратах. Прй этом усилия на тестирование для
обнаружения ошибок должны распределяться в соответствии :
с частостью типов ошибок в ранее созданных КП. Для этого
необходимо знать детальные характеристики ошибок в про*
граммах, часть из которых рассмотрена ниже.
Основные характеристики ошибок в программах. Неодно-
кратно экспериментально установлено, что в любом сложном1
КП в процессе эксплуатации обнаруживаются ошибки, даже:
если проведено самое тщательное тестирование. Тем самым ут-
верждается объективная реальность, заключающаяся в не-
возможности формализовать и обеспечить абсолютную полно-
ту всех эталонных значений, а также провести всеобъемлю-
щее исчерпывающее тестирование и гарантировано устранить
все ошибки в сложных КП- Важной особенностью тестирова-
ния программ является невозможность получения полностью
определенной абсолютной корректной программы, . которую
можно было бы использовать в качестве эталона без ошибок
для сравнения с ней создаваемой программы. Поэтому при тес-
тировании первоначально обнаруживаются вторичные
ошибки, которые являются отклонениями некоторых резуль-
татов функционирования программ от предполагаемых эталон-
ных значений. Тестирование для локализации ошибки позво-
ляет, установить причину вторичной ошибки в выявить л е р-
в и ч и у ю ошибку, подлежащую исправлению.
Анализ многих проектов показывает 111, 50, 66), что до на-
чала тестирования число, ошибок в сложных программах со-
ставляет порядка 1—2 % от общего числа объектных команд в
программе, т. е. в КП объемом 100 тыс. команд в процессе тес-
тирования обычно выявляется 1—2 тыс. ошибок. При тщатель* 
ном системном проектировании н программировании на яэы4
ках высокого уровня начальное число ошибок в несколько
раз Меньше. Самое тщательное тестирование сложных программ
позволяет получить программы с Вероятностью ошибки в
каждой команде порядка 1О~*—10~\ т. е, несколько ошибок/
25 
'.может остаться 114,13,45]. После завершения тестирования и
Испытаний КП в течение нескольких лет эксплуатации и со-
провождения могут быть выявлены еще десятки ошибок. 
Первичные ошибки в программах в различной степени ис-
' кажают результаты, которые, первоначально обнаруживаются
как вторичные ошибки в процессе тестирования, каждая пер-
вичная ошибка Л-готипа отражается как вторичная ошибка
j-ro результата с некоторым коэффициентом пропорциональ-
ности Если в некоторый момент тестирования имеющиеся
первичные ошибки характеризуются вероятностями проявле-
ния Qh (см. § 3.3), то они будут приводить к интегральным вто-
ричным ошибкам с интенсивностью или весом 150]
q т
2 2	<1Л>
/=1*=1
где т — полное число возможных типов ошибок в программах;- ,
q — полное число контролируемых результатов, в которых мо-
гут проявляться вторичные ошибки.
Однако прямыми измерениями невозможно установить ко-
эффициент влияния первичных ошибок на вторичные &kj,
а также вероятность первичных ошибок Qh. Поэтому исследо-
ваны, в основном, обобщенные характеристики вторичных
ошибок и некоторые общие закономерности проявления пер-
вичных ошибок в процессе тестирования программ.
В результате анализа н обобщения экспериментальных
данных ряда реальных разработок предложено 144, 89, 971
несколько математических моделей, описывающих основные
закономерности изменения суммарного числа втор и, ч ных
ошибок в программах. Модели имеют вероятностный характер,
и достоверность прогнозов в значительной степени “зависит
ОТ точности исходных данных и глубины прогнозирования по
времени. Эти математические модели предназначены для оцен-
ки:
возможного изменения надежности функционирования в
процессе отладки, испытаний и эксплуатации;
числа ошибок, оставшихся невыявленными в тестируемых
программах;
времени, требующегося для обнаружения следующей ошиб-
ки в функционирующей или тестируемой программе;
времени, необходимого для выявления всех ошибок с за-
данной вероятностью.
Точное определение полного числа невыявленных ошибок
в КП прямыми методами измерения невозможно, так как в
противном случае их можно было бы все зафиксировать и
26
устранить. Однако имеются косвенные пути для приближенной
статистической оценки их полного числа или вероятности бшиб-
•ки.в каждой команде программы. Такие оценки базируются-на
построении математических моделей в предположении жесткой
корреляции между общим числом ощибок и их проявлениями
в некотором КП после его отладки в течение времени т, т. е.
между следующими параметрами:
 ? . суммарным числом первичных ощибок в КП (пв), или ве-
роятностью ошибки в каждой команде программы (д0);
к числом вторичных ошибок, выявляемых в единицу времени
® процессе тестирования и отладки при постоянных усилиях
на ее проведение (dn/dr);
интенсивностью искажений результатов в единицу времени
(X) на выходе КП (вследствие невыявленных первичных оши-
бок) при функционировании системы в типовых условиях.
Частость проявления вторичных ошибок при рабочем функ-
ционировании программ и частость их обнаружения при тести-
ровании зависят от общего числа первичных ошибок в про-
грамме или от вероятности ошибки в команде. Можно предпо-.
дожить, что все три показателя связаны некоторыми коэффи-
циентами пропорциональности, значения которых зависят в
частности, от интервала времени, на котором производится со-
поставление, от быстродействия ЭВМ, от эффективности средств
автоматизации отладки и от некоторых других параметров.
Однако при фиксированных условиях разработки и функцио-
нирования некоторого конкретного КП эти коэффициенты
должны иметь вполне определенные значения. Для другой по-
добной системы коэффициенты могут несколько измениться,
однако можно предположить, что оценки, проведенные для
нескольких близких по сложности и функциям систем, позво-
лят прогнозировать эти характеристики, а следовательно, и.
соответствующие показатели качества программного обеспе-
чен ня. в зависимости От длительности отладки и ряда других
факторов для вновь создаваемых КП-
В настоящее время описаны несколько математических мо-
делей 144, 89, 93, 971, основой которых являются различные
гипотезы о характере проявления вторичных ошибок в КП.
Эти допущения в той или иной степени апробированы при об-
работке данных реальных разработок и их можно разделить на
три группы.
Первая группу допущений включает прежде все-
го гипотезу о наблюдаемости искажений данных, программ или
вычислительного процесса, обусловленных первичными ошиб-
ками в программах. Точнее, первичная ошибка, являющаяся
причиной искажения результатов, либо фиксируется и ис-
'	27
Управляется после завершения этапа тестирования, либо вооб-
ще не обнаруживается, так как проявление ее последствий й
виде вторичных ошибок незначительно. '
Предполагаете^, что набор тестов, применяемых при отлад-
ке, достаточно полно отражает все внешние условия , в которых
предстоит эксплуатация программы. Множество тестов бодёр
«ли менее равномерно покрывает все множество реальны* ис-
ходных данных, и отсутствуют априорные сведения для искус;
ственного повышения рнтеисивности проявления ошибок при
некоторых тестах.	'7	-
' Типы исполняемых в программе команд перемешаны, по-
этому Время нормальной работы между проявлениями ошибок
определяется средним временем выполнения команды на дацг
ной ЭВМ и средним количеством команд, исполняемых между
бшибками. В результате интенсивность проявления ошибок
при реальном функционировании программ зависит от. сред?
него быстродействия ЭВМ и практически не зависит от конкрет-
но распределения типов команд на маршрутах обработки
данных между ошибками. В общем случае-интенсивность про-
явления ошибок зависит также от интенсивностей потоков тес-
товых данных и их состава. Предполагается, что состав и дру-
гие характеристики тестов способствуют максимальному об-
наружению ошибок.
Коллектив специалистов, их квалификация и загружен-
ность предполагаются постоянными на интервале проектирова-
ния и исследования характеристик ошибок. Также постоянным
считается доступное машинное время .для проведения прове-
рок программ. Реальные флюктуации доступных ресурсов
обычно невелики и учет их изменения практически ие отража-
ется на точности моделей, так как ряд случайных факторов
Сглаживает влияние изменения ресурсов.
Вторая группа допущений при- построении мате-
матических моделей , ошибок является основной и’подлежит
проверке по статистическим экспериментальным данным ре-
альных разработок программ. Ниже рассмотрены допущения
при построении экспоненциальной модели [89, 97],
.л Интервалы времени между обнаруживаемыми искажения-
ми результатов предполагаются статистически независимыми.
Время измеряется по фактической наработке исполнения про-
грамм т без учета затрат календарного времени на локализа-
цию, диагностику и исправление ошибок. Гипотеза статистиче-
ской 'независимости временных интервалов между ошибками
достаточно хороню подтверждается экспериментальными дан-
ными.
28
Предполагается, что интенсивность проявления ошибок ос-
тается постоянной, пока ие произведено исправление первичной
ошибки или не изменена программа по другой, причине. Если
каждая обнаруженная, ошибка исправляется, то Значения ин-
тервалов времени между их. проявлениями изменяются по
экспоненциальному закону. Аппроксимация распределения
времени обнаружения ошибок'более сложными (чем экспонен-
та) функциями не дает заметно лучшего приближения к экспе-
риментальным данным [89, 1011, особенно на> завершающих
стадиях тестирования. ' '' '
Логично предположить [93, 97), что интенсивность обнару-
жения вторичный ошибок пропорциональна суммарному чис-
лу первичных ошибок, имеющихся в данный момент в КП.
Построена функция линейной регрессии между числом ошибрк
и интенсивностью их обнаружения и определен коэффициент
взаимной корреляции, который в среднем составляет около
0,85, что следует считать хорошим подтверждением право-
мерности выдвинутой гипотезы.
Каждая обнаруженная ошибка подлежит исправлению, рр-
этЬму можно предположить, что частота исправления ошибок
пропорциональна частоте их обнаружения. Однако некоторые
исправления в свой) очередь содержат ошибки. Кроме того,
некоторые ошибки являются связанными, н при обнаружении
проявления одной ошибки следует исправление нескольких
первичных ошибок. Поэтому частота обнаружения ошибок й
частота их исправления не равны, а связаны некоторым ко-
эффициентов пропорциональности.	'	.
Третья гр у п п а допущений детализирует исполь-
зование ресурсов на корректировку программ и Повышение их
качества. Необходимо учитывать; что их значения тесно свя-
заны с конкретной технологией Проектирования программ, сте-
пенью ее автоматизации/ квалификацией коллектива и т.д.
Поэтому коэффициенты могут изменяться дЛя разных Проек-
тов в довольно широких пределах.	< ;
В процессе тестирования могут выявляться и накапливать-
ся группы ошибок, которые образуют очередь для корректи-
ровки программ. Предполагается, что длина очереди обнару-
женных и ожидающих исправления ошибок определяется пуас-
соновским потоком, выбор ошибок из очереди для очередных
корректировок; производится случайно, а затраты труда на
корректировку ошибок (в человеко-часах) подчиняются экс-
поненциальному закону распределения.
Приведенные допущения позволяют/построить экспонен-
циальную математическую модель распределения ошибок в
программах и установить связь между интенсивностью обна-
29
. »
„ружения вторичных ошибок при тестировании dnfdx, интен-
сивностью X проявления ошибок при нормальном функцио-
нировании КП и числом выявленных первичных ошибок п.
При этом учитываются все типы ошибок независимо от их ис-
точников и происхождения (технологические, программные,
алгоритмические, системные [50]).
При постоянных усилителях на тестирование интенсив-
ность обнаружения искажений вычислительного процесса, про-
грамм или данных вследствие еще невыявленных ошибок про-
порциональна числу я0 оставшихся первичных ошибок в КП.
Тогда
dnldx = О = Кп0 = К (No — л),	(1.2)
где No — число ошибок в КП в начале отладки, а коэффициен-
ты К и К' учитывают: масштаб времени, используемого для
описания процесса обнаружения ошибок, быстродействие ЭВМ,
распределение тестовых значений на входе проверяемого ком-
плекса и Другие параметры. Значение коэффициента К' мож-
но, в принципе, определить как изменение темпа Проявления
ошибок при переходе от функционирования программ на спе-
циальных тестах к функционированию на нормальных типо-
вых исходных данных. Так как предполагается, что в начале
отладки при т = 0 отсутствуют обнаруженные ошибки, то
п — No [1 —- exp (—/Сг)].	(1.3)
Число оставшихся первичных ошибок в КП
л0 = Мо ехр (--Кх)
пропорционально интенсивности обнаружения dn/dx с точно-
стью до коэффициента К-
Длительность функционирования программ (наработка),
между проявлением ошибок, которые рассматриваются как
обнаруживаемые искажения программ, данных или вычисли-
тельных процесса, равна величине, обратной интенсивности об-
наружения ошибок
Т=’ехр(/<г)..	'	°-4>
/ ат KN©
Если известны все моменты обнаружения ошибок tt и
каждый раз в эти моменты обнаруживается и достоверно устра-
няется одна первичная ошибка, то, используя метод макси-
мального правдоподобия, можно получить уравнение для ой-
30
K^nl(N0
I \	,=>i z=i
ределения значения начального числа•первичных ошибок N,
«2'< .
---- ---LJL---------.	(i.5)
N° 2 2 <*—’ю
i=i /«=i
а также выражение Для расчета коэффициента пропорцио-
нальности	• '
(1.6)
В результате можно рассчитывать число оставшихся в програм-
ме первичных ошибок н среднюю наработку Т до обнаружения
следующей ошибки. Несложными преобразованиями можно
получить затраты времени на тестирование Ат, которые поз-
воляют устранить Ал ошибок и соответственно повысить нара-
ботку между очередными обнаружениями ошибок от, значе-
ния Л дб Тг	,
Ат = In (Л/Л)-	(1.7)
Следует' подчеркнуть статистический характер приведен-
ных соотношений. Неравномерность выбора маршрутов испол-
нения программы при нормальной эксплуатации, разное влия-
ние конкретных типов ошибок в программах на проявление
их при функционировании, а также сравнительно небольшие
значения п и Ал, особенно иа заключительных этапах отладки
приводят к тому, что Ат могут быть весьма значительными.
Изучение статистики первичных ошибок в КП, различаю-
щихся назначением, функциями и структурой, позволяет глуб-
же понять сущность ряда факторов и Показателей, определяю-
щих качество тестирования программ (11, 34, 56). Развитие
технологии создания сложных КП й средств автоматизации
проектирования приводит к изменению распределения ошибок
по типам^ начального уровня и интенсивности устранения оши-
бок в программах, однако опыт и результаты проведенных раз-
работок могут служить первым приближением при последую-
щих оценках и прогнозах. Длительность тестирования, а тем
самым и всей разработки, непосредственно зависит от требую-
щегося значения показателя сглаженности или от допустимого
количества иевыявленных ошибок, при котором разработку мо-
жно считать завершенной. После отладки в течение некоторого
времени интенсивность обнаружения ошибок при тестировании
31
унижается настолько, что коллектив ведущий разработку, по-
падает в зону нечувствительности к Ошибкам и отказам. Со-
здается представление о полном отсутствии ошибок, о невоз-
можности и бесцельности их поиска, вследствие чего усилия и»
отладку сокращаются и интенсивность обнаружения ошибоя
еще больше снижается. Пр^ серийном-выпуске систем с дай*
ным КП благодаря значительному расширению условий экс-
плуатации возможно в течение некоторого времени возраста*
пне суммарной (по всем экземплярам: системы) интенсивное!#
обнаружения ошибок. Это позволяет устранить еще ряд оийе-
бок и увеличить длительность между их проявлениями в прей
цессе эксплуатации.
1.J. КАТЕГОРИИ ТЕСТОВ
> Общие характеристики объектов на этапах тестирования»
Объекты тестирования изменяются в соответствии с поэтап-
ным развитием программ от уровня первичных целей и алго-
ритмов до уровня завершенного эксплуатируемого и сопровож-
даемого программного продукта. С позиции особенностей тес-
тирования наиболее характерными являются .объекты:
спецификации требований на программные модули, груп-
пы программ и комплекс;
программные модули, запрограммированные и подготов-
ленные к отладке;
группы программ', решающие законченные функциональ-
ные задачи;
комплекс программ, для которого завершаются все виды,
отладки;
Программное средство, подлежащее испытаниям перед пере-
дачей его на эксплуатацию;
сопровождаемый программный продукт до завершения его.
жизненного цикла.
Эти объекты-различаются сложностью для тестирования,
уровнем теоретической разработки методов и существующей
степенью автоматизации процесса тестирования. На рис. 1.3
Приведены оценки этих показателей для каждого вида объекта^
Приведенные графики имеют только иллюстративное зна-
чение с целью Показать общее состояние теорий и практики,
тестирования. Наиболее простым является тестирование спе-
цификаций требований, которые содержат.наименьшее коли*
чество информации о программах среди всех-рассматриваемых
объектов. По мере перехода от модуля к группе и Комплексу
программ сложность
объекта быстро возрастает,
тестирования
Тестирование
каждого отдельного
КП при комплекс-

32
нОй отладке, испытаниях и сопровождении по степени слож-
ности более или менее одинаково. Следует отметить, что инте-
гральная сложность (и соответственно трудоемкость) тести-
рования всей совокупности программных модулей, входящей
в комплекс, может быть выше, чем сложность тестирования КП
Ври испытаниях или сопровождении.
Уровень теоретической разработки
методов тестирования значительно зависит от объектов. Наи-
более полно в настоящее время исследованы методы тестиро-
вания программных модулей и небольших групп программ [3,
14,51,81 ]. Мало исследованными остаются методы и теория тес-
тирования в процессе отладки, испытаний и сопровождения
крупных КП, что отражено на рис. 1.3.
Степень автоматизации тестирования илщ
точнее, относительные, затраты на его обеспечение значитель-
но возрастают по мере увеличения сложности объектов тести-
рования (см. рис. 1.3). Автоматизация тестирования отстает От
потребностей практики. Наиболее автоматизировано тестиро-
вание модулей и групп программ. Автоматизация тестирова-
ния КП пока не соответствует реальной сложности объектов.
Слабо автоматизировано сопровождение КП.
Приведенные зависимости отражают общую картину поэтап-
ного тестирования. Они характеризуют необходимость значи-
Рис. 1.3. Сложность (—------), уровень теоретической разработки
{—  ) к степень автоматизации тестирования (—- — —) в зави-
симости от объектов тестирования
2 Зак Ю61	83 -'
тельного повышения уровня автоматизации тестирования групп
и комплексов программ, а также теоретических исследований
' в этой области. Рассмотрим основные задачи объектов поэтап-
ного тестирования, а также категории применяемых тестов
(рис. 1.4). В соответствии с задачами для каждого объекта мож-
но выделить несколько категорий тестов. Каждая категория
' имеет специфическое частное назначение для выявления оши-
бок определенного класса. Упорядочение категорий тестов и
ч____________________________________
Рис. 1.4. Категории тсстов'по объектам тестирования
34
их систематйческое применение способствует повышению пол-
ноты тестирования и экономии ресурсов на его выполнение.
Тестирование спецификаций требований. Программные спе-
цификации требований или формализованные технические за-
дания на КП и их компоненты используются для описания ос-
новных функций программ и -их взаимодействия. Программные
спецификации на модули и группы программ определяют функ-
ции этих компонент и связи между ними -по управлению и по
информации. В результате формализуется структура КП и его
крупных компонент, а также база данных и информационные
межмодульные связи. Основная цель тестирования специфика-
ции требований состоит в проверке полноты и взаимного со-
~'У
ТЕСТИРОВАНИЕ
КОМПЛЕКСА ПРОГРАММ
ПРИ ОТЛАДКЕ
"V
ТЕСТИРОВАНИЕ
КОМПЛЕКСА ПРОГРАММ
ПРИ ИСПЫТАНИЯХ
Категории тестов;
полноты решения фун-
кциональных задач ком-
плексом программ при
типовых исходных дан-
ных;
функционирования
программ в критических
ситуациях по условиям
и логике решения задач;
корректности исполь-
зования ресурсов памя-
ти и-производитепьности
вычислительной систе-
мы;
параппельного испол-
нения программ;
эффективности защи-
ты от искажений исход-
ных данных;
Определения надеж-
ности комплекса прог-
рамм;
оценки эффективнос-
ти защиты от сбоев ап-
паратуры и невыя в лен-
ных ошибок программ
---------1____________
V________
ТЕСТИРОВАНИЕ
ПРИ СОПРОВОЖДЕНИИ
КОМПЛЕКСА ПРОГРАММ
Категории тестов:
испытаний на соответ-
ствие комплекса прог-
рамм техническому за-
данию;
удобства эксплуата-
ции и взаимодействия
человека с комплексом
программ;
удобства установки и
подготовки рабочей вер-
сии;
работы комплекса
программ при конфигу-
рациях оборудования;
корректности доку-
ментации;
удобства сопровожден
имя н модификации про-
грамм

2*
35
' ответствия функций, предписываемых программным компо-
нентам разных иерархических уровней (см. § 1.1)'. Кроме того,
задачи тестирования включают проверку соответствия инфор-
мации на входах и выходах ваимодействующих программных
-модулей и групп программ. В результате тестирования спе-
цификаций должна быть установлена их корректность в пре-
делах общего описания функций и взаимодействия соответст-
вующих программных компонент.
Тест проверки полноты и согласованности функций про-
граммных компонент на уровне спецификаций предназначен для
выявления ошибок функциональных компонент при их пред-
ставлении программными спецификациями. Тестирование це-
лесообразно проводить по нисходящему методу, начиная от
спецификации комплекса или группы программ. Последова-
тельно по иерархическим уровням проверяется обеспечение
программ верхнего уровня функциями программ нижних уров-
ней, предписанными программными спецификациями. Тес-
тирование производится обычно вручную путем просмотра
„программных спецификаций по маршрутам исполнения групп
программ при решении определенных функциональных задач.
Корректировке подлежат программные спецификации моду-
лей и групп программ или вводятся новые компоненты КП с
недостающими функциями.
Тест проверки согласованности интерфейса в спецификациях
программных компонент, применяется для обнаружения оши-
бок в описаниях переменных и передачах управления при вза-
имодействии модулей и групн программ. По структурной схе-
ме комплекса или группы программ устанавливаете^ перечень
последовательно вызываемых модулей и проверяется коррект-
ность описаний вызовов в программных спецификациях. Для
каждой входной переменной сопоставляются ее наименова-
ния и описания в спецификации данного модуля или группы
программ описаниям в спецификациях модулей, где использу-
ется та же переменная. Тестирование может производиться с
применением средств автоматизации для селекции модулей,
использующих заданные переменные, и для выявления ошибок
при сравнении их описаний.
Тестирование программных модулей — наиболее формали-
зованный и автоматизированный процесс (см. гл. 3). Основная;
задача состоит в проверке обработки программными модуляг
ми поступающей информации и корректности получающихся
на выходе данных в соответствии с функциями, представлен-
ными в спецификациях. При этом должна быть проверена кор-
ректность структуры модулей и их основных конструктивных,
компонент: циклов, блоков, переключателей и т. д. Относи?
36
тельная простота программных компонент позволяет осущест-
влять весьма полное тестирование и контролировать степень
их проверки. Тестирование может планироваться с учетом
структуры модулей и особенностей обработки .информации и
осуществляется преимущественно детерминированно. На этом
этапе тестирования участвует наибольшее число специалистов,
и благодаря относительной простоте он доступен для достаточ-
но полной автоматизации 15, 811.
Тест проверки структуры программного модуля предназ-
начен для выявления ошибок в схеме принятия решений и ло-
гике функционирования модуля' Проверке подлежат маршру-
ты обработки информации в модуле и правильность их реали-
зации в зависимости от исходных данных. Полнота текста оп-
ределяется критериями выделения маршрутов для тестирова-
ния и степенью покрытия маршрутов исполнения программы.
На каждом выделенном маршруте проверяется корректность
выполняемых вычислений при-некоторых фиксированных ис-
ходных данных. При этом выявляются ошибки неполного со-
става или некорректности условий при реализации частных
маршрутов обработки данных, а также некоторые ошибки пре-
образования переменных. Выделение и упорядочение маршру-
тов для тестирования может быть автоматизировано, так же
как и контроль полноты охвата маршрутов тестами.
Тест проверки вычислений и преобразования данных про-
граммным модулем служит Для обнаружения ошибок в вычис-
лительной части программы. Для этого выделяются компонен-
ты программного модуля и маршруты обработки данных,
содержащие вычисления и преобразования переменных. В со-
став теста входят наборы значений исходных переменных во
всей области их определения. Особо выделяются комбинации
переменных в критических и особых точках, а. также сочетав
ния противоречивых и искаженных данных. ^Эталонами слу-.
жат результаты предварительных расчетов, по формулам, за1
ложенным в модуле. Наиболее часто обнаруживаются ошибки
при сочетаниях критических значений параметров и при не-
которых искажениях данных. Выделение вычислительной ча-
сти программы и соответствующих' маршрутов может быть
в значительной степени автоматизировано. Также удается авто-
матизировать выделение некоторых особых значений перемен-
ных, подлежащих первоочередной проверке.
Тест проверки полноты функций, выполняемых модулем,
предназначен для выявления ошибок в разработанной програм-
ме относительно функций, заданных в программной специфика-
ции. Тестированию подлежат реализация всех функций,’ оп-
ределенных спецификацией, и характеристики интерфейса^.
37
Для проверки функций используются результаты тестирова-
ния структуры и вычислений, которые дополняются тестами
для проверки неконтролировавшихся функций. Дополнитель-
ные тесты обычно содержат различные искажения и аномаль-
ные данные. Сравнение функций созданного программного
модуля с программной спецификацией трудно автоматизи-
ровать, и оно производится преимущественно вручную. Ав-
томатизировано могут сравниваться описания переменных мо-
дулей (например, в паспортах) с соответствующими описа-
ниями в спецификациях. Тестирование полноты функций за-
вершает проверку программного модуля.
Тестирование функциональных групп программ предназ-
начено для проверки корректности решения крупных автоном-
ных функциональных задач. На этом этапе проверяется кор-
ректность управляющих и информационных связей между мо-
дулями, а также корректность вычисляемых функций в процессе
обработки информаций. При этом значительно возрастает слож-
ность тестируемых объектов и соответственно объем тестов.
Вследствие этого возрастают требования к автоматизации тес-
тирования и затраты на его выполнение. Детерминированным
тестированием проверяются структура групп программ и ос-
новные маршруты обработки информации..В ряде случаев ос-
новные результаты получаются методами стохастического
тестирования. Эти методы пока слабо формализованы и их
применение в значительной степени зависит от конкретных
функций тестируемой группы программ. Автоматизация тес-
тирования групп программ значительно отстает от потребно-
стей практики.
Тест проверки структуры группы программ применяется
для выявления ошибок реального структурного построения
группы программ и его соответствия спецификации. Проверя-
ется правильность вызовов программных модулей и возвратов
управления при взаимодействии в группе программ. Реализую-
щаяся структура может быть построена автоматизированно
по паспортам разработанных программных модулей. Эта струк-
тура также автоматизированно может сравниваться с заданной
в спецификации на группу программ.
Тест проверки 'межмодульного интерфейса в группе про-
грамм предназначен для обнаружения ошибок информацион-
ных связей между модулями в группе. Контролируются так-
же связи через данные, подготавливаемые и используемые дру-
гими группами программ при взаимодействии с данной груп-
пой. Каждая переменная и массив переменных проверяются
на тождественность описаний во взаимодействующих модулях,
а также на соответствие исходным программным специфика-
38
циям. Состав и структура информации реализованной группы
программ контролируется на соответствие спецификаций тре-
бований этой группы. Все реализованные информационные
связи могут быть установлены, упорядочены и обобщены ав-
томатизированно. Сравнение информационного интерфейса
группы программ с исходной спецификацией также может быть
в значительной степени автоматизировано.
Тест проверки выполнения ограничений по использованию
памяти и длительности исполнения группы программ пред-
назначен для выявления ошибок использования группой про-
грамм реальных ресурсов ЭВМ. При этом проверяется исполь-
зование ресурсов в типовых режимах исполнения программ,
в критических режимах максимального количества данных,
а также при различных искажениях входной информации. Вы-
является выход объема используемой памяти за пределы, ус-
тановленные в спецификациях и в описаниях .переменных.
Оценивается вероятность превышения заданных пределов дли-
тельностью обработки данных. Проверки проводятся в основ-
ном стохастические, поэтому большое значение приобретает
автоматизированное формирование' тестов и автоматическая
обработка результатов тестирования.
Тест проверки полноты решения функциональных задач
группой программ служит для завершающего контроля груп-
пы программ и обнаружения ошибок, оставшихся после пре-
дыдущих категорий тестов. Завершается проверка межмодуль-
ного интерфейса внутри группы программ и проверка функ-
ционирования группы во всех заданных режимах. Тестирова-
ние проводится в соответствии со спецификацией требований
на группу программ. Детерминированная часть тестов подго-
тавливается и анализируется в значительной степени вручную,
исполняются тесты автоматически. Стохастическая часть тес-
тирования проводится с использованием имитаторов исходных
данных и программ автоматической обработки результатов
тестирования. Особую роль играют тесты для проверки про-
грамм в особых точках значений параметров и при критиче-
ских сочетаниях условий. Тестирование завершается реги-
страцией полученных результатов и оформляется протоко-
лом тестирования для передачи группы программ на комплек-
сирование.
Тестирование комплексов программ при отладке наиболее
сложный процесс и характеризуется высокой трудоемкостью.
Для этого применяется преимущественно стохастическое тес-
тирование и в реальном масштабе времени с основной целью
установления корректности и надежности функционирования
всего КП. Автоматизация тестирования на этом этапе значи-:
39
тельно отстает от необходимой и требует больших затрат в ос-
новном на имитацию внешней информации и обработку ре-
зультатов. На этом этане завершается проверка корректности
функционирования программ при* правильных исходных, дан-
ных и осуществляются основные проверки при искажениях на
входе. Проверяется надежность функционирования всего КП
. в реальных условиях и эффективность средств программной
защиты и восстановления. Определяется корректность ис-
пользования программами ресурсов вычислительной системы
и функционирования программ в критических условиях. Фор-
мализация процесса тестирования на этом этапе наиболее труд-
: на и оценки полноты тестирования осуществляются преиму-
ицествсцно по степени выполнения функций и по характери-
стикам надежности функционирования КП.
Темп проверки полноты решения функциональных задач
комплексом программ пр и. типовых исходных данных предназна-
। чеп для обнаружения ошибок функционирования в типовых
условиях, определенных техническим заданием на КП. Пер-
I вичным эталоном являются цели .создания КП и соответствую-
щее им формализованное техническое задание, которое яв-
ляется основным эталоном при создании данной категории
тестов. Для систем реального времени'тест содержит, в основ-
ном, динамические и стохастические данные. Эти данные ими-
тируются моделями реальных объектов. Результаты тестиро-
вания обрабатываются и сравниваются'.с эталонами преиму-
щественно автоматически. Некоторая часть теста может со-
держать детерминированные исходные данные, для анализа
которых часто применяются различные системы визуального
отображения. Особое внимание целесообразно обращать на
варианты тестов, позволивших обнаружить ошибки, и на мо-
• дули, в которых ошибки обнаружены. Для этих условий сле-
дует проводить дополнительное тестирование-
Тест проверки функционирования программ в критических
ситуациях по условиям и логике решения задач предназна-
чен для выявления ошибок при исполнении программ, в ситу-
ациях, которые редко реализуются, но важНы для функцио-
нирования системы обработки информации. Для разработки
таких тестов создаются сценарии критических сочетаний зна-
чений параметров и условий решения задач, при которых не-
обходимо проверить функционирование программ и можно ожи-
дать искажения результатов. Такие стрессовые сочетания под- ,
готавливаются вручную или предусматривается их реализа-
ция в составе данных стохастических и динамических тестов.
Особая важность проверки при критических ситуациях опре-
деляется опасностью проявления ошибок при функциониро-
4°	'	• - •
вании КП в реальных условиях. Поэтому при тестировании ак-
тивно применяются имитаторы внешних объектов, автоматиче-
ски подготавливающие исходные данные, и средства контроля,
реагирующие на результаты тестируемых программ.
Тест проверки корректности использования ресурсов па-
мяти и производительности вычислительной системы служит
для обнаружения ошибок исполнения программ при недостат-
ках памяти и производительности. Тестирование производит-
ся в основном в стохастическом режиме В реальном масштабе
времени по подготовленным сценариям, создающим дефицит
одного из ресурсов системы. Обычно наиболее полнотестируют-
ся буферные накопители приема и выдачи информации внеш-
ним абонентам, а также использование массивов в базе данных.
Проверке подлежит изменение качества функционирования
КП вследствие пропусков в обработке сообщений, возраста-
ния длительности ожидания перед их обработкой или растя-
гивания периодов решения задач 1351, Имитаций тестов про-
изводится в основном автоматически по сценариям, создающим
критические условия.Для определенной проверки. В результате
тестирования устанавливаются реальные характеристики КП
на выбранной вычислительной системе по пропускной способ-
ности решения всего комплекса задач й по допустимой интен-
сивности решения отдельных типов задач и обработке различ-
ных сообщений При кратковременных перегрузках памяти
или производительности должна обеспечиваться защита от
отказов и восстановление нормального режима при последую-
щем снижении загрузки.
Тест проверки параллельного исполнения программ исполь- 
зуетбя для обнаружения ошибок, обусловленных несогласо-
ванным использованием исходных и промежуточных данных,
а также устройств вычислительной системы при параллельном
исполнении программ 1181. Тестирование проводится преиму-
щественно стохастичбскге Основная его задача — осуществить
проверку при различных сочетаниях исполнения частей про-
граммы одновременно функционирующими процессорами. Осо-'
беннр важно обнаружить все тупиковые ситуации (клинч),
при которых параллельные программы обращаются к одним и
тем же ресурсам вычислительной системы и не могут продол-
жить . вычисления до их освобождения. Малая вероятность
образований таких ситуаций может приводить к необходи-
мости генерации большогр числа стохастических тестов. Тес-
тирование параллельно исполняемых программ обычно тре-
бует значительного количества исходных данных, содержащих
как случайную, так и детерминированную составляющие.
4it;:.
Такие данные подготавливаются в •основном автоматически по
сценариям наиболее критических сочетаний данных.
Тест проверки эффективности защиты от искажений ис-
ходных данных служит для выявления ошибок в программах,
проявляющихся при ложных или искаженных данных. Тестиро-
вание проводится при относительно небольших искажениях
исходных данных, соответствующих нормированному возра-
станию в них ошибок, а также при случайном полном искаже-
нии данных. Искажения целесообразно измерять по вероят-
ности их появления и другим характеристикам и поддерживать
на уровне, соответствующем ненормально работающим реаль-
ным системам передач и данных. При тестировании выявляются
ситуации нарушения работоспособности КП и снижения каче-
ства его функционирования в зависимости от интенсивности
искажений. Искажения данных производятся в основном сто-
хастически, однако в некоторых случаях могут быть необхо-
димы детерминированные'И коррелированные искажения раз-
личных данных.
. Тест определения надежности комплекса программ пред-
назначен для измерения основных показателей надежности
при реальном функционировании КП. В процессе тестирова-
ния при типовых и критических условиях определяются зна-
чения наработки на отказ, длительности восстановления, ко-
эффициента готовности и других показателей. Для сложных
систем реального времени организуются многочасовые прого-
ны КП при стохастических исходных данных, при которых ре-
гистрируются искажения результатов и выделяются наруше-
ния работоспособности программ. При таком тестировании
особое значение имеет соотношение типовых и критических
условий функционирования и исходных данных. Это соотно-
шение должно устанавливаться в соответствии с техническим
заданием на КП и формализоваться в методике тестирования
по согласованию между разработчиком и заказчиком. Для
КП с высокими показателями надежности могут применяться
форсированные методы тестирования, при которых искусствен-
но повышается интенсивность искажения исходных данных,
вводятся частичные отказы и повышенные уровни сбоев в ап-
паратуре. Значения надежности при форсированных испыта-
ниях затем должны корректно пересчитываться на нормальные
условия эксплуатации (см. § 4.4). Имитация исходных данных
и регистрация отказов может производиться автоматически,
при этом особенно важно обеспечить регистрацию условий на-
рушения работоспособности.
Тест оценки эффективности защиты от сбоев аппаратуры
и невыявленных ошибок программ служит для проверки’каче-
42
ства средств программного контроля и оперативного восста-
новления (рестарта) при различных искажениях функциони-
рования. Стохастическое тестирование средств рестарта про-
изводится в процессе определения показателей надежности
функционирования программ. При этом оцениваются вероят-
ность обнаружения бтказовой ситуации и средняя длитель-
ность восстановления. Специализированный тест оценки эф-
фективности защиты позволяет определить вероятность вы-
явления каждого вида сбоев и соответствующую ему длитель-
ность восстановления нормального функционирования. Для
этого разрабатываются сценарии имитации аппаратных сбо-
ев, искажений исходных данных и программных ошибок, вы-
зывающих срабатывание средств программного контроля и опе-
ративного восстановления. Таким образом обнаруживаются
ошибки программ контроля или программ восстановления, а
также определяются их динамические характеристики. Слож-
ность данного вида тестирования состоит в трудности регла-
ментированного ввода сбоев вычислительных систем и в слож-
ности имитации проявления ошибок в разработанных програм-
мах. Кроме того, вследствие редких событий.отказовых ситу-
аций для Статистических оценок необходимо искусственное по-
вышение интенсивности их возникновения.
Тестирование комплекса программ при испытаниях-пред-
назначено, в основном, для проверки соответствия техниче-
му заданию и для оценки пригодности КП к регулярной экс-
плуатации и сопровождению. Для этого проверяется полнота
и точность технической документации и качество функциони-
Гования программ по всем требованиям технического задания
131. Проверка пригодности к сопровождению включает тести-
рование настройки версий на условия конкретного применения
и анализ удобства модифицирования версий КП. Сложность
тестирования программных изделий может быть значительно
ниже, чем на предыдущем этапе, так как сокращаются объемы
проверок и варьирование условий, в которых они осущест-
вляются. Соответственно снижаются затраты на его выполне-
ние. Проверки должны производиться достаточно формали-
зованно и более четко, чем на предыдущем этапе 1571.
Тест испытаний на соответствие комплекса программ тех-
ническому заданию служит для паспортизации созданного.ком-
плекса как завершенного программного продукта. Тестирова-
ние должно обеспечивать проверку характеристик функцио-
нирования программ по каждому требованию технического за-
дания. Для сокращения объема тёстов разрабатываются ме-
тодики, позволяющие измерять несколько параметров программ
при одном эксперименте тестирования. Для генерации тестов
43
 применяются в основном автоматические имитаторы, характер
ристики которых определяются до начала тестирования. Завер-
шающая стадия испытаний может проводиться на реальной
системе обработки информации и управления в процессе ра-
бочего функционирования. Такие испытания позволяют обна-
руживать ошибки в созданных программах, обусловленные
отличием характеристик иМитаторов от характеристик реаль-
/-' ных источников информации й объектов управления.
Тест проверки удобства эксплуатации и взаимодействия .
человека с комплексом программ предназначен для обнаружения
трудно формализуемых ошибок представления исходных и ре-
зультирующих данных. При тестировании оцениваются объем,
удобство представления и контроля исходных данных, вводн-
мых непосредственно человеком-пользоваталем, а также ото-
бражаемых результирующих данных, удобство их анализа и \
- использования. Кроме того, проверяются динамические ха-
рактеристики ввода и отображения данных в реальном вре-
мени. В сложных автоматизированных системах управления,
• в которых основные данные поступают по телекодовым кана-
лам связи, большое значение имеет тестирование принятия
решений человеком в динамике функционирования системы,
особенно некритических ситуациях. Тестирование позволяет
выявить ошибки распределения между человеком и ЭВМ ав-
томатизируемых функций системы, а также оценить возмож-
ность полного решения задач обслуживающим персоналом си-
стемы. Часть проверок, связанная с оценкой удобства.исполь-
‘ зования документации, может выполняться без вычислитель-
ной системы, путем сравнения целей и действий человека с со-
держанием пользовательской документации. При оценке пси-
хологического удобства эксплуатации КП большое значение
может иметь выбор группы операторов-пользователей. Их
квалификация, критичность и доброжелательность могут силь-
но изменять результаты тестирования.
Тест проверки удобства установки у подготовки рабочей
версии служит для выявления ошибок методов и средств на-
стройки КП к конкретным условиям применения. Многие КП
перед использованием адаптируются к операционной среде или
к конкретным условиям, при которых должны решаться зада-
чи.' Для этого могут автоматизированно подгртавливаться дан-
ные, характеризующие эти условия. Тестирование преследует
цель проверки и обнаружения ошибок средств настройки, а
' также функционирования адаптированных к разным условиям
КП. Для проверки средств адаптации создаются специальные
тесты, охватывающие наиболее типовые режимы использова-
ния КП. Тестирование адаптированных версий может прово- .
44
диться на базе тестов испытаний на соответствие техническо-
му заданию, дорабатываемых по специальной методике адап-.
тации.
Тест проверки работы комплекса программ при конфигура-
циях оборудования используется для обнаружения ошибок,,
проявляющихся при изменении состава или характеристик ком-
понент вычислительной системы иЛи внешних абонентов. Се*
рийно выпускаемые и широко применяемые программы могут
функционировать на вычислительных системах, различающих-
ся составом оборудования' или характеристиками подключае-
мых внешних абонентов. Число возможных конфигураций обо-
рудования может быть слишком велико, чтобы все их протес-
тировать при подготовке программного изделия. Поэтому важ-
ное значение имеет Методика и средства подготовки КП к
различным конфигурациям оборудования. В состав КП вво-
дятся средства, позволяющие адаптировать его к таким изме-
нениям оборудования. Тесты должны обеспечивать проверку
этих средств автоматизированной адаптации во всех допусти-,
мых комплектациях оборудования, а также тестирование адап-
тированных версий. Для этого разрабатывается методика под-
готовки тестов проверки адаптированной версии, которая ис-
пользуется настройщиком версии.
Тест проверки корректности документации предназна-
чен для обнаружения ошибок соответствия реального КП всей
сопровождающей его конструкторской и эксплуатационной до-.,
кументации. Большая часть тестирования КП проводится с
использованием конструкторской И эксплуатационной доку-
ментации, что позволяет в значительной степени проверить ее
корректность. Поэтому данная категория тестов является за-
вершающей и предназначена дЛя регистраций качества доку-
ментации. Корректность конструкторской документации на
программные изделия проверяется сопоставлением кодов про-
грамм в документах и в вычислительной системе или Сопостав-
лением контрольных сумм по некоторым частям программ.
Наиболее полно в документации проверяются контрольные
примеры, входящие ц инструкции по эксплуатации. Для про-
верки корректности эксплуатационной документации выпол-
няются процедуры, предписанные инструкциями, при заранее
подготовленных типовых исходных данных и.рассчитанных ре-
зультатах. Функционирование КП при воздействиях, вводи-
мых в соответствии с документацией, позволяет проверить:
корректность документов и адекватность им реальной версии,
программ. Кроме того, осуществляется проверка соответствия-'
документации стандартам .на проектирование и оформление,
программ. Соблюдение стандартов позволяет повышать каче-
ство программ и только тестированием документации можно
установить степень соблюдения стандартов.
Тест проверки удобства сопровождения и модификации про-
грамм должен обеспечивать выявление ошибок построения
КП и его компонент, затрудняющих их изменение в процессе
сопровождения. Удобство сопровождения закладывается при
системном и структурном проектировании программ путем со-
здания модульно-иерархической структуры на всех уровнях
иерархии программ и данных. Основная цель таких структур
состоит в возможности замены или изменения отдельных ком-
понент программы без необходимости внесения изменений в
другие компоненты. Удобство сопровождения и модификации
КП первоначально оценивается при просмотре документации
без использования ЭВМ. Целесообразно поставить несколько
экспериментов по возможной модификации и оценить, насколь-
ко они хорошо локализуются. Основное тестирование удоб-
ства сопровождения проводится при реальном развитии КП.
При этом наиболее крупные ошибки структурного построения
И организации комплекса или отдельных групп программ*
могут привести к необходимости повторного проектирования
этих компонент.
Тестирование КП при сопровождении осуществляется с ис-
пользованием практически всех перечисленных выше катего-
рий тестов, характерных для разработки и испытаний КП
(штриховые линии на рис. 1.4). С этой позиции сопровождение
является повторением процесса создания программ или его
отдельных этапов. Однако при сопровождении редко применя-
ется вся совокупность систематизированных категорий тес-
тов. Обычно в зависимости от конкретных задач сопровождения
и характеристик, проведенных в программах изменений, ис,
пользуется минимум категорий тестов, позволяющих осущест-
вить проверки выполненных корректировок. Выбор катего-
рий тестов трудно систематизировать в общем виде и может
варьироваться в очень широких пределах в зависимости от со-
держания вносимых изменений. При сопровождении активно
применяются специфические категории тестов, связанные с
обеспечением сохранности данных на магнитных носителях.
Такие тесты используются также в процессе разработки, но
при сопровождении значительно возрастает их роль (см. гл.5).
Перечисленные выше 22 категории тестов являются основ-
ными для КП реального времени, однако их применение за-
висит от класса разрабатываемых программ. Организация и
эффективное проведение такого обширного систематического
тестирования требуют больших затрат и высокой квалифика-
ции специалистов. Систематизация категорий тестов позволя
'46
ет последовательно акцентрировать вниманме-на обнаружении
ошибок определенных классов. Благодаря этому менее вероят-
но пропустить некоторую группу . ошибок, проявляющуюся
только при определенных условиях функционирования. Упо-
рядоченное применение категорий тестов позволяет эффектив-
но использовать ограниченные ресурсы тестирования. Полные
затраты на все тесты оправданы и необходимы, когда КП вы-
полняет особенно ответственные функций и его недостаточное
качество грозит большим ущербом или катастрофами.
Имеются рекомендации [13, 14, 451 по созданию коллекти-
вов для выполнения систематического тестирования, незави-
симых от коллективов, осуществивших разработку программ.
Однако практически реализовать эти рекомендации трудно
прежде всего из-за отсутствия специалистов, которые в об-
ласти тестируемых программ должны иметь квалификацию не
ниже, чем их разработчики. Поэтому для тестирования КП
на завершающих стадиях обычно создаются комиссии, со-
стоящие из представителей разработчиков, заказчиков, потен-
циальных пользователей и специалистов по тестированию.
Основные функции по выполнению тестирования в таких ко-
миссиях осуществляют разработчики программ. Остальные
специалисты в основном играют роль оппонентов и контроле-
ров полноты и корректности выполненного тестирования.
Подготовка средств автоматической генерации тестов и обра-
ботки результатов тестирования чаще всего осуществляется
специализированным коллективом.
ГЛАВА 2
ОСНОВНЫЕ ПОКАЗАТЕЛИ ПРОЦЕССА ТЕСТИРОВАНИЯ
ПРОГРАММ
2.1.	КРИТЕРИИ КАЧЕСТВА ТЕСТИРОВАНИЯ ПРОГРАММ
Критерии качества программ. Следует разделять понятия
критериев качества программ, которые тестируются, и крите-
1 риев качества процессов и методов тестирования. Последние
характеризуют степень достижения целей тестирования с уче-
г том затрат, которые необходимы для этого. Критерии каче- '
ства программ в общем случае являются показателями, поз-
воляющими количественно оценивать важнейшие свойства;
программ в жизненном цикле, независимо от того, как про-
| изводилось их тестирование. Изменение доминирующей цели,
в зависимости от этапов жизненного цикла программ приводит
47
• к изменению состава основных критериев качеств^ программ
и степени их важности при анализе.
На смену интуитивным оценкам качества программ посте-
пенно приходят измерения, контроль показателей ц управле-
ние качеством программного обеспечения 111, 17, 37, 441.
Управление качеством программ предполагает формализацию
технологии проектирования и выделение в специальный про-
цесс измерение, контроль и анализ качества программ:
•анализ системных требований к КП и ранжирование пока-
- зателей качества с выделением обязательных и желательных
значений характеристик;
. разработку методик и стандартов контроля выполнения
технологии структурного, модульно-иерархического проекти-
рования КП-и его компонент;
| создание методов и средств объективного измерения ка-
чества. а также технологии поэтапного контроля степени вы-
полнения заданных требований к качеству;
создание или выбор средств инструментальной технологи-
ческой поддержки автоматизации программирования, тестиро-
, вания, отладки и испытаний, обеспечивающих создание КП
с заданными показателями качества;
организацию коллектива специалистов и процесса проек-
тирования с целевой задачей максимального удовлетворения
требований заказчика к качеству программ.
Разнообразие возможных критериев и факторов, от кото-
рых зависит качество программ на различных этапах, усЛож-
j няет их практическое использование. Поэтому целесообразно
провести классификацию критериев, выделить функциональ-
ные и конструктивные критерии .качества программ и упоря-
дочить их по этапам жизненного цикла.
Функциональные критерии отражают специфику областей
применения и степень соответствия программ их основному
целевому назначению. Для программ управления в них входят
показатели точности, диапазоны изменения параметров, вре-
мя реакции, адаптивность к внешним воздействиям н т. д.
• В системах обработки информации функциональные показатё-
тёли отражают номенклатуру, исходных данных, достоверность
. результатов, разнообразие функций редактирования и др.
Конструктивные критерии (табл. 2.1) более инвариантны
к целевому назначению и основным функциям КП. К ним от-
носятся; сложностть программ, надежность функционирова-
ния, степень использования ресурсов ЭВМ, корректность и т. д.
Некоторые конструктивные показатели для определенных КП
могут быть важны с позиции их прямого функционального
назначения (например, надежность), .однако они выделены и
Таблица 21 Конструктивные критерии качества по этапам жизненного цикла программ
49
далее рассматриваются в группе общесистемных конструктив-
ных показателей. В табл. 2.1 выделены критерии и факторы,
определяющие качество программ, которые целесообразно
анализировать как наиболее важные при оценке тестирова-
ния 1371.
Процесс тестирования невозможно характеризовать од-
'ним универсальным удобно измеряемым критерием качества.
В зависимости от этапов тестирования, функционального на-
значения и характеристик тестируемых программ использует-
ся система показателей, с различных сторон характеризующих
процесс и результаты тестирования. Среди приведенных кри-
териев качества программ ряд показателей не зависит от про-
цесса тестирования и его эффективности (например, структур-
ная упорядоченность или документированность программ),
а некоторые (например, сложность программ или эффектив-
ность использования. ресурсов ЭВМ) зависят в Относительно
небольшой степени. В Наибольшей степени процесс тестиро-
вания влияет на корректность и надежность программных ком-
плексов. Основной целью тестирования прежде всего являет-
ся обнаружение ошибок, нарушающих корректность функцио-
нирования программ и получаемых результатов. Поэтому кри-
терии качества тестирования тесно связаны со степенью до-
стижения основной цели тестирования — получения коррект-
ных и надежных программ (табл. 2.2).
Таблица 2.2. Критерии качества тестирования программ
и их составляющие
Общие критерии качества тестирова иия программ	Измеряемые интегральные показатели качества тестироваиия	Частные конструктивные критерии качества
Корректность	Детерминированная кор- ректность Стахастическая коррект- ность Корректность в реаль- ном масштабе времени	Корректность структу- ры программ Корректность обработ- ки данных Корректность межмо- дульных связей
Надежность	Наработка на отказ Длительность восстанов- ления Коэффициент готовно- сти	Интенсивность обнару- жения ошибок в про- грамме Наработка на отказо- вую ситуацию
Эффективность тестирования завйсит от того, при каких
затратах достигается заданная относительная корректность
или надежность программ. Допустимые затраты всегда огра-
50
ничены, вследствие чего оказывается ограниченной достигае-
мая корректность и надежность программ. Важная задача со-
стоит в построении стратегий тестирования, обеспечивающих
достижение максимальной корректности или максимальной
надежности [36] тестируемых программ в условиях ограничен-
ных ресурсов, которые могут быть выделены на его проведе-
ние.
Понятие относительной корректности, или правиль-
ности всегда подразумевает степень соответствия проверяе-
мого объекта некоторому эталонному объекту или системе фор-
мализованных эталонных характеристик и правил. Особен-,
ность понятия корректности программ в том, что для программ
в процессе проектирования не существует точной эталонной
программы-прототипа, с которой можно сравнивать коррект-
ность вновь создаваемых программ. Корректность программ в
основном определяется степенью соответствия программы
предъявляемым к ней формализованным требованиям — про-
граммным спецификациям [13* 58]. При отсутствии полностью
формализованной спецификаций в качестве эталона, которо-
му должна соответствовать программа и результаты ее функ-
ционирования, иногда используются неформализованные пред-
ставления 'разработчика, пользователя или заказчика про-
грамм- Трудности полной и точной формализации программных
спецификаций все гдаприводят к некоторой неопределенности,
которая уменьшается в процессе разработки программ при.
уточнении спецификаций по согласованию между разработчи-
ком и заказчиком.,;
Корректность КП можно оценивать по функциональным и
конструктивным критериям. Функциональные критерии яв-
ляются специфическими для каждого КП и определяются его
назначением и областью применения. Конструктивные крите-
рии корректности практически не зависят от конкретного на-
значения программ и характеризуют более общие свойства
программ. Эти критерии охватывают правила применения язы-
ка программирования, правила структурного построения мо-
дулей и групп программ, а также ряд других общих свойств
программ.
Важнейшим общим критерием качества функционирова-
ния КП, анализируемым в процессе тестирования, является
надежность. Понятие надежности программ и пути ее
определения базируются на основных понятиях общей тео-
рии надежности. Отказ может проявляться в виде программного
останова или зацикливания, систематического пропуска
исполнения некоторой группы программ, значительного од-
нократного или систематического искажения накопленных
51
(хранимых) данных и т. д. Во всех случаях программные отка-
зы приводят к прекращению выдачи абонентам информации
и управляющих воздействий, а также, возможно, к значи-
тельному искажению ее содержания и темпа выдачи, соот-
ветствующим нарушению работоспособности. КП.
Следует подчеркнуть отсутствие тождественности между
критериями и понятиями корректной и надеж-
ной программ. Правильная (корректная) программа
должна обеспечивать выходные данные, соответствующие эта-
лонным, в области изменения исходных данных, заданных фор-
мализованными требованиями технического задания или спе-
цификации. Степень корректности программы можно характе-
ризовать вероятностью искажения результатов при попадании
в область исходных-данных, которая предусматривалась тре-
бованиями спецификации,'однако не была проверена при тес-
тировании и испытаниях.	х
Надежная программа прежде всего должна обеспечивать ма-
лую вероятность отказа в процессе реального функциониро-
вания. Быстрое реагирование на искажения'программ, дан-
ных или вычислительного процесса и восстановление работо-
способности за время, меньшее, чем заданный порог между
сбоем и отказом, позволяют получить высокую надежность
программ. При этом некорректная программа может функцио-
нировать, в принципе, абсолютно надежно. Если каждое по-
явление реальных исходных данных, стимулирующих непра-
вильные результаты, не приводит к событиям, соответствую-
щим отказу, то такая программа функционирует надежно,
хотя и не всегда правильно.
. Конкретизация содержания критериев приводит к ряду
частных показателей (табл. 2.2), характеризующих специфиче-
ские особенности процесса, средств и объектов тестирования
программ. Эти частные, показатели могут конструктивно ис-
пользоваться при проектировании программ и способствуют
достижению высоких показателей качества тестирования в це-
лом.
Корректность программ. Степень корректности программ,-
полученных в результате тестирования, оценивается косвен-
но по ряду интегральных измеряемых показателей качества >
программных компонент.
Корректность программных модулей включает функцио-'
нальную и конструктивную корректность. Конструктивная
корректность модулей заключается в соответствий их струк-
туры Общим правилам структурного программирования 121,
24, 611 и конкретным правилам оформления и внутреннего
построения программных модулей в этом комплексе. Функ-
62	- '
циональная корректность модулей определяется корректно-
стью обработки исходный данных и получения результатов.
В зависимости от функциональных задач корректность модуля
может оцениваться детерминированно, по полностью опреде-
ленным наборам эталонных значений, или стохастически, при
задании эталонов распределениями случайных величин.
Корректность обработки данных также имеет функцио-
нальную и конструктивную составляющие. Конструктивная
корректность обработки данных определяется правилами их
структурирования и упорядочении (см. § 1.1). Эти правила
могут быть достаточно полно формализованы без учета кон-
кретных особенностей функционирования программ. Назна-
чение и область применения программ определяют выбор ис-
пользуемых структур данных и конкретных дисиплин их упо-
рядочения. Функциональная корректность обработки данных
связана в основном с конкретизацией их содержания в про-
цессе исполнения программ, а также прн подготовке данных
внешними абонентами.	-
Корректность групп tt комплексов программ является пре-
имущественно функциональной. Конструктивная коррект-
ность определяется правилами структурного, модульного по-
строения КП и общими правилами организации межмодульных
связей. Эта составляющая корректности в значительной сте-
пени может быть проверена формализованными автоматизи-
рованными методами. Функциональная корректность КП наи-
более трудно формализуется из-за большого количества воз-
можных эталонных значений и распределений.
Детерминированная корректность программ определяет-
ся по частости отклонения конкретных вычисляемых значений •
от эталонных значений, заданных в техническом задании, или
в иных исходных документах. Точность опенки детерминиро-
ванной корректности зависит от представительности тестовых
наборов, широты варьирования переменных, точности срав-
нения результатов тестирования и т. д.
Стохастическая корректность характеризуется величиной •
статистического отклонения распределений и их парамет-
ров (средних значений, среднеквадратических отклонений) от
заданных в качестве эталонов. При этом не оценивается каж-
дый результат тестирования, а они обобщаются и оценивают-
ся интегрально по некоторой достаточно представительной
выборке. Точность определения стохастической корректности
зависит от статистической корректности наборов эталонных
тестовых данных, от объема статистики, от точности оценки
параметров, распределений исходных данных и результатов
и т. д.
53
В результате малые отклонения результатов в процессе
тестирования могут не нарушать стохастическую’ коррект-
ность, если интегральные отклонения выходных данных полу-
чаются в пределах заданных допусков.
Корректность в реальном масштабе времени определяет-
ся величиной максимального или усредненного отклонения
траектории выходных параметров отгаданной эталонной тра-
ектории обработки тестовых исходных данных. Результаты тес-
тирования оцениваются интегрально . на некотором временном
интервале или по наибольшему отклонению от эталонной тра-
ектории. Таким- образом, корректность во времени является
преимущественно стохастической, однако в некоторых слу-
чаях рассматривается детерминированная динамика'обработ-
ки тестовых данных.
Приведенные виды корректности используются, в основ-
ном, для интегральной оценки результатов тестирования раз-
работанных КП. В процессе проектирования модулей и групп
программ применяются частные конструктивные критерии
корректности тестирования создаваемых компонент, которые
включают корректность структуры программ, обработки дан-
ных и межмодульных связей (см. табл. 2.2). Каждый из част-
ных критериев может характеризоваться несколькими метода-
ми измерений качества тестирования и достигаемой степени
корректности программ.
Корректность структуры программ определяется кор-
ректностью структуры модулей и корректностью структуры
групп программ, построенных из модулей. Для оценки кор-
ректности структуры программ используется несколько ча-
стных показателей, различающихся степенью охвата тестами
структурных компонент программы при тестировании. Про-
верка корректности структурных компонент производится ста-
тически по исходным текстам программ или динамически при
исполнении программы в объектном коде. При обоих методах
по мере углубления критериев тестовых проверок возрастает
объем и сложность тестов, а следовательно, и достигаемая
степень корректности программ. Наиболее часто для тести-
рования структуры программных модулей используются три
критерия выделения тестируемых маршрутов 145, 40].
Первый простейший критерий выделения
тестируемых маршрутов (рис, 2.1) состоит в выборе минималь-
ного множества маршрутов программ, охватывающих все на-
правления передач управления (ветвления при условных пере-
ходах и переключателях). По критерию %, граф программы
по управлению должен быть покрыт минимальным набором
путей, проходящих через каждый оператор ветвления по каж-
54
дой дуге. Повторная проверка дуг не оценивается н считается
избыточной. При этом в процессе проверки гарантируется вы-
полнение всех передач управления между операторами про-
граммы и каждого оператора не менее одного раза. Однако
минимальное число маршрутов по этому критерию не обеспе-
чивает исполнение каждого оператора при различных сочета-
ниях предшествующих условий и последовательностей опера-
торов, образующих весь набор маршрутов,, проходящих через
данное ветвление передачи управления.
Второй критерий выбора маршрутов Хг Для
тестирования структуры программных модулей заключается
в анализе базовых маршрутов в программе, формируемых и
оцениваемых на основе определения цикломатического числа
исходного графа проверяемой программы [8]. Критерий Ха
наиболее широко применяется для оценки сложности и кор-
ректности тестирования программных модулей и наиболее
Рнс. 2.1. Пример графа программы, маршрутов, выделенных по трем
критериям, и показателей сложности тестирования
<55
полно исследован при анализе- корреляции сложности ,и тру» :
доемкости тестирования программ. Для определенияликлома-
тического числа. Z исходного графа программы используется
полное число его вершин пп, связывающих их дуг Y и связ-
ных компонент L'
Z ® У — лп г L.
Вычисление цикломатического числа осуществляется по
величинам, определяемым по максимально связному графу,
который получается из исходного графа замыканием дуги из
конечной вершины в'начальную В результате в максимально
связном-графе появляются маршруты между любыми двумя
вершинами. Приетом предполагается, что исходный граф цор-
^ректен, т е. не содержит высячих и тупиковых вершин. В мак-
симально связном графе, цикломатическое число равно макси- .
мальному числу его линейно-независимых циклов [86|. Каж-
дый цикл отображается в виде одного элементарного (одно-
кратного) никла. Величина L соответствует количеству связ-
ных компонент всего исходного графа, и обычно для графов, не
содержащих полностью независимых частей L = 1. Иначе
говоря, L измеряется количеством замыкающих дуг, необ-
ходимых для преобразования исходного графа в .максималь-
ный сильно связный граф.
Таким образом, критерий Хз учитывает каждый линей-
но-независимый цикл в максимально связном графе програм-
мы. Каждый, линейно-независимый маршрут или цикл отли-
чается от всех остальных хотя бы одной вершиной или дугой,
т. е. его структура не может быть полностью образована-ком-
понентами других маршрутов.
Стремление к увеличению глубины проверок приводит к
третьему критерию %з выделения полного соста-.
ва базовых структур графа программы Он заключается в ана-
лизе хотя бы один раз каждого из реальных ациклических
маршрутов исходного графа программы и каждого цикла, до-
стижимого из всех маршрутов. В результате исходный гфаф
программы представляется полным множеством базовых струк-
тур, каждая из которых образуется очередным ациклическим
, маршрутом -и одним или несколькими циклическими маршру-
тами, так что в совокупности должны быть охвачены все цик-
лы, достижимые из данного ациклического'маршрута Еслй
из некоторого ациклического марштута исходного графа до- .
стижимы несколько элементарных циклов, то при тестирова- .
нии должны исполняться все достижимые циклы
Различие приведенных критериев достаточно - наглядно
можно представить на простейшем ациклическом графе, со-
56-
держащем три вершины ветвления (рис. 2.1). В таком графе
по критерию минимального покрытия выделяется всего
• три маршрута. Линейно-независимыми (критерий у2) являют-
ся четыре маршрута, и циКломатическое число равно 4. Пол-
ное число сочетаний всех дуг (критерий %3) позволяет выде-
лить шесть маршрутов. Суммарное число условий, котррое не-
обходимо для покрытия выделенных маршрутов и должно быть
задано в тестах (сложность тестов), при этих критериях соот-
ветственно равно 8, 11 и 16. В зависимости от сложности вы- .
числений иа дугах и ресурсах тестирования выбирается целе-
сообразный критерий выделения маршрутов. Однако даже при
весьма сложной взаимосвязи результатов, получаемых на
дугах графа, редко возникает необходимость применения кри-
терия х3. Поэтому ниже анализ проводится преимущественно
при критериях выделения маршрутов Xi и %2.
В реальных программах некоторые маршруты могут ока-
заться нереализуемыми ,из-за’несовместимости условий, ко-
торые последовательно анализируются в разных вершинах.
Это обстоятельство приводит в некоторых случаях к значи-
тельному сокращению числа тестируемых маршрутов и слож-
ности тестов. Поэтому необходимы методы и средства селекции
нереализуемых маршрутов для более точной оценки затрат на
тестирование. Однако для каждого реализуемого маршрута
может быть необходимой проверка при нескольких прохоже-
ниях циклов и нескольких значениях каждой обрабатывае-
мой переменной. Особенно важнд проверять циклы с услов-
ным выходом на одиом-двух, а также на максимальном и ми-
нимальном числах исполнения циклов. В результате показа-
тель сложности, число необходимых тестов и длительность
тестирования соответственно возрастают.
Корректность обработки данных определяется степенью
тестирования процесса обработки представительной выборки
значений переменных в диапазонах их изменения. Для слож-
ных программ принципиально невозможно провести исчерпы-
вающее тестирование при всех значениях переменных, которые
могут появиться при реальном функционировании программ
Поэтому так же, как при тестировании структуры программы,
устанавливается иерархия критериев и соответствующих им
корректностей обработки данных в программе. Выбор крите-
рия зависит от ответственности задач, решаемых программой,
и от ресурсов, которые могут быть выделены на тестирование.
При тестировании программ можно выделить следующие уров-
ни корректности обработки данных;
корректность символической обработки данных в исход-
ном тексте программы;
57
корректность использования в программе каждой перемен-
ной в соответствии с ее именем и описанием;
корректность обработки совокупности коррелированных
переменных во всем диапазоне их изменения;
корректность обработки массивов переменных.
Наиболее просто достигается корректность символи-
ческой обработки данных в соответствии с их опи-
саниями, используемыми в исходном тексте программы
(см. § 3.4). Однако это не гарантирует корректности обработки
данных при исполнении программы в объектном коде.
При тестировании транслированной программы прежде
всего проверяется корректность использования в
программе каждой переменной при кон-
кретных значениях в соответствии с ее именем и описанием.
Первоначальные проверки проводятся при отдельных наибо-
лее типовых значениях. После этого следует упорядоченный
перебор значений переменных для установления корректности
во всем диапазоне их изменений.
Квазинепрерывные переменные, являющиеся квантован-
ными результатами измерения непрерывных физических вели-
чин с ограниченными производными, имеют интервальные об-
ласти определения и могут выбираться для тестирования при,
нескольких наиболее характерных значениях. Наличие глад-
кой1 связи между последовательными значениями таких пере-
менных исключает необходимость полного перебора их зна-
чений и огромного объема тестирования. После установления
корректности программ при некоторых значениях квазинепре-
рывных переменных можно считать с высокой достоверностью,
что корректность программы гарантируется в некоторой ок-
рестности использованных значений.
Далее для‘каждой из переменных выявляются особые точ-
ки (переход через нуль, сравнение по значению с другой пере-
менной и т. д.) и для оценки корректности тестирования обра-
ботки данных в качестве частных используются критерии,
характеризующие степень покрытия тестами особых точек
изменения переменных и сочетаний значений переменных,
имеющих особые свойства. В результате в план тестирования
включаются не менее трех (обычно 5— 10) значений каждой
простой переменной, начиная с наиболее типовых, средних
или чаще встречающихся значений, и все особые точки. Крите-
рием качества тестирования может служить отношение числа
проверенных значений переменных к числу выбранных зна-
чений. Последнее обычно составляет менее 1 % от полного
возможного, числа значений каждой простой квазинепрерыв-
ной. переменной.
58
Кроме допустимых значений области определения перемен-
ной, тестирование программ должно предусматривать провер-
ку при непредусмотренных и запрещенных значениях. При
искаженных входных Данных, находящися вне их области
определения, должна быть обеспечена защита программы от
отказовых ситуаций при обработке.
Для кодовых, булевских и символьных переменных, имею-
щих области определения в виде дискретных точек, тестиро-
вание обычно предусматривает практически полный перебор
всех возможных значений. В качестве первоначальных при-
нимаются наиболее типичные или чаще всего испол'ьзуемые
значения величин. Упорядочение значений переменных поз-
воляет построить тестирование с одновременным контролем
достигнутой степени корректности проверяемой программы.
Частным критерием качества тестирования может служить
относительное число выполненных тестов ко всему числу воз-
можных комбинаций значений каждой переменной.
Некоторая переменная может быть функционально связа-
на с другой переменной.иа входе программы. Возникает необ-
ходимость установить корректность обработки сово-
купности коррелированных переменных. В
этом случае тесты должны охватывать совокупность коррели-
рованных значений в краевых и ряде промежуточных точек
их областей определения. Это может приводить к резкому воз-
растанию объема тестирования. Для сохранения тестирования
обработки данных в допустимых пределах выделяется минимум
наиболее характерных коррелированных значений данных.
Кроме того, для проверки защищенности программ целесо-
образно тестирование на значениях переменных, при которых
функциональная связь между Ними искажена.
Многие вычислительные программы имеют переменные в
виде вектора или массива. Компоненты такой переменной об-
ладают более сложными свойствами, чем простые переменные
162, 85, 901, и должна быть обеспечена корректность обра-
ботки массивов перемени ы'х различной
структуры. Тесты должны охватывать полное множество допу-
стимых значений размерностей массивов в заданной области
определения переменных, которые их составляют. Допустимое
множество целых чисел, характеризующих размер массива,
обычно задается как интервал целых чисел. В принципе для
каждого значения в этом интервале необходимо сформиро-
вать тестовые значения переменной. Однако если элементы
массива имеют значения, располагающиеся в одном интервале
единой области определения, то тесты можно ограничить зна-
чениями краевых точек массива и несколькими точками внутри
59
массива. Для обеспечения корректности программ необходимо
применять в тестах особые значения элементов: например, все
элементы массива имеют одинаковые произвольные или нуле-
вые значения, элементы массива имеют резко различающиеся
предельные значения, все элементы имеют экстремальные Зна-
чения й т. д. Каждое особое значение размерности массива сле-
дует комбинировать с каждым ИЗ специальных множеств зна-
чений его элементов.
При наличии в программном модуле нескольких входных
и выходных переменных, образующих массивы, тестирование
при комбинациях всех выделяемых специальных значений пере-
менных и размеров массива угрожает резким возрастанием
числа тестов. В этих случаях целесообразно оценивать полную
представительную выборку комбинаций тестовых переменных,
учитывающую допустимый объем и сроки проведения тести-
- рова'ния. Ранжирование и последующая селекция выделенных
значений входных и выходных переменных с учетом реальных
ограничений ресурсов на тестирование позволяет построить
эффективные и реализуемые планы тестирования. Сопостав-
лением числа проверенных тестов с полным числом рацио-
нальных тестов, учитывающих все специальные значения пере-
менных, можно оценить достигнутую корректность програм-
мы в результате тестирования.
Корректность межмодульных связей. Взаимодействие про-
грамм определяется двумя видами связей между модулями:
по управлению и по информации. Связи по управлению со-
ставляют вызовы программных модулей и возвраты в вызывав-
шие. Каждая связь модуля по управлению может содержать
ошибку и причиной одного из видов некорректностей:
отсутствие вызова необходимого взаимодействующего
модуля; .
вызов модуля, не подлежащего исполнению при вызове;
возврат управления от вызванного модуля к модулю, ие
• осуществляющему вызов;
, возврат управления от вызванного к.вызывающему моду- •
лю в точку,, не предназначенную для возврата управления.
' Первичным эталоном для выявления некорректностей вза-
- имодействия модулей обычно служит структурная схема груп-
пы программ, составляемая по спецификациям вручную.
Данные паспортов программных модулей (571 позволяют по-
строить реализующуюся схему взаимодействия группы про-,
грамм. Эта схема сравнивается с первичным эталоном. Ошибки
взаимодействия модулей по управлению в КП приводят к про-
пуску выполнения отдельных функций или к их‘значитель-
ным искажениям. Такие некорректности сильно влияют на
60
результаты функционирования КП и полностью должны быть
устранены. Поэтому корректность взаимодействия модулей
пр управлению анализируется детерминирование и почти не
применимы статистические оценки степени корректности.
Взаимодействие модулей по информации может происходить
через обменные переменные, непосредственно подготав-
ливаемые и используемые соседними модулями, или через
глобальные переменные (см. рис. 1.1). Связи каждого мо-
дуля Через глобальные переменные могут осуществляться с
большим числом модулей, каждый из которых может рассчи-
тывать или использовать некоторую переменную и вызывать-
ся даже вне группы программ, включающей рассматривае-
мый модуль. Такой характер связей затрудняет наглядное
представление схемы взаимодействия модулей по информации
в группе программ и приходится анализировать корректность
информационных связей последовательно каждого модуля.
При нтом могут обнаруживаться некорректности следующих
видов:	'	'	’
содержание используемой .переменной не соответствует ее
имени и описанию;
конкретное содержание переменной искажено при подго-
товке или хранении;
подготавливаемая переменная частично искажена в име-
ни, описании или адресе хранения;
рассчитанное значение переменной содержит ошибку.
Некорректности взаимодействия модулей по информации
очень разнообразны, трудно контролируемы и носят стохасти-
ческий характер. Ряд искажений переменных при взаимодейст-
вии модулей не вызывает отказовых ситуаций и отражается
только в искажении результирующих данных на выходе моду-
ля. Если дополнительные ошибки в выходных данных, пере-
даваемых внешним абонентам, относительно невелики, то не-
корректности информационного взаимодействия могут оста-
ваться необнаруженными длительное время. Многообразие
и сложность информационных связей в больших КП значи-
тельно затрудняют формализацию достигнутой корректности
программ и эффективности процесса тестирования. Критерии
становятся стохастическими и Качество тестирования оцени-
вается интегрально по результатам общего функционирования.
ф Трудности оценки объема тестирования, д .о с т а т о ч-
и о г о для установления корректности программ, быстро воз-
растают по мере усложнения КП. Для подтверждения абсо-
лютной корректности программ достаточным в пределе явля-
ется полный перебор всех входных и выходных тестовых зна-
чений переменных во всех их сочетаниях, что представляет
61
00
только теоретический интерес. Такой подход практически реа-
лизуем только для структурно очень простых программ неболь-
шого объема при малых диапазонах изменения исходных дан-
ных. Однако такой перебор становится практически невозмож-
ным при наличии на входе программ даже трех переменных.,
содержащих по 10 двоичных разрядов. При этом полное число
тестовых значений достигает 10*. Значительные трудности
встречаются при анализе достаточности тестирования про-
граммных модулей объемом 200—500 команд и практически
невозможно формализованно определить качество тестирова-
ния КП объемом в десятки тысяч команд.
Достаточный объем тестирования реально никогда не оце-
нивается и процессы тестирования строятся с позиции необ-
ходимого минимума тестов, обеспечивающих коррект-
ность в предполагаемых наиболее активных режимах эксплу-
атации программ. Такой подход является конструктивным и
реализуемым, позволяет сохранять затраты на тестирование в
разумных пределах. Однако представительность выборки не-
обходимого минимума тестов остается во многих случаях су-
бъективной и не оценивается. Для сложных КП объем доста-
точного тестирования может на несколько порядков превы-
шать необходимое тестирование. Тем не менее накопленный
опыт позволяет планировать необходимый минимум тестиро-
вания и создавать различные КП с удовлетворительной кор-
ректностью.
Надежность программ. Оценка качества тестирования по по-
казателям надежности программ является более обобщенной
чем по показателям корректности. В этом случае регистри-
руются только такие искажения в процессе динамического тес-
тирования с исполнением программ, которые приводят к потере
работоспособности КП или их крупных компонент. В теории
надежности работоспособным называется такое состояние
объекта, при котором он способен выполнять заданные функ-
ции с параметрами, установленными требованиями, техниче-
ской документации. Надежность является внутренним свой-
ством систем, проявляющимся только во времени. Критерии
'качества тестирования становятся динамическими и преиму-
щественно стохастическими, характеризующими функциони-
рование КП в целом или крупных групп программ. Измеряе-
мые интегральные показатели качества тестирования в этом
случае более определенные и могут достаточно точно оцени-,
ваться. экспериментально (см. табл. 2.2).
Первопричиной нарушения работоспособности программ
при безотказности аппаратуры всегда является конфликт меж-
ду реальными исходными данными, подлежащими обработке,
62'
и программой, осуществляющей Эту обработку. Работоспособ-
ность КП можно гарантировать при исходных .данных, кото-
рые использовались при тестировании и испытаниях. Реаль-
ные исходные данные могут иметь значения, отличающиеся
от заданных техническим заданием и от проверенных при тес-
тировании программ. При таких исходных данных функцио-
нирование программ трудно предсказать заранее и весьма
вероятны различные аномалии, завершающиеся отказами.
Основным принципом классификации сбоев и отка-
зе в в программах является разделение по временному пока-
зателю длительности восстановления после любого искажения
программ, данных или вычислительного процесса, регистри-
руемого как нарушение работоспособности 136]. При длитель-
ности восстановления, меньшей заданного порога /д, аномалии
при функционировании программ следует относить к сбоям,
а при восстановлении, превышающем по длительности поро-
говое значение /д, происходящие искажения соответствуют от-
казу.
Классификация программных сбоев и отказов по длитель-
ности восстановления приводит к необходимости анализа ди-
намических характеристик абонентов, являющихся потребите-
лями данных, обработанных исследуемым КП, а также вре-
менных характеристик функционирования программ. Времен-
ная зона перерыва нормальной выдачи информации и потери
работоспособности, которую следует рассматривать как зону
сбоя, тем шире, чем более инертный объект находится под воз-
действием сообщений, подготовленных данным КП. Пороговое
время восстановления работоспособного состояния системы,
при превышении которого следует фиксировать отказ, близко
к периоду решения задач для подготовки информации соот-.
детствующему абоненту.
Наиболее широко используется критерий длительно-
сти наработки на отказ [321. Для определения
этой величины измеряется время работоспособного состояния
системы между последовательными отказами или начала функ-
ционирования системы. Вероятностные характеристики этой
величины в нескольких формах используются как разновид-
ности критериев надежности. Критерии надежности восстанав-
ливаемых систем учитывают возможность многократных от-
казов и восстановлений. Для оценки надежности таких систем,
которыми чаще всего являются сложные КП, кроме вероятност-
ных характеристик наработки на отказ, важную роль играют
характеристики функционирования после отказа в процессе
восстановления. Основным показателем процесса восстановле-
ния является длительность восстановления
63
и ее вероятностные характеристики. Этот критерий учитывает
возможность многократных отказов и восстановлений.
Обобщение характеристик отказов и восстановлений про-
изводится в критерии коэффициент готовности.
Этот показатель отражает вероятность иметь восстанавливае-
мую систему в работоспособном состоянии в произвольный мо-
мент времени. Значение коэффициента готовности соответствует
доле времени полезной работы системы на достаточно большом
интервале, содержащем отказы и восстановления.
Применение основных понятий теории надежности для
оценки качества сложных КП позволяет получить ряд четких
Хорошо измеряемых интегральных показателей качества тес-
тирования программ. Приведённые критерий используются в
основном при испытаниях КП и на завершающих фазах ком-
плексной отладки. Их практически невозможно использовать '
для оценки качества тестирования программных модулей или
групп программ, решающих-частные функциональные задачи. ,
Процесс тестирования происходит во времени, и его дина-
мические характеристики могут служить частными конструк-
тивными критериями для оценки качества тестирования. В -
§ 1.2 представлена интенсивность обнаруже-
ния ошибок, или число ошибок, выявляемых в програм-
мах в процессе тестирования за единицу времени при-постоян-
ных усилиях на его проведение. В этом критерии качества тес-
тирования отражаются ошибки, приводящие к нарушению ра-
ботоспособности программ, и ошибки, искажающие резуль-
таты, но не влияющие на надежность функционирования про-
грамм. В этом случае для интенсивности тестирования харак-
терна положительная обратная связь — чем больше выявля-
ется ошибок в программе на некотором интервале времени, тем
шире должно быть варьирование тестовых данных и больше
тестов. По мере устранения ошибок в программе частость их
обнаружения снижается и специалисты, осуществляющие тес-
тирование, попадают в область низкого темпа обнаружения
.ошибок.
Если интенсивное тестирование программы в течение до-
статочнодлительного времени не приводит к обнаружению оши-
бок, то у специалистов, ведущих тестирование, создается ощу-
щение бесполезности дальнейшего тестирования данной про-
граммы и онЬ передается на комплексирование или на экс-
плуатацию.Экспериментальное исследование характеристик об-
наружения ошибок в сложных КП Ш. 50, 98) позволило оце-
нить темп обнаружения ошибок, при котором комплексы Пере-,
даются на регулярную эксплуатацию ((2—5)-Ю-’ ошибок в
день на человека). Интенсивность обнаружения, ошибок ниже

1-10-’ ошибок в день на человека, т. е. меньше одной ошибки
в год на трех сйециалистов, непосредственно участвующих в
тестировании, по-видимому, может служить эталоном высоко-
го качества тестирования для. КП обработки информации и
управления. Следуёт подчеркнуть, что при использовании это-
го критерия обычно учитывается календарное время отладки,
включающее длительность непосредственного тестирования
как для обнаружения, так и для локализации ошибок, а также
длительность корректировки программ и других вспомогатель-
ных работ. Таким образом, при постоянных усилиях на тести-
рование программ, интенсивность обнаружения ошибок мож-
но использовать как критерий качества тестирования. Необ-
ходимо учитывать, что обычно по мере снижения темпа обнару-
жения ошибок уменьшается интенсивность тестирования, что
не способствует улучшению качества программ и ускоряет до-
стижение порогового значения нечувствительности к ошиб-
кам.	» .	'7
Наработка на отказ учитывает ситуации потери работоспо-
собности, когда длительность восстановления велика и превы-
шает допустимое значение времени, разделяющее события сбоя
и отказа [361. При этом большое значение имеют средства опе-
ративного контроля н восстановления (рестарта). Качество
проведенного тестирования более полно отражается длитель-
ностью между потерями работоспособности программ — нара-
боткой на о f к а з о в у ю ситуацию, не-
зависимо от того, насколько быстро произошло восстановлен
ние. Средства оперативного контроля и восстановления не
влияЮт на наработку на отказовую ситуацию, однако могут
значительно улучшить показатели надежности программ. По- ,
этому при оценке необходого тестирования целесообразно из-
мерять и контролировать наработку иа отказовую ситуацию,
а объем и длительность тестирования в ряде случаев устанавли-
вать по наработке на отказ, с учетом эффективности средств
рестарта.
В реальных системах достигаемая в процессе тестирова-
ния (при отладке и испытаниях) наработка на отказ КП обыч-
но'сонзмерима с наработкой на отказ аппаратуры, на которой
исполняется программа. Для систем управления в реальном
времени наработка на отказ программ измеряется десятками и
сотнями часов, а для особо важных или широко тиражируе-
мых систем может достигать десятков тысяч часов‘[68, 981.
При дост0хочно развитом программном оперативном контроле
и восстановлении наработка на отказовую ситуацию может,
быть на один-два порядка меньше, чем наработка на отказ.
Реально очень трудно, достичь наработки на отказовую ейтуа-
3 з*к. им!	.65
цкю на уровне сотен часов и поэтому для получения высокой
надежности программ невозможно ограничиться тестирова-
нием без использования средств рестарта.
Приведенные выше интегральные и частные критерии ка-
чества с разных сторон характеризуют процесс тестирования
и различаются удобством применения в зависимости от объе-
ма тестируемых программ, этапов разработки и достигнутого
качества программ. Для завершения тестирования наиболее
активно используются частные конструктивные критерии ка-
чеетва. Однако в реальных условиях при ограниченных ре-
сурсах на проектирование КП критерием завершения тестиро-
вания может быть ограничение допустимых
затрат. Эти допустимые затраты зависят от сложности КП
и его компонент и от удельных затрат на выполнение каждого
акта тестирования. В результате сложность программ и затра-
ты становятся косвенными критериями или факторами, влияю-
щими на качество тестирования программ.
Качество тестирования сильно зависит от достовер-
ности эталонных и тестовых данных.
Эти данные подготавливаются вручную или автоматизировано
и так же, как любые данные, характеризуются некоторым уров-'
нем ошибок. Для сокращения числа ошибок в тестах, эталонах
и заданиях иа тестирование необходимы в свою очередь их
проверка и тестирование. При применении не абсолютно досто-
верных тестов создаваемые программы и данные, естествен-
но не могут иметь'корректность выше, чем у используемых тес-
тов. Слепая вера в безупречность тестов и создающих их средств
часто приводит к низкой фактической корректности программ
при относительно высокой формальной.
2.2. СЛОЖНОСТЬ ТЕСТИРОВАНИЯ ПРОГРАММ
Основные виды сложности программ. При анализе тести-
рования имеются два аспекта оценки его сложности: опреде-
ление сложности процесса тестирования различных про-
граммных компонент и определение сложности объектов
тестирования — программных модулей, групп и комплексов
программ, используемых данных и связей. Эти аспекты тес-
но связаны и сложность объекта тестирования обычно опреде-
ляется числом ошибок, выявленных при тестировании, или
трудоемкостью этого процесса. Глубокая корреляция между
сложностью объектов и сложностью процессов тестирования
Нозволяет рассматривать их совместно, последовательно акцен-
тируя внимание на одной из них.
66
Понятие сложности интуитивно ассоциируется с ресурса-
ми, необходимыми для решения соответствующей заДачн. Весь-
ма расплывчатые понятия сложности программ или их тести-
рования значительно коцкретизнрутся и становятся измеримы-
ми, когда устанавливается связь-этих понятий с конкретными
ресурсами, необходимыми для их реализации. Задача считает-
ся простой, если невелики все ресурсы, используемые для ее
решения. Однако, если хотя бы один из необходимых ресурсов
очень велик или оказывается на пределе, доступном для ис-
пользования, то такую задачу не считают простой. Сложность
задачи может быть велика по одному ограниченному ресурсу
и невелика из-за малого использования остальных.
При тестировании программ их сложность определяется,
в'основном', тремя видами ресурсов, которым соответствуют:
временная сложность программ в процессе тестирования,
которая характеризуется временем счета типовых контроль-
ных примеров, необходимых для проверяй всех функций про-
грамм^, или временем решения типовой задачи;
программная сложность модуля, группы или комплекса, со-
ответствующая сложности текста и структуры программы, В со-
вокупности определяющих разнообразие возможных характе-
ристик ее функционирования;
информационная сложность программы, характеризующая-
ся объемом исходной информации, необходимой для охвата
всех условий ее исполнения, и объемом получаемых на выходе
данных.
Эти виды сложности определяют разные виды ресурсов Ис-
пользуемых при тестировании. Временная сложность прежде
всего влияет на требующуюся производительность ЭВМ, на
которой осуществляется тестирование, и в меньшей степени
определяет ресурсы труда программистов. Программная слож-
ность в основном потребляет ресурсы разработчиков программ
для подготовки и анализа процесса .функционирования про-
граммы при тестировании. В некоторых программах определяю-
щей при тестировании может быть информационная сложности
подготовки и анализа данных, используемых для проверки и
нормального функционирования программ. В зависимости от
алгоритма и характеристик программы при ее тестировании
доминирующей может быть временная, программная или ин-
формационная. сложность.
Временная сложность программ в основном определяется
алгоритмами, используемыми для решения задач [54, 601. Не-
смотря на возрастание быстродействия современных ЭВМ име-
ется.много задач, которые невозможно решать некоторыми точ-
ными, прежде всего комбинаторными, алгоритмами при необ-
3*
67
холимом объеме входных данных. Для того чтобы оценивать
временную сложность алгоритмов независимо от быстродейст-
вия ЭВМ.ее характеризуют количеством операций или услов-
ных единиц времени «шагов» работы ЭВМ, требующихся для
- обработки входных данных [54f.
В принципе, для каждой вычисляемой функции существу-
ет бесконечно много алгоритмов, которые ее. вычисляют и ко-
торые могут значительно различаться по'временной сложности.
Для оценки и сравнения временной сложности различных алго-
ритмов проведены исследования, позволивщие раскрыть сущ-
ность изменения объема вычислений от размерности исходных ’
данных для ряда типовых вычислительных задач. Ускорение
вычислений достигается за счет повышения сложности про-
грамм, вычислителя или расширения алфавита исходных дан-
ных. Для многих типов задач с помощью узкой специализации
программ для ограниченной области изменения входных дан-
ных имеется возможность эффективного ускорения вычислений. -
Теоретически доказана принципиальная возможность
ра'зме-на времени решения любых за-
дач на емкость памяти для хранения программ и
данных, однако пока отсутствуют общие конструктивные пути
размена и оценки соотношения между значениями изменяемых
характеристик в зависимости от классов решаемых задач. Изу-
чены алгоритмы типовых операций над матрицами, комбина-
торные алгоритмы поиска и распознавания, алгоритмы выпол-
нения арифметических операций на ЭВМ и т. д., для которых
найдены предельные по экономии времени общие методы реше-
ния задач и, в некоторых случаях, соотношения размена вре-
мени на емкость оперативной памяти для хранения данных
154, 601.
Современная теория сложности вычислений преимущест-
венно занимается анализом наиболее простых или очень слож-
ных заДач. Основные реальные задачи- находятся между ис-
следуемыми предельными, и для таких реальных задач теория
сложности дает не очень много [601. Тем не менее имеющиеся
оценки временной сложности многих, особенно комбинатор-
ных, алгоритмов показывают, что при реальной производи-
тельности ЭВМ возможности тестирования и достижимая кор-
ректность программ могут существенно определиться их вре-
менной сложностью. Это означает, что время счета программ
по тестовым данным и длительность расчета эталонных зна-
чений возрастают столь быстро, что реальные ресурсы совре-
менных ЭВМ ограничивают допустимую полноту тестирования. .
Программноя сложность оценивается различными методами,
которые в той или иной степени связываются с трудоемкостью •
68
















разработки, и в частности тестирования, программ, а также с
числом, ошибок, выявляемых в процессе тестирования. Разра-
ботан ряд теоретических концепций, способствующих более
адекватной оценке сложности программ.
В простейшем случае сложность можно оценить по числу
символов в тексте программы, необходимому для ее полного
описания на некотором алгоритмическом языке, или по числу
операторов (команд) при. реализации программы на некоторой
ЭВМ. Разнообразие алгоритмических языков и структур ко-
манд ЭВМ затрудняет обобщенные оценки и сравнения про-
граммной сложности различных программ. Однако введение со-
глашений структурного программирования и перечней стан-
дартных операторов программирования позволяет в значи-
тельной степени унифицировать языковую базу, на которой
проектируются программы. При этих ограничениях возмож-
ный разброс объема программ, построенных по одному алго-
ритму, вследствие различия языков программирования в боль-
шинстве случав намного меньше, чем диапазон изменения объе-
ма текста программы при изменении алгоритмов для решения
одной н той же задачи, В качестве меры программной слож-
ности широко применяется число машинных команд в програм-
ме (или в тексте на ассемблере) из-за относительной простоты
определения этого параметра. Однако различия количества ис-
пользуемых байт на одну операцию затрудняют подсчет слож-
ности текстов программ по количеству машинных команд, а
также сопоставление программной сложности при применении
ЭВМ с различной структурой команд. Поэтому часто исполь-
зуются оценки по емкости памяти, занимаемой программами
(байт или слов .конкретной ЭВМ).
Доказано, что программу, записанную на некотором алго-
ритмическом языке, всегда можно сократить, заменив алго-
ритм Вычисления. Кроме Того, сокращение описания програм-
мы возможно при изменении грамматики алгоритмических
языков. Программная сложность в наибольшей степени опре-
деляет трудоемкость тестирования большинства Программ уп-
равления и обработки информации. Поэтому теоретическим ме-
тодам и экспериментальном оценкам программной сложности
посвящена основная часть данного параграфа.
Информационная сложность программ в первую очередь
зависит от числа типов и структуры данных, поступающих на
вход и выдаваемых программой. Число различных видов опе-
рандов, используемых в программе, достаточно полно характе-
ризует ее информационную сложность. Для приближенных
инженерных оценок в качестве, меры информационной слож-
ности применяется емкость памяти, необходимой для оператив-
ен
кого накопления и хранения данных, используемых при реше-
нии задачи. Это понятие включает емкость всех ячеек памяти
и регистров, к которым осуществляется обращение при обра-
ботке операндов в процессе решения задачи. При этом важно
установить величину каждого элемента памяти или стандарти-
зировать их размеры. В пределе, если емкость регистров не
ограничена, все обращения могут осуществляться к единствен-
ному регистру и появляется необходимость измерять емкость
частей этого регистра. Для конструктивного анализа информа-
ционной сложности принимаются соглашения, ограничивающие
емкость элементов памяти в пределах объема одного среднего
или максимального из всех возможных операндов или одного
символа описания данный на языке программирование.
Информационная сложность в значительной степени явля-
ется .динамической и обычно широко варьируется в зависи-
мости от размерности входных данных. Скорость роста инфор-
мационной сложности в зависимости от исходных данных опре-
деляется классом вычисляемых функции" и алгоритмами, ис-
пользуемыми для вычислений. Если методы кодирования и
структура памяти, фиксированы, то информационная слож-
ность может быть уменьшена построением более сложных про-
грамм или применением алгоритмов с большим временем сче-
та.
Информационная сложность алгоритмов связана со слож-
ностью описания, накопления и хранения исходных, промежу-
точных и результирующих данных при решении некоторой за-
дачи. Сложность некоторого набора данных можно характери-
зовать энтропией множества, которая устанавливает, сколько
двоичных разрядов необходимо для наиболее экономичного опи-
сания любого элемента множества. Используя дополнительные
сведения о функциональной связи элементов множества, мож-
но значительно сократить объем данных, необходимых для
однозначного табулирования этого множества. При этом, кро-
ме численного .представления некоторых данных, появляется
алгоритм их декодирования (трансляции) для получения всего1
множества величин. Таким образом, сложность представления
некоторого множества данных может быть отражена совокуп-
ностью сложности табулирования опорных данных и сложно-
сти программ их декодирования для раскрытия всех значе-
ний.
К сложности табулирования примыкает понятие сложности
текста данных — как длины самого короткого слова, содержа-
щего всю информацию, необходимую для восстановления рас-
сматриваемого текста при помощи некоторого способа декоди-
рования. Метод и программы декодирования или трансляции
70
текста данных'существенно влияют на его объем. В совокуп-
ности значения сложностей исходного текста и средст в расшиф-
ровки можно интерпретировать как содержащееся в них коли-
чество информации, необходимой для полной расшифровки
текста данных. В результате сложность текста оказывается кор-
релированной со сложностью программ трансляции при задан-
ном объеме информации, отражающейся в тексте.
Программная сложность модулей. Программные модули яв-
ляются наиболее простыми компонентами в КП, поэтому наи-
более доступны для количественного анализа сложности. Ис-
следования сложности программных модулей развиваются по
двум направлениям 165, 86, 37] и позволяют оценить основные
характеристики, от которых она зависит. Первое направление
(структурное) базируется на исследовании внутренней струк-
туры модулей и на обобщении их характеристик с Целью полу-
чения значений сложности. При ^том наибольшее внимание
уделяется анализу маршрутов исполнения программ и объему
тестов, необходимых для проверки структуры прог^ммных
модулей при тестировании.
Второе направление исследований (статистическое) бази-
руется на опредёленйи некоторых внешних измеряемых харак-
теристик программных модулей (число операторов и операндов,
число их типов и т. д.). Обобщение этих характеристик позво-
лило рассчитать сложность модулей и связать ее. с обобщенной
трудоемкостью их создания и тестирования, а также с количе-
ством ошибок, подлежащих обнаружению и устранению. Оба
направления с различных позиций связывают значения слож-
ности с трудоемкостью разработки (и в частности, тестирова-
ния) модуля.
Структурная сложность программ определяется числом
взаимодействующих компонент, числом связей между компо-
нентами и сложностью их взаимодействия. При функциониро-
вании программы разнообразие ее поведения и разнообразие
связей входных и результирующих данных й значительной сте-
пени определяются набором путей-маршрутов, по которым ис-
полняется программа. Установлено 186], что сложность про-,
граммного модуля зависит не столько от размера программы
(числа команд), сколько от числа отдельных путей ее испол-
нения, существующих в программе. Все маршруты возможной
обработки данных должны быть проверены при создании про-
граммы и тем самым определяют сложность ее тестирования,
В ряде исследований (65, 28, 87, 96] подтверждена доста-
точно высокая адекватность использования структурной слож-
ности программ для оценки трудоемкости тестирования, ве-
роятности невыявленных ошибок и затрат на разработку про.
71
граммных модулей в целом. Сложность 'программных модулей
можно оценивать по числу маршрутов Мь, необходимых для
их'Проверки, или более полно по суммарному числу условий
ЕЛ, которое необходимо задать в тестах для прохождения всех
маршрутов k-и программы:
"л
-U=SU.-	(2.1)
<=i
где — число условий-предикатов, определяющих »-й мар-
шрут. 
Маршруты исполнения Л-го программного модуля можно
усЛовно разделить на два вида: маршруты исполнения пре-
имущественно вычислительной части программы и преобразо-
вания квазинепрерывиых переменных и маршруты принятия
логических решений й преобразования логических переменных.
Маршруты первого вида &5ычно логически проще и короче,
чем BWporo, и предназначены для преобразования величин,
являющихся квантованными результатами измерения неко-
торых непрерывных физических характеристик (квазинепре-
рывные переменные). Такие переменные связаны условиями
гладкости, т. е. условиями малых извинений производных этих
переменных по времени или по другим параметрам. Этим мар-
шрутам соответствует понятие сложности обработки данных.
При оценке сложности вычислительных маршрутов про-
грамм необходим учет чиела операндов, участвующих в вычис-
лениях. Кроме того, исходные и результирующие данные при
тестировании должны принимать несколько значений. Во всем
диапазоне исходных переменных следует выбрать несколько
характерных точек (предельные значения и несколько проме-
жуточных), при которых проверяется программа. В особых
точках значений и сочетаний переменных и в точках разрыва
функции необходимо планировать дополнительные проверки.
Таким образом, сложность проверки Л-го программного модуля
будет определяться числом маршрутов Mh исполнения про-
граммы и числом обрабатываемых операндов /f на каждом i
маршруте, умноженном на число значений vt] для каждой ис-
ходной j-й величины на этом маршруте
(2.2)
Расчет показателя сложности программного модуля по
такой схеме имеет значительную неопределенность из-за про-
извола в выборе числа значений vfj (в основном особых точек)
72
при варьировании исходных данных. В то же время доля вы-
числительной части во многих сложных КП управления и об-
работки информации относительно невелика. Ее можно оце-
нить из того, что число умножений и делений в таких програм-
мах в сумме составляет обычно 1—3 %, а общее число ариф-
метических операций не превышает 10 % [34i. Поэтому ниже
большее внимание уделено анализу структурной сложности
модулей программ.
Второй вид маршрутов является результатом функциони-
рования схем принятия решений, и преобразования логиче-
ских переменных. Для логических переменных отсутствует
сильная корреляционная связь между соседними значениями и
каждое изменение разряда переменной может определять раз-
ные области результирующих значений. Такое преобразова-
ние переменных обеспечивается алгоритмами со сложной ло-
гической структурой, содержащей ряд проверок логических
условий, циклов для поиска и селекции переменных, а также
логические преобразования переменных. В результате в про-
грамме образуется множество маршрутов обработки исходных
данных, которые определяют сложность структуры програм-
мы,
Структурная сложность программного модуля может быть
рассчитана по числу маршрутов Л4Л в программе и сложности
каждого i-гс маршрута Эти показатели в совокупности
определяют минимальную сложность тестов для проверки
программных модулей (2.1), а следовательно, трудоемкость
их разработки и вероятность пропуска ошибки в программе.
Выделение маршрутов исполнения программы, минимально
необходимых для ее проверки, и оценка структурной сложно-
сти может осуществляться по различным критериям. При этом
формирование маршрутов зависит не только От структуры
программы'яо н от значений переменных на различных фазах
обработки. Такое выделение маршрутов трудно формализо-
вать, И оно представляется излишне трудоемким для оценки
показателей сложности*программ.' Поэтому, в основном, ис-
пользуются проетые критерии выделения. маршрутов, учиты-
вающие только структурные характеристики программных мо-
дулей.
Программные модули являются наиболее массовой компо-
нентой в КП и требуют для тестирования суммарно наиболь-
ших затрат. Затраты на тестирование каждого модуля прямо
пропорциональны сложности, которая зависит от его струк-
туры И объема вычислений. При тестировании А-го программно-
го модуля необходимо задать и проанализировать число зна-
73
чений параметров
Mk { li	\	'
₽*=2 2VSi-	(2-3'
* = i \ / = i	/
Суммарные затраты на тестирование модуля пропорцио-
нальны значению его сложности и определяются выраже-
нием:
' Mk [ h	\
O-Cj +	,	(2.4)
i=i\/=i	J
Значение множителя с зависит от степени автоматизации
процесса тестированиями .генерации тестов. В высокоавтома-
тизированных системах сокращаются затраты ручного труда
на подготовку и анализ тестовых данных, однако увеличивают-
ся затраты на машинное время, необходимое для генерации
тестов и для автоматической обработки результатов тести-
рования. В зависимости от этих факторов значения с могут
различаться в несколько раз и их следует экспериментально
определять для каждой системы автоматизации тестирова-
ния.
Для определения суммарных затрат на тестирование моду-
ля необходима оценка вероятности пропуска ошибки в моду-
ле, т. е. достигаемого качества тестирования при принятом
критерии выбора маршрутов исполнения программы и числа 1
значений каждой переменной vtJ для выбранного марш-
рута. Обычно устанавливаются некоторые правила выде-
ления маршрутов и варьирования переменных, гарантирующие
достаточно глубокое тестирование модулей. Эти правила вы-
бираются эмпирически по опыту аналогичных разработок и
стандартизируются для определенного проекта.
-Приведенное выражение (2.3) целесообразно использо-
вать для выявления сложных модулей, требующих наиболь-
ших затрат на тестирование, и для рационального распределе-
ния ограниченных ресурсов тестирования. Некоторые модули
могут оказаться недостаточно протестированными из-за их
высокой сложности и необходимости больших затрат, которые
всегда ограничены. Их неполная тестированность определяет
качество функционирования групп и комплекса программ в
целом. Ограниченность ресурсов на тестирование программных
модулей приводит к целесообразности вы равняв а ния
их стр'уктурной сложности и выделения за-
трат на проверку в соответствии со сложностью каждого мо-
дуля. Особенно сложные модули следует делить на более мел-
74
кие и простые и так перестраивать их структуру, чтобы сокра-
щались число маршрутов в модуле и их длина.
Сложность групп' программ определяется сложностью моду-
лей и межмодульных связей по управлений и по информации.
Каждый модуль тестируется автономно до включения в груп-
пу программ и частично в. составе этбй группы. Затраты на тес-
тирование модулей в составе группы программ должны учиты-
вать относительные суммарные затраты на тестирование всех
входящих модулей с коэффициентом 1, зависящим от
степени проверки А-гр модуля. Если модули автономно не тес-
тировались (например, при нисходящем тестировании), то
= 1 и затраты на тестирование каждого модуля войдут в
затраты при тестировании группы программ в полном объе-
ме. При тщательном автономном тестировании модулей мож-
но полагать « 0,1 4- 0,01, т. е. в КП затраты на тестирова-
ние модулей составляет несколько процентов. В результате
затраты Сг на тестирование Н модулей в составе группы про-
грамм
Я Мк ( ‘i	\	'	„ _ -
сг= 2 8*сУ 2 ^ + Si 	(2.5)
л = 1	\/=i	J	;
При анализе сложности тестирования межмодульных свя-
зей по управлению и по информации следует учитывать, что тес-
тирование каждой информационной связи обычно необходимо
при нескольких значениях каждой переменной, что соответст-
венно увеличивает затраты. Оценка относительной сложности
тестирования групп программ способствует правильному рас-
пределению ресурсов (машинного времени, специалистов и
т. д.), выделяемых на тестирование групп разной сложности.
Кроме того, такие оценки стимулируют более полное тестиро-
вание программных модулей, так кдк обнаружение и локализа-
ция каждой ошибки в группе программ на порядок дороже, чем
в автономном модуле. Поэтому целесообразно при тестирова-
нии групп программ составляющую затрат на тестирование
модулей иметь минимально возможной.
При тщательном предварительном тестировании комплекси-
руемых модулей, сложность тестирования групп программ оп-
ределяется в основном затратами на тестирование межмодуль-
ных информационных связей.' В ряде случаев наибольшие
затраты обусловлены связями по глобальным переменным
между тестируемой и другими группами программ. Для оценки
абсолютных затрат на тестирование групп программ необхо-
димы значения затрат на проверку каждой информационной
и управляющей связи. Эти затраты зависят от сложности ими-
75
танин входных данных тестируемой группы программ и от
сложности самих связей. Четкое структурирование групп
программ позволяет значительно упростить связи и. снизить
затраты на их тестирование. Снижению затрат способствует
также автоматизация и упорядочение тестирования групп
программ.
Сложность разработанных реальных программных модулей. В наи-
большей. степени на сложность тестирования влияют:
положение модуля в иерархической схеме КП;
особенности и тип структуры ациклической части модуля;
наличие в модулях циклов и нх- характеристики;
характер вычислительного процесса в- модуле;
характеристики нереализуемых путей исполнения программы..
В. ряде работ [11, 29, 41] исследованы статистические характери-
стики программных модулей в КП управления и обработки информации.
Модули оценивались по числукоманд и условных переходов, по числу 
глобальных переменных на входе и выходе модуля, по сложности струк-
туры и числу циклов и т. д. В результате выявлены три значительно
различающихся типа модулей:
управляющие программы организации вычислительного процес-
са, взаимодействия с внешней памятью, межмашинного обмена и дру-
гие расположенные на высших иерархических уровнях КП;
основные функциональные программы, расположенные иа сред-
них иерархических уровнях и обеспечивающие решение всех специфи-
ческих задач данного комплекса;
стандартные программы для вычисления различных функций и рас-
положенные на низших уровнях иерархии в КП.
Программные модули высших иерархических уровней выполняют
управляющие функции и почти ие осуществляют вычислений. Поэто-
му такие модули имеют на входе небольшое число преимущественно ло-
гических переменных и выдают управляющие воздействия иа вызовы
функциональных модулей. Объем модулей обычно невелик и состав-
ляет в среднем около 100 операторов на ассемблере. В программах часто
'организуются циклы для поиска и селекции данных, а также применяют-
ся переключательные схемы с многим^ выходами. Структурная схема
модулей имеет достаточно регулярный характер, что упрощает нх тес-
тирование.
Наиболее сложными для -тестирования являются функциональные
программные модули, располагающиеся на средних иерархических
уровнях комплекса программ. Эти модули имеют в среднем 200—300
операторов на ассемблере или около-50 операторов на языке высого
уровня. Общее число глобальных переменных составляет в .среднем
около 20.	. ь
Программные модули для вычисления стандартных функций и ре-
шения типовых-простейших задач имеют обычно простую структуру
без циклов и объем в пределах 30—100 операторов на ассемблере.
Число переменных на входе, так же как и на выходе, составляет.около
3—5, а число маршрутов исполнения программы ие превышает 10.
Эти программные модули наиболее просты для тестирования.
Более полно структурная сложность реальных программ исследо-
вана. дл>ц функциональных й стандартных программных модулей [41].
При этом структурная сложность оценивалась числом .в и сложностью
вводящих в него базовых структур (рис. 2.2). Под базовой структу-
рой понимается совокупность линейных участков программы, образую*
76
Рис. 2.2. Зависимость распределения
функциональных (—•—) н стан-
дартных (------) модулей от коли-
чества содержащихся в них базовых
структур 0 и от средней сложности
базовых структур;
щих ациклический маршрут в
сочетании со всеми достижи-
мыми из данного маршрута ци-
клическими. участками, кото-
рые моделируются как одно-
кратно исполняемые. Полное
множество ’ базовых структур
охватывает все маршруты об-
работки информации в кон-
кретной программе. Сложность
базовой структуры оценива-
лась как сумма числа опера-
торов передач управления в
циклах и числа операторов пе-
редач управления в ацикли-
ческом маршруте,
Функциональные модули
содержат в среднем mf = 13
базовых структур (срёднеквад-
ратическое отклонение og =
= 3,8), однако часть их (~5%)
имеет 100 и более базовых
структур. Трудоемкость • от-
ладки таких уникальных по
сложности модулей, как по-
казывает Практика, может пре-
вышать в десятки раз трудоемкость отладки типового модуля. Для
стандартных модулей характерно наличие одной-двух структур, и
распределение в этом случае характеризуется малой дисперсией
1.8, о' = 1,2).
Распределение модулей по средней сложности содержащихся в
I, них базовых структур показывает относительную логическую простоту
стандартных модулей по сравнению с функциональными. Этот факт
подтверждается тем, что усредненная сложность базовой структуры
стандартных модулей оценивается значениями = 1,1 -и о| = 0,3,
т. е. типичный маршрут прохождения информации содержит в таком
। модуле 0—2 передачи управления. Для функциональных модулей ха-
рактерно наличие в среднем восьми передач управления в каждом
маршруте (т| = 8,2 и с| = 4,8).' Совместный анализ этих распределе-
ний показывает, что имеется положительная корреляция между числом
и сложностью базовых структур для исследуемых классов програм-
мных модулей. На основе данных о числе и сложности базовых структур
могут быть получены интегральные оценки сложности тестирования,
измеряемой суммарным числом операторов "передач управления на
I всех возможный маршрутах лрохождёиия информации, для типового
функционального 5* —	= 104 и стандартного £с = mS/nS —
= 1.-98 модулей.
Функциональные модули в КП управлении и обработки информа-
ции приблизительно в 50 % случаев ие имеют циклов. Поэтому после-
| дующий анализ целесообразно проводить, разделив модули на два ти-
па: ациклические и содержащие -циклы различных типов.
77
Сложность тестирования ациклических программных моду-
лей. Анализ проводится с применением типовых абстрактных -
структур и характеристик реальных модулей, разработанных ’
в нескольких проектах. Сложность модулей оценивается по
числу маршрутов М исполнения программы, характеризующих
число тестов, необходимых для полной проверки корректности
структуры модуля. Кроме того, анализируется суммарное чис-
ло условий £, которое необходимо задать в тестах для провер-
ки модуля'. Для получения предельных характеристик струк-
турной сложности модулей целесообразно оценить 140] характе-
ристики некоторых простейших регулярных структур абстракт-
ных графов программ. Анализ проведен для трех типов (42]
ациклических графов (рис, 2.3) при выделении марштутов по
критерию %! охвата каждой дуги графа программы хотя бы
один раз и по критерию Хг выделения всех маршрутов, разли-
чающихся хотя бы одной дугой (см. § 2.1). В числе выбранных
содержатся структуры, охватывающие наиболее типовые ва-
рианты компонент графов программ. При последующем ана-
лизе используются термины, принятые в теории .графов и при
описании структур программ [2, 21, 541. Структуры программ
различаются шириной графов, наличием Симметрии и структу-
рированности. В зависимости от-этого изменяется число мар-
шрутов и сложность структур.
Рис. 2.3. Структуры абстрактных графов программ, использованных
в качестве предельных прн анализе структурной сложности и каче-
ства тестирования
78
Рис. 2.4. Зависимость числа маршрутов М в графах программ (рис.
2.3) от числа вершин ветвления пв при выделении маршрутов по
первому Xi и второму х> критериям (О — реальные программы при
Хь А — при цифры — число совпадающих значений)
Граф Гх представляет собой симметричное упорядоченное бииар-
ное дерево с максимальным использованием ветвлений и максималь-
ной шириной. В графе Г3, наоборот, ширина минимальная и всего два
полностью различающихся дугами маршрута; Простую линейную струк-
туру представляет граф Г2, в котором число маршрутов при любых рас-
смотренных критериях выделения определяется, чйслом ветвлений.
Предельные размеры исследованных графов ограничивались 128 вер-
шинами, одиако основные результаты анализировались для графов до
32 вершин, чтд соответствует средним программным модулям, содер-
жащим до 300 команд.	. «
Исследованные графы характеризуются двумя функциональными
зависимостями числа маршрутов от числа вершин ветвления (рис. 2.4).
При выделении маршрутов по первому критерию в графе Г3 число
79
маршрутов не зависит от числа вершин и определяется повторяющейся
структурой между узлами. В результате в графе Г3 выделяется только
два маршрута. В графах Гя и Га при выделении маршрутов по крите-
рию fa их число линейно возрастает при увеличении числа вершин.
При выделении маршрутов по второму критерию их число про-
порционально полному числу вершин для всех типов графов. Если в
графах учитывать только те вершины, в которых происходит ветвле-
ние лв, то нх число с точностью до единицы равно цикломатн ческому
числу Z или полному числу маршрутов /И;	*
2=Г—nB4-2 = 2nB—nB + l=nB4-l.	(2.6)
Следовательно, все зависимости числа маршрутов от числа верши-
ны ветвления при критерии Хе совпадают. Кроме того, для графов Га
н Г3 числа маршрутов совпадают при всех трех критериях fa, х« и fa
и равны М = лв + 1. В графах Г3 и Г3 полное число вершин, кро-
ме вершин с ветвлением, включает единственную конечную вершину,
в результате чего число маршрутов точно равно полному числу верШнн.
В бинарном дереве Г1( в нижней половине графа вершины не содержат
ветвления и число таких вершин равно половине от общего числа. По-
этому число маршрутов в таком графе вдвое меньше полного числа вер-
шин.
Следует отметить, что в узких графех Г3 число маршрутов, выде-
ляемых по первому и второму критериям, различается на величину,
пропорциональную числу вершин (лв — 1). Число маршрутов в ре-
альных ациклических программах (точки на рис. 2.4) при критерии fa
точно соответствует цикломатнческому числу, а при критерии fa
.близко к нему. Таким' образом, при инженерных о ц'е и-
к а х числа тестируемых маршрутов целесо-
образно использовать выражение (2.6). Число
мршрутов при их выделении по критерию fa в графе Г\ и Г3 не изме-
няется, а в графе Г3 возрастает в зависимости от числа вершин значи-
тельно быстрее (2*®), чем цикломатнческое число; Величину 2П“ можно
использовать для оценки максимального' числа маршрутов в наиболее
сложных ациклических- программах.
Структурная Сложность. £ графов изменяется в более широком
диапазоне, чем число маршрутов, что определило выбор логарифмиче-
’ ского масштаба по оси ординат иа рис. 2.5. Наименьшей структурной
сложностью характеризуется граф Г3 при выделении маршрутов по
первому критерию. Для таких графов структурная сложность возраста-
ет линейно в зависимости от числа вершин. При ныделенни маршрутов,
по второму критерию граф Г3 характеризуется’ наибольшей структур-
ной сложностью. При 32 и более вершинах структурная сложность гра-
фа Г3 почти на порядок выше, чем графа 1\ при том же числе вершин.
Относительная разница сложности этих графов при критерии Хе при-’
близительво сохраняется при изменении числа вердиин от 16 до 128.
Такое распределение значений структурной сложности от тнпон
графов обусловлено различием их ширины. Так как при критерии х»
.число маршрутов в зависимости рт пв во всех графах изменяется- оди-
наково, то различия структурной сложности определяются числом ус-
ловий, анализируемых в каждом маршруте. Во всех маршрутах графа
Г3 участвуют все его вершины, поэтому он имеет наибольшую структур-
ную сложность средн рассматриваемых графов.
На рис. .2.5 приведены значения структурной сложности реальных
ациклических программных модулей в двух системах. Характеристики
абстрактных графов Г( и Г3” действительно охватывают диапазон изме*
во
Рис. 2.5. Зависимость сложности тестирования j от числа вершин
ветвления пв в графах программ (рис. 2.3) при выделении маршру-
тов по первому Xi и второму х» критериям (О — реальные про-
граммы при критерии Xi. Д —при критерии Ха.--------; аппрокси-
мация /3; цифрами обозначено число совпадающих значений)
81
нення показателей сложности тестов для реальных программ, которые
по каждому критерию группируются приблизительно посередине. По-
этому при инженерных оценках суммарной сложности тестов) необхо-
димых для полной проверки ациклических программных модулей, мож-
но пользоваться простым произведением числа маршрутов на число
вершин в самом длинном маршруте, деленном на два.
Максимальная сложность тестов во второму критерию для произ-
вольных ациклических программ близка к числу |тах (Хг) ~ я*. По
тому, же критерию минимальная сложность тестов для широких струк-
турированных графов типа дерево ( Г4) иа порядок меньше максималь-
ной. Для усредненных оценок сложности тестов произвольных ацикли-
ческих программ хорошее приближение • прй лв > 10 дает выражение
I — Лв/3 (штриховая линия иа рис. 2.5). Характерно, что увеличение
числа вершин в 4 раза (от 32 до 128) для рассмотренных графов приво-
дит к возрастанию структурной сложности более чем в 10 раз. Если же
.программу, имеющую 128 вершин, разделить на 4 модуля, то их суммар-
ная сложность практически равна только учетверенной сложности мо-
дулей, содержащих по 32 вершины. Следовательно, для упрощения тес-
тирования программ необходимо ограничивать размеры программных
модулей а пределах 10—20 вершин. Исследованные реальные програм-
мные модули н 80 % случаев содержат не более 10 вершин и имеют струк-
турную сложность |	50.
Сложность тестирования программ,. содержащих циклы. Наличие
циклов в программе способно резко увеличивать сложность нх тести-
рования. Полное (исчерпывающее) тестирование должно охватывать
проверку каждого маршрута в цикле при всех возможных итерациях
цикла и при всех сочетаниях циклов с маршрутами ациклической ча-
сти программы. Предположим для простоты [43], что число маршру-
тов в инжией ациклической части S3 программы (рис. 2.6) равно
Af3 = 1. Тогда полное множество маршрутов М* состоит из полной со-
вокупности всех марштутон Мг в верхней ациклической ^асти програм-
мы и группы маршрутов Ма, в которой к каждому маршруту ц1/1 ( М1
присоединено 1,2, ... итерации (витка) цикла, причём на каждой итера-
ции выполняется, по крайней мере, один из ннутренннх маршрутов
р2уа € Мг тела цикла Sa. Например, для графа, имеющего один цикл,
требующего исполнения пяти итераций (витков) с тремя внутренними
маршрутами, а также содержащего Л4Х — 10 ациклических маршрутов,
проходящих через цикл, суммарное число маршрутов для исчерпываю;
щего тестирования равно. М* = (3-5)-10= 150. При возрастании
любого из сомножителей (числа ациклических маршрутов, проходящих
через цикл, числа внутренних маршрутов тела цикла или числа его
итераций) пропорционально растет их произведение, а следовательно,
И сложность тестирования. Поэтому исчерпывающее тестирование ре-
альных сложных программ с циклами практически невозможно.
На сложность тестирования цикла оказывает влияние его струк-
тура и два параметра: число маршрутов в теле цикла и число итераций
цикла. В динамике реального исполнения простейшего цикла между
его итерациями может существовать по крайней мере три вида зависи-
мостей:
иа разных итерациях цикла'исполняются независимо все возмож-
ные маршруты тела цикла;
на всех итерациях цикла исполняется один и тот же маршрут тела
цикла или некоторая определенная нх последовательность;
82
на разных итерациях цикла из-за наличия семантических связей
исполняется подмножество реализуемых маршрутов тела цикла, зави-
сящее от данных или от номера итерации.
При первой зависимости, которая' встречается наиболее редко,
возникает необходимость в полном переборе всех внутренних маршру-
тов, тела цикла в сочетании^ каждым числом итераций. В этом случае
сложность тестирования цикла определяется сразу обоими параметра-
ми: и числом маршрутов тела цикла, и числом итераций — и прибли-
жается к сложности исчерпывающего тестирования. При второй за-
висимости число маршрутов тела цикла практически не влияет на слож-
ность цикла. Определяющим становится число'итераций, необходимых
для тестирования вычислений в теле цикла (например с учетом требуе-
мой точности). При третьей, наиболее распространенной зависимости
определяющим при оценке сложности тестирования является не число-
Рис. 2.6. Граф программы с циклом и его маршруты
83
итераций цикла, а число маршрутов тела цикла. Простейшие оценки
сложности циклических структур целесообразно проводить в предпо-
ложении. что порядок.реализации маршрутов тела цикла не зависит от
номера итерации. В этом случае при оценке сложности циклических
структур конструктивным является подход с позиции минимально не-
обходимого числа проверок итераций 'циклов.
Для оценки сложности структурного тестирования логических
программ с простейшими циклами целесообразно уточнить критерии
проверки Xi и Ха- По критерию Xi циклическая часть программы покры-
вается минимальным числом маршрутов, в которые входят маршруты,
проходящие через цикл, размыкающие его и образующие минимальное
покрытие тела цикла. Кроме того, к покрытию добавляется маршрут,
содержащий замыкающую дугу цикла.
По критерию х* ациклическая часть программы проверяется чис-
лом тестов, равным цикломатической сложности [86, 96} ациклической
. части графа программы. К каждому такому маршруту присоединяются
. все примыкающие к нему циклы (такую конструкцию называют так-
же базовой структурой). Проверка каждого цикла осуществляется од-
ним маршрутом с числом итераций, равным цикломатической сложно-
сти тела цикла, а тело цикла покрывается линейно-независимыми март
шрутами.
При таких оценках определяющими факторами являются полнота
проверки тела цикла, условий его замыкания и размыкания. При этих
критериях сложность цикла наиболее просто оценить, представив его
эквивалентным ациклическим подграфом (подграфами). Например, при
критерии Ха эквивалентным циклу с одной точкой входа и одной точкой
вы кода будет линейный подграф, содержащий последовательно соеди-
ненные все линейно-независимые подмаршруты тела’цикла, связываю-
щие его Точку входа с точкой выхода. Такой вквивалентный ацикличе-
ский подграф добавляется к каждому маршруту в покрытии ацикличес-
кой части графа по критерию х«-
.Прн 'Критерии Xi эквивалентной циклу с одной точкой входа и од- ' '
ной точкой выхода будет Совокупность подмаршрутов, соединяющих -J
точки вдода и выхода и докрывающих тело цикла по критерию Xi, J
а также подмаршрут, представляющий собой одну итерацию циклв, со-< •:
стоящую из замыкающей дуги и подмаршрута из покрытия тела цикла.
Совокупность этих подмаршрутов, объединенная в ациклический граф
с общей точкой входа, будет в этом случае эквивалентным графом для г
всего.цикла. Однако в этом случает к каждому из маршрутов в покры-
тии ациклической части графа программы по критерию Хх добавляется
только одни подмаршрут из эквивалентного ациклического графа.
В качестве критериев сложности тестирования структуры програм-
мы с циклами используются два ранее введенных критерия:
число маршрутов М*, выделяемый по критериям х> или Ха и
.. । - суммарная сложность тестирования £, т. е. суммарное число нер- 
шин ветвления нВ всех выделенных маршрутах, соответствующее чис-.
лу условий, которое необходимо задать в тестах прн ныбранном крите-
рии хх или Xi-	е х
На значение критериев сложности М* и t большое влияние оказы-
вает метод покрытия. Действительно, пусть оценивается сложность гра-
фа С циклом (рис. 2:6). При методе Х1 число маршрутов в графе
М* (Х1) = шах {Л1х (xD. (Xi), М, (Хх)}.	(2.7)
где Ма (Xi) — число- маршрутов в теле цикла Sa прн выделении их
по критерию Xi! Mt (Xi), М, (Хх) — число маршрутов, выделенных в
подграфах Sx и Sa по критерию Хх-	*
84
По критерию Xs цикл покрывается одним маршрутом, состоящим
из лииейно-независимых подмаршрутов, покрывающих его тело. Этот
маршрут как составная часть включается в состав каждого маршрута,
покрывающего ациклическую часть графа и проходящего через цикл.
Следовательно, наличие цикла не увеличивает число маршрутов по
сравнении) с ациклическим графом. Поэтому число маршрутов в покры-
тии М* будет состоять из маршрутов, входящих в его ациклические ча-
сти:- Sa покрывает Мг (у,е) и З3 покрывает Ма (х2) маршрутов за ис-
ключением одного общего для инх маршрута: .
м* (х») = Mt (х?) + М3 (Хе) — 1,
где Afj (Ха) и М3 (х2) — число лннейио-иезависимых маршрутов в под-
графах Sj и S3- соответственно,	•	'
Прн простейшей оценке суммарной сложности тестирования мож-
но использовать понятие ранга вершины. Рангом вершины t иазынается
.ее расстояние (т. е. длина' максимального пути по числу пройден-
ных вершин) от начальной вершины графа. Сложность 3-й компоненты
можно оценить сверху величиной [40]:
iS-Zj(%S+l).	(2-8)
где Zs — цикломатическая сложность S-й компоненты (цикла или
ациклического подграфа), соответствующая числу маршрутов; Ящах^—
максимальный ранг компоненты, т. е. наибольший ранг вершины,
входящей в компоненту. Тогда (Rs + 1) представляет собой верхнюю
оценку длины маршрута.
Приведенные соотношения дают возможность провести оценки зна-
чений сложности программ с циклами; имеющих произвольную струк-
туру, по критериям Xi и Хг- Маршруты М* в графе программы в общем
случае состоят из маршрутов, проходящих (М') ,н не проходящих (Л4*)
через цикл:	,•
Af*=.AT4-M*. .	(2.9>
Для критерия Ха к сложности каждого из маршрутов, проходящих'
через цикл, добавляется сложность тестирования цикла:
М' '	ми
5	2 кж₽и+ 1)2Ц]+ 2	"	(2-ю>
I	/»1
где Е(, Еу — сложности тестирования ациклической части маршрутов,
проходящих (()-н не проходящих (/) через цикл, за исключением слож-
ности тестирования цикла; У?ц, — максимальный ранг и цикломати-
ческая сложность тела цикла соответственно.
Для критерия Xii при котором к каждому маршруту, проходящему
через цикл, присоединяется только один подмаршрут из тела цикла
может оказаться, что М' < С учетом этого оценка суммарной слож-
ности тестирования имеет вид:
mlnfAP.ZJ	2ц.
E(Xi) =	2	(Е/+Яц+1)+ 2 Е/+« 2 КЖ#Ж)|.
t=l	/=!	У=Л<'+1
( 1, если Z„—ЛГ>0;
где а = { л	, 
( 0 в противном случае.
85.
Сложность тестирования групп и комплексов программ.
При анализе сложности групп и комплексов программ модули
целесообразно рассматривать как закрытые компоненты, ха-
рактеризующиеся только сложностью связей по управлению
и по информации с другими модулями. При этом внутренняя
сложность структуры модуля и обработки в нем информации
не учитывается, так же как в предыдущих разделах не учиты-
валась сложность реализации операторов при анализе слож-
ности тестирования модулей. Такой иерархический подход к
оценке сложности соответствует теории и практике поэтапного
проектирования и иерархии тестирования модулей, групп и
КП (см. § 1.3). Анализ проводится в два этапа Для каждого
вида связей:
определяется сложность тестирования связей модуля;
рассчитывается совокупная сложность тестирования свя-
зей в группе программ на базе сложности связей входящих мо-
дулей.
Принципы анализа сложностей.тестирования связей моду-
лей в составе группы илн КП практически не различаются, по-
этому ниже используется термин «группа программ».
Сложность тестирования связей каждого модуля по управле-
нию определяется числом вариантов возможных вызовов дан-
ного модуля из других модулей и числом модулей, вызываемых
из данного 141,87, 92]. Каждый t-й модуль может иметь управ-
ляющие, связи ац, которые вызывают его для исполнениями
связи а1}, с помощью которых он вызывает другие модули
—4—•
(рис. 2.7). Величины afj и qi} характеризуют сложность каж-
Рис. 2.7. Схема связей i-ro модуля ,с другими модулями и с исполь-
зуемыми переменными
86
дой связи по управлению и мог ут зависеть от конкретной реа-
лизации этой связи в программе, от интенсивности использова-
ния связи, от метода размещения модулей в памяти ЭВМ и от
ряда других факторов. Однако детальные оценки сложности
каждой связи трудоемки и субъективны, поэтому ниже града-
ция их сложности не учитывается и регистрируется только на-
-4—
лнчие межмодульной связи по управлению, т.е. atJ = atJ = 1,
если модули г и / вызывают друг друга Или возвращают управ-
ление. Тогда число путей входа в данный модуль, т. е. число мо-
дулей, откуда он вызывается, можно характеризовать суммой
входных управляющих связей из группы //модулей. Ана-
/ен
логично число выходных управляющих связей можно предста-
вить как число модулей вызываемых из данного.
Наименьшая связность реализуется, когда i-й модуль име-
ет одну, входную (аи = 1) и одну выходную (ац — 1) связь.
При этом номера модулей на входе и выходе или могут быть
различными или совпадают. В последнем случае t-й Модуль на-
ходится на нижнем иерархическом уровне в данной ветви КП,
так как он не вызывает других, отличающихся от вызывающе-
го, а только возвращает управление после завершения своей
функции. В общем случае сложность управляющих связей для
1-го модуля можно представить суммой:
Л< = 5 (а« + ао)-
/ен
Тогда сложность управляющих связей группы из Н про-
грамм описывается выражением
и	н н
*	(2.11)
i «1	/== 1	1
где суммирование идет по веем Н модулям, входящим в группу.
Представленное число связей характеризует сложность струк-
туры группы или комплекса программ по управлению в процес-
се его функционирования, а также число связей, подлежащих
проверке в процессе тестирования и комплексной отладки. Сле-
дует подчеркнуть, что при таком определении сложности
каждая управляющая связь учитывается дважды: в вызываю-
щем и в вызываемом модуле, что соответствует необходимости
ее проверки в обоих сопрягаемых модулях.
Информационные связи между модулями количественно ана-
лизировать труднее, чем управляющие. Это обусловлено тем,
87
что, во-первых, возможны информационные связи между моду*
лями, непосредственно не связанными ло управлению, а во-
вторых, каждая информационная связь может различаться
сложностью данных. В первом приближении информационная
связь 1-го и /-го модулей может быть оценена числом глобаль-
ных и обменных переменных с одинаковыми именами, исполь-
зуемых в анализируемой паре модулей.. Степень зависимости
каждого модуля от остальных можно характеризовать числом
имен (индекс А), переменных bih на входе, необходимых для
нормального функционирований данного модуля:
Ф.= 5 bik-
Л=1
Число результирующих переменных, подготавливаемых i-M
модулем, характеризует степень информационной зависи-
мости от данного модуля всех остальных в КП
= -2 bih,
где G — число имен переменных, участвующих в информацион-
ных связях. При этом, если некоторая k-я результирующая
переменная применяется несколькими модулями, то число ин-
формационных связей равно соответственно сумме числа моду- -
лей, использующих этуЛ-ю переменную. Переменные, которые
не модифицируются t-м модулем, являются входными и их не
следует учитывать как связи по выходу. Таким образом, слож-
ность информационных связей i-ro модуля можно представить
выражением	-	,
_	_	о—*.
Ф/— Ф14-Ф1=" у, (blh + blh).
fe =* I
Полное число информационных связей в группе программ
равно сумме связей модулей:	-
н и а
ф= 2 Ф*= S S (ь*+blh).
t = l 1=1t=i
(2-12)
Каждая информационная связь учитывается в модулях,
имеющих переменную на входе, а также в модулях, имеющих
ту же переменную на выходе. В результате некоторая k- я гло-
бальная переменная может участвовать в нескольких информа-
ционных связях между, программами, способными использо-
88
вать эту переменную на входе, ив выходных связях только тех
программ, которые модифицируют значение данной пере-
менной. Таким образом, сложность информационных связей
всех Н модулей через k-ю глобальную переменную можно
представить выражением
фл= i (bih+bihy.
/ яи 1
Обычно каждая глобальная переменная применяется двумя
или более программами, а модифицируется чаше всего только
одной, поэтому « 3-4-4. Обменные переменные обеспечива-
ют взаимодействие только двух программ, и сложность нх свя-
зей по каждой переменной минимальная = 21 Кроме того,
обменные переменные упрощают связи тем, что отражают ин-
формационное взаимодействие модулей, непосредственно свя-
занных по управлению.
В представленных выражениях учитывалось только число
информационных связей и не оценивалось их различие по слож-
ности. В реальных КП информационные связи осуществляют-
ся не только через отдельные переменные, но и через перемен-
ные, объединенные в сложные структуры (массивы, списки,
очереди и т. д.). Связи через такие структуры могут быть значи-
тельно сложнее, чем связи через отдельные переменные. Одна-
ко структуры переменных в большинстве случаев участвуют вб
взаимодействии модулей как компактные компоненты, вследст-
вие чего Сложность связей растет не так быстро, как число
переменных в структуре. Для учета возрастания сложности
информационных связей при различных структурах перемен-
ных целесообразно использовать коэффициенты веса xh этих
Лруктур, полученные по результатам экспертных оценок.
В большинстве случаев весовые коэффициенты можно ограни-
чить^ пределах xh = 2-^5.
Информационные, так же как и управляющие связи можно
описать матрицей связей между модулями. Для каждого номе-
ра (имени) программы может быть определено число глобаль-
ных и обменных переменных, по которым эта программа взаи-
модействует с /-й программой btj + btj. Матрица связей фор-
мируется по спецификациям иа модули или по паспортам, про-
траислированных программ. Она позволяет выявить модули,
характеризующиеся наиболее сложными информационными
связями.	'
Таким образом, сложность тестирования управляющих и
информационных связей группы программ, состоящей из Н
модулей, в которых применяется G глобальных и обменных
891
Рис. 2.8. Пример оценки сложности управляющих и информацион-
ных связей группы программ
переменных (или структур данных), можно оценить по фор-
муле
н г Я ч	О	1
Сг=л4-Ф = 2 .2 («w+м + 2 х* •	(2-13)
i=iL/=i	*=»	J
Для примера, представленного на рис. 2.8, сложность уп-
равляющих связей Л = 32, сложность информационных "свя-
зей при xk = 1 равна Ф = 29 и суммарная сложность Сг = 61.
Подобные оценки позволяют сопоставлять значения слож-
ности групп программ и распределять ограниченные ресурсы
тестирования с учетом сложности этих групп. Кроме того, ве-
личина Сг характеризует число параметров в тестах или их со-
вокупную сложность, которая обеспечивает однократную ми-
нимально необходимую проверку всех связей в группе или ком-
плексе программ.
Характеристики сложности межмодульных связей исследованы
экспериментально [41) иа базе двух реальных КП, функционирующих
в системах управления объектами. Каждый КП имел объем около
100 тыс. команд и порядка 500 модулей. Такне комплексы программ со-
стоят из 10—15 групп программ объемом от 5 до 20 тыс. команд каждая.
Для анализа выбирались несколько групп программ, решающих круп-
ные фуикциоиальные задачи и содержащие в сумме до 200 модулей.
Структура программных групп, входящих в комплекс., может быть
отнесена к одному из двух видов. Первый вид структур близок к би-
90
иариому дереву, состоящему из 10—15 иерархических уровней. Число
модулей на каждом уровне увеличивается по мере снижения уровня,
однако медленнее, чем в регулярном бинарном дереве. Структуры вто-
рого вида содержат один или несколько модулей, вызывающих последо-
вательно большое число (5—10) модулей более низкого уровня. Число
уровней в структурах этого вида находится в пределах 3—6, а на одном-
двух нижних уровнях сосредоточивается основное число модулей из
группы. В результате в среднем при любых видах структур на самом
нижнем Иерархическом уровне сосредоточивается до 30 % от общего
числа программных модулей. С учетом двух следующих нижиях уров-
ней число вызываемы! модулей увеличивается до 60 %.
Характеристики взаимодействия между модулями значительно
различаются в зависимости от их расположения в структуре КП. Как
уже отмечалось, можно * выделить программные модули трех типов:
диспетчерские- и управляющие программы организации вычисле-
ний и распределения ресурсов ЭВМ, расположенные на высшнх иерар-
хических уровнях;
основные функциональные программы, решающие наиболее слож-
ные задачи обработки информации и управления, и занимающие сред-
ние уровни в структуре программ;
стандартные программы, предназначенные для решения простейших
типовых задач и вычисления массовых функций, используемые преиму-
щественно на нижиих уровнях иерархии КП.
. Программные модули первого типа характеризуются слабой ин"
формационной связью со всеми остальными. Они практически не обра-
батывают информацию и не используют глобальные переменные. В то
же время их связи по управлению могут быть весьма значительными.
Мойиторы и диспетчеры (центральные и местные) вызывают обычно
около десятка головных модулей групп программ Ю После за-
вершения каждой группы программ вызывается управляющая ею
программа «монитор» или «диспетчер». Возвраты к управляющим про-
граммам производятся по стандартным правилам из нескольких моду-
лей каждой группы программ, поэтому 2jQij Ю -г-400
Функциональные программные модули имеют разнообразные ха-
рактеристики взаимодействия, одиако можно выделить ряд специфиче-
ских особенностей. В исследованных КП каждый модуль вызывает в
среднем “ 3,1 различных модулей Однако примерно для 10 %
программных модулей 2^4 > 6 Каждый функциональный модуль вы-
зывается в среднем из ~ 3.8 различных модулей. Встречаются
А. 7	'	.
('20 программные модули, у которых	6 Каждый функ-
циональный модуль использует глобальные переменные 10—20 наимено-
ваний; т е число таких переменных составляет 5—7 % от числа авто-
кодиых операторов.' Число переменных, которые считываются из памя
ти для обработки модулем, в среднем больше, чем число глобальных пе-
ременных, рассчитываемых и записываемых каждым модулем >
*	к
> Это естественно,^так как переменная перед считыванием всег-
91
да записывается и число записей не может превышать число считыва-
ний.
Стандартные программные модули относительно редко вызывают
другие программы, обычно (~ 75 %) такие программы только возвра-
щают Управление вызывавшим программам в результате ** QA
Однако в некоторых случаях стандартные программы вызывают другие
стандартные программы: в 20 % случаев « 2, а-в-5-% случаев
«3.	,
Стандартные программы по числу модулей, из которых они вызы-
ваются, можно разделить на две группы. В первой группируются ши-
роко применяемые стандартные программы для расчета простейших
функций; Эти модули вызываются из десятков видов различных функ-
циональных и стандартных программ 2аО « 20 4- 30. Во.вторуЮТруп-
пу входят программы, оформляемые как стандартные, одиако'предназ-
иачеииые для сравнительно-узкого применения «2-4-3. В рег
зультате распределение программ, вызывающих стандартные-програм-
мы, имеет два максимума: при « 2 и 30. Последняя величина' за-
висит от числа модулей в КП и в значительной степени определяется
общим числом проанализированных прн исследованиях программных
модулей.
Приведенные характеристики позволили выявить некоторые тенден-
ции сложности тестирования связей между модулями. Связи по управ-
лению, обеспечивающие вызовы других программных модулей, наибо-
лее просты между модулями нижних иерархических уровней. При по-
вышении иерархических уровней средняя величина возрастает и
/
имеет максимум, по-видимому,' для модулей высшего уровня. Если ие
учитывать возвраты управления, то число модулей, вызывающих i-й,
минимальное иа верхних уровнях иерархии и в среднем несколько
возрастает при снижении уровней. Это соответствует расширению об-
ласти применения модулей но мере снижения уровня иерархии и уп-
рощения их функций (более широко применяются стандартные програм-
мы). По числу информационных связей наиболее сложными являются
функциональные модули средних иерархических уровней. Программы
верхии*' н иижиих уровней характеризуются минимальными связями
попеременным. Для сложного КП объемом около 100 тыс. команд (500
модулей) суммарная сложность межмодульных связей, рассчитанная
по (2.13), достигает 10 тыс.
1J. ЗАТРАТЫ НА ТЕСТИРОВАНИЕ ПРОГРАММ
Общие оценки тестирования программ по показателю «эф-
фективность-стоимость». Экономика тестированйя программ
только недавно, начала развиваться, и наибольшие результаты
получены по. затратам и эффективности обнаружения ошибок
92
на этапе тестирования программных модулей. Наметились пу-
ти оценки затрат, необходимых для тестирования групп и ком-
плексов программ 1131. Эффективность тестирования специфи-
каций трудно оценивать вследствие относительно малого опыта
применения программных спецификаций, больших различий
их форм и состава, а также различий методов их применения и
тестирования. Затраты на испытания программных комплек-
сов в значительной степени зависят от ответственности
функций, выполняемых КП, требующейся корректности про-
грамм, возможности поэтапного выявления и устранения оши-
бок. Наибольшие затраты требуются для тестирования высоко-
надежных КП логического управления объектами разового и
кратковременного действия, например для управления косми-
. ческими аппаратами. Эта затрату могут на один-два порядка
превьппать затраты на тестирование сложных вычислительных
программ того же объема;
В ряде работ [13, 14, 34, 451 отмечалась большая доля за-
трат на отладку КП в совокупных затратах на его создание.
Там же приведены оценки затрат иа тестирование программ
как составляющей полных затрат на отладку. Эти характерис-
тики'иллюстрируют круговые дйаграммына рис. 2.9,о и б. Тес-
тирование на ранних этапах проектирования модулей и групп
программ требует более половины затрат на отладку программ
на этих этапах. По мере'снижения интенсивности обнаружения
ошибок и увеличения объема тестируемых программ возраста-
ет доля затрат на тестирование в общих затратах иа отладку.
При тестировании КП эта доля затрат достигает 90—95%, а при
тестировании программных изделий 95—99%. Интегрально по
всём этапам долю затрат на тестирование можно оценить на
уровне 70—80% от затрат иа отладку. Поэтому в некоторых
случаях затраты на тестирование можно оценивать совместно
с затратами на диагностику ошибок и корректировку программ
и не выделять нх из общих затрат на отладку.
Усложение методов генерации тестов и процесса тестирова-
ния по мере перехода от ручных методов к тестированию в ре-
альном масштабе времени приводит к возрастанию полных за-
трат на средства автоматизации тестирования( рис. 2,9, в).
Они включают затраты на создание средств автоматизации тес-
тирования и на их эксплуатацию. Последние в значительной
степени определяются стоимостью машинного времени, ис-
пользуемого для тестирования. В результате доля затрат на
средства автоматизации при отладке в реальном масштабе вре-
мени возрастает до 80—90% от общих затрат на тестирование.
Это означает, что только 10—20% затрат составляет труд
специалистов, осуществляющих непосредственную подготовку
S3
Проектирование КП	-Отладка КП	Тестирование программ
94
и анализ результатов тестирования на этом, этапе. ₽ целом для
сложных КП реального времени на автоматизацию всех эта-
пов тестирования приходится около'70% затрат и только при-
близительно 30% составляют затраты на непосредственных раз-
работчиков программ (см. рис. 2.9, г). Видимое сокращение
затрат труда программистов при применении автоматизиро-
ванных средств определило относительно низкую популяр-
ность ручных методов тестирования. В результате совокупные
затраты на тестирование в единицу времени монотонно возрас-
тают до стадии комплексной отладки в реалвйом времени и
только при испытаниях возможно нк некоторое снижение.
В- процессе разработки программ изменяется активность
применения различных методов тестирования и соответствен-
но относительные затраты на них. Одновременная разработка
многих компонент КП и различие этапов их тестирования,в
каждый момент приводят к тому, что активность применения
каждого из методов и средств тестирования в зависимости от
времени имеет размытые экстремумы (рис. 2.10, а). Кроме того,
почти на любой стадии создания КП в той или иной степени
используются несколько методов тестирования. В произволь-
ный момент времени А (рис. 2.10, а) могут быть необходимыми
затраты практически на все методы тестирования. При этом
отдельные программы еще проходят ручное и статическое те-
стирование, а часть КП может начинать тестироваться стоха-
стическими методами или в реальном времени. По мере разра-
ботки КП происходит постепенный переход к более сложным
методам тестирования’и соответственно возрастают затраты на
тестирование этими методами. На завершающих стадиях комп-
лексной отладки и испытаний КП эти методы становятся домиг
нирующими.
Затраты на тестирование способствуют повышению коррект-
ности, надежности и других показателей качества КП.- Одна-,
ко достигнутое в результате тестирования качество программ
трудно измерить непосредственно. Одним из наиболее простых
и удобных показателей качества тестирования программ явля-
ется интенсивность обнаружения ошибок в КП. При возраста-
нии объема тестируемых компонент увеличивается сложность
выявления ошибок и снижается интенсивность их обнаруже-
ния. Последовательное применение методов тестирования
обусловлено изменением их эффективности, которую можно ил-
люстрировать интенсивностью выявления ошибок каждым из
методов (рис. 2.10, б). На начальных этапах разработки, ког-
да в программе много простейших ошибок, наиболее активно
применяются ручные методы тестирования, которые Обеспечи-
вают высокую интенсивность выявления простейших ошибок
95
при относительно небольших затратах. Постепенно интенсив-
ность выявления ошибок этим методом падает и перестает оп-
равдывать затраты на его применение.
В отмеченном на рис. 2.10 временном сечении А имеется за-
метная интенсивность выявления ошибок почти всеми метода-
ми. Однако статическое и детерминированное тестирование ха-
рактеризуются низкой интенсивностью обнаружения ошибок,
которая падает быстрее, чем снижаются затраты на их исполь-
зование. При стохастическом тестировании и тестировани|1 в
реальном времени благодаря расширению областей варьиро-
Рис. 2.10. Зависимость затрат на тестирование программы (а) и ин-
тенсивности выявленных ошибок (б) различными методами от дли-
тельности разработки КП
96
Рис. 2.11. Зависимость интегральной
интенсивности обнаружении ошибок
в программах на единицу затрат
(-----) и изменения их качества
(надежности) (-------) от длитель-
ности разработки КП 
вания переменных и увеличению числа используемых тестовых
значений возрастает обнаруживающая способность тестов на
единицу затрат. Однако далее номере выявления и устранения
ошибок интенсивность их обнаружения также падает, что при-
водит к целесообразности снижения затрат сначала на стоха-
стическое, а затем на тестирование в реальном времени.
Таким образом, постепенная смена методов замедляет в не-
которой степени уменьшение интегральной интенсивности вы-
явления ошибок на единицу затрат (штриховая линия на
рис. 2.11), несмотря на значительное сокращение общего числа
невыявленных ошибок в КП. Высокоавтоматизированные до-
рогие методы тестирования позоволяют выявить небольшое чис-
ло трудно обнаруживаемых ошибок,' которые существенно
влияют на корректность и надежность программ (сплошная
линия на рис. 2.11). Ни один из методов тестирования при ав-
тономном применении не позволяет достигнуть высокого ка-
чества сложных КП при разумных затратах и только сбалан-
сированное последовательное их использование обеспечивает
значительное снижение совокупных затрат при создании про-
грамм. Целесообразно активное систематическое применение
простейших методов тестирования для выявления максималь-
но возможного числа ошибок самыми дешевыми методами на
ранних этапах проектирования.
Приведенный общий анализ эффективности-стоимости мето-
дов тестирования показывает пути оптимизации затрат на до-
стижение заданного качества программ. Однако для выполне-
ния такой оптимизации необходимы конкретные характеристи-
ки эффективности каждого метода тестирования и достигаемой
корректности или надежности разных классов программ в за-
висимости от затрат на использование этого метода. Такие ис-
следования 1 почти отсутствуют, что не позволяет провести ко-
личественный анализ эффективности-стоимости методой тес-
тирования. Имеются результаты некоторых частных оценок и
общие подходы к определению составляющих интегральных,
затрат на создание КП. Приведенные значения затрат являют-
ся приближенными иллюстративными оценками и могут зна-
4 Зак. 1061
97
чительно изменяться в зависимости от ряда факторов. Однако
при планировании разработки программ эти оценки можно ис-
пользовать как первичные ориентиры.
Для последующего анализа экономики тестирования про-
грамм можно выделить следующие задачи, для которых имеют-
ся конструктивные решения:
интегральные оценки затрат на проектирование и в том чис-
ле на тестирование КП, а также на средства автоматизации тех-
нологии;
оценка допустимых затрат на тестирование, обеспечиваю-
щих заданную надежность КП с учетом средств оперативной
помехозащиты;
оценка затрат на комплексную отладку и испытания про-
грамм, а также эффективности имитационно-моделирующих
стендов по сравнению с натурными экспериментами.
В ряде случаев затраты на тестирование трудно отделить от
общих затрат на отладку, и они анализируются совместно.
Интегральные оценки затрат на тестирование как доли зат-
рат на проектирование комплексов программ. Технология
проектирования сложных КП состоит из ряда частных этапов
157], большинство из которых может быть автоматизировано,
для чего необходимы соответствующие средства. Очевидно, что
разработка простейших программ может эффективно осуществ-
ляться по упрощенной технологии с малой автоматизацией.
Однако создание сверхсложных уникальных КП невозможно
без высокоавтоматизированной и четко формализованной тех-
нологии. В 157, 72] представлены этапы и задачи достаточно
полной современной технологии проектирования КП высокой
сложности. Автоматизация такой технологии требует больших
затрат и необходим анализ рентабельного уровня автомати-
зации технологии проектирования (и в том числе тестирова-
ния) КП различной сложности.
Значительная доля затрат как на создание сложных КП,
так и на средства автоматизации проектирования обусловлена
необходимостью-их тестирования. Поэтому проводимый далее
анализ интегральных затрат на проектирование программ це-
ликом относится к его значительной части — тестированию с
соответствующим сокращением доли затрат. Однако все ос-
новные соотношения могут использоваться практически пол-
ностью.
В качестве показателя экономической эффективности тех-
нологических систем можно рассматривать сумму затрат СХп
на проектирование (тестирование) КП и затрат С3а на созда-
ние и эксплуатацию технологических (тестирующих) систем.
При создании определенного КП с заданными функциональны-
98
ми характеристиками будем считать рентабельной такую техно-
логию, которая минимизирует суммарные затраты:
Cz .= (Gn + С3а) -> min.
В [37] проведен анализ и обоснованы соотношения, опреде-
ляющие затраты на непосредственное проектирование про-
грамм и на создание и эксплуатацию технологических систем.
Рассмотрим каждую составляющую и факторы, влияющие на
ее значения.
Затраты на проектирование С1П программ в первую очередь оп-
ределяют следующие факторы:
сложность самого КП (П), которую в первом приближении мож-
но отразить числом команд (П) в программе или объемом занимаемой
памяти;
степень использования ресурсов производительности f2 (р, Б), реа-
лизующей ЭВМ, которая зависит от реального быстродействия ЭВМ
(Б), ее загрузки (р), а также архитектуры многоуровневой памяти;
предполагаемый тираж КП N и широта его внедрения f3 (М);
уровень автоматизации технологии проектирования U программ
объемом П—ft(U, П).
Перечисленные факторы являются основными и могут быть объек-
тивно измерены н учтены. Кроме представленных имеется еще ряд фак-
торов, которые меньше влияют на суммарные затраты или значитель-
но трудней измеряются я учитываются (квалификация и организация
коллектива разработчиков, тип н характеристики реализующей ЭВМ,
регламентированность технологии и т.д.). Эти второстепенные факторы
в последующих зависимостях отражаются неявно коэффициентами а4,
значения которых необходимо уточнять по данным аналогичных реаль-
ных разработок.
В зависимости от объема разрабатываемого комплекса П (выражен-
ного числом команд иа автокоде), уровня автоматизации проектирова-
ния U и предполагаемого тиража программ N затраты на разработку
войдут в каждый экземпляр КП:
С1П = а1п nig/7[l-exp(-O,2M)12-^	(2. 14)
/V
Обоснование этого выражения представлено в [37). Выражение полу-
чено путем аппроксимации составляющих /1(Д);/2(р, Б); /3 (М) и ft(U,
П), определяющих затраты С1п простыми аналитическими выражениями.
Считается, что программы функционируют в реальном масштабе
времени при постоянной загрузке р = 0,9, которая учтена в значениях
а1п, характеризующих стоимость (в рублях) проектирования одной ко-
манды в уникальном КП при ,иеавтоматизйрованиой технологии
((7 = 0). Тогда а1п = 10 -г 30 при средней стоимости одной команды
около 20 руб. Приближенно уровень автоматизации можно характери-
зовать сложностью технологических программных средств, выражен-
ной числом команд и совокупной стоимостью этих средств. Для
классификации целесообразно использовать логарифмическую шкалу
сложностей технологических систем автоматизация, что приблизитель-
но соответствует линейному приросту производительности труда при
их использовании. Значения уровней автоматизации проектирования
отражаются целыми числами (7 = 0 — 4, соответствующими объемам
4*
99
программ технологических систем от 10* до 10е команд иа ассемблере,
выраженным через U как показатель степени (100-Ю17).
Технология проектирования и средства ее автоматизации обычно'
создаются для многократного и длительного применении при проекти-
ровании программ различного назначения. Широкое применение оп-
ределенных средств автоматизации технологии сокращает длитель-
ность их окупаемости и долю стоимости, которую необходимо учиты-
вать в эксплуатируемых программах. Основными факторами, опре-
деляющими затраты Сзв на разработку и зксплуатацию технологиче-
ских средств автоматизации проектирования в каждом экземпляре
КП, являются:
затраты на создание и внедрение инструментальных и методиче-
ских технологических средств ft (U), определяющиеся уровнем авто-
матизации технологии проектирования программ О;
доля затрат (N), зависящая от широты использования данного
КП, т. е. от числа «ропий программ N в установочной серии Или за весь
период использования технологии;
доля затрат, зависящая от применения дайной технологии (Л4Т)
для проектирования КП различных типов и наначеиия с общим числом
созданных типов М, за период использования технологии или за неко-
торый нормативный срок;
затраты на эксплуатацию и обслуживание технологическихсредств
/е (тн. U) в процессе проектирования данного КП в течение календар-
ного иремени разработки ти.
В каждый экземпляр созданного КП затраты на разработку и экс-
плуатацию технрлогии входят долей Сзв, которая зависит [57] от уров-
ня автоматизации U, тиража созданного КП N, длительности тк ис-
пользования технологической системы в процессе разработки данно-
го КП и числа Мг различных проектов программ (тиражность техноло-
гической системы), созданных с использованием этой технологической
системы
Сзв ”ЧП + С'зп = ft (N) I, (t„, U)/N =
(2.15)
• где at № 100 (50 4- 300) руб., a, ~ 25 (10 -г 100) руб./ч. В этом вы-
ражении обычно доминирует одно из слагаемых. При создании уни-
кальной сложной технологической системы для проектирования кон-
кретного КП основное значение имеют затраты иа ее разработку (Сзп).
Если заимствуется широко применяемая технологическая система, то
основную роль играют затраты на ее эксплуатацию (Сзп), так как за-
траты на разработку войдут только А1т-й частью.
Длительность использования технологической системы ти, а сле-
довательно, и затраты Сзп зависят от • сложности- создаваемого КП.
В первом приближении можно предположить, 4to при фиксированном
уровне U значение ти прямо пропорционально объему программ П,
т. е. тк = Тк/7. Для проверки этой гипотезы были*определены реальные
затраты машинного времени на фуикциоиироваиие технологических
систем (с учетом их уровня) при создании 13 комплексов программ двух
классов: объемом около 10 тыс. команд и около 100 тыс. комаяд каж-
дый. Для определения коэффициента пропорциональности тк по каж--
дому КП оценены удельные затраты машинного времени на 1 коман-
ду. Полученные значения скорректированы с учетом уроиней автома-
*= а# ~ л/"лл~ + а» ти U/Л/,
N/rhg
100
тизации используемых при разработке технологических средств (при-
ведены к первому уровню), так как зависимость стоимости эксплуата-
ции технологической системы от уровня ее автоматизации в формуле
(2.!5) уже учтеиа. Далее было оценено среднее значение затрат машин-
ного времени на одну команду тк « 0,07 ч/ком.
Оценки эффективности автоматизации технологии проектирова-
ния программ.. Приведенные соотношения (2.14) и (2.15) позволяют оце-
нить ожидаемые суммарные затраты на создание определенного КП при
использовании некоторой технологии. Кроме того, можно определить'
уровень технологии, обеспечивающий минимум затрат при создании
КП заданного объема с учетом его тиража и широты применения тех-
нологии. Рассмотрим затраты при проектировании относительно про-
стых (П = 104) и особо сложных КП (П — 10е). Предположим, что тех-
нологическая система создается для проектирования единственного
КП (Л4Т « 1) или применяется при создании ряда проектов (МТ — 10
и 1,00). Значения приведенных выше коэффициентов следует рассматри-
вать только как примеры и не применять как реальные нормативы.
Разработка относительно небольших КП (П = 10*) целесообраз-
на (рис.'2.12) на базе простейших (И = I—2) уникальных (Л4Т = 1)
технологических средств или с использованием высокоавтоматизи-
рованной технологической системы (U = 3)' широкого применения
(Л4Т 10 -г 100). Этим сочетаниям параметров соответствует минимум
суммарных затрат и рростые резндент-снстемы на микро-ЭВМ (U— 1
или 2) или сложные адаптируемые кросс-системы на универсальных
технологических ЭВМ (U = 3). Тиражность создаваемых КП почти
одинаково (обратно пропорционально N) влияет на изменение затрат
С1П и С8П. Однако в С1п величина тиража N входит не только в знамена-
тель, но и в числитель, изменяя значения С1п в 3—5 раз при изменениях
N на порядок. Поэтому абсолютные значения суммарных затрат в за-
висимости от N могут отличаться в неколько раз, хотя оптимальное ,
значение уровни автоматизации U относительно мало изменяется в за-
висимости от N.
Для создания особо сложных КП (П = 10е) эффективны (рис. 2.13)
кросс-системы широкого^’применения (Л4Т = 10 4- 100) с высоким
уровнем автоматизации технологии' (U = 4). Однако значении Сэп,
малые относительно С1п, могут,быть получены и при создании уникаль-
ных (AfT s= 1) резидент-систем с уровнем автоматизации технологии,
близким к 3. При разработке сложных программ наиболее эффективны
резндент-системы широкого применения с V — 4, которые, в частно-
сти, могут компоноваться на базе штатных операционных систем' уни-
версальиых ЭВМ. В промежуточном случае при П,— 10е оптимальные
уровни автоматизации располагаются между вторым и третьим. При
этом целесообразны высокоавтоматизированные резидент- или кросс-
системы, которые желательно применять во многих заказах. (Л4,= 10 —
4- 100).	' 	'
Следует обратить внимание на то, что приведенные графики по-
строены в логарифмическом масштабе по оси ординат и визуально по-
логим характеристикам соответствуют1‘изменения затрат в несколько -
раз. При этом абсолютные значения затрат на создание каждого слож-
ного (77 яа 10е) КП составляют около 1 млн. руб? Широкое тиражиро-
вание программ позволяет почти пропорционально распределить сум-
марные затраты на разработку по всем экземплярам КП. Затраты на
разработку технологических систем (Сзп) особенно сильно отражаются
при создании относительно небольших программ (см. рис. 2.12). Для
особо сложных КП (см рис. 2.13) при высоком уровне автоматизации
101
программ технологических систем от 10я до 10я команд на ассемблере,
выраженным через U как показатель степени (100-10^).
Технология проектирования и средства ее автоматизации обычно
создаются для многократного и длительного применения при проекти-
ровании программ различного назначения. Широкое применение оп-
ределенных средств автоматизации технологии сокращает длитель-
ность их окупаемости и долю стоимости, которую необходимо учиты-
вать в эксплуатируемых программах. Основными факторами, опре-
деляющими затраты Сза на разработку и эксплуатацию технологиче-
ских средств автоматизации проектирования в каждом экземпляре
КП, являются:
затраты иа создание и внедрение инструментальных и методиче-
ских технологических средств /в (U), определяющиеся уровнем авто-
матизации технологии проектирования программ £/;
доля затрат /, (N), зависящая от широты использования данного
КП, т. е. от числа фопий программ JV в установочной серии или за весь
период использования технологии;
доля затрат, зависящая от применения дайной технологии /7 (Л)т)
для проектирования КП различных типов и наиачения с общим числом
созданных типов М, за период использования технологии или за неко-
торый нормативный срок;
затраты на эксплуатацию и обслуживание техиологическях-средств
ft (Kt, У) в процессе проектирования данного КП в течение календар-
ного времени разработки тк.
В каждый экземпляр созданного КП затраты на разработку и экс-
плуатацию технрлогии входят долей Сзп, которая зависит [57] от уров-
ня автоматизации U, тиража созданного КП N, длительности тн ис-
пользования технологической системы в процессе разработки данно-
го КП и числа МТ различных проектов программ (тнражность техноло-
гической системы), созданных с использованием этой технологической
системы
С»п“Сзп + С^1=/»(<У)Я«(Л,)^(Л’т)+7.(Тк.	=
• nV
_J£^--]-a,TKUyW,	(2.15)
где at я» 100 (50 -г 300) руб., a, ~ 25 (10 4- 100) руб./ч. В этом вы-
ражении обычно доминирует одно из слагаемых. При создании уни-
кальной сложной технологической системы для проектирования кон-
кретного КП основное значение имеют затраты иа ее разработку (Сзп).
Если заимствуется широко применяемаи технологическая система, то
основную роль играют затраты на ее эисплуатацию (Сзп), так май за-
траты на разработку войдут только Мч-й частью.
Длительность использования технологической системы ти, а сле-
довательно, и затраты Сэп зависят от сложности создаваемого КП.
В первом приближении можно предположить, что при фиксированном
уровне U значение ти прямо пропорционально объему’ программ П,
т. е. тк = т*/7. Для проверки этой гипотезы были-определены реальные
затраты машинного времени иа функционирование технологических
систем (с учетом их уровня) при создании 13 комплексов программ двух
классов: объемом около 10 тыс. команд и около 100 тыс. команд каж-
дый. Для определения коэффициента пропорциональности тк по каж-
дому КП оценены удельные затраты машинного времени на 1 коман-
ду. Полученные' значения скорреитированы с учетом уровней автома*
100
тизании используемых при разработке технологических средств (при-
ведены к первому уровню), так как зависимость стоимости эксплуата-
ции технологической системы от уровня ее автоматизации в формуле
(2.15) уже учтена. Далее было оценено среднее значение затрат машин-
ного времени иа одну команду тк та 0,07 ч/ком.
Оценки эффективности автоматизации технологии проектирова-
ния программ.,Приведенные соотношения (2.14)'и (2.15) позволяют оце-
нить ожидаемые суммарные затраты на создание определенного КП при
использовании некоторой технологии. Кроме того, можно определить
уровень технологии, обеспечивающий минимум затрат при создании
КП заданного объема с учетом его тиража и широты применения тех-
нологии. Рассмотрим затраты при проектировании относительно про-
стых (77 = Ю4) и особо сложных КП (77 = 10е). Предположим, что тех-
нологическая система создается для проектирования единственного
КП (Л1т =* 1) или применяется при создании ряда проектов (Л1Т = 10
и 100). Значения приведенных выше коэффициентов следует рассматри-
вать только как примеры и ие применять как реальные нормативы.
Разработка относительно небольших КП (П = 10*) целесообраз-
на (рнс. 2.12) на базе простейших (I/ = 1—2) уникальных (AfT = 1)
технологических средств или с использованием высокоавтоматизи-
рованной технологической системы (U — 3)' широкого применения
(Мт =' 10 -т- 100). Этим сочетаниям параметров сбответствует минимум
суммарных затрат н простые резидент-снстемы на микро-ЭВМ (U— 1
или 2) или сложные адаптируемые кросс-системы на универсальных
технологических ЭВМ (U — 3). Тиражиость создаваемых КП почти
одинаково (обратно пропорционально N) влияет на изменение затрат
С1П и Сеп. Однако в CUI величина тиража N входит не только в знамена-
тель, но и а числитель, изменяя значения С1п в 3—5 раз при изменениях
N на порядок. Поэтому абсолютные значения суммарных затрат в за-
висимости от N могут отличаться в неколько раз, хотя оптимальное
значение уровня автоматизации U относительно мало изменяется в за-
висимости от N.
Для создания особо сложных КП (П = 10е) эффективны (рис. 2.13)
кросс-системы широкого ’применения (Л4Т = 10 — 100) с высоким
уровнем автоматизации технологии (U = 4). Однако значения Сзп,
малые относительно С1п, могут,быть получены и при создании уникаль-
ных (Л1Т = 1) резидент-си стем с уровнем автоматизации технологии,
близким к 3. При разработке сложных программ наиболее эффективны •
резидент-системы широкого применения с U — 4, которые, в частно-
сти, могут компоноваться на базе штатных операционных систем'уни-
версальиых ЭВМ. В промежуточном случае при 77 = 10е оптимальные
уровни автоматизации располагаются между вторым и третьим. При
этом целесообразны высокоавтоматизированные резидент- или кросс-
системы, которые желательно применять во многйх заказах (7ИТ = 10 —
-г- 100).	 	'	•
Следует обратить внимание на. то, что приведенные графики по-
строены в логарифмическом масштабе по оси ординат и визуально по-
логим характеристикам соответствуют изменения затрат в несколько -
раз. Прн этом абсолютные значения затрат на создание каждого слож-
ного (П та 10е) КП Составляют около 1 мли. руб. Широкое тиражиро-
вание программ позволяет почти пропорционально распределить сум-
марные затраты на разработку по всем экземплярам КП- Затраты на
разработку технологических систем (Сзп) особенно сильно отражаются
при создании относительно небольших программ (см. ,ряс. 2.12). Для
особо сложных КП (см рнс. 2.13) при высоком уровне автоматизации
101

Рис. 2.12. Зависимость затрат на проектирование	Рис. 2.13, Зависимость затрат на проектирование
комплекса программ Cm (-•-), на разработку и экс-	комплекса программ С)п (------), иа разработку и
плуатацню технологической системы Сзп (— — —) и	эксплуатацию технологической системы Csn (--)
суммарных затрат С2/ (—-—) от уровня автома- -	и суммарных затрат С (-—) от уровня автома-
тизации технологии при /7=»=10‘ команд и тк = 700 ч	тизаиии технологии /7=»10б команд и тк=г70000 ч
102
доминируют затраты Сзп на эксплуатацию технологических систем.
При этом на оптимальное значение уровня автоматизации особенно
сильно влияют удельные затраты на машинное время т*. Снижение этой
величины в 1,5—2 раза смещает оптимум в сторону высокоавтоматизи-
рЬваниых систем, и для особо сложных программ (П = 10е)' наиболее
эффективными становятся технологические системы с V = 4.
Широкое применение технологических систем (Л4Т » 10	100)
значительно ёнижает затраты на технологию (рис. 2.12) и позволяет
даже при создании относительно небольших КП эффективно применять
высокоавтоматизированные универсальные технологические системы.
Для этого системы должны иметь возможность достаточно просто адап-
тироваться к условиям применения и к специфике реализации конкрет-
ного проектируемого КП. Такими универсальными адаптируемыми сиг
стемами могут быть кросс-системы, реализованные иа мощных универ-
сальных ЭВМ. Затраты на создание таких кросс-систем могут быть рен-
табельными Даже в том случае, если они в десятки раз превышают за-
траты на непосредственное проектирование каждого КП [37, 57].
Применение резидент-систем для микро-ЭВМ зачастую ограни-
чено (Л4Т ~ 1), в этих случаях целесообразно, чтобы затраты на их
создание не превышали затратна проектируемый КП. Поэтому резндёнт-
снстемы либо должны автоматизировать только минимум необходимых
технологических функций (U = 1 или 2), либо использоваться в со-
четании с кросс-системами. В последнем случае на микро-ЭВМ-целе-
сообразно реализовывать средства автоматизации комплексной отлад-
ки, а все основные компоненты технологической системы базировать
в виде кросс-системы на универсальной ЭВМ.
Принятые при анализе значения коэффициентов а1п, а8 могут
в реальных условиях отличаться В 3—4 раза от использованных при
оценках. Однако варьирование этих коэффициентов относительно сла-
бо влияет на уровни автоматизации технологии, соответствующие ми-
нимальным, затратам. Это объясняется в первую очередь тем, что в вы-
ражениях (2.14) и (2.15) основные параметры изменяются на один-
два порядка, 11 поэтому определяют как абсолютные значения затрат,
так и уровень автоматизации, соответствующий их минимуму.
Приведенные графики могут служить ориентирами при предва-
рительном анализе эффективности разработки и применения различ-
ных типов систем автоматизации технологии проектирования (в част-
ности, тестирования) программ. Для более точного анализа целесооб-
разно определять значения коэффициентов по опыту реальных разра-
боток в данной организации и выбирать значения параметров, соот-
ветствующие конкретному проекту (5/]. Рассмотренный метод оптими-
зации затрат не учитывает длительность разработок. В ряде случаев
важнейшую роль играют сроки создания КП н. может быть допустимым
некоторое повышение затрат, обеспечивающее сокращение длительно-
сти разработки. Эти обстоятельства приводят к целесообразности при-
менения более высоких уровней автоматизации проектирования по
сравнению с теми, которые обеспечивают только минимум суммарных
затрат.
Затраты иа проектирование тестов и подготовку их к исполне-
нию, а также на анализ результатов тестирования возрастают по мере
усложнения тестируемых компонент программ. В среднем эта доля за-
трат составляет 70—80 % от С1п (см. рис. 2.9). Таким обазом, приве-
денные результаты можно использовать практически полностью для
оценки эффективности технологий отладки и тестирования. При этом
достаточно умножить масштабы всех характеристик по оси ординат на
коэффициент, примерно равный 0,7—0,8.
W3
Допустимые затраты на тестирование, обеспечивающие за*
данную надежность комплексов программ. Трудность прямого
измерения качества программ привела к оценкам допустимых
затрат на тестирование на базе использования математических
моделей описания характеристик ошибок в программах
(см. § 1.2). При этом тестирование производится до тех пор, по-
ка затраты на обнаружение очередной ошибки или длитель-
ность тестирования для ее выявления не превысят заданный
порог. Этому порогу соответствуют некотЬрые значения кор-
ректности н надежности программы, которые
предполагаются достаточными для успешной эксплуатации.
Последующие затраты на тестирование считаются нерентабель-
ными, и тестирование прекращается.
В КП, осуществляющих обработку информации и управле-
ние в реальном масштабе времени, влияние программных оши-
бок может быть значительно снижено за счет оператив-
но г а рестарта программ прй появлении аномаЛий в их
функционировании. В системах реального времени это соответ-
ствует тестированию с целью достижения определенной надеж-
ности функционирования КП. Необходимая надежность функ-
ционирования КП может достигаться высокими затратами на
тестирование, что допускает, соответствующее снижение затрат
на средства обнаружения искажений и восстановление, или за
счет высокой эффективности средств оперативного контроля и
восстановления (рестарта), что позволяет быстрее получать на-
дежные, но менее отлаженные программы.	’
Анализ можно проводить по критерию коэффициента готов-
ности или по критерию наработки на отказ 1321.' Первая задача
. состоит с определении минимальных суммарных затрат на тес-
тирование, обеспечивающих заданную вероятность возникно-
вения и обнаружения отказовой ситуации или проявления
ошибки в программе 136). Вторая задача непосредственно свя-
зана с анализом затрат-, обеспечивающих заданную надежность
..КП или наработку на Отказ Ти. В этом случае учитываются
пороговое время восстановления /д и влияние средств рестарта
на показатели надежности функционирования программ. При
этом не каждая отказовая ситуация, обусловленная ошибкой в
программе, учитывается в показателе надежности, а только те,
которые приводят к полному отказу.
Длительность тестирования т обычно оценивается по чистому вре-
мени функционирования программ, когда проявляются и регистри-
руются ртказовые ситуации и ошибки. Для определения календарного
времени тн проведения работ по тестированию и отладке и полных вре-
менных затрат на обнаружение н устранение ошибок значения т долж-
ны быть увеличены. В этом случае к затратам на непосредственное' тес-
тирование добавляется время локализации ошибки, длительность под-
104 .
готовки и реализации исправления, а также время на проверку правиль-
ности проведенной корректировки. По мере повышения наработки на
отказовую ситуацию доля затрат времени на непосредственное .тести-
рование возрастает относительно длительности работ ти с учетом устра-
нении причин, вызвавших конкретную отказовую ситуацию. На эта-
пах автономной и в начале комплексной отладки 'соотношение между
временем устранения причин отказовых ситуаций и наработкой на от-
казовую ситуацию хк = тк/т достигает хк « 100 (34]. При завершении
комплексной отладки в реальном времени относительные затраты на ло-
кализацию и корректировку ошибок значительно сокращаются и
т-»тк, т. е. хн -> 1.
Предположим, что в процессе тестирования усилия на его выпол-
нение ие изменяются и пропорциональны машинному времени испол-
нения тестируемых нрограмм т с коэффициентом хк. Это допущение со-
ответствует сохранению состава используемых средств и коллектива
специалистов, проводящих отладку на всех этапах ее выполнения.
Значения времени 7 (см. § 1.2) соответствуют интервалам между про-
явлениями ошибок .и вознйкиовениями отказовых ситуаций при непре-
рывном функциоиированни программ. Для определения затрат на от-
ладку при заданной наработке иа отказовую ситуацию Т следует опре-
делить соответствующее время тестирования т и далее рассчитать за-
траты иа отладку. Предварительно экспериментально необходимо опре-
делить, например, по(1.6) интенсивность выявления ошибок К, исполь-
зуемую в выражении (1.4), и экспериментально оценить реальный ко-
эффициент возрастания суммарных затрат хк на данном этапе. Зна-
чения К и хк зависят в основном от степени автоматизации технологии
тестирования и отладки программ н могут значительно изменяться в
зависимости’ от объема н сложности проектируемых КП.
Естественно предположить (32, 50], что отказовые ситуации об-
разуют пуассоновский поток, а длительность восстановления распре-
делена экспоненциально. В (36] рассмотрены практически важные слу-
чаи для программ, когда показатели надежности велики, а период
контроля /' н средняя длительность восстановления 1а.малы по срав-
нению с наработкой на отказовую ситуацию 7. Тогда для фиксирован-
ного значения порогового времени tn между сбоем н отказом (см. § 2,1)
можно рассчитать наработку иа полный отказ 7И и коэффициент готов-
ности дг в системе с оперативным рестартом.
Задаваясь либо допустимой длительностью отладки, либо наработ-
кой иа отказовую ситуацию, либо, наконец, суммарными затратами и*
тестирование н рестарт, можно определить остальные параметры, влияю-
щие на надежность, программ, а также наработку ма отказ и коэффи-
циент готовности прн этих параметрах. Практически обычно необхо-
димо решение обратной задачи, когда для заданных значений 7К или
Кт определяются суммарные затраты Сх, наработка иа отказовую си-
туацию И соответствующая им длительность отладки тк. При этом воз-
можно варьирование периода контроля что Непосредственно опре-
деляет среднюю величину простоядо обнаружения отказовой ситуа-
ции. При изменении эффективности средств рестарта это отражается
на среднем времени восстановления Ц.
Явные выражения для расчета затрат на тестирование и на рестарт
программ отсутствуют, кроме того, большее количество варьируемых
параметров затрудняет анализ~приВедеиных соотношений в общем виде.
Поэтому такие исследования проведены для случаев, когда параметры
изменяются в областях значений, наиболее характерных для проекти-
рования реальных КП. В. [36] показано, что при /Д=Ю73 прак-
105
тически все отиаз9вые ситуации квалифицируются как кратковремен-
ные сбои и наработка на отказ возрастает на два-три порядка относи-
тельно наработки на отказовую ситуацию. При- /я ял 3/s наработка на
отказ Ти возрастает на порядок по сравнению с Т, а при < /8 зна-
чения Т„ н Т отличаются мало. Аналогичные зависимости характерны
и для изменения коэффициента готовности. Наиболее резкое изменение
Кг происходит при тех же соотношениях между/д и73, что и для нара-
ботки на отказ Тв.
Таким образом, при относительно небольших затратах на опера-
тивный рестарт программ реального времени может быть значительно
повышена надежность их функционирования. При этом в программе ос-
таются ошибки, не выявленные при тестировании, которые приводят к
отказовым ситуациям. Однако быстрое устранение последствии этих
ситуаций приводит к явлениям, эквивалентным кратковременному сбою
при функционировании, не влияющим на показатели надежности про-
грамм. В результате затраты на тестирование могут быть значительно
ниже по сравнению со случаем, когда та же надежность программ дости-
гается только отладкой без применения средств оперативного рестарта.
Затраты на комплексную отладку и испытания программ
реального времени. По мере расширения условий тестирова-
ния у увеличения объема данных, содержащихся в тестах, воз-
растает необходимость автоматической генерации тестов и об-
работки результатов тестирования. Исходные данные в тестах
должны отражать функционирование реальных объектов во
всем диапазоне изменения их характеристик. Выработка та-
ких тестовых данных может осуществляться с применением:
реальных объектов-источников информации в соответст-
вующих режимах функционирования;
аналоговых и аналого-цифровых имитаторов, функцио-
нально подобных реальным объектам;
имитационных стендов на базе цифровых ЭВМ, содержа-
щих программные модели имитации исходных данных внешних
абонентов.
В последние годы аналоговые и аналого-цифровые имитато-
ры несколько уменьшили свое значение, прежде всего вследст-
вие их глубокой специализации и сложности адаптации при из-
менении имитируемых объектов. Поэтому ниже анализируют-
ся и сопоставляются затраты на подготовку тестовых данных
при использовании реальных источников информации и при
применении комплексных имитационно-моделирующих стен-
дов (КИМС> на базе ЭВМ. Такие стенды могут создаваться на
основе универсальных ЭВМ с аппаратурой вывода данных в те-
лекодовые линии связи или непосредственно иа ЭВМ, реали-
зующих тестируемые программы 157, 591.
Наиболее наглядна экономическая эффективность примене-
ния программных имитаторов тестов для комплексной отладки
КП, функционирующих в реальном масштабе времени. В этом
*06'
случае имитаторы генерируют всю информацию внешних або-
нентов, реальное функционирование которых для проведения
тестирования КП требует значительно больших затрат.
Эффективность применения программных имитаторов для тес-
тирования КП в реальном масштабе времени определяется сле-
дующими факторами:
сокращением экономических затрат на подготовку тестовых
данных, отражающих функционирование внешних абонентов,
по сравнению с натурными экспериментами;
расширением диапазона характеристик имитируемых або-
нентов за пределами реально существующих объектов и воз-
можностью генерирования тестов, отражающих перспективные
характеристики создаваемых систем;
возможностью создания тестовых данных, соответствую-
щих критическим или опасным ситуациям функционирования
внешних объектов, которые невозможно реализовать при на-
турных экспериментах [112];
высокой повторяемостью генерируемых тестовых данных
при заданных условиях тестирования КП и возможностью вре-
менного прекращения тестирования на любых фазах;
возможностью длительного генерирования тестов для оп-
ределения характеристик надежности функционирования
КП.
Эффективность тестирования программ с применением ими-
тационных стендов прежде всего определяется соотношением
затрат на генерацию совокупности тестовых данных при ис-
пользовании реальных объектов и при применении комплекс-
ных имитационно-моделирующих стендов. Кроме того, эф-
фективность стендов можно оценивать по степени расширения
условий и значений параметров, при которых тестируются про-
граммы в процессе комплексной отладки и испытаний. Поэто-
му при сравнении двух способов генерации тестовых данных
необходимо учитывать не только различие затрат при одинако-
вых тестах, но также возможность изменения объема тестиро-
вания и достигаемой корректности и надежности КП.
Затраты на генерацию тестовых данных Сп при исполь-
зовании реальных объектов прямо пропорциональны реаль-
ному времени их функционирования при проведении ком-
плексной Отладки и испытаний
С„ (Xi,x3, ...,xn)tn.
Множитель f (хь х2, ..., хп) является' коэффициентом, оп-
ределяющим стоимость эксплуатации реального объекта, соз-
дающего тесты в единицу времени, например затраты на функ-

ционирование прокатного стана или системы управления воз-
душным движением. В некоторых случаях / (хх, х2, хп)
может быть сложной функцией .числа привлекаемых объектов
xit создающих внешнюю среду, н типов источников информа-
ции, участвующих в эксперименте. Например, при тестирова-
нии программ управления воздушным движением в зоне аэро-
порта f (хь ха, ..., хп) является сложной функцией характерис-
тик воздушных объектов, привлекаемых к эксперименту., со-
седних пунктов обработки информации о воздушной обстанов-
ке и диспетчерских постов управления воздушным движением
в данном аэропорту. Таким образом, вид этой функции и ее
конкретные значения необходимо оценивать каждый раз непо-
средственно по затратам в единицу времени на функциониро-
вание объектов, являющихся источниками информации..
Затраты на имитацию тестовых данных с использованием
КИМС соответствуют затратам на проектирование и эксплуата-
цию сложных КП и определяются следующими составляющи-
ми:
затратами на проектирование программ имитации информа-
ции внешних абонентов и среды их функционирования;
затратами на эксплуатацию программ имитации за время
проведения комплексной отладки и испытаний тестируемого-
КП;
затратами на первичную установку и эксплуатацию ЭВМ и
вспомогательного оборудования, используемого в КИМС.
Перечисленные затраты на программное обеспечение для
имитации тестов могут быть оценены по формулам (2.14) и
(2.15). При расчетах следует учитывать некоторые особенности
КП для имитации тестовых данных. В большинстве случаев
Имитаторы создаются на базе универсальных ЭВМ с развитым
технологическим программным обеспечением. Для создания
имитирующих программ, как правило, применяются апроби-
рованные технологические системы, поэтому при оценках нуж-
но учитывать только затраты на эксплуатацию и обслужива-
ние технологических средств С'п. Имитационные стенды прак-
тически всегда являются уникальными (N = 1) и достаточно
полно используют ресурсы имитирующей ЭВМ (р « 0,9/.
Эти комплексы программ, могут иметь объем порядка 106 —10е
команд и должны проектироваться с применением современных
технологических систем (U « 34-4).
Затраты на эксплуатацию программ имитации определя-
ются длительностью проведения комплексной отладки и испы-
таний
С1Э = «1Л + «гЛ-
108
Коэффициенты ctjg и cija соответствуют стоимости машин-
ного времени имитирующей ЭВМ и стоимости обслуживании
версии имитационных программ в единицу,времени. Обычно до»
минирует коэффициент Oi3, значение которого равно 10—
100 руб./ч. Значение времени ta, так же как и выше, соответ-
ствует реальному времени генерации тестовых данных и тес-
тирования программ.
Затраты на эксплуатацию ЭВМ, используемой в КИМС, в
основном учитываются величиной С1В. Первичные затраты на
закупку и установку оборудования, необходимого для имита-
ции тестовых данных, включают стоимость имитирующей ЭВМ
и устройств сопряжения имитационного стенда с ЭВМ, на кото-
рой функционирует тестируемые программы. Эти затраты за-
висят от задач имитации и мощности ЭВМ, которая необходи-
ма для их реализации.
При создании КИМС значительные сомнения возникают в
рациональности капитальных затрат на оборудование и про-
граммное обеспечение. При суммировании перечисленных за-
трат следует учитывать, что годовые затраты на капитальное
оборудование обычно получаются с учетом длительности его
использования (8—12 лет), соответствующей, периоду мораль-
ного износа электронного оборудования. Первичные затраты на
разработку программ имитаторов можно относить к этому же
интервалу времени или, учитывая программную совмести-
мость ЭВМ, на которых реализуется КИМС (например, поко-
ление ЕС ЭВМ), — к длительности жизни КП, для тестирова-
ния которого создавался стенд (10—20 лет). Обычно КИМС при-
меняется для тестирования нескольких КП разного целевого
назначения. При этом используется единая аппаратура и неко-
торая часть унифицированного программного обеспечения
имитаторов. В результате затраты на 'имитационный стенд и
на часть его программ необходимо разделить на соответствую-
щее число проектов тестируемых КП. Таким образом,,можно
оценить суммарные ежегодные затраты на имитацию тестов на
базе КИМС для одного проекта КП. В результате удельные за-
траты на создание и эксплуатацию стендов быстро убывают при
унификации имитаторов и расширении области их применения
для тестирования большого числа КП в течение их жизненного
цикла.
Приведенные выражения позволяют оценить затраты на
имитацию Сс и сопоставить их с затратами на подготовку
тестовых данных при реальном функционировании объектов
Сгт. При тестировании КП для управления воздушным движе-
нием применение имитационных стендов на порядок снижает,,
затраты по сравнению с натурными экспериментами и йсполь-
109
зованием реальных объектов, а для управления космическими
аппаратами еще больше (Сгт/Сс > 10). Эффективность стен-
дов возрастает по мере развития КП при создании очередных
версий, так как снижается Доля первичных затрат'на создание
аппаратуры и программ имитации. В пределе эффективность
применения имитаторов приближается к отношению затрат в
единицу времени на функционирование реальных объектов
f (*х, Хг, .... Х„) и на имитацию тестовых данных а13 в тех же
условиях.
Выше считалось,, что подготовка тестовых данных на базе
реальных объектов и стендов производится в одиндковых усло-
виях и полностью аналогична по объему. Однако применение
имитационных стендов позволяет значительно рас-
ширить область изменения тестовых
д а н и ы х, а тем самым повысить корректность и надежность
тестируемых программ. Например, в системах управления воз-
душным движением в реальных условиях трудно и рисковано
создавать ситуации перегрузки аэропорта по числу управляе-
мых самолетов и опасно -создавать ситуации значительного
сближения самолетов для проверки критических условий по
безопасности движения, которые достаточно просто имитиру-
ются.
Для оценки эффективности имитации целесообразно стро-
ить диаграммы пространства изменения характеристик исход-
ных данных, которые могут быть реально созданы в настоящее
время и в перспективе в соответствии с техническим заданием.
В этом пространстве отображаются области изменения пара-
метров, которые при имеющихся ресурсах могут быть'охвачены
в натурных экспериментах и при имитации. Отношение много-
мерных (в соответствии с числом параметров) объемов этих об-
ластей характеризует достигаемое соотношение корректности
-программ в процессе тестирования. Соотношение надежностей
тестируемых программ можно более полно оценивать, если учи-
тывать не только размеры областей изменения параметров, но
и распределения вероятностей значений каждого параметра в
этих областях для реальных объектов. Некоторые ситуации не
только трудно создать при натурных экспериментах, ио они
маловероятны в реальных условиях. Такие ситуации могут
практически не влиять на надежность функционирования про-
веряемых» программ.
При оценках эффективности имитационных стендов необ-
ходимо учитывать возможные затраты на получе-
ние эталонных данных о внешней обстановке.
Например, для испытаний точности сопровождения воздуш-
ных объектов в зоне аэропорта необходимо с высокой точностью
110
измерять эталонные координаты объектов. Для этого могут
привлекаться специальные, особенно точные, радиолокацион-
ные станции или оптические измерители. Регистрация и обра-
ботка получаемых данных требует значительных затрат. Эта
же задача на имитационных стендах решается значительно про-
ще, так как эталонные' данные имеются при подготовке
имитируемых сообщений и их достаточно зарегистрировать и
упорядочить.
Таким образом, интегральные оценки экономической эффек-
тивности имитаторов тестов с использованием КИМС целесооб-
разно проводить с учетом совокупных затрат на тестирование
определенного КП. Более полное представление эффективности
можно получить, если оценивать стоимость разработки одной
команды в КП с учетом совокупных затрат на тестирование.
Подобные оценки позволяют наглядно представить повышение
производительности труда создателей сложных КП за счет ав-
томатизации тестирования с учетом затрат на средства автома-
тизации.
ГЛАВА 3
ТЕСТИРОВАНИЕ ПРОГРАММНЫХ МОДУЛЕЙ
XI. МЕТОДЫ И МЕТОДИКА ТЕСТИРОВАНИЯ ПРОГРАММНЫХ
МОДУЛЕЙ -
Методы тестирования программных модулей. Приведенные
выше (см. § 2.2) оценки сложности программных модулей под-
тверждают невозможность или практическую нерентабель-
ность полного исчерпывающего тестирования многих модулей.
Поэтому основным критерием тестирования является достиже-
ние максимальной глубины проверки модуля при реальных ог-
раничениях ресурсов. Иногда применяется критерий заданной
полноты проверки программного модуля при минимальном ис-
пользовании ресурсов тестирования. Для реализации таких
подходов необходимы теоретические и экспериментальные ис-
следования, позволяющие оценивать достигнутую полноту
проверки программы при ограниченных затратах и практичес-
кое внедрение методов систематического регламентированного
тестирования.
Теория тестирования программ значительно отстает от экс-
периментальных исследований и от нужд практики. Имеется
ряд работ -по частным вопросам теории тестирования моду-
лей [40, 8, 53, 106) и несколько обзоров [78, 811, освещаю-
III
щих состояние теории тестирования. В данной главе системати-
зируются и развиваются основные концепции теории тестиро-
вания программных модулей.
Основными задачами в процессе тестирования программных
модулей являются:
планирование тестирования в соответствии с выбранными
критериями и распределение ограниченных ресурсов для до-
стижения заданного качества программ;
разработка конкретных тестовых значений и соответствую-
щих им эталонов;
формирование отладочных заданий с указаниями тестов,
регистрируемых и контролируемых параметров;
тестирование программы при заданном наборе тестов}
обработка результатов тестирования, сопоставление их с
эталонами и анализ отклонений от эталонов.
Перечисленные задачи могут решаться различными метода-
ми и при различной степени автоматизации. Эффективность
тестирования и достигаемая корректность программ при огра-
ниченных затратах прежде всего зависит от планомерного ис-
пользования методов тестирования. Каждый из методов спо-
собствует повышению качества программ. Однако в зависимо-
сти от характеристик тестируемых модулей могут быть выбра-
ны наиболее рациональные методы и последовательности их
использования. Поэтому в данном разделе сначала рассматри-
ваются особенности, признаки и классификация различных
методов тестирования, а затем методика их применения при ре-
альной разработке. программ.
Применяемые методы тестирования различаются по ряду
признаков, среди которых можно выделить доминирующие:
степень автоматизаций пропесса тестирования (ручные —
без использования ЭВМ как средства анализа и обработки дан-
ных или автоматизированные, при которых ЭВМ используется
для непосредственного выявления ошибок и для анализа те-
стируемых программ);'
форма представления н исполнения программы при тестиро-
вании (в символьном виде на языке программирования или в
машинном коде реализующей ЭВМ);
основные компоненты программы, подлежащие тестирова-
нию (поток передач управления — структура программы или
поток данных — преобразование переменных).
Кроме того, методы тестирования программ можно объеди-
нить в группы: детерминированные, стохастические и тести-
рование в реальном масштабе времени. Общие характеристи-
ки этих групп методов приведены в § 1.2. При тестировании
программных модулей наиболее широко применяются детер-
112
минированные методы. Очень редко на уровне модулей прово-
дится тестирование в реальном масштабе времени. Этот метод
наиболее эффективно используется для тестирования групп и
комплексов программ (см. гл.4).
Некоторые признаки тестирования в реальных методах не-
совместимы либо принципиально, либо из-за низкой эффектив-
ности методов при таких сочетаниях. Выбор методов тестиро-
вания зависит от этапа разработки, объема и особенностей тес-
тируемых программ и ряда других факторов. Так, автоматизи-
рованное тестирование структуры программ может проводить-
ся детерминированно или стохастически, а также по символь-
ному тексту программ или при исполнении их в машинном ко-
де. В процессе разработки модулей символьной тестирование
используется преимущественно при детерминированных те-
стах, а стохастическое тестирование применяется при испол-
нении программ в машинных кодах. Поэтому ниже рассматри-
ваются методы с таким сочетанием признаков, при котором
обеспечивается наиболее эффективное обнаружение ошибок
определенных тийов. Последовательное систематическое при-
менение методов позволяет целенаправленно проконтролиро-
вать в программах практически всё возможные типы ошибок.
Рассмотрим подробнее особенности методов тестирования про-
граммных модулей по выделенным признакам.
По степени автоматизации процесса тестирования можно
выделить группу методов ..ручного тестирования (см. § 3.2).
Эти методы не исключают использования ЭВМ для трансляции,
контроля и подготовки текстов программ. Однэко'предполага-
ется, что ЭВМ не производит анализа и обработки текстов или.
машинных кодов программ для получения и отображения ре-
зультатов тестирования. Ручные методы позволяют обнаружи-
вать наиболее простые и массовые ошибки, которые не требуют
высокой автоматизации тестирования и не оправдывают затрат
на функционирование средств автоматизации. Поэтому всегда
целесообразно сочетать ручные и автоматизированные методы.
Основная часть методов тестирования является в той или
иной степени автоматизированной. При этом ЭВМ использует-
ся для обработки текстов программ в различной форме и для
представления информации о результатах тестирования в виде,
удобном для анализа специалистами.
Форма представления и исполнение программу для тестиро-
вания зависит от этапов разработки,-уровня языков программи-
рования, наличия соответствующих средств автоматизации и
других факторов. Применяются две принципиально различные
фэрмы представления программ в процессе тестирования:
113
в ваде текста иа языке программирования (символьное
представление), удобного для анализа человеком и недоступ-
ного для непосредственного исполнения на ЭВМ;
в машинном коде конкретной ЭВМ (объектное представле-
ние), пригодном для обработки определенных кодовых исход-
ных данных и неудобном для анализа человеком.
Конечной целью тестирования является получение коррект-
ной и надежной программы, функционирующей в машинном ко-
де на ЭВМ. Нельзя утверждать, что абсолютно корректная
программа в одной из форм представления будет столь же кор-
ректной в другой форме. Однако достижение корректности
программы в символьном представлении способствует повыше-
нию корректности программы в объектном представлении,
и наоборот. Кроме того, провесе тестирования в символьном
представлении во многих случаях экономичнее, чем в машин-
ном коде. Поэтому созданы две группы методов тестирования:
статические, использующие только исходные текс-
ты программ, преимущественно на языках высокого уровня (юз
исполнения той же программы в машинном коде на ЭВМ;
динамические, при которых тестируемая программа
исполняется на ЭВМ в соответствующем машинном коде, а тек-
сты на языке программирования применяются как вспомога-
тельные.
С понятием статического тестирования тесно связано поня-
тие символического тестирования. В литературе они в ряде
случаев используются как синонимы. Ниже под снмволичес-
ским тестированием понимается ручной или автоматизирован-
ный анализ текста программы для проверки адекватности реа-
лизуемых маршрутов в программе и выражений, определяю-
щих преобразование данных. Понятие статического тестирова-
ния несколько шире, оно учитывает формализованный конт-
роль корректности структуры программ, записи и чтения пере-
менных, расчет длительностей исполнения программ и другие
виды анализа корректности исходного текста программы. Кро-
ме того, статическое тестирование позволяет планировать по
различным критериям эффективное динамическое тестирование
с учетом ограниченных ресурсов на его проведение.
При динамическом тестировании основные результаты полу-
чаются в процессе исполнения программы в машинном коде той
ЭВМ, для которой предназначена программа. Однако для опи-
сания тестов и отладочных заданий, а также для отображения
результатов тестирования широко применяется символьное
представление на языке, близком к языку программирования.
Использование символьного представления при динамическом
тестировании обеспечивается соответствующими транслято-
114
рами и значительно упрощает анализ результатов тестирова-
ния.
По признаку основных компонент программы, подлежа-
щих тестированию, выделяется тестирование потоков управле-
ния и потоков данных. Эти методы применяются как при пред-
ставлении программ на языках программирования, так и при
исполнении их в машинном коде, после трансляции, а также
при ручном тестировании.
Тестирование потоков управления (структуры программы)
при ручных, статических и динамических методах является
первым шагом, так как при некорректной структуре возможны
наиболее грубые искажения выходных результатов я даже от-
сутствие некоторых из них. В большинстве программных мо-
дулей, особенно в системах управления и обработки информа-
ции, логические операторы анализа условий составляют су-
щественную часть (10—15%) 1341, что приводит к сравнитель-
но небольшим участкам последовательных вычислений и обра-
ботки переменных (5—10 машинных команд между условными
переходами). Связи логических операторов определяют после-
довательность вычислений и обработки переменных и основ-
ную логику функционирования программы. Искажения логи-
ческих условий и вследствие этого изменение последователь-
ности обработки данных может приводить к наиболее грубым
ошибкам в функционировании программы. Кроме того, для
тестирования структуры , программных модулей в большинстве
случаев требуются относительно меньшие затраты, чем для тес-
тирования потоков данных. Так как тестирование структуры
программ обеспечивает наилучшее соотношение эффективность-
стоимость, то ему отдают предпочтение как при ручных,
так и при автоматизированных методах тестирования. Анализ
структуры программ может проводиться по различным крите-
риям выделения компонент программы (см. §2.1). При этом
постепенно увеличивается полнота проверки модулей, од-
нако соответственно возрастают затраты на тестирование
(см. рис. 2.10).
' Тестирование потоков данных можно разделить на два эта-
па. Первый этап состоит в анализе обработки данных, опреде-
ляющих значения предикатов в операторах выработки логи-
ческих решений. Решения влияют на маршруты обработки ин-
формации, что сближает этот этап с тестированием структуры
программы. В этом случае значения операндов и их взаимо-
связь . используются для формирования маршрутов исполнения
программы. Второй этап тестирования обработки данных со-
стоит в проверке вычислений по аналитическим формулам. Ло-
гические операции являются второстепенными и основую роль
115
5 ГРУППЫ МЕТОДОВ ТЕСТИРОВАНИЯ
ЧАСТНЫЕ МЕТОДЫ ТЕСТИРОВАНИЯ
Рис. 3.1. Методы тестирования программных модулей'
играют арифметические операции над целыми и вещественными
величинами. За эталоны принимаются результаты ручных или
автоматизированных расчетов по тем же или близким по со-
держанию формулам. Такое тестирование позволяет выявлять
ошибки масштабирования, ошибки предельных значений ве-
личин и арифметических преобразований над несовместимыми
величинами и т. д. При обработке массивов могут выявляться
ошибки в их структуре и в использовании переменных из мас-
сивов различной структуры.
На основе проведенной классификации, а также с учетом
практики тестирования программ целесообразно выделить на-
иболее различающиеся группы методов, которые представлены
на рис. 3.1. Степень автоматизации этих методе® зависит от
сложности создаваемого КП и ресурсов, выделенных для ав-
томатизации. Эти ресурсы распределяются, в основном, меж-
ду ЭВМ, осуществляющей исполнение тестовых заданий, а
также имитацию тестов и обработку результатов тестирования,
и специалистами, подготавливающими тесты и отладочные за-
дания, а также анализирующими результаты тестирования
(см. рис. 2.9, г). В некоторых случаях ограниченная произво-
дительность и память ЭВМ, которые реально могут быть нс?
пользованы для тестирования, определяют возможность приме-
нения частных методов и достигаемую лблноту проверок мо-
дуля.
' В каждую из выделенных групп входят частные методы, ос-
новные из которых представлены на схеме. Особое внимание в
данной главе уделено тестированию структуры программ
(п. 3.3) и тестированию потоков данных (п. 3.4). Эти методы
являются в значительной степени общими при ручном, стати-
ческом и динамическом тестировании. Например, тестирова-
ние структуры модуля, записи и чтения переменных, границ
областей изменения переменных, потоков данных могут про-
изводиться статическими (на символьном уровне) и динамиче-
скими (в машинных кодах) методами.
Следует подчеркнуть особенность применения вошедших в
практику терминов «динамические методы и средства» прн
тестировании модулей и их отличие от понятий «средства и ме-
тоды для динамического тестирования комплексов программ в
реальном масштабе времени» 134, 57, 59]. В первом случае тер-
мином «динамические» подчеркивается наличие исполне-
ния программы при некоторых исходных данных для полу-
чения контролируемых результатов. При этом не важно, имеет-
ся ли в программе в качестве параметра реальное время и изме-
няются ли значения. Во втором случае, при тестировании КП,
функционирующих в реальном масштабе времени, термином
118
«динамические» отмечается наличие изменения пара-
метра «реальное время» в процессе тестирова-
ния. В этом случае «статическими» методами и средствами на-
зываются такие, которые обеспечивают тестирование КП при
их исполнении для фиксированных значений реального време-
ни. В дайной главе понятие «статические» и «динамические»
средства тестирования программных модулей соответствуют
первому случаю, т. е. связываются с наличием исполнения
программ при их проверке.
При завершении систематического тестирования частными
методами осуществляется проверка функционирования про-
граммы относительно заданной спецификации (функциональ-
ное тестирование). В результате обнаруживаются отклонения
от эталонных значений и спецификаций, для локализации ко-
торых' применяются частные методы анализа потоков управ-
ления или потоков данных в программе. Кроме того, определя-
ется работоспособность и защищенность программы при про-
извольных искажениях тестовых данных. Тестирование при
искаженных данных позволяет подготовить программные моду-
ли к надежному функционированию в составе КП. При завер-
шении тестирования оценивается глубина проведенных прове-
рок и достигнутая степень корректности модуля.
Методика тестирования программных модулей. Особенно-
стью методики является систематическое применение методов,
начиная с простейших и характеризующихся наименьшими,
затратами, в порядке увеличения их способности обнаружи-
вать и локализовать наиболее сложные ошибки (рис. 3.2). Для
каждого этапа на схеме дается содержание основных работ и
показаны сйязи иа последующие и предыдущие эт'алы. Возврат
на предыдущие этапы тестирования является достаточно ти-
пичным и обусловлен чаще всего необходимостью дополнитель-
ных проверок после корректировок программ. На схеме пред-
ставлены некоторые вспомогательные работы, несколько иначе
и не полностью отражены частные методы, приведенные на
рис. 3.1. Тем самым выделены наиболее важные задачи для ме-
тодики тестирования модулей.
Эту схему целесообразно использовать в качестве основы
при создании рабочих методик тестирования для конкретных
проектов. В зависимости от особенностей проектов некоторые
работы могут увеличивать свое значение, а другие исключать-
ся из рабочей методики. В данной главе основное внимание со-
средоточено на методах, используемых на первых четырех эта-
пах тестирования (рис. 3.2). Функциональное тестирование бо-
лее широко применяется для проверки групп и комплексов
программ (см. гл. 4).
119
Рис. 3.2.' Схема систематического тестирования программных модулей
S:
120
3.2. ТЕСТИРОВАНИЕ МОДУЛЕЙ БЕЗ ИСПОЛНЕНИЯ ПРОГРАММ
Ручное тестирование. Существенное повышение произво-
дительности труда при разработке программ и ускорение об-
наружения ошибок обеспечивают методы систематической про-
верки программ за рабочим столом без применения ЭВМ.
Высокая эффективность ручных методов тестирования дости-
гается благодаря: сокращению затрат на трансляцию программ
после исправления каждой ошибки, уменьшению числа отла-
дочных заданий и затрат на их исполнение иа ЭВМ, а также
раннему обнаружению наиболее массовых и грубых ошибок.
Экспериментально' установлено, что в модулях ручными мето-
дами удается обнаруживать от 30 до 70% программных и алго-
ритмических ошибок из общего числа ошибок, выявленных при
тестировании [14, 451. При особо методичном применении руч-
ного тестирования и инспекций доля обнаруживаемых сшибок
достигает 80%. При этом одновременно осуществляется дора-
ботка программ в направлении улучшения их структуры и ло-
гики обработки данных, а также в направлении снижения пси-
хологической сложности и сложности последующего автомати-
зированного тестирования на ЭВМ.
Применение ручных методов базируется на использовании
исходных функциональных спецификаций или технических
заданий’ на программные модули и текстов программ (листин-
гов) на языке программирования. Листинги могут быть пред-
ставлены в виде текстов, подготовленных для первичной тран-
сляции или получены после трансляции на ЭВМ и корректи-
ровки автоматически обнаруживаемых синтаксических и се-
мантических ошибок. Основные проверки проводятся по лис-
тингам после устранения автоматически обнаруживаемых оши-
бок с применением следующих методов [14, 451:
ручного тестирования за рабочим столом индивидуально
создателем дайной программы;
сквозного просмотра текста и тестирования программы
группой специалистов;
инспекции группой специалистов текста программы на ло-
гику ее функционирования с позиции типовых ошибок.
Перечисленные методы целесообразно применять последо-'
вательно, что позволяет проводить наиболее полный и разно-
сторонний контроль корректности программ. На практике
обычно используется индивидуальное ручное тестирование й
коллективная проверка либо сквозным просмотром, либо ме-
тодом инспекции, текста. Психологические трудности коллек-
тивных проверок сдерживают широкое применение ручных ме-
тодов.	ч
121
Ручное тестирование трудно формализуется и его эффек-
тивность существенно зависит от планирования и докумен-
тального оформления. Для повышения методичности проверок
необходимы следующие документы:
функциональная спецификация на программный модуль;
текст программы (листинг) на языке программирования;
графовая модель программы (блок-схема) или таблица ре-
шений, характеризующая логику программы;
основные формулы, по которым проводятся вычисления и
результаты ручных расчетов;
таблица регистрации ошибок или сомнительных конструк-
ций, подлежащих дополнительной проверке.
В качестве эталонов при проверках используется, в первую
очередь, функциональная спецификация. Вычисления йроверя-
ются путем сравнения с результатами независимых расчетов по
исходным формулам. Для проверки логики программы в каче-
стве эталона используется графовая модель или таблица реше-
ний, а также неформализованные представления разработчи-
ка программы и коллектива специалистов, участвующих в про-
верках.
Индивидуальное ручное тестирование за столом . является
самым необходимым и широко используемым. Для проверки
реализующейся логики программы и обработки потока данных
производится:
анализ текста программы на наличие ошибок в операторах,
описаниях данных, маршрутах исполнения программы и логи-
ке обработки данных;
выполнение расчетов в вычислительной части программы
для проверки полноты и точности вычислений;
исполнение* программы вручную на тестовых наборах для
проверки логики функционирования и обработки данных при
конкретных тестовых.значениях.
Перечисленные проверки позволяют также получать тесто-
вые наборы, которые в дальнейшем служат эталонами при тес-
тировании на ЭВМ. При программировании на языках низкого
уровня в процессе ручной проверки осуществляется контроль
использования регистров и компонент памяти ЭВМ, правиль-
ности формирования циклов, обращений к функциям и другим
модулям и т. д. В результате ручных проверок уточняются ос-
новные эталоны — функциональная спецификация, блок-схе-.
ма и таблица решений, в результате программа подготавлива-
ется к'более глубокой и разносторонней коллективной провер-
ке.
Коллективный сквозной просмотр текста программы про-
водится в основном по той же схеме и с применением тех же ис-
Ш
ходных документов, что и ручные индивидуальные проверки.
В группу контроля обычно входят 3—5 специалистов различ-
ной квалификации. Во главе группы должен быть высококва-
лифицированный программист, ответственный за группу про-
грамм, в которую входит данный модуль. Кроме разработчика
проверяемого модуля в группе желательно участие разработ-
чиков модулей, наиболее тесно взаимодействующих с анализи-
руемым. Для контроля документов и структурного построе-
ния модуля целесообразно участие технолога по программиро-
ванию. Один из членов группы назначается ответственным за
регистрацию всех выявленных ошибок. Целесообразно, чтобы
все участники группы в некоторой степени были заинтересо-
ваны в проверке модуля и могли быкорректно н дру-
желюбно сотрудничать для достижения высокого
качества программы. Выявленные ошибки не следует рассмат-
ривать как слабость разработчика, а необходимо относить толь-
ко к самой программе.
Для продуктивной работы группы целесообразно предвари-
тельное ознакомление всех ее участников со спецификацией и
листингом программы. При коллективном сквозном просмот-
ре автор программы должен объяснить по листингу процесс об-
работки тестовых данных. Тестовые данные и основные марш-
руты исполнения программы заранее подготавливаются разра-
ботчиком,^ могут дополняться членами группы в процессе ана-
лиза. Тесты служат для углубленного критического понимания
программы членами группы и должны содержать простейшие
числовые значения. Участники проверки выполняют роль вы-
числительной машины и обрабатывают тестовые данные в соот-
ветствии с логикой текста программы. Значения переменных
точно не вычисляются, а оцениваются и отслеживаются запися-
ми в таблицах или на листинге. Проверки программного моду-
ля проводятся заседаниями продолжительностью 14-2 часа,
на каждом из которых анализируются маршруты, содержащие
около 100 операторов. Ошибки, выявленные на заседании, же-
лательно устранять до следующего заседания и продолжать
сквозной просмотр после краткого комментирования прове-
денных корректировок. В результате сквозного просмотра под-
готавливается и уточняется состав тестов и набор эталонов для
тестирования на ЭВМ.
Коллективная инспекция исходного текста проводится
группой специалистов, близкой по составу к предыдущей.
Весь анализ строится для обнаружения типовых ошибок про-
граммных модулей. Таким образом, в отличие от предыдущих
проверок при инспекции текста в качестве основных исход-
ных данных выступают типовые ошибки и соответствующие им
123
конструкции в программах. Работа начинается с ознакомления,
•с логикой программы по ее листингу при комментировании ав-
тором. В процессе изложения содержания программы задаются
уточняющие вопросы с целью обнаружения ошибок. Список
этих ошибок (14, 451 составлен на основе экспериментального
изучения статистики ошибок и практически не зависит от язы-
ка программирования. Ошибки можно объединить в следующие
группы:
обращение к данным — использование переменных с неус-
тановленными значениями, ошибки индексации и базирования,
несоответствие структур данных в процедурах;
описание данных — отсутствие явного описания или не пол-
ное описание данных, отсутствие или неправильное присвое-.
ние начальных значений, несогласованность инициализации *
переменной с определением типа памяти;
вычисления — наличие в последовательных вычислениях
данных разных или недопустимых видов, несогласованность
масштабов, приводящая к переполнению или потере точности,
возможность деления на нуль;
сравнения — использование при операциях сравнения не-
совместимых типов или различных размеров величины, искаже-
ние операторов отношений БОЛЬШЕ, РАВНО, МЕНЬШЕ и
операций И, ИЛИ, НЕ, сравнение чисел с фиксированной
и плавающей запятой;
передачи управления — ошибки организации циклов, при-
водящие к возможности зацикливания или неправильного вы-
полнения цикла, наличие решений по умолЯаиию или неполно-
го числа выходов в переключателях;
межмодульный интерфейс — несоответствие числа,' струк-
туры и размерности параметров на входе модуля переменным
^-каждого вызывающего модуля, несоответствие описаний пере-
менных требованиям на выходе модуля, несогласованность опи-
саний глобальных переменных и их интерпретации операторн-
ыми программы;
вводгвывод — неполное или неправильное описание атри-
бутов файлов или оператора обращения к файлу, несогласо-
ванность размера записи и выделенной емкости памяти, не-
полный контроль и регистрация операций с файлами;
помехозащитна. — отсутствие контроля входных данных, от- ;
сутствие сохранения исходных данных и возможности рестарта
модуля при сбоях. .		»
Для каждой из перечисленных групп ошибок и для каждо-
го типа ошибки в.группе выделяются операторы, потенциально
допускающие данный <тип ошибок. Инспекции исходного
текста с позиции типов ошибок позволяют их выявлять без уг-
124
дубления в функциональное назначение и детальную логику
функционирования-программы. Поэтому данный метод следует
рассматривать как дополняющий и расширяющий возможности
предыдущих ручных проверок.
Совокупные затраты па ручные проверки могут составлять
заметную часть полных затрат (10—30% 1141) на разработку
программ. Однако они вполне оправдываются, сокращением
сроков разработки и повышением качества программ. Основ*
ные трудности ручных проверок носят психологический харак-
тер и связаны с коллективным анализом результатов творчес-
кой деятельности отдельных программистов. Во многих слу-
чаях эффективность ручных проверок недооценивается вслед-
ствие традиционного оптимизма программистов и убежденно-
сти в собственной непогрешимости, а также из-за кажущей-
ся экономичности автоматизированных методов и средств.
Для активного и эффективного использования ручных методов
необходима разработка регламентирующих методик и стандар-
тов, а также организационные мероприятия по контролю их
применения в.конкретном проекте.
Символическое тестирование. В предыдущем разделе и на.
рис. З.Г символическое тестирование представлено как часть
статического. При этом тексты модулей используются на язы-
ке программирования без исполнения программы в машинных
кодах на ЭВМ. В процессе тестирования анализируются не
числа, а формулы программ, записанные в символическом виде
1161. Они связывают наборы входных переменных программы и
выходных переменных, участвующих в исполнении программы
по определенному маршруту. При этом области определения
входных и выходных данных для конкретных маршрутов раз-
биваются на соответствующие им подобласти. Каждому пост-
роенному таким образом тесту соответствует определенный на-
бор входных и выходных переменных с конкретными граница-
ми подобластей и указанием реализуемого маршрута. В ре-
зультате некоторый символьный тест эквивалентен целому
классу динамических тестов с числовыми, несимвблическими
данными.
При символическом тестировании основная цель состоит в
установлении соответствия между областями определения набо-
ров данных (входных и выходных) и маршрутами их обработки
в программе. Эта задача может решаться с двух позиций 1101.
При первом подходе за эталон принимается маршрут исполне-
ния программы и проверяются входные и выходные данные это-
го маршрута (символическое тестирование маршрутов). Вто-
рой подход состоит в том, что для заданной области измене-
ния входных данных выявляются маршруты исполнения про-
126
граммы, а также символические значения переменных-в конце
этих маршрутов (символическое тестирование на сочетаниях
входных данных). В результате в обоих случаях обнаружива-
ются ошибки несоответствия маршрутов и данных и после их
устранения повышается корректность программы.
Символическое тестирование маршрутов исполнения про-
граммы формализует на уровне выражений совокупность ус-
ловий и связей между входными данными, приводящую к ре-*
ализации конкретных маршрутов. Эти условия и связи позво-
ляют генерировать тесты для проверки выделенных маршру-
тов. Кроме того, могут быть выделены переменные или облас-
ти их изменения, не влияющие на результаты при исполнении
программы по этим маршрутам. При таком методе тесты гене-
рируются целенаправленно па базе маршрутов исполнения й
логической структуры программы. В результате можно обес-
печить тестами проверку всех маршрутов или оценивать сте-
пень тестирования программы по относительному числу не-
проверенных маршрутов. Выбор маршрутов целесообразно
осуществлять по критериям структурного тестирования и
анализа сложности структуры программ (см. §§ 2.1 и 3.3).
Прн этом минимизируется число тестов и выявляются нереа-
лизуемые маршруты. Последнее означает, что для анализируе-
мого маршрута отсутствует область определения входных дан-
ных, обеспечивающая получение соответствующих ей выход-
ных данных.
Символическое тестирование на сочетаниях входных данных
имеет целью выделение маршрутов, которые реализуются при
каждом наборе областей определения входных данных, а также
выделение символических выражений и областей изменения со-
ответствующих им выходных данных. В результате тестирова-
ния получается реализуемая программой функция в виде фор-
мульного описания отображения входных данных в выходные.
Если область определения некоторой переменной не ограниче-
на или задана широко, то ,возможно выделение нескольких
маршрутов исполнения программы и областей изменения ре-
зультирующих данных. Корректность программы в этом слу-
чае устанавливается по соответствию заданным эталонам реа-
лизующихся маршрутов и областей изменения выходных пере-
менных.
При некоторых сочетаниях областей изменения перемен-
ных из-за их противоречивости полный маршрут при последо-
вательном анализе ие образуется и символическое исполнение
программы ие доходит до конца. Такой маршрут является не-
реализуемым и для выделенного набора входных данных отсут-
ствует адекватный набор выходных данных. В результате, ес-
126
ли установлены области изменения входных значений и соот-
ветствующие им области результатов, то тестирование про-
граммы иа символических значениях может быть достаточным
для полной проверки корректности программы. Такое симво-
лическое тестирование в ряде случаев позволяет сократить мно-
жество исполнений программы на числовых тестовых значе-
ниях.
Символическое тестирование близко к задачам планирова-
ния динамического тестирования на конкретных значениях на
основе анализа структуры и обработки потоков данных. Преж-
де всего это оценка сложности анализируемых программ по
числу маршрутов и суммарной сложности тестов по совокуп-
ности условий (см. § 2.1). При символическом тестировании
значительные трудности встречаются при обработке индекси-
рованных переменных и обращений к функциям и подпрограм-
мам. Последнее обусловлено возможностью вычислений иад
всеми переменными и в том числе иад входящими в состав пре-
дикатов, в теле вызываемых и ие раскрываемых функций или
подпрограмм. Технологические системы для автоматизации
символического тестирования программ и генерации тестов
создаются в большинстве случаев на базе задания маршрутов
ПО, 551. Однако в них, как правило, отсутствуют средства об-
работки обращений к функциям и подпрограммам.
Есть ряд попыток 146, 80] применить для символического
тестирования метод таблиц решений. Таблицы ре-1
шений представляют собой упорядоченные условия, каждому
набору которых ставится в соответствие набор-действий или
решений (рис. З.ЗЛ 1121. Тем самым формулируется не конкрет-
ный алгоритм решения задачи, а ее точная формальная поста-
новка и необходимые условия ее решения. Наборы условий
компонуются в правила, описываемые матрицей условий.
В матрице действий для каждого правила указывается сово-
купность решений. В общем случае таблица решений прн п
условиях является формально полной, если для каждой из
всех 2П ситуаций имеется решающее правило. В результате
формально полные таблицы решений даже прй небольшом чис-
ле условий могут оказаться весьма громоздкими. В действи-
тельности таблицы редко строятся формально полными. Кроме
того, значительное сокращение размера таблиц обеспечивается
их фрагментацией путем выделения трупа условий и соответ-
ствующих им решений.
Большое практическое значение имеет понятие логйческой
полноты таблиц решений. Таблица решений называется логи-
чески полной, если всем логически истинным ситуациям она
ставит в соответствие некоторые действия. Формальная полно-
127
Правила
И/>10
К - 12
Z# 6
К- 4
Х< 1
Да Нет
Нет Да
Да -
Да -
Да	Нет
Да ' Нет
Д«	Д»
Да	Нет
Рис. 3.3. Структура таблицы решений
та таблиц решений может быть проверена автоматйчески при
одновременном выделении ситуаций, для которых отсутствуют
правила. Логическая полнота учитывает семантические связи
условий, что затрудняет формальную проверку ее полноты,
однако значительно уменьшает размерность.
Из каждой .таблицы' решений можно получить множество
эквивалентных графовых моделей (блок-схем) программ, и на-
оборот. Преимущества таблиц решений перед графовыми моде-
лями программ проявляются тогда, когда решение задачи за-
висит от многочисленных связанных между собой условий.
Таблицы обозримы, легко изменяются и позволяют наглядно
представить логику задач. Таблицы решений могут составлять-
ся по тексту программы автоматически или разрабатываться
вручную независимо от программного текста. В первом случае
таблица решений соответствует исходной программе и исполь-
зуется для анализа полноты схемы решений, для структурного
контроля, а также для контрол я. записи и чтения переменных
на маршрутах. Возможно использовать полученные таблицы
также для выделения иекторой части нереализуемых мар-
шрутов, в которых имеются явно противоречивые условия.
Маршруты исполнения программы, содержащие не полностью
определенные условия, Зависящие от предшествующих вычис-
лений или значений элементов массива, невозможно формаль-
но селектировать на реализуемость при исполнении.
128
s.-• Исходная информация лЛя таблиц рёшёниёй Црак|ичёй<и
такая и*, как при других видах символического тестирова-
ния. Поэтому тиНЫ выявляемых ошибок и грубила контроля
аналогичны тем/которые получаются при оперировании с гра-
фовыми моделяямкпрограмм. Однако таблицы решений в Неко-
торых случаях* позволяют представить данные для крй£р(й0Гв
более наглядной1 форме. Кроме того, автоматическое получе-
ние и преобразован ня Таблиц' решений МойсеТ быть более эко- '
цомным по времени счета й требуемой памяти ЭВМ, чем опе-
рирование с графовой моделью программы; 4' ' * ; '
Втсфой-путь применения таблцц рёГиеннй для тестирования
программ состоит в, независимой ручной подготовке таблйц'по
-• спецификациям программных модулей. Такие таблицы могут
•быть автоматически преобразованы В блок-схемы или графовые
Модели программ. Сопоставление получерной таким Образом
модели каждой программы с моделью; автоматически получае-
мой по тексту программы, позволяет выявлять некоторые
структурныеошйбки и ошибки потокрп данных. В этом случае,
по-существу, сравниваются два независимо подготавливаемых -
описания программы: в форме таблиц решений и на языке про-
граммирования. Подобный контроле рочти цдвбе урелиуивр^т
затраты ,иа описание программы, одйако' может BaMetiiO сокра-
тить затраты'на обнаружение и локализацию ошибок. Эффек-*
тивность такого применения таблиц решений пока не изучена,
однако выявлены значительные Трудности прЙ'осврёнйй п^р-
грд0!истамй метода составлений таблиц решений, кроме того,
трудоемкость их подготовки достаточно вёлика.
Любые методы, тестирования в той или иной степени^ ориен-
тированы на обнаружение ошибок определённых классов, На-
иболее полно такай’ ориентация П^Ойрляетёй в частном' метр- .
•де поиска . к 6 н к р е т и ы х с е й а н т и ч е с к и х
о ni и бок1 В.символйчёскомтёксте программ 131. ДЛЯ эТрго ис-
следована статистика реайьных семантических ошибок прр-
граммирования на языках высокого уровня и создан каталог'
наиболее^ типичных Ошибок. Выявлено наличие устойчивых
семантических ошибок программирования, Практически,Неза-
висимых. от- класса Задач, реализуемых алгоритмов,- языка
программирования и квалификации разработчика. К ним от-
носятся: наложение массивов или переменных, неправильное”
формирование м употребление логических 'выражений, невер-
наяпередача управления Окератбром’переХсДа, ртрутствЦё.НА*
чаЛьной установки переменных, иеЪернь1й формат данных и
т. д. Выделены Наиболее часто встречающиеся типы ошибок р
текстах программ, которые дополнительно классифицированы
по областям поиска: оператор, линейный участок иливеск
5 3»к. 1061 ~	„		129
программный модуль. Область порска в значительной степени
определяет, сложность обнаружения конкретной ошибки. Для
наиболее часто встречающихся типов ошибок разработаны от-
ладочные процедуры, позволяющие выделять, программные
конструкции, в .которых 'могут, содержаться ошибки опреде-
ленных типов. Эти конструкции.Иодлежат автоматическому или
автоматйзировянному анализу для проверки их корректности.
Таким методом иа ранних этапах символического .тестирования
при относительно небольших затратах могут быть обнаружены
и устранены в тексте программы некоторые типы формализуе-
мых семантических ошибок*, •.-и -		-<
' >!.i” >’•
.. .ЭД ТЕСТИРОВАНИЕ СТРУКТУРЫ ПРОГРАММНЫХ МОДУЛЕЙ
Принципы тестирования структуры программныхмодулей.
Найболеё полная проверка корректности структуры програм-
мы достигается при автоматизированном детерминированном
тестировании. Значительную часть теоретических результатов,
полученных Для этого метода, можно использовать.с.некото-
рыми ограничениями при ручном и символическом тестирова-
ни'и 114,44].
Детерминированное тестирование структуры программных ,
модулей имеет целью проверку корректности маршрутов ис-
, полнения программ и обнаружение в основном логических оши-
бок формирования маршрутов. На практике при отсутствии •
 упорядоченного.анализа потоков управления некоторые Мар- ;
шрутыв программе (до! 50% 1451) оказываются пропущенными
Нри тестировании. Поэтому первая задача, которая решается 1
при тестировании структуры программ, — это получение ин-
формации о полной совокупности реальных маршрутов испол-
нения в каждой программе. Такое представление маршрутов
позволяет упорядоченно контролировать достигнутую степень ,
проверки маршрутов й в некоторой Степени предохраняет от
случайного пропуска отдельных летестировавшихся маршру-
тов. В результате значительно повышается достигаемое каче-
ство программ и тестирование приобретает планируемый сис-
тематический характер.,	.	. ' '
Сложность и трудоемкость тестирования потоков управле-
ния определяется комбинаторным характером схем принятия


решений во многих программных модулях, что приводит к
большому числу Маршрутов обработки информации в програм-
мах. Анализ критериев Тестирования и выделение, тестируемых
маршрутов удобно проводить,, используя графовые модели про-
грамма При планировании тестирования структуры программ
возникают прежде всегоДйё задачи: формирование критериев
130
выделения маршрутов длятес'гировайня и выбор стратегий упо-
рядочения выделенных маршрутов (рис. 3.2).	•’
Критерии выделения маршрутов для тестирования соответ-
ствуют критериям определения структурной сложности про-
граммныхмодулей, Приведенным В § 2.2. В основном исполь-
зуются критерии (табл 3.1):
покрытия графа программы минимальным количеством
маршрутов, охватывающих каждую Дугу графа хотя, бы один
раз (Xi);	:
выделения линейно-независимых маршрутов на базе поня-
тия цикломатнческого числа (у2);	’
выделения маршрутов прн всех возможных комбинациях
дуг, входящих в маршруты (х3).
Таблица 3.1. Основные факторы, определяющие тестирование
структуры программных модулей	' >
Критерии • выделения маршрутов длд тестиро- вания модулей программ	Xi — минимальное покрытие графа про- граммы Xs — линейно-независимые маршруты на ба- зе цикломатнческого числа X» — маршруты, образующиеся при всех возможных комбинациях входящих дуг
.Стратегии упорядочения маршрутов	- 1.	По длительности исполнения или числу команд в маршрутах 2.	По количеству условных переходов или дуг графа программы 3.	По вероятности исполнения маршрутов
Гипотеэы о вероятности невыявленной ошибки в тестированной дуге маршрута	Vi —>• вероятность ошибки - постоянна до полной' проверки всех маршрутов, про- (	ходящих через данную дугу. После че- го становится равной нулю у»— вероятность ошибки убывает пропор. ционалыщ числу протестированных ..маршрутов, проходящих через данную ДУГУ у3 — вероятность ошибки становится рав- ной нулю после тестирований любого маршрута, проходящего через дугу
Гипотезы о вероятности ветвлений ,в каждой вершине Графа програм- мы ' 1 ' ।		.	'•	1	1 1		.1 .1. Ветвление .происходит равновероятно , 2. Вероятности ветвления имеют пары зна- чений, одинаковые Для, всех вершин гра- фа программы и различающиеся В зави- симости' от направления ветвлений: 3, Вероятности ветвления цмею^ случайные некоррелированные значения ^реального исполнения программ	* . -?•
5*
131
' Число маршрутов, выделяемых во этим критериям, зависит
от структуры программы;'Однако всегда: число маршрутов
Х^^'число маршрутов число маршрутов Ха-В реальных
.программах1 часть маршрутов может быть нереализуемой из-
за противоречий в условиях, анализируемых на последова-
тельных участках маршруту. Это может-приводить к сокраще-
нию чи'ела маршрутов по Любому критерию. Невыполнение
правил структурного построения программ 121, 27, 371, наобо-
рот, приводит, к возрастанию чиСЛа маршрутов, выделяемых цо
третьему критерию. К значительному возрастанию числа марш-
рутов обычно приводят циклыв. программ ах. Несмотря на пере-
численные обстоятельства, приведенные критерии являются до-
статочно удобными для практических оценок сложности й под-
' ноты тестирования структуры программ. Планировать тести-
рование можно по одному из критериев или, испоЛьзуя последо-
вательно жесткие критерии выделения маршрутов 18, 621, при
которых соответственно возрастает объем и сложность тести-
рования.'	.	.
Стратегии упорядочения маршрутов. Все множество выде-
ленных маршрутов необходимо упорядочить по некоторому по-
казателю в соответствии с выбранной стратегией. Показатель
важности маршрута для тестирования программы может учи-
тывать сложность Маршрута и тестов ДЛя его проверки (коли-
чество операторов, условных переходов и циклов в маршруте,
частость его исполнения при рабочем функционировании КП,
сложность получений соответствующих эталонных данных и
другие факторы) Ц101. В первую очередь целесообразно про-
изводить проверку Основной группы маршрутов с экстремаль-
ными значениями показателя в пределах ресурсов, выделенных
для тестирования. При имеющихся ограничениях некоторая
часть маршрутов может оказаться не проверенной й характери-
зует достигнутую корректность данной, программы по выбран-
ному критерию. 	;
. Упорядочение маршрутов при планировании тестирования
базируется на использовании в основном трех характеристик
-программных модулей (табл. 3.1):	’' - "
числа команд в выделенных маршрута^ или-расчетной дли-
тельности'их реализации (стратегия 1);
числа альтернатив или условных переходов, определяю-
щих образование каждого маршрута (стратегия 2);
, вероятности исполнения маршрутов при реальном функцио-
нировании программы (стратегий 3).
S. Этц стратегии тестирования позволяют сосредоточить вни-
мание разработчика Па анализе Наиболее важных компонент
программ 181. При стратегии 1 первичному тестированию под-
132 ’	/•"	:'fi
лежат маршруты, наиболее длинные по Числу команд, и по вре-
мени исполнения. Им соответствуют обычно маршруты с иа-
ибольшимобъемом вычислений и преобразований переменных.
Эта стратегия целесообразна при планировании тестирования
 программ, ймейщих вычислительный характер обработки.дан- ".
‘ны* при небольшом чисде логических, условий и маршрутов Ис-
полнения программ. Выбранные первичные маршруты не.обя-
зательно являются наиболее ^сложными по логике функциони-
рования.
При стратегии 2приОритет отдается маршрутам, наиболее
сложным по числу анализируемых условий. Такая.стратегия
предпочтительна при тестировании логических программ с не-
большим объемом вычислений. При обеих стратегиях на за-
’ вёрйающие этапы тестирования остаются простые по вычис-
лениям или по логике маршруты, для которых, необходимы .от-
носительно короткие тесты. Это соответствует традиционней •
стратегии многих разработчиков программ -подготавливать
вначале тесты с возможно большим охватом компонент Отлажи-
. ваёмой программы. ' .
* ‘ В типичной программе на Арлю 3% операторов приходится
дд 50% времени исполнения всей программы 1791..В результате
Изучения профиля программы (см. § 1.2) могут быть выявлены
наиболее критические по длительности или самые .частые
маршруты исполнения программы. Использование профиля
программ позволяет сконцентрировать усилия разработчиков
на прбверке наиболее активно функционирующих .компонент
И'НЫделить слабо проверенные части программ, которые испол-
няются редко-	;	• v
При упорядочении маршрутов по стратегий 3 основная
сложность состоит в оценке вероятностей ветвления в Условных
переходах И переключателях, а также в оценке числа исполне-
ний циклов. Эти ’значения доданы указываться разработчика-
ми Программ, что достаточно, трудоемко и субъективно. Тем не
меиёе такие стратегии позволяют более корректно планировать
тестирование и оценивать уровень сглаженности программ. ,
‘ Планирование тестирования-структуры программных моду-
лей в значительной степени может быть автоматизировано 1301.
Задача автоматизированных систем планирования-тестирования
состоит в выделении маршрутов программ, по одному или не-
скольким выбранным критериям, с .последующим их упорядо-
чением по заданной стратегии (см,' § 3,5}. Ж результате: разра-
ботчик программ автоматизированно, информируется «составе
Ыаршрутдв в программе ддя проведения упорядоченного тес-
тирования. Кроме того, если фиксировать маршруты, по кото-’
рым уже проведено тестирование, то их можно автоматически .
133
исключать из • информирования и выдавать на регистрацию
только группу маршрутов, подлежащих первоочередной про-
верке. Эти же данные могут использоваться для автоматическо-
го расчета полноты проверки и для оценки достигнутой кор-
ректности программы по каждому из критериев выбора
маршрутов.
Показатели корректности тестирования структуры про-
граммных модулей. Эффективность тестирования определяется
полнотой проверки программного модуля или вероятностью на-
личия оставшихся ошибок в зависимости* of затрат на создание
тестов, исполнение программ и анализ данных тестирования.
Затратьте значительной степени зависят of суммарной сложно-
сти тестов, проверяющих маршруты исполнения Программы.
На каждой дуге графа программы между условными перехода-
ми производятся вычисления и преобразования переменных,
объем которых может изменяться в широких пределах.* Для
упрощения анализа тестирования структуры программ,1 пред-
положим, что длительность и сложность вычислений на дугах
графов программ одинакова и ие велика 1991. Некоторые .верши-
ны графа программы могут образовываться в результате схож-
дения дуг без последующего ветвления. Такие вершины не вли-
яют на число маршрутов и их можно прианал изеобобщать с-
ближайшей последующей вершиной, в которой происходит
ветвление. При этих предположениях; сложность теста, прове-
ряющего каждый t-й маршрут, в первом приближении пропор-
циональна числу дуг графа программы, входящих в этот мар-
шрут, или числу условий которые необходимо задать в те-
сте. Каждое условие определяет выбор /-Й дуги в графе про-
граммы к очередной вершине и, следовательно, включение
7-й дуги в i-й маршрут, ведущий из начальной вершины в ко-
нечную:
«и,
где ои
1, если /-я вершина графа входит в Лй
маршрут;
.; [О в противном случае.
Полная сложность тестов для проверки программы в по-
следующем-Принимается равной сумме сложностей тестов
используемых для проверки каждого i-ro маршрута: :
(3.1)
134
где суммирование ведется по маршрутам, выделяемым по
одному из приведенных выше х-х критериев.	. ,
 качество проверенного тестирования и достигнутая кор-
ректность модуля Определяются возможностью получить прн
его реальном • функционировании искаженные результаты.
В. маршрутах исполнения программы,, содержащих участки,
., не проверенные тестированием, наиболее возмржно' искажение
результатов из-за невыявленных ошибок. Предположим, что
.. . до тестирования вероятность ошибки в /-Й дуге графа програм-
мы,.входящей в t-й маршрут, равна Кроме того, пусть ве-
роятность ошибки в /-й дуге в первом приближении не зависит
от ошибок в остальных дугах графа программы, т. е. резуль-
тат вычисления либо полностью используется на этой же ду-
ге, либо является итогом программы. Тогда вероятность полу-
чения правильного результата иа конкретном i-м. маршруте
.18,421
Pi =П(1	(3,2)
/6<
. В реальных условиях конкретное исполнение программы
происходит по одному нз всех возможных /Их маршрутов.
Выбор маршрута определяется обрабатываемыми данными, ко-
торые влияют на направление ветвления в вершинах графа
программы. Реализация каждой /-й дуги i-ro маршрута испол-
нения программ зависит от вероятности ли выбора этой дуги
при предшествующем анализе условия ветвления,' вследствие
чего вероятность реализации i-го маршрут^'
л,= f) Лгу.
/6<
В результате вероятность отсутствия проявления ошибки
при реальном исполнении программы определяется произведе-
нием вероятностей выбора соответствующих дуг и вероятнос-
тей правильного исполнения этих дуг
РП	—#у)=х я, 1 (1 —ql}).		(3.3)
/6*	/€*
Предположим, что правильность выполнения маршрута не
зависит от .предыдущих исполнений программы н равна Рь
Тогда полная вероятность правильного функционирования
программы при, произвольных исходных данных, определяется
вероятностью Выбора различных маршрутов и корректностью
их исполнения,
^Pi»2 л,П(1-9Ц).	(3.4)‘
i=l ,«=!	/6*
135
Эта величина можетрассматриваться как п о к a 3 are л>*,-.
ч кОр ре к'тй 6»ст и программы по результатам тес-
тирования её структуры. Следовательно, Вероятность проявле-
'ния ошибки при случайных Данных на входе ,
<? *. 1	1 - s я, п (1 -?</).	(з.б)
:* .	jfj		;oi
Значения вероятностей исполнения маршрутов, зависят не’
только от вероятностей ветвления1 в каждой вершине и выбора Г*
Дуг графа программы, но и от критериев выделения маршру-
тов. Полное число маршрутов Мх. выделяемых каждому
%-му критерию, может значительно измениться в зависимости 7
от критерия : нх выделения. При завершении тестирования
программного модуля повеем Мх маршрутам» выделенным по
выбранному, критерию, модуль следует считать полностью кор-
ректным Но данному критерию выделения маршрутов. Однако,
если после тестирования оценить степень корректности про-
граммы-при выделении маршрутов по более жесткому крите-
рий, то модуль окажется протестированным не полностью и со-
ответственно вероятность ошибки может быть не равна нулю на
дополнительных маршрутах, выделяемых rib этому критерию.
-Таким образом, набор маршрутов Л4Х, выделяемых по каж-
дому %-му критерию, является полным в пределах использова-,
ния этого критерия, и суммарная вероятность исполнения •
этих маршрутов должна быть равна единице. По каждому набо-
ру Маршрутов Мх суммарные вероятности реализации маршру-.
тов, подсчитанные цо. значениям Лц, могут отличаться от еди- .
нйцы:, ’ -	.....	..
-•	(3.6)
'-.‘76*,
Для рценки вероятности ошибки при выделении маршрутов
. по каждому критерию значения Р следует делить на Вероят-
ность Врех маршрутов по х-му критерию:
* ’ г< ‘	\ ~* 1	’*
Р^. Х*гП71^ч) £ П Яц|	(3.7)
'М :7(У,'	.''”’•/67	/	> .
Следует подчеркнуть, что в предыдущем выражении веро-
ятность может стать равной нулю поеле П олного
, тестирования соответствующей j -й дуги. Когда тестируется
последней маршрут из выделенных но х-му критерию, то пред-»
г полагается, «по входящие в негр дуги не будут содержать оши- ,.
1Э6 .
бок после их проверки. Поэтому после тестирования порледне-
го из Мх маршрута вероятность Рх для каждого критерия ста-. --
новится равной'единице.’	"	,	/ .
Представляет интерес оценка изменения'Рх в'зависимости
от затрат иа тестирование, которые характеризуются суммар-
ным объёмом тестов для %-го критерия выделения маршру-
тов, число которых Мх:	, *
-7—=2 П 9и)( 2 п2 М’ (Эф
В зависимости от критериев выделения и.стратегий упоря-
дочения для любого числа выделенных Мх маршрутов, эта. ве-
личина может значительно изменяться. Прй увеличении жест-
кости критериев выделения маршрутов увеличивается их чис-
ло и замедляется рост корректности программ при возрастаний
суммарной сложности тестов. Так как ресурсы на тестирование ,
всегда, or раиичены, то приходится прекращать тестирование ' -
при использовании допустимых затрат ^. Вспомогательным
критерием для оценки целесообразности дополнительных за?.,
трат на тестирование может служить величина. Рх/£х.Есдн она.
мала, то корректность программ увеличивается медленно и
эффективность дополнительного тестирования может оказать-
ся сомнительной.
Полное тестирование при некотором у-й критерии выделе-
ния маршрутов может соответствовать некоторой ненулевой
вероятности обнаружения ошибки Qx+T ПРИ выделении мар-
шрутов по более жесткому (% + 1)-Му критерий). Разность
Qx+i — Qx может использоваться для оценки целесообраз-
ности продолжения тестирования с переходом на более жёст-
кий критерий выделения маршрутов при ограниченном их чйс- .
ле. При этом за вспомогательный может приниматься крите-
рий, представленный выражением (3.8), Формальный анализ
рациональных’пределов тестирования и выбора критериев для
конкретных программ, затруднен разнообразием структур Я.
характеристик программных модулей,, а также различием тре-
бований, предъявляемых к корректности программ. Поэтому
рассмотренные мртоды следует принимать как ориентирующие
при планироваииИ'И оценке эффективности тестирования струк-
туры программ.	-	1	.
Оценка достигаемой корректности программы. Вероятность .
правильного функционирования Программы зависит!6г зиачёч?
ний Otj, которые/прежде-всего, с	гея тем, ‘насколько
тщательно- нротеетировэны ветви' программы к текущёму ыо-
менту отладкй.'В-нетестирбваийые-мартруты ‘ могут входить
Чч —
линейные участки программы, ранее тестировавшиеся В составе \
других маршрутов.'Дуги графа программы, проверенные при
тестировании некоторых маршрутов, могут содержать ошибки,
проявлющйеся при тестировании других маршрутов, включаю-
щих1те жедуги. О вероятности ошибок qtj в тестированных j-x
дугах Ложно сделать следующие’предположения (Табл. 3.1).
. Гипотеза При исполнении программы по нётёстирд- '
вавшемуся маршруту возможно получение на дуге ошибочных
результатов, несмотря на то, что она уже проверялась в со-
ставе другого маршрута. В этом случае вероятность ошибкй.'в
любой дуге графа программы не зависит от ее проверок по дру-
гим маршрутам'и становится равной нулю только после пол- 
ного завершения тестирования по всад возможным маршрутам, •
проходящим через данную дугу: *
О после полного тестирования всех маршрутов
через j-ю дугу;
9тах В противном Случае.
Эта гипотеза позволяет получить пессимистичес-
кие оценки вероятности, правильности исполнения про- '
граммы- после проведения тестирования по части маршрутов.
Такие оценки могут оправдываться при наличии сложныхвы-
числений на дугах графа программы. При этом вследствие раз-
нообразия исходных данных, формируемых на других участ-
ках маршрутов, проходящих через данную Дугу, возможна не-
полная проверка вычислений до тех пор, пока при различных
значениях переменных не будут протестированы все маршруты,
включающие рассматриваемую дугу. В результате вероятность
обнаружения Ошибки при тестировании очередного маршрута
зависит от полногр числа дуг в тестируемом маршруте незави-
симо от того; проверялись ли оии ранее или нет.
• Гипотеза у». При завершении тестирования программы по
некоторому маршруту вероятность сохранения ошибок в ду-
. гах этого маршрута убывает, пропорционально относительно-
му числу протестированных маршрутов, проходящих через
данную дугу:
?шах
= О
. 4^fPi . в противном случае,
где tty — относительное число протестированных маршрутов,
проходящих через j-ю дугу.
Эту гипотезу трудно использовать при, анализе из-за необ-
ходимости учега для каждой дуги программы соотношения
138
" до начала тестирования;
после тестирования на всех маршрутах;
Ча
числе маршрутов, протестированных и не проверенных. Ги-
потеза наиболее неопределенная и может давать завышенные
или заниженные оценки в зависимости от объема вычислений
на дугах графа программы.
Гипотеза ys. Любая дуга графа программы, проверенная
хотя бы в одном маршруте тестирования,: проверена полностью
и не содержит ошибок, которые могли бы проявиться при дру-
гих маршрутах исполнения программы: ,. . "
{О, если дуга проверялась хотя бы один раз;
в-противном случае.
Эта гипотеза, соответствует оптимист и ч ес к и м.
оценкам вероятности правильного исполнения програм-
мы. Подобные опенки близки к реальным значениям Для ло-
гических программ принятия решений с малым объемом вы-
числений’на дугах графа программы, когда их однократная
проверка достаточно достоверна. В этом случае вероятность
ошибки при тестировании маршрута зависит от числа только
тех дуг в маршруте, которые райее не были охвачены при тес-
тировании Других маршрутов. При всех гипотезах предпола-
гается, что при исправлении новые ошибки не вносятся.
Вероятность лц выбора /-й дугй при ветвлении в вершине
графа программы в общем случае зависит от начальной части
i-ro Маршрута исполнения программы, по которому достигну-
та эта дуга. Влияние' предшествующих частей маршрутов на
вероятность ветвления мОжет быть учтено только прн анализе
конкретных программ. Для получения обобщённых результа-
тов целесообразно предположить, что вероятность Ветвления
не зависит от предшествующей части маршрута исполнения
программы.
Если вероятности ветвления в графе программы нё извест-
ны, то можно предположить, что ветвления происходят равно-
вероятно Лц •= 0,5 ч» const. При этом ие учитывается реаль-
ный профиль в динамике функционирования программы. -
Вероятность исполнения i-ro маршрута прбграммы зависит
от числа вершин, в которых происходят ветвления, что эквива-
лентно полному числу дуг Lt в маршруте. Вследствие этого
даже при ntt > 0,5 маршруты неравновероятны и вероятность
их исполнения убывает по мере возрастания числа вершин.
В этом случае при первой гипотезе о распределении.ошибок по
дугам программы вероятность проявления ошибки После тес-
тирования М* маршрутов будет равна
- м_
=	2 10.5(1	(3.9)
.339
При третьей гипотезе вероятность проявления ошибки Зави-
сит от числа Дуг Tt Li, входящих в i-й -маршрут и не про-
верейных при тесццрованйи предшествующих маршрутов: .
м- ,	г-
^(3) ₽ 1 - 2 [0,5 1 (1 - w) Ч	'	(310)
<=*	. .	.	•.	.	 ..-и
В пределе"прн полной проверке всех дуг /-го маршрута но
одному из приведенных выше критериев Lt = 0, и, сле-
довательно, вероятность проявления ошибки на i-M маршрутё
<2, =0.	.		.... ...
Для получения практических оценок необходимо опреде-'
лить диапазон изменения реальной вероятности ошибки в
каждой дуге графа программы, Экспериментально- установле-
но, что для слабо структурированных программ число, ошибок,
выявляемых в процессе тестирования программных модулей
составляет 1—2% от чисЛа команд этих меду лей (50, 561. Для
программ обработки информации и управления число услов-
ных переходов составляет около 10% от. числа команд в про-
грамме, т. е. ветвление в программе происходит в среднем пос-
ле исполнения 10 команд линейных участков. Следовательно, •
10—20% линейных участков (или дуг в графе) программных
модулей содержат ошибки перед тестированием, что соответст-
> Вует вероятности фц й?.0,1^-0,2.
. Использование правил структурного программирования,
спецификаций, .требований на модули и группы программ по-
зволяет снизить вероятность ошибок приблизительно иа поря-
док,!. е. до уровня цц « 0,01. Поэтому исследования страте-
гий тестирования целесообразно проводить в диапазоне
ж= 0,1-7- 0,01, соответствующем практически наихудшим и на-
... илучшим реальным значениям. .
Выше предполагалось, что все дуги в графГпрограммы име-г
ют одинаковую длину и эквивалентны по вероятности Появле-
ния в них ошибки, т. е. qu = const в начале тестирования мо-
. Дуля. В действительности дуги графов реальных программ со>
держат.различные типы операторов, которые в разной степени
нодвержены искажениям и ошибкам (31. Операторы в програм-
ме различаются по своей сложности и, соответственно, по ве-
роятности pfc искажения их разработчиками в процессе созда-
ния программ. JB простых, операторах, осуществляющих пре-
образования величин' в соответствии.с некоторыми аналити-
ческими формулами,’ ошибки встречаются относитедьно редко.
Значительно чаще первичные ошибки возникают в совокупно-
сти логических Операторов, осуществляющих формирование
< переменных, анализ условий или образующих циклы.
140
Распределение первичных ошибок по типам операторов за
висит также от этапов разработки КП 134]. На начальных эта-
пах разработки и освоения языка программирования достаточ-
но частыми могут быть первйчныё ошибки в простейших опера-
• торах. По мере освоения, языка и метода программирования
ошибки концентрируются в более сложных операторах или их
сочетаниях. Следовательно, априорная вероятность дц наличия
первичной ошибки в j-й дуге графа программы зависит от со-
става входящих в нее программных операторов и от вероятнос-
тей внести Ошибку А-го, типа .при .разработке .операторов
Дуги;
£ Pv
»е/;
В зависимости от типа оператора, в котором допущена пер-
вичная ошибка, различаются последствия .проявления искаже-
ний (вторичные ошибки). Ошибки операторов приводят в боль-
шинстве случаев только к небольшим искажениям выходных
> переменных. Искажения в этих операторах редко могут вы-
звать нарушения вычислительного процесса или значитель-
ные искажения данных, достаточные для возникновения отка-
зовой ситуации или отказа. Другие операторы, например ус-
ловный переход по содержимому ячейки оперативной памяти
(GOTO) или некоторые типы циклов, могут приводить при ио.
кажении к.катастрофическим последствиям, эквивалентным от-
казу; полному разрушению вычислительного процесса (на-
пример, зацикливание) или значительному искажению Накоп-
ленных данных.	•	. - л. •<’
Каждая дуга в графе программы характеризуется величи-
ной wt}, отражающей потенциальную помехоустойчивость опе-
раторов, составляющих эту дугу. При анализе надежности про-
граммы величина wi} может рассматриваться как вероятность
возникновения отказовой ситуации-при искажении операто-
ров в j-и дуге. В общем случае можно интерпретировать как
усредненное искажение результатов на выходе анализируемой^
программы При .ее исполнении по т’-му маршруту из-за случай-
ных искажений операторов в j-й дуге. Для определения степе-
ни проявления ошибки при исполнении программы по i-му
маршруту необходимо учитывать^ вероятность исполнения ду-
ги nti, вероятность ошибки qtJ в операторах, составляющих
дугу, и вероятность обнаруживаемых последствий после
искажения операторов j-й дуги	, > ,
Л-П лм(1-9О)(1-Шп).	,	43.11)
/е<	= 	г. .
141
Если величину wtj Определять как вероятность возникнове-
ния отказовой ситуации Вследствие первичных ошибок в опе-
раторах, составляющих /-ю дугу, id Pt можно интерпретиро- _
вать как вероятность отсутствия бтказовой ситуации при ис-
• полпенни программы по t-му маршруту. Суммируя Pt по всем
маршрутам программного модуля, можно оценить вероятность
. возникновения отказовой ситуации при исполнении этого мо-
дуля. Кроме того, если учесть частость и Длительность испол-
нения каждого модуля в КП, в принципе, можно рассчитать
наработку на отказовую. ситуацию [261.0бъем вычислений ве-
лик и может быть реализован только специальной программой,
автоматически анализирующей каждый оператор, определяю-
щей его вероятностные характеристики и рекуррентно рассчи-
тывающей характеристики модулей, групп программ и всего
комплекса. Таким образом, создается впечатление, что имеется
потенциальная возможность; расчета надежностных характе-
ристик программ по показателям надежности их компонент.
Рассмотренный метод расчета -вряд ли является конструк-
тивным, так как достоверность таких вычислений низка. В ре-
альных КП, когда достигнута некоторая надежность их функ-
ционирования, отказовые ситуации возникают из-за отдель-
ных необнаруженных ошибок. Малое число таких ошибок при-
водит к большому разбросу их возможного положения и про-
явления в программе, которое зависит, в частности, от полно-
ты и стратегии тестирования, от состава и характеристик ис-
ходных и накопленных данных, от особенностей структурного
построения и методов проектирования программ и от ряда дру-
гих трудно учитываемых факторов.
В (3.11) входят три составляющие, каждая из которых при .
априорном диализе определяется в значительной степени субъ- ;
_ ективно, в основном', на базе экспертных оценок. Дисперсия
такого расчета может быть оценена путем последовательного ,
определения дисперсии вероятности ошибки в операторах, ду- ,
гах графа ''программы, модулях, группах программ и вб всем
комплексе. Весьма велики дисперсия вероятностей первич- "
ных ошибок в операторах и дисперсия вероятностей возникно-
' вения отказовых ситуаций вследствие этих ошибок. Каждая
из этих вероятностей может изменяться в очень широком диапа-.
зоне (два-три порядка) в зависимости от типа оператора. В ре-
зультате рассчитанные значения надежности исполнения про-
граммных модулей будут характеризоваться случайной ошиб- 1
кой, значительно превышающей величину, определяемой на-
дежности. Поэтому метод аналитического расчета надежности
программных комплексов на базе вероятностных характерис-
тик операторов программ и их графовых моделей не позволяет







I
М2
получить данные, приходные ддя практического использования
в качеств оценок их надежности. Однако подобные данные мо-
гут быть эффективно использованы для расчета профиля про-
граммы и планирования систематического, тестирования.
Характеристики тестирования структуры ациклических програм-
мны* модулей. В §2,2l отвечалось, что около половины программных Мо-
дулей; не содержит циклы. Для выявления основных закономерностей
К оценки полнрты тестирования в зависимости от ряда факторов прове-
дён расчет характеристик качества тестирования [8,42] абстрактных
ациклических программных модулей (см. рис. 2.3). Использовались
графы программ, содержавшие, в основном, 32 вершины, что соответст-
вует модулям размером, около 300 предложений нё автокоде, а также
графы с четырьмя вершинами ветвления. Определялась, вероятность
проявления необнаруженной ошибки Q (выражение (3.5)) в зависимости
От суммарной сложности Тестов | при исполнении программы со случай-
ными исходными Данными.
При фиксированной длительности дуг графов программ стратегии
Тестирования 1 и 2 полностью, совпадают и .далее представляются как
стратегия 1. Предполагалось [8, 42], что после тестирования по любому
маршруту Каждой дуги графа программы вероятность наличия ошибки в
этой дуге ft/^=> 0; что соответствует оптимистической гипотезе fy.
В первой группе расчетов вероятности ветвления в вершинах графа при-
нимались равными 0,5, а затем отдельно анализировалось влияние
асимметрии вероятностей при ветвлениях, ,
' Влияние ТипоЬ графов программ на вероятность проявления ошиб-
ки иллюстрирует рис. 3.4. Маршруты выделялись rip критериям Xi й х«.
а упорядочивались по убыванию их дляйЫ. При одинаковом (32) числе
вершйи ветвления в программах .сложность тестов, обеспечивающих до-
статочно низкую вероятность, Q, различается почти иа два порядка
(60--1020) в зависимости от структуры программы^и критерия выДаде-
ния маршрутов. При критерии xi суммарная сложность тестов, необхо-
димых для ,полного тестирования программ, имеющий Структуры Г, ц
Г», различается в 6,5 раз. Сравнительно небольшой разброс^лин мар-
Ряс, 3.4. Зависимость вероятности проявления нёвыявленнрй Ошиб-
ки Q от суммарной сложности тестов | дЛя трей типов графов при
выделении маршрутов ио критерию Xi (— — ;—> й пв'Критерию
——) и.их упорЯдоуедиц.во, Длине (гипотеза пж«*32)
М3
Шрутов в графах rt и Г, приводит к тому, что вероятность проявлений
ошибки Q. почти линейно убывает при возрастании объема тестировав
. ния, В графе Га маршруты значительно различаются по длине-и при
Стратегии 1 тестом наибольшей длины проверяется значительная часть
Программы. Последующие убывающие по длйне тесты-,, при Лц ~ 0,6
Характеризуются малой вероятностью исполнения, вследствие чего для
графа Г» величина Q очень медленно убывает в широком диапазоне зна-
ффнцй Ё. После проверки нескольких последних коротких маршрутов с
Наибольшей вероятностью исполнения зидчеиия <? -> 0 при завершении
уеспфовання.
Приведенные графики позволяют оценить дрстнгаемую полноту
Тестирования при 'заданном объеме тестов. Например, если суммарная
сложность тестов Ё •*.64, то для графа Га по критерию fa достигается
тюлйое тестирование (Q 0), а по критерию fa. только .значение '
Q fo 0,5. При той же сложности тестоц, для программ, описываемых
графами Г> и Га, вероятность проявления ошибки также близка к 0,5.
Для структурированных графов Гх и-Га число маршрутов не зависите!
критериев их выделения и равно числу вершин ветвления. Поэтому для
каждого из этих графов при fa п fa характеристики совпадают, а для
Га различаются весьма существенно. В среднем полное третирование
программ с 32 вершинами ветвления производится тестами с суммарной
сложностью 5 .» 500. Однако, программ^ характеризующиеся графом
Г>, при этом имею* Q sa 0,3 (npH fa).
 Влияние критериев выбора маршрутов, стратегий их упорядочения
к вероятностей ветвления в вершинах на вероятность проявления оши-
бок при тестировании программ более.ваглядн$ отражается'ва неболь-
ших графах программ; В качестве объектов анализа примем симметрич-
ный граф Г,и. асимметричный Гь в каждом Из которых по четыревер-
ёцины ветвления. Граф Гх симметричный й,структурированный й его
Характеристики занимают промежуточное положение между анализи-
руемыми, поэтому он ниже ие рассматривается.
В симметричном графе при использовании критерий fa выделя-
ется всего Два маршрута; а пру Критерий %, — ПятьМарШрутрв. Пря-
ное тестирование по критериям fa. и fa достигается соответственно при
.	«=е ц 5 = ?0 (рис. 3.5), т.ё.сложносТ Д тестовВ завиеймости от кри-
териев различается в 2,5 раза. При равновероятном.выборе направлений
. ветвления после исполнения первого теста охватывается половина дуг
/Трефа программы й вероятность проявления ошибки при fa и fa снижа-
ется до Q « 0,5. Дальнейшее тестирование при выделении Маршрутов
по критерию fa приводит к Постепенному сииЖенйю ф до нуля при Ё =
•=20. Следует заметить, что при Ё =’ .8 Программа полностью протести-
рована покритерию Xi, а по критерию fa вероятность’проявлений ошиб-
ки около 0,4. Симметричная структура, графа Программы Г# обеспечи-
вает равенство длины всех .маршрутов и стратегия, упорядочения по
длине вырождается в произвольный выбор маршрутов..
По мере увеличения асимметрии вероятностей ветвления возраста-
ет эффективность упорядочений маршрутов по вероятности их.иСполие-’
ния. Для симметричных графов ^иГ* распределения направлений с
наибольшей вероятностью исполнения нё влияют' на зависимость Q от
{. Для таких графов При фу •» 0,5 стратегий упорядочения по вероят-
ности и по длительности совпадают. Асимметрия вероятностей ветвле-
ния в вершинах программ может приводить к появлению маршрутов,р'аз-
личающихся по Вероятности исполнений на нескОлрКр порядков, Дёйст-
BtfreHbhoj достаточно на i-МТЧЗршрутеиметъ пятьйершйй ветвления с ве-
роятностью выбора'дуг nij == ОД/Нтобы Вероятность этогб маршрута
стали < В реальных программах, имеющих В маршрутах
.144








I






















Ряс. 3.5. Зависимость вероятности проявления невыявленной ошиб-
ки Q от Суммарной сложности'тестов 6 для графа Га при выделении
Марщрутов.по критерию х« (—• — —) и ио критерию х» ( i—^)’ 
..ИХ упррядочению по вероятности (гипотеза у», п>*4)
' Рис. 3.6. Зависимость вероятности проявления неВыявлениой ошиб-
ки Q от суммариойсложности тестов (• для графа Г» при выделении
маршрутов по критерию Xi и по критерию *» ц их упорядочению по
-Длине (—*—:) и по вероятности (-——) (гипотеза у», я» «4) .
около 10 вершин, возможны вероятности на уровне Ю-1* и ниже.
При расчетах на абстрактных графах было принято, что соотношениаве-
10Ятностей ветвления по направлениям в каждой вершине Одинаковы и
вдаются парами 0,3 и 0,7 или 0,1 и 0,9. Выбор дуги, для которой веро-
ятность Исполнения принималась наибольшей (0,7 или 0,9), в каждой
вершине, фиксировался при растете одной реализации Q для как*
дого типа графа программы.
В симметричном графе Г8 при выделении маршрутов по первому
Критерию и при ветвлении -в вершинах с вероятностями, зависящими
Направления, первый тест (по наиболее вероятному Маршруту) по-
зволяет значительно снизить вероятность проявлеиия'ощибкн (при <
“0,1; 0,9 до 0,1 (рис. 3.6)). Последующее тестирование приводит
К уменьшению.значении Q подобно тоцу, как при равновероятном .ветв-
лении. .		. 5 .	‘ '
В асимметричном графе Г3 вследствие его структурированности
число Маршрутов по обоим критериям равно числу вершин и суммарная
сложность тестов £•«• Ц. В этом случае достигаемая вероятность прояв-
ления ошибки существенно зависит от стратегии упорядочения маршру-
тов. При упорядочении маршрутов по длийе при Лц «0,5 первый тест
ВдВатывает четыре вершины ветвления и дает Q в» 0,5 (рис. 3.6).
/Црй последующем тестировании вероятность Q снижается сначала *
относительно медленно й' только последний самый короткий Тест рез-
ко уменьшает О до нуля. При упорядочении маршрутов по. убыванию
вероятности тесТЯроваиие'начннается с коротких маршрутов и только
дм последние маршрута-проходят по всем вершинам. При я'ц «0,6
146ч
упорядочение по вероятностям (штриховая линия на рис. -3.6) имеет
Значительное преимущество передупорядочением по длительностям
.маршрутов.'
'"Если'В графеТ* вероятность ухода по короткой боковой дуге по-
вышается (при лу >0,5), то- возрастает различие В эффективности
стратегий упорядочения маршрутов по длительности и по вероятности.
При Вероятности ветвления по короткому маршруту я,-) =*= 0,9 во всех
ВёрШИНах сложность тестов £ ==* 7 (половина затрат на полное тестирова-
ние) позволяет достигнуть Qж 10’3 при упорядочении маршрутов по
вероятностям и только- Q=aO,9 при упорядочении- по длительностям
(рис. 3.6).	 
- При малой "вероятности ветвления но короткому маршруту в графе
Га длинные маршруты могут быть и наиболее вероятными. Например,
-;при Лц «е 0,1- по коротким маршрутам наиболее вероятным является
самый длинный маршрут. Однако выбор следующих маршрутов различа-
ется в зависимости от стратегии 'ИХ упорядочения; При упорядочении
па длительностям следующий маршрут содержит также четыре вершины,
а при упорядочении по вероятностям только одну. В результате упоря-
дочение маршрутов по вероятностям при-последующем тестировании бо-
лее выгодно.
. Еще больше различаются стратегии упорядочения маршрутов для
 несимметричного графа Га с большим числом вершин. Особенно эффек-
тивна Стратегия 3, когда ветвления с наибольшей вероятностью про-
исходят в направлении дуг.с малым числом вершин.В этом случае эф-
«ективность  стратегий упорядочения различается на 2—3 порядка,
ероятнбсть исполнения маршрута с «наибольшей длительностью при
-атом- -может быть очень мала и его существование в- программе вряд лп
оправдано. Часть маршрута ниже7 десятой вершины при яцж 0,1
имеет-вероятность nj < 10—1в. Таким образом, оценки- вероятности- Я/
позволяют выявить маршруты с низкой вероятностью исполнения и уп-
рощать их, исключая из плаца тестирования компоненты с л изной. (на-
пример, ni < 10—10) вероятностью исполнения. Кроме того, учитывая
вероятность исполнений маршрутов при значительной асимметрии1 ве-
роятностей ветвления в Программе, можно существенно сокращать объем
тестирования и сосредоточивать его на маршрутах, обеспечивающих
наиболее аффективную проверку программ. В некоторых случаях на-
иболее эффективной оказывается смешанная стратегия, , при которой
сначала тестируется одни или несколько самых длинных маршрутов,
а затем проверяются наиболее вероятные маршруты. На'практике оцен-
ка вероятностей ветвления и вероятностей исполнения маршрутов мо-
гут представлять некоторые трудности 150] Для решения этих задач
при планировании тестирования необходимы автоматизированные
средства расчета ц обработки графов программ (см $3.5):
Различие стратегий упорядочения маршрутов в зависимости от ти
па графа-наиболее наглядно отражает анализ графов с большим (32)
числом вертнйн ветвления На графиках рис 3 7 представлено-влияние
стратегий упорядочения маршрутов при их выделении по второму кри-
терии в равных вероятностих исполнения дуг после ветвления (л^о
•“ 0,5) Для симметричных графов Г, и Г» стратегии упорядочения
маршрутом не изменяют зависимость Q от t и кривые совпадают. Для
графа Га при упорядочений маршрутов по стратегии 3 значительно бы-
стрее можно достичь заданного значения Q, чем при стратегии 1 Од-
нако полная корректность ‘гестированйя достигается! Всегда при одина-
ковых аначейнях Для rj в Га при 40 значения при страте-
гиях I и 3 различаются На два порядка. Б этой сл'уййедля доегйжёния
значения Q, полученного при третьей стратегии, сложйость тестов при
146
< .перво# стратегии необходимо увеличить в. И раз.(до 5 — 560). Таким
образом, упорядочение маршрутов по вероятностям их исполнения, в
ряде случаев позволяет достигать заданной корректности программ при
значительно меньшем объеме третирования даже при равновероятном
.ветвлении,
При .оценке необходимого объема тестирования для графа Г. це-
лесообразно учитывать. Ие только значения Q.HO н отношение Л/Е,
(см. выражение.(3.8)). При стратегии упорядочения маршрутов по ве-
роятности после проверки нескольких тестов с суммарной сложностью
С as 100 очень малыми становятся как значения вероятности проявле-
ния ошибки, так и производная этой вероятности по J, что позволяет
прекратить тестирование.' При стратегии упорядочения <по длительно-
сти при 5 > 32 также резко падает значение производной/Q по 6, одна-
ко при этом Q as 0,5 и тестирование прекращать недопустимо до пол-
ного завершения тестирования’маршрутов с высокой вероятностью ис-
- волнения. В таких случаях может быть рентабельной смешанная стра-
тегия, при которой вначале тестируются несколько маршрутов с наи-
большими значениями вероятностей исполнения и. значениями длэтель-
‘ иостей.	-
Приведенные графики могут служить ориентирами при выборе кри-
териев н стратегий тестирования реальных ациклических программных
модулей^ Абсолютные значении Q в некоторых случаях можно исполь-
зовать для ограничения сложности тестов. Значительное сокращение
-тестирования структуры программ возможно путем учета реальных ие-
роятностей иетвления при условных переходах.
КарактериОтики тестирования, программных. модулей с циклом.
Для выявления типовых структур программ с циклами Проанализирова-
ны 66 программных модулей, функционирующих в реальных системах
управления [43]. Анализ этой выборки показал, что в них отсутствуют
циклы с Числом выходов больше 3, а число циклов с тремя выходами со-
ставляет менее 10% от их общего числа. Число вложенных друг в друга
Рис. .3.7. Зависимость вероятности проявления девыивленнрй ошиб-
ки Q от. суммарной, елржнбегн Жестов £ для графов Д .и -Г»,при .вы-
делении маршрутов пр, второму критерию и их упорядочении. по
длине (—-—rrJ,. H. цо , вероятности, (т- ——) (гипотеза, ум яо=0Д
rtB=±32)	>
147
__ /
. Миклов равно 2,2. Среднее число выходов из цикла составляет 1,4, сред-
нее Число операторов ветвления в цикле 4. средние ранг тела цикла 2,5.
Практически Не встречаются зацепляющиеся циклы, т. е. циклы, име-
ющие общие части, ио не вложенные полностьюдруг в друга. Такие Цйк*-
mi особенно трудно тестировать, в первую Очередь, в силу иеопределеи.
мости значений'Переменных, влияющих На условия замыкания (размы-
кания) цикла. Применение зацепляющихся .циклов при создании реаль-
ных программ, каи правило, запрещаю^ в методиках проектирования
143).
В реальных программных модулях наиболее часто встречаются-
простейшие одиночные циклы.с небольшим числом (2—5) ветвлений в те-
|" ле цикла и одним выходом. Однацо разнообразие даже простейших '
реальных модулей и циклов достаточно велико,и затрудняет обобщеи-
ВцеГоЦеики сложности тестирования модулей с циклами /14, 405].По-
этому с учетом Характеристик реальных модулей выбран^ топовые
страктные структуры графов ациклических программ и разработана ме-
тодика формирования в них одного цикла. Это позволило выявить вли-
яние некоторых характеристик циклана изменение сложности струк-
турного тестирования модуля.
Анализ влияния ци^ла иа число тестируемых маршрутов исуммар-
ную ^ложность тертое проведен, для топовых структурированных абст-*
ррХтных графов программ Г,, Г». Г» (рис. 3.8)1 Методика исследова-
ний состояла в том, что в типовые ациклические графы вводились цик-
лы При следующих ограничивающих условиях;
* ’ число вершин ветвления пя остается неизменным в графе с циклом .
и соответствует исходному ациклическому графу;
может изменяться степень охддта графа циклом, т. е. значения мак-
симального ранга цикла /?щах ц варьируются от нуля (петля) до макси-
маЛьнрго ранга'ациклического.графа, т, е. в циклическом графе,имеет-
ся дуга, связывающая' конечную и начальную вершины;
РИс. 3.8. Типовые абстрактные графы программы с. замыкающими
дугами циклов	’	. - ж	•
148
Г
каждый, цикл проходит «толща итераций* сколько маршрутов соч.
держится в покрытии тела-,цикла-	. v	•••
Сопоставление сложности циклических и ациклических графов про*
грамм целесообразно производить по относительным характеристикам;
относительному числу маршрутов	. ! •	, . . -
М(у)= Мц(х)/Л1а(х);	-	;-
и-относительной сложности тестирования
<Р (X) -ЧцОД/Ьа (X)»
где индексы «Ц» и «а» обозначают характеристики циклического и ацик-/
лйчёского графов соответственно. Кройе того, полезной является харак-
теристика средней длины Маршрута 4> программе с циклом
* Т(х)=£ц(х)/Л1ц(Х>.	'
. Исследована зависимость величин М, <р, от степени охвата графа
Программы циклом, Т. е. of величины tj — nBn/he, где лвц и пв—число
вершки ветвления в теле цикла и в полном ациклическом графе соответ-
ственно: Оценка части структуры программы, охваченной циклом, и
влйян'ия этой часГи иа-структурную сложностьдсего программного мо-
дуля позволяет наметить путь приближенной оценки сложности тести-
рования некоторых типов реальных модулей с циклами. -
При введении обратной замыкающей дуги в графах Г. и Г» об-
разуются симметричные циклы с одной точкой входа и одной точкой вы-
хода, различающиеся числом вершин ветвления в теле цикла. ₽ графе
Г4 образуются неструктурированные циклы с числом, выходов, опреде-
ляющимся числом вершин ветвления в теле цикла. При'Ввёдении'В йтбм
графе замыкающей дуги, исходящей из конечной вершины, или петлй v
образуется цикл с одной точкой входа и одной точкой выхода.
При покрытии графов'с циклом маршрутами по критерию Xi число
маршрутов по сравнению с ациклическим графом увеличивается На один
К не зависит от степени охвата графа циклом. С ростом степени охвата
^мфа цИклом т).уменьшается соотношение ациклической и.циклической
частей Графа. Поскольку число Маршрутов при критерия уд!> определя-
ется ациклической частью графа, то Ьио уменьшается с ростом t). Для
симметричных Графов 1\, Г? величина' М уменьшается До I при tj t=?l,
так как в этом случив весь граф представляет собой цикл и при крите-
рии X» покрывается одним маршрутом р соответственно возросшим чис-
лом вершин.
•В асимметричном графе Г, через цикл проходит лишь небольшая
часть маршрутов, а рост /степени охвату графа циклом приводит к уве-
личению числа выходов из цикла, т. е. к появлению неструцтурировай* '
ных кбистру кций типа «цикл с т выходами:». В этом случае йри любой из
рассматриваемых критериев чн > маршрутов определяете^ ие степенью
охвата графа циклом; а суммарным числом выходов из-циклов и числом
маршрутов в ациклической уасти графа, ,ие проходящих через цикл.
Для графа Fs эта вели чина постоянна, поэтому число маршрутов ие из-
меняется.	.
Возрастание степени охвата графа циклом г) по-раэиому влияет на
изменение средней длины маршрутов в графах. Для критерия Xi -число
маршрутов в графах 4je изменяется, поэтому при. росте степени охвдта
графа циклом прбпорцибНаЛЙнд Нрзрастает Средняя длина маршрута
£ (рнс. 3.9) приблизительно в 2 раза (Е яг 1,75-5-2,6); Для критерия
X» с ростом степени охвата графа циклом увеличивается длина маршрут
‘149
Рис. 3.9. Зависимость средней сложности маршрута ! от степени
охвата графа циклом ц при критериях выделения маршрутов Xi
'<— — —) и Xi (-“----)	.
Рис. ЗЛО. Зависимость относительной сложности- тестирования <р оу
( Степени охвата графа циклом при критериях выделения маршру-
тов х, (——-)hxi(—)
тов, проходящих через цикл. Поскольку в узком симметричном графе
Г» все его маршруты проходят через цикл, то при увеличении ») сред-
няя длина маршрута резко возрастает (в 6—20 раз). Для графов 1\ 
Г». В которых Не все маршруты проходят через цикл, рост средней слож-
ности В зависимости от 1) в. 2—4 раза медленнее, чем для Г,. Однако для
всех графов средняя сложность Маршрута? для критерия х» в 2—3 раза
выше, чем для критерия Xi и возрастает с ростом степени охвата графа
циклом.
При покрытии графов маршрутами по критерию х» относительная
сложность тестирования <р всех Исследованных программ не убывает
С ростом п, а для симметричных графов — монотонно возрастает
{рис. 3.10). Соотношение сложности ациклической и циклической час-
тей графа в эТом случае несущественно.
 Для критерия Ха это соотношение, наоборот, играет большую роль.
При малой степени охвата графа циклом число маршрутов в графе мень-
ше до сравнению с исходным графом, а сложность тела цикла невелика.
Поэтому для симметричных графов Т> и Г, относительная сложность
тестирования становится меньше, чем в ациклическом графе. С возрас-
танием степени охвата графа циклом т) увеличивается сложность тела
цикла;' поэтому возрастает величина «р. Однако для узкого Графа Г8,
все .маршруты ациклической части которого проходят через цикл, име-
ется и область возрастания относительной сложности тестирования', а
также область ее убывания, когда сложность тела цикла высока, во ста-
новится малб число маршрутов в’ациклической части программы.
>В графах rt. н Г, не все Маршруты проходят через цикл, и.следова-
тельно, они составляют определенную долю относительной сложности
тестирования.ф, не зависвфую от степени охвата графа циклом. Рост
сложности тела цикла для этих графов приводив it монотонному возрас-
танию «р при росте*]. Для графа, Г», где число маршрутов при покры-
тии по критерию %, де изменяется, этот рост происходит быстрее. Вместе
с тем относительная сложность тестирования ф для графа Г, и. крите-
рия,xt .выше, чем для %! (до 2.7 раз), в то время как для двух других
графоа ф (хО > <Р (X*)-	’
В симметричных графах Гх и Г, значения М, ф, g ие зависят от
размещения цикла и определяются размером графа и степенью Охвата
его циклом. Для асимметричного графа 'Г4 аналогичные характеристи-
ки зависит от размещении (ранга точки замыкания) цикла. Однйко за-
иисимосты'указанных характернстик ог размера графа является доволь-
но слабой. При изменении размеров графа от лв 7 Дб Лв = 31 значе-
нии ф изменяются не более, чем на 10% для одинаковых значений т].
При введенных предположениях о структуре цикла с, ростом стенени
охвата графа циклом относительная сложность тестирования ф воз-
растает по сравнению с исходным ациклическим графом в 2—2,7 раза
для всех тинов графов.
Таким образом, сложность тестирования исследованных модулей
с циклами рассматривавшейся структуры при выделении маршрутов по
критерию хг близка к сложности тестирования ациклических программ
с таким же числом вершив ветвления. Это позволяет приближенно оце-
нивать сложность минимально необходимого тестирования некоторого
класса программ с Циклами по имеющемуся числу вершин ветвления.
При выделеннн маршрутов по критерию х» Сложность тестирования
'зависит от структуры программы и числа вёршии, входящих в цикл.
В этом случае обобщенные оценки сложности тестирования модулй за-
труднительны и необходим детальный анализ длины и числа маршрутов
с циклами для каждого анализируемого модуля.
Приведенные результаты исследований тестирования на
абстрактных структурах программ (см. также § 2.2) позволяют
провести некоторые обобщения; Подтверждено, что выбран-
ные структуры ациклических программ достаточно хорошо от-
Йажают характеристики реальных модулей (см. рис. 2.4 и 2.5).
[оэтому анализ абстрактных структур может быть использо-
ван для подготовки рекомендаций при практическом тестирова-
нии.
Для большинства ациклических программ при выделении
маршрутов по простейшим критериям полнде число тестов
близко к числу вершин ветвления в программе. Суммарная
сложность тестов в таких программах возрастает пропорцио-
нально квадрату числа вершин ветвления. Поэтому програм-
мные модули целесообразно ограничивать числом команд ир ас-
семблере около 300 или приблизительно 30 вершинами ветвле-
ния. Для полного тестирования таких модулей в тестах необ-
ходимо задавать от 100 до 1000 значений предикатов. ; ‘
При ограниченных ресурсах для тестирования модулей, их
высокой' корректности или надежности можно, добиться,'при-
меняя упорядочение тестируемых маршрутов срответствеино
по длительности или по вероятности их исполнения. Начинать
1 ’ тестирование целесообразно с. выделений маршрутов по про^ *’
Стёйшему критерий охвата каждого'.Линейного участка про-
: граммы. Упорядочение тестирования с. учетом'структуры про-
. грамм-позволяет сокращать'суммарную сложность тестов^ обес-
печивающую заданную вероятность проявления ошибок^ в дё- '•
. сятки раз и контролировать достигнутое качество модулей.
Циклы с простейшей' структурой приводят к относительно
небольшому увеличению суммарной сложности тестов. Прй‘ 9
тестировании целесообразно выделять циклы для автономной^’4
проверки и упорядочивать их маршруты по критериям и стр^'?
тёгиям,’ аналогичным применяемым в' ациклических програм- ж .
 мах. Прн применении циклов со сложной Структурой н.боЛЬ-
, шим' числом ветвлений в теле цикла' сложность ‘тестирования
программ резко возрастает.
, Для применения систематического тестирования необходи-
мо автоматизированно выделять циклы й маршруты в програм-' ’I
мах, а тяюке упорядочивать их по разным параметрам. Кроме
того, целесообразно автоматизировать контроль проте-
стированных маршрутов и выявление маршрутов, подлежа-
щих первоочередному тестированию. Для таких маршрутов мо- _ "
гут автоматически подготавливаться значения некоторых пре-
. дикатов и переменных, которые следует задавать в тестах. Эти
 же средства помогают выделению нереализуемых маршрутов.
i

М.- тестирование обработки данный
• •>- 4V Л
Частные методы тестирований обработки данных. Функцио-
нирование любой программы можно рассматривать как обработ-
ку потока данных, передаваемых от входа в программу к ее
выходу. 'Входные данные последовательно используются для
Определения ряда промежуточных результатов вплоть др по-
лучения набора выходных данных. Задача анализа потока дан-
ных состоит в установлении корректности их обработки и в
. -выявлении ошибок в тестируемой программе. Эта задача-может
решаться т т а т и ч ё с к ц — без исполнения программы (по
"её тексту) и дни амически — путем исполнения про-
граммына ЭВМ в машинных кодах при корректных исходных
данных	 * '
Программирование на языках высокого уровня позволяет
более полно и эффективно анализировать потоки данных в ста-
тике, т. е. на уровне исходных текстов программ. Данные, уча-
' ствующие в вычислениях, на языках программирования тзысо-
кого уровня определены явно по имени, типу и . способу досту-
па. Это позволяет рассматривать программу в виде мультигра-
фа, заданного структуройпередач у правления (потоком управ-
152	'	•
лення) в графом преобразования данных. участвующих в вы? '
числениях (поток данных!(рир,3.II). Вершинылевого рядасо--
ответствуют операторам программы, *а правого ,ряда.*— пере?
мерным и константам, обрабатываемым программой* Поток ,
управления между операторами представлен сплошными ли- -
ниями, а поток данных ~~ штриховыми. ,. 'Г.
Пересечение потоков управления и данных осуществляется
в операторах ветвления: проверки ..условия и цикла. Совмест-
ный.анализ потоков управленцу и данных позволяет проверять
корректность областей определения переменных на маршрутах
исполнения программы. Маршруты могут выделяткяметода-
ми анализа потока управления, а совместимость областёйЗизме-
ненйя данных устанавливаться с использованием характерис-
тик потоков данных.	.v,.-
Последствия ошибок в программе проявляется как малые
изменения некоторых, переменных в процессе вычислений и как
полное искажение нли отсутствие, на выходе требующихся ве-
личин. Тестирование программного - модуля .целесообразно ►
проводить на упорядоченных наборах данных с учетом степе- ;
нн их влияния, на выходные результаты. С этой позиции для
последующего анализа целесообразно выделить (см;, рис. 3.1 и
/ . Лоток ц
* управления
- ПОТфС
данным
. 4$.следующие частике методы тестирования и рациональную Л
последовательность их применения 172,90,911:.	Я
тестирование, при значениях данных, определяющих ветв- Я
ления в программе и маршруты, исполнения программы; • я
. тестирование корректности записи и считывания перемен- 1
ных при вычислениях й полноты состава выходных данных .на |
всех маршрутах исполнения,программы;	jl
тестирование точности результатов вычислений и коррект- |
кости обработки каждой переменной; •*	'	_	J
тестирование па полное соответствие состава и значений вы- |
, ходных данных программной спецификации.	. fl
В приведенной последовательности частные методы Тестнро- 1
вания позволяют прежде всего выявлять первичные ошибки, .3
которые способны искажать результаты в наибольшей степени.
При ограниченных ресурсах и такой последовательности тес», - J
тироваиия в программе будут оставаться ошибки, наименее '4
- влияющие на корректность выходных данных. Прследова- - J
. тельно акцентируется внимание на выявлении следующих я
ошибок обработки данных: влияющих на логику и маршруты' Я
. исполнения программыгзаписи и считывания перемеиных, пол-
ноты состава результатов, точности расчета выходных дан- ’i
ных н полного соответствия выходных данных спецификации. .-
На основе таких проверок Может оцениваться степень охвата
тестированием всех условий, определенных в спецификации, и
дополнительное тестирование следует проводить только при 
отдельных недостаточно проверенных входных данных.
Тестирование при значениях данных, определяющих марщ- 1
. руты исполнения программы (стратегия областей). Обработку 1
данных в процессе ..исполнения программ можно разде- ’*
лить на два вида. Первый вид обработки сводится к преобра-
зованиям данных, результаты которых не влияют на выбор
маршрутов исполнения программы. В вычислениях участвуют
преимущественно, вещественные и целые величины во всей об-
ласти их определения. Кроме того, возможны логические пре-
образования символьных или булевских.величин, в результа-
те которых получаются величины аналогичных типов. При
обработке второго вида подготавливаются и реализуются ло-
гические решения, определяющие последующий маршрут ,об-
работки данных. Осцорой такой обработки является анализ
Соотношений между обрабатываемыми, .величинами, которые
Влияют на направления исполнения программы.
Первомувиду обработки соответствуют данные в ограничен-
хной или неограниченной .области 'определения, которая может
делиться иа некоторое, множество сопрягающихся областей.
Изменение данных внутри такой области не влияет на маршрут
16*
исполнения программы. Поэтому для проверки функциониро-
вания программы из всего множества значений достаточно ис-
пользовать при тестирований только несколько значений внут-
ри и вблизи границ, области. Количество Величин, используе-
мых д ля тестирования при обработке этого вйда, может быть
на, два-три порядка меньше полного'числазначений каждой
переменной в области.
При обработке данных, изменяющихся в пределах области,
преобразования переменных могут иметь, вычислительный или
логический характер. Такая обработка данных в процессе
тестирования проверяется нВ-точность осуществляемых вы-
числений, на правильность масштабирования, и размерности
обрабатываемых величин, на корректность формирования ло-
гических величин и т. д. При этом тестирование должно охва-
тывать всю область изменения каждой обрабатываемой пере-
менной и каждой результирующей величины. Учитывая кор-
реляцию значений каждой переменной и взаимную корреля-
цию переменных, можно существенно сокращать объем тести-
рования. 
Обработке второго вйда соответствуют исходные данные в
критических точках' на границах областей йзмененйя пере-
менных. При таких критических значениях может1 изменяться
маршрут исполнения программы; 'вследствие чего возможно
наибольшее изменение результатов. Поэтому тестирование об-
работки данных прежде всего направлено иа проверку испол-
нения программ при значениях переменных, влияющих на
выбор маршрутов и логику функционирований программы
(стратегия областей). Граничные1 условия это ситуации,
возникающие в непосредственной близости к границам облас-
тей изменений обрабатываемых переменных. Число таких кри-
тических значений каждой переменной может быть на несколь-
ко порядков меньше, чем число значений во всей области Изме-
нений этой величины. В этой части тестирование обработки
данных по содержанию близко к тестированию структуры про-
граммы (см. § 3.3); ,
Маршруты последовательности обработки данных могут
зависеть от любых типов величин. При выборе направления
ветвления участвуют переменные" и константы, отражающие
вещественные, целые, булевские; символьные, векторные и Дру-
гие величины. Области определения таких величин зависят от
их: типов и содержания :и представляют как отдельные точки
и несвязанные области, так И. неограниченную непрерывную
последовательность значений. Одной из задач тестирования \
является проверка сопоставймостй сравииваемых типов вели-
чин и идентичности условий их кодирования (разрядности,
191
маештабов и т. Д.)., Критические значения — предикаты, ми-
'	яющие"н.а маршруты, во многих случаях не являются фиксиро-
ванным#, д выделяются при сопоставлении нескольких пере-
менных. При этом предикаты образуются во всей области из-
м&дшя каждой из переменных, например, когда онн оказы-
. - ЙДютсЯ равными или отличаются на некоторую, постоянную,рё-
Лйчйну.	: г- '	\
1' Предикаты, определяющие выбор маршрутов исполнения
1 программы, формируются в результате вычислений налйней-
I ных участках программы. Как *уже отмечалось, эти,участки р
среднем невелики и содержат около 10 команд. Вычисления в
’ большинстве Случаев представляют собой простейшие линей-
ные преобразования входных данных' По оценкам 167] 95—97%
арифметических операторов включают только сложение и вы- i
питание, а 98 % всех выражений между последовательными d
предикатами содержат не более двух операторов. Кроме тбго, 1
Предикаты обычно очень простые —в большинстве случаев с '*
одной входной переменной и практически отсутствуют преди-
каты, использующие более двух входных переменных. Нели-
нейные'йредикаты встречаются очень редко (0,1—0,3%). При- :
веденные данные позволяют ограничить анализ линейными
Предикатами, характерных для широкого класса программ*.
. - "Каждая ограниченная область исходных данных соответст-
вует Определенному маршруту в программе. Граница области
определяется вдтерпретаДй*ямй предикатов по маршруту н со-
стоит из набора участков границы, каждый изкоторых опреде- J
' ляется единственным простом предикатом, .формирующим ду- <
Гу маршрута в графе программы. Каждый участок границы об- j
Пасти мозкет быть открытым или закрытым в,,зависимости от ;
операторД условий в предикате^ Закрытый участок границы
. принадлежит ограничиваемой области и формируется.предика-
тамис операторами Или Открытый участок границы
’ирЬ входит в,состав Области и формируется операторами '<,.> й
.> Общее число предикатов в маршруте — это верхний предел
числа граничных участков области входных переменных дан-
' Ного Маршрута, так Как некоторые предикаты маршрута могу+
в действительности не создавать граничных участков. Такие
Случаи .возникают, когда предикат требуется для нескольких
рутёй, й в некоторых иэ них повторно анализируется на мар-
шруте.	\	7' .	’	" ''	. '' <1
1 ^Предикаты можНб разделить нЙ три типа: равенство ( ==),
' отношение больше-меньше (<,. >.	5?) и неравенство (=4=).
Использование предика^гой кйждЬгб типа Дет существенно рдз-
личнЫйЭффектна границе области. Предикаты каждого марш-
рута определяют Некоторую гиперплоскость, в пространстве.
156	.
Ограничение типа неравенства эквивалентно составному вреди*
к^ту 0<в) и (Л > J5), такой Предикат приводит к разделе-,
иию исходной области на Две части. Предикаты типа равенст-
ва и больше меньше приводят к формнровй,вию обдаст)!
в виде единственного многоугольника! Многоугольникяр-
ляется выпуклым,'если’’для любых двух точек области
участок границы, формирующий маршрут, входит всрстаВ
эТОЙ области [107]. Если в состав предикатов ввести нера-
венства, то пространство входных данных будет объединё-
ИЙёМ множества выпуклых многоугольников., .	>
^;!Тйкйй образом, программа по отношению к потоку данный,
прежде всего, выполняет функцию разделения пространства
исходных Данных на области, каждая из которых соответст- ..
вует одному исполняемому Маршруту. Ошибки в программ» •
мргут быть обусловлены модификацией границы области оп-
ределенного маршрута, приводящей к расширение'или ружё-
нйЩ пространства исходных дйнных соответствующего маршру-
та. Кроме того, деформацнятраннц областей может приводить
К ошибкам уничтожения некоторых областей и потери соответ-
ствующих. нм маршрутов. Причинами таких, ошибок могут
быть искажения операторов анализа условий или искажений
в процессе вычисления значений предикатов при правильном
оператора условия _ В последнем случае обычно
сдвигается граница области, однако она сохраняет общую
структуру. Искажения' операторов анализа. условий. мож$2
приводить как к дефбрмацйи границы сйда$тй,тац и к появлё- •
нию ровых границ иди их уничтожению, вследствие Чего могут
разделяться или сливаться' области.
СЩин из достаточно часто встречающихся типрв ошибок
обусловлен искажениями условий формирования гранйй, об-
ластей. Ьыбор тестовых Данных вблизи границ областей обёс- -
Печивает наибольшую чувствительность к атим ошибкам. Тес-
товые исходный данные в зависимости от их положения от- -
носительно конкретной границы области можно разделить на
два вида. Первый вид данных (принадлежащая точка) размеща-
ется на границе ббластн. При тестировании граничные точки ,
входят в состав проверяемой области (условий	=^'),
Второй вид (иепринадлежащая точка)'Отстонт от границы на
сколь угодно малую величину-в и находится на открытой сторо-
не данной области (условия-<ъ>, =/=)• Пр^ 'ЦВстаровании та-
кой'области принадлежащие (граничные) точки относятся к
смежной области, а в проверяемую область данная граница •
невхбдйт.,	” -	‘	; ’
-.Для проверки границ областей разработана [67,1071 стра-
тегия выбора тестовых значений, минимизирующая объем про-
Г .. ,	. ....... ,	....	.
/•'1Т-•	-	J57
л
верок. Для закрытой области на каждой границе целесообраз-
но формировать три тестовых значения;-Первые два теста (Л н
Д) (рис. 3.12) размещаются на границе данной области вблизи 
. .стыка данной границы с соседними. Третья точка (С)размеща-~
втся на малом расстоянии в от дайной границы н удовлетйо-
ряет всем, неравенствам области, кроме проверяемогона дан-
ной границе. При таких тестовых данных должны получаться
-выходные результаты, искажения которых обусловлены не-
выполнением условия на анализируемой границе; • ’•.ох
При любом сдвиге границы областей на величину, большую
• в, обнаруживается ошибка. Действительно, если анализируе-
мая граница сдвинута во внешнюю область-по сравнению с за-
данной на величину, большую е, то в точке С выполнится уело-1;
. вне, анализируемое на границе, что является указанием пали- i
чия ошибки. При сдвиге границы внутрь анализируемЬй пбд-
области неправильно выполняются тесты в точках А и В или
«одной из них. При таком расположении контрольных точек
{-Обнаруживаются не только ошибки вычислений', используемых
в предикатах, но и ошибки операторов, предикатов. Даже в
. случае ошибочной замены неравенства на < ошибка обнару-
живается в результате неправильных данных в точках Л и С.-'
 Для проверки Области изменения данных, образующих
. маршрут, необходимо тестировать граничные значения каждого
^предиката. В зависимости от числа ветвлений в каждом марш-
руте имеется пй таких границ. Для каждой'границы, как пока-
зано выше, необходимо иметь три тестовых значения. Однако
число тестовых значений можно несколько-сократить, если
крайние из них выбирать на пересечениях соседних границ. /
JB результате число тестов для каждого маршрута В лежит*
.в пределах 2пр<: 6? < Зпв,
Л'



1






каждого маршрута В лежит
\ > -игХ
Г-Д, ~х,Х ,
Г-Д, -а,Х
X
• Рис. 3.12. Области изменения переменных и точки ддя тестирования
' при условии J' -	'	‘
Рйа 3.13. Области изменения перемённыкй точки для тестирования
...при условии &


, 168 .
Дальнейшее сокращение числа тестовых значений возмож-
но, если-учитывать корреляцию • у елбвнйиаразличных марш-
рутах,; имеющих общие границы областейлВ рвде случаев про-
верка программы в точках; Л и С (рис. 3.12) может проводить-
ся только На одном маршруте,соответствующем нижней части
области'Изменения данных. На маршруте, - использующем
верх нюючастьобдастщ-достаточно тестировать только при тес-
.товых значениях, соответству ющйхточ Не В.	л. . •
1: Для.-ролной проверки предиката-строгого равенства необ-
ходимы два теста на границе условия-равенства значений й два
теста, имеющие малые отклонения от этой границы (рис. 3.13).
Таким образом, по сравнению с Проверкой неравенств в данном
-случае прибавляется ещё один тест. При этом гарантируется
обнаружение ошибок как в операторе предиката, так и в расчете
даниыхпри формировании границы анализируемого условия.
Приведенный подход полностью может быть отнесен к анализу
предикатов типа строгого неравенства. Проверка совокупности '
маршрутов-, содержащих-строгие неравенства и равенства,- мо-
жет быть сокращена, - если учитывать при последовательном
тестировании уже проверенные области.	* •
.. При использовании стратегии областей по признаку их вы-
пуклости' могут автоматически выделяться неверные предика-
ты. Если одна из граней многогранника приводит* нарушению
его . выпуклости, .то область считается аномальной и может
быть локализован предикат, содержащий ошибку..Последова-
тельный попарной Анализ предикатов ид их совместимость ю
непротиворечивость позволяет отсеивать некоторые нереали-
зуемые, маршруту. Тем самым в ряде случает значительно со-
кращается- .необходимый объем тестирования модуля.. '
•Приведенная, методология упорядоченного регулярного
тестирования иа основе определения.областей изменения дан-
ных является весьма эффективной. Сложность тестов линейно
растег с увеличением размерности пространства исходных дан-
ных (числа переменных) и с ростом числа предикатов на маршру- _
тах.Для мдогих типовых Модулей сложность тестов оказыва- *
ется допустимой для полной проверки модуля/Ограничения -
метода проверки областей'могут проявляться при сложных ор-
ганизациях циклов, когда резко возрастает число маршрутов <
и анализируемых условий. Значительные трудности возникают
при нелинейных предикатах. Даже'на хождение точек пересе-
чения нелинейной границы :с множествам линейных границ мо-
жет потребовать сложных вычислений. При использовании В
программе, операторов ИЛИ необходимо, установить характер
перекрытая областей, соответствующих анализируемомурпе-
W -ТРе^Ует	Расчетов. Тем не ценее
.ч	'	'
1S9

-метод анализа.областей изменения давныхможет существенной
г упорядочить тестированиепрог^аМм. -	<7	1
-/ >Нереализуемые маршруты, Предшествующее изложение в
.	$.< базировалось на ‘анализе отдельнык условий и пре- s
с^Д^агЙр» без учета их взаимосвязи при последовательном. нс-
'ЯДОенин операторе* пррграммы.Оценка сЛожност»шг#рб^ 1
>, ^1 МИЯ модулей ори &тиХПредпЪлоЖеШя^ориенТируСТна~Йк-1
ябольщиезатраты. В реальйъга ироТреммных модулях мнст$1
' предикаты, определяющийс Последовав
. •маршрутах программы, являются взаймозавйсимымий^вча-1
стнйсти,несовместимыми; Такне маршруты,: выделенные 1
i, формально по полному, графу программы, ие' могут быть ’нс-1
, ^полнены при реальном функционировании программы н|< При I
неких сочетаниях исходных данных. В результате сокращает- д
Гдо общее число маршрутов, характеризующих"данный?. про- V
f граммныймодуль, и уменьшается сЛожностЬгеготеСтирования. $
может приводить и целесообразности изменения страте-
тестирования и к сокращению ресурсов, необходимых для ?
; <? ’достижения заданной корректности программ: .:
' ; . За счет нереалиэуемых маршрутов прилюбом критерии
выделения сокращается их общее число М*.Если не учитывать я
то расмитаяная вероятность проявления 1
й;м|цбки Q 1см. (3:5)1 всегда будет завышенной и ий при какрм ,|
достигнет нуля, в действительности >
исчерпывающее тестирование при критерии yf возможно тодь- Л
' йр По реаливуемым маршрутам. Поэтому при расчете вероятно-
,ети проявления ошибки Целесообразно проводить предвари- 1
, тельную оценцу числа” нереализуемых маршрутов ккорректи- I
ровать мепольвуемое значение (см. рис. 3.2),	я
'	। 'ш маршрутах графа программ!» несовместимые условии, j
исключающие возмржиость нх 'исполнения, в целом разде- 1
, лены рядом точек ветвленИя. в которых используются другие ]
предикаты при опрцделенни направлега^	< 1
•ШРУТУ: Для нереалнзуемостимарспрута достаточно двух несов- J
 л ^И^имых условий, которьге встредйютея в СледуюЙмд'Я
' тождественные выражения, определяющие явно условия j
ветвления, -крторь1е анализируются на формально выделяемом I
1 маршруте пря лротивополрждых значениях условий движения 1
ноятомумарлнру^у; ’	..Л “;г	‘-а
ц,Выражения с одними и темй же переменными, но с разными 4
их значениями. опредедягощими пенересекающнеся области ус- Я
' деаий-ветвления; •. Ve:.1 •	- v.	‘ j
3 выражения 1 с различными переменными, связанные неярко 1
здгиксЙ * решаемой; Задача; ’ которая формальна Й отражена р 1
данной программе. ‘	‘	|
!Й'	' V 	; ]
Для выявления нереализуемых маршрутов в формально
построенном графе программы каждый из них должен быть про-
анализирован на наличие подобных пар несовместимых усло-
вий. Такой анализ относительно просто выполнить для усло-
вий первого вида, которые однако не так часто встречаются.
Наиболее важный вид неявных несовместимых условий фор-
мально проанализировать невозможно без привлечения описа-
ний всех корреляционных связей между переменными. Пост-
роение таких описаний громоздко и трудоемко, что затрудня-
ет их применение для селекции нереализуемых маршрутов.
Выделение непересекающихся областей значений переменных
при формировании условий образования маршрутов трудно ре-
ализовать из-за часто встречающихся областей со сложной кон-
фигурацией. Дополнительные трудности может представлять
селекция условий с точными и неточными неравенствами иа
границах областей, когда граничные значения по-разному
используются в анализируемых условиях маршрута (см.
рис. 3.12).
Приведенные факторы затрудняют формализованное выде-
ление нереализуемых маршрутов и оценку влияния несовмес-
тимости условий на снижение сложности тестирования моду-
лей. Особенно быстро возрастают трудности при попытке фор-
мального выделения нереализуемых маршрутов в группах про-
грамм, состоящих из многих модулей. Поэтому имеются только
экспериментальные оценки доли нереализуемых маршрутов в
некоторых произвольных программах. Эти данные получа-
лись либо в процессе ручного анализа предикатов на маршру-
тах, построенных в результате автоматического формального
анализа графов программ, либо путем набора статистики чис-
ла различных исполняемых маршрутов при реальном функцио-
нировании программ на случайных исходных данных.
Доля нереализуемых маршрутов сильно различается для
разных модулей. Достаточно часто, встречаются модули, в ко-
торых все маршруты являются реализуемыми и отсутствуют
несовместимые условия при ветвлениях. В ряде программ не-
совместимые условия приводят к сокращению числа маршрутов
в несколько раз. Анализ некоторых логических программ
П09] показал, что доля нереализуемых маршрутов из их об-
щего числа может быть весьма велика и достигает в отдельных
случаях 90—95%. При этом доля нереализуемых маршрутов
в среднем быстро возрастает при увеличении числа ветвлений в
программе. Это обусловлено тем, что вероятность нереализуе-
мости маршрута'зависит от его длины, точнее, от числа ветвле-
ний. На коротких маршрутах с небольшим числом ветвлений,
естественно, менее вероятно наличие одинаковых предикатов,
в 3*к. 106t
16»
определяющих ветвления, и вероятность нереализуемое™ низ-
ка. В пределе маршруты с одним-двумя ветвлениями всегда‘яв-
ляются реализуемыми.
Особенно значительное снижение сложности тестирования
за счет исключения нереализуемых маршрутов происходит в
программах с циклами. Например, циклы, имеющие фикси-
рованный параметр выхода из цикла, образуют нереализуе-
мые маршруты при всех остальных значениях параметра. На-
личие в теле цикла нескольких предикатов и их (обычно неяв-
ная) логическая связь, а также корреляция с номером витка
исполняемого цикла, приводят к тому, что при тестировании
нет необходимости полного перебора всех условий в теле цикла
на каждом его витке. Путем ручного неформального анализа
в некоторых случаях удается эффективно выделять реализуе-
мые маршруты с циклами, без анализа всех сочетаний несов-
местимых условий, при которых образуются нереализуемые
маршруты.
Автоматизация выделения нереализуемых маршрутов огра-
ничена технической сложностью переборного анализа предика-
тов на маршрутах и принципиальной сложностью идентифика-
ции несовместимых условий. Дополнительные трудности ана-
лиза несовместимости условий имеются в программах, напи-
санных на языках низкого уровня (ассемблер), при неявном
представлении предикатов в тексте программ. Поэтому имеются
только отдельные работы, например 17],в которых предприня-
ты попытки построить алгоритм выделения полной совокупно-
сти реализуемых маршрутов по текстам программ на языках
высокого уровня. При этом вводится ряд серьезных ограниче-
ний на структуру и применяемые предикаты в программе, при
которых такой анализ дает результаты. На практике немногие
реальные модули удовлетворяют этим ограничениям, поэтому
системы выделения нереализуемых маршрутов пока имеют
только экспериментальное значение.
Тестирование корректности определения и использования
данных на маршрутах исполнения программы. Если маршруты
исполнения программы соответствуют правильным областям
изменения входных данных, то целесообразно проверить кор-
ректность основных операций обработки данных на выделен-
ных маршрутах. Эти проверки могут производиться путём сим-
волического анализа текста программы или накопления ре-
зультатов обработки реальных данных при исполнении про-
граммы. Каждая величина на маршруте исполнения програм-
мы считывается из памяти и после использования для вычисле-
ний записывается в память ЭВМ для хранения и последую-
щей обработки. Чередование операций чтения и записи пере-
162
менных может быть нарушено в результате ошибок в про-
грамме. Для выявления таких ошибок проводится тестирова-
ние корректности записи и считывание реальных значений дан-
ных или статический анализ этих операций по тексту програм-
мы.
Одни и те же ячейки оперативной памяти и регистры ис-
пользуются программой последовательно для хранения раз-
личных величин. Это позволяет экономить память и проводить
сложные вычисления при ограничении на число программно
доступных регистров и емкость оперативной памяти. При за-
писи текстов программ на языках высокого уровня правиль-
ность распределения памяти и регистров для записи и чтения
промежуточных переменных обеспечивается трансляторами.
При использовании для подготовки программ макроязыков и
автокодов контроль распределения памяти возлагается на про-
граммиста или осуществляется автоматизированно специаль-
ными средствами. В дальнейшем для определенности рассмат-
ривается только распределение регистров хотя это полностью
относится и к распределению ячеек оперативной памяти.
Ошибки при распределении регистров возникают, как пра-
вило, при отстутствии на соответствующем регистре величины,
подлежащей считыванию. Причиной может быть:
операция записи необходимой величины вообще отсутству-
ет;
операция записи существует, ио выполняется не на тот ре-
гистр;
правильно произведенная запись необходимой величины на
заданный регистр уничтожается непредусмотренной записью
другой величины до момента использования первичной записи.
Эти ошибки могут обнаруживаться не на всех маршрутах
исполнения программы, а также при последовательном выпол-
нении операций, разделенных большим числом промежуточных
операций, не связанных с анализируемыми величинами. Зада-
чу тестирования можно рассматривать как задачу обнаружения
ошибочных сочетаний операций считывания — записи для
каждой величины и адресов (имен) регистров, с которыми про-
изводятся эти операции по маршрутам программы 1501. Для
этого в явном виде необходима информация об именах (или но-
мерах) регистров (ге) и наименованиях записываемых (Зп)
и считываемых (Сч) величин (х().
Основные особенности этого вида тестирования можцо про-
следить, рассматривая операции считывания — записи двух
величин на два регистра на некотором маршруте программы в
предположении, что проверяются операции с величиной хх и
регистром гх. Последовательности таких операций на некото-
6*
163
ром маршруте могут быть явно ошибочными или сомнительны-
ми. Последние могут оказаться правильными или неверными в
зависимости от конкретного текста программы или значений
данных.
Ошибочные сочетания:
Зп (хх, Гу) — Сч (х2, гх) — между этими операциями отсут-
ствуют операции Сч (хх, гл) и Зп (х2, гх), вследствие ошибок в
логике или искажены наименования переменных, или регист-
ров;
Сч (хх, гх) — Сч (х2, гх) — пропущена операция Зп (х2, гх)
или искажены составляющие одной из операций;
Зп (лх, л) — Зп (хь г2) — одна из операций лишняя, од-
нако иногда такие записи делаются для удобства последую-
щих вычислений;
Зп (хх, гх) — Сч (х2, г2) — пропущены операции Сч (xJf гх)
и Зп (х2, г2) или имеются ошибки в составляющих этих опера-
ций.
Сомнительные сочетания:
Сч (хь Г1) — в пределах модуля на данном маршруте отсут-
ствует операция Зп (хх, гх), однако может быть запись произ-
водится в другом модуле;
Сч (хъ го — Зп (хх, г2)— причина может быть аналогична
предыдущей, т. е. нет предварительной записи хх на гх и не яс-
на цель записи хх на г2 без последующего считывания;
Зп (хх, гх) — Зп (х2, Гл) — пропущена операция Сч (хъ гх)
или искажены компоненты одной из операций;
Зп (хх, гх) — Зп (хх, гх) — одна из операций на данном
маршруте лишняя и может быть обусловлена формированием
других маршрутов.
Аналогично сочетания операций можно построить для пере-
менной х2 и регистра г2, а также для сочетаний хх, г2 и х2,
гх. Перечисленные типы ошибок обычно проявляются только
на отдельных маршрутах, поэтому тестирование записей-
считывания необходимо проводить по всем маршрутам ис-
полнения программы. При распределении памяти ограничен-
ного объема наиболее частыми являются ошибки записи неко-
торой величины до использования другой ранее записанной
на тот же регистр.
Тестирование корректности записи-считывания перемен-»
ных рассмотрим на уровне символического исполнения про-
граммного модуля. В этом случае после устранения синтакси-
ческих и семантических ошибок по тексту программы строит-
ся графовая диагностическая модель программы. Для каждого
маршрута исполнения программы или для некоторых связан-
164
ных групп маршрутов выделяются операции надданными. Для
операций записи и считывания регистрируются имена величий
и имена регистров или ячеек памяти, а также номера вершин
графа программы, на которых осуществляются операции (см.
рис. 3.11). В результате образуется список маршрутов с точ-
ным указанием места операций записи — считывания перемен-
ных и их размещения в памяти.
Тестирование программы производится при последователь-
ном просмотре маршрутов, начиная с выхода из программы к ее
входу. При анализе маршрута регистрируются прежде всего
операции считывания переменных. Затем по мере анализа
операций на маршруте для каждой считываемой переменной
устанавливается-
существует ли запись контролируемой переменной на дан-
ном маршруте в заданный регистр:
не забивается ли считываемая величина, т. е. нет ли между
записью и считыванием контролируемой величины записи на
тот же регистр другой величины.
Кроме того, выделяются операции записи, для которых не
оказалось операции считывания на данном маршруте. Упоря-
дочение просмотра можно производить, опираясь на номера
маршрутов программы, на имена переменных или на имена ре-
гистров. В общем случае анализ, записи — считывания пере-
менных целесообразно начинать с объекта, имеющего мини-
мальную размерность. Обычно в программе используется мало
регистров при большом числе операций записи-считывания и
маршрутов. Поэтому наиболее эффективно организовывать
проверку операций по именам регистров, прослеживая последо-
вательно имена переменных, использующих соответствующий
регистр, на различных маршрутах.
Несколько иной подход к тестированию процесса использо-
вания переменных основан на анализе потока данных 167, 81,
1001. Выявляются все определения переменных, которые мо-
гут достигать каждой вершины графа программы по управле-
нию.-При этом под определением данных подразумеваются дей-
ствия в программе, которые изменяют соответствующую еди-
ницу данных. Использование данных — это операция в выра-
жении, которая обращается к переменной, не изменяя ее. В' ре-
зультате для каждой точки программы устанавливается, какие
переменные действуют в этой точке, т. е. какие данные, сформи-'
рованные до прихода в эту точку, используются после выхода
из нее. Анализ потока данных позволяет обнаруживать ошибки, 1
обусловленные нарушением корректной последовательности
операций определение-использование данных и выявлять пере-
менные, которые целесообразно сохранять на регистрах.
165
Если переменная не является действующей на некоторой
части программы, то занимаемая память может быть освобожде-
на и определение этой переменной может производиться в дру-
гом месте программы. Анализ процесса определение-использо-
вание или «жизни» данных в программе естественно проводить
по маршрутам ее исполнения. Для каждой единицы данных мо-
жет быть установлена точка освобождения этой переменной,
после которой она больше не используется и ие определяется.
Некоторые последовательности операции определение —ис-
пользование над переменными являются аномальными. Так,
например, последовательное изменение переменной без проме-
жуточного использования на некотором маршруте скорее все-
го содержит ошибку в программе. Для выявления подобных
аномалий необходимо упорядочить вершины графа программы
так, чтобы операция в вершине нс выполнялась до тех пор, по-
ка не выполнятся все предшествующие ей вершины. При на-
личии циклов пока нет способов для предсказания информации,
достигающей вершин, при однократном прохождении через
граф. Значительные трудности для выявления аномалий пред-
ставляют вызываемые процедуры. В этом случае необходимо
раскрывать процесс использования данных процедурами.
Тестирование корректности обработки каждой переменной
и точности результатов вычислений. Когда показано, что соче-
тания данных и их области определения соответствуют коррект-
ному формированию маршрутов в программе, а также нет яв-
ных ошибок в последовательностях определения и использова-
ния каждой переменной, целесообразно провести тестирование
корректности обработки каждой переменной и точности вы-
числительной части программы. Этот вид тестирования произ-
водится преимущественно с вещественными и целыми величина-
ми во внутренней части их областей определения. Кроме того,
может выполняться дополнительный контроль точности вы-
числений при граничных значениях, ранее использовавшихся
для тестирования маршрутов по областям определения.
Множество тестовых значений для проверки вычислений при
простых числовых переменных целесообразно строить упоря-
доченно с учетом следующих правил:
входные тестовые данные в области гладкого изменения за-
висящих от них результатов должны принимать, по крайней
мере, значения, близкие к наибольшим и на-
именьшим, а также одно-два промежуточных значения;
тестирование должно проводиться при всех осо-
бых значениях входных переменны х—
в точках резкого возрастания или разрыва производных, при
нулевом, единичном и предельно малых численных значениях;
166
входные тестовые значения должны обеспечивать проверку
программы при выходных результатах,
имеющих особые точки резкого изменения или
разрыва производных;
если значения некоторой переменной зависят от значений
другой перемеииой, то необходимо тестировать при осо-
бых значениях сочетаний переменных
(равенство обеих переменных, малое и предельно большое их
различие, нулевое и единичные значения).
Таким образом, для каждой простой числовой переменной,
кроме трех точек вблизи и на границе области определения,
обычно необходимо тестирование программы в 3—4 промежу-
точных и в 2—5 особых точках значений входных данных. При
10 входных переменных и сложных вычислениях в программ-
ном модуле для тестирования вычислений может потребо-
ваться до 50 тестовых значений. Группируя и упорядочивая
тестовые значения разных переменных, их общее количество
можно сократить до 5—10 тестовых наборов.
Если каждая числовая переменная кодируется 2 байтами
(2+м значений), то полная совокупность значений 10 входных
переменных составляет около 2,5 млн. В десяти тестовых на-
борах для 10 переменных охватывается только 100 значений.
Следовательно, из веек значений переменных в их области оп-
ределения при таком тестировании проверяется около 0,04%
значений. Однако благодаря гладкости изменения переменных
между особыми и граничными точками указанного количес-
ства тестов может быть вполне достаточно. Исчерпывающее тес-
тирование в таких случаях практически не достижимо и не це-
цесообразно.
В вычислительных программах переменные часто представ-
лены в виде массивов. При наличии массивов объем тестирова-
ния значительно увеличивается. Для проведения эффективно-
го упорядоченного тестирования при переменных,
образующих массив, необходимо учитывать:
структуру и размер массива, а также наличие в структуре
массива особых точек или подструктур;
изменение области определения и особых точек значений пе-
ременной при расположении данных в различных местах мас-
сива.
В простейшем случае (отсутствие особых точек в одномерной
структуре массива и в значениях переменной) при тестировании
необходимо минимум 3 значения переменной (краевые и про-
межуточные) при ее расположении в 3 точках массива, т. е.
9 тестов. При увеличении размерности массива и появлении
особых точек в его структуре или значениях переменной соот-
167
ветственно возрастает число тестов, необходимых для провер-, г
ки программы. Если область определения переменной включает
значение нуль, то целесообразно тестирование программы при
всех значениях переменной в массиве, равных нулю. Кроме
того, следует задавать все значения переменной в массиве рав-
ными между собой, а также изменяющимися случайно или в со-
ответствии с наиболее характерной закономерностью.
В ряде массивов можно выделить определенные столбцы,
строки или иные подструктуры, имеющие самостоятельное наз-
начение. Такой массив может быть использован для реализации
иерархии подструктур. В этом случае каждая подструктура де-
лится на подструктуры более низкого уровня, пока не полу-
чатся подструктуры, состоящие из отдельных элементов масси-
ва.
При формировании тестов целесообразно задавать их значе-
ния в соответствии с предельными размерами подструктуры, а
также особые и типовые значения элементов в подструктуре.
При этом компоненты остальных подструктур могут быть фик-
сированными на некоторых типовых значениях. Затем может
потребоваться перебор сочетаний типовых и особых значений
каждой подструктуры с типовыми и особыми значениями раз-
меров и элементов остальных подструктур. Перебор значений
может приводить к весьма резкому росту объема тестирования.
В этом случае для уменьшения объема тестирования целесооб-
разен детальный анализ типовых и особых точек реальных мас-
сивов и их подструктур. Выделение и упорядочение особых то-
чек, учет симметрии подструктур и их компонент позволяют
отойти от полного перебора сочетаний тестовых значений и до-
стичь высокого качества тестирования при разумном его объе-
ме.
Для обработки информации и управления широко приме-
няются малоразрядные (8—16 бит) ЭВМ, реализующие системы
команд с представлением операндов (переменных и констант)
в виде чисел с фиксированной точкой (запятой). Такое пред-
ставление данных характерно для встраиваемых управляю-
щих ЭВМ, в которых невелика доля вычислительных алгорит-
мов и арифметических операций (—10%) 134, 561. Исходные
данные для таких ЭВМ получаются в основном путем измере-
ния с ограниченной точностью реальных физических величин
и их квантования для передачи по каналам связи. В результа-
те удается значительно экономить аппаратные компоненты
ЭВМ и емкость памяти по сравнению с универсальными много-
разрядными машинами с плавающей точкой, а также быстрее
выполнять элементарные операции. Однако при этом возника-
ет задача масштабирования используемых перемен-
168
ных и констайФ' ири'вреграмммрораиии. вычисляемых выраже-
ний 1571.
Масштабирование состоит в выборе масштабных коэффициен-
тов для машинного представления рельных физических вели-
чин с учетом особенностей изображения чисел в конкретной
ЭВМ. Для этого производится анализ диапазонов изменения
исходных, промежуточных и результирующих величин и вы-
бор масштабов их изображения в разрядной сетке ЭВМ. При
выборе масштабных коэффициентов анализируются операции
над величинами в соответствии с алгоритмом вычислений и про-
веряются условия корректности вычислений с фиксированной
точкой. В результате масштабирования 14]:
при’ любых операциях результат не должен выходить за
пределы диапазона машинного представления чисел в данной
ЭВМ, в частности, должно быть исключено деление на нуль
(исключение переполнения);
цена младшего разряда машинного представления ис-
ходных, промежуточных и результирующих величин не дол-
жна превышать половины ошибки измерения соответствующих
реальных физических величин (исключение потери точности
вычислений).
Процесс масштабирования зависит от структуры и сложно-
сти конкретных вычислительных алгоритмов. Масштабирование
реализуется несколькими методами: вручную, при разработ-
ке текстов программы; полуавтоматически (по указанию) пу-
тем автоматического анализа текста программы, выделения опе-
раторов, подлежащих масштабированию и возможных значе-
ний коэффициентов с ручным вводом реализуемых масштабов;
а также полностью автоматически при трансляции текстов про-
грамм. Для автоматического масштабирования в трансляторы
с языков высокого уровня вводятся специальные блоки, осу-
ществляющие анализ арифметических выражений, вычисление
масштабных коэффициентов с использованием описаний пере-
менных и констант, а также вставку операций масштабирова-
ния. Протранслироваиная программа в объектном коде, подго-
товленном к исполнению на ЭВМ, в своем составе имеет в явном
виде операции и коэффициенты масштабирования, число кото-
рых желательно минимизировать. При любом методе не исклю-
чены ошибки, что приводит к необходимости дополнительного
тестирования вычислений для проверки корректности масшта-
бирования.
Тестирование масштабирования предназначено
для проверки отсутствия переполнения и потери точности вы-
числений при изменении исходных данных в допустимых диа-
пазонах. В некоторых случаях может быть необходимым тес-
169
тирование при искаженных входных величинах, которые вы-
ходят за заданные пределы. В этих случаях тестируемые про-
граммы должны селектировать искаженные данные для ис-
ключения аномалий и тупиковых ситуациях при вычислениях
(например, в алгоритмы вводятся обходы возможного деления
на нуль).
При достоверных исходных данных необходимо выбрать
сочетания значений тестовых переменных, обеспечивающие
предельные вычисляемые переменные на всех промежуточных
и конечных операциях. Предельные значения тестов целесог
образно подготавливать путем просмотра вычислений снизу
вверх, начиная от выходных результатов. На каждом шаге
могут быть установлены максимальные реальные значения ве-
личин и значения переменных, при которых возможна потеря
точности из-за ограниченного числа разрядов ЭВМ. При по-
шаговом выборе тестов некоторые сочетания переменных охва-
тывают предельные условия масштабирования для нескольких
операций вычислений. Другие сочетания переменных могут
оказаться уникальными и должны найти отражение в исходных
тестовых данных. В результате формируется полная совокуп-
ность тестов, охватывающих весь процесс вычислений с выбран-
ными коэффициентами масштабирования. Тесты для проверки
масштабирования в значительной степени могут покрывать
тесты предельных значений переменных, что позволяет сокра-
щать общий объем тестирования.
3.5.	СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ ПРОГРАММНЫХ
МОДУЛЕЙ
Общая схема автоматизации тестирования программных
модулей. Высокая корректность отдельных небольших про-
грамм может быть достигнута различными ручными методами
без применения ЭВМ для автоматизации их тестирования.
Ручные методы инспекций и контроля позволяют обнаруживать
основную массу ошибок (до 80% 1141), однако необходимы
большие затраты времени и труда для достижения высокого ка-
чества программ. Автоматизация позволяет сокращать длитель-
ность и трудоемкость тестирования и достигать высокого каче-
ства программ при меньших суммарных затратах. Однако сле-
дует учитывать, что средства автоматизации связаны с затра-
тами на их создание и на эксплуатацию (см. § 2. 3), которые
увеличиваются с повышением уровня автоматизации. В ре-
зультате для определенной совокупности программных моду-
лей с учетом их сложности, общего числа, требований к каче-
ству целесообразна такая степень автоматиза-
170
ц и и тестирования, при которой затраты на автоматизацию
оправдываются достигаемым сокращением длительности й сто-
имости разработки заданной совокупности программных моду-
лей. Для этой степени автоматизации могут быть разработаны
или выбраны из имеющихся соответствующие средства тести-
рования, обеспечивающие минимальные совокупные затраты на
создание модулей при заданном их качестве.
При крупных многолетних разработках КП большим кол-
лективом рассмотренный метод оптимизации совокупных за-
трат на разработку модулей с учетом затрат на конкретные
средства автоматизации вряд ли целесообразно применять в
полном объеме. В таких случаях средства тестирования разви-
ваются с целью достижения наибольшей автоматизации процес-
са проектирования для большой группы проектов без ориента-
ции на конкретную совокупность программных модулей. При
разработке конкретного модуля или некоторой группы модулей
используется часть средств из полного набора, которые могут
обеспечить необходимое качество при допустимых затратах на
их эксплуатацию.
Конструктивным представляется анализ всей совокупности
современных средств автоматизации тестирования программ и
рациональной последовательности их применения. В множест-
ве реальных систем, созданных разными организациями, ис-
пользуются различные сочетания методов и средств автомати-
зации тестирования, иногда в иной последовательности, чем
они изложены выше (см. §§ 3.1—3.4). Много данных опублико-
вано о системах, которые ориентированы на один-два метода
тестирования и имеют ограниченный набор средств. Послед-
нее особенно характерно для научнотисследовательских разра-
боток вузов и академических организаций.
Многие современные системы тестирования создавались
эволюционно, путем последовательного расширения функций
и применяемых методов. В отдельных случаях системы тестиро-
вания проектировались комплексно с целью предоставления
создателям программных модулей практически всего спектра
современных средств автоматизации тестирования. Наиболее
полными по применяемым наборам средств автоматизации
тестирования программных модулей являются системы
ЯУЗА-6Д 139], РУЗА (381, АСПП [1], ARGUS, SADAT, AT
LAS, AIDES (76, 94]. Большинство зарубежных систем ком-
плексной автоматизации тестирования созданы крупными спе-
циализированными организациями (TRW, NASA, Western
Electric, Boeing) для проектирования программ высокого ка-
чества, используемых в системах управления и обработки ин-
формации. На основе имеющихся публикаций, а также, исхо-
171
дя из отечественного опыта разработки и эксплуатации систем
ЯУЗА-6Д, АСПП, РУЗА и ПРОТВА, можно сформулировать
требования к системе комплексной автомати-
зации систематического тестирования программных моду-
лей на всех этапах жизненного цикла для выпуска программ-
ного продукта высокого и контролируемого качества.
1.	Система автоматизации тестирования программ должна
обеспечивать доступ пользователей в пакетном и терминальном
режимах, представление данных в символьном и графическом
видах и, в основном, безбумажное проектирование программ.
2.	Система должна использовать достаточно развитую ба-
зу данных проектирования для накопления данных о разра-
батываемых программах, их версиях, планах тестирования, тес-
товых и эталонных данных, выполненных корректировках и
т. д.
3.	Система должна позволять автоматически выявлять
большинство ошибок, обусловленных нарушениями формали-
зованных правил структурного построения модулей и исполь-
зования данных.
4.	Система должна обеспечивать автоматизированное пла-
нирование тестирования и подготовку рекомендаций по систе-
матическому применению методов и стратегий тестирования с
целью достижения максимальной корректности и надежности
программ в условиях ограниченных ресурсов, выделяемых на
тестирование.
5.	Система должна позволять проводить автоматизирован-
ное тестирование программных модулей, в том числе без де-
формации исполняемых программ операторами отладки.
6.	Система должна позволять оценивать достигнутую кор-
ректность программного модуля по выбранным критериям
тестирования и определять основные конструктивные показа-
тели качества 137 ] (логическую и информационную сложность,
сложность связей, длительность счета и т. д.) созданных про-
грамм.
7.	Система должна осуществлять регистрацию всех выпол-
ненных изменений в программах и учет версий программ,
в Которых проведены те или иные корректировки.
Приведенным требованиям, в основном, соответствует гипо-
тетическая система автоматизации тестирования, общая схема
средств которой приведена на рис. 3.14. На схеме выделены ис-
ходные и результирующие данные, а также компоненты, осу-
ществляющие взаимодействие основных средств тестирования
с пользователем. Это взаимодействие обеспечивается средства-
ми управления и подготовки данных для выполнения тестиро-
172
вания, а также средствами редактирования результатов и под-
готовки их к отображению в текстовой и графической формах.
Всю совокупность средств, применяемых при автоматизи-
рованном тестировании программных модулей, можно разде-
лить на: статические — функционирующие без исполнения
тестируемых программ и динамические, при использовании
которых необходимо исполнение тестируемых программ.
В группу статического тестирования входят сред-
ства, автоматизирующие непосредственную формальную про-
верку корректности модулей и выявление ошибок, а также
средства, автоматизирующие получение данных, способствую-
щих без испрлнения программы частичному их контролю и под-
готавливающих выявление ошибок при последующем приме-
нении динамических средств. Непосредственное обнаружение
ошибок и выявление компонент программного модуля, где воз-
можны некоторые виды некорректностей, осуществляется сред-
ствами контроля структурной корректности программы и сред-
ствами контроля записи и чтения переменных. Эти средства об-
наруживают нарушения формализованных правил структур-
ного построения модулей и использования в них переменных.
Средства расчета длительностей функционирования про-
грамм позволяют получить значения и распределения длитель-
ностей счета программы аналитически, без ее исполнения на
ЭВМ. Расчет проводится по тексту программы на языке и в ма-
шинных кодах. В результате расчетов выявляются компонен-
ты программы, требующие, большого времени счета на ЭВМ
из-за возможных алгоритмических или программных ошибок,
а также подготавливаются данные для общей проверки произ-
водительности КП в реальном времени. Эти данные позволяют
обнаруживать ошибки нарушения соответствия длительно-
сти функционирования КП в реальном масштабе времени и ре-
альной производительности ЭВМ (см. гл. 4).
Средства подготовки данных для планирования тестирова-
ния обеспечивают выделение типовых структур в модуле (цик-
лов, альтернатив, маршрутов исполнения) и их упорядочение
по некоторым параметрам. Выделение маршрутов исполнения
программы и условий их формирования позволяет определить
границы областей изменения переменных, влияющие на фор-
мирование тестовых наборов и их объем. В результате стати-
ческого анализа программы автоматически создаются упорядо-
ченные наборы ее характеристик, которые могут быть исполь-
зованы для подготовки множества тестов, а также для контро-
ля полноты проведенного тестирования модулей.
Группу средств динамического тестирования мож-
но разделить на средства, Непосредственно обеспечивающие ис-
173
Исходны» данные
Т ветируемая
программа на
языке програм-
мирования и в
объектном коде
Описание
переменных
Средства управления и
подготовки данных
Средства редактирова-
ния и подготовки к
отображению
Выходные данные 
Нарушения пра-
вил структур-
ной коррект-
ности програм-
м ы
Нарушения пр а*
вил последов а*
тельности за-
писи и чтения
переменных
Значения и рас*
пределение дли*
полнения про-
граммы
Выделенные
циклы, упорядо-
ченные марш-
руты и условия
их формирова-
ния
[Директивы упра-
вления средств а-
ми и их режима-
I	ми
Средства обработки I
директив управления!
системой тестирования
Средства динамическо-
го тестирования
Средства редактиро-
вания и обеспечения
отображения в тексто-
вой форме
ГТ есты и дополни- 1т е л ь и ы а данные		Средства обработки тестов и дополни, телъиых данных
		
Средства подготовки
отладочного задания
и тестов к исполнению
Средства исполнения
тестируемой програм-
мы по отладочному
заданию
Средства обеспечения
отображения в графи-
ческой форме
Реализованные
маршруты и зна-
мен ия перемен-
ных в контроль-
ных точках
Эталонные пра-
вила, маршруты
исполнения про-
граммы и значе-
ния переменных
Средства регистрации
и селекции данных
о результатах
тестирования
Состав и с п ол•
| Средства учета тестов |
—9* и оценки полноты тес- —*
| тировения I
и характерно-
Средства учета изме- 1
нений и версий про-^
граммы 1
Журнал умета
изменений и ре-
г и с трации вер-
сий программы
Рис. 3.14. Схема средств комплексной системы автоматизации тестирования-программных модулей
полнение программ в соответствии с отладочными заданиями,
и вспомогательные средства, учитывающие выполненное тес-
тирование, его результаты и проведенные корректировки.
В первую группу входят средства подготовки к исполнению от-
ладочного задания, которое состоит в управлении тестируемой
программой. Средства исполнения тестируемой программы по
отладочному заданию обеспечивают контролируемое функцио-
нирование программы при тестовых исходных данных. При
этом в различных течках программы осуществляется регистра-
ция промежуточных и конечных результатов, определенных от-
ладочным заданием. Контролируемое исполнение программы
позволяет накапливать данные для их последующей селекции и
обобщения средствами подготовки данных о результатах тес-
тирования. Эти данные отображаются в текстовой и графичес-
кой формах в виде реализованных маршрутов исполнения про-
граммы и значений переменных в заданных контрольных точ-
ках. В отдельных случаях полученные результаты могут срав-
ниваться с эталонными значениями для автоматического выяв-
ления ошибок. Кроме того, результаты проведенного тестиро-
вания накапливаются и обобщаются для оценки полноты вы-
полненного тестирования и достигнутой корректности програм-
мы.
Вспомогательные средства, включенные в эту группу, пред-
назначены для накопления и учета тестов, по которым проведе-
ны проверки, и для учета выявленных ошибок и их характе-
ристик. Эти данные позволяют контролировать степень выпол-
нения планов отладки и оценивать уровень достигнутой про-
верки каждого программного модуля. Для этих же целей ис-
пользуются средства учета проведенных изменений в програм-
ме, которые позволяют более полно квалифицировать выявлен-
ные ошибки и учитывать процесс модифицкации программы.
Эти средства учитывают версии одного и того же программно-
го модуля и регистрируют особенности каждого варианта, ко-
торые отображаются в журнале учета изменений и регистрации
версий программы (см. гл. 5).
Средства контроля структурной корректности программ. Исходной
информацией для структурного контроля являются тексты программных
модулей на соответствующем языке программирования (ряс. 3.15). По
тексту программы строится диагностическая графовая модель програм-
мы. Процесс построения модели состоит в выделении элементарных опе-
раторов, их нумерации и составлении списка связей этих операторов по
адресам передач управления между командами, составляющими опера-
торы. При этом предполагается, что все связи между операторами описа-
ны явно в тексте программы или в комментариях, которые могут быть
использованы для полной конкретизации связей. С целью унификации
процесса построения диагностической модели для программ, написан-
ных на различных языках программирования, для выделения процеду-
176
I 1 J.
Рис. 3-15- Схема, контроля структурной корректности программ
ры построения модели от части, анализирующей текст исходного описа-
ния, вводится некоторый промежуточный язык описания программы —
контрольный язык. Специальный транслятор, обеспечивает перевод ис-
ходного текста программы на контрольный язык. Описание программы
на контрольном языке служит исходной формой ее представления для
построения модели [50].
Для обеспечения анализа моделей необходимо ограничить объем
данных, представляющих описание программ. Для этого применяется,
с одной стороны, ограничение объема текста программных модулей, а с
другой — укрупнение операторов на контрольном языке до уровня
условных и безусловных переходов в программе. Ограничение размера
программных модулей широко практикуется при разработке сложных
КП на уровне 30—50 предложений языка программирования высокого'
177
уровня, или 300—500 автокодных предложений, или в пределах
3—5 страниц текста программы. Выделение операторов для модели
программы на контрольном языке в соответствии с условными и безус*
ловнымн переходами представляет собой объединение 5—10 команд на
уровне автокода или 1—3 строк текста на языке высокого уровня. В ре-
зультате модель программы можно ограничить 50—100 операторами на
контрольном языке.
В процессе построения модели программы выполняется контроль
соблюдения ограничений объема программы и правил использования ос-
новных логических конструкций и операторов. Выделяются логические
конструкции, содержащие неявные условия и требующие дополнитель-
ного описания. Последовательное выделение элементарных компонент
и структурированных частей программ позволяет выявить участки про-
граммы, где нарушены правила структурировании [21, 27, 371. В ре-
зультате выявляются и отображаются ошибки построения структуриро-
ванных программ, которые не позволяют завершить построение графо-
вой модели программы и проводить дальнейший структурный контроль
После нх устранения может проводиться автоматический структурный
контроль.
В корректно составленной программе, через каждый оператор дол-
жен проходить хотя бы один маршрут исполнения программы. Возмож-
ны два случая нарушения условия принадлежности оператора хотя
бы одному маршруту. Первый заключается в том, что некоторый опера-
тор вообще не достигается ни по одному нз маршрутов, идущих от вхо-
дов программы. Второй состоит в том, что из некоторого оператора или
их совокупности не существует ни одного пути, ведущего хотя бы к од-
ному выходу из программы, т. е. образуются тупиковые пути или циклы
Для контроля корректности структуры программы может приме-
няться эффективный метод с использованием матрицы достижимости
[50]. С целью построения эффективной по вычислительной трудоемко-
сти процедуры получения матрицы достижимости применяется списко-
вая форма задания графа. Алгоритм построення матрицы на основе мо-
делирования процесса движения по графу программы состоит в следую-
щем. В соответствии со списком связей последовательно выбираются
вершины графа, начиная с начальной. Очередная вершина становится
как бы источником, от которого дальше распространяется волна При
прохождении волны по графу отмечаются н заносятся в матрицу дости-
жимости все достигнутые вершины. Вершины, достигнутые волной ра-
нее, из дальнейшего рассмотрения в качестве источников исключаются
Последнее условие обеспечивает однократное прохождение цикличес-
ких участков графа и достижение всех возможных вершин по кратчай-
шим маршрутам. Условие окончания процесса соответствует тому, что
среди множества вершин, достигнутых волной на очередном шаге, нет
нн одной вершины, которую волна не достигла бы. Таким образом, про-
цесс построения матрицы достижимости для одной вершины связан с
однократным просмотром всех вершин графа анализируемой програм-
мы.
При использовании матрицы достижимости задача нахождения лиш-
них участков сводится к определению множества вершин, которые не
достижимы из начальных вершин. Условие принадлежности какой-либо
вершины к числу тупиковых вершин состоит в недостижимости из нее
ии одной конечной вершины. Выделение связных компонент, образован-
ных лншннмн или тупиковыми вершинами, состоит в нахождении в мат-
рице достижимости мажорирующих столбцов [50]. Выделенке лишних
и тупиковых циклических участков определяется путем сопоставления
строк матрицы достижимости. Номера строк матрицы достижимости.
178
диагональные элементы которых равны 1, образуют циклы. Цикличес-
кая компонента графа программы является лишней, если значения об-
разующих ее элементов в строке начальной вершины равны нулю, и ту-
пиковой, если значения образующих ее элементов в столбце конечной
вершины равны нулю.
Средства контроля закиси и чтения переменных. Контроль записи
И чтения переменных без исполнения программы включает две задачи
(рис. 3.16): построение диагностической модели программы с учетом ин-
формационных связей и просмотр модели с целью выявления недопусти-
мых сочетаний операций считывания и записи иелнчин. Схема структур-
ных связей в виде направленного графа программы используется как
база для однозначного представления на модели программы информа-
ционных связей между операторами. Для этого данные об управляющих
связях каждого оператора дополняются списками операций считывания
Рис. 3.16. Схема контроля записи н чтения переменных
179
и записи переменных. Для проверки корректности использования памя-
ти необходимо установить реализованную при выполнении операций в
программе последовательность записи и чтения каждой переменной и
последовательность обращения к устройствам ЭВМ.	•'»
Диагностическая модель программы отражает статические инфор-
мационные связи с подробностью, позволяющей по каждой операции
записи и считывания указывать нмя величины и имя регистра, кото-
рый используется для хранения ее значения. При этом структурные свя-
зи должны быть представлены с детальностью, обеспечивающей одно-
значное описание порядка исполнения операций записи н считывания.
Это приводит к тому, что размер моделей контролируемых программ,
встречающихся на практике, оказывается большим.
По всем маршрутам, ведущим из начальной вершины программы в
конечную вершину, выполняется контроль наличия запрещенных со-
четаний операций по всем наименованиям величин и номерам регист-
ров. Условиями правильной реализации операций являются:
предварительная запись в ячейку оперативной памяти значения
считываемой из Нее информацяи;
наличие в индексном регистре значения индекса требуемого наиме-
нования;
результат, который хранится на сумматоре, должен соответствовать
величине, использующейся в дальнейших вычислениях, илн сумматор
должен быть установлен в нулевое состояние.
Состояние в этих случаях характеризуется парой: именем (номе-1
ром) ячейки памяти нлн регистра и именем величины, значение которой
хранится в ячейке или на регистре. Однократность просмотра достига-
ется выделением в модели программы независимо проверяемых частей
и заданием правила упорядоченного просмотра с запоминанием уже про-
веренных частей программы. Составляются списки операций считыва-
ния и записи с указанием имен величин, имен регистров н частей выде-
ленных участков, к которым относятся эти операции. После выделения
участков операции считывания и записи перенумеровываются в соответ-
ствии с порядком их следования и принадлежностью командам участков
программы. Это делается для удобства просмотра, когда необходимо
определять место конкретной операции на участке.
Контроль записи и чтения переменных сводится к последовательно-
му просмотру частей программы, которые образуют маршруты, веду-
щие от места считывания некоторой величины с регистра ко входам про-
граммы. При просмотре устанавливается (см. § 3.4):
существует ли запись этой величины вообще;
на всех ли путях, ведущих ко входам, есть запись соответствующей
величины перед считыванием с того же регистра;
не забивается ли считываемая величина записью другой величины,
т. е. нет ли между записью и считыванием дополнительной записи на тот
же регистр другой величины.
Проверка программы выполняется последовательно по регистрам
или рабочим ячейкам. Просмотр идет по маршрутам программы от выхо-
да до начала программы либо до нужной операции записи с регистра-
цией тех нз них, на которых нет нужных операций записи. При этом от-
мечаются ошибки, отсутствия записи на зафиксированном маршруте
и осуществляется переход к проверке параллельных путей, образуе-
мых приходами на проверенную часть программы. В ходе проверки на-
ряду с установлением отсутствия записи может быть зафиксирована за-
пись величины, имеющей другое наименование. В этом случае отмечает-
ся ошибка забивания н фиксируется часть программы, иа которой эта
ошибка имеет место.
180
Достаточно эффективный метод проверки основан на организации
последовательного независимого просмотра упорядоченных час-
тей модели программы с предварительным выделением в модели толь-
ко той информации, которая имеет непосредственное отношение к кон-
тролируемым величинам и к регистрам. При проверке использования
каждого регистра или ячейки памяти модель, представляющая описание
программы или некоторой ее части, преобразуется. В результате ис-
ключаются все те вершины, команды которых не используют контроли-
руемый регистр.1 Прн этом размер модели уменьшается, а просмотр для
проверки условий наличия запрещенных сочетаний операций записи-
считывания сводится к попарной проверке связанных между собой вер-
шин.
Средства расчета длительностей функционирования программ.
С использованием графовой модели программы может быть автомати-
чески построен массив длительностей исполнения отдельных операто-
ров (рис. 3.17). При этом используется список операторов с нх гранич-
ными адресами в программе, полученный прн построении графовой мо-
дели, и текст исследуемой программы в объектном коде ЭВМ, для кото-
рой она предназначена. Длительности исполнения отдельных команд,
нз которых складываются веса операторов, определяются по кодам опе-
раций нз таблицы. Эта таблица может содержать не только длительно-
сти исполнения команд, но и обращение к подпрограммам для вычисле-
ния значений длительности с учетом некоторого параметра (напрнмер,
значение сдвига числа в соответствующей операции), Вероятности услов-
ных переходов либо принимаются равными 0,5, либо задаются разработ-
чиков на основе его представлений о динамике работы данной програм-
мы. Для оценки вероятностей ветвления при исполнении программы ис-
пользуется модель внешней обстановки, соответствующая нормальным
н предельным условиям функционирования комплекса программ (см.
§ 4.1). Такая модель позволяет оценить средине н предельные значения
количества реализаций циклов и вероятности условных переходов,
определяющие маршруты обработки информации в КП.
Для приведения графа к ациклическому виду и уточнения его
структуры используются Программы взаимодействия разработчика с
ЭВМ двух видов. Первый вид программ автоматически выделяет цикли-
ческий подграф модели, относительно которого требуется дополнитель-
ная информация от разработчика, и осуществляет формирование и вы-
дачу конкретного запроса. Вторая группа программ производит необхо-
димую трансформацию весов и топологии выделенного участка на осно-
ве данных. введенных в машину разработчиком в качестве ответа.
Для анализа применяются эквивалентные преобразования весов
и структуры графовой модели до приведения ее к ациклическому гра-
фу, для которого и рассчитываются статистические характеристики дли-
тельностей [50J. Эти преобразования производят такую трансформацию
взвешенной графовой модели, которая не изменяет значения исследуе-
мого параметра. Наиболее важными являются два частных вида преоб-
разований: эквивалентная замена и эквивалентная разметка.
Эквивалентная замена заключается в переходе от сложной графовой
модели, интегральные параметры которой известны, к более простой
стандартной структуре, интегральные параметры которой совпадают с
параметрами исходной модели. Она полезна прежде всего в том случае,
когда отдельные операторы исследуемой программы представляют собой
обращения к некоторым подпрограммам. Эквивалентная замена позво-*
ляет вставить на место подпрограммы подграф, полностью отражающий
динамические свойства заменяемой подпрограммы.
181
Рис. 3.17. Схема расчета длительностей функционирования программ
182
Эквивалентной разметкой является преобразование весов и тополо-
гии графовой модели, связанное с внесением в нее разработчиком ин-
формации о динамике работы программы. При этом, в частности, могут
исключаться маршруты, ие реализуемые по информационным условиям,
или вместо циклических участков подставляться подграфы с их средни-
ми и предельными характеристиками.
Для проведения расчетов длительностей необходимо с помощью
эквивалентных преобразований устранить из модели программы циклы
и привести ее к ациклическому виду, применяя в основном эквива-
лентную разметку. Каждый из полученных' циклических подграфов'в
дальнейшем кодируется в машинной памяти как отдельный граф. Такой
подграф подвергается топологическому анализу с помощью программы
классификации. Если оказывается, что он принадлежит к одному из ав-
томатически распознаваемых классов, то производится автоматическая
эквивалентная разметка цикла. Если все циклы в программе удается
разметить автоматически, то осуществляется расчет интегральных ха-
рактеристик длительностей исполнения Программы при вероятностях
ветвления, равных 0,5. Кроме того, рассчитываются экстремальные ха-
рактеристики. В противном случае выделенный цикл распечатываетси
для ручной разметки.
Ответы на выданные запросы для разметки циклов вводятся в ма-
шину в виде макрокоманд, которым предшествует номер вопроса. Про-
цедуры, которые производятся в зависимости от ответа разработчика,
состоят, по существу, из одних и тех же стандартных действий над взве-
шенной графовой моделью: исключить или добавить дугу; исключить,
дублировать или увеличить веса вершин подграфа с выделенным входом
и выходом; заменить вероятность (или длительность) дуги.
Далее формируется список, где маршруты расставлены в требуемом
порядке. Благодаря этому обеспечивается автоматический контроль ра-
боты предшествующих программ: если в графе остался некий цикл, то
входящие в него вершины не попадут в упорядоченный список. Веса вер-
шин графовой модели хранятся в виде массивов, в которых их располо-
жение повторяет порядок следования номеров вершин в списковом за-
дании графа.
По заданному графу и массивам весов последовательно для всех
маршрутов графа рассчитываются интегральные характеристики про-
граммы. После рекуррентных расчетов, выделяются экстремальные
маршруты. По рассчитанным для всех промежуточных вершин величи-
нам отбираются дуги, входящие в самый длинный или кратчайший путь.
Из отобранных дуг без перебора выделяются дуги, образующие мар-
шрут из входной вершины в выходную или совокупность таких кратчай-
ших (длиннейших) маршрутов/ если нх окажется несколько. Наиболее
вероятный и наименее вероятный маршруты строятся аналогично.
Информация полученная в результате анализа взвешенной графо-,
вой модели заносится в виде паспорта программы в архив'зиачеинй дли-
тельностей. Такие паспорта программ позволяют последовательно, на-
чиная с нижних иерархических уровней, рассчитывать длительность ис-
полнения групп н комплекса программ в целом. При этом1 каждая про-
грамма, благодаря операциям эквивалентной замены, учитывает дли-
тельность исполнения всех программ, вызываемых как непосредствен-
но, так и программами более низких уровней.
Средства подготовки данных для планирования тестирования про-
граммных модулей. Планирование тестирования — процесс творческий
и средства автоматизации предназначены, в основном, для подготовки
исходных данных, используемых при планировании. Эту информации
можно разделить на три группы данных о циклах в программе; о
183
маршрутах исполнения программы и о предикатах, определяющих мар-
шруты исполнения программы н границы областей изменения пере-
менных, Для подготовки этих данных используется текст программы на
языке программирования и взвешенная графовая модель программы ।
(рнс. 3.18). В последней учитываются вероятности ветвления в верши-
нах графа и длительности исполнения дуг на маршрутах. Взвешенная
графовая модель может подготавливаться специально средствами авто-
матизации планирования тестирования или строиться средствами конт-
роля структуры н определения длительности исполнения программы.
В этом случае образуется глубокая конструктивная связь между всеми
средствами статического тестирования программ.
В программе прежде всего автоматически выделяются циклы опи-
санными выше методами. В циклах определяются маршруты, подлежа-
щие тестированию. Для этого используются указания разработчика о
стратегии выделения маршрутов при тестировании циклов. Кроме того,
в содержание стратегии вводятся указания о количестве итераций цик-
лов н их связях с маршрутами исполнения циклов. В результате разра-
ботчику отображаются данные о маршрутах в циклах, которые подле-
жат тестированию по выбранной стратегии. Возможно автоматическое
выделение некоторых циклов, которые реально не исполняются по усло-
виям изменения переменных, использующихся в предикатах маршру-
тов. Разработчик может выделить циклы и маршруты, подлежащие ис-
ключению из планов автономного тестирования циклов илн при тести-
ровании полных маршрутов, содержащих циклы.
По данным о циклах, выделенных для автономного тестирования,
рассчитывается суммарное число тестов в плане н суммарная сложность
тестирования циклов. Если сложность тестирования превышает реаль-
ные ресурсы, которые могут быть выделены для выполнения этих работ,
то необходимо упростить стратегию тестирования циклов и повторить
расчеты. Выделение циклов и маршрутов в них позволяет преобразо-
вать программу к ациклическому виду. При этом циклы заменяются
их ациклическими эквивалентами с фиксированным и ограниченным
числом итераций. Для выделения тестируемых маршрутов в такой ацик-
лической программе разработчик должен указать критерий, по которо-
му следует формировать маршруты. Кроме того, разработчик указывает
стратегию для составления упорядоченного списка маршрутов, по кото-
рому надлежит планировать тестирование. Упорядочение маршрутов
производится по длительности их исполнения или по вероятности реа-
лизации при случайных данных на входе программы. При подготовке
первичных данных для планирования тестирования вероятности ветв-
ления в условных переходах могут приниматься равными 0,5. Если ряд
маршрутов может быть нереализуемым по сочетаниям условий в верши-
нах графа программы, то такие маршруты целесообразно исключать из
последующего анализа.
В результате составляется список маршрутов, упорядоченных по
выбранной стратегии. По этим маршрутам рассчитывается полное чис-
ло тестов н суммарная сложность тестирования структуры программы
в соответствии с выбранным критерием выделения маршрутов. Коррек-
тировка планов возможна за счет изменения критерия выделения марш-
рутов и за счет ограничения числа выделенных для тестирования марш-
рутов из их общего упорядоченного множества.
Выделенные для тестирования маршруты дополняются данными о
значениях переменных в предикатах условий на каждом маршруте.
Для этого используются текст программы на языке программирова-
ния и описание переменных. По полученным соотношениям между пе-
ременными в предикатах условий строятся границы областей измене-
184
-ч
Рис. 3.18. Схема подготовки данных для планирования тестирования
!«5
ния переменных для'каждого нз маршрутов и для программы в целом.
По числу границ областей изменения переменных осуществляется
оценка числа тестов, необходимых для проверки процессов обработки
данных в анализируемой программе.
В программе встречаются участки, где производятся вычисления
и преобразования переменных по более или менее сложным алгебраи-
ческим выражениям. При наличии таких вычислений необходимо пла-
нировать тестирование, позволяющее оценить точность получаемых ре-
зультатов с учетом масштабирования. Подготовку планов тестирова-
ния иа точность вычислений формализовать трудно, поэтому средства
автоматизации только выделяют вычислительные части программы,
содержащие операции умножения и деления, где возможны потери
точности вычислений. Выделенные выражения отображаются разработ-
чику для подготовки тестов.
Характеристики сложности тестирования областей в совокупно-
сти с характеристиками сложности тестирования структуры программы
и циклов позволяют оценить реализуемость плана тестирования про-
граммного модуля. Кроме того, рассматриваемые средства представ-
ляют разработчику достаточно полные сведения о циклах, маршрутах
и переменных, которые необходимо учитывать при планировании тес-
тирования. Автоматический расчет и упорядочение информации об
особенностях рассматриваемой программы, а также отображение этих
сведений в компактной и наглядной форме, позволяют сделать процесс
тестирования более эффективным и экономичным.
Основная часть данных для планирования тестирования может
быть получена автоматическим расчетом по тексту программы с исполь-
зованием указаний о критерии выделения и стратегии упорядочения
маршрутов. Диалог разработчика со средствами автоматизации целе-
сообразен для уточнения критерия и стратегии образования маршрутов
в зависимости от сложности тестирования, а также для исключения цик-
лов н ациклических маршрутов, которые не реализуются по условиям
в предикатах. Диалог может также быть полезным прн подготовке
взвешенной графовой модели программы, когда необходимо ввести
реальные вероятности ветвления в вершинах графа и характеристики
итераций циклов. Однако первичные данные для планирования тести-
рования можно получить в автоматическом режиме расчетов без диа-
лога с разработчиком.
Средства исполнения тестируемых программ по отладочному за-
данию. Специфика исполнения программ при тестировании состоит в
том, что на любом шаге должна быть доступна информация о ходе и ре-
зультатах процесса реализации программы. Необходимо иметь возмож-
ность селектировать, регистрировать, контролировать и отображать
эту информацию в форме, удобной для анализа н обобщения [34, 45].
Для этого тем или иным путем должен быть нарушен естественный ход
исполнения программы для выполнения процедур регистрации ее со-
стояния и получаемых результатов. Однако эти нарушения не должны
влиять иа итоговые и промежуточные результаты функционирования
тестируемых программ.
Исполнение программы осуществляется последовательно во вре-
мени, по шагам в соответствии с кодами операций, содержащихся
в тексте программы. На каждом шаге осуществляется преобразование
исходных данных н определение преемника исполняемого оператора.
Значения переменных, полученные после исполнения очередного опе-
ратора программы, используются другими операторами в качестве
исходной информации на последующих шагах программы. Если в хо-
де исполнения программы регистрировать последовательность опе-
186
раторов, реализуемых на каждом шаге, то получится трасса нли
маршрут исполнения программы, который зависит только от исходных
данных.
Для регистрации результатов исполнения каждого оператора не-
обходимо осуществить разрыв нх естественного ис-
полнения в ЭВМ и вставить операторы регистрации. Это может
быть осуществлено методами вставок и моделирования (интерпретации)
каждой команды. При методе вставок заранее выделяются в
тексте программы контролируемые операторы и после каждого из них
вставляется текст регистрирующей программы или операторов ухода
на группу программ регистрации, селекции и отображения промежу-
точных данных (рис. 3.19). Текст тестируемой программы прн этом рас-
ширяется и деформируется за счет операторов регистрации.
Вставка операторов регистрации в текст программы производится
вручную или автоматически. Наиболее просто осуществляется вставка
операторов с точечной областью действия, т. е. регистрирующих ре-
зультаты после исполнения конкретного оператора тестируемой про-
граммы. Операторы, регистрирующие результаты на некотором участ-
ке исполнения программы нлн при выполнении заданного условия,
требуют исполнения программы в режиме интерпретации. В этом
случае подключение операторов регистрации производится управляю-
щей программой интерпретатора, которая в заданном участке включа-
ется на каждом шаге после исполнения очередного оператора.
Включение операторов регистрации промежуточных данных мо-
жет производиться на уровне исходных текстов на языке программи-
рования и на уровне объектных кодов исполняемой программы. В пер-
вом случав'после объединения текста тестируемой программы с текстом
регистрирующих операторов полученная программа транслируется в
объектный код. При тестировании исполняется программа деформи-
рованная операторами регистрации. При этом введение нли исключе-
ние операторов регистрации требует перетрансляции исходного текста
программы. Перетрансляцнн оказываются достаточно трудоемкими.
Рис. 3.19. Схема регистрации результатов исполнения программы
методом вставок
187
что снижает эффективность тестирования. После завершения тестиро?
вания операторы регистрации исключаются и требуются повторный
трансляции и тестирование без контроля промежуточных данных для
дополнительной проверки правильности исполнения программы после
исключения средств регистрации.
Возможно включение операторов регистрации в текст программы
на уровне объектных кодов. В этом случае протранслированные тести-
руемая программа и операторы регистрации объединяются на уровне
загрузочного модуля с последующим редактированием связей. Объе-
динение осуществляется специальными технологическими программа-
ми, которые определяют адреса вставки операторов с использованием
исходного текста и паспорта тестируемой программы. При этом исход-
ный. текст транслируется однократно и программа перезагружается
прн каждом изменении состава операторов регистрации. Исполняемая
программа деформируется н расширяется за счет операторов регист-
рации и требует дополнительной проверки после нх исключения.
Метод моделирования (интерпретации) ис-
полнения тестируемых программ позволяет использовать текст програм-
мы в объектном коде, каждая команда которой моделируется в соот-
ветствии с логикой операций данной ЭВМ (рис. 3.20). Разрыв процесса
исполнения программы после каждой команды может осуществляться
аппаратно. Для этого в ЭВМ должен быть предусмотрен режим поко-
мандного функционирования тестируемых программ. После выполне-
ния каждой команды аппаратным способом управление передается
программе регистрации, которая анализирует задание на контроль и
регистрацию. Если есть необходимость, то регистрируется состояние
памяти н основных устройств ЭВМ в момент прерывания, а также в
соответствии с заданием селектируются данные для накопления и по-
следующей обработки. При отсутствии указаний на регистрацию пре-
рывание восстанавливается н исполняется очередная команда програм-
мы.
Наиболее широко для регистрации промежуточных данных прн
тестировании применяется покомандное программное моделирование
тестируемой программы (рис. 3.21). Сущность его состоит в том, что на
каждом шаге анализируется содержание операции объектного крда н
значения переменных тестируемой программы и программой-интерпре-
татором моделируется функционирование устройств ЭВМ при этих
данных. Для этого в интерпретаторе производится:
Тестируемая
программа
Программа —
интерпретатор
команд
Операторы
регистрации
Рнс. 3.20. Схема регистрации результатов исполнения программы
методом интерпретации каждой команды
188
Рис. 3.21. Схема исполнения тестируемых программ и регистрации
результатов методом интерпретации
1S9
формирование кода адреса очередной команды, подлежащей ис-
полнению, и его запоминание в памяти, моделирующей регистр команд;
анализ кода операции и подготовка программы, моделирующей ис-
полнение этой конкретной операции на ЭВМ;
моделирование исполнения очередной операции в соответствии с
ее кодом и исходными данными;
запоминание полученных результатов после нсполнения опера-
ции и селекция данных для регистрации н последующей обработки;
фиксирование полученного текущего состояния устройств моде-
лируемой ЭВМ и переход к следующей интерпретируемой команде.
Некоторое трудности может вызывать выбор следующей команды
при интерпретации условных переходов. В этом случае код адреса оче-
редной команды формируется с учетом результатов выполненной опе-
рации или некоторых данных, полученных ранее. Моделирование ус-
ловного перехода состоит в формировании в зависимости от признака
условия либо адреса очередной команды плюс единица, либо в выборке
адреса Из адресного поля команды условного перехода.
Преимущества интерпретации при тестировании состоят в отсут-
ствии деформации тестируемой программы для регистрации промежу-
точных данных и' в возможности моделирования ЭВМ с произвольны-
ми системами команд. Последнее, в частности, означает, что иа техно-
логической ЭВМ можно проводить тестирование программ, система
команд объектного кода которых отличается от системы команд техно-
логической ЭВМ. Поэтому интерпретация широко применяется в адап-
тируемых кросС-системах для тестирования программ специализиро-
ванных н Микро-ЭВМ [38, 39, 57].
Однако метод интерпретации требует для исполнения каждой
команды моделируемой программы в среднем 50—100 операций в моде-
лирующей программе. В результате исполнение тестируемых программ
замедляется почти на два порядка. При тестировании больших групп
программ зачастую оказывается, что имеющиеся резервы оперативной
памяти в технологической ЭВМ не достаточны для их размещения. Если
часть тестируемой группы программ, глобальные переменные или кон-
станты размещаются во внешней памяти, то иа их вызов в оперативную
память может затрачиваться значительное время. Это приводит к до-
полнительному снижению скорости исполнения тестируемых программ
еще на один-два порядка. Поэтому метод интерпретации наиболее эф-
фективно используется для тестирования программных модулей или
небольших групп программ, полностью размещающихся в оператйв-
ной памяти технологической ЭВМ.
Средства регистрации и селекции данных о результатах тестиро-
вания. Регистрация выходных и промежуточных данных тестируемых
программ производится в кодах исполняющей ЭВМ. которые не удобны
для анализа. Тем не менее, при отсутствии необходимых ресурсов ЭВМ
приходится с этим мириться и вручную преобразовывать значения ве-
личии и адресов из объектного кода в их символьное представление на
уровне языка программирования. Этот способ наиболее широко при-
меняется при тестировании программ на встраиваемых, специализи-
рованных и микро-ЭВМ, функционирующих в реальном времени. Та-
кие ЭВМ не имеют ресурсов для дополнительных технологических
программ или эти ресурсы очень ограничены.
В ряде случаев применяются специальные трансляторы данных
зарегистрированных при тестировании из объектного кода на язык
программирования. Транслятор использует описания переменный,
текст тестируемой программы на языке программирования и ее паспорт.
В результате трансляции данные, полученные при тестировании, пре-
190
образуются в форму, удобную для анализа. Переменные н константы
получают символьные значения в соответствии с нх именами и описа-
ниями, а адреса команд отображаются номерами операторов или меток
исходного текста программы. Все данные селектируются, редактиру-
ются н группируются по заданию на тестирование, и представляются
иа экранах дисплеев или на цнфропечати.
Для обнаружения и локализации ошибок необходима промежу-
точная информация о результатах тестирования и реализованных
маршрутах исполнения программ. На практике чаще всего промежу-
точная информация регистрируется по мере необходимости и точки ре-
гистрации определяются интуитивно с большой избыточностью. В этих
точках фиксируются состояния устройств ЭВМ, адреса н значения пе-
ременных, что обеспечивает анализ маршрутов исполнения програм-
мы и реализованных потоков данных. Интерпретация н прокрутка
программ позволяет получить состояние основных устройств ЭВМ на
каждом шаге исполнения тестируемой программы. Это обеспечивает
возможность анализа процесса вычислений н преобразования каждой
переменной на любой стадии.
Однако такой метод при каждом тестовом прогоне приводит к ре-
гистрации огромВого количества промежуточных результатов тести-
рования, Гелекция и анализ которых требуют больших затрат. После-
довательный перебор тестовых данных и маршрутов исполнения про-
граммы не гарантирует необходимую полноту тестирования и в то же
время многие результаты тестирования многократно повторяются.
Кроме того, регистрация всех промежуточных данных значительно (в
сотни раз) замедляет процесс исполнения тестируемой программы и
требует соответствующей емкости памяти ЭВМ.
Поэтому возникла задача более рациональной организации тес-
тирования путем выделения и регистрации только минимума проме-
жуточных результатов, а также автоматизированного анализа для
обнаружения некоторых'типов ошибок. Основная идея состоит в одно-
кратном оптимальном планировании распределения точек регистра-
ции состояния программы н переменных при тестировании и в обеспе-
чении возможности многократного анализа зарегистрированных н на-
копленных в памяти результатов тестирования.
Эту задачу целесообразно решать поэтапно 131] (рис. 3.22). На
первом этапе распределяется минимальное число точек регистрации,
позволяющих однозначно идентифицировать маршруты исполнения
программы н условия их реализации. Оценивается объем информации,
который мойсет быть получен по точкам регистрации при тестировании,
а также достигаемая полнота проверки программ при обработке всех
зарегистрированных данных. Далее, на втором этапе, производится
размещение операторов регистрации по тестируемой программе для
накопления промежуточных результатов в базе данных. В процессе
тестирования зарегистрированные данные о значениях переменных н
координатах маршрутов исполнения программы оперативно селекти-
руются н обрабатываются. Накопленные В’ базе данных результаты
тестирования анализируются независимо и асинхронно от моментов
их получения иа третьем этапе. При этом данные дополнительно селек-
тируются и редактируются.
Такая трехэтапная схема тестирования и анализа результатов по-
зволяет минимизировать время для тестирования н реализации опе-
раторов регистрации и многократно анализировать накопленные дан-
ные тестирования без повторения исполнения программы. Благодаря
накоплению результатов тестирования в базе данных процессы тести-
рования н анализа результатов могут быть разделены во времени. При
Рис. 3.22. Схема трехэтапной регистрации н анализа результатов
тестирования
192
этом промежуточные данные регистрируются с минимальными затра-
тами времени, что особенно важно при тестировании программ реаль-
ного времени. Обработка и анализ результатов не имеют жестких вре-
менных ограничений н могут производиться многократно по .мере не-
обходимости.
Использование этого метода регистрации имеет значительные осо-
бенности при тестировании структуры программ и при анализе потоков
данных. Рассмотрим сначала регистрацию при тестировании струк-
туры программ. Выделение точек регистрации и минимизация
их числа.зависит от'структуры графа программы/В .ациклическом гра-
фе типа дерево Г,, (см. рнс. 2.3) достаточно фиксировать исполнения
каждой команды после завершения ветвления в самой Широкой час-
ти графа. В этом случае регистрация предшествующих ветвлений яв-
ляется избыточной. Для асимметричного графа Гг однозначное опре-
деление маршрута может быть произведено, если регистрируется ис-
полнение каждой из боковых ветвей; Тогда центральный маршрут рас-
сматривается как альтернатива при отсутствии реализации Хотя бы1
одного из боковых. В графе Г3 необходимо регистрировать прохожде-
ние'после ветвления одной из дуг. Это позволяет однозначно устано-,
вить каждый маршрут исполнения программы,-если вычислять.альтер--
нативные .незарегистрированные дуги. В результате минимальное чис-
ло точек регистрации для однозначной идентификации, маршрутов не-,
полнения -программ в графах Г2 и Г3 соответствует числу вершин вет-
вления, а в графе Г, равно удвоенному числу вершин ветвления иа
ннжнем иерархическом уровне, что значительно меньше общего числа
вершин.
В общем случае для выделения минимального числа точек реги-
страции исполняемых маршрутов необходимо построить граф програм-
мы по управлению и последовательно проанализировать его структу-
ру и образующиеся маршруты. Для выделенных точек разрабатыва-’
ются операторы регистрации, которые- прерывают естественный про-
цесс исполнения программы и фиксируют состояние устройств ЭВМ в
этих точках. Полученные результаты накапливаются в базе данных
тестирования, которые анализируются на- третьем этапе. В процессе
анализа полностью восстанавливаются все точки ветвления, входящие'
в каждый маршрут при реальном исполнении-программы иа заданных
тестах. Эти данные позволяют выявить всю совокупность маршрутов,
исполненных в процессе тестирования, и оценить полноту покрытия
структуры программы протестированными маршрутами.
Особое значение минимизация точек регистрации приобретает при
анализе маршРУт°в исполнения в больших группах программ. В этой
случае пОлное фиксирование всех точек ветвления в модулях и передач
управления между модулями становится практически невозможным, и
необходимы радикальные меры по сокращению объема^ регистрируемой
информации. Интуиция специалистов, осуществляющих тестирование,
позволяет рационализировать выделение регистрируемых данных.'
Одиако обычцо такое выделение осуществляется без обнаружения и
локализации ошибок определенного типа на основе предварительного
анализа результатов тестирования, Систематический анализ структу-
ры группы программ и размещение операторов регистрации до начала
тестирования, позволяют более полно с минимальными затратами тес-
тировать процесс исполнения 'И корректность маршрутов в группе
программ. Накопление результатов тестирования.в базе данных'об-
легчает поэтапный анализ и выделение сложных событий передач уп-
равления на особо длинных маршрутах программ.
7 Зак. 10В1	_	193 -
Значительно сложнее выделять точки регистрации переменных
для анализа п б т о к о в данных. Для этого в тексте программы
необходимо выделить элементарные события обработки переменных,
в наибольшей степени влияющие на выходные результаты. Эти элемен-
тарные события,- наложенные на граф программы по управлению, об-
разуют граф с указаниями основных событий обработки информации
и содержанием этих событий. В зависимости от цейей тестирования вы-
бирается состав элементарных событий, представляющих наибольший
интерес, которые подлежат размещению в программе.
Каждое элементарное событие определяется идентификатором, и
аргументами. Для анализа целесообразно выделить следующие виды
элементарных событий:
с постоянными аргументами, значения которых не изменяются
при любом маршруте исполнения программ и любых исходных дан-
ных;
с фиксированными переменными аргументами, количество значе-
ний которых определяется свойствами оператора и не зависит от ха-
рактера предшествующего исполнения программы (условные перехо-
ды на два направления, заголовки циклов);
с абсолютно переменными аргументами, количество значений ко-
торых определяется предшествующим исполнением программы в зави-
симости от исходных данных.
Статический анализ исходного текста и графа программы позво-
ляет выделить заданные элементарные события с постоянными и фик-
сированными переменными .аргументами. Для учета элементарных
событий с абсолютно переменными аргументами необходимо их явное
описание и дополнительный анализ. При выделении точек регистра-
ции элементарных событий должна быть обеспечена возможность од-
нозначного восстановления последовательности состоявшихся собы-
тий при любых тестовых данных. При этом эффективность тестирова-
ния может быть повышена, если минимизируется число точек регист-
рации элементарных событий. Для решения этой задачи строится граф
элементарных событий, который размечается минимально достаточ-
ным набором точек регистрации, Дополнительной важной задачей при
этом является унификация и минимизация описаний элементарных
событий при регистрации.
•Имеются попытки создать алгоритмы для автоматической размет-
кд программ точками регистрации элементарных событий (77]. Одна- .
ко при этом- встречаются большие трудности, обусловленные:
большой размерностью анализируемого набора элементарных со-
бытий;
наличием ограничений на размещение операторов регистрации
событий, связанных с особенностями языка программирования и язы-
ка отладки;
необходимостью учета предварительных указаний разработчика
программы на размещение операторов регистрации;
требованием достоверного и достаточно быстрого восстановления
по зарегистрированным данным последовательностей элементарных и
сложных событий.
Приведенные обстоятельства пока ограничивают применение ав-
томатизированной разметки элементарными событиями для регистра-
ции и анализа тестирования программ с учетом обрабатываемой инфор->
мации.
Результаты тестирования, зарегистрированные на втором этапе,
упорядоченно размещаются в базе данных. Эти данные содержат све-
дения о передачах управления в программе, позволяющие ндентифи-
цировать маршруты исполнения, и характеристики обработки пере-
менных, классифицированные по типам заданных элементарных, со-
бытий. Накопленные данные обеспечивают на третьем этапе реализа-
цию широкого класса стратегий поиска ошибок в программе. В частно-
сти, можно организовать анализ программных событий с обратным дви-
жением по маршруту и выделять сложные события, идентифицируя
их по именам переменных или адресам памяти. Сложные события пре-
образования переменных в ряде случаев могут происходить на марш-
рутах исполнения программ, когда компоненты этих событий разделе-
ны большим числом операций, не влияющих на участвующие в них
элементарные события. Выявление сложных событий и их анализ обыч-
но осуществляется в режиме диалога с разработчиком программ с
целью локализации некоторых ошибок нли уточнения реализованно-
го процесса преобразования конкретных переменных. Для этого спе-
циалист, тестирующий программу, задает набор интересующих его
элементарных или сложных событий, которые могут быть автоматизи-
рование* отселектированы из базы данных и отображены для анализа.
Многократный перекрестный анализ результатов тестирования, на-
копленных в базе данных, и выделение сложных событий позволяют
достигать высокой корректности программ при минимальных затрат^
на тестирование и регистрацию промежуточных результатов. ।
Особенности реальных систем автоматизации тестирования
программ. Зарубежные технологические системы и средства
автоматизации проектирования и в том числе тестирования про-
грамм достаточно полно представлены в обзорах [76, 941. Боль-
шинство средств не входит в системы комплексной автоматиза-
ции тестирования, что ограничивает их применение И затруд-
няет оценку эффективности.
На основе общей схемы автоматизации тестирования моду-
лей (см. рис. 3.14) отобраны.восемь крупных комплексных сис-
тем, в которых наиболее полно применяются описанные выше
методы автоматизации тестирования (Табл. 3.2). Из зарубежных
разработок проанализированы по имеющимся публикациям
пять систем: SDS [711, ARGUS [1001, ATLAS [831, SADAT
[1021, AIDES 1108], которые созданы и используются, в основ-
ном, крупными промышленным^ фирмами, разрабатывающи-
ми программное обеспечение для систем управления и обработ-
ки информации, а также университетами. Для этих систем
опубликованы наиболее полные данные, тем не менее по неко-
торым функциям и характеристикам систем трудно сделать до-
стоверные заключения. Из отечественных разработок представ-
лены четыре системы: ЯУЗА-6Д [391, РУЗА [381, ПРОТВА
[521, АСПП [1]. В сводных данных (табл. 3.2) характеристики
систем ЯУЗА-6Д и РУЗА объединены, так как системы близки
по своим функциям.	k
Анализируемые отечественные и зарубежные средства ав-
томатизации тестирования создавались независимо и тем не ме-
нее оказались близки по применяемым методам и выполняемым
7*
195
Таблица 3-2 Состав средств автоматизации тестирования прог-
автоматизацин проектирования программ
Средстве, обеспечивающие автоматизацию тестирования и отладки программ	SDS
Диалоговый и телепакетный ввод данных	
Отображение результатов в текстовой форме	у'// ////
‘Отображение результатов в графической форме	///////
Контроль структурной корректности программ	
Контроль записи и чтения леременнь1Х	
 Расчет длительностей функционирования программ	
Подготовка данных для планирования тестирования структуры программ и обработки переменных	
1 Автономная трансляция тестов и отладочного задания	
Отображение и регистрация маршрутов исполнения программ	
Оценка сложности лрогремм	
Оценка полноты выполненного тестирования	
Контроль проведенных корректировок программ	
Учет версий и ведение паспортов программ	
Контроль конфигурации комплекса программ	
с широкими функциями
|, || || |||] Средство с ограниченными функциями
|	] Средство отсутствует или нет сведений
функциям. Практически во всех Системах реализуется диалого-
вый и телепакетный вйод данных и отображение данных в тек-
стовой форме. Широкое применение имеет формализованный
структурный контроль и планирование тестирования структу-
ры программ и обработки данных. Для управления тестирова-
нием в большинсте систем регистрируются и отображаются
возможные маршруты исполнения программ. Маршруты выде-
ляются наиболее часто по критерию однократного прохожде-
' ния каждой дуги в графе программы (критерий Хъ § 2.2). В не-
которые случаях число маршрутов определяется цикломатиче-'
ским числом (критерий хр- Исчерпывающее тестирование да*
196
раммных модулей в некоторых комплексных системах
же для модулей практически не применяется. Широкое исполь-
зование структурного тестирования в комплексных системах
подтверждает целесообразность большого внимания этому ме-
тоду, которое уделено в данной книге.
Во' многих системах результаты отображаются в графичес-
кой форме, контролируется .запись н чтение переменных, а
также рассчитывается длительность функционирования. про-
грамм. Динамическое тестирование имеется почти во всех сис- -
темах, однако реализуется оно по-разному. Независимая транс-
ляция тестов и отладочных заданий реализоваиа только в сис-
теме ARGUS и в отечественных системах. В большинстве за-
рубежных систем отладочные задания с отлаживаемой програм-
мой объединяются на уровне исходных текстов с последующей
совместной трансляцией для исполнения. Средства динамичес-
197
кого тестирования в реальном масштабе времени особенно раз-
виты в системе АСПП (1].- В этой системе имеются средства для
динамической имитации тестов в реальном масштабе времени и
контроль'исполнения программ может производиться по основ-
ным результатам также в реальном времени. Имеются средства
классификации и хранения тестов, а также статистической об-
работки результатов тестирования.
Пока почти не применяются методы1 и средства оценки пол-
ноты выполненного тестирования и сложности программ. Тру-
доемкость этих работ и сложность средств для автоматизации,
по-видимому, затрудняет их создание и ограничивает исполь-
зование в промышленных разработках. Однако эти средства
являются основными для контроля качества создаваемых про-
грамм и учета затрат, при которых достигается необходимое
качество. Развитие таких средств позволит тестирование пере-
вести на промышленную основу с сопутствующими оценками
эффективности и стоимости достижения заданной корректно-
сти и надежности программ.
Также ограниченно применяются средства для автоматиза-
ции контроля проведенных корректировок программ, для уче-
та версий и ведения паспортов программ, а также для конфигу-
рационного контроля программ в целом. Эти средства включе-
ны в анализ и в таблицу средств тестирования условно. Более
подробно они рассматриваются гл. 5.
Различия зарубежных и отечественных систем тестирова-
ния по'применяемым методам невелики и обусловлены в основ-
ном типами комплексов программ, для проектирования кото-
рых они предназначены. Существенной особенностью отечест-
венных систем ЯУЗА-6Д, РУЗА и АСПП является возмож-
ность их адаптации на различные системы команд тестируемых
программ. Это позволяет эффективно использовать средства
автоматизации для разработки программ широкого класса
специализированных и микро-ЭВМ. Поэтому системы
ЯУЗА-6Д и РУЗА нашли широкое применение во многих ор-
ганизациях И' адаптированы на десятки системы команд спе-
циализированных и микро-ЭВМ. При разработке отечествен-
ных систем автоматизации тестирования применялись в основ-
ном автокоды и макроязыки.
В зарубежных системах значительное внимание уделяется
представлению данных о процессе тестирования в графической
форме, отработке спецификаций и тестированию на ранних эта-
пах разработки программ. Последнее особенно четко отрази-
лось в системе SDS1711. где имеются оригинальные средства
предупреждения ошибок, четкого ведения и контроля формали-
зованных спецификаций на модули и группы программ. Для
198
ведения и обработки программных спецификаций использует-
ся специальная подсистема SREM 1711.
В зарубежных системах при их создании и для последую-
щего проектирования программ с их использованием широко
применяются наиболее распространенные языки высокого
уровня (ФОРТРАН; ПАСКАЛЬ) и приемы структурного про-
граммирования. Это позволяет упростить некоторые средства
тестирования и облегчает их создание, однако требует больших
ресурсов памяти и производительности технологических ЭВМ
и машин, для которых создаются программы. Применение язы-
ков высокого уровня как для создания технологических сис-
тем, так и для последующего проектирования КП’за рубежом
обусловлено относительно низкой стоимостью, памяти и про-
изводительности ЭВМ при высокой стоимости разработки про-
грамм.
ГЛАВА 4
ТЕСТИРОВАНИЕ ПРИ ОТЛАДКЕ И ИСПЫТАНИЯХ
КОМПЛЕКСОВ ПРОГРАММ
4.1. ГЕНЕРИРОВАНИЕ ТЕСТОВ ДЛЯ КОМПЛЕКСОВ ПРОГРАММ
Принципы применения программных имитаторов для гене-
рирования тестов. Для анализа результатов тестирования
сложных КП необходимо большое количество исходных дан-
ных и эталонных значений. Ручная подготовка всего множест-
ва тестов нерентабельна, а во многих случаях практически не-
возможна. Использование реальных объектов и натурных экс-
периментов для получения тестовых данных обычно связано с
большими затратами и значительно ограничивает реально по-
лучаемый объем генерируемых тестов. Поэтому для тестирова-
ния КП широко применяется вычислительный эксперимент, а в
качестве источников тестов и эталонных данных используются
программные модели и имитаторы.
Моделирование и вычислительный эксперимент — это метод
изучения сложных систем с помощью их замены более удобной
для исследования системой, сохраняющей основные черты
оригинала. Моделирование всегда сопряжено с той или иной
степенью абстрагирования от реальности, подлежащей исследо-
ванию, и связано с исключением второстепенных факторов,
особенностей и элементов моделируемых систем или процесеов.
Модели реализуются на иной технической базе и являются ана-
логами реальных систем только в части основных характери-
199
стик и свойств/ отражающих принципиальные особенности
моделируемых систем. Поэтому моделирование не способно
полностью заменить натурные испытания или тестирование в
реальных условиях.
В отличие от натурного эксперимента вычислительный экс-
перимент имеет большие возможности контроля как исходных
данных, так и всех промежуточных и выходных результатов
функционирования тестируемой системы. В реальных систе-.
мах ряд звеньев иногда оказывается недоступным для кон-
роля, так как либо невозможно поместить измерители контро-
лируемых сигналов в реальные подсистемы, подлежащие ис-
следованию, либо это сопряжено с некоторым изменением ха-
рактеристик всей системы. Преимуществом моделирования
является также повторяемость результатов и возможность ис-
следования большого количества вариантов, в то время как на-
турные эксперименты зачастую невозможно остановить на не-
которой промежуточной фазе или повторить с теми же или до-
статочно близкими исходными данными.
При тестировании программ модели создаются преимущест-
венно на базе ЭВМ программными методами и средствами. На-
иболее широко применяются:
модели алгоритмов создаваемых КП.или их важнейших
компонент, имеющие ряд упрощений и ограничений и исполь-
зуемые для получения эталонных значений’тестируемых про-
грамм;	'
имитаторы для моделирования внешней среды и генерации
тестовых исходных данных, заменяющие реальные объекты и
системы;	-
модели еще не разрабо!анных компонент КП, применяемые
в качестве временных «заглушек».
Моделирование алгоритмов, создаваемых КП, позволяет
исследовать их характеристики и выбрать наилучшие для при-
менения в'реальных проектах. При этом оптимизируются мето-
ды управления и обработки информации и выбираются наибо-
лее эффективные из них для конкретного КП. В процессе ис-
следования обычно не более двух—трех заранее отобранных
алгоритмов получаются их основные характеристики, кото-
рые при тестировании реализуемых КП, в ряде случаев,
могут использоваться как эталонные. Кроме того, модели
компонент КП могут тестироваться при тех же исходных
данных, которые используются для реальных программ, что
позволяет сопоставлять результаты тестирования, получен-
ные по одинаковым алгоритмам на разных программах. Мо-
делирование алгоритмов представляет широкую область ис-
следований и системного проектирования, которая сильно
200
V
зависит от назначения, характера применения *и специфичес-
ких свойств алгоритмов. Особенности моделирования алго-
ритмов относительно слабо влияют на тестирование реальных,
программ, поэтому этот вид моделей далее не рассматривает-
ся.
Задача имитации внешней среды, входной информации и
формирования тестов для отладки КП может решаться следую-
щим образом:
вручную, когда каждый вариант исходных данных форми-
руется разработчиком программы;
автоматизированно, с испол_ьзованием специальных ими-
тирующих программ, рассчитывающих тесты непосредственно
в ЭВМ, на которой функционируют тестируемые программы;
автоматизированно, с использованием универсальной тех-
нологической ЭВМ для генерации тестов, которые затем вво-
дятся с перфолент, магнитных дисков илй через каналы связи
в ЭВМ, на которой ведется отладка КП;
автоматизированно, с применением специализированной
аналоговой и цифровой аппаратуры для генерации исходной
тестовой информации.
Ручная подготовка тестов целесообразна, когда немного-
численные величины, представленные кодами, имеют глубо-
кие логические связи, которые трудно формализовать и пред-
ставить аналитически. При этом ручное составление тестовых
таблиц во всем диапазоне варьирования переменных величин
с исключением запрещенных и противоречивых кодов может
оказаться проще, чем разработка Программного или аппара-
турного имитатора, учитывающего все необходимые корреля-
ционные. связи и автоматически формирующего тесты. Однако
такие случаи относительно редки й в подавляющем большин-
стве , целесообразно идти по пути автоматизации генерации
тестов.
Программные. имитаторы внешней среды, в зависимости от
типа ЭВМ, на которой они реализуются, подразделяются на
совмещенные в одной ЭВМ с отлаживаемой программой и раз-
деленные. В ЭВМ, используемых для управления объектами,
при жестких ограничениях памяти и производительности
обычно трудно выделить ресурсы для программ генерации
тестов. Автоматические имитаторы, совмещенные с тестируе-
мыми программами, достаточно часто применяются, однако
они предназначаются в основном для оперативного функцио-
< иального контроля при взаимодействии с реальными объек-
тами, а также используются на завершающих стадиях комп-
лексной отладки. Программные имитаторы, совмещенные с от-
лаживаемыми программами, используются также при стати-
201
ческой комплексной отладке на универсальных ЭВМ. Основ
ным ограничением при этом может являться недостаточная
производительность универсальной ЭВМ.
Программные имитаторы внешней среды для генерации
тестовых данных применяются на всех этапах отладки про-
грамм, однако значительно различаются по сложности и функ-
циональным возможностям (рис. 4.1). Для тестирования
модуле.йи небольших групп программ используются прр-
стейшие программные имитаторы, генерирующие тестовые
значения нескольких переменных для головного модуля груп-
пы программ. Тестирование осуществляется снизу вверх,
т. е. прежде всего проверяются модули или небольшие группы
программ нижних иерархических уровней КП. По мере комп-
лексирования и увеличения числа модулей в группах программ
генераторы тестов заменяются на новые с более широкими
функциями для имитации данных на входе головных модулей
тестируемых групп.
Особенностью таких имитаторов является генерация преи-
мущественно детерминированных исходных данных, изменяю-
щихся по некоторому закону. Получаемые результаты тести-
рования могут быть использованы не только дЛя обнаружения,
но также для диагностики и локализации ошибок. Некоторые
имитаторы могут генерировать стохастические исходные дан-
ные для локальных испытаний и стохастического тестирования
небольших групп программ. Тестовые значения чаще всего
имитируют функционирование не внешних.абонентов, а групп
программ, расположенных в структурной схеме КП на более
высоких уровнях иерархии и предшествующих тестируемой
группе программ. Эти же имитаторы иногда полезно снабжать
компонентами для генерирования выходных эталонных зна-
чений, соответствующих исходным.
Оформляются такие имитаторы как обычные программные
модули или небольшие группы программ на той же ЭВМ, на
которой функционируют тестируемые программу. Для их от-
личия от модулей тестируемого КП целесообразно вводить
специальные идентификаторы для генераторов тестов. Необ-
ходимо предусматривать накопление и упорядоченное хране-
ние отдельных генераторов тестов для обеспечения возможно-
сти их повторного использования при локализации ошибок,
обнаруженных при тестировании групп программ.
Для тестирования больших групп программ
применяются генераторы тестовых данных, отражающих
функционирование внешних абонентов. Некоторая часть те-
стов может потребоваться также для имитации функциониро-
вания других групп программ. При этом тестирование осу-
202
х
Рис. 4.1. Схема использования имитаторов и обработки результатов на разных уровнях тестирования програм:
203
ществляегся преимущественно сверху вниз и служит, в основ-
ном, для обнаружения ошибок и определения характеристик
разработанных программ Тестируемые данные чаще всего
являются стохастическими, однако для некоторых групп про-
грамм большую роль могут играть детерминированные тесты.
Последние могут использоваться также для диагностики и
локализации ошибок.
• Для генерации таких тестов разрабатываются более или
менее сложные программные имитаторы, преимущественно
на той же ЭВМ, на которой реализуется КП- Такие имитаторы
могут создаваться как автономная группа программ под уп-
равлением центрального диспетчера или монитора КП. Управ-
ление вызовом имитаторов и задание режимов их функциони-
рования осуществляется директивами, аналогичными приме-
няемым в тестируемом КП. Оформляться такие’ имитаторы мо-
гут как самостоятельные группы программ в общей структуре*
КП. Комплект генераторов тестовых данных должен охваты-
вать все основные режимы функционирования КП и характе-
ристики имитируемой внешней среды.
Комплект генераторов тестов для групп программ может
объединяться в комплексный имитатор внешней среды, входя-
щий в состав КП как автономное изделие. Такие имитаторы
передаются пользователям с инструкциями для их применения
при контроле эксплуатируемых КП. Объем и сложность комп-
лекта таких имитаторов приближаются к объему и сложности
КП. Поэтому при ограниченных ресурсах ЭВМ отдельные ими-
таторы включаются за счет нетестируемых в данный момент
компонент КП или последовательно за счет второстепенных
задач.
Наиболее сложными являются генераторы тестовых дан-
ных для отладки ииспытаиий комплек-
сов программе реальном масштабе времени. Такие
программные имитаторы должны представлять возможность
создания тестов во всем разнообразии поведения объектов
внешней среды данного КП. В этом случае обычно только не-
большая часть тестов является детерминированной, а основ-
ная совокупность характеризует стохастическое и динамичес-,
кое поведение внешних абонентов. Особые трудности встре-
чаются при необходимости имитации в реальном масштабе
времени большого объема тестовых данных J1061. Ограничен-
ность памяти, а главное, производительности ЭВМ, на кото-
рой реализуется КП, не позволяют, как правило, реализовать
имитаторы полностью на той же ЭВМ.
Это ограничение может быть преодолено применением
разделенной во. времени генерации тестов и исполнения отла-
204
живаемых программ. В этом случае имитаторы функционируют
на отдельной универсальной ЭВМ и выдают информацию на
перфоленты или магнитные носители, с которых данные вво-
дятся в ЭВМ, реализующую КП. Для комплексной отладки
существенное значение приобретает имитация й ввод тесто-
вой информации в реальном масштабе времени и возникает
необходимость синхронизации процесса генерации тестовой
информации, процесса реального функционирования КП и
процесса обработки-результатов тестирования. При програм-
мной реализации всех трех процессов для имитации информа-.
ции и обработки результатов тестирования необходимо время,
затраты которого не Должны искажать 'реальный масштаб -
времени функционирования КП. Решить, эту задачу можно
тремя способами [341.
При первом способе (сплошные линии на рис. 4.2) предпо-
лагается, что затраты времени на генерацию тестов и обработ-
ку результатов малы, не искажают реального времени н могут
производиться незадолго до'выдачи вне связи с реальным мас-
штабом времени КП. Подготовленная при имитации тестовая
информация имеет значения времени, на которые она рассчи-
тана и когда она должна быть введена для использования в
КП. Таким образом, обеспечивается функционирование про-
грамм с полной имитацией реального масштаба времени и
возможность корректного моделирования обратных связей
взаимодействия тестируемого КП с внешними объектами [501.
В тех случаях, когда время,, необходимое для генерации
тестов и обработки результатов, велико и непосредственно не
j
Рис. 4.2. Два способа имитации тестов'и обработки результатов для
тестирования программ в реальном масштабе времени
*
20В
обеспечивается темп поступления информации в ЭВМ в. реаль-
ном масштабе времени, может использоваться второй способ
взаимодействия с имитаторами через промежуточные носители
информации (штриховые линии на рис. 4.2). При этом имити-
руемая информация заранее накапливается в имитирующей
технологической ЭВМ со значениями времени, которым она
соответствует, а затем переписывается на специальные носи-
тели информации, например магнитные ленты или диски.
Таким образом, обеспечивается ввод информации в тестируе-
мый КП и вывод результатов из ЭВМ в реальном масштабе
времени, однако затруднена имитация обратных связей и
реакции объектов на управляющие воздействия от тестируе-
мого КП, так как моделирование данных от объектов произ-
водится предварительно, вне реального масштаба времени,
задолго до их выдачи на тестируемый КП. Если учет обратных
связей состоит в небольшой корректировке заранее подго-
товленного тестового набора данных, такие корректировки
могут производиться в реальном времени в процессе выдачи
на тестируемый КП. Совмещение двух способов взаимодей-
ствия генераторов тестов с тестируемыми КП позволяет зара-
нее имитировать основные потоки тестовых данных с высокой
интенсивностью н дополнительно учитывать обратные связи
от тестируемого КП. Такое совмещение обеспечивает значи-
тельное снижение требований к производительности имити-
рующих ЭВМ.
Третий, старт-стопный, способ позволяет использовать
для имитации и обработки тестов основную ЭВМ с тестируе-
мым КП, когда невозможно обеспечить решение вспомога-
тельных задач в реальном масштабе времени (рис. 4.3). Для
этого реальный масштаб времени сохраняется только при реше-
нии задач тестируемым КП, а решение вспомогательных задач
генерации тестов происходит вне счета реального времени.
Рис. 4.3. Старт-стопный способ имитации и обработки результатов
при тестировании программ
206
При этой схеме имитации могут корректно моделироваться
управляемые объекты с учетом обратных связей от КП.
Однако старт-стопный режим имитации реального времейи
затрудняет смешанное моделирование с частичным использо-
ванием реальных' объектов—источников информации.
.Программные средства имитации тестов и обработки ре-
зультатов тестирования. Наиболее сложной является имита-
ция стохастических тестов в реальном масштабе времени для
комплексной отладки и испытаний сложных КП, управляю-
щих реальными объектами (рис. 4,4), при следующих требо-
ваниях:
необходимо формировать большое количество разнород;
ных тестовых сообщений в ограниченное время;
- ряд тестовых данных зависит от информации, выдаваемой
комплексом программ, и должен формироваться оперативно
с учетом обратной,связи от результатов обработки предыду-
щих тестов;
необходимо обеспечивать контроль генерируемых тестов,
регистрацию эталонных данных и характеристик искусствен-
ных искажений, дополняемых к эталонным при подготовке
тестов;
некоторые типы тестов' содержат коррелированные логи-
ческие величины, сложно связанные между собой, которые не-
обходимо также корректно имитировать, как и квазинепрерыв-
ные переменные;
следует обеспечить полную повторяемость серий генери-
руемых тестов при обнаружении аномалий в функционирова-
нии КП.
Для формирования болыцрго количества тестов в строго
ограниченное время необходимы ресурсы вычислительных
средств по производительности, а также некоторая емкость
памяти ЭВМ. Поэтому широко применяются имитационные
комплексы программ, исполняемые на специальной техноло-
гической ЭВМ, предназначенной целиком для генерации тес-
тов и обработки результатов тестирования — комплекс-
ные имитационн о-м оделирующие стенды
(КИМС) 157, 59]. При этом имеются следующие пути реализа-
ции имитационных комплексов программ:
на ЭВМ, полностью аналогичной основной с тестируемым
КП и являющейся дублирующей в составе вычислительного
комплекса, когда обмен сообщениями осуществляется по ка-
налам межмашинного обмена комплекса;
 на технологической ЭВМ, обеспеченной каналами сопря-
жения с ЭВМ, реализующей отлаживаемый КП, с соблюде-
207

нием реального масштаба времени при формировании и вводе
сообщений;
также на специальной технологической ЭВМ, однако функ-
ционирующей вне реального масштаба времени, в которой осу-
ществляется подготовка массивов имитированных сообщений и
их последующая запись (с синхронизацией реальным масшта?
бом времени) на промежуточные носители.
Для имитационных средств при комплексной отладке и
испытаниях программ управления динамическими объектами
наиболее широко, применяются высокопроизводительные уни-
версальные ЭВМ, непосредственно сопряженные с ЭВМ, реа-
лизующей КП, и обеспечивающие решения всего комплекса
задач’ имитации, обработки результатов, трансляции, коррек-
тировки программ и т. д.
Имитация стохастических тестов может быть представлена
следующими достаточно автономными частями: имитацией
эталонных данных и, имитацией случайных ошибок, искажений
и пропусков данных (рис. 4.4). Эти данные затем объединяются
по некоторым правилам й должны обеспечивать подготовку
сообщений с динамическими и статистическими характери-
стиками, максимально приближающимися к реальным. Эта-
лонные данные и характеристики сформированных искажений
в большинстве случаев обрабатывается и используются при
оценке результатов тестирования КП.
Значительную сложность для генерации тестов представ-
ляют коррелированные логические переменные и различные
воздействия от человека-оператора. Автоматическая програм-
мная имитация таких данных обычно весьма сложна, что при-
водит к необходимости создания специальных стендов, близких
к реальной аппаратуре системы управления. Такие стенды
позволяют дополнить автоматическую имитацию основной мас-
сы тестов реальными данными от человека, контролирующего
функционирование системы управления и обработки информа-
ции. Для решения этой задачи стендовая аппаратура сбпря-
гается с имитирующей ЭВМ, что требует разработки програм-
много обеспечения для отображения информации и ввода с
пультов управления. В тех случаях когда человек-оператор
в реальных условиях непосредственно взаимодействует с КП,
стендовая аппаратура может являться аналогом или прототи-
пом реальной аппаратуры отображения информации и управ-
ления Тогда автоматическая генерация тестов и их взаимо-
действие с- человеком происходят технически независимо (со-
ответственно в технологической и управляющей ЭВМ) и связь
осуществляется через логику функционирования тестируе-
мых Программ
209
Повторяемость экспериментов при автоматической генера- '.Й1-
ции тестов обеспечивается фиксированием исходных данных и 'Ж
применением программного формирования псевдослучайных 1 J
чисел? При надежной работе аппаратуры ЭВМ, в принципе, л
можно добиться абсолютной повторяемости весьма длительных I
экспериментов. Неидентичность результатов при повторных |
экспериментах может быть обусловлена сбоями и частичными
отказами аппаратуры. Труднее обеспечить повторяемость .,.''
экспериментов, в которых активно участвует человек-опера-
тор. В этом случае необходимо регистрировать действие чело-
века с начала эксперимента в зависимости от времени и затем
повторять эти действия в соответствии с записанным временем.
При необходимости временная диаграмма может соблюдаться
с точностью около 1 с, однако ошибки в действиях оператора
и вводимых* им параметрах каждый раз будут отличаться..»
Вследствие этого повторяемость тестов может рассматриваться
тольско статистически.	'	I
Еще один способ имитации тестов сводится к записи сооб- mJ
щений, полученных от реальных объектов в процессе натурных /ф
экспериментов (см. рис. 4.4). В этом случае входная информа-
ция действительно соответствует полностью реальным усло-
виям, однако не всегда удается ее описать обобщенными ха-
рактеристиками условий экспериментов. Наличие ряда слу- * '
чайных неконтролируемых параметров и воздействий услож- 
няет картину исходных данных и затрудняет сопоставление 
результатов экспериментов с полученными при программной I
генерации тестов. Кроме того, в этом случае' невозможно из- JiLi
менять и. учитывать обратную связь на управляемые объекты тМ
от тестируемых программ, т. е. имитация происходит в разомк- 'М
иутом контуре управления. Однако тестирование КП, обра- J
батывающих информацию без обратной связи от объектов, «Я
можно проводить весьма корректно при полной повторяемо- ™
сти исходных данных.	,
Сложность и объем имитационно-моделирующих стендов ,:
зависят прежде всего от стоимости натурных экспериментов, !
которые они должны сократить или заменить (см. §2.3). За- 
вершающей проверкой любого КП является испытание функ-
ционирования реальной системы управления объектом или
технологическим процессом. Однако моделирующие стенды Ж
позволяют к этому этапу подойти с достаточно отлаженным КП. «И
Пренебрежение разработкой КИМС всегда приводит к услож- шН
нению и удорожанию отладки и испытаний, а в худшем слу-
чае к опасному включению й реальную систему не полностью Д1
работоспособных программ.	ЯР
210
Достоверность генерации тестов. Качество тестирования и
достигаемая корректность программ в значительной степени
зависят от достоверности моделирования объектов, являю-
щихся источниками тестовых данных. При генерации тестов с
использованием программных моделей на ЭВМ их достовер-
ность определяется следующимим факторами:
адекватностью имитатора моделируемому объекту или ис-
точнику информации;
инструментальной точностью средств, реализующих ими-
татор внешней среды;
статистической точностью процесса имитации и объемом
тестовых данных, учитываемых при статистическом обобще-
нии результатов ТОстирования;
точностью дискретизации имитаторами непрерывных про-
цессов моделируемых объектов.
Перечисленные составляющие достоверности генерации
тестов взаимозависимы и повышение достоверности имитации
за счет одного из факторов приводит, как правило, к.снижению
достоверности вследствие влияния остальных. Поэтому важ-
ной задачей при создании имитационных моделей является до-
стижение заданной суммарной достоверности имитации при
сбалансированном влиянии каждого из факторов.
Адекватность имитатора зависит от степени учета вто-
ростепенных факторов, характеризующих функционирование
реальных объектов или источников информации, при создании
их моделей. Точность моделей на ЭВМ прежде всего определя-
ется алгоритмами, на которых они базируются, и полнотой
учета'в них всех особенностей моделируемых объектов. Кроме
того, на адекватность имитации влияет качество программи-
рования и уровень ошибок [63, 73, 82] в программах имитации.
Каждый неучитываемый в имитаторе элемент или фактор
моделируемой системы необходимо аналитически или иным
путем оценивать и сопоставлять его возможное влияние на
полную требуемую точность модели с учетом других состав-
ляющих достоверности имитации. Необходимым, ’но недоста-
точным условием, адекватности модели является взаимная
непротиворечивость отдельных генерируемых тестов. Конт-
роль и эталонирование моделей может проводиться путем
сопоставления частных имитируемых данных с результатами
аналитических исследований или с данными, полученными
на реальных системах.
Наиболее часто приходится встречаться с неоправданно
переусложненными имитаторами тестов, на разработку кото-
рых затрачиваются излишние силы. Методика последователь-
ного наращивания и усложнения моделей и замены отдельных
211
устройств и процессов их интегральными характеристиками
позволяет создавать даже крупные модели, достаточно адек-
ватные имитируемым системам. Однако единого метода оценки
адекватности программных имитаторов не существует и в
каждом конкретном случае приходится использовать специ-
фические методы эталонирования моделей.
Инструментальная точность имитаторов определяется
прежде всего надежностью ЭВМ и точностью программного
формирования псевдослучайных чисел. За счет случайных
сбоев и трудно обнаруживаемых частичных отказов аппара-
туры ЭВМ всегда есть риск искажения имитируемых данных.
Если длительность моделирования тестов на ЭВМ соизмерима с
длительностью наработки ЭВМ на сбой или частичный отказ
[44,_59], то искажение тестовых данных за счет имитирующего
инструмента становится весьма вероятным. Для повышения
инструментальной точности может применяться двойной
счет, однако это снижает производительность имитации по
крайней мере вдвое.
В моделях, имитирующих стохастические тесты, инструмен-
тальная точность зависит также от качества формирования
псевдослучайных чисел с необходимыми законами распреде-
ления. Программы для формирования псевдослучайных чисел
с равномерным законом распределения, используемые в ка-
честве исходных, характеризуются периодом повторения по-
рядка 105—10е чисел. При преобразовании псевдослучайных
чисел с равномерным распределением в псевдослучайные
числа с более сложными распределениями ошибка, как прави-
ло, возрастает. Совершенствование средств моделирования
псевдослучайных чисел сопряжено с возрастанием сложности
программ для их формирования, что в свою очередь приводит
к снижению объема получаемых результатов и соответственно
статистической точности имитации.
Статистическая точность генерации тестов определяется
получаемым количеством стохастических тестовых данных при
заданной ограниченной длительности тестирования. Так как
ресурсы времени для проведения тестирования всегда ограни-
чены, то ограниченным является и время, выделяемое для ге-
нерации тестов. Это влияет на объем выборки случайных те-
стовых данных и достигаемую статистическую точность ими-
тации. Определяя из предварительных результатов генерации
тестов или априори из задания на имитацию среднеквадратичес-
кие значения тестовых величин и задаваясь достоверностью
последующей выборки генерируемых данных, можно оценить
необходимое число тестовых значений.
212
Во многих случаях задача оценки статистической точнос-
ти имитации осложняется тем, что заранее неизвестны законы
распределения и значения математических ожиданий имити-
руемых случайных величин в тестах. Это приводит к необхо-
димости предварительных статистических испытаний-моделей
с целью оценки получаемых законов распределений и мате-
матических ожиданий генерируемых величин. По данным ис-
пытаний рассчитываются достижимые объемы выборок тестов
и статистическая точность имитации при этом объеме выборок.
Точность дискретизаций имитаторами проявляется только
при моделировании внешних объектов или источников инфор-
мации, характеризующихся непрерывностью процессов. При-
менение цифровых ЭВМ для имитации объектов с непрерыв-
ными процессами сопряжено с интерпретацией непрерывных
сигналов дискретными состояниями. Такая интерпретация
непрерывных состояний дискретными, а также моделирование
их функционирования сопряжены с потерей точностй из-за
квантования состояний. Интервалы дискретизации при моде-
лировании могут значительно различаться, так как компонен-
ты имитатора обычно имеют различные быстродействие и
спектральные характеристики. Кроме того, в процессе модели-
рования состояния некоторых компонент последовательно
обобщаются/ что сопряжено с увеличением интервалов дискре-
тизации.	,
При имитации сложных многбконтурных систем с большим
числом обратных связей для определения состояния всей сис-
темы в некоторый момент времени приходится его рассчиты-
вать последовательно методом'интераций. Необходимое число
итераций устанавливается при контрольных оценках имита-
тора, а затем закрепляется на весь цикл тестирования, либо
контролируется по величине ошибки, получаемой в процессе
генерации тестов.
В заключение следует подчеркнуть тесную взаимозависи-
мость перечисленных составляющих в реальных сложных ими-
таторах тестов. Достигаемая достоверность имитации естест-
венно зависит от ресурсов памяти, производительности и
других характеристик ЭВМ, на которой реализуется имитатор.
Параметры ЭВМ в наибольшей степени влияют на статисти-
ческую и инструментальную точность, достигаемую в процессе
эксплуатации модели. Адекватность моделей и точность
дискретизации в наибольшей степени зависят от сложности
моделирующих алгоритмов и, следовательно, от затрат на раз-
работку имитаторов. Поэтому при создании сложных генера-
торов тестов. необходимо достигать сбалансированного влияния
факторов на суммарную достоверность.
213
4.2. РЕГИСТРАЦИЯ И ОБРАБОТКА ДАННЫХ ПРИ ТЕСТИРОВАНИИ
КОМПЛЕКСОВ ПРОГРАММ	_
Регистрация результатов тестирования комплексов про- ;
грамм. Для анализа результатов тестирования используются i
не только выходные данные программ, но и реализация про-
цесса их исполнения. При локализации ошибок зачастую
необходимо иметь возможность проконтролировать в КП про-
цесс и результаты исполнения отдельных команд в программе.
Для этого должна быть обеспечена возможность регистрации
любых промежуточных данных и их увязывания с исходными
тестами. В процессе тестирования сложного КП может быть
получено огромное количество данных, характеризующих
процесс функционирования программы при каждом тестовом
наборе. Однако основная масса этих данных не несет полезной i
информаций для оценки результатов тестирования. Поэтому •
необходима селекция результатов исполнения программ при <1
тестировании, которая выделяла бы данные, максимально j
полезные для оценки результатов и качества программы. • •
Селекция р езультатов тестирования может
основываться на стратегии контроля функционирования про-
грамм снизу вверх, т. е. от анализа исполнения отдельных
операторов' программы и далее до стохастических результа-
тов функционирования КП в динамике реального времени.
При этом регистрируется избыточное количество данных, из
которых затем отбирается минимум, необходимый для анали-
за. Может использоваться стратегия — сверху вниз, т. е. щ
упорядоченное, иерархическое выделение в первую очередь "
обобщенных результатов функционирования программ с по- |
следующим уточнением регистрируемых и анализируемых ре- ]
зультатов вплоть до контроля исполнения отмеченного про- j
граммного модуля или отдельных операторов. В этом случае
регистрируются только те данные, которые необходимы для i
анализа в конкретном сеансе тестирования. При обеих стра- ]
тегиях необходимо иметь возможность управлять объемом и 1
видом выделяемой и регистрируемой информации в зависи- ;
мости от целей тестирования.	• J
Для диагностики и локализации ошибок нужны програм-
мные средства, обеспечивающие перехват отмеченных проме- J
жуточных данных для накопления, последующей селекции и 1
обработки. В сложных КП, функционирующих в реальном 1
масштабе времени в стохастической среде, эти средства конт- 1
роля не должны нарушать естественное исполнение программ, 1
определяющееся исходными тестовыми данными и промежу- <1
точной информацией. Кроме того, реальный масштаб времени
214
исполнения программ вследствие затрат на контроль данных
должен деформироваться • в минимальной степени. Поэтому
для регистрации промежуточных результатов тестирования
следует ограничивать их объем и при каждом эксперименте
выделять только те величины, которые действительно не-
обходимы в данном конкретном случае.
Данные, получаемые и выделяемые в процессе тестирова-
ния КП, можно разделить на следующие группы (рис. 4.5):
данные, характеризующие исходную тестовую информацию,
 и выходные результаты тестирования;
маршруты исполнения групп программ при некоторых тес-
товых данных;
промежуточные результаты исполнения отдельных опера-
 торов, модулей или .групп программ;
; аномальные события и данные, характеризующие отклоне-
ние результатов тестирования за допустимые пределы и огра-
й ничения;	•	«
характеристики использования ресурсов ЭВМ.
Средства, необходимые для получения этих данных в КП,
требуют некоторых ресурсов памяти и производительности
ЭВМ, выделение которых может вызывать значительные труд-
ности, особенно в системах реального времени, используемых
для управления и обработки информации. В зависимости от
объема н сложности КП и ресурсов ЭВМ, на которой он функ-
, ционирует, выделяется память и производительность на реа-
лизацию средств регистрации, обработки и обобщения резуль-
татов тестирования.
Относительная доля затрат ресурсов на эти средства обычно
составляет 5—10 % от полных ресурсов на реализацию КП.
В результате в КП объемом 10s команд средства регистрации
и обработки данных могут достигать 10 тыс. команд. При этом
часть средств может использоваться только при испытаниях
и комплексной отладке, а часть средств функционировать для
тестирования и контроля также в процессе эксплуатации. Это
приводит к разделению средств на две категории:
минимально необходимые средства эксплуатационного конт-
роля и средства более глубокого контроля для обнаружения,
диагностик^ и локализации ошибок в процессе тестирования.
Последний вид средств может реализовываться, в' частности,
за счет ресурсов памяти и произврдительности ЭВМ, выделяе-
мых путем отключения групп программ, не подвергающихся
тестированию при данном эксперименте.
В. более простых комплексах программ (~ 104 команд) ре-
сурсы на реализацию средств регистрации и обработки данных
, тестирования весьма ограничены. Поэтому приходится сокра-
215
216
щать объем информации, подготавливаемой для анализа те-
стирования. Ниже отмечаются средства, которые целесообраз-
но иметь даже при весьма ограниченных ресурсах .на их реа-
лизацию.
Регистрация данных, характеризующих исходную тесто-
вую информацию и результаты тестирования в КП реального
времени, осуществляется, в основном, "на выходе ЭВМ в теле-
кодовые каналы связи. Для этого к устройствам обмена могут
подключаться аппаратура или программы регистрации, ко-
торые либо только запоминают информацию, либо. кроме того,
тут же ведут ее обработку. Следует учитывать высокоприори-
тетный характер программ регистрации 1341 и целесообраз-
ность малого времени работы этих программ. Регистрацию
обменных данных следует проводить как можно реже. В нако-
пители для последующей обработки могут быть пересланы за-
регистрированные тестовые данные, не только подлежащие
обработке данной группой программ, но и йоступившиев бу-
ферные накопители ЭВМ для обработки.в следующих циклах.
Это позволяет анализировать динамику использования бу-
ферной памяти в зависимости от поступления тестовых данных.
Также могут анализироваться буферные накопители ЭВМ,
используемые для хранения перед выдачей результатов тести-
рования.
Оперативный анализ результатов стохастического тести-
рования и тестирования в реальном времени по выходным
данным удобно проводить в графической 'форме, используя
индикаторы или графопостроители. В этом случае некоторые
аномалии результатов тестирования хорошо наблюдаются по
нарушению гладкости выходных графиков или по отклонению
данных от предполагаемых эталонных. Например, при тести-
ровании КП управления воздушным движением трассы поле-
та сопровождаемых самолетов, отображаемые на индикаторах
диспетчеров, позволяют удобно анализировать качество функ-
ционирования групп программ обработки радиолокационной
информаций.
Управление регистрацией промежуточной информации и
маршрутов исполнения программ может производиться либо
по времени — от программы тактировки периодических вы-
числений, либо асинхронно — при завершении некоторых мо-
дулей или групп программ. Во всех случаях .следует обеспе-
чивать максимальную автономность регистрирующих программ
и тщательно контролировать их влияние на основные функ-
циональные программные модули и результаты их исполнения.
Целесообразно максимально ограничивать контроль проме-
жуточных результатов, требующий нарушения целостности
217
функционирования. Регистрация промежуточных данных
обычно соответствует некоторым достаточно завершенным
фазам функционирования КП. Для выдачи на регистрацию
используются стандартные каналы выдачи устройства отобра-
жения (дисплей, АЦПУ) или специальный канал выдачи дан-
ных внешним абонентам.
В отдельных случаях при разработке функциональных
модулей рекомендуется вставлять в них вызовы специальных
программ для регистрации промежуточных результатов. Та-
кой вызов становится органической частью модуля и, если от-
падает необходимость регистрации, то вместо вызываемой про-
граммы вставляется заглушка. Вызовы регистрирующих про-
грамм должны подчиняться определенной системе контроля
динамического функционирования КП при исходной гипоте-
зе, что некоторые ошибки в программах
могут быть на любой стадии отладки и
испытаний. Однако количество вызовов регистрирующих
программ следует ограничивать, учитывая допустимые расхо-
ды ресурсов на их реализацию. Так как основная задача ре-
гистрации при тестировании в реальном времени состоит в
обнаружении и локализации ошибок с точностью до функцио-
нальной группы программ или модуля, то более точное опреде-
ление места ошибки следует переносить на тестирование в ста-
тике вне реального масштаба времени.
Для максимального сокращения объема регистрируемых и
отображаемых результатов тестирования при каждом экспе-
рименте контролируются маршруты только выделенной груп-
пы программ. Вызовы из модулей регистрирующих программ
позволяют накапливать маршруты исполнения групп программ
с точностью до имен модулей. В отдельных случаях некоторые
модули могут контролироваться более глубоко с точностью до
операторов ветвления или циклов. В результате в процессе
тестирования КП регистрируется набор маршрутов функцио-
нирования программы на уровне модулей и только на отдельных
участках, детализированный до операторов. Это позволяет
локализовать некоторые логические ошибки и некорректности
взаимодействия модулей по управлению.
Кроме того, на выходе каждого модуля может регистриро-
ваться подготовленная им обменная и глобальная информа-
ция. Эта информация позволяет восстанавливать реализо-
ванный в динамике процесс обработки тестовых исходных
данных с точностью до модулей, где рассчитана каждая вели-
чина. Таким образом, в соответствии с заданием могут быть вы-
делены отдельные маршруты исполнения групп программ и
весь процесс обработки некоторых величин.
218
От ресурсов ЭВМ, которые могут быть выделены на средства
регистрации, зависит форма и полнота информации, отобра-
жаемой для анализа маршрутов и промежуточных данных.
Эти данные целесообразно представлять в виде имен модулей
и меток операторов на маршруте, а также имен переменных в
их естественном представлении на . языке программирования.
Для этого необходимы трансляторы с машинного языка ЭВМ,
исполняющей тестируемые программы, на язык исходных
текстов программ (см. § 3.5). Транслятор должен обеспечивать
преобразование абсолютных машинных адресов в имена моду-
лей и меток операторов, а также транслировать машинное
представление переменных в их имена и содержание на уровне
текста программы. Создание таких трансляторов — достаточно
сложная задача и требует значительных ресурсов ЭВМ. По-
этому во многих случаях при стохастическом тестировании в
реальном времени приходится ограничиваться регистрацией и
представлением данных в машинных-кодах ЭВМ, исполняющей
тестируемые программы.
Существенную помощь при тестировании может оказать
программа анализа сбоев [341. Поэтому ее разработку целе-
сообразно завершать до начала тестирования в реальном вре-
мени. Программа анализа сбоев обеспечивает оперативную ре-
гистрацию аномальных ситуаций и искажений, выявляемых
аппаратным и программно-алгоритмическим контролем. Эта
программа должна позволять селектировать причины иска-
жений результатов (программные или аппаратные) и локали-
зовать наиболее значительные искажения вычислительного
процесса (зацикливания, остановы, стирания данных в памяти
и т. д.). Кроме того, накопление и систематизация редких по-
вторяющихся искажений вычислительного процесса или дан-
ных при длительном функционировании позволяют обнаружи-
вать и устанавливать причины редко проявляющихся ошибок
в программе и условия их проявления. Это средство контроля
результатов тестирования может иметь существенное значение
также и при эксплуатации серийных образцов КП. При этом
следует организовывать регулярную регистрацию и анализ
накопленных искажений на всех КП определенного типа (см.
гл. 5).
Еще одним средством регистрации результатов тестирова-
ния, органических входящим в состав КП реального бреме-
ни, являете^ программа анализа реальной загрузки ЭВМ про-
цессом обработки данных. Ее разработка также должна пред-
шествовать тестированию и испытаниям КП. Эта программа
позволяет регистрировать в динамике функционирования КП
использование ресурсов ЭВМ и выделять потоки сообщенйй с
219
наибольшей интенсивностью. Тем самым могут быть селекти-
рованы аномалии в функционировании КП, обусловленные не-
нормальными интенсивностями потоков сообщений или из-
лишней длительностью их обработки. Кроме того, программа
анализа загрузки может обеспечить, регистрацию части ре-
зультатов испытаний, а также подготовку информации для
подключения дополнительной вычислительной мощности в
многопроцессорных и многомашинных системах. В процес-
се эксплуатации регулярная регистрация загрузки позволяет
контролировать динамические характеристики КП в различ-
ных условиях, выделяя критические режимы перегрузки.
Длительная регистрация и накопление значений загрузки мо-
жет помочь установлению условий, при которых проявляются
некоторые ошибки в программах.
Следует подчеркнуть необходимость системного подхода к ,
разработке комплекса средств регистрации динамики функ-
ционирования КП в процессе проектирования. Весьма часто- ,
увлечение проектированием функциональных программ при-
водит к значительному отставанию разработки средств конт-
роля и регистрации, что впоследствии существенно усложняет
и задерживает динамическое тестирование.
Обработка результатов тестирования. Современное тести-
рование систем обработки информации и управления позво-
ляет получить большое количество результатов, такое что
достаточно полный их анализ представляет сложную методичес-
кую и техническую задачу. При избытке контролируемых ве-
личин снижается общее быстродействие имитаторов и КП в ре-
зультате затрат времени на контроль и регистрацию, что за-
трудняет анализ функционирования программ в реальном мас-~
штабе времени. При переходе к массовым экспериментам при-
ходится значительно сокращать количество анализируемых
параметров и по возможности представлять их в обобщенном
виде. В каждом конкретном случае необходимо стремиться к
компромиссу между полнотой данных тестирования и удобст-
вом анализа обобщенных результатов, учитывая, что как обоб-
щение, так и глубокий контроль связаны со сниженьем быстро-
действия имитаторов и испытываемой системы.
Общим методом получения результатов, которые можно
анализировать удобно и экономично, является иерархическое
деление обрабатываемых данных на несколько уров-
ней детализации. Так, например, для контроля сис-
темы управления воздушным движением в основном необходи-
мы координаты сопровождаемых объектов, их сообщения и
управляющие распоряжения. При сопровождении одиночного
объекта можно получать гистограммы и корреляционные
220
функции ошибок выходных координат. На первой стадии комп-
лексной отладки контролируется основная информация, пере-
даваемая между модулями. Далее, при расчете контрольных
вариантов проверяются данные, поступающие к диспетчерам,
и признаки, характеризующие работу 'имитаторов и КП на
каждом цикле обработки информации. И, наконец, при мас-
совых статистических испытайиях контролируются только
обобщенные Данные — значения средних ошибок, вероятности
основных событий, правильных и ошибочных решений для ва-
риантов имитируемой обстановки и т. д.
Одной из основных задач обработки результатов тестирова-
ния является получение по данным экспериментов статистичес-
ких распределений контролируемых величин. На практике во
многих задачах форма распределения проверяемых парамет-
ров и показателей качества оказывается заранее неизвестной.
Однако часто в качестве такого распределения можно пред-
положить нормальный закон распределения. Например, сум-
марную погрешность измерения координат воздушных объек-
тов е-помощью радиолокационной станции можно рассматри-
вать как результат действия большого числа независимых и
слабо зависимых причин и поэтому полученную ошибку можно
представить как сумму элементарных ошибок. Это позволяет
в соответствии с центральной предельной теоремой считать
закон распределения ошибок измерения координат нормаль-
ным. В ряде случаев хорошим приближением является закон
Пуассона или экспоненциальный закон.
Обработка результатов тестирования КП реального време-
ни может быть разделена на две автономные части (см. рис. 4.5):
оперативную и обобщающую. Оперативная обработка резуль-
татов тестирования производится по упрощенным алгорит-
мам с большой пропускной способностью, обеспечивающим
сохранение реального масштаба времени для всего тестируе-
мого комплекса. Основная часть оперативной обработки ре-
зультатов связана с замыканием контура обратной связи для
имитации динамики управляемей объектов. Оперативно сле-
дует производить также селекцию некоторых результатов
тестирования и их предварительную обработку для значи-
тельного сокращения объема хранимых результатов.
В состав оперативной обработки целесообразно включать
расчет части интегральных данных, позволяющих контроли-
ровать текущий процесс обработки информации и управления
тестируемым КП. Желательно выделять, регистрировать и
отображать критические значения параметров или ситуации
при . функционировании КП. Объем таких оперативно отобра-
жаемых данных должен быть максимально сокращенным и в
221
то же время достаточным для анализа поведения КП. Эти дан-
ные должны позволять специалистам, ведущим отладку или
испытания, фиксировать условия, при которых проявляются
аномалии в функционировании программ, с учетом того, что
автоматическая регистрация условий тестирования всегда
имеет пробелы в составе фиксируемых параметров;
Обобщающая обработка накопленных результатов тести-
рования производится вне реального масштаба времени после
завершения одного или-серии экспериментов. Основная задача
при этом состоит в расчете различных интегральных харак-
теристик функционирования КП. Существенная сложность
связана с получением и использованием эталонных данных.
Некоторые эталонные данные могут быть получены от генера-
торов тестов. При экспериментах с реальными объектами для
расчета эталонных данных используются специальные изме-
рительные комплексы. В обоих случаях непростой задачей
может оказаться сопоставление и совместная обработка экс-
периментальных данных тестирования с эталонными. Осо-
бые трудности при этом встречаются в связи с необходимостью
совмещения во времени результатов экспериментов и данных,
получаемых от внешних измерительных комплексов, инфор-
мация которых об объектах или процессах используется как
эталонная. Решение этой задачи возможно либо жесткой син-
хронизацией функционирования измерительных и проверяе-
мых систем, либо использованием системы единого времени.
Последний способ применяется наиболее широко, так как он
достаточно устойчив к временным искажениям или кратковре-
менному отсутствию единого времени в одной из систем.
4Д НЕКОТОРЫЕ ОСОБЕННОСТИ ТЕСТИРОВАНИЯ КОМПЛЕКСОВ
ПРОГРАММ РЕАЛЬНОГО ВРЕМЕНИ
Тестирование использования ресурсов ЭВМ при функцио-
нировании комплекса программ. Потребность в ресурсах па-
мяти и производительности ЭВМ в процессе решения задач
значительно изменяется в зависимости от состава- и объема
исходны* данных. Степень использования памяти и произ-
водительности ЭВМ в некоторых пределах не влияет на ка-
чество решения задач комплексом программ. При высокой ин-
тенсивности ввода исходных данных может нарушаться вре-
менной баланс между длительностью решения совокупности
задач КП в реальном масштабе времени и реальной произво-
дительностью ЭВМ при решении этих задач [351. Также воз-
можно нарушение баланса между имеющейся в ЭВМ памятью
и памятью, необходимой для хранения всей поступившей и
222
обрабатываемой информации. Для выявления подобных ситуа-
ций и определения характеристик КП в условиях недостаточ-
ности ресурсов ЭВМ производится тестирование при высокой
интенсивности поступления исходных данных.
Наиболее сложным является тестирование использоваиия
ресурсов производительности ЭВМ в реальном масштабе вре-
мени. При этом основная задча тестирования состоит в опре-
делении вероятностей, с которыми будет нарушаться соответ-
ствие между потребностями в производительности для решения
всей совокупности задач и реальными возможностями ЭВМ.
Если эта вероятность невелика и можно считать допустимыми
получающиеся задержки и пропуски в обработке сообщений,
то делается вывод о соответствии производительности ЭВМ
данному КП. При тестировании может быть также определена
зависимость качества решения задач от характеристик посту-
пающей информации.
При тестировании использования ресурсов производитель-
ности должны быть решены следующие частные задачи: .
определены значения интенсивностей поступающих исход-
ных данных и распределения вероятностей интенсивностей для
различных сообщений;
определена длительность автономного, решения отдельно
каждой из функциональных задач, обрабатывающей исходные
данные или включаемой периодически;
определена загрузка ЭВМ в нормальном режиме поступле-
ния сообщений, а также вероятность перегрузки и распредет
ление длительностей перегрузки в реальных условиях;
определено влияние пропуска в обработке сообщений и сни-
жения темпа решения периодических Задач на качество функ-
ционирования КП.
Перечисленные задачи могут быть решены эксперимен-
тально в процессе тестирования завершенного КП, однако при
этом велик риск, что производительность ЭВМ окажется недо-
статочной для решения заданной совокупности задач в реаль-
ном масштабе времени, Кроме того, не всегда условия испыта-
ний или опытной эксплуатации системы соответствуют режимам
массового ее применения. Поэтому при тестировании требуется
принимать специальные меры для создания реальных, но на-
иболее тяжелых по загрузке условий функционирования КП.
При соответствующей регистрации результатов тестирования
могут быть решены все перечисленные задачи, что позволяет
анализировать факторы, определяющие пропускную способ-
ность ЭВМ и разрабатывать меры для приведения ее в соот-
ветствие с потребностями. Если предварительно в процессе
проектирования производительность ЭВМ не оценивалась или
223
определялась слишком грубо, то почти наверняка доработки
КП будут большими или даже понадобится заменить ЭВМ на
более быстродействующую. Это обусловлено, как правило, оп-
тимизмом разработчиков, который приводит к занижению ин-
туитивных оценок длительностей решения задач.
Достоверность тестирования пропускной способности ЭВМ с
конкретным КП зависит от корректности моделирования по-
токов внешних сообщений и от достоверности определения дли-
тельностей исполнения программ. При подготовке техничес-
кого задания на КП следует согласовывать с заказчиком харак-
теристики внешней- среды, в которой должен работать КП.
Должны быть определены темпы решения периодических за-
дач и возможное увеличение периодов при повышенной за-
грузке. Эти условия следует детализировать до уровня, по-
зволяющего однозначно определять значения интенсивностей
решения различных задач в среднем, нормальном режиме ра-
боты КП, в режиме допустимой предельной загрузки, реали-
зующемся. с определенной вероятностью, и в режиме кратко-;
временной аварийной перегрузки. В результате формируется
модель внешней, среды функционирования КП, в которой долж-1
ны выполняться требования технического задания по-основным '
характеристикам.	!
Такая модель, согласованная б заказчиком, позволяет бо- '
лее рационально определять необходимое быстродействие ЭВМ ,
и уменьшает вероятность конфликтов между заказчиком и;
разработчиком из-за различной трактовки предельных внеш- ,
них условий, в которых должен работать КП. В системах уп-
равления Воздушным движением такими согласуемыми внеш- ;
ними условиями являются, цапример, число самолетов на раз-
личных этапах взлета, посадки и движения по трассе, возмож-
ные изменения их числа в зависимости от времени года и суток,
от метеоусловий и других факторов. Эти условия влияют как
на локальную плотность поступления сообщений* так и на па- 
раметры критических ситуаций по пропускной, способности ,
при обработке информации, при которых система должна сох-
ранять характеристику, соответствующие требованиям техни- ,
ческого задания.
Согласованная модель внешней среды может использовать-
ся непосредственно при формировании тестов для испытаний
КП, а также в качестве исходных данных для предваритель-
ных оценок на начальных этапах проектирования. В послед-
нем случае модель является основой для оценки вероятност-
ных характеристик профиля (см. § 1.2) исполнения программ:
вероятностей условных переходов, числа реализаций циклов
и вероятностей исполнения маршрутов обработки инфррма-
224
ции. Подобная модель применяется для аналитического рас-
чета длительностей исполнения программных модулей и все-
го КП. В результате для определения пропускной способности
ЭВМ модель внешней среды используется на двух этапах:
в вероятностном виде — для аналитического расчета длитель- ✓
ностей исполнения программ и в первоначальном — для фор-
мирования потоков тестовых данных.
В зависимости от набора значений тестовых данных осу-
ществляется последовательный выбор компонент маршрута
при исполнении программы. Выбор маршрута происходит
при определении направлений условных переходов. Отсюда
следует, что различные маршруты заведомо не являются рав-
новероятными, а также возможны нереализуемые маршру-
ты^’которые не допускаются логикой алгоритмов или системы в
целом. Для корректного определения пропуской способности
ЭВМ с данным КП нужно иметь следующие характеристики
групп программ:	/
экстремальные значения длительностей и маршруты, на
которых эти значения достигаются;
среднее значение длительности каждой группы программ
на всем возможном множестве маршрутов КП и его дисперсию;
распределение вероятностей значений длительностей испол-
нения групп программ;
перечисление маршрутов, упорядоченное по значениям их
длительностей.
В общем случае для полного описания длительностей испол-
нения программ необходимо задать вероятность каждой ком-
бинации тестовых данных и измерить соответствующую ей дли-
тельность исполнения группы программ (см. § 3.3). После
упорядочения значений длительностей получается распреде-
ление вероятностей в зависимости рт длительностей. Одиако
для сложных групп программ весьма трудно определить веро-
ятность каждой комбинации исходных данных. Поэтому на
практике в ряде случаев ограничиваются некоторыми средними
или наиболее вероятными значениями тестовых данных, а так-
же одним или несколькими сочетаниями данных, при которых
ожидаются предельные значения длительности исполнения
программ
В соответствии с моделью средних и предельных условий
функционирования КП устанавливаются характеристики тес-
товой информации, при которой должны быть оценены дли-
тельности исполнения программ. Набор таких тестовых дан-
ных всегда желательно максимально ограничить. Далее для
каждого набора исходных данных измеряется длительность
исполнения программ одним из методов: при реальной одно-
8 3«. 1061
225
кратной обработке исходных данных или при многократ-
ной обработке некоторых одинаковых исходных данных, в
специально создаваемом цикле. При первом методе трудно
получить'достаточно высокую точность измерения длительно-
стей исполнения небольших программ, так как масштаб счета
реального времени в ЭВМ зависит от динамических характе-
ристик внешних объектов и обычно соизмерим с длительностью
исполнения групп программ.
При втором методе могут использоваться счетчики реаль-
ного времени с любым масштабом, однако исследуемые про-
граммы должцы обеспечивать возможность многократного
повторения обработки одних и тех же тестовых данных. Сле-
дует подчеркнуть, что приведенные методы экспериментального
определения длительностей исполнения программ предпола-
гают наличие готовых отлаженных программ. Кроме того,
требуется, корректный выбор сочетаний тестовых данных,
при которых проводятся эксперименты.
Аналитический расчет с использованием графовой модели
исследуемого КП (см. § 3.5) позволяет в общем случае с мень-
шими затратами по сравнению с экспериментальным тестиро-
ванием программ получить приближенные временные харак-
теристики [501. Однако при аналитическом определении дли-
тельностей исполнения программ трудно учесть два фактора,
влияющих на результаты. Первый из них — взаимозависи-
мость направлений условных переходов, выбираемых при
реальном исполнении программы, из-за связей по информации
между теми условиями, которые управляют переходами. Вслед-
ствие, этого при анализе модели могут'учитываться маршруты,
. не реализуемые в действительности.
Второй фактор — возможность изменения значений веро-
ятностей условных переходов. Она обусловлена происходящей
в ходе реального функционирования программы переработкой
информации, управляющей условными переходами, которую
топологическая модель не отражает из-за отсутствия учета
детального изменения информации. Связь с моделью изме-
нения информации осуществляется фактически только при на-
значении разработчиком величин вероятностей на различных
направлениях условных переходов (на дугах графовой модели).
Эти факторы затрудняют интерпретацию реальной динамики
функционирования программы в графовой модели и прежде
всего делают приближенным описание характера прохождения
циклических участков.
।	. Особенности тестирования параллельных программ. Па-
раллельное исполнение программ реализуется.в вычислитель-
ных системах (ВС) в разных видах, что. приводит к мцогообра-
226
зию особенностей тестирований таких программ [49, 18). Опыт
тестирования параллельных программ пока невелик и почти
отсутствуют обобщающие теоретические работы в этой области..
Основные особенности тестирования обусловлены взаимодей-
ствием параллельных программ по управлению, влияющему на
последовательность исполнения компонент программы, а так-
же взаимодействием по информации. Степень и особенности
взаимодействия программных компонент зависят от класса
ВС, методов распараллеливания программ и характеристик
реализуемых алгоритмов. Многообразие видов и глубины свя-
зей параллельных программ, прежде всего через общие дан-
ные, затрудняют создание общих методов их тестирования и
теоретические обобщения.
При проектировании параллельных программ для повыше-
ния их потенциальной корректности и облегчения последую-
щего тестирования необходимо по возможности ослаблять и
упорядочивать связи между параллельно исполняемыми про-
граммами. В простейшем случае в многомашинных вычисли-
тельных системах 1181 параллельно функционирующие про-
граммы могут исполняться почти независимо во времени и
асинхронно. При этом их взаимодействие организуется только
через общие данные, накапливаемые во внешней памяти. Под-
готовка данных может производиться независимо каждой ЭВМ,
и последовательность их расчетов не влияет на результаты.,
Тестирование таких программ сосредоточивается в основном'
на тестировании каждой компоненты для каждой машины.
Оно может проводиться всеми описанными выше методами, в
том числе детёрминированно. Для проверки взаимодействия
программ через общие данные обычно подготавливается не-
сколько детерминированных сценариев такого взаимодейст-
вия. По этим сценариям разрабатываются тестовые наборы и
окончательное тестирование КП производится на реальной
многомашинной ВС при реальных потоках исходных; данных.
В общем случае параллельного функционирования про-
грамм на многопроцессорных ЭВМ принципиальной Иробле-'
мой является недетерминированное взаимо-
действие программ через общие данные [18, 19].
Характер такого взаимодействия определяется наличием
случайной составляющей в моментах вызова программ для ис-
полнения процессорами, случайной длительностью функцио-
нирования программ, флюктуациями объема и состава данных,
через которые взаимодействуют программы, и рядом других
факторов. Вследствие этого последовательность и моменты
записи и чтения каждой переменной взаимодействующими про-
граммами могут изменяться в широких пределах, и все такие
8*
227
ситуации необходимо протестировать. Количество подобных
ситуаций в ряде случаев оказывается катастрофически боль-
шим, что требует применения специальных методов упорядо-
ченного стохастического тестирования.
Ряд ситуаций недетерминированного взаимодействия про-
грамм через данные можно исключить при структурном по-
строении программ и данных, а также упорядоченным обра-
щением к данным. Структурирование динамики и областей
взаимодействия параллельных программ позволяет упорядо-
чивать варианты совместного функционирования программ и
резко сокращать необходимые объемы тестирования. При
этом появляется необходимость тестирования выполнения
правил взаимодействия программ и данных, однако значи-
тельно уменьшаются диапазоны варьирования тестов.
При взаимодействии параллельно исполняемых программ
тестированию прежде всего подлежат наиболее опасные конф-
ликтные ситуации, которые в некоторых случаях способны при-
водить к полному отказу функционирования ВС. При решении
ряда задач преобразуемые данные могут использоваться толь-
ко после того, как проведены преобразования всех взаимо-
связанных переменных. Например, экстраполяция координат
движущегося объекта на заданный интервал времени предпо-
лагает, что они могут применяться только после полного за-
вершения операций по пересчету всех пространственных ко-
ординат. В процессе расчетов по преобразованию координат,
их значения в памяти соответствуют разным моментам време-
ни, что может резко исказить расчеты, выполняемые паралг
лельно.
Недетерминированное исполнение программ каждым процес-
сором может приводить к логическому несоответствию и проти-
воречивости некоторых данных в памяти на интервалах вре-
мени их активного преобразования. Общие данные для парал-
лельно исполняемых программ могут Определяться и приме-
няться несинхронно, из-за чего возникает возможность обра-
щения к вце не определенным переменным. Для предотвраще-
ния этого необходимо- временно блокировать доступ к неко-
торым блокам памяти или данным, пока их преобразование
не будет полностью завершейо.
Возможность конфликтов при использовании общих дан-
ных трудно заранее учесть при распределении программ по
процессорам. Для этого, в принципе, необходимо построить
матрицу связности различных программ через общие данные
и при распределении исключать назначения на одновременное
исполнение процессорами тех программ, которые применяют
одни и те же переменные.
228 , '
Задача временной блокировки доступа к данным может быть
решена методом семафоров (флагов) 170]. Если в
некоторый набор данных вносятся изменения определенной
программой, то перед началом ее исполнения специальной
командой закрывается «семафор» (записывается признак), ко-
торый запрещает использование этих данных любой другой
параллельно исполняемой программой. Все программы при
обращении к блокируемым данным проверяют состояние
признака «семафора». Если признак имеется, то либо програм-
ма должйа ожидать до его снятая, либо следует вызвать другую
программу, не имеющую обращения к заблокированным дан-
ным. Признак. «семафора» снимается после завершения пере-
счета данных соответствующей программой, включившей бло-
кировку.
В многопроцессорных ВС информационные связи иногда
приводят к полной самоблокировке («клинч») [49] вычисли-
тельного процесса при исполнении параллельных программ,
применяющих одни и те же ресурсы или данные. В простей-
шем виде подобная ситуация может возникнуть из-за приме-
нения «Семафоров» При обращении к нескольким блокам опе-
ративной памяти. Предположим, что программа первого про-
цессора применяет блокировку «семафором» для запрещения
обращения сначала к первому блоку оперативной памяти, а
затем сама обращается к другому блоку, не снимая запрета
обращения к первому. В это время второй процессор исполь-
зует данные из второго блока оперативной памяти, который
защищен от вмешательства закрытым «семафором», и ему тре-
буются данные из первого блока оперативной памяти. Так как
первый блок закрыт от обращений всех процессоров, кроме
первого, то второй Процессор вынужден ждать снятия запре-
та «семафором». В подобной же ситуации оказывается первый
процессор, заблокированный «семафором» на втором блоке
оперативной памяти. Продолжение вычислений возможно .
только после внешнего вмешательства и принудительного
снятия одного из «семафоров», что, в частности., может привести
к искажению результатов- решавшейся задачи или к необхо-
димости ее полного повторения.
Для устранения возможности самоблокировки достаточно,
чтобы каждая программа комплекса, непрерывно исполняе-
мая одним из процессоров, запрашивала и ожидала освобо-
ждения всех необходимых для нее ресурсов до начала испол-
нения программы. Другим способом профилактики самобло-
кировки является устранение условия «отсутствия предпоч-
тения». Для ajoro при обращении к ресурсам, занятым другой
программой или процессором, следует освобождать все ресур-
ВВ 4oe»l-“i>	229
сы, занятые данной программой и заблокированные от исполь-
зования другими процессорами. Программа может быть повто-
рена или продолжена только после освобождения всех ресур-
сов, необходимых для ее исполнения.
Еще один способ предотвращения самоблокировки состоит
в специальном планировании вычислительного процесса и
выборе программ на исполнение. При этом организация вы-
числительного процесса весьма усложняется, так как необ-
ходима проверка отсутствия самоблокировки при всех сочета-
ниях программ, которые могут одновременно исполняться на
разных процессорах. Размерность такой задачи может быть
очень большой, так как зависит от числа: процессоров, типов
независимо вызываемых параллельных-программ и типов ре-
сурсов или данных, к которым могут обращаться одновременно
разные процессоры..
В вычислительных системах, используемых для управления
объектами или технологическими процессами, даже очень ма-
лая вероятность неблагоприятного сочетания параллельно
исполняемых программ может приводить к редкой эпизоди-
ческой самоблокировке процесса управления, эквивалентной
отказу всей ВС. Для выявления и устранения таких ситуаций
требуется длительное стохастическое тестирование в очень
широком диапазоне изменения исходных данных. Эффектив-
ным методом борьбы с подобными явлениями может быть опе-
ративное обнаружение нарушений и восстановление вычнс-,
лительного процесса (рестарт, см. § 2.3). Для оперативного об-
наружения самоблокировки могут применяться аппаратно-
программные методы защиты, аналогичные методам борьбы
с зацикливаниями и остановами I50J.
Таким образом, значительное увеличение сложности функ-
ционирования параллельных программ по сравнению с после-
довательными, особенно в системах реального времени, при-
водит к необходимости применения ряда дополнительных мер
для предотвращения, обнаружения и локализации возможных
ошибок в таких программах. Эти меры должны базироваться
на высокоавтоматизированной, упорядоченной и контролич
руемой технологии создания таких программ. Для параллель-
ных программ особое значение приобретают методы структур-
ного построения КП и его компонент, а также систематизиро-
ванная организация вычислительного процесса, способствую-
щие максимально возможному ослаблению и упорядочению
связей при исполнении параллельных программ. Для этого
целесообразно выделять непараллельное исполнение крупные
программные компоненты разных функциональных задач. >.
Большую помощь при создании ^адежных параллельных про-
230
грамм оказывают методы оперативного рестарта. Окончатёль
ная отработка таких КП проводится методами регламентиро-
ванного стохастического и динамического тестирования. 'Его
основные особенности состоят в необходимости охвата всей
области исходных данных и в сложности локализации ситуа-
ций, приводящих к аномальным результатам тестирования в
недетерминированной среде.
4.4. ТЕСТИРОВАНИЕ ПРИ ИСПЫТАНИЯХ ПРОГРАММ	,
Задачи .и этапы испытаний программ. Общая цель прове-
дения испытаний изделий состоит в -демонстрации пользова-
телю-заказчику соответствия созданного изделия техническим
требованиям, выдвигавшимся и принятым разработчиком для
проектирования. Для программ, создаваемых на уровне из-
делий и отчуждаемых от разработчика, испытания являются
одним из важнейших этапов жизненного цикла [59, 404], на
котором проверяются и фиксируются достигнутые показатели
-качества КП. Важная особенность тестирования при испыта-
ниях программ состоит в наличии достаточно полных эталонов,
которым должен соответствовать КП, — требований техни-
ческого задания. Это позволяет сформулировать цель испы-
таний как определение степени соответст-
вия созданного комплекса программ
техническому заданию, выданному заказчиком.
За относительно короткий период приемосдаточных испы-
таний трудно провести достаточно полное тестирование, де-
монстрирующее достигнутое качество сложного КП. Поэто-
му для обеспечения высокого качества программ в техническом
задании целесообразно задавать технологию его проектиро-
вания и условия поэтапной проверки основных компонент в
процессе разработки [131. Для этого до начала разработки в
процессе формирования технического задания формулируются
основные положения методики тестирования и проверяемые
характеристики программ при будущих испытаниях. В ре-
зультате группа испытателей или заказчик-пользователь
может встречаться с заданным изделием не только в конечном
виде, предъявленном к испытаниям, но и на некоторых про-
межуточных фазах разработки компонент. В этом случае
испытатель получает возможность поэтапно и глубоко зна-
. комиться с создаваемым изделием и достаточно полно подго-
товиться к испытаниям КП. Одновременно уточняется и конк-
ретизируется техническое задание и методика тестирования
программ на завершающих приёмосдаточных испытаниях.
Зб*	«31
Наиболее полному поэтапному тестированию подверга-
ются КП, функционирующие в реальном масштабе времени в
особо ответственных системах управления и обработки ин-
формации. Например, стандартами министерства обороны
США (68, 69] определены пять этапов испытаний и проверок
проекта в процессе разработки до окончательных приемосда-
точных испытаний. Предварительные испытания на основе
тестирования проекта и компонент начинаются на этапе опре-
деления технического задания и конфигурации системы в
эскизном проекте (1-й этап). При техническом проектировании
идентифицируются основные модули комплекса и специфици-
руются требования по их тестированию (2-й этап). Испытания
технического проекта КП предусматривают проверку дорабо-
ток и уточнений технического задания, а также контроль тре-
бований к тестированию компонент и средствам его автомати-
зации (3-й этап). Критическая проверка проекта (4-й этап)
предшествует кодированию -программ. При этом анализиру-
ются полные и детальные спецификации на все модули и
группы программ, а также проекты планов тестирования, их
экономичность и непротиворечивость* с компонентами комп-
лекса. Анализ функциональной и физической реализации
КП (5-й этап) позволяет установить согласованность реализуе-
мых компонент с требованиями к ним и с документацией.
В соответствии со стандартами иа всех этапах разработчик от-,
читывается перед заказчиком соответствующими документами и
тестами проверки. По требованию испытателей или заказчика
Проверки могут дополняться и углубляться.
В ряде работ [14, 45, 72] подчеркивается необходимости
наличия независимой группы (комиссии) специалистов, вы-
полняющих тестирование программ, особенно на этапе прие-
мосдаточных испытаний. Такая группа может включать пред-
ставителей разработчиков' программ, однако основными чле-
нами должны быть профессиональные испытатели, а также за-
казчики и будущие пользователи данного КП. Группа по тести-
рованию программ при испытаниях должна обеспечивать объек-
тивную проверку качества программного продукта в пределах
требований технического задания. Для этого разрабатывается
программа.испытаний, методики и конкретные тесты для про-
верки по каждому пункту технического задания. Возможней
проверки КП за пределами требований технического задания;
Такое тестирование должно согласовываться' с разработчиком,
и если оно будет принято, то может приводить к уточнению и
расширению,технического задания. Если предлагаемое при
испытаниях тестирование значительно расширяет обязатель-
ства разработчика, принятые в рамках технического задания,
то такое тестирование либо отклоняется, либо его результаты
не учитываются при оценке степени выполнения разработчиком
взятых обязательств.
В жизненном цикле КП Можно выделить следующие виды
испытаний, каждый из которых имеет особенности тестиро-
вания (рис. 4.6):
' испытания опытного образца КП на полное соответствие
требованиям технического задания;
испытания рабочей версии КП, адаптированной к условиям
конкретного применения;
испытания версии модернизированного КП при сопровож-
дении. '
Наиболее полным и разносторонним испытаниям подвер-
гаемся КП при пеовичной проверке опытного образца. Тести-
рование при испытаниях очередных модернизированных вер-
сий сложных КП по объему и сложности приближается к тести-
рованию опытного образна. Поэтому тестирование модерни-
зированных версий, так же как и средства, используемые для’
его проведения, далее рассматривается совместо с тестирова-
нием при испытаниях опытного образца.
Тестирование опытного образца при-приемо-сдаточных ис-
пытаниях программ. Для обеспечения полноты приемосда-
Рис. 4.6. Схема методов и видов тестирования при испытаниях КП
233
точных испытаний опытного образца КП' как программного
изделия при их планировании целесообразно выделять специ-
фические цели испытаний и соответствующие им категории
тестирования:
функциональное тегирование— для проверки полноты и
корректности решения основных задач при типовых условиях;
стрессовое тестирование — испытания программ при пре-
дельных и критических значениях параметров и условий экс-
плуатации;
тестирование использования ресурсов ЭВМ — для проверки
корректности распределения памяти и производительности
вычислительных средств при нормальных и предельных усло-
виях решения задач;
тестирование параллельного решения задач в многома-
шинных или многопроцессорных системах — для испытаний
КП в условиях взаимодействия при параллельном исполнении
отдельных программ;
тестирование надежности функционирования КП — для оп-
ределения характеристик надежности и эффективности средств,
используемых для их повышения.
Функциональное тестирование— наиболее обширное и
труднее всего систематизируемое. Набор испытательных тестов
полностью определяется функциональными задачами и слож-
ностью КП. Эти тесты должны обеспечивать проверку и демон-
страцию заказчику-пользователю качества решения функцио-
нальных задач, сформулированных в техническом задании и
конкретизированных в документации.
Поскольку исчерпывающее тестирование для сложных
КП невозможно, большое значение имеет уточнение областей
варьирования тестовых данных и выделение областей их из-
менения, наиболее важных для последующего использования
программ. Кроме того, для испытаний устойчивости функцио-
нирования при аномалиях на входе программы тестируются
при значениях переменных, которые невозможны при нормаль-
ном функционировании источников- исходных данных. Таким
образом, проблема функционального тестирования может рас-
сматриваться как проблема определения обла-
стей изменения исходных данных и их
классификации на допустимые, нааиболее вероятные и не-
допустимые.
Большой объем тестовых данных приводит к необходимо-
сти оптимизировать набор тестов, обеспечивающих наиболь-
шую глубину проверок испытываемых программ при задан-
ной длительности испытаний и соответствующей ей сложности
тестирования. Для увеличения полноты тестирования в ряде
234
случаев целесообразно учитывать результаты тестирования
при комплексной отладке и иа предыдущих этапах испытаний.
Это позволяет не повторять полностью выполненные провер-
ки и акцентировать внимание на условиях и значениях па-
раметров функционирования программ, который могут способ-
ствовать выявлению ошибок и ранее не контролировались.
При функциональном тестировании особенно ва?кно созда-
вать, условия испытаний, которые позволяют обнаруживать
ошибки исполнения программ, а не только демонстрируют их
работоспособность. Такие условия должны соответствовать
ограничениям технического задания или специально согла-
совываться между заказчиком и разработчиком.
Стрессовое тестирование (в критических ситуациях) ба-
зируется на проведенной ранее классификации областей оп-
ределения исходных данных и использует граничные или экс-
тремальные значения параметров ,и условий. В § 3.4 такие
граничные значения параметров рассматривались при анализе
потоков данных. Однако при испытаниях программ особенно
важно использовать в тестах сочетания граничных и экстре-
мальных значений различных параметров. Комбинации кри-
тических значений и условий испытаний в большинстве слу-
чаев очень разнообразны и необходим тщательный анализ Для
выделения достаточно представительной выборки.
Испытания программ в критических условиях и при
значениях параметров вблизи границ областей определения
должно показать корректность решения задач, если условия
и параметры не выходят за пределы, ограниченные техничес-
ким заданием и документацией. Кроме того, при стрессовых
испытаниях должно быть показано, что При изменении исход-
ных данных за допустимыми пределами, эти ситуации обна-
руживаются, селектируются и выдается диагностика о на-
рушении ограничений на условия эксплуатации программ.
Тестирование использования ресурсов ЭВМ комплексом про-
грамм в значительной степени явдяетея стрессовым тестиро-
ванием. При этом вниманий сосредоточивается на исследова-
_ иии зависимости емкости памяти и длительности решения за-
дач от предельных характеристик исходной информации. Оп-
ределяются допустимые размерность задач и интенсивности
потоков исходных данных, при которых возможно нормальное
функционирование КП на данной ЭВМ {см. § 4.3).
Тестирование параллельного решения задач в многомашин-
ных или многопроцессорных вычислительных комплексах со-
стоит -в испытаниях взаимодействия программ и данных при
одновременном исполнений компонент КП (181. Эти испыта-
ний можно разделить на две части: при детерминированных.
235
запланированных ситуациях и при случайном нормальном
функционировании программ. В первом случае основная
проблема состоит в создании представительногоТиногообразия
ситуаций параллельного функционирования программ. Вто-
рая часть тестирования может совмещаться с остальными ви-
дами испытаний и заключается, в основном, в выделении слу-
чайных тестов и условий, при которых проверяется недетер-
минированное параллельное исполнение программ (см. §4.3).
Тестирование надежности программ. В теории надежности
разработан ряд методов, позволяющих, определять характе-
ристики надежности сложных систем. Эти методы можно све-
сти к трем основным группам:
прямые экспериментальные методы определения показате-
лей надежности систем в условиях нормального функциони-
рования;
форсированные методы испытаний реальных систем на на-
дежность;
расчетно-экспериментальные методы, при использовании
которых ряд исходных данных для компонент получается
экспериментально, а окончательные показатели надежности
систем рассчитываются с использованием этих данных.
Прямые- экспериментальные методы определения показа-
телей надежности программ в нормальных условиях функцио-
нирования в ряде случаев весьма трудно использовать при
испытаниях из-за больших значенйй времени наработки на
отказ (десятки и сотни часов). Сложность выявления и реги-
страции редких отказов, а также высокая стоимость экспери-
ментов при длительном функционировании сложных КП при-
водят к тому, что на испытаниях получаются малые выборки
зарегистрированных отказов-. Кроме того, при таких экспе-
риментах трудно гарантировать полную представительность
выборки исходных данных, так как режимы эксплуатации
определяются конкретными условиями использования дан-
ного КП на испытаниях [74, 93, 981.
При испытаниях КП на Надежность функционирования не-
обходимо разделение причин Отказов и отказовых ситуаций
на обусловленные ненадежностью аппаратуры и Ошибками в
программах. Устойчивые отказы аппаратуры Селектируются
достаточно просто. Однако кратковременные сбои в аппарату-
ре й последствия ошибок в программе требуют тщательного
анализа для выделения И диагностики их источника. Для это-
го прежде всего в процессе стохастического и динамического
тестирования необходимо регистрировать состояние исходных
данных и аппаратуры при обнаружении отказа. Значитель-
ную помощь может оказать программа анализа сбоев [501.
23К'
Эта программа автоматически регистрирует наличие отказа
и отказовой ситуации, а также условия их возникновения,
осуществляет первичный анализ и классификацию,возможных
источников аномалий функционирования. Для диагностики
и локализации причины отказа обычно требуется дополни-
тельное стохастическое недетерминированное тестирование,
которое позволяет либо выделить первичную ошибку в про-
грамме, либо отнести источник отказа к сбою в аппаратуре.
При дополнительном тестировании одна из задач заключается
в подготовке стохастических тестов, способных значительно
повысить частость проявления отказов вследствие локали-
зуемых ошибок. Это позволяет в конце концов зафиксировать
значения тестовых данных, при которых происходит отказ,
й детерминированным тестированием локализовать ошибку.
Ошибки, локализованные в программах, на этапе испы-
таний Целесообразно устранять. При этом характеристики на-
дежности КП становятся не стационарными. Этн
характеристики в среднем улучшаются, однако возможны из-
менения программ, которые их ухудшают. Для выявления
тенденции изменения показателей надежности их значения
обрабатываются методами теории статистики. Измерения по-
казателей надежности необходимо связывать во времени с мо-
ментами корректировки программ. Анализируя корреляцию
между значениями надежНостй и процессом изменения про-
грамм, можно выявить корректировки, 'которые содержат
ошибки и ухудшают надежность.
Получающиеся при этом показатели надежности позволя-
ют прогнозировать число ошибок, подлежащих исправлению
для достижения заданной надежности. Для этого использу-
ются математические модели изменения ошибок и основных
показателей надежности в зависимости от длительности тес-
тирования (см. § 1.2). При высокой надежндсти КП органи-
зуются многочасовые прогоны реального функционирования
программ в условиях широкого варьирования исходных дан-
ных. Такие; прогоны позволяют измерить и зафиксировать
достигнутые показатели надежности и степень их соответст-
вия требованиям технического задания, а также закрепить
их в технических условиях на КП.
 Форсированные испытания надежности программ значи-
тельно отличаются от традиционных методов испытаний ап-
паратуры. Основными факторами, влияющими на надеж-
ность КП, являются исходные данные и их взаимодействие с
ошибками программ или сбоями в аппаратуре ЭВМ., Поэтому
форсирование испытаний осуществляется повышением интен-
сивности искажений исходных данных и расширением варьи-
237
рования их значений, а также специальным увеличением за-
грузки КП выше нормальной. Планирование форснрован-
ных .испытаний должно предусматривать последующий пе-
ресчет полученных показателей надежности на условия нор-
мального функционирования. Для этого необходимо изучать
надежность испытываемых программ в зависимости от интен-
сивности искажений данных или от характеристик перегрузки
ЭВМ и способы корректного пересчета получаемых показа-
телей на нормальные условия эксплуатации.
Особым видом форсированных испытаний является тести-
рование эффективности средств контроля и восстановления
программ, данных и вычислительного процесса. Для этого
имитируются запланированные экстремальные условия функ-
ционирования программ, при которых в наибольшей степени
стимулируется работа тестируемого средства программного
рестарта. При таких испытаниях основная задача состоит в
проверке качества функционирования средств повышения
надежности, а оценка интегральных показателей надежности
отходит на второй план.
Форсированные методы испытаний программ иногда при-
меняются заказчиком без предварительного согласования с
разработчиком условии таких испытаний и методики пересче-
та получаемых показателей на нормальный режим функцио-
нирования. В результате показатели надежности оказываются
ниже заданных техническим заданием, В любом случае при
использовании форсированных методов испытаний недопусти-
мо произвольное неконтролируемое варьирование тестовых
данных за пределами требований согласованного задания, так
как в этом случае оценки показателей надежности оказыва-
ются некорректными и не соответствуют заданным нормаль-
ным условиям функционирования программ.
Расчетно-экспериментальные методы определения надеж- .
ности программ более ограничены, чем при анализе аппара-
туры- Это обусловлено прежде всего неоднородностью надеж-
ностных характеристик основных компонент: программных
модулей, групп программ, массивов данных и т. д. (см. гл. 3).
Однако в некоторых случаях расчетным путем можно оценить
характеристики надежности компонент КП. Если, например,
экспериментально определены характеристики возможного
искажения массива данных при функционировании КП, то
аналитически можно рассчитать надежность хранения данных
при типовых схемах их дублированного хранения и оператив-
ного восстановления при искажениях.
Планирование тестирования при испытаниях программ.
Особенностью планирования тестирования при испытаниях
ЭД8
программ является необходимость достаточно полной ихпро-
верки при ограниченной длительности испытаний. Эта особен-
ность определяет целесообразность тщательного планирова-
ния тестирования с учетом всех результатов, полученных ца
предыдущих этапах тестирования. При планировании основ-
ная задача состоит в достижении максимальной достоверности
испытаний и определения качества КП при ограниченных за-
тратах ресурсов всех видов на проведение тестирования. Для
этого прежде всего необходимо выявить области изменения
тестовых значений на предыдущих этапах испытаний. Полно-
стью повторять тестирование в этих областях обычно нецеле-
сообразно и можно ограничиться некоторой, относительно
небольшой (~10 %) выборкой тестов из имеющегося набора
для подтверждения ранее полученных результатов. Такая тех-
нология требует сохранения тестов и результатов тестирова-
ния на этапах отладки, если в дальнейшем их можно будет
использовать.
Основная часть тестов при испытаниях должна обеспечи-
вать проверку программ в областях изменения переменных
и условий, протестированных В наймем ь-.
шей степени. Поэтому при планировании испытаний
основное внимание сосредоточивается на подготовке стрессо-
вых тестов, на тестировании в режимах предельного исполь-
зования ресурсов и иа тестировании надежности КП. Задача
испытателей и заказчика при Планировании испытаний состоит
в выделении условий и областей изменения переменных, ко-
торые недостаточно проверены разработчиком и важны для
последующего использования программ. При этом разработ-
чик контролирует, чтобы планируемое тестирование не вы-
ходило из областей, заданных техническим заданием. Испы-
тания за пределами технического задания могут квалифици-
роваться как его расширейие или могут исключаться по т*ре-
бованию разработчика.
При планировании испытаний важную роль играет оценка
и обеспечение близких значений методической и статистичес-
кой достоверностей испытаний (см. §4.1). Если высокая ме-
тодическая достоверность испытаний не может быть исполь- "
зована вследствие ограничений по набору статистики резуль-
татов тестирования, то оказываются нерентабельно затрачен-
ными .ресурсы иа обеспечение методической достоверности.
Однако возможны случаи, когда некоторые неучтенные фак-
торы значительно снижают методическую достоверность, в
результате чего может сказаться бесполезным набор большой
статистики при испытаниях.
"	t 239
 Методическая достоверность испытаний КП определи*
ется следующими факторами:
полнотой программы испытаний и корректностью методик
тестирования по охвату возможных условий функциониро-
вания' и областей изменения исходных данных программ;
достоверностью и точностью эталонных значений, с кото-
рыми сравниваются результаты тестирования испытываемой
программы или которые служат опорными при расчете пара-
метров, зафиксированных в техническом задании;
адекватностью и точностью моделей, используемых для
имитации.тестов от внешних абонентов и для подыгрыща их
реакции на управляющие воздействия;
точностью и корректностью регистрации и обработки ре-
зультатов тестирования, а также сравнения полученных дан-
ных с требованиями технического задания.
До начала испытаний подлежат проверке и паспортиза-
ции средства, обеспечивающие получение эталонных данных,
средства имитации тестов внешних абонентов и средства фик-
. сирования и обработки результатов тестирования. Например,
при испытаниях программ, решающих задачи управления
воздушным движением, эталонами служат координаты и па-
раметры движения воздушных объектов, получаемые спе-
циальными высокоточными радиолокационными станциями
113, 69, 81] по небольшому количеству объектов. Остальная
воздушная обстановка может дополняться имитаторами тестов
на базе цифровых вычислительных машин. Результаты функ-
ционирования системы регистрируются в ходе экспериментов
и накапливаются либо в управляющей ЭВМ, либо на специ-
альных носителях информации. Сопоставление результатов
тестирования с эталонными данными, полученными специаль-
ными измерителями и сформированными при моделировании,
может производиться на универсальной вычислительной маши-
не после завершения экспериментов. На этой же вычислитель-
ной машине обрабатываются результаты тестирования и рас-
считываются параметры, подлежащие проверке на соответст-
вие техническому заданию. .......
Для корректности испытаний измерительные, имитирую*
щие, регистрирующие и обрабатывающие средства, и в том
числе программы обработки результатов, паспортизируются
до начала испытаний и периодически проверяются в ходе всех
испытаний. Объем работ по созданию таких испытательных
комплексов и их эксплуатации может быть весьма большим и
его разработку следует планировать намного раньше начала
испытаний. В то же время корректность тестирования и воз-
240
можности средств по его проведению существенно определяют-
достоверность. и длительность Испытаний.
Статистическая достоверность испытаний в' значительной
степени ограничена допустимым объемом и продолжитель-
ностью испытаний. Методы теории планирования экспери-
ментов позволяют упорядоченно варьировать исходные дан-
ные и наиболее эффективно использовать ограниченные ре-
сурсы тестирования. Статистическая достоверность испытаний
может быть повышена за счет использования данных, получен-
ных в процессе комплексной отладки и на других этапах раз-
работки программ. Подобное использование ранее получен-
ных данных наиболее наглядно можно показать на примере
определения надежности функционирования программ.
Математические модели .оценки наработки на отказ (см.
§ 1.2) по набору данных моментов выявления отказов t( позво-
ляют определить параметры математической модели К и Т
для данного проекта. В результате может быть оценена нара-
ботка до следующего выявления ошибки или отказа (1.7). Та-
ким образом, при испытаниях появляется опорное значение
наработки на отказ, базирующееся на всех результатах вы-
явления отказов, полученных при комплексной отладке. Это
значение может включаться в статистику наработок на отказ,
полученных в ходе испытаний, с весом, определяющимся чис-
лом отказов, выявленных при комплексной отладке и вклю-
ченных в обработку при определении параметров математи-
ческой модели - (1.5), (1.6).
В процессе испытаний КП могут выявляться ошибки, ко-
торые необходимо устранять. Количество выявляемых оши-
бок зависит от тщательности комплексной отладки и от плана
тестирования при испытаниях. После устранения ошибок
необходимо частично повторить тестирование, прежде всего
при тех условиях, которые позволяли обнаружить ошибку.
Поэтому при планировании испытаний следует выделять ре-
зервы времени для локализации и устранения некоторого чис-
ла ошибок и для корректировки отдельных документов.
Некоторые недостатки КП в процессе испытаний только
регистрируются и фиксируются в плайе устранения замечаний
группы, проводившей испытания. Этот плац является прило-
жением к акту о результатах испытаний н позволяет отделять
последующие доработки от непосредственных испытаний.
; При планировании испытаний большое значение имеют
характеристики средств автоматизации, используемых для
имитации внешней среды и обработки результатов. Наиболее
полно тестируются опытные образцы и версии КН после зна-
чительной модернизации (см. гл. 5). Кроме того, должны быть
обеспечены испытания каждого экземпляра программ при
передаче пользователю и эпизодически при/ эксплуатации.
Эти виды испытаний значительно различаются целями, слож-
ностью, глубиной и достоверностью проверок. Противоречия
между необходимой степенью достоверности тестирования и
объемом анализируемых данных при различных видах испы-
таний привели к созданию систем автоматизации испытаний
различной сложности и глубины проверок. Их можно разде-
лить на следующие типы:
системы автоматизации испытаний опытного образца КП
на соответствие всем требованиям технического задания;
системы автоматизации тестирования на заводе-изготовй-
теле серийных образцов КП на соответствие утвержденным
техническим условиям;
системы автоматизации тестирования каждого КП в про-
цессе его эксплуатации и решения задач на соответствие до-
кументации.
Перечисленные системы последовательно упрощаются по
объему допустимых проверок, и представляемые ими харак-
теристики отражают функционирование систем в более обоб-
щенном и интегральном виде. Одновременно происходит зна-
чительное сокращение допустимой длительности тестирования
и использования соответствующих контрольных средств.Уиж
версализация средств обеспечения испытаний затруднена преж-
де всего разнообразием функциональных требований техни-
ческих заданий, подлежащих проверке. Однако отдельные
компоненты имитаторов исходной информации, программ об-
работки результатов, программ управления системами авто-
матизации испытаний могут быть в значительной степени
унифицированы для широкого класса систем на правах стан-
дартных подпрограмм. Для этого необходимо соблюдение
единых правил структурного построения системы автомати-
зации испытаний и их компонёнт.
Уникальный характер и сложность систем автоматизации
испытаний ограничивает возможность их применения при мас-
совом серийном изготовлении и эксплуатации. В этом случае
для проверки каждого КП на соответствие техническим усло-
виям должен быть создан некоторый сокращенный вариант
системы, на базе которой испытывался опытный образец.
В то же время испытания и проверки по техническим условиям
не могут полностью гарантировать отсутствие ошибок в КПд
Для обеспечения выявления ошибок в процессе эксплуатации
серийных образцов в каждом из них должен быть предусмот-
рен некоторый минимум средств проверки функционирования
н обнаружения искажений результатов. Этот минимум средств
242
должен .позволять фиксировать условия неправильной рабо-
ты программ и характер проявления искажения. Последую-
щая локализация причин неправильного функционирования
программ может проводиться либо в заводских условиях с ис-
пользованием системы автоматизации проверки по техничес-
ким условиям, либо на опытном образце при дополнительных
испытаниях.
Порядок проведения и оценки результатов тестирования
при испытаниях программ. Тестирование при испытаниях
сложных КП является наиболее формализованным и регла-
ментированным видом тестирования, подкрепленным значи-
тельным Числом документов. Для всесторонней проверки
опытный образец КП подвергается испытаниям, которые обыч-
но проходят две стадии: испытания главного конструктора
(предварительные испытания) и испытания заказчика-поль-
зователя с участием разработчиков (совместные испытания).
При испытаниях главного конструктора, которые зачастую
совмещаются с завершением комплексной отладки, произво-
дится, по существу, такое же тестирование, что и на совмест-
ных испытаниях, только в несколько меньшем объеме. Эти
проверки оформляются документально и являются основанием
для предъявления КП заказчику на совместные испытания.
Любые испытания ограничены допустимым объемом проверок
и длительностью работы комиссии, поэтому не могут гаранти-
ровать всестороннюю проверку изделия. Для повышения до-
стоверности определения и улучшения характеристик КП после
испытаний главного конструктора программы целесообразно
на некоторое время передавать на опытную эксплуатацию в
типовых условиях. Это позволяет более глубоко оцени*гь экс-
плуатационные характеристики созданного комплекса и устра-
нить некоторые ошибки. Опытная эксплуатация проводится
разработчиками с участием испытателей и некоторых поль-
зователей, назначаемых заказчиком. Результаты опытной
эксплуатации после испытаний главного конструктора могут
учитываться при проведении совместных испытаний для их
сокращения.
Совместные, испытания проводятся комиссией заказчика,
в которой участвует главный конструктор разработки и не-
которые ведущие разработчики. Комиссия при испытаниях
руководствуется следующими документами:
утвержденным заказчиком и согласованным с разработчи-
ком техническим заданием на КП;
действующими государственными и отраслевыми стан-
дартами на проектирование и испытания программ и на тех-
ническую документацию;
.243
обеспечены испытания каждого экземпляра программ при
передаче пользователю и эпизодически при' эксплуатации.
Эти виды испытаний значительно различаются целями, слож-
ностью, глубиной и достоверностью проверок. Противоречия
между необходимой степенью достоверности тестирования и
объемом анализируемых данных при различных видах испы-
таний привели к созданию систем автоматизации испытаний
различной сложности и глубины проверок. Их можно разде-
лить на следующие типы:
системы автоматизации испытаний опытного образца КП
на соответствие всем требованиям технического задания; ‘
системы автоматизации тестирования на заводе-изготови-
теле серийных образцов КП на соответствие утвержденным
техническим условиям;
системы автоматизации тестирования каждого КП в про-
цессе его эксплуатации и решения задач на соответствие до-
кументации.
Перечисленные системы последовательно упрощаются по
объему допустимых проверок, и представляемые ими харак-
теристики отражают функционирование систем в более обоб-
щенном и интегральном виде. Одновременно происходит зна-
чительное сокращение допустимой длительности тестирования
и использования соответствующих контрольных средств.Уни-
версализация средств обеспечения испытаний затруднена преж-
де всего разнообразием функциональных требований техни-
ческих заданий, подлежащих проверке. Однако отдельные
компоненты имитаторов исходной информации, программ об-
работки результатов, программ управления системами авто-
матизации испытаний могут быть в значительной степени
унифицированы для широкого класса систем на правах стан/
дартных подпрограмм. Для этого необходимо соблюдение
единых правил структурного построения системы автомати-
зации испытаний и их компонент.
Уникальный характер и сложность систем автоматизации
испытаний ограничивает возможность их применения при мас-
совом серийном изготовлении и эксплуатации. В этом случае
для проверки каждого КП на соответствие техническим усло-
виям должен быть создан некоторый сокращенный вариант
системы, на базе которой испытывался опытный образец.
В то же время испытания и проверки по техническим условиям
не могут полностью гарантировать отсутствие ошибок в КПд
Для обеспечения выявления ошибок в процессе эксплуатации
серийных образцов в каждом из них должен быть предусмот-
рен некоторый минимум средств проверки функционирования
и обнаружения искажений результатов. Этот минимум средств
242
должен .позволять фиксировать условия неправильной рабо-
ты программ н характер проявления искажения. Последую-
щая локализация причин неправильного функционирования
программ может проводиться либо в заводских условиях с ис-
пользованием системы автоматизации проверки по техничес-
ким условиям, либо на опытном образце при дополнительных
испытаниях.
Порядок проведения и оценки результатов тестирования
при испытаниях программ. Тестирование при испытаниях
сложных КП является наиболее формализованным и регла-
ментированным видом тестирования, подкрепленным значи-
тельным Числом документов. Для всесторонней проверки
опытный образец КП подвергается испытаниям, которые обыч-
но проходят две стадии: испытания главного конструктора
(предварительные испытания) и испытания заказчика-поль-
зователя с участием разработчиков (совместные испытания).
При испытаниях главного конструктора, которые зачастую
совмещаются с завершением комплексной отладки, произво-
дится, по существу, такое же тестирование, что и на совмест-
ных испытаниях, только в несколько меньшем объеме. Эти
проверки оформляются документально и являются основанием
для предъявления КП заказчику на совместные испытания.
Любые испытания ограничены'допустимым объемом проверок
и длительностью работы комиссии, поэтому не могут гаранти-
ровать всестороннюю проверку изделия. Для повышения до-
стоверности определения и улучшения характеристик КП после
испытаний главного конструктора программы целесообразно-
на некоторое время передавать на опытную эксплуатацию в-
типовых условиях. Это позволяет более глубоко оценить экс-
плуатационные характеристики созданного комплекса и устра-
нить некоторые ошибки. Опытная эксплуатация проводится
разработчиками с участием испытателей и некоторых поль-
зователей, назначаемых заказчиком. Результаты опытной
эксплуатации после испытаний главного конструктора могут
учитываться при проведении совместных испытаний для их
сокращения.
Совместные испытания проводятся комиссией заказчика,
в которой участвует главный конструктор разработки и не-
которые ведущие разработчики. Комиссия при испытаниях
руководствуется следующими документами:
утвержденным заказчиком и согласованным с разработчи-
ком техническим заданием на КП;
действующими государственными и отраслевыми стан-
дартами на проектирование и испытания программ и на тех-
ническую документацию;
.243
программой испытаний по всем требованиям технического
задания;
методиками испытаний по каждому разделу требований
технического задания.	-
Программа испытаний, методики их проведения и оценки
результатов, разработанные совместно заказчиком и разра-
ботчиком, должны быть- согласованы и утверждены. ОнП со-
держат уточнения требований технического задания для дан-
ного КП и должны гарантировать их корректную проверку.
В процессе испытаний должны быть не только определены
характеристики КП, но и выявлена пригодность испытывае-
мой системы к эксплуатации в режимах, заданных техничес-
ким заданием. Это, в частности, означает, что документация
на КП должна полностью соответствовать испытываемым
программам, обеспечивать познаваемость системы обслужи-
вающим персоналом, а также обеспечивать возможность разви-
тия и модернизации программ для увеличения их жизненного
цикла. В процессе испытаний проверяются и корректируются
инструкции по эксплуатации комплекса во всех заданных ре-
жимах. Такими режимами являются:
контроль работоспособности программ и функциональный
контроль всего комплекса перед включением рабочего режима;
нормальное рабочее функционирование всех программ в
различных условиях;
аварийные и критические (стрессовые) маловероятные
ситуации, при которых должна сохраняться работоспособность
программ;
диагностика компонент программ и .аппаратуры поиска
неисправностей или источника искажений;
профилактические работы, контроль носителей информа-
ции и программ, их дублирование, эталонирование и т. д.
Программа испытаний является планом проведения серии
экспериментов И разрабатывается с позиции минимизации
объема тестирования при заданной и согласованной с заказчи-
ком достоверности Получаемых результатов. Для этого ме-
тодами факторного анализа и теории планирования экспери-
ментов определяется последовательность и объем каждого тес-
тирования в процессе проведения испытаний для проверки
выполнения требований технического задания при минималь-,
ных затратах. Особенно сложно выбрать минимальный набор
стрессовых ситуаций функционирования системы, при кото-
рых, следует провести испытания. Программа испытаний
должна содержать следующие четко сформулированные раз-
делы:
244
объект испытаний, его’ назначение и перечень
основных документов, определивших его разработку;
п'ель испытаний с указанием основных требова-
ний технического задания, подлежащих проверке, и ограни-
чений на проведение испытаний;
собственно программу испытаний, содержа-
щую проверку комплектности спроектированного КП в соот-
ветствии с техническим заданием и план тестирования для
проверки по всем разделам технического задания и дополни-
тельным требованиям, формализованным отдельными решени-
ями;
методики испытаний, однозначно определяю-
щие всё понятия проверяемых характеристик, условия тес-
тирования, средства, используемые для испытаний, методи-
ки обработки и оценки результатов тестирования по каждому
разделу программы испытаний.
Большой объем разнородных данных, получаемых при
испытаниях КП, я разнообразие возможных способов их об-
работки, интерпретации и оценки приводят к тому, что важ-
нейшими факторами для обработки результатов тестировав
ния,становятся методики обработки и оценки
результатов, а также протоколы проверки, по пунктам
программы испытаний. Как уже отмечалось, методики должны
обеспечивать единство взглядов заказчика и разработчика
программ на детальную технологию обработки и оценку ре-
зультатов тестирования и не допускать искажений интерпре-
тации результатов за счет неоднозначности методик. В соот-
ветствии с методиками испытаний средства автоматизации
должны обеспечивать всю полноту проверок характеристик
по каждому разделу методик. Сложность КП и сильная вза-
имосвязь между их характеристиками приводят к необходи-
мости тщательной формулировки всех условий тестирования
и значений параметров, при которых должна производиться
проверка по каждому разделу программы.
Результаты испытаний фиксируются в протоколах, кото-
рые обычно содержат следующие разделы;
назначение тестирования н раздел требований техничес-
кого задания, по которому проводится испытание;
указание методик, в соответствии с которыми проводились
испытания, обработка и оценка результатов;
условия проведения тестирования й характеристика ис-
ходных Данных;
обобщенные результаты испытаний с оценкой их на соот-
ветствие требованиям технического задания и другим руково-
дящим документам;	- ' ,
выводы о результатах испытаний и соответствий создан-
ного КП определенному разделу требований технического за-
дания.
Протоколы по всей программе испытаний обобщаются в
акте, в результате чего делается заключение о соответствии
системы требованиям заказчика и о завершении работы с по-
ложительным или отрицательным итогом. При полном вы-
полнении всех требований технического задания заказчик,
обязан принять систему и работа считается завершенной. .
Однако, как ужеготмечалось, для сложных КП трудно на
начальных этапах проектирования предусмотреть и корректно
сформулировать все требования технического задания. Поэ- '
тому при отладке и испытаниях часто выявляется, что неко-. ?
торые требования технического задания оказываются невы- j
полненными,- и иногда даже принципиально не могут быть :
выполнены при самом добросовестном отношении к этому со. 5
стороны разработчика., В этом случае необходима совместная
работа заказчика и разработчика в поисках компромиссного |
решения при завершении испытаний и составлении заключе-
ния.	•
Если невыполненные требования являются второстепеп-
ными и слабо влияют на-решение основных целевых задач КП,
то может быть допустима корректировка технического задания
или приемка комплекса с отклонениями от требований. При
выявлении в процессе испытаний отклонений от основных
требований технического задания, существенно влияющих на
целевые задачи функционирования, КП подлежит бракова-
нню и возвращается на доработку и на повторные испытания- '
Таким образом, заключение по испытаниям должно содер- *
жать степень выполнения требований технического задания ;
и вывод о возможности передачи программ в эксплуатацию ;
и для серийного производства.	«
ГЛАВА 5
ТЕСТИРОВАНИЕ ПРИ СОПРОВОЖДЕНИИ КОМПЛЕКСОВ
ПРОГРАММ
5.1. ПРИНЦИПЫ КОНФИГУРАЦИОННОГО УПРАВЛЕНИЯ
И СОПРОВОЖДЕНИЯ КОМПЛЕКСОВ ПРОГРАММ
Задачи сопровождения программ. После успешного Завер-
шения приемо-сдаточных испытаний опытного образца про-
граммы подлежат тиражированию и эксплуатации. В процес-
се эксплуатации комплексы программ не остаются неизменны-
ми, соответствующими опытному образцу. Программы явля-
246
ются одним из наиболее гибких видов промышленных изделий
и эпизодически подвергаются изменениям в течение всего вре-
мени их использования, что может приводить к ошибкам и
снижению их качества. Иногда достаточно одной ошибки, вне-
сенной при Корректировке, чтобы резко снизилась надежность
программы или ее корректность при некоторых исходных дан-
ных. Для сохранения и повышения качества КП необходимо
регламентировать процесс модификации и поддерживать его
соответствующим тестированием и контролем качества. В ре-
зультате программное обеспечение со временем обычно улуч-
шается как по функциональным возможностям, так и по ка-
честву решения отдельных задач.
Работы, обеспечивающие контроль и Повышение качества,
а также развитие функциональных возможностей программ,
составляют процесс сопровождения {15, 23, 1111. В сопровож--
дение входят мероприятия по выявлению и устранению обна-
руженных ошибок, тиражирование и контроль распростра-
нения версий, введение новых функций и компонент в КП,
анализ состояния и корректировка документации, обеспечение
сохранности магнитных носителей и т. д. Для проведения этих
работ необходимы данные о текущем состоянии и качестве
функционирования программ, основным методом получения
которых является тестирование.
Сопровождение необходимо предусматривать с начала
разработки, с подготовки технического задания на КП. Тех-
нология разработки программ в значительной степени зависит
от перспективы последующего сопровождения. Для этого
оценивается возможная*длительность сопровождения и тираж
КП, которые учитываются При введении стандартов на техно-
логию проектирования компонент и комплекса в целом. Эти
данные являются основой для выработки стратегии сопровож-
дения после завершения испытаний опытного образца. С точки
зрения мероприятий по сопровождению программы можно раз-
делить на: уникальные, е д'и ничные, серийные
и массовые. Сопровождение уникальных и единичных
программ обычно осуществляется разработчиками опытного
образца и практически неотделимо от разработки. Более
сложным является сопровождение массовых и крупносерий-
ных КП, которому посвящена данная глава.
При создании массовых КП, которые подлежат длительно-
му сопровождению, необходимы дополнительные затраты
на структуризацию программ, повышение независимости мо-
дулей, обеспечение ясности и простоты их межмодульных свя-
зей и функционирования, на стандартизацию программиро-
вания и упорядоченное тестирование (рис. 5.1). Кроме того,
247
С.	Рис. 5,1. Зависимость относи-
тельных ^затрат С на раэработ-
5 	/	~ ку КП от отношений длнтель-
/ -	ности сопровождения Tt к дли-
4 ’	/	тельности разработки Tv
з -	/
у	затраты возрастают при
2 .	повышении сложности и
,	увеличении функциональ-
'o.i о.2~"од 1—2—5—io"r«/7#> ных возможностей исполь-
зуемых . средств автомати-
зации проектирования программ, а также из-за необходи-
мости их эксплуатации в течение всей длительности сопровож-
дения. Однако эти затраты оправданы повышением качества
программ, увеличением длительности их жизни и снижением
суммарных затрат на непосредственное сопровождение про-
грамм.
Сопровождение' можно считать в значительной степени
обеспеченным, если КП имеет четкую и ясную структуру, а.
его Компоненты — унифицированные простые связи по уп-
равлению и по информации. Для удобного и качественного
сопровождения структура и содержание компонент должны
способствовать высокой вероятности локализации ошибки
при первом ее проявлении, а также высокой вероятности из-
менения программных компонент без внесения вторичных оши-
бок в другие части КП. Изложенные в § 1.1 правила модуль-
но-иерархического построения КП должны детализироваться
до конкретных методик создания и оформления модулей и
- межмодульного взаимодействия. При этом межмодульные
связи целесообразно, по возможности,‘упрощать и ослаблять
[661, а также подготавливать условия для их проверок при
реальном функционировании программ.* Проектирование КП
сверху вниз и последующее сохранение четкой структуры
данных и межмодульных связей значительно облегчают сопро-
вождение и продлевают срок жизни программ.
В процессе сопровождения в программы вносятся различ-
ные изменения:
исправления о ш ибо к корректировка про-
грамм, выдающих неправильные результаты в условиях,,
ограниченных техническим заданием и документацией (в про-
цессе сопровождения требуют около 20 % общих затрат 1151); 
регламентированная документами а д а п т а ц и я к ус-
ловиям конкретного использования, обусловленным харак-
теристиками внешней среды или конфигурацией аппаратуры,
на которой- предстоит функционировать программам (около
20 % затрат);
модернизация — расширение функциональных
возможностей или улучшение качества решения отдельных
задач в соответствии с новым или дополненным техническим
заданием на-КП (до 60 % общих затрат [151).
Первый вид изменений является непредсказуемым и его
трудно регламентировать. Остальные виды корректировок
носят упорядоченный характер и проводятся в соответствии
с заранее подготавливаемыми планами и документами. Эти
корректировки в наибольшей степени изменяют программы н
требуют наибольших затрат. Поэтому изменения, обуслов-
ленные ошибками, в большинстве -случаев целесообразно на-
капливать и реализовывать, приурочивая к изменениям,
регламентированным модернизациями. Однако некоторые '
ошибки могут -приводить к необходимости срочного исправ-
ления программ. В этих случаях допустимо некоторое отста-
вание корректировки документации при более срочном и ре-
гистрируемом исправлений самих программ.
Рано или поздно, иногда через десятки лет, сопровожде-
ние КП прекращается. Это может быть обусловлено разработ-
кой более совершенных КП или нерентабельным возрастанием
затрат на сопровождение. Часто сопровождение прекращается
постепенно, в процессе последовательного снижения качест-
ва н полноты его поддержки. Для того чтобы со временем прий-
ти к обоснованному решению о прекращении сопровождения,
необходимо периодически оценивать эффективность эксплуа-’
тации и возможный ущерб от отмены сопровождения. В не-
которых случаях решение о прекращении сопровождения при-
ходится принимать в конфликтных условиях противодейст-
вия со стороны отдельных пользователей [88].	*~
Общие закономерности процесса сопровождения комплек-
сов программ. В 60-е годы предполагалось, что цикл сопровож-
дения программ потребует небольших ресурсов и его практи-
чески можно не учитывать при оценке затрат на создание, и
эксплуатацию программ. Однако по мере накопления програм-
много' продукта сопровождение требовало все больших уси-
лий и стало ясно, что по интегральным затратам сопровож-
дение может превосходить разработку. Действительно, если
разработка сложного КП продолжается 3 года, а последую-
щие эксплуатация й сопровождение 20 лет, то можно ожидать,
что интегральные затраты на этих интервалах времени будут
соизмеримыми. Даже при предположении, что сопровождени-
ем КП будут загружены только 20 % специалистов, осущест-
вивших его разработку, суммарные затраты на сопровожде-
ние превысят затраты на разработку в полтора раза. Опыт .
последних лет показал, что во многих случаях для обеспе-
249
чения сопровождения необходимо практически такое же чис-
ло специалистов, которое разработало КП. или, если оно и
сокращается, то не более чем вдвое (331. При таких исходных
данных суммарные затраты на сопровождение будут в три-че-
тыре раза превышать затраты на разработку.
При создании многих КП перемещение специалистов с
разработки на обеспечение сопровождения носит системати-
ческий характер. Это приводит к тому, что по мере накопле-
ния эксплуатируемого программного продукта все большее .
число специалистов переходит в сферу сопровождения. Дейст-
вительно. если предположить, что коллектив специалистов
стабилен и ограничен и что каждые 3 года половина создате-
лей программ переходит на их сопровождение, то за 20 лет на
разработке останется приблизительно 0,5е « 0,016 от перво- ,
начального состава.
Только при прекращении сопровождения первых, разра- 1
ботанных КП прекратится переход кадров в сферу сопровож- ,
дения н установится стабильное соотношение между числом ;
специалистов, занятых разработкой и сопровождением. Это ।
соотношение зависит от длительности разработки и сопровож- ,
дения, от соотношения затрат на их выполнение в каждом про-
екте и от графика начала разработки проектов.
Рост затрат на сопровождение нашел отражение в прогно-
зах затрат па программное обеспечение министерства обороны"' ’
(МО) США на 1990 г. J95] (рис. 5.2). Доля затрат на сопровож-
дение с каждым годом возрастает и к 1990 г. достигнет 60—
70 % от общих затрат на вычислительную технику для МО ,
США. При этом за 1980—1990 гг. затраты на сопровождение
программ возрастут примерно в .14 раз, а затраты на разработ-
ку только в 5 раз. Таким образом, соотношение затрат на со- ;
провождение и на разработку за десятилетие изменится при-
мерно от 0,84 до 2,4, т. е. почти в 3 раза. Можно предположить, и
что в последующем рост относительных и абсолютных затрат
на сопровождение продолжится, хотя и не столь быстро. Сле-
дует ожидать, что в перспек-
тиве соотношение суммарных
ежегодных затрат на сопро-
вождение и на разработку
сложных КП стабилизирует-
ся и будет составлять около
Рис. 5.2. Прогноз соотношения
расходов в США на аппаратные
средства вычислительной техника,
разработку программного обеспе-
чения и его сопровождение
3—4. Поэтому в ближайшие годы резко возрастёт роль те-
стирования программ в процессе сопровождения. Однако осо-
бенностям этого тестирования пока уделяется недостаточное
внимание.
Тестирование при разработке и комплексировании новых
компонент КП в процессе его модернизации технологически
очень близко к тестированию при создании опытного образца.
Однако тестирование для обнаружения и локализации оши-
бок при сопровождении несколько отличается от аналогичных
операций при создании опытного образца программ. Имеется
специфика при тестировании адаптированных рабочих вер-
сий программ. Поэтому целесообразно рассмотреть основные
закономерности сопровождения программ и влияние различ-
ных факторов на затраты при,сопровождении.
Общие закономерности изменения и тестирования программ
выявлены при анализе сопровождения крупной операционной
системы OS/360 [331. Обобщены результаты процесса разра-
ботки 21 версий этой системы (за исключением двух самых
первых) за 12 лет. Процесс первичного проектирования и пер-
вые версии исключены из анализа, так как при их создании
отсутствовали результаты эксплуатации и обратная связь
от пользователя, что существенно повлияло на статистические
характеристики модификации программ. Над развитием си-
стемы работал более или менее постоянный коллектив, конк-
ретный состав которого несколько изменялся из-за естествен-
ной текучести кадров. Поэтому трудоемкость разработки счи-
талась пропорциональной интервалу времени между регист-
рациями очередных версий, который принят за единицу из-
мерения сложности создания версий.
В качестве меры трудоемкости сопровождения и создания
очередной версии использовано число модулей, подвергшихся
изменениям и дополненных в КП. Кроме того, оценивалась
интенсивность работ по созданию версии, которая измерялась
числом измененных модулей на единицу времени. Специфика
связей между модулями, а также структурные особенности
групп программ, не учитывались. Модули имели ограничен-
ные размеры, правила нх оформления стандартизованы.
~ Исследованные операционные системы развивались, по
существу, без ограничений на используемые ресурсы ЭВМ по
памяти и производительности. Это отличает такие системы от
КП управления, функционирующих в системах реального,
времени, и этим частично обусловлены выявленные законо-
мерности эволюция и сопровождения программ. Исследован-
ные зависимости обобщены в несколько «законов» динамики
развития КП. Рассмотрим три основных «закона». '
254
Рис. 5.3. Зависимость доли иамо- 
няемых модулей при создании оче-
редной версии от возраста КП
Первый «закон»
состоит в постоянном изме-
нении и развитии КП до тех'
пор, пока не будет сочтено
экономически выгодным пре-
кратить сопровождение и раз-
работать полностью новый
комплекс программ для ана- .*
логичных целей. Для разви- ...
тия программ имеются внеш- .
ние стимулы со стороны поль- .
зователей, непрерывно предъ- <
являющих новые требования
к функциям и характеристикам программ, а также расширение ..
внешних условий и исходных данных функционирования .
программ. Кроме того, для изменения программ имеются вну- 
трёниие стимулы, заключающиеся в необходимости устране-
ния недочетов проектирования и ошибок программирования, -
выявленных при эксплуатации. В результате образуется цикл
взаимного приспособления изменяющегося КП и расширяю-
щихся внешних условий, в которых он может эффективно ,,
эксплуатироваться.
В процессе развития и изменения КП его первичная чет*
кая структура искажается и усложняется, что приводит к
возрастанию, сложности при модификации программ. Эти осо-
бенности отражаются вторым «законом» — возрас-
тания энтропии (меры неопределенности) КП при сопровож-
дении, если не предпринимаются специальные усилия для ее
уменьшения. По мере развития КП становится все более хао-
тичным по структуре и процессу функционирования и все
больше отличается от упорядоченного, первоначально' заду-
манного варианта, характеризующегося наименьшей энтро-
пией (некоторая внешняя аналогия второму закону термоди-
намики), вплоть до момента нерентабельности дальнейшего -
сопровождения данного комплекса и целесообразности его,
замены на новый КП.	’'
Т р етий «закон» состоит в гладком среднестатичес-,
"ком росте объема и сложности КП. Обобщенные характерце-
стики могут иметь случайные колебания на небольших интер-
валах времени, однако сохраняется регулярная составляющая
непрерывного роста программ (рис. 5.3). Этому процессу со-
2&2:
ответствуют постоянные "усилия коллектива специалистов,
осуществляющих сопровождение КП. Одиако доля продук-
тивно используемых ресурсов уменьшается по мере старения
программного обеспечения. В результате увеличиваются ин-
тервалы времени между выпусками очередных- верст).
Кроме детерминированной и случайной составляющих
прирост числа модулей и доля измененных модулей на версию
(рис. 5.3) имеют периодическую составляющую, которая мо-
жет быть обусловлена взаимодействием процессов развития
КП и исправления ошибок. При эксплуатации системы на-
капливаются замечания и дополнительные требования, а так-
же возрастает опыт разработчиков, что стимулирует прове-
дение доработок программ. Эти доработки подготавливаются
для очередной версии и вводятся в нее. В начале эксплуата-
ции новой версии обнаруживается значительное число вторич-
ных ошибок и недоработок, что вынуждает проектировщи-
ков ограничить расширение функций системы и сосредоточить
усилия на повышении надежности и других - показателей
качества функционирования. В результате появляются две-
три промежуточные версии, близкие по объему' и функциям
и отличающиеся в основном уровнем отлажённости. После
тогЬ как сокращается количество претензий пользователей к
качеству функционирования, появляется возможность удов-
летворить новые требования по развитию функциональных ха-
рактеристик КП. Наличие такой обратной связи с запазды-
ванием приводит к цоявлению периодической составляющей
в характеристиках версий.
На интервал времени между отработанными версиями вли-
яют: также административные планы, запаздывания оформле-
ния полной документации и инерционность в передаче версий
пользователям. В худшем случае возможен распад системы,
когда чрезмерный рост доработок в версии системы делает ее
развитие1 неуправляемым й резко ухудшает эксплуатацион-
ные, характеристики.. Период колебаний объема изменений и
соответствующих нм характеристик качества для больших
КП в разных проектах операционных систем 1331 составляет
1—2 года. Приблизительно такой же период характеризует
развитие версий систем автоматизации программирования, и
отладки ЯУЗА-6, РУЗА, ПРОТВА 1371.
В процессе развития OS/360 установлен объем среднего
прироста системы на каждую версию около 200 модулей. При
этом КП увеличился по объему от 1 тыс. модулей в первых
версиях почти до 5 тыс. модулей в последних. В тех случаях
когда этот уровень прироста сложности был превзойден, для
устранения ошибок и проведения дополнительных корректи-
253
ровок появлялась необходимость создания 1—3 промежуточ-
ных версий с малым приростом количества измененных мо-
дулей. В результате появилось понятие «критической массы»
или «критической сложности» модифицируемой части КП при
сопровождении. Если при модернизации и выпуске очередной
версии объем доработок заметно превышает «критический»,
то велика вероятность частичного ухудшения характеристик
системы или необходимости выпуска нескольких промежуточ-
ных версий для доработки проведенной модернизации. Харак-
терно, что «критический» объем доработок около 200 модулей
оставался (более 10 лет) для коллектива почти постоянным,
несмотря на рост квалификации специалистов, развитие тех-
нологии программирования и другие факторы. При этом
объем доработок в первых версиях составлял около 20 % мо-
дулей и постепенно снизился приблизительно до 5 % от об-
щего числа модулей в последних версиях.
Аналогичная картина наблюдалась при развитии систем
ЯУЗА-6, РУЗА, ПРОТВА, в которых прирост версий более
или менее постоянен по объему и характеризовался 6—10 под-
системами объемом 100—200 тыс. команд. Таким образом,
при сопровождении' КП существует рациональное значение
прироста для очередной версии, которое специфично для каж-
дого коллектива и трудно изменяемо, пока не будут введены
коренные улучшения в технологию проектирования и српро-
вождения программного обеспечения или значительно изменен
состав коллектива.
Стабильность темпа развития КП подтверждается также
практически линейным ростом числа переработанных в каж-
дой версии модулей в зависимости от номера версии. В процес-
се Исследований не удалось установить степень пересечения
версий по Изменяемым модулям, однако ясно, что некоторые
модули многократно перерабатывались, а некоторые практи-
чески не изменялись. Общее число измененных модулей достиг-
ло 17 тыс., т. е. в среднем каждый модуль перерабатывался
трижды. При возрастании сложности версий рост количества
модулей в каждой из иих продолжается непрерывно, однако
увеличивается интервал времени между версиями и снижается
скорость изменения объема КП. Увеличение реальной сложно-
сти КП требует возрастающих усилий на корректировку имею-
щихся и подключение новых модулей, что приводит соответ-
ственно к уменьшению темпа развития комплекса . э
Приведенные зависимости можно объяснить некоторой мо-
делью административной деятельности при сопровождении
КП. Для сопровождения системы коллектив специалистов
имеет ограниченные ресурсы, которые обобщенно можно ха-
рактеризовать бюджетом. .Для введения новых функций и
программных модулей необходимы усилия, которые должны
увеличиваться по мере роста сложности КП. Прогрессивному
развитию программ сопутствует пропорциональный рост
числа вносимых при этом ошибок в комплекс. Рост сложности 1
системы способствует увеличению энтропии, которая требует
затрат на «антирегрессионную» деятельность -- борьбу с
ошибками и отставанием корректировок документации, затрат
на повышение квалификации специалистов и т. д. Пренебре-
жение «антирегрессионной» деятельностью приводит к накопле-
нию потребностей в этой' работе в условиях повышающейся
сложности и ограниченного бюджета. Для борьбы с ростом
сложности программ нужны усилия для их упорядочения.
Мера сложности в данном случае выражает степень накопле-
ния дезорганизации в системе вследствие пренебрежения «ан-
тирегрессионной» деятельностью. В результате приходится
временно снижать развитие программ с тем, чтобы не выйти
за допустимые ресурсы.
Между отдельными компонентами затрат существуют за-
держки и обратные связи, которые затрудняют их описание.
В [331 предложены аппроксимации для перечисленных затрат
и проведено моделирование административной деятельности
при сопровождении КП. Моделирование подтвердило приве-
денные , выше закономерности и. позволило более корректно
подойти к прогнозу развития сложных КП. Выявлены наибо-
лее существенные факторы, влияющие на показатели качества
КП, способствующие улучшению технологии и администра-
тивного управления процессом проектирования программ.
При ограниченных трудовых ресурсах возможна предель-
ная критическая сложность сопровождаемых *
программ, при которой устанавливается динамическое равно-,
весне между доработками и вносимыми ошибками, вследствие
чего качество КП не улучшается.
Затраты на сопровождение программ. Рассмотрим эффек
тивность автоматизации сопровождениями затраты иа егоосу-
ществление [37] по методике, представленной в § 2.3. Дли-
тельность и большой объем работ по тестированию и коррек-
тировке программ в процессе сопровождения способствуют
повышению роли средств автоматизации технологии этих
работ. Сопровождение обычно осуществляется с использова-
нием той же технологии и средств автоматизации, что и про-
ектирование данного КП. Поэтому при анализе целесообраз-
ного уровня автоматизации сопровождения первичные затра-
ты на создание средств автоматизации можно не учитывать.
Кроме того, предположим, что при сопровождении техноло-
.2^5
гические средства не развиваются и полностью соответству-
ют тем, которые применялись при разработке.	-v
Затраты на эксплуатацию средств автоматизации Сзп (см. §2.3)
1 практически аналогичны затратам на проектирование программ и про-
порциональны длительности сопровождения и суммарному изменяемо-
му объему программ. Поэтому для оценки затрат на эксплуатацию тех--
нологии в процессе сопровождении С1Ч можйо воспользоваться выра-
- жеиием для Сзп в (2.15). заменив величину П на -суммарный объем
программ Л1, подвергающихся корректировкам:
С„=алх*кП' UIN.
Затраты иа изменение программ при сопровождении обусловлены.
необходимостью корректировать программы для исправления ошн-
бок, а также для модернизации й усовершенствования выполняемых
функций. Эти затраты можно считать аддитивными и включающими v
три составляющие:	щ
С1С — затраты на обнаружение и устранение ошибок в каждой "Я
версии КП;
С2С — затраты на доработку и совершенствование .программ, фор- i
мирование и испытание новых модернизированных версий КП; S
С9С — затраты на тиражирование каждой новой версии н ее внед-- -Й
' рение в эксплуатируемых, и новых системах,
Затраты на обнаружение и устранение ошибок ClD в программе.,
определяются двумя факторами: затратами на тестирование для обна-
' ружеиня каждой ошибки и затратами на устранение всех выявленных
ошибок при формировании очередной версии. Чем меньше ошибок пф
в программе, тем труднее они обнаруживаются, т. е. тем выше затраты
иа выявление каждой из них. Число выявляемых и устраняемых оши-
бок п зввисит от объема программ Л' практически прямо пропорцио-
нально. Кроме того, полные затраты С10 пропорциональны длитель-.
иости сопровождения 7С, кргда происходит тестирование, выявление и .
устранение ошибок»*	t
б\с ~ ® 1с ^с/По •	*
Дополнения и усовершенствования программ' при формировании
каждой новой версии приводят к появлению новых ошибок, вследствие ?
чего величина л0 иэменяетси около некоторого среднего значения. Эту-,
величину трудно определить прямыми измерениями, поэтому включим
значение л0 в состав коэффициента al0«atc/n0 и оценим значение а1С
Косвенно. КП объемом вДОО тыс. команд,может требовать непрерывных
усилий коллектива в Б—10 человек для устранения ошибок,^ коррек-;
тйровок версий и документации, Отсюда можно оценить а1С, напри-
мер, как величину затрат иа корректировку ошибок в программе в пе-.
рёсчете на одну команду в течение часа для среднего коллектива и^ {>’
специалистов. В каждом экземпляре КП затраты на обнаружение 1н
устранение ошибок при сопровождении присутствуют только А^-й
частью, тогда	-	,
Сц. = alc tc HjN.
Затраты Cte на развитие и модернизацию КП близки по содержа-
нию к затратам на первичную разработку программ, поэтому в качест-
ве опорной можно использовать величину Сл и коэффициент. в1П (см.
§2.3). Модернизация'производится поэтапно и дли каждой новой 1-й
2Й
версии изменяется только некоторая ₽| < 1 часть от объема всего
комплекса (б—20 %) [37]. Удельные затраты на изменяемые программы
при модернизации каждой версии больше, чем затраты на создание
программ такого же объема при первичном проектировании, что мож-
но учесть безразмерным коэффициентом 3 > a»e > 1.
Возрастание удельных затрат при корректировках КП в процессе
сопровождения обусловлено необходимостью тщательцбго анализа вно-
симых изменений на функционирование остальных программ в комп-
лексе, возрастанием объема и повышением уровня тестирования про-
грамм. На затраты влияют изменение состава специалистов, осуществ-
ляющих сопровождение, относнтельво состава, проводившего разра-
ботку, а также сложность фрагментарной корректировки документа-
ции и другие факторы. В результате затраты на разработку новых
компонент и изменение программ в расчете на одну новую команду в
программе при сопровождении возрастают в два-три раза относитель-
но затрат при создании опытного образца. Таким образом, затраты иа
модернизацию и развитие ю версий в жизненном цикле КП, имеющего
объем П н тираж N (входит в С1П), составят
<и
CK=saieCln 2 Pi-
/= 1
Затраты на тиражирование каждой версии Сзс включают совокуп-
ные. затраты иа ивготовление копий программ, нх установку в ЭВМ и
освоение для нормальной эксплуатации. Эти затраты практически со-
ответствуют затратам иа тиражирование программ при первичном вво-
де, зависят От типа памяти для хранения программ в ЭВМ и относи-
тельно невелики (C1CL,— 10*-е-10* руб). Поэтому ниже оий ие учитыва-
ются.
Уровень технологии непосредственно влияет на затраты, связан-
ные с развитием и модернизацией КП, так как в выражение для См
входит величина С,п из (2.14), зависящая от U. Для упрощении ана-
лиза составляющую Ct0 можно представить равной значению С,в с
множителем, зависящим от числа модернизация ш И объема каждой из
них Рь а также от относительной сложности выполнения каждой мо-
дернизации а»с-
Таким образом, полные затраты иа сопровождение в каждом образ-
це КП можйо представить в виде:
€с = а,т*П' U/N+atcC^ 2 ₽i+<»icff <с/^.
i ™ 1
Рассмотрим два достаточно типичных примера: долго сопровож-
даемый, сильно развиваемый КП и однократно слабо модернизируе-
мый комплекс. В первом случае примем, что число версий « = 20,
каждая версия приводит к изменению 20 % программ и затраты иа
создание Каждой версии в два раза больше, чемиа перничиую разра-
ботку Такой же программы (ajc = 2). Тогда затраты на сопровождение
в восемь раз превышают затраты На первичную разработку того же
КП, Для КП объемом П = 10* (рис. 5.4) это приводит ц возрастанию
значений С1П 4- С1с в 9 раз по сравнению с значением Сх&. -
В этом, примере затраты на эксплуатацию технологической систе-
мы можно считать пропорциональными объему измененных программ
П‘, который равен П' = 477. Суммарные затраты на технологию при
проектировании и сопровождении программ будут равны- С30 =
— Сзп + БСзп, вследствие чего снижается доля затрат иа создание и
' 
Рис. 5.4. Зависимость затрат «а
проектирование и сопровождение
программ от уровня автоматиза-
ции проектирования при единовре-
менной замене 20 % Программ
в каждой из 20 версий (---------
£1Т,--------Сэп.-------Сс)
внедрение технологии. В совокуп-
ности учет затрат на длительное
сопровождение программ приво-
дит к возрастанию рационального
уровня-автоматизации технологии
(U = 3 или 4) даже .при ее ис-
пользовании дли малого числа
создаваемых и сопровождаемых
проектов.
Во втором примере предположим, что со = 1,	= 10 и а2с = 2.
Тогда затраты на проектирование возрастают только иа 20.% (С2с =
= 0,2С1п). При этом рациональный уровень автоматизации техноло-
гии практически не изменяется по сравнению с оценками, полученны-
ми прн анализе затрат только на проектирование. Перспективы дли-
тельного сопровождения с большим числом версий способствуют со-
вершенствованию технологии и повышению уровня ее автоматизации.
В частности, эти тенденции отражаются на требованиях к интенсивно-
му развитию и совершенствованию методов и -средств'тестирования
программ.
Принципы конфигурационного управления. Для управ-
ления разработкой крупных проектов сложных технических
систем в 60-е годы были созданы методы конфигураци-
онного управления [9, 661. Цель этих методов —
обеспечение управляемого развития сложных высококачест-
венных технических систем и изделий в течение жизненного
цикла. В качестве исходного принимается постулат, что слож-
ные системы не могут быть точно и исчерпывающе определе-
ны в первичных технических заданиях на разработку. Кроме
того, в реальной практике даже после изготовления и завер-
шения испытаний сложные системы подвергаются многочис-
ленным изменениям для улучшения их качества в течение
всего времени использования вплоть до прекращения эксплуа-
тации. Для этого разработаны методы и средства, обеспечи-
вающие контроль за вносимыми изменениями и возможность
определять фактическое состояние (конфигурацию) системы
при разработке н эксплуатации в любой момент времени, Ос-
новой конфигурационного управления является точная и. до-
стоверная информация о состоянии системы и предполагаемых
изменениях.
Управление конфигурацией позволяет организовывать, система-
тически учитывать и контролировать внесение обоснованных исаик-
-258
циоиированиых изменений в систему и,а всех этапах. Для решения
этих задач применяются конфигурационные идентификация, конт-
роль н учет. Конфигурационная идентификация
включает методы, с помощью которых устанавливается текущий состав
системы, конкретное содержайие выполненных к определенному момен-
ту времени изменений в каждом экземпляре, а также соответствие
системы и документации.
Конфигурационный контроль составляют мето-
ды, позволяющие систематически оценивать предлагаемые измене-
ния системы и координировать нх реализацию с учетом эффективности
каждого из них и затрат на выполнение изменений. Утвержденные и
реализованные изменения подлежат учету и регистрации для обеспе-
чения непрерывной адекватности изделия и сопровождающей его доку-
ментации.
Конфигурационный учет — этЪ методы регистрации
и накопления отчетов о всех реализованных и отвергнутых изменениях
относительно некоторого исходного варианта ’системы. Такие отчеты
в наглядной форме отражают текущее состояние системы, историю ее
развития н подготавливаемые изменения.
Схема и стандарты конфигурационного управления устанавлива-
ют категорию руководителей, которые1 правомочны.определять целе-
сообразность и эффективность изменений, а также техническую осу-
ществимость корректировок изделий с учетом ограничений бюджетов
и сроков. При анализе и селекции изменений важное значение имеет
точный учет степени влияния каждого изменения на все остальные
компоненты системы и на ее основные показатели качества. Поэтому
решения об изменениях должны приниматься на достаточно высоком
уровне руководства проектом, способном оценить их влияние на кон-
цептуальную целостность и качество всей системы.
Эффективность конфигурационного управления в значительной
степени определяется его организацией. При разработке крупных
проектов создаются специальные коллективы, ответственные за уп-
равление конфигурацией конкретной системы. Руководитель (глав-
ный конструктор) проекта является высшим должностным лицом, при-
нимающим важнейшие решения по конфигурации системы.. Непосред-
ственно осуществляет селекцию и контроль проведения изменений со-
вет Конфигурационного управления, имеющий во главе управляющего
конфигурацией, подчиненного непосредственно главному конструк-
тору. Эти лица взаимодействуют, с заказчиком и пользователями для
согласования изменений в системе и в техническом задании, опреде-
ляющем разработку или эксплуатацию системы. Заказчик системы
оценивает и разрешает проводить наиболее крупные изменения, за-
метно влияющие на ее технические характеристики или стоимость.
Утвержденные изменения поступают к специалистам, осуществ-
ляющим планирование их внесения в реальную систему и организацию
разработки конкретных компонент и документов. После выполнения
доработок разработчиками компонент и корректировки документации
следует окончательная проверка корректности изменений, которая
осуществляется специалистами по тестированию и испытаниям. При
положительных итогах испытаний изменения регистрируются спе-
циалистами, ведущий» архив или журнал изменений,.и подлежат за-
вершающей обработке в виде извещений на изменения.
Таким образом, в конфигурационном управлении сложными си-;
стемами участвует большое число специалистов различных направле-
ний и квалификаций, которые в ряде случаев объединяются в единый
коллектив — службу управления конфигурацией,
259
Структура такой службы зависит от Сложности и фазы развития про-
екта, от структуры проектирующей организации и ее взаимодействия с
заказчиком и субподрядчиками и от многих других факторов. Четкость
организации службы и фактическое положение управляющего во мно-
гом определяет эффективность конфигурационного контроля и про-
цесса координированного развития сложных систем. Процедуры кои- '
фигурационного управления и лица, отвечающие за их реализацию,
должны быть определены документами" достаточно высокого^ уровня,
обязательными для выполнения всеми участниками проекта? Только
при этом условии можно обеспечить достоверную информацию о состоя-
нии разработок и возможность координированного развития сложных
систем.
Организация и реализация конфигурационного управления су-
щественно зависит от сложности и конкретных технических особен-
ностей системы. В системах, реализуемых аппаратно, наиболее важно
конфигурационное управление в процессе создания опытного образца
системы. При переходе к эксплуатации аппаратных систем поток из-
менений значительно сокращается, прежде всего вследствие трудности
н большой стоимости их реализации. Иное положение со сложными
Комплексами программ, реализуемыми на ЭВМ.
Относительная легкость модификации программ привела
к тому что значительная часть изменений приходится на пе-
риод эксплуатации и сопровождения программ. В процессе
разработки многие изменения не .требуют больших затрат и
могут выполняться без жесткого контроля и учета, характер-
ных для конфигурационного управления. Некоторые некор-
ректные изменения эксплуатируемых программ могут вызы-
вать значительный ущерб, что приводит к необходимости их
селекции и тщательной проверке. Поэтому для программного
обеспечения конфигурационное управление наиболее эффек-
тивно на завершающих стадиях комплексной отладки, в про-
цессе эксплуатации и сопровождения сложных КП. Особенно-
сти конфигурационного управления ниже излагаются приме-
нительно к этапу сопровождения программных комплексов.
При этом основное внимание акцентируется на различных ме-
тодах тестирования программ и установления их корректно-
сти в процессе сопровождения.
S.J. ТЕСТИРОВАНИЕ ПРИ СОПРОВОЖДЕНИИ ПРОГРАММ
Особенности конфигурационного управления при сопро-
вождении программ. Конфигурационное управление с соот-
ветствующей службой необходимо и особенно эффективно
при сопровождении широко тиражируемых очень сложных
КП, используемых одновременно в нескольких версиях (23,
1111. Предположим, что сопровождается сложный КП (объе-
мом в 105—10’ команд), прошедший испытание опытного об-
разца и уже имеющий и-ю версию. Этот КП используется в
>260
течение 10—20 лет многими пользователями, у каждого из
которых он адаптируется к конкретным условиям примене-
ния.
Схема конфигурационного управления при сопровожде-
нии КП между л-й и (л + 1)-й версиями с учетом тиражиро-
вания и возможности прекращения сопровождения представ-
лена на рис. 5.5. Ошибки и предложения первоначально селек-
тируются специалистами по компонентам КП и анализируют-
ся советом конфигурационного управления по их влиянию на
качество функционирования программ и затратам на осуществ-
ление изменений. Каждое предлагаемое изменение программ
оценивается по следующим критериям:
насколько данное изменение может улучшить эксплуата-
ционные характеристики КП в целом;
каковы затраты на выполнение корректировок в новой вер-
сии и их распространение пользователям;
возможно ли и насколько; сильно влияние изменения иа
функциональные характеристики остальных компонент дан-
ного КП;
какова срочность извещения пользователей о разработан-
ной корректировке и целесообразно ли ее распространять до
подготовки очередной версии;
для какого числа пользователей может быть полезным
данное изменение;
как данное изменение отразится на эксплуатации пользо-
вателями предыдущих версий;
насколько подготовка данного изменения может отразить-
ся на сроках создания очередной версии.
В результате анализа часть предлагаемых изменений от-
вергается, а для тех, которые отобраны для реализации, осу-
ществляется разработка корректировок. Гибкость н кажущая-
ся простота изменения программ значительно затрудняет ве-
дение жесткого конфигурационного управления и учета. Поэ-
тому далеко не всегда конфигурационное управление вводится
как обязательное при создании и сопровождении сложных
программных комплексов. Разработчики программ и даже
пользователи иногда пытаются внести изменения, с их позиции
улучшающие характеристики программ, без санкции руково-
дителя конфигурационного управления. Поэтому внедрять
дисциплину конфигурационного управления при сопровож-
дении программ оказывается труднее, чем при создании дру-
гих технических систе'м.
Относительные затраты на тиражирование программ обыч-
но значительно меньше, чем на разработку и проверку изме-
нений очередной версии. Поэтому в большинстве случаев
261
Ц Рис. 5.5. Организационная структура и взаимодействие групп специалистов при сопровождении КП
внедрение новых версий у пользорателей может осуществлять-
ся заменой носителей программ- копиями новых версий. В
технических системах других классов изменения обычно по-
следовательно вводятся в изделие пользователей и трудоем-
кость таких работ может значительно превышать трудоемкость
подготовки корректировок.
Особое значение приобретает тестирование подготовлен-
ных изменений н испытания выпускаемых версий. При этом
основное тестирование сосредоточивается на проверке коррект-
ности каждой выполненной корректировки программ и ка-
честве функционирования испытываемой эталонной версии
КП. В этом случае значительные трудности представляет
создание достаточно полной совокупности тестов и эталонов
для проверки КП. Испытания эталонов версий значительно
сложнее, чем испытания тиражируемых изделий. При тира-
жировании программ тестирование должно обеспечивать толь-
ко абсолютную идентичность копий и подлинника версии.
Проверка функционирования копий может быть ограничена
некоторым набором типовых контрольных задач. С учетом
этих особенностей последующий анализ тестирования целе-
сообразно разделить на два этапа: при подготовке и внесении
изменений и при тиражировании и обеспечении сохранности
версий КП.
Тестирование при подготовке и внесении изменений в комп-
лекс программ. В процессе эксплуатации n-й версии КП у
каждого т-го пользователя появляются некоторые претензии
к функционированию, которые обычно квалифицируются им
как ошибки эталонной или собственной версии. Информация
от пользователей о выявленных ошибках прежде всего подле-
жит; проверке на достоверность (рис. 5.6). Для установления
достоверности сообщений о выявленных ошибках производит-
ся регистрация условий, при которых проявляются аномалии,
и предварительное тестирование версии программ для селек-
ции неподтверждающихся ошибок. Часть претензий оказы-
вается не связанной с корректностью программ н возникает
лйбо из-за недостаточной квалификации самого пользователя,
либо нз-за неправильной документации на КП, либо из-за
сбоев в аппаратуре ЭВМ. Эти претензии устраняются соответ-
ствующими консультациями.
Установление достоверности ошибок начинается с тести-
рования эталонной версии КП при исходных данных т-го
пользователя, обнаружившего ошибку. Если проявляется
ошибка, то она регистрируется как подтвержденная при за-
фиксированных тестовых данных. При отсутствии проявле-
ния ошибки иа эталонной версии, при тех же исходных дан-
264
ных целесообразно проводить последующее тестирование ко-
пии версии,. адаптированной к условиям применения т-го
пользователя. Если н при этом ошибка не проявляется, то.ре-
гистрируется ее нёподтверждение, о чем сообщается пользова-
телю, и ошибка снимается с учета. В этом случае причиной
предварительного сообщения об ошибке обычно является не-
достаточная квалификация пользователя или сбои в его ЭВМ.
Если ошибка'подтверждена на версии пользователя, то
возможно, что'эта версия была неправильно адаптирована к
условиям применения. Для проверки может быть полезным
повторение адаптации и повторное тестирование новой адап-
тированной версии. Тестирование новой адаптированной вер-
сии может подтверждать проявление ошибки, о которой ин-
формировал пользователь, н тогда ошибка регистрируется для
последующего анализа. Если ошибка не подтверждается, то
регистрируется неправильная адаптация версии пользователем
и уточняется причина некорректной адаптации.
В результате тестирования выявляются подтвердившиеся
ошибки в эталонном КП, в адаптированных версиях или в
документации, которая представляется пользователю. Все >
эти ошибки Подлежат регистрации вместе, с условиями их про-
явления и анализу целесообразности и срочности устранения.
От пользователя могут поступать также предложения по
внесению изменений в (я + 1)- версию для улучшения экс-
плуатационных характеристик и расширения функциональных
возможностей КП. Аналогичные предложения могут посту-
пать ОТ' разработчиков комплекса. Для оценки,предложений -
полезно экспериментальное тестирование эталонной версии
или ее предварительных вариантов.
В процессе сопровождения большое значение имеет исто-
рия эксплуатации КП, развития его версий и соответствующая^ -
документация. Еще на стадии проектирования могут возни-
кать идеи совершенствования программ, которые в этом время
невозможно реализовать нз-за ограниченных сроков проекти-
рования или* по иным причинам. Идеи изменений могут быть
направлены на коренное улучшение функциональных возмож-
ностей программ или некоторые «косметические» улучшения
реализуемых функций. Идеи небольших корректировок .
программ целесообразно накапливать отдельно от’ предложе-
ний по существенному совершенствованию системы. Таким
образом создается документ исходных данных для планиро-
вания доработок и тестирования КП в процессе сопровожде-
ния, содержащий разделы: выявленные ошибки в программах,
предложения По улучшению качества имеющиеся программ и
идеи по коренной, модернизации функций КП.
9 Зак. 1061	265
Ряс. 5.6. Схема применения тестирования при корректировках КП в процессе сопровождения
й	1
Для общения с пользователями и накопления информации j
о выявляемых, недостатках в широко тиражируемых сложных j
КП целесообразно выделение группы специалистов высокой
квалификации, овладевши? всеми функциональными возмож-
ностями данного КП. Эта группа конфигурационного контро- ,
ля и сопровождения должна иметь в Своем зарегистрирован- J
ном и аннотированном арсенале практически весь комплекс
тестов, применявшихся при испытаниях опытного образца и 4
предыдущих версий КП для антирегрессионного тестирова- - 3
ння 164, 20, 331. Эти тесты накапливаются, упорядочиваются и I
каталогизируются в базе данных тестирования. Они исполь- |
зуются для контроля сохранности версий и установления до- j
стоверностн ошибок, сообщенных пользователями. Эти же *;
специалисты осуществляют развитие набора тестов для под- J
твержДения наличия и-локализации частных ошибок, а так- , J
же для первичной оценки целесообразности реализации пред- S
ложений по развитию и модернизации программ.	|
В группе конфигурационного управления сосредоточивает- ]
ся информация для планирования основных.операций по до- j
работке и выпуску очередных версий КП. Специалисты оие- 1
нпвают степень срочности исправления ошибок, и проведения
модернизаций, а также находят условия, позволяющие доста-
точно полноценно эксплуатировать программы до выполне-
ния всех запланированных изменений при выпуске очередной
версии. Для этого также необходимо развивать средства тес-
тирования н проводить множество проверок, которые не вы-
полнялись при создании., опытного образца и предыдущих
версий. Кроме того, специалистам группы управления необ-
ходима «дипломатическая» квалификация для того, чтобы
убеждать пользователей до выпуска очередной'версии некото-
рое время использовать КП без проведения изменений, воз- •
можно с некоторыми ограничениями или видоизменениями
функций.
Для повышения качества очередных версий руководитель
сопровождения и совет конфигурационного управления ана-
лизируют все предлагаемые изменения и выделяет изменения,
разрешенные для данной версий. При выделении изменений
. прихбдится решать оптимизационную задачу по оценке
ущерба от того, что изменение не проведено и не повышается
соответственно качество функционирования- КП, и по оценке
затрат на проведение изменения н возможного ущерба, если
оно содержит ошибки. Селекция проводимых изменений в вер-
сиях сложных КП Требует значительной формализации этого
нроЦесса и документирований утвержденных изменений.
268
В процессе анализа предполагаемые изменения селекти-
руются на четыре группы:
срочные изменения, которые должны не только быть вне-
сены в очередную (л + 1)-ю версию КП, но и сообщены поль-
зователям для оперативной корректировки программ до внед-
рения официальной версии;
изменения, которые целесообразно .внести в (л + 1)-ю
версию с учетом затрат на их реализацию и улучшенйя эффек-
тивности КП;	-
изменения, которые требуют дополнительного анализа це-
лесообразности и эффективности их реализации в последую-
щих версиях и могут не внедряться в ближайшую (л 4- 1)-ю
версию КП;
изменения, которые не оправдывают затрат на разработ-
ку- и выполнение корректировок нли практически не влияют
на эффективность КП и поэтому не подлежат реализаций.
Все проанализированные изменения регистрируются, для
принятых к внедрению изменений разрабатывается план до-
работок программ и определяется ответственный за каждую
корректировку программы- Предположим, чтр все корректи-
ровки реализуются только в (п + 1)-й -версии, т. е. частные
изменения Не сообщаются пользователям. Изменения про-
грамм могут потребовать либо полной замены модуля или
группы программ, либо небольшого изменения текста про-
граммного модуля, описания данных или констант. При пол-
ной замене компонент КП они подлежат тестированию, как
все'вновь созданные компоненты (см. гл. 3. и 4).
Если’изменения в программе или в данных невелики, то
тестирование стремятся ограничить компонентами, непосред-
ственно связанными с выполненной корректировкой (см.
рис. 5.6). Однако следует учитывать, что корректировки про-
грамм в 10—30 % 115] случаев сами содержат ошибки и тре-
буют тщательного тестирования почти всей программы, а не
только тех частей, где внесены изменения. Наличие в програм-
мах глубоких межмодульных-связей по управлению и по ин-
формации вызывают необходимость тестирования и тех ком-
понент, где по первому впечатлению корректировки не ока-
зывают влияния. Такие связи зачастую приводят к появле-
нию ошибок вследствие проведенных изменений и нарушения
концептуальной или функциональной целостности группы
взаимодействующих программ и данных. Поэтому антирег-
рессионному тестированию необходимо подвергать также не-
которые^частн программ, которые не подвергались изменени-
ям. Для этого используются тесты, ранее применявшиеся при
испытаниях предыдущей л-й версии или опытного образца.
269
Все корректировки предварительно выполняются и про-
веряются на версиях программ разработчиков (рис. 5.7), ко-
торые формируются на основе фрагментов подлинника л-й
версии КП. Эти откорректированные версии компонент под-
вергаются автономному тестированию, после чего объединя-
ются в группы программ и тестируются в некольких скомп-
лекснрованных группах.. Проверенные таким образом изме-
нения регистрируются в журнале проведенных корректировок
для (л + 1)-й версии КП.
Объединение групп откорректированных программ 'позво-
ляет создать эталон (п + 1)-й версии КП, подлежащий тес- *
тированию по программе испытаний. При большом количест-
ве выполненных изменений сложность испытаний может при-'
ближаться к испытаниям опытного образца. Объем тестиро-
вания при испытаниях (л + 4)-й версии согласуется' разра-
ботчиком с заказчиком или пользователями. Все проверенные
и подтвержденные при испытаниях изменения программ ре-
гистрируются и утверждаются окончательно руководителем
конфигурационного управления и главным конструктором.
После этого оформляется докумеАтация и магнитные носите-
ли подлинника (л + 1)-й версии, которая передается' на тира-
жирование и внедрение у'пользователей В некоторых слу-
чаях может быть полезным выпуск извещения для пользова-
телей, объявляющего создание (л Н- 1)-й версии КП и ее ос-
новные отличия от предыдущей версии.* ’
Для развития версий’и корректировки ошибок необходи-
мы ресурсы памяти и производительности ЭВМ, на которой
функционирует данный КП. Прн сопровождении пакетов при-
кладных программ в большинстве случаев предполагается,
что ресурсы не имеют жестких ограничений, вследствие чего
объем программ и длительность их счета растет от версии к-
версии 1з5, 37], В системах реального времени память и до-
пустимое время решения комплекса задач обычно ограниче-
ны. При создании опытного образца программ реального вре-
мени могут предусматриваться в электронной вычислительной
машине некоторые резервы ресурсов для последующего раз-
вития программ, однако эти резервы быстро иссякают при
первых же версиях. Поэтому процесс сопровождения значи-
тельно усложняется.
При создании Очередной (л + 1)-й версии КП в таких ус-
ловиях необходимо не только подготовить^ новые компоненты
и корректировки ошибок, но и выделить ресурсы ЭВМ для их
реализации. Эти ресурсы образуются за счет исключения ком- х
понент программ, что обеспечивает освобождение необходи-
мой емкости памяти команд и данных, а также сокраще-
270
<n 11)-я версия разработчиков КП
271
ние длительности счета при решении заданного комплексе;
задач. '
Ограниченность ’емкости памяти ЭВМ учитывать относи-
тельно просто, так как при формировании (л + 1)-й версии
новые компоненты н корректировки могут располагаться толь--
ко на местах, освобожденных в памяти л-й версии. Зйачи-
тельные трудности встречаются, при определении длительно-
сти счета (л + 1)-й версии КП в реальном времени [351. За-
частую оказывается, что исключенные из л-й версии коМпо--
ненты, хотя и освободили необходимую память, однако недо-
статочно 'сократили длительность счета; Поэтому чтобы обес-
печить функционирование (л + Q-й версии в реальном масш-
табе времени может потребоваться исключение из л-й версии
еще некоторых программ. Для расчета полного времени функ-
ционирования (л + 1)-й версии КП применяются те же ме-
тоды и средства, что и при анализе длительности функциони-
рования опытного образца [341.
Тестирование при тиражировании .и для обеспечения со-
хранности версий комплекса программ. Для установления со-
стояния программ на магнитных носителях (МН) (рис. 5.8)
используются три вида тестирования: контрольное суммиро-
вание, решение подготовленных контрольных задач и срав-
нение содержания МН на полное совпадение. Во всех случаях
эталоны точно известны н тестирование производится на абсо-
лютное совпадение с эталонами. Так как при хранении и ис-
пользовании магнитных носителей возможно искажение за-
писанной информации, то разработаны схемы, позволяющие
уменьшать вероятность такого искажения и восстанавливать
информацию.	• '
В процессе разработки (л + 1 )-й версии КП используются
версии t-х подсистем, переписываемых из предыдущей л-й
версий (см. рис. 5.7). После внесения изменений из г-х под-
систем образуются /-е версии комплексирования групп про-
грамм, которые после автономного тестирования объединяются
в (л + 1)-ю версию КП для испытаний и документального
оформления. Все версии разработчиков сопровождайтся
дубликатами, которйе эпизодически тестируются на соответ-
ствие основной версии 'разработчика на данном этапе разра-
ботки. При выявлении отклонения дубликата от основной вер-
сии разработчика тестирование продолжается до установления
причины и места различия. После этого осуществляется кор-
ректировка дубликата илй’основной версии до абсолютного
совпадения. Корректировку компонент и сборку очередной
версии производят специалисты, ответственные за сопровож-
дение с привлечением разработчиков предыдущих версий под-
272
Рис. 5.8. Схема применения'тестирования при
тиражировании и обеспечении сохранностиверсий КП
273
систем. Пользователи в этих работах не участвуют, но • могут
привлекаться для испытаний и уточнения целей корректиро^
вок.
Версия, прошедшая испытания, после оформления акта
испытаний и окончательной корректировки документации
превращается в подлинник (п + 1)-й версии. Этот подлинник
снабжается техническими условиями и тестами для проверки
его полной сохранности и функциональной работоспособности.
Для сохранения подлинника должны обеспечиваться особые
условия его хранения и периодическое (с интервалами полго- ,
да-год) тестирование для проверки отсутствия разрушений. *
С подлинника копируется дубликат, который используется
для подготовки Пользовательских копий и, так же как подлин-'
иик, подлежит особенно тщательному хранению и периоди-
ческому тестированию; Таким образом, подлинник и дубли-
кат, а также идентичные им копии гарантируют сохранность
(п + 1)-й эталонной версии КП.	*	:
.Для Повышения надежности сохраняются все изменения,
внесенные в п-ю версию.при подготовке (п + 1)-й версии.
~ Благодаря этому в аварийном случае разрушения подлинни-
ка, дубликата и всех копий (п + 1)-й версии КП обеспечива-
ется возможность их восстановления на базе предыдущей вер-
сии U зарегистрированных проведенных изменений 146, 57].
Основная особенность тестирования эталонных версий со-
стоит в наличии зафиксированной в технической документа-'
цри совокупности контрольных сумм и тестовых задач ,с из-
вестными точными результатами решений для каждой версии.
Эти тесты должны обеспечивать установление полной сохран-
ности версии и локализацию компонент; где имеются откло-
нения от технической документации.
Аналогичная схема применяется для поддержания сохран-
ности адаптированных рабочих версий пользователей (см.
рис. 5.7). При этом иа базе копии п 4- 1 эталонной версии КП
создается адаптированный к конкретным условиям примене-
ния подлинник версии zn-ro пользователя. Каждая версия
т-го пользователя должна снабжаться адаптированными тес-
тами для проверки сохранности и работоспособности программ.
Эти тесты так же, как эталонные, содержат контрольные сум-
мы компонент и адаптированную контрольную задачу для
проверки функционирования.
Особым видом адаптации программ к среде пользователя
может быть их настройка и перетрансляция иа систему команд
ЭВМ, применяемой пользователем' и отличающуюся от той
машины, на которой отрабатывалась и испытывалась эталон-
ная версия. Некоторые КП или их компоненты (модули, груп-
274
пы программ) целесообразно использовать на ЭВМ даже со
значительно различающимися системами команд. В связи с
этим возникла проблема мобильности (переносимости)
версий программ на разные типа ЭВМ [48, 103J. В этом случае
для конфигурационного управления появляется еще один па-
раметр — система команд ЭВМ пользователя и степень ее от-
личия от системы команд базовой ЭВМ, на которой создаются
эталонные версии.
Эффективно эта проблема решается при малых различиях
систем команд и применении языков высокого уровня. В се-
мействах ЭВМ их отдельные модели могут иметь небольшие
различия в системах команд. Эти различия приводят к- необ-
ходимости . пёретрансляции* всего КП и проверки полученной
эталонной версии перед адаптацией на.остальные характерис-
тики конкретной среды применения пользователя. Мобиль-
ность КП в пределах семейства ЭВМ может быть обязатель-
ным требованием при создании опытного образца и последую-
щих версий тиражируемых программ.
В общем случае, при произвольных системах команд и ар-
хитектурах ЭВМ эффективную мобильность Программ обес-
печить не удается [48].хПри формализованном переносе даже
отдельных модулей, написанных на языках высокого уровня,
из-за различия их диалектов и особенностей конкретных
трансляторов, переносимые программы, как правило, моди-
фицируются. Создаваемая при-этом версия пользователя тре-
бует, по существу, полного тестирования и испытаний и может
рассматриваться как новый КП, подлежащий отдельному кон-
фигурационному управлению,
Хранение, учет и тиражирование версий требуют больших
затрат. Поэтому при выпуске каждой новой версии стремятся
обеспечить преемственность ее функций с предыдущими, а так-
же рассматривается возможность прекращения сопровожде-'
ния некоторой ранней версии КП. В результате среди всего
множества версий каждого КП образуется зона сопровождае-
мых версий (см. рис. 5.7). Число таких сопровождаемых эта-
лонных версий или глубина сопровождения практически
всегда не менее двух версий и редко превышает 4 версии. Для
сложных КП это соответствует рациональному времени жизни
и тиражирования каждой версии около 3—5 лет. При этом
полное вреМя жизни и развитий КП может составлять 30 лет
и суммарное число эталонных версий достигать 20—30.
Приведенную схему жесткого конфигурационного управ-
ления версиями КП не всегда удаётся реализовать полностью.
Наличие срочных исправлений ошибок н запросов пользова-
телей на частичные изменений в эксплуатируемых версиях, а
275
также ряд других причин могут приводить к появлению между Я
• n-й и (п + 1)-й версиями КП ряда промежуточных пользова- Я
тельскрх версий. Для этого, наряду с выпуском очередных 
завершенных версий, приходится выпускать временные изве- Я
щения о выявленных ошибках и подготовленных корректиров- Я
ках, а также извещения об основных изменениях, которые Д
проведены в (п + 1)-й версии по сравнению с n-й. В резуль-
тате у пользователей могут создаваться промежуточные вер- I
син, каждая из которых кроме адаптации иа характеристики Я
среды эксплуатации содержит специфический набор изменений 'Я
из состава вводимых в очередную версию КП.	- Я
Появление промежуточных версий у пользователей может Я
сопровождаться ошибками,' обусловленными разрушением ;Л
концептуальной взаимосвязи некоторых изменений. Такие ja
ошибки являются следствием того, что корректировки программ л
для исправления ранее выявленных ошибок и для развития "Л
функциональных возможностей (п + 1)-й версии мбгут быть -и
взаимозависимыми как непосредственно, так и через некого- -Я
рые промежуточные программы и данные, - что трудно обна-
руживать. При подготовке (п + 1)-й версии эти связи между л
корректировками не раскрываются, однако они проверяются ж
в процессе комплексного тестирования. В то же время коррект- 1
ность каждого отдельного изменения может автономно не пол- „ я
ностью испытываться при подготовке версии. В результате Д
выделенные пользователем отдельные иЗмененийоказывают- j
ся между собой не полностью согласованными, что приводит J
к ошибкам функционирования версии n-гр пользователя. Я
Таким образом, на совет конфигурационного управления з
приходится возлагать функции* выявления связанных изме-
нений и учета эксплуатации у пользователей промежуточных <1
версий с частичными изменениями. Вследствие этого для слож- .1
- ных КП может появляться необходимость конфигурационно- ,
го учета и управления не только эталонными версиями, но и j
•рядом'промежуточных версий пользователей с частичными j
изменениями. Сложность сопровождения при этом резко воз- 'i
растает. Поэтому в большинстве случаев целесообразно при- ]
нимать организационные меры по ограничению распростра- 1
няемых изменений между n-й и (п + 1)-й версиями в пределах j
только простейших локальных корректировок ошибок, су- !
щеетвенно влияющих на качество КП.
Средства автоматизации тестирования при сопровождении .. ц
программ. Для автоматизации тестирования при сопровож- i
дении КП используются практически все средства автоматиза- >
ции автономной'и комплексной отладки и Значительная часть 1
средств; применяемых для испытаний КП. Кроме того, для >
276	।
г
обеспечения длительного сопровождения широко тиражируе-
мых КП с рядом версий необходимы специфические средства
автоматизации тестирования, которые могут отсутствовать или
применяться в ограниченном виде для программ, не предназ-
наченных для сопровождения: .
средства накоплений данных рб ошибках, предложениях на
изменения, выполненных корректировках и' характеристиках
версий; „	.
средства встроенного контроля процесса исполнения про-
грамм для установления' их состояния и выявления ошибок
при характеристиках внешней среды пользователя;
средства имитации внешней среды и наборов тестов для ти-
повых режимов функционирования данного КП;
средства накопления, упорядочения и каталогизации тес-
товых наборов для проверки компонент и версий КП;
средства тестирования и проверки тождественности и со-,
хранности копий КП. ,
. Перечисленные средства тестирования, а также средства,
применявшиеся при созданий опытного образца, входят в
комплексную систему автоматизации проектированйя версий
и сопровождения программ. Важной особенностью такой тех-
нологической системы является очень длительное (20—30 лет)
ее существование и стабильное эволюционное развитие. Сред-
ства такой системы должны обеспечивать возможность повтор-
ного тестирования компонент и всего КП через много лет экс-
плуатации, в том числе и на тех тестах, которые применялись
при создании опытного образца КП. •'	.
Поэтому в течение всего времени сопровождения необхо-
димо сохранять основные средства автоматизации тестирова-
ния и некоторые наборы тестов, использовавшихся при раз-
работке первых версий КП. Кроме того, нужно иметь историю
развития версий средств автоматизации тестирования и эво-
люции базовых наборов тестов. Таким образом, возникает
проблема, конфигурационного управления и сопровождения
тестовых наборов и КП, автоматизирующих технологический
процесс сопровождения и в том числе тестирование сопровож-
даемого КП.
Технологические системы автоматизации проектирования
и сопровождения КП создаются с использованием средств ав-
томатизации программирования и тестирования, входящих,
как правило, в операционные системы^универсальных ЭВМ,
которые также являются сложными программными комплек-
сами (объемом 10*—Ю* команд), подлежащими сопровожде-
нию. В результате образуется иерархическая совокупность
трех систем, каждая из которых подлежит сопровождению и
277
конфигурационному управлению в течение всего жизненного Я
- цикла КП, выполняющего основную целевую задачу коикрет- Я
ной разработки на нижнем уровне.	Я
По мере повышения иерархического уровня системы ста- " J
новятся труднее изменяемыми. На высшем уровне,их состав- а
ляют технологические средства разработки программ иа уни- '
версальных языках программирования, входящие в большие а
операционные системы универсальных ЭВМ. На среднем'уров- 
не размещаются системы автоматизации проектирования, при- • л
меняемые для создания конкретных КП управления и обра- и
ботки информаций нижнего уровня. При этом следует учи- 41
тывать, что развитие основного КП может вызывать необхо-
димость изменений, как технологических средств, непосред- 1
ственно использующихся для его создания, так и, в некоторых ... 1
. случаях, средств на самом высоком уровне, применяемых для , 1
создания самих технологических систем автоматизации сопро- ад
вождения.	- ‘а
Возникает задача сопровождения этих двух сложных тех- я
-дологических комплексов программ. Благодаря универсаль- -’1
ности и широте применения технологические системы изМе- i
няются меньше, чем КП,, создаваемые с их использованием. |
Кроме того, технологические системы развиваются, как пра- ,’i
вило, с полной преемственностью версий, т.. е. функции ком- J
понент не сокращаются и не исключаются. Эта особенность j
развития технологических систем сопровождения должна со- л
блюдаться очень строго для обеспечения полной преемствен- J
ности процесса сопровождения версий КП управления и об- i
работки информации.
Средства накопления сообщений об ошибках, предложениях ]
на изменения, выполненных корректировках и характеристи- j
ках версий являются, основными средствами автоматизации
конфигурационного управления и управления базой данных ’
сопровождения, которая может состоять ’ из следующих ча-
стей:
данные об ошибках, условиях их проявления и характе-
ристиках обнаруживающих тестов, а также предложения иа
- изменения программ, подлежащие анализу, и селекций для вы-
деления тех из них, для которых будут разрабатываться кор-
ректировки программ (журнал предварительных изменений);
изменения программ, отобранные группой конфигураци-
онного управления для проведения корректировок в очеред-
ной версии КП (журнал утвержденных корректировок); .
характеристики эталонных версий и набор изменений, вы-
полненных в каждой их них (журнал эталонных-версий);
278
характеристики пользователей, которым переданы для
внедрения соответствующие версии КП и особенности среды
эксплуатации у них (журнал пользовательских версий).
Перечисленные компоненты базы данных сопровождения
взаимосвязаны, сведения об изменениях по мере обработки
переходят последовательно из одной части в другую. Первич-.
ные сообщения-от пользователей об ошиб^х регистрируются
на содержательном уровне вместе с тестовыми данными, при *
которых зарегистрирована аномалия. Также на содержатель-
ном уровне или в виде спецификации требований, регистрируй
ются в базе данных предложения на улучшения программ. Все
данные запоминаются вместе с датами получения и их первич-
ными авторами. По результатам анализами тестирования дан-
ные получают от группы1 конфигурационного управления при-
знаки отвергнутых или подлежащих дальнейшей проработке
изменений. Отвергнутые изменения через некоторое время-
могут исключаться из журнала предварительных изменений.
Изменения, отобранные группой конфигурационного уп-
равления, переводятся из журнала предварительных изме-
нений во вторую часть базы данных. Здесь изменения конкре-
тизируются вплоть до текстов корректировок программ или
созданных новых компонент с датами и именами авторов их
разработки, тестирования и испытаний. Кроме того, для каж-.
дой подготовленной корректировки регистрируются резуль-
таты ее рассмотрения, группой конфигурационного управ-
ления и дата утверждения на введение в новую версию КП или
для частных сообщений пользователям. Отвергнутые коррек-
тировки вместе с разработанными программами возвращают-
ся в журнал предварительных изменений.
Все корректировки, утвержденные для введения в очеред-
ную версию, регистрируются в третьей части базы данных со-
провождения. Для каждого изменения дается содержатель-
ная аннотация, а также приводятся общие характеристики
и достигнутые на испытаниях показатели качества данной эта-
лонной версии КП. Результаты испытаний версии запомина-
ются вместе с условиями и параметрами, при которых оии про-
водились, а также с набором тестов или местом, их'хранения.
Кроме того, регистрируются магнитные носители, на. которых
размещены программы и данные подлинника и дубликатов со-
ответствующей эталонной версии. Утвержденные изменения
для конкретной версии КП, крдме журнала эталонных вер-
сий, целесообразно сохранять в журнале утвержденных кор-
ректировок.
Учет тиражирования и распространения версий КП ведет-
ся с использованием в базе данных журнала пользовательских
279
версий. В этом журнале нак-аяляваются сведення о среде при- ]
менения й. адаптации КП у каждого пользователя и активно- ]
сти его работы с программами. Регистрируются замены версий
и наличие в эксплуатации старых версий, в том числе снятых j
с сопровождения. Особое значение имеет четкий учет переда- i
чи пользователям срочных частных корректировок эксплуа-
тируемых версий.	•	*
База данных сопровождения доступна ограниченному чис- .
лу лиц, непосредственно участвующих в конфигурационном j
управлении. Эта база данных должна быть тщательно защи- 3
щена от несанкционированного доступа и от случайного раз- 1
. рушения. Накопленные данные об изменениях и история кор- J
ректировок подлежат хранению в течение всего жизненного
цикла программ или значительной его части. Разрушение све-
дений о выполненных или предполагаемых изменениях может
приводить к большим затратам труда на их восстановление.. J
Поэтому база данных должна дублироваться и поддержи- 2
ваться методами н средствами сопровождения, аналогичными
применяемым для основного КП.	• i
Средства встроенного контроля процесса исполнения про-
грамм. Сложные программные комплексы постоянно развива-. ;
ются и поэтому неотъемлемой их компонентой становятся
средства встроенного контроля процесса исполнения программ.
Этй средства могут или- непрерывно контролировать проме- ,
жуточные и 'результирующие данные, или включаться только
по запросу при обнаружении сомнительных результатов, так
как непрерывный .контроль требует значительных ресурсов
памяти и производительности ЭВМ.
Средства контроля должны позволять получать информа-
цию о состоянии переменных в процессе решения конкретных
задач и о маршрутах, в которых нарушаются некоторые задан-
ные условия. По мнению некоторых специалистов [151, объем
таких средств контроля может составлять около трети КП.
Для их эксплуатации создаются методики и инструкций, ко- *.
торыё позволяют пользователям достаточно квалифицирован-
но осуществлять диагностику состояния КП и результатов их
функционирования. Унификация средств у пользователей и
коллективов сопровождения облегчает селекцию и локализа-
цию ошибок, а также идентификацию исходных данных, при
кбторых они обнаружены.
Средства имитаций внешней среды и'наборов тестов, пред-
назначены для генерации исходных Данных при проверке ти-
повых режимов фуйкционирования данного КП. Эти средства
могут быть двух уровней. Средства нижнего уровня позволя-
ют формировать типовые тестовые задачи в соответствии с ин-
280
струкцяей по эксплуатации КП. Эти средства могут переда-’
ваться пользователям для контроля рабочих версий КП «'вхо-
дить в комплект поставки каждой пользовательской версии.
Для более' глубокой проверки функционирования версий
и локализации, ошибок целесообразно создавать комплекс
средств имитации'внешней среды высшего уровня, которые ис-
пользуются специалистами по конфигурационному управле-
нию и сопровождению; Эти средства имитации включают так-
же средства нижнего уровня (пользовательские) для обеспе-
чения полного повторения ситуаций, при которых пользова-
телями обнаружены аномалии функционирования. Средства
имитации высшего уров*Ня не передаются пользователям и
входят в состав стенда, предназначенного Для сопровождения
и испытаний определенного КП (см. §4.1).
Средства Накопления, упорядочения и каталогизации тесто-
вых наборов данных, обеспечивают возможность многократно-
го использования тестов в течение жизненного Цикла Kft.
После применения терта часто' создается впечатление, что он
больше не Потребуется н Yie следует его сохранять. Однако зна-
чительное число тестов приходится использовать повторно,
что определяет целесообразность их хранения.
Для эффективного использования таких, в основном де-
терминированных тестов необходима система управления ба-
зой данных для их накопления и хранения с тщательно про-
думанной идентификацией и каталогизацией тестов. Тесты
целесообразно упорядочивать по уровням отладки, при кото-
рых они применяются (автономная, комплексная, испытания,
обнаружение, локализация или диагностика ошибок и т. д.),
по именам программных компонент^ которые контролируют-
ся при их использовании, по номерам версий, для которых они
созданы и использовались. Система каталогизации Должна
обеспечивать достаточно простой и надежный поиск тестов
среди имеющихся, а также достоверное обнаружение тестов,
которые понадобились, но отсутствуют среди сохраняемых.
База данных тестовых наборов оправдана при конфигура-
ционном управлении сложными КП с множеством версий.
Быстрый рост числа и суммарной сложности тестовых наборов
в этих случаях приводит к необходимости их селекции по сте-
пени важности и удобства повторной генерации. Группа кон-
фигурационного управления и специалисты по тестированию
программ должны выделять иа хранение тесты с учетом их
эффективности, затрат на подготовку и прогноза на повтор-
ное использование. Поэтому должна быть .предусмотрена не
только возможность пополнять базу тестовых данных, но и
'	281
исключать устаревшие или недостоверные тесты при создании
новых версий.
Средства тестирования и проверки тождественности и со-,
хранности копий программ используются при сопровождении
для обеспечения полной идентичности подлинников, дублика-
тов и копий каждого КП. Для этого вида тестирования наибо-
лее широко применяются контрольные суммы кодов текстов
программ на языках описания различных видов. Суммирова-
ние осуществляется иерархически обычно сверху вниз. Точ-
ным эталоном служат предварительно подготовленные конт-
рольные суммы версий в целом и ее компонент различного
размера вплоть до модулей. В начале производится суммиро-
вание команд всего КП или его крупных компонент, например
загрузочных модулей. При выявлении отличия суммы от эта-
лонного значения последовательно суммируются команды
групп программ или модулей. В результате'локализуется ком-
понента копии, имеющая искаженную контрольную сумму и
подлежащая восстановлению.
Для проверки сохранности копий КП целесообразно соз-
давать типовую контрольную задачу, для которой заранее
рассчитываются точные значения результатов. Некоторые
виды частных отказов ЭВМ не обнаруживаются типовыми тес-
тами ЭВМ и могут влиять на функционирование программ.
Контрольная задача повышает достоверность оценки работо-
способности ЭВМ и позволяет установить не только сохран-
ность программ, но и полную готовность системы к решению
конкретной задачи.
Документирование тестирования при сопровождении про-
грамм. Для конфигурационного управления сопровождением
необходима четкая структура документации, позволяющей
установить текущее состояние программ в любой момент вре-
мени и процесс их изменения. Структура документации и фор-
мы отдельных документов, используемых, для сопровождения .
программ, должны, позволять:
точно документально описывать опытный образец и каж-
дую оформленную версию программ в любое -время на всем
протяжении жизненного цикла КП;
надежно учитывать все анализируемые, подготавливаемые
и проведенные изменения в КП;
снабжать руководителей необходимой информацией для
принятия решений на изменения программ, а также для конт-
роля выполнения принятых решений;
Обеспечивать заказчиков и пользователей сведениями о
наиболее существенных частичных корректировках программ
и об особенностях новых версий КП.
. 282
Исходной является документация иа опытный образец КП, оформ>-
ленная в соответствии с действующими стандартами. Для обеспечения
сопровождения в документации-должны быть предусмотрены компо-
ненты, регистрирующие состояние нескольких версий; динамику их
изменений и утверждений. В документах целесообразно использовать
иерархическую систему идентификации компонент КП и описаний дан-
ных. Каждый модуль или массив переменных в своем имени и опи-
сании должны содержать обозначения компонент более высокого уров-
ня (например, группы программ и комплекса), а также отмечать оче-
редность.модификаций и номер конкретной версии. Целесообразно
централизованно группой конфигурационного управления присваи-
вать обозначения наиболее крупным составляющим вплоть до утверж-
денных'версий модулей и массивов переменных. .Произвольная индек-
сация компонент допускается только в процессе подготовки корректи-
ровок программ и данных до комплексировання их в версию, предъяв-
ляемую на 'испытания.
Особое значение прй сопровождений имеет документация на изме-
нения и тесты, с помощью которых проверялась корректность верснн
в целом. Эта документация- должна позволять восстанавливать после-
довательность разработки и’ проверки каждого достаточно крупного
изменения. На базе всего комплекса использованных тестов создается
и документируется-для каждой версии КП эталонная тестовая (конт-
рольная) задача и контрольные результаты ее решения. Эти докумен-
ты оформляются в соответствии со стандартами, тиражируются и пере-
даются пользователям вместе с программами верснн и остальными до-
кументами. Документы на частные тесты используются только раз‘ -
работниками.
Относительная легкость изменения отдельных программ и комп-
лектации версий КП способствует появлению у пользователей (особен-
но малоквалифицированных) стремления к самостоятельному «улуч-
шению» программ за пределами, разрешенными инструкциями для
пользовательских версий. Такне изменения должны быть организаци-
онно заблокированы правилами внедрения КП и передачей пользова-
телям только эксплуатационной документации, минимально необхо-
димой для правильной адаптации пользовательской версии и работы
с ней. Целесообразно ограничивать доступ пользователей к технологи-
ческой документации, хранящей подробные сведения о содержании и
логике функционирования программ, а- также детальные тесты для их
проверки. Такие меры в некоторой1 степени предотвращают -возмож-
ность резкого ухудшения показателей качества КП из-за неквалифи-
цированного вмешательства пользователей.
Для корректного изменения программ ;пециадистамн, ответст- •
венными за'сопровождеиие, необходима технологическая документация,
бблее полная чем эксплуатационная. В технологической документации
раскрывается содержание программ и данных. Позволяющее новому
квалифицированному специалисту понять1 функционирование программ
и корректно их модифицировать. Для каждой очередной эталонной
версии КП регистрируются и документально офбрмлиются ,все изме-
нения, которые вводятся в комплект документации, полностью адекват-
ной данной эталонной верснн. В технологическую документаций) вклю-
чаются все вновь разработанные тесты и тесты, использованные для
Проверок ранее выпущенных версий.
Разработка и тестирование -изменений всегда опережает их
документальное оформление. Технологический цикл разра-
ботки полного комплекта документации для пользователей
283
на версию КП может занимать несколько месяцев. Б течение
этого времени возможны Отдельные уточнения изменений в
версии. В результате документация должна непрерывно «до-
гонять» реальное состояние изделия. Для упорядочения это-
го процесса ГОСТами установлена возможность оперативно-
го выпуска'«предварительных» извещений на изменения. Эти
извещения регистрируются как временные и погашаются при
полном оформлении документации на версию КП и все утверж-
денные изменения. Кроме того, у разработчиков ведется ар-
хив собственных документов, которые регулярно контролиру-
ются группой конфигурационного управления.
ЗАКЛЮЧЕНИЕ
Быстрое увеличение объема и расширение функцио-
нальных возможностей разрабатываемых комплексов про-
- грамм усложняет их тестирование. Необходимость повы-
шения качества программ также повышает требования
к полноте и.глубине тестирования. Эти обстоятельства сти-
мулируют развитие теории, методов и средств автоматиза-
ции тестирования и требуют значительного увеличения
ресурсов для их практической реализации и приме- .
нения.	,	-
Разработка конкретных комплексов программ (КП) все-
гда происходит в условиях ограниченных ресурсов, что
в значительной степени определяет качество программ.
Рациональное упорядоченное распределение и использова-
ние ресурсов различных видов позволяет достичь заданно-
. го качества программ,, значительно сократив совокупные
затраты на разработку КП (см. §'2.3). Ресурсы, требуемые
для автоматизированного тестирования и отладки КП,
прежде всего зависят от характеристик объекта разработ-
• ки: объема и сложности, программ, их надежности и кор-
ректности, длительности цикла жизни и предполагаемого
тиража, степени связи с реальным масштабом -времени и
использования производительности реализующей ЭВМ
и т. д.
Важнейшим ресурсом любой разработки являются.кад-
ры специалистов. От их квалификации и организации зави-
сит успех любых и-особенна крупных разработок КП.ВЬз-
можности коллектива специалистов при создании конкрет-
 кого КП. принято оценивать достигаемой производительно-
стью труда, измеряемой средним числом команд или строк
текста готовой программы в КП, отнесенным к единице вре-
284
Мени труда каждого участника разработки. Эта произведи-,
тельность непосредственно зависит от уровня автоматиза-
ции труда и соответственно от ресурсов, выделяемых на
автоматизацию. Перераспределение совокупных ресурсов
разработки позволяет снизить затраты на непосредствен-
ное создание КП, однако повышает ресурсы, необходимые
на разработку и эксплуатацию соответствующих методов
и средств, автоматизации. Эффект от автоматизации заме-
тен с некоторым запаздыванием и не всегда нагляден. По-
этому для повышения уровня автоматизации требуется не
только научно-техническая, но и организационная работа,
чтобы преодолеть консерватизм многих руководителей и
программистов с большим стажем, привыкших к слабо ав-
томатизированной и не очень систематизированной разра-
ботке программ.
Оснащенность процесса разработки конкретного КП
программными и - аппаратурными средствами автоматиза-
ции и выделяемые ресурсы наиспользование этих средств
ассоциируются с понятием «энерговооруженности» произ-
водства, широко применяемым в промышленности. Эта ана-
логия позволяет наглядно анализировать влияние ограни-
ченности ресурсов на тестирование программ. В данном
случае термин «эиерговооружёниость» взят в кавычки, так
как энергетика здесь играет второстепенную роль только
при учете затрат на эксплуатацию ЭВМ. Более адекватным
является понятие степени оснащенности специалистов ме- -
•годами и средствами автоматизации и их оперативная до-
ступность в процессе разработки программ. Практическое
применение методов и средств автоматизации систематиче-
ского тестирования и отладки сложных программных комп-
лексов определяется двумя видами ресурсов:
программными ресурсами, используемыми для реализа- .
ции различных методов н средств тестирования (программ-
ная «энерговооруженность»);
ресурсами аппаратных средств вычислительной техни-
ки, доступными для размещения и эксплуатаций программ-
ных средств' автоматизации -Тестирования (аппаратурная
«энерговооруженность»).
Программная «энерговооруженность» те-
стирования определяется функциональными возможностя-
ми и полнотой , использования всех современных методов
в применяемой системе автоматизации разработки конкрет-
ного КП. .Однако такую характеристику трудно предста-
вить численно для оценки и сопоставления различных си- .
стем автоматизации. Наглядным и достаточно адекватным
285
показателем уровня автоматизации тестирования является
объем используемых программных средств (см. § 2.3). Этот
показатель в некоторой степени соответствует сложности
средств автоматизации и пропорционален затратам, необ-
ходимым на нх создание.
Реальная «энерговооруженность» конкретных коллекти-
вов разработчиков характеризуется средствами автомати-
зации тестирования и отладки, которые действительно ис-
пользуются в процессе разработки. Эти средства включают
программы обеспечения статического и динамического те-
стирования КП на различных этапах разработки, средства
программного моделирования объектов внешней среды и
обработки результатов тестирования, а также все сервис-
ные программы, обеспечивающие.эффективное применение
средств тестирования. Каждое средство характеризуется
определенной эффективностью при применении в процессе
разработки и требует различных затрат при эксплуатации,
что значительно усложняет оценку реальной программной
«энерговооруженности» тестирования. Однако для обоб-
щенной приближенной оценки этого показателя можно
пользоваться объемом программ, активно применяемых для
автоматизации тестирования и отладки.
Как отмечалось в гл. 2, рациональный суммарный объем
программ автоматизации, обеспечивающих тестирование,
в значительной степени коррелирован с объемом программ
разрабатываемого КП. Небольшие автономные программы
могут разрабатываться почти без средств автоматизации.
Однако,для успешного и эффективного тестирования КП
объемом около 104 команд рационально применять сред-
ства автоматизации тестирования приблизительно такого
же объема: Для эффективного тестирования более круп-
ных КП сложность необходимых средств автоматизации
обычно опережает рост сложности самих отлаживаемых
КП. Для отладки КП объемом около 10® команд средства
имитации внешней среды и автоматизации тестирования
на всех этапах разработки по объему могут быть в не-
сколько раз больше самого КП [72, 112].
В ряде, развитых технологических систем средства авто-
матизации тестирования и Отладки сложных КП реализу-
ются программами объемом 100—200 тыс. команд (38, 39,
76, 94], однако при этом применяют только некоторые, не
всегда наиболее эффективные методы и средства. Оценки
программной энерговооруженности некоторых реальных
разработок показывают, что объем программных средств
автоматизации зачастую значительно отстает от объёма
разрабатываемых КП. Следствием этого является повыше-
ние совокупных затрат на разработку программ.
А п п а р а т у.р н а я «э н е р г о в о о р у ж е н и о с т ь» раз-
работчиков сложных КП определяется характеристиками,
ЭВМ и их периферийного оборудования, доступных и ис-
пользуемых каждым разработчиком в процессе тестирова-
ния и отладки КП. Для эффективного применения методов
и средств автоматизации тестирования и отладки программ
наибольшее значение имеют:
быстродействие ЭВМ, используемых при тестировании
программ на всех этапах разработки, приходящееся в сред-
нем на одного специалиста из коллектива, осуществляю-
щего разработку КП;
. число дисплеев, используемых при тестировании про-
грамм в среднем одним разработчиком;
среднее число возможных подходов к ЭВМ каждым раз-
работчиком программ за рабочий день для реализации за-
даний иа тестирование.
Если ЭВМ, применяемые при тестировании определен-
ного КП, имеют низкое совокупное быстродействие, то это
ограничивает использование высокоавтоматизированных
программных средств тестирования. Это ограничение отра-
жается на возможности и полноте тестирования как от-
дельных программных компонент, так и КП в целом тем
сильнее, чем выше сложность разрабатываемых программ.
Вследствие’этого при выборе быстродействия технологиче-
ской ЭВМ для тестирования, программ необходимо учиты-
вать сложность разрабатываемого КП. Однако сложность
создаваемого КП и число участников разработки достаточ-
но тесно связаны. На практике оказалось удобным харак-
теризовать аппаратурную «энерговооруженность» относи-
\ тельным быстродействием ЭВМ — значением быстродейст-
вия ЭВМ, приходящимся на одного разработчика программ.
Эта величина характеризует реальную возможность систе-
матического оперативного применения средств автоматиза-
ции тестирования и имитации внешней среды на ЭВМ каж-
дым специалистом в-процессе разработки КП. Как показы-
вает практика, для активного применения средств
автоматизации тестирования сложных КП объемом около
105 команд требуется относительное быстродействие ЭВМ
порядка 165 операций в секунду на'каждого специалиста’.
Прн быстродействии доступных ЭВМ 10s операций в секун-
ду на одного разработчика возможно только очень, ограни-
ченное применение простейших методов и средств автома-
тизации, При этом следует подчеркнуть, что приведенные^
287
данные относятся к коллективным разработкам достаточно
сложных КП.
Эффективность применения ЭВМ для автоматизации
разработки кроме ее номинального быстродействия зави-
сит от степени йспольздвания процессорного времени. При
тестировании она определяет уровень обработки и объем
информации, доступной разработчикам для анализа состоя-
ния и функционирования компонент отлаживаемого КП.
При этом возможно сокращение календарного времени
применения ЭВМ (и всего процесса разработки) при по-
вышении автоматизации тестирования. Степень использо-
вания процессорного времени ЭВМ быстро возрастает при
повышении программной «энерговооруженности».. При до-
статочно высоком, быстродействии ЭВМ это допускает сокра-
. Щение потребления их календарного времени из-за значи-
тельного возрастания эффективности его использования. .
Относительное быстродействие и степень использования 7
процессорного времени ЭВМ определяют среднее число 1юд-
ходов к ЭВМ и средствам айтоматизации тестирования, Д
которое обеспечено каждому специалисту за рабочий день.
Для эффективного использования рабочего времени бы-
стродействие вычислительных машин и число терминалов
должны обеспечивать каждому специалисту по крайней
мере три-четыре подхода к ЭВМ за рабочий день (57]. Ца
практике эффективное использование развитых средств,
айтоматизации тестирования возможно при применении
ЭВМ с быстродействием порядка 1 млн. операций в. секун-
ду. При этом одновременно с такими ЭВМ в режиме раз-
' деления времени могут продуктивно работать 6—8 специа-
листов. В результате один дисплей должен приходиться
не более чем на трех-четырех разработчиков программ. *•
В принципе' возможно монопольное использование дисплея
каждым разработчиком в течение всего рабочего времени.
Однако пока это не всегда рационально с позиции эффек-
' тивного использования дорогостоящей аппаратуры.
Рациональная аппаратурная н программная «энергово-
оруженность» тестирования тесно связаны. Ограниченность
их характеристик совместно определяет практические воз-
можности автоматизации тестирования, достигаемое, прй
этом качество программ и производитель-
ность труда разработчиков. Встречаются ситуации,
когда программные средства; обеспечивающие высокий
уровень автоматизации тестирования программ,. базируют-
ся' на ЭВМ с недостаточным быстродействием и слабым
периферийным оборудованием. В результате высокоэффек-
.288	'	’
R'''
ртТ
тивные методы и средства не используются специалистами
систематически и практически не способствуют повышению
производительности труда и качества, создаваемых про-
грамм. Такие ситуации, в частности, дискредитируют Весь-
ма эффективные методы и средства. Согласованность аппа-
ратурной и программной «энерговооружённости» тестиро-
вания программ является важнейшим фактором эффектив-
ного применения существующих и создаваемых методов и
средств автоматизации. Систематическое тестирование га-
рантирует высокое качество программ при соответствую-
щем уровне его комплексного обеспечения.
СЛИСОК. ЛИТЕРАТУРЫ
1.	Айзенберг Я- Е., Вельбицкий И. В., Конорев Б. М., Стегни й А. А*
Автоматнзиррванная система производства программ СИНТЕРМ. — <
Управляющие системы и машины, 1980, Ns'l, с. 16—21.,
2.	АнДерсон Р. Доказательство правильности программ:. Пер. с
 англ, — М.: Мир, 1982. — 168 с.
3.	Архангельский Б. В., Никитин А. И., Черняховский В. В. Устой-
чивые типы семантических ошибок программ. — В ки.: Синтез,
' тестирование, верификация и отладка программ/Латв. гос. уи-т. —
Рига, 1981,. с. 17.
4.	Бабаева И. Б., Рехии Н. К. Формализация процесса масштабиро-
вания при решении задач на малоразрядиых  ЦВМ.— Програм-
мирование, 1975, Ns 6; с. 12—Г9.
5.	Безбородов Ю. М. Индивидуальная .отладка программ. — М.: Hay- z
ка, 1982. — 192 с.
6.	Бичевский Я. Я., Борзов Ю. В. Развитие методов символического
тестирования программ ЭВМ. — Автоматика и телемеханика, 1982,
Ns 8, с. 93—101. *
7.	Бичевский Я- Я. Автоматическое построение систем примеров. —
Программирование, 1977, № 3, с. ’60—70-
8.	<БлауС. А., Липаев В. В., Лозин Б. А. Эффективность тестирования
структуры программных модулей. — Автоматика н телемеханика,
1984, №4, с. 139—148.
9.	Бобрышев Д. Н., Рекснн В. Э. Управление конфигурацией техни-
ческих систем. — М.: Сов. радио, 1978- — 184 с.^
10.	Борзов Ю. В. Тестирование программ с использованием сим-
волического выполнения. —. Программирование, 1980, Ns 1, с.
51-60.
11.	Боэм Б., Браун Дж., Каспар X. и др. Характеристики качества
’программного обеспечения: Пер. с англ. — М.: Мир, 1981.—208 с.’
12.	Введение в технику работы с таблицами решений:-Пер. с нем./
Г. Фрайтол, В. Годе, X. Якоби и др.; Под ред. Д. А. Поспелова. —
М.: Энергия, 1979.’— 88 с.	'
13.	Гантер Р. Методы управления проектированием программного -
’обеспечения: Пер. с англ./Под ред.. Е. К. Масловбкого. — М.: Мйр,
1981. — 392 с.
14.	Гласс Р, Руководство по надежному программированию: Пер. с
англ. — М.: Финансы и статистика, 1982. — 280 с.
15.	Гласс Р., Нуазо Р. Сопровождение программного обеспечения
Пер. с англ./Под. ред. Ю. А. Чернышова.—.М.: Мир, 1983, 160 с.
289
1
16*. Глушков В. М., Цейтлин Г. Е., Ющенко Е. Л. Методы символьной
мультиобработки: — Киев: Наукова думка, 1980.	248 с.
17. Головкин Б. А. Надежное программное обеспечение:- Обзор. —
Зарубежная радиоэлектроника, 1978, № 12. с. 3—61.
18. Головкин Б. А. Расчет характеристик и планирование параллель-
ных вычислительных процессов. — М.: Радио и связь, 1983. —
272 с.
19-	Горинович Л. Н., Трахтеигерц Э. А., Шурайц Ю. М. Особенности
отладки параллельных программ. —'В кн.: Синтез, тестирование,
верификация и отладка программ/Латв. гос. ун-т. — Рига', 1981,
с. 76—77.
20.	Гуденаф Д. Б., Макгоуэн К-Л. Обеспечение качества программных,
средств. Испытания и оценка. —ТИИЭР, 1980, т. 68, №9,
с.66—73.
21.	Грис Д. Наука программирования: Пер. с англ./Под ред. А. П. Ер-
шова. — М.: Мир, 1984, — 416 с.
22.	Дейт К. Введение в системы баз данных: Пер.'с англ. — М.: Наука, А
1980. — 464 fc.
23.	Елманова М. С, Кузнецов Н. И., Ларионов К. А. Модификация .f’ j
больших программ. — В кн.: Синтез, тестирование, верификация. №
и отладка программ. /Латв. гос. ун-т. — Рига, 1981, с. 95. J
24.	Ершов А. П. Введение в теоретическое программирование (беседы ,®'
о методе). — М., Наука, 1977, — 288 с.
,25. Ершов А. П. Два облика программирования. — Кибернетика,
1982, № 6. £. 122—123.
26.	Карповский Е. А. Надежность специального математического
обеспечения управления. — Киев: Вища школа, 1982. — 192 с,
27. Касьянов В. Н. Анализ структур программ. — Кибернетика,
1980, Ml, с. 48—567.
28.	Кертис Б. Измерения и эксперименты в проектировании програм-
мных средств. — ТИИЭР, 1980, т. 68, №9, с. 129—145.
29.	Колганова Т.' В., Орлов С. Г., Фнллнповнч В. В. Исследование
характеристик иерархической структуры системы программ АСУ.— 1
Управляющие системы и машины, 1976, № 4, с. 16—23. ’	ч
30.	Колганова Т. В. Планирование тестирования управляющих про- S
грамм. — В кн.: Автоматизация проектирования систем управле- d
ния.—М.: Наука, 1979, с. 74—76.	' '	.1
31.	Колякни Ю. Д. Отладка программного обеспечения й диалоговой '
многотерминальной системе. — Управляющие системы и машины,.
1983, № 2, с. 56—60.
32.	Креденцер Б. П. Прогнозирование надежности систем с временной
избыточностью. — Киев; Наукова думка, 1978. — 272 с.
33.	Леман М. М. Программы, жизненные циклы и законы эволюции
программного обеспечения. — ТИИЭР, 1980, т. 68, № 9, с. 26—45.
34.	Липаев В. В. Проектирование математического обеспечения АСУ.—-
М.: Сов. радио. 1977. — 400 с.
35.	Липаев В. В. Распределение ресурсов в-вычислительных системах.
М.: Статистика, 1979. — 248 с.
' 36. Липаев В. В. Надежность программного обеспечения АСУ. — М.:
, Энергонздат, 1981. — 240 с.
37.	Липаев В. В. Качество программного обеспечения. — М.: Финан-
сы и статистика, .1983. — 264 с.	.
38.	Липаев В. В., Штрих А. А. Основные концепции кросС-системы
автоматизации программирования и отладки сложных комплексов
программ На базе ЕС ЭВМ. — В кн.: Технология создания про-
290
граммных средств АСУ/Центропрограммсистем. — Калинин, 1980,
с. 248—252.
39.	Лшме(.В. В., Серебровскнй Л. А., Кагаиов Ф. А. и др. Методу
и средства автоматизированного проектирования математического
обеспечения систем управления в системе автоматизации програм-
мирования и отладки ЯУЗА^бД. — В кн.: Автоматизация проек-
тирования систем управлении. М.: Финансы.и статистика, 1981,
с. 18—28.
40-	Липаев В. В., Позии Б. А., Блау С. А. Анализ стратегий тестиро-
вания догиКн программ. — Кибернетика, 1982, №2, с. 45—50.
41.	Липаев В. В., Мессих И. Г., Просвирник В. Н. Статистические
Характеристики программных .модулей и межмодульных связей
'. в комплексах программ управления. — Управляющие системы и
машины, 1983, № 5, с. 55—60.
42-	Липаев В. В., Позии Б. А., Строганова И. Н. Сложность тестиро-
вания структуры программных 'модулей. — Программирование,
1983, №6, с. 67—74.
43.	Липаев В. В., Позии Б. А. Сложность структурного тестирования
' программных модулей с циклами. — Программирование, 1984,
№6, с. 46—51.	/
44.	Майерс Г. Надежность программного обеспечения: Пер. с англ./
Под ред. В. Ш. Кауфмана. —М.г'Мир, 1980. — 360 с.
45-	Майерс Г. Искусство тестирования программ. Пер. с англ. — М.:
Финансы и статистика, 1982.' — 178 с.
46-	Мамиконов А, Г1, Цвиркуи А- Д., Кульба В. В. Автоматизация у
проектирования АСУ. — М.: Энергоиздат, 1981. — 328 с.
47-	Месарович М., Мако Д., Такахара И. Теория иерархических мно-
. гоуровневых систем: Пер. с англ./Цод ред. И. Ф. Шахнова. —
1 М.:Мнр, 1973. — 344 с.
48.	Мобильность программного обеспечения: Пер. с англ./Под ред.
Д, Б. Подшивалова. — М.: Мир, 1980. — 336 с.
49.	Мультипроцессорные системы и параллельные вычисления./Под
ред. Ф. Г. Энслоу: Пер. с англ. — М.: Мир, 1976. — 348 с.
50-	Отладка систем управляющих алгоритмов ЦВМ реального, вре-
меии/В. В. Липаев, Л. А. Фидловский, В. В. Филиппович,
Б. Н. Шнейдер; Под ред. В. В. Липаева. — М.: Сов. радио, 1974. —
- 328 с.
51.	Пархоменко П. П., Правильщиков П.' А. Диагностирование про-
граммного обеспечения. — Автоматика н телемеханика, 1980,
№ 1, с. 117—Ml-
52.	Позии Б.-А., Догадкии Е. Б., Капичиикова Е. Н. Технологии раз-
работки сложных Комплексов программ для ЕС ЭВМ с примене-
нием САРПО ПРОТВА. — В кн.: Прогрессивные технологии про-
граммнрования/МДНТП. — М., 1983, с. 45—50.
53.	Правильщиков П. А. Построение Тестов для программ. — Авто-
матика и телемеханика, 1977, № 5, с. 147—161.
54.	Рейнгольд Э., Нивергельт Ю., Део Н. Комбинаторные алгоритмы —
теория н практика.: Пер. с англ./Под ред. В. Б. Алексеева; — М.:
Мнр, 1980. — 478 с.
55.	Технологическая система ТКП: концепции и возможности.
В. П. Шарков, А. Н. Валышев, С. А. Котов, А. К- Мочалов. —
В кн.: Технология разработки программного обеспечеийЯ. Между-
народ. 'пауч-техн. конф. «Программное обеспечение ЭВМ»: — Ка-
линин, 1984, с. 32—36.
'56	. Тейер Т., Липов М., Нельсон Э. Надежность программного обеспе-
чения: Пер. с англ. — М.: Мнр, 1981. — 324 с."
291

57.	Технология проектирования комплексов программ АСУ/В. В. Ли-
паев. Л. А. Серёбровский, П.Г. Гаганов и др.; Под ред. Ю. В.-Аса-
фьева н В. В. Липаева. — М.: Радио и связь, 1983. — 264 с.
58.	ТыугуЭ; X., Харф М. Я. Алгоритмы структурного синтеза про-
грамм.— Программирование, 1980. №4, с. 3—13.
59.	Шаракшана А. С., Шахин В. П., Халецкий А. К. Испытания про-
грамм сложных автоматизированных систем. — М.: Высшая школа,
1982. — 192 с. >
60.	Юдин Д. Б., Горяшко А. П. Задачи управления и теория сложно-
сти. В 3-х ч. -г- Изв. АН СССР. Техническая кибернетика, 1974,
. № 3, с. 34—53; 1975; № 2, с. 3—19; 1976, №3, с. 3—15.
61.	Ющенко Е. Л., Касаткина И. В. Современные методы доказательст-
ва правильности программ. — Кибернетика, 1980, №6. с. 37—62.
62.	Adrion W. Rm Branstad М. A., Chernlavcky J. С Validation, verifi-
cation and testing of computet Software. — Computing Surveys,
1982, v. 14, Ns 2, p. 159—192.
63.	Bailey R. Human error in computer systems. — Prentice-Hall,
1983. — 176 p.
64.	Bargland G. D. A guided tour of program design metodologies.' — . X
Computer. 1981, №10, p. 13—37.	'>>.
65.	Bowen J. B. Are current approaches sufficient for measuring softwa- #
re quality? — Software Engineering Notes, 1978, v. 3, № 5, p. 148—	
’ '	155.
66.	Buckle J. K- 'Software configuration management. — McMillan - ’
Press, 1982. — 168 p.
'	67. Clarke L. A. et al. A close look at domain testing. — IEEE Trans.,
1982. s. SE-8, №4, p. 380—390.
68.	Software quality management/Ed. by J. D. Cooper, M. J. Fisher. —
A Petrocelli Book, 1979. — 278 ,p.
69.	’ Crossman T. D. Taking the measure of programmer productivity.—
Datamation; 1979, v. 25r-№ 5, p. 136—1Й.	-
70.	DljkstraE. W. Solution of a problem in concurrent programming.—
CACM, 1965, № 9, p. 317—323.
71.	Davis C. G., Vick C. R. The software.development system: status and
evalution. —Proc. IEEE'Computer Soc. 2-nd Int. Comput. Soft-
„ ware and Appt-Conf. — Chicago, 1978, № 4; p. 326—331.
72.	Deutsch M. S. Software verification and validation. Realistic project
approaches. — Englewood Cliffs, N. J.: Prentice-Hali, 1982. — <i
330 p.'	- ,
73.	Diinn R., Ullman R. Quality assurance for computer software. —
McGraw-Hill, 1982. — 352 p.	<
74.	Goel A. L.,*-Okumoto K. Time-dependent error-detection rate mo-
del for software reliability and other performance measures. — IEEE
Trans., 1979, v. R-28, №3, p. 206—209. -
75.	Geller D. P. Coding in two languages bosts program reliability. —
Electronic Design, 1983, v. 31, №7, p. 161—170.
.	76. Hausen H.-E-, Mullerburg M. Conspectus of software engineering
environments. — 5-th Int. Conf. Software Engineering, 1981, p. 34—
43.	'	-
•	77. Hennell M. A., An experimental testbed for numerical software. —
Computer J., 1979, v. 21, №4, p. 333—336-
78.	Howden W. E. Theoretical and empirical studies of program tes-
ting. — IEEE, Trans., 1978, v. SE-4, №4, ₽. 293—298-
- 79. Howden W. E. Functional, program testing. — IEEE Trans., 1980,
v. SE-6, №2. p. 162—169.
292
вО. Ibrtmdia М., Raleratnan V. Detection of logical errors in detection
, table programs-— CACM.1978, v. 21, N 12, p. 1016-1024.-
Si.	Infotech state of the art. report. Software testing. In 2 pt.— Maiden-
head, Pergamon Press, 197$.
82.	. Jensen R. W., Tonies C. C. Software- engineering. — Englewood
Cliffs, N. J: Prentice-Hall, 1979.—580p.	.	 '
83.	Jessop W. H., Kane J. R., Roy S., Scanlon J. M. ATLAS — an auto-
mated software testing system. —Proc. 2-nd Int. Conf. Sof-
tware Engineering, 1ЁЕЕ/АСМ.— San-Francisco, N. Y., .1976,
, p. 629—635.
84.	. King C. A new . approach to program testing. —, Proc. Int. Conf.
Reliable Software.— Los Angeles, 1975, p. 228—233.
85.	Laaki I. W. A hierarchical approach to program'testing. -*-АСМ
Sigplan Notices,. 1980, v. 15, N I, p. 77—85.
86.	. McCabe T. J, A complexity measure.— IEEE Trans., 1976, v. SE-2,
x N 4, p. 308—320.
87.	McClurr C. L. A model for program complexity analysis.— Proc.
3-nd Int. Conf.. Software Engineerings Atlanta,— N. Y.,. 1978,
p/149—157.	" 	_
88.	Munson I. B. Software maintenability: a practical concern for Hfe-
cyqie costs.—Computer, 1981, v- 14, N 11, p. 103—109..
89.	Musa 1. D. Validity of execution-time theory -of software reliabili-
ty.— IEEE Trans., 1979, v._R-28, N 3, p. 181—191.
90.	Chterweil L. A. A strategy for integrating program testing and analy-
sis,— Proc. Summer.School on Computer Program Testing held at
Sogesta, Italy, 1981, p. 187—229.
91.	Software Engineering Notes, 1983, v. 8, N 4. Proc. ACM Sigsoft/
Sigplan Software Engineering Simposium on High-Lewel Debugging/
Ed. M.S. Johnson.— 268 p.-, <
92.	Rosene A. F. et al. Software maintainability — what it means and
how to achieve it. — IEEE Trans., 1981, v. R;30, N 3, p. 240—245,
93.	Schick G. I., Wolverton R. W. An analysis of computing software re-
. liability models. — IEEE Trans., 1978, v._ SE-4, N 2, p. 104—120.
94.	Schindler M. Todays software tools point to tomorrow’s tool sys-
tems. — Electronic Design, 1981, v. 29, N 15, p. 73—110.
95.	. Schindler M. 1981: Technology forecast. Software. — Electronic .
Desing, 1981tv. 29, N 1, p. 190—199.
96.	Schneidewind N. F. Application of program graphs and complexity
analysis to software development and testing. — IEEE Trans..
1979, v. R-28, N 3, p. 192—198.
97.	Shooman M. L. Structural models for software reliability predicti-
on.— 2-nd Int. Conf. Software Engineering, 1976, p. 268—280.
98.	Shoontan M* Software engineering: Reliability, Development
and Management.— McGrow-Hill Inter. Book Co, 1983. — 672 p,
99.	Stikney M. E. An application of graph theory to software test date ,
selection.— Software Engineering Notes, 1978, v. 3, N 5, p. Ill—115.
100.	Stuck! L. G., Walker H. D. Concepts and prototips of ARGUS.—
Software Enfineering Environments, North-Holland Publishing
" Co, 1981, p. 61—79.
101.	Sukert A. N. Empirical validation of three software error prediction
models. — IEEE Trans., 1979, v. R-28. N 3. p. 199—204.
102.	Voges U. etai. SADAT—an automated testing tool.—IEEE Trans.,
1980, v. SE-6, N 3, p. 286—290.
103.	Walker M. G., Harrison R. G. Program portability. —Datamation,
1982, v. 28, N 1, p. 140—144. ,
. 293
104.	Walters G. E., McCall 1. A. Software quality metrics for lite-cycle
cost-rednction.— IEEE Trans., 1979. v. R-28, N'3, p 212—220.
105.	Waters R. C. A" method for analysing zoop programs. — IEEE
Trans., 1979, v. SE-5, N 3, p. 237—247.
106.	Weyuker E. I. On testing non-testable programs.—Computer J.,
1982, v. 25, N 4, p. 465—470.
107.	White I» 1., Cohen E. I. A domain strategy for computer program
testing. — IEEE Trans., 1980, v. SE.-6, N 3, p. 247—257.
108.	Willis R. R. AIDES: Computer aided design of software systems.
II.	Software engineering environments. — North-Holland Publi-
shing Co, 1981, p. 27—48.	'	•	,
109.	Woodward M. R., Hedley D., Hennell M. A: Experience with path
analysis and testing of programs.— IEEE Trans., 1980, v. SE-6,
N 3, p. 278—285.	-
110.	Yin В. H., Winchester J. W. The establishment and use of measures
to evaluate the quality of software designs.—Software Engineering
News, 1978, v. 3, N 5, p. 4j>—52. ~
111.	Martin J., McClure C. Software maintenance, the problems and its ’>
solutions.— Prentice-Hall, 1983.—472 p.
112.	Vai rand С. B. et al. Performance verification, of space shuttle on- Л
board software.— 4-th AIAA/IEEE Digital Avionics Systems Conf., >
1981, p. 446—458.	V
'	t
ОГЛАВЛЕНИЕ	*
Предисловие...............................................   3
Глава 1. Общие принципы и методй тестирования программ 5
1.1.	Программы как объекты тестирования................ 5
1.2.	Основные понятия систематического тестирования
программ и характеристики выявляемых ошибок . .	15
1.З.	- Категории тестов . ; . .#.....................".	32
Глава 2. Основные показатели процесса тестирования про-
' грамм.....................................................47
2Л.	Критерии качества тестирования программ	......	4?
2.2. Сложность тестирования	программ	..........	66
•2.3.. Затраты на тестирование	программ	.	. . .’....92
Глава 3. Тестирование программных модулей................. .111
3.1.	Методы и методика тестирования программных моду-
лей ................................................. 111
3.2.	Тестирование модулей без исполнения Программ . .121
3.3.	Тестирование структуры программных модулей . .’ . 130
3.4.	Тестирование обработки данных . . .'.............152
3.5.	Средства автоматизации тестирования программных
модулей.............*............  .	................170
Глава 4. Тестирование при отладк! и испытаниях комплек-
сов программ...............................'.............199
4.1.	Генерирование тестов для комплексов программ ... 199
4.2.	Регистрация и обработка данных при тестировании ком-
плексов программ....................................  214
4.3.	Некоторые особенности тестирования комплексов про-
грамм реального времени........................’	. . . 222
4.4.	Тестирование при испытаниях программ . . .231
Глава 5. Тестирование при сопровождении комплексов про-
грамм .....................................-...........  246
5.1. Принципы конфигурационного управления и сопро-
вождения комплексов программ............, . . ... . . 246
I	5.2. Тестирование прн сопровождении программ..........260
Заключение ...............................  Г..............284
Список литературы.................................  .	.	. 289