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

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

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

—исполняемый объектный код удовлетворяет требованиям к исход­ ному тексту программных компонентов.

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

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

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

—полностью определены функции информационной системы, кото­ рые должно выполнять ПС;

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

ичто правильно определены производные требования и обоснована их необходимость;

360

13.1.принципы верификации и тестирования программ

—каждое требование высокого уровня к ПС является точным, одно­ значным и достаточно детализированным и что требования не конфликту­ ют друг с другом;

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

—процесс разработки требований к ПС полностью соответствует стандартам на создание спецификаций требований и любые отклонения от стандартов обоснованны;

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

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

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

361

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

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

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

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

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

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

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

исредства при творческой, высокой роли специалистов при тестировании;

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

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

—активное участие в тестировании специалистов, различающихся по квалификации, опыту, темпераменту и творческим возможностям, а также различия архитектуры, сложности и функций отлаживаемых про-

362

13.1. принципы верификации и тестирования программ

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

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

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

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

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

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

363

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

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

Далее внимание сосредоточено на основных методах обеспечения

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

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

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

364

13.1. Принципы верификации и тестирования программ

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

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

Методы и стратегии тестирования программных компонентов

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

принципиально различных формах представления:

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

—в машинном коде конкретной ЭВМ (объектное представление), пригодном для автоматической обработки определенных кодовых исход­ ных данных и неудобном для их анализа человеком.

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

365

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

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

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

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

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

366

13.1. принципы верификации и тестирования программ

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

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

Совокупность спецификаций тестов может рассматриваться как вто-

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

367

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

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

Спецификация требований к функциям и качеству системы

Рис. 13.2

368

13.1. принципы верификации и тестирования программ

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

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

верификация спецификаций требований на программные компоненты и ПС могут использоваться с двумя целями (см. рис. 13.2):

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

вкомплексе программ;

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

369