авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |   ...   | 11 |

«Институт системного программирования Российской академии наук В.В. Липаев ЭКОНОМИКА ПРОИЗВОДСТВА ПРОГРАММНЫХ ПРОДУКТОВ ...»

-- [ Страница 8 ] --

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

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

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

План тестирования должен определять объем работ по тестиро ванию [3, 9, 29]. Обычно выстраивают структуру работ, в которой на одном уровне определяются категории работ по тестированию, а на другом уровне подробные описания работ. Структура детализа ции работ используется в сочетании с хронометражем для определе ния времени выполнения каждого из этапов тестирования. Кроме то го, план тестирования должен отражать оценки затрат на тестиро вание. Оценка затрат может определять число сотрудников группы тестирования в проекте в часах или в количестве людей, если на вы полнение определенного объема работ выделяется конкретный срок.

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

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

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

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

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

В ходе разработки тестовых процедур группа тестирования должна проводить конфигурационное управление и контроль для тестовых сценариев и тестовых данных, а также для каждой отдель ной тестовой процедуры. Группы тестовых процедур и сценариев многократного применения обычно хранятся в списке или библиотеке тестовых данных – в тестовом архиве. Необходимо создавать базовые версии тестового архива при помощи инструментов конфигурацион ного управления (см. главу 2.6). Группа тестирования должна состав лять график разработки и выполнения тестовых процедур, чтобы оп ределить время и ресурсы, на эти работы. При подготовке графика [10]:

• назначаются специалисты, ответственные за выполнение ка ждой из работ по тестированию;

• следует учитывать последовательность разработки тестов, их взаимозависимость и связь с процессами и компонентами ЖЦ ком плекса программ;

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

• тестовые процедуры могут быть объединены в группы в соот ветствии с функциями программного продукта;

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

• в структуре тестовых процедур следует учитывать и докумен тировать их приоритеты и риски;

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

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

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

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

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

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

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

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

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

Планирование тестирования комплексов программ должно поддерживать:

• разработку множеств тестов на основе их проектирования сверху вниз, используя цели тестов, анализ рисков, требования к функциям и характеристикам комплекса программ;

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

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

Планирование тестирования функций и характеристик комплекса программ должно содержать – рис. 2.10 [9, 12]:

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

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

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

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

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

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

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

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

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

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

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

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

Глава 2. ТЕСТИРОВАНИЕ ПРИ ПРОИЗВОДСТВЕ ДИНАМИЧЕСКИХ ЗАКАЗНЫХ ПРОГРАММНЫХ ПРОДУКТОВ Подготовка динамических тестов для тестирования заказных программных продуктов Требования и реализация совокупности динамических тестов должны полностью обеспечивать возможность проверки выполне ния утвержденных требований к программному продукту, и соот ветственно должны быть адекватны по сложности и трудоемкости, производству такого программного комплекса. Эти два представле ния комплексов программ (требования и тесты) отличаются только формой описания их содержания: функциональным (процессным) или событийным (сценариями и результатами исполнения) (см. главу 2.2). Генерация тестов особенно сложна (также как и требований к программному продукту) для крупных заказных динамических ком плексов программ реального времени. Выбор типов моделей генера ции тестов зависит от глубины знаний об алгоритмах функциониро вания комплексов программ, требований к характеристикам их каче ства и обобщенных параметрах необходимых результатов примене ния системы в целом. Кроме того, существенным для выбора типов моделей для генерации динамических тестов может быть длитель ность расчета имитированных тестовых данных и обеспечение воз можности проводить полную обработку результатов тестирования.

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

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

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

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

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

• задачи автоматизированного формирования динамических тестов внешней среды;

• оценки методов автоматизации разработки динамических тес тов в реальном времени;

- компоненты генераторов динамических тестов внешней среды в реальном времени:

• исходные данные для генерации тестов внешней среды;

• состав средств для формирования тестов внешней среды;

- обработку результатов динамического тестирования комплексов программ в реальном времени:

• средства оперативной обработки результатов динамического тестирования комплексов программ реального времени;

• средства оценки характеристик комплекса программ и систе мы реального времени;

- оценки эффективности динамической генерации тестов в реальном времени:

• оценки затрат на программную имитацию динамических тес тов;

• оценки экономической эффективности программной имитации тестов.

Рис. 2.12.

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

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

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

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

Другие генераторы могут извлекать информацию о документирован ных требованиях из архивов программных комплексов и создавать тестовые процедуры автоматически [3, 9, 35, 44].

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

• определение и формирование динамических тестов реали зацию процесса тестирования разработчиком: ввод тестовых наборов;

генерацию тестовых данных;

ввод ожидаемых, эталонных результа тов;

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

• управление тестами и участком программы, для которого средство тестирования может автоматически выполнять тестовые на боры;

• анализ и обработку тестовых результатов возможность средства тестирования автоматически анализировать части тестовые результаты: сравнение ожидаемых и реальных результатов;

сравне ние файлов;

статистическую обработку результатов;

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

процедур, которые не были вызваны;

данных, к которым не были обращения;

• анализ производительности комплекса программ, когда он исполняется: загрузку центрального процессора;

загрузку памяти;

об ращения к специфицированным элементам данных и/или сегментам кода;

временные характеристики функционирования испытываемой программы;

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

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

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

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

• внешних, динамических потоков информации, в том числе, их распределение по видам источников, характеристикам качества данных и возможности их дефектов;

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

• возможных негативных и несанкционированных воздействий от внешней среды при применении программного комплекса;

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

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

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

Программная имитация динамических тестов внешней сре ды на компьютере в реальном времени позволяет [29, 33]:

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

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

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

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

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

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

объектов систем проти вовоздушной обороны;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приведенные выше рекомендации по функциям и применению МИС ориентированы на создание сложных заказных программных комплексов, их динамическое тестирование и испытания, в основном, до передачи в регулярную эксплуатацию. После приемки заказчиком или приобретения пользователями, в процессе функционирования и применения программного комплекса должно обеспечиваться их ре гулярное тестирование и оценка текущего качества. Для этого в со ставе программного продукта необходимы средства, обеспечи вающие [9, 20, 35]:

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

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

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

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

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

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

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

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

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

Селекция результатов динамических испытаний может осно вываться на стратегии контроля функционирования программного комплекса снизу вверх, т.е. от анализа исполнения отдельных компо нентов программы и далее до стохастических результатов функцио нирования всего комплекса в динамике реального времени. При этом регистрируется избыточное количество данных, из которых затем от бирается минимум, необходимый для анализа. Может использоваться стратегия сверху вниз, т.е. упорядоченное, иерархическое выделение в первую очередь обобщенных результатов функционирования ком плекса программ с последующим уточнением регистрируемых и ана лизируемых результатов вплоть до детального контроля исполнения отмеченных программных компонентов. В этом случае регистриру ются только те данные, которые необходимы для анализа в конкрет ном сеансе динамического тестирования. При обеих стратегиях необ ходимо иметь возможность управлять объемом и видом выделяемой и регистрируемой информации тестирования в зависимости от целей испытаний. Данные, получаемые и выделяемые в процессе испыта ний качества комплекса программ, целесообразно делить на следую щие группы [20, 33, 35] :

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

• маршруты исполнения программных компонентов и их опе раторов при некоторых фиксированных тестовых данных;

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Задача состоит в определении соответствия требованиям, функ ций и характеристик программного комплекса при различной интен сивности потоков тестов, адекватных нормальным условиям приме нения программного комплекса, а также критическим по составу и интенсивности, для выявления предельных условий его работоспо собности. Такие условия тестирования отражаются на инте гральных характеристиках, на снижении надежности и/или безо пасности, а также на повышении рисков применения программного комплекса. Для комплексов программ реального времени особое зна чение могут иметь причины и методы уменьшения рисков надеж ности и производительности, вследствие дефектов и ошибок, а также при формировании и реализации требований к этим характери стикам. Эти взаимосвязанные характеристики качества программных комплексов зависят от одних и тех же свойств воздействий из внеш ней среды, требуют совместного анализа и методов для выявления и устранения дефектов. Локализация и устранение таких динамических дефектов обычно осуществляется вне реального времени, путем при менения детерминированных сценариев и тестовых процедур, а ино гда за счет изменения требований заказчика [17, 35,44].

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

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

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


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

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

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

Если интенсивное тестирование программ в течение достаточно длительного времени не приводит к обнаружению дефектов или ошибок, то у специалистов, ведущих испытания, создается ощущение бесполезности дальнейшего тестирования программного продукта, и он передается на эксплуатацию. Экспериментальное исследование характеристик сложных КП позволило оценить темп обнаружения дефектов – риски, при котором крупные программные продукты передаются на регулярную эксплуатацию: 0,0020,005 дефектов в день на человека, т.е. специалисты по испытаниям или все пользова тели в совокупности выявляют только около одной ошибки или де фекта каждые два три месяца использования КП. Интенсивность обнаружения ошибок ниже 0,001 ошибок в день на человека, т.е.

меньше одной ошибки в год на трех-четырех специалистов, непо средственно выполняющих динамическое квалификационное тести рование и/или эксплуатацию комплекса программ, по-видимому, мо жет служить эталоном высокой надежности обработки информа ции. Если динамическое функционирование программного продукта происходит непрерывно, то эти показатели соответствуют высокой наработке на обнаружение дефекта или отказа порядка 5 10 тысяч часов и коэффициенту готовности выше 0,99.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• загрузку вычислительной системы функционирующими про граммами;

• значения интенсивности потоков данных для обработки от конкретных внешних абонентов;

• длительность исполнения типовых заданий при реализации конкретных функций;

• характеристики функционирования устройств ввода/вывода;

• время ожидания результатов (отклика) на функциональные задания пользователей или системы;

• заполнение памяти обмена с внешними абонентами в различ ных режимах применения программного комплекса.

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

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

При использовании комплексом программ производительности и памяти реализующем компьютером менее чем на 50%, разработчик может практически не учитывать эти ограничения и сопутствующие риски. Закономерным является стремление разработчиков программ применять, особенно для систем реального времени, встроенные объ ектные компьютеры с предельным использованием их технических характеристик. Опыт создания программ реального времени позво ляет утверждать, что практически невозможно использовать произво дительность объектного компьютера более чем на 95%, и почти все гда целесообразно ограничиваться на уровне 80 90%, так как иначе, затраты на разработку программного комплекса могут значительно увеличиться. Для оценивания характеристик использования произво дительности при тестировании крупных программных продуктов должны быть измерены:

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

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

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

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

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

Для корректного оценивания предельной пропускной способ ности системы с данным программным комплексом необходимо из мерять следующие характеристики реализации функциональных про грамм в процессе разработки:

• экстремальные значения длительностей их исполнения и маршруты, на которых эти значения достигаются;

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

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

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



Pages:     | 1 |   ...   | 6 | 7 || 9 | 10 |   ...   | 11 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.