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

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

344 Глава 7

- руководитель проекта;

- группа качества;

- группа тестирования;

- разработчики (аналитики и программисты);

- администратор базы данных.

Пользователи привлекаются к процессу тестирования для:

- согласования серьезности отказов и дефектов;

- регистрации отказов и дефектов при опытной эксплуатации;

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

оценки удобства применения и адекватности поддержки решения задач в ПрО.

Задача 1.3. Распределение обязанностей и формирование плана работы

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

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

ставлено в таблице 7.16. Распределение задач тестирования между членами группы опреде-

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

сценариев, проектов тестов осуществляет аналитик («архитектор тестов»), а выполнение

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

человек.

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

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

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

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

Требования к квалификации тестировщиков. Во многих организациях на

роль тестировщиков приглашаются специалисты с более низкой квалификацией,

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

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

рыми должен обладать идеальный тестировщик (по материалам сайта www.it-

online.ru/library):

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

угрызений совести;

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

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

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

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

другим тестировщикам и руководству);

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

• умение противостоять давлению (тестирование всегда является завер-

шающей стадией любого процесса разработки, и, как правило, проходит в стрессо-

вых условиях);

• способность быстро осваивать новые технологии;

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

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

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

• гибкость мышления – способность быстро переключиться на тестирование

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

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

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

умение сосредоточиться на деталях.

Глава 7 345

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

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

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

других областей.

7.5.3. Анализ риска

Теме анализа и управления рисками проекта разработки ПС посвящена от-

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

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

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

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

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

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

кратко описаны ниже петитом.

Задача 2.1. Идентификация риска.

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

циональных требований к ПС, характеристик ее размера и сложности, а также среды и ус-

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

и будущего функционирования ПС.

Помимо использования общих вопросов, предлагаемых в таксономии рисков (при-

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

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

Функциональность.

• Какие функции наиболее критические (важные)

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

ций?

Надежность.

• Определены ли типы и серьезность возможных отказов в ПС?

• Какие компоненты ПО могут вносить вклад в отказы системы? Могут ли отказы

привести к потере и разрушению данных?

• Какие процедуры восстановления предусмотрены в проекте?

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

интерфейсов со средой и др?

Удобство применения.

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

зователя и процедур обслуживания?

• Согласованы ли требования к интерфейсу между компонентами ПО?

• Будет ли группа тестирования принимать участие в проверке документации?

Производительность.

• Как распределены требования к производительности в системе по уровням? На

уровне администратора БД? На уровне сети? На уровне приложений?

• Какие функции ПО требуют высокой производительности?

• Какова относительная частота использования функций в приложениях?

Безопасность.

• Какие требования установлены к разграничению доступа к ПС?

Классификация критичности функций приведена в главе 6.

346 Глава 7

Для выявления потенциальных рисков, связанных с объемом и сложностью тести-

рования, рассматриваются вопросы, касающиеся характеристик ПС и условий ее эксплуата-

ции, например:

Сложность ПС.

• Какой предполагаемый размер и сложность ПС?

• Количество функций, входных (входных документов), их размер и др.?

• Какой объем выходных документов (результатов), их сложность?

Условия эксплуатации.

• Какое планируемое количество пользователей ПС? Будут ли они работать одновре-

менно?

• Можно ли прогнозировать скорость роста БД?

• Известны ли любые «пиковые нагрузки» системы?

Характеристики среды.

• Типы и разрешающая способность мониторов, на которых должна работать ПС?

• Типы ОС и их версий, типы и версии общесистемного ПО?

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

• Какие системные возможности будут использоваться?

• Будут ли они работать в новой версии?

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

сти процесса тестирования, например:

Требования и спецификации системы и ПО.

• Существуют ли требования и подробные спецификации?

• Описаны ли все функции ПО, форматы экранов, интерфейсы системы, все входы и

выходы системы? Доступна ли эта информация для группы тестирования?

• Участвует ли группа тестирования в анализе требований?

Модель разработки.

• Какая выбрана модель разработки?

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

тестов (по V-образной модели)?

• Если модель итерационная, то есть ли прототип или первая версия ПС, чтобы на-

чать планирование тестирования?

Проверки.

• Планируются ли внутренние действия по V&V: коллегиальные проверки, инспек-

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

Сроки.

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

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

Среда тестирования.

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

Процесс тестирования.

• Каким будет сам процесс тестирования?

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

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

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

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

Следующий шаг в идентификации рисков – определить вероятность и серьезность

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

две шкалы оценки.

Глава 7 347

Вероятность возникно-

вения (1-99%)

Описание серьезности проблемы

Низкая (1%-25%) Критическая – проблема требует немедленного решения,

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

дефекты в критических функциях не будут обнаружены.

Средняя (26% - 49%) Серьезная – может привести к тому, что важные тесты не

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

ны.

Значительная (50% - 74%) Значительная – может привести к задержке выполнения

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

Высокая (75% - 99%) Незначительная – может быть решена в ближайшее время.

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

Поскольку в условиях ограниченных ресурсов всеобъемлющее тестирование невоз-

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

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

ПО. Методы анализа риска, которые могут использоваться при идентификации отказов для

сложных систем, описаны в разделе 7.6.

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

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

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

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

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

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

вероятности отказа используется та же шкала, что и для проблем (см. рисунок 7.7).

Вероятность отказа может ассоциироваться с:

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

больше вероятность, что пользователь «столкнется» с необнаруженными дефектами.

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

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

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

сервере и др.).

Сложностью функции. Чем сложнее функция, тем больше дефектов может содер-

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

риваются в главах 8 и 9. Хотя сложность функции не повышает вероятности отказа, а связа-

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

ный риск отказа.

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

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

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

риском. Любые отказы в критических функциях рассматриваются как серьезные. Величина

риска отказа функции определяется по традиционной матрице рисков (глава 10).

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

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

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

Задача 2.2. Упорядочение рисков по приоритетам.

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

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

личины риска.

348 Глава 7

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

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

Проект: Версия: Дата анализа:

Идентифика-

тор риска

Описание потенции-

альной проблемы

Приоритет

устранения

Ответственный

за решение

Дата ре-

шения

Рис. 7.8. Форма описания риска проекта

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

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

риска, наряду с описанием факторов риска, например, как на рисунке 7.9.

Проект: X Версия: X.01 Дата анализа: 20.09.2006

Функция Наименование Риск отказа Описание риска

Ф1 Первичный ввод ин-

формации в БД для

формирования отче-

тов

высокий Функция часто используется.

Отказы могут привести к потере

данных, невозможности выпол-

нения других функций.

Ф2 Формирование не-

дельного отчета

высокий Отказы приведут к потере време-

ни персонала.

Ф3 Ведение канцелярии средний Отказы не затрагивают других

функций ПС.

Рис. 7.9. Пример таблицы риска отказа внешних функций ПС

Задача 2.3. Распределение ресурсов.

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

нии тестирования. Наиболее распространенный подход к распределению – правило Парето

(80/20), согласно которому 80% ресурсов должно выделяться на тестирование областей вы-

сокого и среднего риска, а 20% - низкого. Однако план выделения ресурсов должен регу-

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

ранних стадиях разработки.

Задача 2.4. Создание базы данных по оценке риска.

Результаты оценки рисков могут храниться в базе данных (или в таблице MS Excel) и

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

эффективностью процесса тестирования.

7.5.4. Определение целей тестирования

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

с каждым из которых ассоциируется критерий завершения тестирования. Задачи,

решаемые для определения целей, представлены ниже петитом:

Задача 3.1. Идентификация целей тестирования.

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

1. Идентификация функций. Составляется список всех внешних (пользовательских)

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

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

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

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

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

Глава 7 349

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

сов).

3. Идентификация программных компонентов ПС, которые будут тестироваться.

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

ристик, соотнесенных с компонентами ПС.

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

системы. Если разработка выполняется с помощью CASE-средств – из описания проекта в

их среде.

Задача 3.2. Определение критериев прохождения тестов.

После построения списка целей нужно определить критерий принятия решения о

достижении каждой из них (как узнать, что цель достигнута?). Критерии могут быть качест-

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

зультату выполнения тестов (проход/отказ). Количественные критерии основываются на

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

ся дефектов и интенсивности отказов.

Задача 3.3. Приоритезация целей тестирования.

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

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

7.5.5. Разработка плана тестирования

План тестирования определяется в стандарте IEEE Std. 829:1998 [11] как

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

тестирования. В нем указываются тестируемые объекты (элементы), характеристи-

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

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

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

тируемые элементы» применительно к любым объектам (модулям, компонентам,

подсистемам или системе) и «характеристики» применительно к любым тестируе-

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

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

Планы могут уточняться по мере разработки системы (например, при уточне-

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

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

Структура плана тестирования, рекомендуемая стандартом IEEE Std. 829,

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

речислены и в ДСТУ 2853-94 [4], однако структура плана не представлена.

Идентификатор плана

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

Введение

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

также уровень плана (автономное, интеграционное и пр.). Здесь же указывают ссылки на

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

Тестируемые элементы

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

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

средствам или требования к инсталляции объекта перед началом его тестирования. Указы-

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

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

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

350 Глава 7

Тестируемые характеристики

Указывают все тестируемые характеристики и их комбинации. На следующем шаге про-

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

характеристикой и каждой комбинацией характеристик.

Не тестируемые характеристики

Указывают, что не будет тестироваться и почему (например, переносимость системы).

Подход

Описывают общий подход к тестированию. Для каждой группы характеристик или их

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

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

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

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

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

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

время безотказного функционирования). Кроме того, указывают методы, применяемые для

трассировки требований. Идентифицируют существенные ограничения, такие как степень

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

Критерии прохождения теста

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

или не прошел тестируемый объект каждый тест.

Критерии приостановки и возобновления тестирования

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

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

Документирование результатов тестирования

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

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

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

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

Задачи тестирования

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

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

Среда тестирования

Указывают нужную аппаратно-программную конфигурацию и инструменты.

Обязанности

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

Вопросы кадров и их подготовки

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

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

Календарный план

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

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

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

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

и предпринимаемые меры по их уменьшению.

Утверждения

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

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

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

описаны ниже петитом.

Глава 7 351

Задача 4.1. Разработка плана приемочных испытаний системы.

Согласно стандарту ISO/IEC 12207 планирование приемочных испытаний не связано

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

и проведения.

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

пользователей, администраторов системы (сети, БД), персонала сопровождения (развития).

Задача 4.2. Разработка плана тестирования системы.

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

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

ссылки на соответствующие планы.

В плане должны быть указаны все объекты тестирования:

- все внешние функции и компоненты ПО, упорядоченные по приоритетам тести-

рования;

- требуемые конфигурации аппаратных и программных платформ;

- требуемые интерфейсы с другими системами;

- документация потребителя;

- учебные материалы.

Все планируемые виды тестирования, в порядке приоритета важности:

- функциональное;

- надежности;

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

- конфигурации;

- безопасности;

- восстановления;

- регрессионное.

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

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

Задача 4.3. Разработка плана тестирования ПО.

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

В плане должны быть отражены цели функционального тестирования ПО:

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

- описание интерфейса пользователя (форматы экранов, меню и т.д.);

- характеристики производительности, распределенные по компонентам ПО;

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

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

- все сообщения об ошибках, формируемые ПО;

- возможные области неустойчивого функционирования (граничные значения);

все таблицы БД.

Задача 4.4. Разработка плана интеграционного тестирования.

Этот план разрабатывается на основе плана интеграции ПО и должен отражать пере-

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

Планирование тестирования включает следующие действия:

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

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

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

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

ты имеют эти интерфейсы (графические интерфейсы), то в план должно быть включено

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

разной разрешающей способности экрана.

352 Глава 7

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

Планирование автономного тестирования включает следующие действия:

- идентификация функций ПО, реализуемых в компоненте ПО;

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

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

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

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

данные, генераторы данных);

- определение граничных значений;

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

функционального покрытия);

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

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

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

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

- перечень внесенных изменений;

- перечень тестов, которые должны быть выполнены повторно;

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

требованиями (новые тесты);

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

функции, интерфейсы, компоненты, в которых были обнаружены и устранены ошибки).

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

ненных тестов: тесты проверки последних изменений в ПО, тесты, при выполнении кото-

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

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

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

ботку ПС. Утвержденные планы передаются группе управления конфигурацией (кроме

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

7.5.6. Разработка тестов

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

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

петитом.

Задача 5.1. Определение подходов к разработке тестов.

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

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

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

дут отслеживаться при тестировании (таблица риска отказов внешних функций). В таблице

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

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

Таблица 7.17. Применение подходов/методов на уровнях тестирования

Метод/подход Автоном-

ное

Интегра-

ционное

ПО Сис-

темное

Методы структурного тестирования + +

Эвристические + +

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

Функциональные диаграммы + + +

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

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

Разбиение на категории + + +

Глава 7 353

Метод/подход Автоном-

ное

Интегра-

ционное

ПО Сис-

темное

Тестирование переходов состояний + + + +

Тестирование по спецификациям + + +

Предположение об ошибке + + +

Мутационное тестирование +

Случайное тестирование + +

Операционный профиль +

Тестирование по сценариям + +

Определение требований к полноте охвата функций. Для каждой функции устано-

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

Задача 5.2. Проектирование и разработка тестов.

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

сценариев тестирования, в соответствии с выбранными стратегиями.

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

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

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

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

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

Структура этого документа, рекомендуемая IEEE Std. 829, приведена ниже.

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

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

Тестируемые характеристики

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

тываемые данным проектом. Для каждой характеристики (или комбинации) указывают

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

Уточненный подход

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

тестов (например, применение утилит сравнения файлов, визуальная проверка), критерии

подтверждения выполнения тестов. Указывают общие характеристики любых наборов тес-

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

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

Идентификация тестов

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

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

сании проекта. Перечисляют идентификаторы и краткое описание каждой процедуры, свя-

занной с данным проектом.

Критерии прохождения тестов

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

рактеристика или их комбинация тесты.

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

тов, связанных с проектом тестов. Структура этого документа, рекомендуемая стандартом

IEEE Std. 829, приведена ниже.

Идентификатор теста

Уникальный идентификатор набора тестов

Тестируемые элементы

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

го элемента указывают ссылки на соответствующую документацию.