Программная инженерия

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

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

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

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

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

380

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

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

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

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

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

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

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

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

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

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

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

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

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

381

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

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

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

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

382

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

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

тимых отклонений от эталонов и решений о степени корректности

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

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

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

При систематическом восходящем тестировании, прежде всего, про­ веряются программные компоненты и/или модули нижних иерархических

383

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

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

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

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

объектов:

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

384

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

—программных модулей, запрограммированных и подготовленных

ктестированию на уровне исходных текстов программ и на уровне объект­ ных кодов реализующей ЭВМ;

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

—функциональных компонентов в составе программных средств.

Требования к характеристикам системы

Тестирование программных модулей

Рис. 13.5

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

385

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

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

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

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

Автономное тестирование функциональных компонентов с исполне­ нием программ предназначено для проверки корректности решения от­ дельных достаточно крупных функциональных задач. На этом этапе про-

386

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

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

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

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

387

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

рование при максимально широком варьировании тестов в условиях, соот­ ветствующих нормальной и форсированной эксплуатации.

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

Тестирование функционирования программ в критических ситуациях

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

Основные этапы систематического тестирования и испытаний

крупного комплекса программ реального времени и его компонентов пред­ ставлены на рис. 13.6. При тестировании и испытаниях корректности

функциональных компонентов комплексов программ выделены этапы:

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

388

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

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

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

сосновными компонентами операционной системы и базы данных.

•программ при реальных воздействиях

Рис. 13.6

389