К программному средству

К эксплуатационной и технологической документации требованиям

Верификация соответствия спецификации требований

Требованиям к программному средству

К технологическому обеспечению жизненного цикла программ

Верификация соответствия спецификации требований

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

ВЕРИФИКАЦИЯ, ТЕСТИРОВАНИЕ И ОЦЕНИВАНИЕ КОРРЕКТНОСТИ ПРОГРАММНЫХ КОМПОНЕНТОВ

ЛЕКЦИЯ 13

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

Назначение верификации ПС — последовательно проверить, что в реализованном комплексе программ (рис. 13.1):

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

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

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

	Верификация соответствия спецификации требований к программному средству требованиям к информационной системе
	у
	Верификация соответствия архитектуры комплекса программ требованиям к программному средству
	f
	Верификация соответствия спецификаций требований к функциональным компонентам требованиям к программному средству
	?
	Верификация соответствия спецификаций требований к программным и информационным модулям требованиям к функциональным компонентам
		'
	Верификация соответствия объектного кода программ спецификациям требований к модулям

Рис. 13.1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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