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

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

Лекция

Организация сертификационных

испытаний.,.

221

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

вышение их качества, сокращение дефектов, ошибок, неоднозначно-

стей и противоречий.

Потребности заказника и

пользователей;

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

функциям и характеристикам

системы

Верификация спецификации

фебованнй к upoi раммному

продукту па coo'iiicrcTJUic

требованиям к

функциям и характеристикам

СИС1СММ

Верификации спецификаций

требований к функциональным

компоисп

гам на

соответствие

|+.

|ребовапиям к программному

продукту

Верификация полноты и

коррекiнос

i и

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

и сценариев иегов на

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

функциям и характеристикам

системы

Верификация политы и

коррекi пост спецификации

и сценариев гесюв комплекса

itpoipaMM

на

COOIBCICIBIIC

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

продукту

Тестирование комплекса

про!

рамм на

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

программному продушу

Рис. 8.3

Спецификации тестов должны обеспечивать дополнительный

контроль корректности спецификаций требований и верификацию

взаимодействия компонентов на соответствующем уровне описания

222

В. В.

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

комплекса программ. Независимая разработка спецификаций тестов

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

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

быть проверены тестированием. Таким образом, верификация спе-

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

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

целями:

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

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

программ;

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

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

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

сом программ.

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

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

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

ции спецификаций требований к тестам сверху вниз, а также сами

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

требованиям к компонентам текстов программ разного уровня (см.

рис.

8.3).

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

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

явлению и исключению множества вторичных дефектов и ошибок

комплексов программ. Впоследствии, эти спецификации тестов

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

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

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

стороны, спецификаций программ и спецификаций тестов, а также их

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

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

программ.

Реализация этих целей верификации и тестирования может про-

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

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

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

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

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

Лекция 8.

Организация

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

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

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

грамм, существенно отличаются от представлений и методов

описаний тех же функций комплекса программ тестировщиками

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

вания.

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

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

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

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

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

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

ошибок в сценариях и реализациях тестов и в описаниях требований к

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

Испытания на базе верифицированных требований к тестам

должно обеспечивать качество комплексов программ. Такие сценарии

предназначены для поэтапной проверки внутренней непротиворечи-

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

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

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

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

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

для последующего тестирования и применения (рис. 8.4). Последова-

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

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

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

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

ваний, так как обычно эти работы проводятся частично вручную и

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

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

характеристикам и требованиями к тестам системного уровня может

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

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

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

224

В. В.

Липаев.

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

1 *

•*

**»

•е-

•»•

ова

1 v

И"

-Q

я я з

* i 8.

2 Е

Я 2 **•

5 Я А

§-1

О р> U

к© о

Й с-

д О SO в

*»

Я 2 с

^ 2

Лекция 8.

Организация

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

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

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

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

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

продукта.

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

системы, разбитые на составные части на уровне спецификации

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

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

мо-сдаточных испытаний.

Матрица отслеживания требований тестами позволяет

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

мы,

а также покрытие требований тестовыми процедурами. Матрица

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

ных видах отображений. Матрица отслеживания требований должна

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

также метод его верификации. Матрица отображает тестовые проце-

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

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

использования системы, проверенные при тестировании, успешно

реализованы.

Тестовое покрытие - это отображение пространства варьиро-

вания тестов на некоторую совокупность требований к функциям и

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

ченных для тестирования. Покрытие можно отражать с помощью

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

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

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

[5,6].

При этом можно отсле-

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

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

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

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

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

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

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

ряя,

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

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

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

226

В. В.

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

плекса программ. Точность определения степени покрытия ограниче-

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

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

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

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

Таким образом, совокупности требований к тестам могут при-

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

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

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

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

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

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

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

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

сти или ограниченным рискам системы. Например, покрытие полной

структуры решений для некоторых функций может быть необходимо

в аэрокосмических и других критических системах с повышенными

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

Стратегии и планирование испытаний

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

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

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

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

работки программного продукта высокого качества. Ведущий испы-

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

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

использующие план, четко понимали, что от них требуется: страте-

гию тестирования, планирование и использование ресурсов, управле-

ние конфигурацией проекта и минимизацию рисков (рис. 8.5). При

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

следующие рекомендации [8].

Тестирование в первую очередь следует проводить для тре-

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

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

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

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

ний, и ресурсы это позволяют, естественно, проверить выполнение

Лекция 8.

Организация

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

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

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

требования с наивысшими приоритетами. Целесообразно получить

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

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

держиваться вплоть до следующей версии продукта.

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

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

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

го качества;

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

ний с наивысшим приоритетом, которые наиболее важны, либо

могут причинить наибольшие неприятности;

- сначала испытания следует осуществлять для новых функ-

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

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

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

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

тель или система;

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

вать:

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

темы и пользовательских данных;

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

• для покрытия критических пробелов в тестовом покрытии;

• функциям, наиболее значимым для работы системы, и

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

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

ние требований, отслеживание связей, оценку рисков требова-

ний

тестам.

Рис. 8.5

Тестирование сначала осуществлять для новых функцио-

нальных

возможностей,

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

или совершенствования функций и характеристик. Если версия

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

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

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

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

228

В. В.

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

изменениями. В этом случае лучше всего как можно шире следует

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

комплекса программ, какими бы ни были изменения.

Тестирование следует проводить тех компонентов и уча-

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

дефектов.

Если

обнаружен какой-то дефект, часто рядом может быть еще несколько

аналогичных дефектов. Если есть сведения от разработчиков, что

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

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

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

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

ях.

Тестирование желательно начинать с функций и конфигу-

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

пользователь или система. Для этого в спецификации требований

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

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

пользователя - математическому ожиданию использования каждой

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

приоритетов тестирования. Большая часть времени, отведенного на

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

пользуемых функций, конфигураций и операций.

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

программ должна содержать последовательные процессы:

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

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

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

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

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

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

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

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

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

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

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

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

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

повышенного риска наличия дефектов;

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

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

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

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

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

белов в тестовом покрытии [5, 6].

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

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

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

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

темы и/или описание назначения системы для того, чтобы лучше по-

нять цель ее разработки. Еще один шаг — определение функций,

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

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

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

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

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

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

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

одно требование к тестам на каждое системное требование.

Управление требованиями к тестам включает в себя хране-

ние требований, отслеживание связей, оценку рисков требований к

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

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

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

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

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

Заказчик и разработчики должны анализировать и, в конечном

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

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

соответствия системных требований и тестовых сценариев [6].

Матрица соответствия должна содержать информацию о требовани-

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

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

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

этими требованиями. Оно предполагает, что процессы тестирования,

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

вание организованы и эффективно применяются. Когда план испыта-

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

230

В. В.

Липаев.

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

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

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

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

изменений требований к тестам, фиксирует параметры Программы

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

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

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

готовить тестовую среду. Испытатели должны определить требо-

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

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

Нужно спланировать работы по приобретению, установке и настрой-

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

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

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

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

полняться.

План испытаний должен определять объем работ по испытани-

ям.

Обычно выстраивают структуру работ, в которой на одном

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

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

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

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

вания должен отражать оценки затрат на тестирование. Оценка за-

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

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

ленного объема работ выделяется конкретный срок.

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

трудников, необходимых для проведения испытаний [7]. Состав

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

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

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

чтобы определить возможные направления обучения. Также необхо-

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

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

дукта.

Любая Программа испытаний должна иметь определенные рам-

ки,

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

по графику. В плане тестирования также следует отражать допуще-