ЛЕКЦИЯ 13. Лекция 13 верификация, тестирование и оценивание корректности программных компонентов
 Скачать 200.7 Kb.
|
|
376 13.2. Процессы и средства тестирования программных компонентов
Эти средства объединяются средствами интерактивного диалога с пользователями и базой данных проектирования, В группу статической отладки входят средства, автоматизирующие структурный анализ и проверку формальной корректности текстов программ и выявление соответствующих типов ошибок. Кроме того, они должны обеспечивать автоматизированное получение данных, поддерживающих выявление ошибок при последующем применении динамических средств. Средства подготовки данных для планирования тестирования должны обеспечивать выделение типовых структур в модуле (циклов, альтернатив, маршрутов исполнения) и их упорядочения по некоторым правилам. Выделение маршрутов исполнения программы и условий их формирования позволяет определить границы областей изменения переменных, влияющие на формирование тестовых наборов и их объем. В результате статического анализа программы автоматически могут создаваться упорядоченные наборы ее характеристик, которые используются для подготовки наборов тестов, а также для контроля полноты проведенного тестирования модулей при динамической отладке. В группу средств статической отладки входят также средства расчета длительностей исполнения модулей и компонентов. Эти средства позволяют получать ориентировочные значения и распределения длительностей счета программы аналитически, без ее исполнения на ЭВМ. В результате расчетов выявляются компоненты программы, требующие избыточно большого времени счета на реализующей ЭВМ, а также подготавливаются данные для общей проверки реализуемости ПС в реальном времени, Группу средств динамической отладки можно разделить на основные средства, непосредственно обеспечивающие исполнение программ в соответствии с отладочными заданиями, и средства, анализирующие выполненное тестирование, его результаты и проведенные корректировки. В основные входят средства:
377 Лекция 13. Верификация, тестирование и оценивание корректности компонентов Средства трансляции заданий с языка отладки обеспечивают обработку и подготовку к исполнению тестов и сценария отладочного задания. В задании указывается тестируемая программа, контролируемые и регистрируемые переменные и состояния программы в процессе исполнения. Тестовые значения преобразуются в форму, пригодную для исполнения отлаживаемой программой. Операторы отладочного задания объединяются с отлаживаемой программой или подготавливаются для исполнения в режиме эмуляции или интерпретации. Средства исполнения программы по отладочному заданию управляют реализацией операторов задания в процессе исполнения отлаживаемой программы. В процессе обработки тестов производится предварительная селекция результатов тестирования в соответствии с указаниями операторов отладочного задания. В некоторых случаях получаемые результаты могут автоматизировано сравниваться с эталонными значениями для выявления ошибок. Средства регистрации и обобщения данных о результатах тестирования осуществляют преобразование зафиксированных данных функционирования отлаживаемой программы на язык отладки для диалогового взаимодействия с пользователем. Для сокращения избыточной информации производятся редактирование и селекция результатов исполнения операторов отладочного задания. Отображение результатов тестирования в мнемонической и графической формах может обеспечиваться унифицированными средствами интерактивного взаимодействия пользователей с ЭВМ. Для каждого отлаженного программного компонента должно обеспечиваться хранение основных тестов и отладочных заданий, с использованием которых проведено тестирование. Это позволяет поддерживать высокое качество компонентов и при необходимости вносить в них корректировки. При проведении таких изменений соответственно расширяется и модифицируется состав применявшихся тестов и заданий. Вместе с тестами целесообразно хранить результаты оценки полноты тестирования и достигнутой корректности программного компонента. Эти данные вместе с оценкой сложности компонента, структурными и информационными характеристиками могут объединяться в паспорт аттестации компонента. Для поддержки конфигурационного управления программными компонентами может быть полезным хранение на некотором интервале вре- 378 13.2. Процессы и средства тестирования программных компонентов мени проведенных изменений и выявленных ошибок (см. лекцию 16). Эти данные могут использоваться для прогнозирования процессов отладки программ и сроков достижения заданного их качества. Они позволяют выявлять статистические характеристики ошибок и квалифицированно управлять процессом модификации программ. Планирование тестирования — процесс творческий, и средства автоматизации предназначены в основном для подготовки исходных данных, используемых при планировании. Эту информацию можно разделить на три группы данных:
Для подготовки этих данных используются текст программы на языке программирования и взвешенная графовая модель программы. Эта модель может подготавливаться специально средствами автоматизации планирования тестирования или средствами контроля структуры и определения длительности исполнения программы. Основная часть данных для планирования тестирования может быть получена автоматическим расчетом по тексту программы с использованием указаний разработчика о критерии выделения и стратегии упорядочения маршрутов. Диалог разработчика со средствами автоматизации целесообразен для уточнения критерия и стратегии образования маршрутов в зависимости от сложности тестирования, а также для исключения циклов и ациклических маршрутов, которые не реализуются по сочетаниям условий в предикатах. Диалог может также быть полезным при подготовке взвешенной графовой модели программы, когда необходимо ввести оценки значений вероятностей ветвления в вершинах графа и характеристики итераций циклов. В программе, прежде всего, автоматически должны выделяться циклы, подлежащие тестированию. Для этого используются указания разработчика о стратегии выделения маршрутов при тестировании циклов. Кроме того, следует вводить указания о количестве итераций циклов и их связях с маршрутами исполнения циклов. В результате разработчику отображаются данные о маршрутах в циклах, которые подлежат тестированию по выбранной стратегии. По данным о циклах, выделенных для автономного тестирования, рассчитываются суммарное число тестов в плане и сум- 379 Лекция 13. Верификация, тестирование и оценивание корректности компонентов марная сложность тестирования циклов. Выделение циклов и маршрутов в них позволяет преобразовать программу к ациклическому виду. Для выделения тестируемых маршрутов в такой ациклической программе разработчик должен указать критерий, по которому следует формировать маршруты. Кроме того, разработчик указывает стратегию для составления упорядоченного списка маршрутов, по которому надлежит планировать последовательность тестирования. Упорядочение маршрутов производится по длительности их исполнения или по вероятности реализации при случайных данных на входе программы. Если ряд маршрутов может быть нереализуемым по сочетаниям условий в вершинах графа программы, то такие маршруты следует исключать из последующего анализа. В результате составляется список маршрутов, упорядоченных по выбранной стратегии. По этим маршрутам рассчитываются полное число тестов и суммарная сложность тестирования структуры программы в соответствии с выбранным критерием выделения маршрутов. Корректировка планов возможна за счет изменения критерия выделения маршрутов и за счет ограничения числа выделенных для тестирования маршрутов из общего упорядоченного множества. Выделенные для тестирования маршруты могут дополняться данными о значениях переменных в предикатах условий на каждом маршруте. Для этого используются текст программы на языке программирования и описание переменных. По полученным соотношениям между переменными в предикатах условий могут быть построены границы областей изменения переменных для каждого из маршрутов и для программы в целом (см. п. 13.5). По числу границ областей изменения переменных осуществляется оценка числа тестов, необходимых для проверки процессов обработки данных в анализируемой программе. Характеристики сложности тестирования областей в совокупности с характеристиками сложности тестирования структуры программы и циклов позволяют оценить реализуемость плана тестирования конкретного программного модуля или компонента. Кроме того, рассматриваемые средства представляют разработчику достаточно полные сведения о циклах, маршрутах и переменных, которые необходимо учитывать при планировании тестирования. Автоматический расчет и упорядочение информации о характеристиках программы, а также отображение этих сведений 380 13.3. Технологические этапы и стратегии систематического тестирования программ в компактной и наглядной форме позволяют сделать процесс тестирования эффективным и экономичным. Документирование процессов тестирования программных компонентов следует проводить непосредственно при выполнении каждой из соответствующих работ с определенными целями. Должны быть описаны и документированы, упорядочены и конкретизированы весь технологический процесс тестирования и частные результаты на каждом этапе ЖЦ ПС:
13.3. Технологические этапы и стратегии систематического тестирования программ Исходным эталоном для тестирования любой программы являются требования технического задания и/или спецификации требований заказчика и потенциального пользователя, предъявляемые к создаваемым программам. Подобные документы должны устанавливать состав, содержание и значения результатов, которые должен получать пользователь при определенных условиях и исходных данных. Любое отклонение результатов функционирования программы от предъявляемых к ней требований и сформированных по ним эталонов следует квалифицировать как ошибку или дефект в программе. 381 Лекция 13. Верификация, тестирование и оценивание корректности компонентов Эталонные значения параметров и характеристик результатов тестирования для вычислительных программ получать относительно проще, прежде всего потому, что требуется значительно меньшее количество контрольных величин. Промежуточные значения результатов можно определять интерполяцией или вообще пропускать, опираясь на предположение о гладкости вычисляемых функций, т.е. необязательна подготовка эталонов при абсолютно всех комбинациях исходных данных. При том же объеме тестируемой программы подготовка эталонных значений для логических программ усложняется, прежде всего, вследствие их комбинаторного характера и увеличения необходимого числа тестовых значений. В этом случае тесты, в принципе, необходимо рассчитывать для всех возможных сочетаний исходных данных, так как каждое из них может полностью изменять область определения и смысловое значение результирующих величин. На математических моделях или прототипах, реализуемых на ЭВМ, наиболее эффективно получать эталонные значения и требуемые характеристики функционирования сложных программ. Возможно создание моделей двух типов: на базе более сложных и более точных алгоритмов, которые, например, не могут быть реализованы на объектной ЭВМ вследствие ограниченных ресурсов, и на базе упрощенных, обобщенных моделей для более быстрого получения эталонных значений. Модели второго типа, естественно, характеризуются меньшей потенциальной точностью результатов, однако, благодаря снижению сложности, в них менее вероятны ошибки. Результаты функционирования реальных программ, являющихся предшественниками-прототипами или пилотными проектами разрабатываемой версии ПС, для использования в качестве эталонов при тестировании требуют обеспечения идентичности и повторяемости исходных данных, используемых проверяемыми программами при получении эталонных значений. На завершающих стадиях создания ПС формализация эталонных значений в ряде случаев не доводится до конца и в качестве эталона выступает неформализованное представление разработчика или заказчика. Во всех случаях целесообразно фиксировать и сохранять значения используемые в качестве тестовых эталонов для обеспечения повторяемости сеансов тестирования. 382 13.3. Технологические этапы и стратегии систематического тестирования программ При сравнении результатов функционирования проверяемых программ на соответствие эталонам следует использовать критерии оценки допустимых отклонений от эталонов и решений о степени корректности программы. Величина допусков зависит от типа проверяемого алгоритма, метода и этапа проверки корректности программ. Для простых логических алгоритмов, реализующих некоторые схемы принятия решений, при анализе результатов тестирования обычно используется детерминированный критерий абсолютной идентичности проверяемых и эталонных решений при одинаковых исходных данных. В вычислительных алгоритмах и при проверке сложных логических алгоритмов сравнение с эталоном приходится осуществлять статистически. Выделение и стратегия упорядочения компонентов для тестирования в крупных ПС зависит от их архитектуры и реального состава готовых к использованию компонентов. При нисходящем тестировании от требований оно начинается с программ организации вычислительного процесса. Первоначально тестируются управляющее ядро комплекса программ и программы решения функциональных задач, размещенные на высших иерархических уровнях, на соответствие исходным требованиям технического задания. К ним последовательно, по мере готовности, подключаются компоненты более низких иерархических уровней. Такая стратегия сверху вниз эффективна, когда имеется достаточно полный набор готовых апробированных программных компонентов и/или модулей, ранее отработанных в версиях подобных или пилотных программных комплексов. Если некоторые программы нижних уровней не разработаны или недостаточно протестированы, то вместо них временно могут подключаться программные имитаторы — «заглушки». В результате при тестировании на начальных этапах проверяются модели функциональных групп программ или комплекса с некоторым числом имитаторов программных компонентов. Преимуществом такой стратегии тестирования является сохранение и последовательное развитие тестовых исходных данных по мере подключения компонентов. Однако тестирование групп программ с заглушками может требовать больших затрат на обнаружение простейших ошибок во вновь разработанных и подключаемых модулях, если они до этого автономно недостаточно тестировались. При систематическом восходящем тестировании, прежде всего, проверяются программные компоненты и/или модули нижних иерархических 383 Лекция 13. Верификация, тестирование и оценивание корректности компонентов уровней в функциональной группе программ, к которым последовательно подключаются вызывающие их модули. В этих модулях тестирование также начинается с простейших конструкций, переменных и маршрутов обработки информации. Соответственно последовательно усложняются используемые методы тестирования и типы выявляемых при этом ошибок. Последовательное наращивание компонентов в комплексе программ снизу вверх позволяет проверять работоспособность таких групп в их естественном исполнении, без подмены и имитации компонентов нижних уровней. Основные трудности при такой стратегии состоят в необходимости непрерывного обновления и увеличения числа тестовых наборов по мере подключения каждого нового компонента более высокого уровня. Одновременно углубляется тестирование компонентов нижних иерархических уровней, что способствует систематическому повышению их качества. Нисходящее и восходящее тестирование отличаются не только схемой анализа модулей или небольших компонентов, но также принципиальными целями всего процесса тестирования крупных комплексов программ. Основная цель нисходящего тестирования — верифицировать требования к модулям и программным компонентам, а также добиться их качества при автономном тестировании каждого из них вне реального времени. Тем самым в процессе декомпозиции должно быть обеспечено требуемое качество компонентов и их соответствие исходным требованиям. При восходящем тестировании главная задача — обеспечить укрупнение, интеграцию и корректное взаимодействие всех компонентов для полного решения задач требуемым комплексом программ. При этом предполагается достаточно высокое качество подготовленных ранее компонентов. Представленные в данной главе фрагменты этих базовых процессов тестирования схематично объединены на рис. 13.5. Подобную схему полезно иметь в виду при планировании стратегии тестирования крупных ПС. С учетом особенностей применения методов и технологических этапов ЖЦ программных компонентов ниже в данном разделе последовательно рассматриваются задачи восходящего тестирования следующих объектов: — формализованных спецификаций требований на программные и информационные модули, на группы программ и на программные комплексы; 384 13.3. Технологические этапы и стратегии систематического тестирования программ
|