Липаев В.В. Сертификация программных средств. Учебник

Подождите немного. Документ загружается.

Лекция

10.

Сертификационные испытания...

281

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

обнаруженные причины несоответствия и подтвердить без повторных

испытаний в аккредитованной лаборатории, соответствие продукта

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

то действие сертификата отменяется, и лицензия на право примене-

ния знака соответствия аннулируется. Информация о приостановле-

нии или отмене действия сертификата доводится органом по серти-

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

гих заинтересованных организаций.

Программа и методики испытаний комплексов

программ на соответствие требованиям

Успешная и рентабельная Программа испытаний требует ясно-

го видения целей и четкого понимания различных параметров и/или

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

испытаний может ориентироваться на тестирование только конечного

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

качества или на последовательные, поэтапные испытания укрупняю-

щихся программных компонентов, усложнение тестов и объектов

внешней среды - рис. 10.2. Подробное изучение системных требо-

ваний или сценариев использования системы вместе с тщательным

определением параметров Программы испытаний и требований к тес-

там необходимы для эффективного тестирования продукта. Планиро-

вание и реализация испытаний - не единовременный акт, а процесс.

Эффективная Программа испытаний, включающая в себя ав-

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

свой собственный жизненный цикл, в который входят планирова-

ние стратегий и целей, определение требований к тестам, анализ,

проектирование и кодирование тестов.

По аналогии с процессом, которому следуют при разработке

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

прежде, чем они будут спроектированы. Ресурсы Программы испы-

таний ограничены, а способов тестирования систем много. Пред-

ставление работ по испытаниям в графической форме, позволяет спе-

циалистам оценивать границы и масштаб Программы тестирования.

282

В.В.

Липаев.

Сертификация программных

средств

Поэтапная автоматизация испытаний

сложных комплексов программ

Исходные

данные

Этапы испытаний

Результаты

Сценарии и

тесты для

испытаний

компонентов

всташке

Сценарии и

динамические

тесты от

имитаюров

для испытании

в реальном

времени

Сценарии и

гесты от

онераюрови

реальных

объектов

внешней

среды

Рис.

10.2

Испытания

программных компонентов

автономно в статике

Испытания групп

программных компонентов

в статике с другими

компонентами

Испытания функциональных

программных компонентов

в реальном времени

Испытания программного

продукта по данным

имитаторов внешней

среды

Испытания программного

продукта при реальных

воздействиях от

операторов- пол ьзователей

Заключительные

испытании программного

продукта

BHCU1H

в реальной

ей среде

Проверенные

в статике

программные

компоненты с

оценкой

характеристик

качества

Компоненты и

комплекс

программ,

испытанные по

данным

имитаторов в

реальном

времени

Программный

продукт,

испытанный в

i реальной

внешней среде

н реальном

времени

Лекция

10.

Сертификационные испытания...

283

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

моделей реализации и оформлению Программы, которая в графиче-

ской форме описывает ее масштаб. Структуру Программы испытаний

обычно представляют двумя способами.

Один метод организации тестовых процедур, известный как ар-

хитектура тестирования на базе архитектуры системы, разбивает

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

тектуры, по логическому принципу приоритетов в ее иерархии. Вто-

рой метод архитектуры тестирования на базе выбранных методов

связывает тестовые процедуры с различными методами испытаний,

представленными в модели Программы тестирования.

Оценивание качества и соответствия требованиям программ-

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

которой участвует руководитель (главный менеджер) разработки и

некоторые ведущие разработчики, или аттестованной сертификаци-

онной лабораторией. Комиссия при испытаниях должна руково-

дствоваться следующими документами (см. рис. 10.1):

• утвержденными заказчиком и согласованными с разработчи-

ком контрактом, техническим заданием и спецификациями требова-

ний на программный продукт и систему;

• действующими государственными и ведомственными стан-

дартами на жизненный цикл и испытания крупных комплексов про-

грамм, на технологическую и эксплуатационную документацию, а

также стандартами де-факто, согласованными с заказчиком для ис-

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

• Программой испытаний по всем требованиям контракта, тех-

нического задания и спецификаций;

• методиками испытаний и матрицей тестов, охватывающими

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

Программы испытаний;

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

документации на программный продукт.

Кроме того, в документе должны быть представлены план-

график тестирования и матрица трассирования тестов к требова-

ниям спецификаций на программный продукт или на его функцио-

нальные компоненты, а также субподрядчики, принимающие участие

в тестировании, их роль и ответственность.

284

В. В.

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

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

должна разрабатываться с позиции необходимого объема тестирова-

ния в процессе проведения испытаний для проверки выполнения всех

требований технического задания и соответствия предъявленной до-

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

ки результатов, разработанные совместно заказчиком и разработчи-

ком, должны быть согласованы и утверждены. Они должны содер-

жать уточнения и детализацию требований технического задания

и спецификаций для данного программного продукта, а также гаран-

тировать корректную проверку всех заданных функций и характе-

ристик качества. Программа испытаний должна содержать еле-

дующие четко сформулированные разделы:

• объект испытаний, его назначение и перечень основных до-

кументов, определивших его разработку;

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

задания, характеристик качества, подлежащих проверке, и ограниче-

ний на проведение испытаний;

• собственно Программу испытаний, содержащую проверку

комплектности спроектированного программного продукта в соот-

ветствие с техническим заданием, план и график проведения тестиро-

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

ния и дополнительных требований, формализованных отдельными

решениями разработчиков и заказчика;

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

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

ва, условия и сценарии тестирования, инструментальные средства,

используемые для испытаний;

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

ния по каждому разделу Программы испытаний.

Методика испытаний

должна

содержать:

описание организации и

матрицу процесса тестирования, тестовые варианты, сценарии и процеду-

ры,

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

компонента или комплекса программ в целом. Каждый тест должен иметь

уникальный для данного проекта идентификатор; должны быть представ-

лены инструкции для проведения процедур тестирования; описание аппа-

ратуры и инструментальные средства для реализации тестирования, а так-

же инструкции для динамического и регрессионного тестирования. Кроме

того,

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

Лекция

10.

Сертификационные испытания,..

285

требования, указаны условия выполнения (конфигурация аппаратуры и

компонентов комплекса программ), входные данные, эталонные и ожи-

даемые результаты, критерии оценки качества результатов, процедура

проведения тестирования для каждого тестового варианта, допущения и

ограничения.

Большой объем разнородных данных, получаемых при испыта-

ниях крупных комплексов программ, и разнообразие возможных спо-

собов их обработки, интерпретации и оценки приводят к тому, что

важнейшими факторами становятся методики обработки и оценки

результатов, а также протоколы проверки по пунктам Програм-

мы испытаний. В соответствии с методиками испытаний, средства

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

ристик по каждому разделу методик. Результаты испытаний фик-

сируются в протоколах (см. стандарт ISO 12119 и

рис.

10.1),

ко-

торые обычно содержат следующие разделы:

• назначение тестирования и раздел требований технического

задания, по которому проводились испытания;

• указания разделов методик в соответствии, с которыми про-

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

• условия и сценарии проведения тестирования и характерис-

тики исходных данных при динамическом испытании;

• обобщенные результаты испытаний с оценкой их на соответс-

твие требованиям технического задания и другим руководящим до-

кументам, а также технической и эксплуатационной документации;

• описание отличий тестовой и реальной эксплуатационной

среды;

• описание обнаруженных дефектов и ошибок и рекомендуе-

мых улучшений в испытываемом комплексе программ;

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

программного продукта или его функционального компонента опре-

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

спецификаций.

Протоколы по всей программе испытаний обобщаются в акте,

в результате чего делается заключение о соответствии системы

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

или отрицательным итогом. При выполнении всех требований техни-

ческого задания заказчик обязан принять программный продукт, и

проект считается завершенным.

286

В.

Я Липаев. Сертификация программных средств

Испытания надежности функционирования

программного продукта

В составе требований к системам и программным продуктам,

функционирующим в реальном времени, особое значение имеют ди-

намические функции и характеристики. Для обеспечения их высо-

кого качества недостаточны отдельные сценарии и процедуры тестов,

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

времени, адекватные соответствующим данным при функционирова-

нии внешней среды систем и/или пользователей (см. рис. 10.1). Эти

потоки тестов должны обеспечивать динамическую проверку ком-

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

и ошибок в реализации их функций и характеристик в реальном вре-

мени. Основная особенность такого тестирования состоит в создании

динамической среды функционирования программного продукта,

максимально приближенной к реальной, при его практическом при-

менении.

Задача состоит в определении соответствия требованиям, функ-

ций и характеристик программного продукта при различной интен-

сивности потоков тестов, адекватных нормальным условиям приме-

нения программного продукта, а также критическим по составу и ин-

тенсивности, для выявления предельных условий его работоспособ-

ности. Такие условия тестирования отражаются на интеграль-

ных характеристиках, на снижении надежности и/или безопасно-

сти,

а также на повышении рисков применения программного про-

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

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

производительности, вследствие дефектов и ошибок, а также при

формировании и реализации требований к этим характеристикам

программных продуктов. Эти взаимосвязанные характеристики каче-

ства программного продукта зависят от одних и тех же свойств воз-

действий из внешней среды, требуют совместного анализа и методов

для выявления и устранения дефектов. Локализация и устранение та-

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

времени, путем применения детерминированных сценариев и тесто-

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

Оценивание надежности программных комплексов включает

измерение количественных характеристик: завершенности, устойчи-

вости к дефектам, восстанавливаемости и доступности-готовности

Лекция

10.

Сертификационные испытания...

287

(см.

лекцию 7). При этом предполагается, что в контракте, техниче-

ском задании или спецификации требований зафиксированы, и ут-

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

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

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

ваниями и для оценивания рисков соответствия этим спецификация-

ми требований. Тестирование для оценки надежности комплекса про-

грамм должно проводиться в тестовом окружении, которое макси-

мально приближено к реальным условиям применения системы.

Входные параметры тестов следует задавать на основе вероятностно-

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

при эксплуатации программного продукта, исходя из частоты воз-

можных сценариев работы пользователей или системы.

Значения надежности коррелированны с характеристикой кор-

ректность, однако можно достигать высокую надежность функциони-

рования комплекса программ при относительно невысокой их кор-

ректности за счет сокращения времени восстановления при отказах.

Кроме того, надежность можно оценивать косвенно в процессе раз-

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

тов и ошибок, а также по плотности выявляемых и устраняемых оши-

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

ционирования комплекса программ. Степень покрытия тестами

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

целом может служить ориентиром для прогнозирования их потен-

циальной надежности. Распределение реальных длительностей и

эффективности восстановления при ограниченных ресурсах для

функционирования программ, может рассматриваться как дополни-

тельная составляющая при оценивании надежности.

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

мы инструментальные средства, встроенные

операционную систему

или в соответствующие компоненты комплекса программ. Эти сред-

ства должны в динамике функционирования программного продукта,

автоматически селектировать и регистрировать аномальные ситуа-

ции,

дефекты и искажения вычислительного процесса, программ и

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

тролем или пользователями. Накопление и систематизация проявле-

ний дефектов при исполнении программ позволяет оценивать основ-

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

288

В. В.

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

отказов и подготавливать данные для повышения надежности про-

граммных продуктов.

Прямые экспериментальные методы оценивания интеграль-

ных характеристик надежности (безопасности и рисков) программ-

ных продуктов, в ряде случаев весьма трудно реализовать при нор-

мальных штатных условиях функционирования крупных комплексов

программ, из-за больших значений времени наработки на отказ (сот-

ни и тысячи часов), которые необходимо достигать при разработке и

фиксировать при испытаниях. Сложность выявления и регистрации

редких отказов, а также высокая стоимость экспериментов при дли-

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

программ приводят к тому, что на испытаниях получаются малые вы-

борки зарегистрированных отказов и низка достоверность оценки на-

дежности. Кроме того, при таких экспериментах трудно гарантиро-

вать полную представительность выборки исходных данных, так как

проверки определяются конкретными условиями применения данно-

го программного продукта на испытаниях.

При испытаниях надежности в первую очередь обнаруживаются

отказы - потери работоспособности. Однако в большинстве слу-

чаев первоначально остается неизвестной причина происшедшего от-

каза. Для выявления фактора, вызвавшего отказ (первичной ошибки

или дефекта) и устранения его причины, необходимо, прежде всего,

определить, каким компонентом системы стимулирован данный от-

каз.

Наиболее крупными источниками отказов являются частичные

физические неисправности или сбои аппаратуры ЭВМ, а также де-

фекты и ошибки программных продуктов. Стабильные неисправно-

сти аппаратуры диагностируются достаточно просто, соответствую-

щими аппаратными тестами, после чего должен следовать ремонт или

замена определенных блоков. Однако при возникновении случайного

отказа, после которого происходит автоматически полное восстанов-

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

однозначно выявить его первичный источник, особенно при очень

редких отказах.

Для диагностики и устранения случайных редких отказов долж-

на быть организована служба их регистрации с максимально пол-

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

каждый. Сбои в аппаратуре носят более или менее случайный харак-

тер и полное повторение отказовой ситуации маловероятно. Ошибки

Лекция

10.

Сертификационные испытания...

289

и дефекты программ содержатся в определенном месте и должны ре-

гулярно проявляться при полном повторении внешних ситуаций. На

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

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

причине. Для повышения надежности при высокой наработке на от-

каз необходима тщательная, систематическая работа специалистов,

накапливающих, регистрирующих и анализирующих все отказовые

ситуации при функционировании комплекса программ. Эти специа-

листы должны также регистрировать все проведенные корректировки

для прогнозирования причин появления возможных, дополнительных

источников отказов, вызванных дефектами корректировок.

Для выявления тенденции изменения показателей надежно-

сти, их зарегистрированные значения необходимо связывать во вре-

мени с моментами корректировки программ. Анализируя корреляцию

между значениями надежности и процессом изменения программ,

можно выявлять некоторые корректировки, которые содержат ошиб-

ки и снижают надежность. Получающиеся при этом показатели по-

зволяют прогнозировать число ошибок, подлежащих исправлению

для достижения требуемых значений надежности в зависимости от

длительности испытаний. В результате может быть оценена наработ-

ка

до следующего выявления ошибки или отказа.

При заключительных приемо-сдаточных и сертификационных

испытаниях для достоверного определения надежности организу-

ются многочасовые и многосуточные прогоны динамического функ-

ционирования комплекса программ в реальной

и/или

имитированной

внешней среде в условиях широкого варьирования исходных данных

с акцентом на стрессовые ситуации, стимулирующие проявления уг-

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

характеристики надежности и определять степень их соответствия

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

ских условиях

документации на программный продукт.

Если интенсивное тестирование программ в течение достаточно

длительного времени не приводит

обнаружению дефектов или оши-

бок, то у специалистов, ведущих испытания, создается ощущение

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

он передается на эксплуатацию. Экспериментальное исследование ха-

рактеристик сложных ПС позволило оценить темп обнаружения

дефектов - риски, при котором крупные программные продукты

290

В. В.

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

передаются на регулярную эксплуатацию: 0,002-0,005 дефектов в

день на человека, т.е. специалисты по испытаниям или все пользо-

ватели в совокупности выявляют только около одной ошибки или де-

фекта каждые два - три месяца использования ПС. Интенсивность

обнаружения ошибок ниже 0,001 ошибок в день на человека, т.е.

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

средственно выполняющих динамическое квалификационное тести-

рование

и/или

эксплуатацию комплекса программ, по-видимому, мо-

жет служить эталоном высокой надежности обработки информа-

ции.

Если динамическое функционирование программного продукта

происходит непрерывно, то эти показатели соответствуют высокой

наработке на обнаружение дефекта или отказа порядка 5-10 тысяч ча-

сов и коэффициенту готовности выше 0,99. При использовании этого

критерия обычно учитывается календарное время испытаний, вклю-

чающее длительность непосредственного тестирования, как для обна-

ружения, так и для локализации дефектов, а также длительность кор-

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

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

Форсированные (стрессовые) испытания для оценивания на-

дежности, а также функциональной безопасности и рисков про-

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

тодов испытаний аппаратуры. Основными факторами, влияющими на

надежность ПС, являются исходные данные и их взаимодействие с

дефектами и ошибками программ или сбоями

аппаратуре ЭВМ. По-

этому форсирование испытаний надежности осуществляется повы-

шением интенсивности искажений исходных данных и расширением

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

сивности потоков информации и загрузки программ на ЭВМ выше

нормальной.

Планирование форсированных динамических испытаний долж-

но предусматривать последующий пересчет полученных значений

надежности на условия нормального функционирования. Для этого

необходимо оценивать надежность испытываемых программ в зави-

симости от интенсивности искажений данных или от характеристик

перегрузки ЭВМ, а также применять способы корректного пересчета

получаемых показателей на нормальные условия эксплуатации. При

форсированных испытаниях целесообразно выделять следующие ре-

жимы тестирования: