13.2. Процессы и средства тестирования программных компонентов

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

Стратегия 1 Стратегия 2

I Построение структуры ПМ

I по тексту программы

Подготовка теста для проверки функции и потока данных в ПМ

*

I Выделение и упорядочение маршрутов I по выбранным критериям

Тестирование ПМ по сформированному тесту

*

I Формирование теста по условиям

I в предикатах выбранного маршрута

i

Выявление ошибок в данных и вычислениях в ПМ

I Тестирование маршрута ПМ

I по сформированному тесту

*

Обобщение протестированных маршрутов ПМ

I Сравнение реализованного маршрута I исполнения ПМ и исходного по тексту

i

I Выявление и устранение ошибок

Формирование структуры ПМ по протестированным маршрутам

I несоответствия маршрутов

Выявление ошибок в вычислениях на выделенном маршруте

1_

Оценка покрытия исходной структуры ПМ протестированными маршрутами

\

Оценка достаточности выполненного тестирования ПМ

I

Окончание-тестирования и регистрация степени корректности ПМ

Рис. 13.3 371

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

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

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

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

372

13.2. Процессы и средства тестирования программных компонентов

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

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

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

373

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

При разработке сложных ПС верификация и тестирование требуют значительных ресурсов в течение всего ЖЦ ПС, и наиболее критичным ресурсом является допустимое время поэтапного выполнения этих процедур. Интенсивность выявления дефектов при тестировании программ практически экспоненциально убывает в зависимости от времени, затрачиваемого на их обнаружение, и соответственно возрастают интервалы между очередными проявлениями дефектов. На основе экспериментальных данных созданы математические модели, которые позволяют прогнозировать интервалы времени между последовательными обнаружениями дефектов или ошибок в программных компонентах при некотором методе и этапе верификации или тестирования (см. лекцию 10). Например, если при тестировании определенного модуля или компонента ПС выявлено определенное число дефектов (например, 5 или 10), то модели позволяют оценить ресурсы (время), необходимое для обнаружения следующего дефекта, и рентабельность продолжения тестирования используемым методом. Рациональное изменение стратегии или метода выявления дефектов может приводить к кратковременному повышению интенсивности их проявления, а затем к постепенному ее снижению.

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

374

13.2. Процессы и средства тестирования программных компонентов

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

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

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

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

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

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

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

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

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

375

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

Исходные					Результирующие
данные		Средства статической отладки:						данные
								Нарушения правил структурной I корректности I программ
1 Тексты программ 1 в исходном и 1 объектном коде		1 Анализ и контроль 1 структурной 1 1 корректности программ 1
		1 Расчет 1 1 длительностей 1 исполнения программ						Значения I длительностей исполнения I программ I
Задания и 1 директивы 1 управления 1 средствами
		1 Планирование 1 1 тестирования структуры 1 1 программ 1						Упорядоченные I маршруты и I условия их формирования
1				г
		Средства отладки с исполнением программ:								План тестирования
Тесты и 1 отладочные 1 задания 1
		1 Формирование 1 отладочного задания и 1 I тестов для программы 1
								I Протестированные I маршруты и 1 данные в 1 контрольных 1 точках
		1 Исполнение 1 тестируемой программы по отладочному заданию
Эталонные 1 данные и 1 маршруты исполнения Г программ 1
		1 Обработка и 1 обобщение результатов 1 тестирования программы
								J Характеристики 1 покрытия тестами 1 и результаты 1 тестирования 1 программ
Задания на 1 корректировку Г программ 1		1 Диагностика, 1 локализация дефектов и 1 1 корректировка программ
								1 Характеристики J качества и 1 полноты 1 тестирования 1 программ
		Оценивание полноты 1 тестирования и качества 1 1 программы
		Рис.	13.4

376

13.2. Процессы и средства тестирования программных компонентов

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

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

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

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

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

• трансляции программ, тестов и заданий с языка отладки;

• исполнения программы по отладочному заданию в соответствии с планом и сценарием тестирования;

• регистрации данных о результатах тестирования.

377

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

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

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

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

Для поддержки конфигурационного управления программными компонентами может быть полезным хранение на некотором интервале вре-

378

13.2. Процессы и средства тестирования программных компонентов

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

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

• о циклах в программе;

• о маршрутах исполнения программы;

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

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

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

379

Лекция 13. Верификация, тестирование и оценивание корректности компонентов

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

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

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

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

380

13.3. Технологические этапы и стратегии систематического тестирования программ

в компактной и наглядной форме позволяют сделать процесс тестирования эффективным и экономичным.

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

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

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

• план тестирования компонентов;

• методы и критерии оценки достигнутого качества программных компонентов;

• входные и результирующие данные тестирования;

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

• распределение ответственности между специалистами по компонентам и видам проверок;

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