Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Липаев В.В. Программная инженерия

.pdf
Скачиваний:
719
Добавлен:
02.05.2014
Размер:
10.14 Mб
Скачать

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

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

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

370

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

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

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

Стратегия 1

Стратегия 2

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

 

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

Подготовка теста для проверки

*

функции и потока данных в ПМ

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

 

по выбранным критериям

 

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

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

тесту

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

 

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

Выявление ошибок в данных

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

и вычислениях в ПМ

 

Сравнение реализованного маршрута

 

исполнения ПМ и исходного по тексту

Обобшение протестированных

 

 

маршрутов ПМ

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

 

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

 

Выявление ошибок в вычислениях

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

по протестированным маршрутам

на выделенном маршруте

 

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

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

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

Рис. 13.3

371

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

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

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

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

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

372

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

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

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

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

373

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

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

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

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

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

374

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

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

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

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

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

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

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

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

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

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

игрупп программ, в которых проведены корректировки.

375

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

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

 

Исходные

 

 

 

 

 

данные

 

 

Средства статической

 

 

 

 

отладки:

 

1 Тексты программ

1

Анализ и контроль

|

1 в исходном и

 

 

структурной

1

1 объектном коде

 

1

коррекгности программ

1

 

 

 

1

Расчет

1

 

Задания и

 

1

длительностей

1

1

директивы

 

 

исполнения программ

 

1

управления

 

 

 

 

1

средствами

 

 

 

 

 

 

 

1

Планирование

|

 

 

 

1

тестирования структуры

1

 

 

 

1

программ

1

 

 

 

 

1 г

 

 

 

 

 

Средства отладки с

 

 

 

 

исполнением программ:

 

Тесты и

1

1

Формирование

 

 

отладочные

1

 

 

1

отладочного задания и

1

 

задания

1

 

1

тестов для программы

1

 

 

 

 

 

 

1

Исполнение

 

 

 

 

1

тестируемой программы

 

 

 

 

 

по отладочному заданию

 

 

Эталонные

1

 

 

 

 

данные и

1

 

 

 

 

маршруты

 

1

Обработка и

 

 

исполнения

Г

1

обобщение результатов

 

 

программ

1

1 тестирования программы

 

 

Задания на

1

1

Диагностика,

1

 

корректировку

Г

 

локализация дефектов и

1

 

программ

1

1 корректировка программ

 

 

 

 

 

Оценивание полноты

1

 

 

 

 

тестирования и качества

|

 

 

 

1

программы

 

Результирующие

данные

Нарушения правил структурной 1 корректности 1

программ

Значения 1 длительностей

исполнения 1 программ 1

Упорядоченные 1 маршруты и 1 условия их формирования

План

тестирования

1 Протестированные

1

маршруты и

1

данные в

1

контрольных

1

точках

J

Характеристики

1

покрытия тестами

1

и результаты

1

тестирования

1

программ

1

Характеристики

J

качества и

1

полноты

1

тестирования

1

программ

Рис. 13.4

376

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

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

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

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

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

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

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

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

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

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

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

377

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

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

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

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

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

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

378

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

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

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

три группы данных:

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

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

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

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

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

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

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

379