Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

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

314 Глава 7

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

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

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

му числу ошибок, содержащихся в программе. Если выявлены все внесенные

ошибки, то считается, что, либо набор тестов достаточен, либо, что эти ошибки бы-

ло слишком легко найти.

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

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

цией», для имитации ошибки в операторе или операнде, не отражающееся на син-

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

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

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

также обнаружены ранее не выявленные ошибки). Для того чтобы метод был эф-

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

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

5. Методы, основанные на анализе ожидаемого использования.

К этой категории в [7] отнесено два основных метода:

• статистическое тестирование;

• тестирование по операционному профилю.

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

тестов выбираются из входного пространства в соответствии с частотой их появ-

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

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

(Mean Time Between Failure), обычно в единицах процессорного времени (CPU) или

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

сти и предсказания момента завершения тестирования [18]. Метод применяется на

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

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

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

гии инженерии надежности (SRE, от Software Reliability Engineering) и называется

методом SRET (от Software Reliability Engineered Testing). Методология SRE охва-

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

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

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

функций, режимов и последствий отказов систем при эксплуатации [17, 32].

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

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

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

пользователя и разработке по ним сценариев тестирования (test-cases). Этот метод

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

тестирования программ, имеющих интерфейс пользователя (инструменты Capture-

Replay). Он также используется в популярной методологии RUP (Rational Unify

Process) [33], согласно которой сценарии тестирования формируются на этапе ана-

лиза и проектирования по набору «бизнес-сценариев» (use-cases).

Глава 7 315

Обобщением данного метода можно считать тестирование на базе моделей

(model-based testing, model-driven testing), применяемое в рамках соответствующего

подхода к разработке (model-driven development) [34].

Такие известные подходы к тестированию как тестирование, основанное на

риске (risk-driven testing, risk-based testing), представляют не методы разработки

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

тов. Эти стратегии подобны тестированию по операционному профилю, но прово-

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

использования, но и величину риска отказа ПС.

6. Методы, учитывающие специфику программной системы.

Рассмотренные выше методы универсальны и применимы к любым типам

ПС. Однако они не учитывают характерных особенностей построения систем раз-

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

Руководствуясь рекомендациями SWEBOK 2004 года, мы далее кратко оха-

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

• тестирование объектно-ориентированных программ;

• компонентное тестирование;

• тестирование Web-приложений;

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

• тестирование протоколов на соответствие;

• тестирование систем реального времени;

• тестирование критических систем.

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

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

наиболее подходящих для определенных объектов тестирования.

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

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

стей, а в 7.3.8 подробнее остановимся на тестировании Web-приложений.

Тестирование объектно-ориентированных программ (ООП). Тестирова-

нию ООП посвящено достаточно литературы, например [31, 33, 35, 36].

Специфика тестирования ООП связана, в первую очередь, с:

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

ложнению интеграционного и регрессионного тестирования;

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

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

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

структуры и методов (функций-членов) класса традиционными методами, основан-

ными на коде.

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

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

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

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

ных моделей выступают модель классов ПО и модели каждого класса.

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

(use-cases) – начиная с анализа требований и проектирования ПС.

Основные методы (подходы) тестирования ООП перечислены в таблице 7.1.

316 Глава 7

Таблица 7.1. Основные методы тестирования ООП

Задача тестирования Методы/подходы

Разработка тестовых на-

боров (test-case)

Тестирование, основанное на ошибках (шаблонах ошибок)

Тестирование, основанное на сценариях использования

Тестирование внутренней

структуры класса

Стохастическое тестирование классов

Эквивалентное разбиение на уровне класса

Таблицы решений

Тестирование взаимодей-

ствия классов

Стохастическое тестирование классов

Эквивалентное разбиение на уровне классов

Тестирование переходов между состояниями

Парадигма компонентного программирования (глава 2) и компонентная

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

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

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

- процесс разработки ПС из компонентов (фактически сборки) отделен от

процесса разработки самих компонентов;

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

адаптацию и тестирование;

- основные усилия в ЖЦ сосредоточены на интеграции («встраивании») ком-

понентов в ПС.

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

- тестирование компонента в изоляции (автономное);

- тестирование в процессе сборки;

- системное тестирование.

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

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

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

ных конфигурациях сред.

В наибольшей мере специфика компонентного тестирования проявляется в

процессе сборки компонентов. Например, возможны проблемы несовместимости

разных компонентов (или их версий). Помимо этого, требуется тестирование свя-

зующего кода, который, собственно, и формирует ПС.

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

нального тестирования. Специфика их применения для данного типа ПС проявля-

ется в сложности поиска причин ошибок, особенно, если ошибка, обнаруженная в

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

ность контрактных интерфейсов, которые обеспечивают спецификацию входов и

выходов компонента и делают возможной проверку корректности данных [37].

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

тремя основными факторами: моделью ЖЦ, спецификой объектов (архитектурой

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

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

Тестирование графического интерфейса пользователя всегда включает

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

ставления (например, Windows), а также тестирование конфигурации (на разных

типах мониторов). Процесс планирования и проектирования тестов систематизиру-

Глава 7 317

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

интерфейсу, подлежащие проверке.

Тестирование протоколов. Бурное развитие сетевых технологий, усложне-

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

увеличивают число интерфейсов, подлежащих тестированию.

В работе [38] рассмотрены следующие задачи тестирования протоколов:

- тестирование соответствия (аттестационное);

- тестирование производительности;

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

- тестирования взаимодействия;

- тестирование функциональности;

- мониторинг.

Тестирование на соответствие заданной спецификации – это стандартизиро-

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

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

лизированный язык написания тестов TTCN [38]. Стандартизация подходов к тес-

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

циями ETSI, ITU-T и ISO. Основной документ - стандарт ISO 9646:1994 [39].

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

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

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

чений параметров спецификации. Поэтому наряду с ним необходимо проведение и

остальных перечисленных видов тестирования.

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

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

эталонную. Для имитации эталонной системы, с которой должно стыковаться тес-

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

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

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

руемую систему с эталонной. Подробнее эти вопросы рассмотрены в [38].

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

в виде формальной модели. Поэтому на модульном уровне применяются формаль-

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

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

является тестирование переходов между состояниями (state transition testing) [36].

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

Тестирование критических систем включает не только динамические, но и

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

тичности, анализ деревьев событий и деревьев отказов [40] (кратко рассмотрен-

ные далее в этой главе), а также инспекции документов и исходного кода. Для ми-

нимизации стоимости тестирования и риска отказа в ходе анализа ПС выделяются

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

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

318 Глава 7

7.3.2. Исследовательское тестирование

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

граммы и обнаружения в ней ошибок одновременно. Эти методы применяются в

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

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

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

среде Windows, предложены в [41].

Процедура включает следующие шаги.

Шаг 1. Исследование. Изучение назначения и функций программного про-

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

(факторов риска отказа).

Успех выполнения шага зависит от наличия информации о программном

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

Для получения информации о продукте может использоваться документация (в том

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

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

1. Формирование списка функций (иерархии функций).

2. Разбиение функций на основные и второстепенные. В таблице 7.2 приве-

ден пример критерия разбиения – по важности.

3. Выявление областей возможной неустойчивости продукта (подвержен-

ных отказам функций и данных).

Таблица 7.2. Пример разбиения функций на основные и второстепенные

Определение Критерии отнесения

Основная функция – любая внешняя функ-

ция (видимая пользователю), отказы в ко-

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

своему назначению.

1. Функции, являющиеся определяющими

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

нию.

2. Функции, часто используемые обычными

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

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

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

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

Второстепенная функция – функция, без

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

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

выполнении которых не могут иметь суще-

ственных последствий.

Примеры областей возможной неустойчивости функций:

- функции обработки внешних событий;

- функции, интенсивно использующие оперативную память;

- очень сложные функции;

- функции, использующие средства Windows и/или изменяющие ее пара-

метры (настройки параметров);

- функции, манипулирующие конфигурацией Windows;

- функции анализа входных данных и обработки ошибок;

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

новление удаленных файлов);

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

цессов;

Глава 7 319

- функции, работающие со многими файлами одновременно;

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

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

- документы: длинные, много одновременно открытых;

- записи: длинные, много записей, пустые, сложные;

- списки: длинные, пустые или многоколоночные;

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

словых полей;

- объекты: много, крупные, сложные и др.

Шаг 2. Проектирование тестов. Определение стратегий выполнения тестов

и критериев оценивания результатов (как, например, в таблице 7.3).

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

Определение цели Критерий прохода Критерий отказа

Функция выполняется в

соответствии с ее назначе-

нием.

Хотя бы одна функция не

выполняется в соответствии

с ее назначением.

Функциональность – спо-

собность продукта выпол-

нять требуемые функции.

Любое неправильное вы-

полнение функции не при-

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

ствиям при корректном ис-

пользовании.

Неправильное выполнение

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

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

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

Устойчивость – способ-

ность продукта функциони-

ровать без отказов при по-

вышенных нагрузках (по

времени, памяти).

Работа продукта при повы-

шенных нагрузках не при-

водит к разрушению Win-

dows.

Работа продукта не приво-

дит к потере данных, зави-

санию, отказу.

При тестировании не было

обнаружено отказов или

любых дефектов при вы-

полнении основных функ-

ций.

Работа продукта разрушает

Windows.

Работа продукта может

привести к потере данных,

зависанию, отказу.

При тестировании хоть од-

ной из основных функций

наблюдались отказы.

Шаг 3. Выполнение тестов. Выполнение тестов, наблюдение и фиксация ре-

зультатов и использование этой информации для формирования мнения о работе

продукта. Задачи шага:

- тестирование всех основных функций;

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

вости;

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

- регистрация отказов;

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

Шаг 4. Построение эвристик. Эвристики представляют неформальные пра-

вила (основанные на опыте тестировщика и здравом смысле) принятия решения о

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

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

320 Глава 7

Шаг 5. Определение критерия покрытия. В данной процедуре используется

следующий критерий покрытия:

- протестированы все основные функций;

- протестированы выбранные второстепенные функции;

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

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

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

Рекомендуемое распределение времени тестирования: 80% времени – на ос-

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

устойчивости.

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

7.3.3. Эквивалентное разбиение

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

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

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

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

вительные (с наибольшей вероятностью обнаружения ошибки).

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

ваться на следующих практических критериях [8]:

- тесты включают значения одних и тех же входных данных;

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

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

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

бок, либо все тесты вызывают выполнение этого блока (в предположении, что про-

грамма вообще содержит блоки обработки ошибок).

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

ности, представляющие правильные входные данные и входные события (события-

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

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

зоваться табличной формой (ее пример дан в таблице 7.4).

При выделении классов эквивалентности можно руководствоваться рядом

общих правил:

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

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

пустимых (в таблице их пять);

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

чество чего-либо (например, от 1 до 20), то определяется один допустимый класс

эквивалентности (1<= X <= 20) и ряд недопустимых (X < 1 и X > 20);

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

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

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

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

сутствующих в перечне). В этом случае граничные значения не определяются;

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

ню, кнопки панели инструментов) представляет отдельный класс эквивалентности.

Глава 7 321

Таблица 7.4. Пример описания классов эквивалентности

Входные события Допустимые классы

эквивалентности

Недопустимые классы эквива-

лентности

Ввод числа Числа от 0 до 9000 Числа меньше 0 и числа больше 9000

Пробел

Нечисловые символы

Вычисляемое выражение, результат

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

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

Ввод первой буквы

фамилии

Первый символ должен

быть заглавной буквой

Первый символ строчная буква

Первый символ – не буква

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

затем – для недопустимых:

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

класса (например, если параметр программы содержит список, нужно из списка

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

чений в диапазоне от 1 до 100, выбрать 1, 100 и любое число внутри диапазона);

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

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

словой символ).

7.3.4. Анализ граничных значений

По этому методу тесты разрабатываются для направленного тестирования

границ классов эквивалентности. Если область входных данных класса представля-

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

ложенные на нижней и верхней границах диапазона. Если диапазон дискретный

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

тимые элементы.

При этом анализируются также все выходные классы эквивалентности - ожи-

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

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

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

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

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

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

строки отчета).

Отличие данного метода от метода эквивалентного разбиения состоит в сле-

дующем:

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

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

этого класса;

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

ожидаемые результаты.

322 Глава 7

7.3.5. Разбиение входного пространства на категории

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

ность шагов.

Шаг 1. Декомпозиция функции на функциональные элементы, которые мо-

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

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

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

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

функциональному признаку [42].

Шаг 2. Идентификация параметров и условий среды, влияющих на поведение

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

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

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

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

мых элементов и др., а условиями среды – файлы, поля таблицы базы данных и др.

Реальные тесты для функционального элемента представляют собой компо-

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

максимизации шансов поиска дефектов в реализации элемента.

Шаг 3. Выделение категорий информации, характеризующей каждый пара-

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

кой) параметра или условия среды. В приведенном выше примере параметров и

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

категории:

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

держание, обязательность и др.;

- для условия среды «окно» - категории координаты, цвет окна, цвет сим-

волов, рамка и др.

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

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

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

Шаг 4. Разбиение каждой категории на четкие альтернативы, которые

включают различные виды значений, возможные для категории. Альтернативы яв-

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

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

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

фейса пользователя.

Шаг 5. Формирование формальной спецификации теста для каждого функ-

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

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

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

реальных тестовых наборов. Фрейм теста состоит из множества выделенных аль-

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

вой (или нулем). Построенная спецификация теста практически не ограничена, по-

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

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

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

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

Глава 7 323

Таблица 7.5. Пример разбиения на категории и альтернативы

Параметр Категория Альтернативы

Поле выбора Содержание Текст

Пиктограмма

Значок с текстом

Состояние Поле не указано/выбрано

Поле не указано/не выбрано

Поле указано/выбрано

Поле указано/не выбрано

Тип поля Однозначный выбор

Многозначный выбор

Расширенный выбор

Меню Способ выбора Выбор курсором

Выделенная буква/(комбинация букв)

Функциональная клавиша

Выбор с помощью клавиатуры

Типичное ограничение указывает на то, что альтернатива из одной категории

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

других категорий.

Шаг 6. Генерация тестовых фреймов. Поскольку процесс формирования тес-

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

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

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

рии.

Шаг 7. Преобразование тестовых фреймов в тестовые наборы и разработ-

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

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

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

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

мента.

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

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

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

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

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

мых, граничных, недопустимых).

Этот метод обладает рядом очевидных достоинств:

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

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

лее уязвимых частях программы;

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

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

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

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

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

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

тирования;