Автоматизация тестирования и отладки

ЛЕКЦИЯ 12

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

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

•уменьшается количество соединений между двумя модулями, что приводит к уменьшению вероятности появления «волно­вого эффекта» (ошибка в одном модуле влияет на работу дру­гих модулей);

• минимизируется риск появления «эффекта ряби» (внесение изменений, например при исправлении ошибки, приводит к появлению новых ошибок), так как изменение влияет на ми­нимальное количество модулей;

• при сопровождении модуля отпадает необходимость беспоко­иться о внутренних деталях других модулей;

•система упрощается для понимания настолько, насколько это возможно.

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

Два модуля А и В нормально сцеплены, если: А вызываетВ;

В возвращает управление А; вся информация, передаваемая между А иВ, представляется значениями параметров при вызове.

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

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

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

^ Два модуля сцеплены по управлению, если один посылает дру­гому информационный объект — флаг, предназначенный для уп­равления его внутренней логикой. Существует два типа флагов — описательный и управляющий. Описательный флаг обычно описы­вает ситуацию, которая произошла, и именуется с использованием существительных и прилагательных: Конец файла, Введенная кредит­ная карта. Управляющий флаг используется для декларирования определенных действий в вызываемом модуле и именуется с ис­пользованием глаголов: Читать следующую запись, Установить в на­чало. В общем случае управляющие флаги усиливают сцепление и, следовательно, ухудшают качество проекта.

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

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

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

В табл. 6 приведены сравнительные характеристики по каждому типу сцепления.

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

Связность — это мера прочности соединения функциональных и информационных объектов внутри одного модуля. Размещение силь­носвязанных объектов в одном и том же модуле уменьшает межмо-

Таблица б

^ Тип сцепления	Устойчивость к волновому эффекту	Модифици­руемость	Понятность	Используемость в других системах
По данным	*	хорошая	хорошая	хорошая
По образцу	*	средняя	средняя	средняя
По управлению	средняя	плохая	плохая	плохая
По общей области	плохая	средняя	плохая	плохая
По содержимому	плохая	плохая	плохая	плохая

* — зависит от количества параметров интерфейса

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

^ Функционально связный модуль содержит объекты, предназначен­ные для выполнения одной и только одной задачи, например: Рас­чет заработной платы. Считывание данных кредитной карты. Каж­дый из таких модулей имеет одну четко определенную цель, при его вызове выполняется только одна задача (при этом она выполняется полностью без исполнения любого другого дополнительного дей­ствия).

^ Последовательно связный модуль содержит объекты, охватываю­щие подзадачи, для которых выходные данные предыдущей подза­дачи служат входными данными для последующей, например: От­крыть файл— Прочитать запись— Закрыть файл.

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

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

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

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

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

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

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

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

В табл. 7 приведены сравнительные характеристики для каждого уровня связности.

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

Таблица 7

СВЯЗНОСТИ	Сцепление	Модифици­руемость	Понятность	Сопровож-даемость
функцио­нальная	хорошее	хорошая	хорошая	хорошая
последова­тельная	хорошее	хорошая	близкая к хорошей	хорошая
информа­ционная	среднее	средняя	средняя	средняя
процедурная	переменное	переменная	переменная	плохая
временная	плохое	средняя	средняя	плохая
логическая	плохое	плохая	плохая	плохая
случайная	плохое	плохая	плохая	плохая

шей связности к худшей). Как и сцепление, связность является од­ним из лучших критериев оценки качества про­екта.

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

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

Рассмотрим основные принципы, позволяющие получать каче­ственные системы.

1) ^ Принцип факторизации. Под факторизацией понимается вы­деление подзадачи, реализуемой некоторым модулем, в новый са­мостоятельный модуль. Это может быть сделано с целью:

• уменьшения размеров модуля;

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

• устранения дублирования подзадачи, выполняемой более чем одним модулем;

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

• обеспечения более широкой пригодности модулей для исполь­зования их в различных частях системы;

• упрощения реализации.

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

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

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

• появляется возможность хранить тексты сообщений в отдель­ном файле, а не внутри кода модуля;

• легче избежать дублирования сообщений;

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

4) ^ Принцип отсутствия памяти состояния. Когда вызванный мо­дуль после выполнения своей функции возвра­щает управление выз­вавшему его модулю, он «умирает», оставляя после себя лишь ре­зультат. При повторном вы­зове он делает свою работу так, будто он только что «родился». Модуль «не помнит», что происходило в его пре­дыдущих жизнях. Однако существует тип модуля, который «зна­ет» о своем прошлом благодаря так называемой памяти состояния. Память состояния — это информационный объект внутри модуля, который продолжает суще­ствовать неизменным между двумя вызо­вами модуля. Работа модуля с памятью состояния в общем случае не­предсказуема, это означает, что хотя модуль вызывался с одина­ковыми фактическими параметрами, исполняться он может по-раз­ному, и результаты его работы при разных вызовах могут быть раз­личными. Сопровождение та­кого модуля резко усложняется.

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

6) ^ Компромисс между ограниченностью и обобщенностью. Огра­ниченный модуль обладает по крайней мере одной из следующих характеристик:

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

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

• включает в себя условия о месте и способе его использова­ния.

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

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

• имеет дело со слишком избыточными типами данных, их значениями и структурами. Например, ис­пользование числа типа REAL вместо INTEGER для того, чтобы следить за ко­личеством болтов на складе, было бы чрезмерным обобще­нием;

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

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

8) ^ Нагрузка по входу и выходу. Под нагрузкой модуля по входу понимается количество непосредственных вы­зывающих его моду­лей. Соответственно, нагрузка модуля по выходу — это количество непосредственно подчи­ненных ему модулей. По уже упоминавшим­ся выше причинам нагрузка по выходу не должна превышать 6—7 мо­дулей. Высокая нагрузка по входу требует от модуля хорошей связ­ности.

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

^ Объектно-ориентированное проектирование

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

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

На этапе проектирования используются следующие диаграммные техники:

• наследуемые от этапа анализа требований и развиваемые на этапе проектирования диаграммы классов и диаграммы объек­тов, являющиеся основой статической логической модели;

• диаграммы модулей и диаграммы процессов, моделирующие конкретные программные и аппаратные ком­поненты и явля­ющиеся частью статической физической модели;

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

^ Реализация (программирование/адаптация)

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

Корректность АСУП является ее самым важным свойством и, несомненно, составляет главный предмет за­боты разработчиков. В идеальном случае под корректностью АСУП понимается отсут­ствие в ней ошибок. Од­нако для большинства сложных программ­ных продуктов достигнуть этого невозможно — «в каждой програм­ме со­держится по крайней мере одна ошибка». Поэтому под коррек­тным обычно подразумевают программный продукт, работающий в соответствии с предъявленными к нему требованиями, другими сло­вами, продукт, для которого пока еще не найдены такие условия, в которых он окажется неработоспособным.

Установление корректности является главной целью рассматри­ваемого этапа жизненного цикла. Следует отме­тить, что этап тести­рования и отладки — один из наиболее трудоемких, утомительных и непредсказуемых этапов разработки АСУП. В среднем при разра­ботке традиционными методами этот этап занимает от '/₃ до '/₂ полного времени разработки. С другой стороны, тестирование и от­ладка представляют собой серьезную проблему: в некото­рых случаях тестирование и отладка программы требуют в несколько раз больше времени, чем непосредственно программирование.

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

Различные аспекты тестирования многократно исследовались, однако полученные теоретические результаты носят почти исклю­чительно негативный характер, что создает пессимистическую кар­тину ценности получаемых при тестировании данных и в целом мо­жет быть суммировано в известном тезисе Дейкстры: «Тестирование про­грамм может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!». Тем не менее нужно констати­ровать, что на практике результаты тестовых испытаний, не выя­вившие программных ошибок, интерпретируются как свидетельство корректности этой программы.

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

• формулировку целей тестирования;

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

• стратегию проведения тестирования, обеспечивающую дости­жение заданных критериев качества;

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

Для целей тестирования программные элементы АСУП удобно представлять в виде ориентированного графа G = (N, Е),

где N = (N₁, N₂,..., N_m) — множество узлов (вершин), соответ­ствующих выполняемым операторам тестируемой программы;

Е= (Е₁, Е₂,..., Е_п) — множество ребер (дуг), соответствующих передачам управления между операторами.

Путем (маршрутом) называется последовательность вершин и дуг Р= (N₁, E_1,2, N₂, E_2,3 ,..., E_k-1,k, N_k), где каждая дуга E_i,i+l выходит из N_t и входит в N_i+l, причем N₁ не обязательно начальный узел. Ветвью называется путь Р, в котором N₁ — либо начальный узел, либо узел ветвления, N_k — либо узел ветвления, либо завершающий узел, все остальные N₁ не являются узлами ветвления.

Очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, не гарантирую­щие полной проверки программы. Общим требованием к этим крите­риям является достижение лишь определенной степени полноты АСУП или ее компонент. Как правило, эти критерии устанавливают требо­вание по крайней мере однократной проверки всех операторов про­граммы, всех ветвей программы, либо всех подпутей специального вида (например, всех под­путей, проверяющих циклы при началь­ном, завершающем и одном из промежуточных значений перемен­ной — счетчика цикла). Самым распространенным критерием тести­рования является критерий, требующий по крайней мере однократ­ной проверки каждой из ветвей программ (критерий С₁). Так, напри­мер, тестирование при приемке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независи­мых оценок использование критерия С₁ обеспечивает обнаружение от 67 до 90% ошибок.

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

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

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

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

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

Система автоматизации тестирования и отладки (САТО) пред­ставляет собой сложный комплекс алгоритмиче­ских и программных средств, предназначенных для автоматизации анализа АСУП, тес­тирования, отладки и оценки ее качества, и позволяет облегчить модификацию компонент АСУП, обеспечить выявление ошибок на ранних стадиях отладки, повысить процент автоматически обнару­живаемых ошибок. На рис. 23 показано, как использование САТО влияет на цену обнаружения ошибок в течение жизненного цикла АСУП. АСУП стано­вится «работоспособной», когда цена обнару­женной ошибки меньше некоторого значения μ, которое отражает уровень терпимости пользователя к программным ошибкам. Число имеющихся ошибок (область под кривой) одно и то же в обоих случаях. Отметим, что число обнаруженных ошибок после того, как АСУП становится ра­ботоспособной, почти постоянно по следую­щим причинам:

1) влияние эффекта «ряби» — исправление ошибки служит ис­точником внесения новых ошибок (практика показывает, что такие ошибки составляют 19% всех обнаруженных ошибок);

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

Рис. 23

I - кривая тестирования с использованием САТО,

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

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

Средства автоматизации, включаемые в САТО, в зависимости от решаемых ими задач разбиваются на средства автоматизации тести­рования и средства автоматизации отладки.

Средства автоматизации тестирования в соответствии с этапами процесса тестирования классифицируются на следующие пять типов:

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

2) средства автоматизированного контроля результатов, пред­назначенные для автоматического сравнения ожидаемых результа­тов с реальными и выдачи информации обо всех расхождениях. Иног­да удается автоматизиро­вать и получение ожидаемых результатов, однако соответствующие средства не будут являться универсальны­ми по отношению к тестируемым объектам;

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

4) средства автоматизированного контроля тестирования, позво­ляющие оценить, насколько полная и тщатель­ная проверка АСУП была осуществлена, например, на основе информации о непрове­ренных операто­рах/функциях, непроверенных маршрутах и т. п.;

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

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

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

^ Средства статического анализа классифицируются следующим образом:

1) средства анализа потоков управления, осуществляющие кон­троль структуры АСУП в целом, а также от­дельных ее конструкций на основе графовой модели. Средства данного типа позволяют авто­матически обнаружить следующие изъяны: невыполняемые опера­торы/функции, тупиковые ветви, некоторые виды бесконечных циклов и др.;

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

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

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

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

6) средства для контроля последовательности событий, произ­водящие сравнение этой последовательности с правильной, зара­нее заданной последовательностью (например, при работе с фай­лом должна соблюдаться сле­дующая последовательность: создание, открытие, совокупность чтений/записей, закрытие).

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

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

Средства частичной автоматизации позволяют пользователю ав­томатически получать необходимую ему инфор­мацию для дальней­шей локализации ошибок вручную. Среди таких средств наиболее распространены DDT (Di­namic Debugging Tools) — «системы для уничтожения блох«(слово «bug» в английском языке означает не только «ошибка», но и»блоха», а ДДТ — популярное в недавнее время средство борьбы с насекомыми). Управление системой DDT и, соответственно, управление отладкой осуществляются посред­ством языка отладки командного типа, его операторы имеют форму приказов (команд), состоящих из ключевого слова и списка опе­рандов, если последние необходимы. Операторы языка отладки обес­печивают взаимодействие программиста с DDT и инициируют вы­полнение соответствующих отладочных функций, согласно которым они могут быть разбиты на следующие группы:

1) управляющие операторы, обеспечивающие управление вы­полнением АСУП в отладочном режиме, а также гибкий контроль исполнения информирующих и контролирующих операторов;

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

3) контролирующие операторы, осуществляющие контроль зна­чений переменных, маршрутов и т. п. на пред­мет сравнения с зара­нее заданными;

4) операторы чтения/записи, дающие возможность форматного ввода тестовых данных и вывода результатов в протокол сеанса от­ладки в терминах исходного языка программирования;

5) служебные операторы, обеспечивающие загрузку отлаживае­мых программных и информационных компо­нент АСУП, переклю­чение режимов (пакет, диалог), ввод в протокол сеанса отладки комментариев и т. д.

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

Дата добавления: 2017-01-14