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

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

Лекция 8. Организация сертификационных испытаний,.. 231

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

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

мешать выполнению испытаний в срок. С разработкой плана должно

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

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

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

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

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

тирования.

Требования к тестам должны заноситься в базу данных и/или

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

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

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

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

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

или сценариев использования системы. После определения требова-

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

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

будут проверять каждое требование.

Необходимо, чтобы испытатели как можно раньше получили

информацию о матрице отслеживания требований от конечных поль-

зователей или заказчиков системы. Это способствует достижению со-

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

или контроль каждого требования. Принятие этого решения особенно

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

тратами времени. Раннее получение информации по матрице от за-

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

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

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

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

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

системы.

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

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

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

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

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

вой среды должно тщательно планироваться. При составлении плана

232

В. В.

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

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

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

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

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

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

ного тестирования.

К ключевым элементам планирования испытаний относится

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

тации. Группа тестирования должна исчерпывающе документиро-

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

изучить содержание этих планов. Эти специалисты должны получить

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

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

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

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

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

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

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

пользования системы.

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

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

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

ботка программистами тестируемых текстов программ. Чтобы до-

биться максимального эффекта от автоматизации тестирования, ис-

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

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

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

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

тестов.

Анализ полноты покрытия тестами требований при ис-

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

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

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

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

элементы структуры программы, которые не проверены тестовыми

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

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

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

Лекция 8. Организация сертификационных испытаний... 233

ко полно тестирование проверило реализацию всех требований, и по-

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

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

водиться его верификация. При тестировании реализации требований

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

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

90%

и хорошо, если составляет

около

80%

[5, 6].

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

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

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

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

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

руководствуясь этим принципом, можно оценивать, какое время

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

та тестов при создании очередной версии программного продукта.

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

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

та,

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

полнения различных тестов (графики Ганта). План-график определяет

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

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

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

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

ми.

Результаты этого анализа помогут выявить независимые компо-

ненты, спланировать зависимости между тестами и выделить общие

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

вания последующих версий. Для этого строится матрица связей, ко-

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

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

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

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

минимуму объем работ по созданию и сопровождению версий тесто-

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

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

троль для тестовых сценариев и тестовых данных, а также для каж-

дой отдельной тестовой процедуры.

Испытатели должны определить время и ресурсы на эти рабо-

ты.

При подготовке графика:

234

В. В.

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

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

дой из работ по испытаниям;

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

взаимозависимость и связь с процессами и компонентами ЖЦ ком-

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

• сокращаются или исключаются возможные конфликты ме-

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

ваны;

• тестовые процедуры могут быть объединены в группы в со-

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

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

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

работ;

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

докумен-

тировать их приоритеты и риски.

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

ков отвечает за выполнение конкретного вида работ. Составив де-

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

группа испытателей сможет избежать дублирования работ. Модель

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

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

стройку тестовых процедур, чтобы убедиться, что проведение этих

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

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

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

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

рует нужные данные. График разработки и выполнения тестовых

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

личные циклы обработки, относящиеся к комплексу программ. Необ-

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

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

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

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

торые могут порождать конфликты.

При группировании автоматизированных тестовых про-

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

Программу и план испытаний и тестовые сценарии с целью проверки

того,

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

Лекция

Организация

сертификационных испытаний... 235

не-графике. При составлении графика разработки и выполнения тес-

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

своенные различным тестам. График тестирования должен уделять

большее внимание проверке функций, наиболее значимых для про-

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

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

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

необходимости, для регрессионного тестирования.

Группа испытателей должна отслеживать изменения требований

и тестов и соответственно обновлять график

испытаний.

Имея в ви-

ду многообразие возможных изменений, требующих уточнения

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

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

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

с помощью систем отслеживания графиков.

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

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

возможно на основе обобщения статистических данных ряда предше-

ствующих проектов [4, 18]. В данном случае, задача ограничена толь-

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

рые целесообразно учитывать в процессе испытаний. Этот перечень

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

пытаний. Обычно наиболее важным для реализации проекта и зави-

сящим от большинства его особенностей и факторов является трудо-

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

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

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

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

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

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

таться практически неизменной. Многократное применение одних и

тех же апробированных компонентов и/или многократная адаптация

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

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

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

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

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

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

программных продуктов (рис. 8.6).

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

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

версии программного продукта включают следующие этапы:

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

должны быть выполнены;

• оценка трудозатрат на решение отдельных задач и всего

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

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

дачи

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

• затраты на обеспечение требований надежности и безопас-

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

• построение подробного расписания и поэтапного графика

решения каждой тестовой задачи;

• оценка рисков невыполнения графика работ и формули-

ровка планов их снижения;

- затраты на сопровождение и корректировки дефектов версий

программных продуктов включают:

• затраты на тестирование для обнаружения и устранения

ошибок и дефектов в каждой версии программного про-

дукта;

• оценка затрат на устранение выявленных ошибок при фор-

мировании очередной версии;

• затраты на доработку и совершенствование программ,

формирование и испытание новых модернизированных

версий;

• затраты на конфигурационное управление, тиражирование

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

новых системах;

- затраты на завершающие испытания программного продукта в

целом.

Рис.

8.6

Затраты труда и времени, необходимых для квалификационного

тестирования могут составлять существенную часть стоимости про-

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

проводило достаточное число специалистов и у них было достаточно

Лекция 8. Организация сертификационных испытаний... 237

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

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

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

Определение перечня и состава задач испытаний, которые

должны быть выполнены. Эта оценка начинается с определения ра-

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

программного продукта считалось состоявшимся. На этом этапе мо-

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

задачи, отражающие проверку реализации конкретных требований к

функциям и характеристикам комплекса программ. Если используют-

ся менее формальные методы, то результатом этого этапа может быть

простой список основных задач.

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

цесса испытаний. Каждая задача, выявленная на первом этапе, требу-

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

собой объем работ, необходимых для выполнения соответствующей

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

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

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

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

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

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

граммного продукта, на параметры ЭВМ и технологию проекти-

рования. Одним из наиболее важных компонентов планирования

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

мых для его выполнения. Затраты на тестирование реализации тре-

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

существенную часть стоимости проекта, при этом жизненно важно

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

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

венное выполнение задач по корректировкам комплекса программ.

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

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

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

длительности всего квалификационного тестирования. Время, необ-

ходимое для решения задачи, измеряется в днях, неделях или меся-

цах. Время, необходимое для выполнения той или иной задачи, зави-

сит от количества исполнителей, однако эта зависимость не обяза-

238

В. В.

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

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

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

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

торые задачи можно решать параллельно

одновременно с другими.

Построение подробного расписания и поэтапного графика ре-

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

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

диаграммы Ганта [5, 17] и вычислить сумму наиболее важных трудо-

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

Оценка рисков невыполнения графика работ и формулировка

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

ки,

которые могут возникнуть при решении задач в запланированные

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

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

ленных шагов, важно учитывать, насколько точными могут

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

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

от окончательной, фактической стоимости примерно в два раза. При

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

достигать 30 - 40% от полной трудоемкости создания комплекса про-

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

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

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

торинг и периодическое возвращение к оценке трудозатрат и графика

выполнения тестирования, и считать это неотъемлемой частью орга-

низации работ по испытаниям.

Затраты на обнаружение и устранение дефектов и ошибок в

программе определяются двумя

факторами',

затратами на обнаруже-

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

при формировании очередной версии. Чем меньше ошибок в про-

грамме, тем труднее они обнаруживаются, т.е. тем выше затраты на

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

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

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

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

грамм и обеспечения их сохранности. По опыту работ, широко тира-

жируемый комплекс программ объемом - 10

строк, может требовать

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

Лекция 8. Организация сертификационных испытаний... 239

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

документации [7, 18].

Затраты на завершающие испытания программного продук-

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

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

заказчик и пользователи. Величина этих затрат, без учета ресурсов,

необходимых для моделирования динамической внешней среды, мо-

жет составлять около 10-15% от общих затрат труда и 10% времени

на разработку программного продукта. При этом практически невоз-

можно разделять затраты на оценивание реализации отдельных тре-

бований и характеристик.

Возрастание относительных затрат всех видов при квалифика-

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

времени (СРВ) обусловлено высокой трудоемкостью динамической

отладки и тестирования в реальном времени. При этом следует учи-

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

СРВ приблизительно в 5 раз выше, чем программ административных

систем (АС) [3, 18]. Относительная трудоемкость и длительность при

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

тельно одинакова и составляет 8 -10% от совокупных затрат на раз-

работку. Однако абсолютная трудоемкость для испытаний АС также

приблизительно в 5 раз меньше, чем программ СРВ. При этом следу-

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

5 раз, абсолютная длительность этого процесса сокращается всего в

1,5 - 1,7 раза. В результате полная длительность отладки и испыта-

ний программ АС также приблизительно в полтора раза меньше, чем

программы СРВ того же размера.

Затраты на обеспечение требований надежности и безо-

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

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

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

критических программных продуктов эти затраты могут в 2 - 3 раза

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

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

граммных средств защиты обычно составляет 20 - 40% затрат на ре-

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

доля таких затрат может снижаться до 5 - 10%. Затраты на обеспече-

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

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

пасности, и, в составе разработки, они могут достигать 2-3 кратного

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

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

в ординарных системах, затраты составляют порядка 10 - 20%. Одна-

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

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

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

Затраты па сопровождение и корректировки дефектов вер-

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

чающими составляющие (см. рис. 8.6):

• затраты на тестирование для обнаружения и устранения оши-

бок и дефектов в каждой версии программного продукта;

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

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

• затраты на конфигурационное управление, тиражирование

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

темах.

Доля каждой составляющей в общих затратах на сопровождение

может значительно изменяться в зависимости от особенностей сферы

применения и жизненного цикла конкретного программного продук-

та. Для долгоживущих (~ 10 лет), многократно тиражируемых (1000 -

100000 экземпляров) комплексов доминирующими обычно являются

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

та.

Затраты па совершенствование и модернизацию комплексов

программ близки по содержанию (но не по величине) к затратам на

их первичную разработку. Модернизация обычно производится по-

этапно. Для каждой новой версии изменяется (разрабатывается) толь-

ко некоторая часть от всего объема программного продукта. Экспе-

риментально установлено, что эта часть при вводе очередной версии

обычно составляет 10 - 20% от объема всего комплекса [4]. Слож-

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

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

быть в 2 - 3 раза больше, чем затраты на создание программ такого

же объема при разработке первой версии. Эта величина зависит от

того,

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

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

грамм. Затраты на модернизацию зависят от тиража косвенно, вслед-