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

Методологии и стандартизации оценки характеристик качества готовых программных средств и их компонентов (программного продукта) на различных этапах жизненного цикла посвящен международный стандарт ISO 14598.

Рекомендуется следующая общая схема процессов оценки характеристик качества программ:

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

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

· планирование и проектирование процессов оценки характеристик качества в жизненном цикле программного средства;

· выполнение измерений для оценки, сравнение результатов с критериями и требованиями, обобщение и оценка результатов.

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

Реализация процессов оценки должна коррелировать с этапами жизненного цикла конкретного проекта программного средства в соответствии с применяемой, адаптированной версией стандарта ISO 12207.

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

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

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

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

Оценка защищенности программных средстввключает определение полноты использования доступных методов и средств защиты программного средства от потенциальных угроз и достигнутой при этом безопасности функционирования информационной системы. Наиболее широко и детально методологические и системные задачи оценки комплексной защиты информационных систем изложены в трех частях стандарта ISO 15408:1999-1—3 «Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий».

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

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

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

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

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

4.3 Надежность программных средств

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

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

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

К основным количественным показателям надежности ПС относятся:

Вероятность безотказной работы – это вероятность того, что в пределах заданной наработки отказ системы не возникает. Наработка – продолжительность или объем работ.

Вероятность отказа – вероятность того, что в пределах, заданной наработки отказ системы возникает. Это показатель, обратный предыдущему.

Интенсивность отказа системы – это условная плотность вероятности возникновения отказа ПС в определенный момент времени при условии, что до этого времени отказ не возник. Если в процессе тестирования фиксируется число отказов за определенный интервал времени, то интенсивность – число отказов в единицу времени.

Средняя наработка до отказа – суммарное время безотказной работы до текущего момента, деленное на количество ошибок;

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

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

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

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

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

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

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

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

Наиболее широко используются:

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

2. критерий длительность восстановления — основной показатель процесса восстановления.

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

4.3.1 Дестабилизирующие факторы и методы обеспечения надежности функционирования ПС.

Верификация, тестирование и оценивание корректности программных компонентов (стр. 1 )

Из за большого объема этот материал размещен на нескольких страницах: 1 2 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13.2. Процессы и средства тестирования программных компонентов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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