Липаев В.В. Программная инженерия
.pdfЛекция 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