ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 2571
Скачиваний: 13

Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 31 из 101
13 апреля 2011
© International Software Testing Qualifications Board
рассматриваться как риск. Бизнес-процессы могут включать
последовательность систем; могут быть важны кроссплатформенные
различия.
Чем больше объем интеграции, тем труднее становится изолировать дефекты
отдельного компонента или системы, которые могут привести к увеличению
рисков и требующих дополнительного времени для решения проблем.
Стратегии системного интеграционного тестирования могут основываться на
архитектуре системы (такой как нисходящая или восходящая), функциональных
задачах, последовательности обработки транзакций или других аспектах системы
и ее компонентов. Для того, чтобы упростить процесс изоляции отказа и как можно
раньше обнаруживать дефекты, интеграция должна проводиться по
возрастающей, а не происходить по сценарию «большого взрыва».
Тестирование специфичных нефункциональных характеристик ( например,
производительности), может быть включено в интеграционное тестирование,
наравне с функциональным.
На каждой стадии интеграции тестировщики концентрируют все внимание именно
на интеграции как таковой. Например, если интегрируется модуль А с модулем В,
они проверяют взаимодействие модулей, а не функциональность каждого из них,
т.к. она должна быть проверена во время компонентного тестирования. Для
тестирования могут использоваться как функциональный, так и структурный
подходы.
В идеале, тестировщики должны понимать архитектуру и ее влияние на
интеграционное планирование. Если интеграционное тестирование планируется
до разработки компонентов или системы, эти компоненты могут разрабатываться
в порядке, обеспечивающем наиболее эффективное тестирование.
2.2.3 Системное тестирование (K2)
Базис тестирования:
•
Система и спецификация требований к программному обеспечению
•
Сценарии использования
•
Функциональная спецификация
•
Отчеты об анализе степени риска
Типичные объекты тестирования:
•
Руководство по эксплуатации системы
•
Конфигурация системы
Конфигурационные данные
Системное тестирование сконцентрировано на поведении тестового объекта как
целостной системы или продукта. Область тестирования должна быть четко
определена в главном плане тестирования либо плане тестирования для
конкретного уровня тестирования.

Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 32 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Во время системного тестирования тестовое окружение должно быть как можно
ближе к предполагаемому эксплуатационному окружению системы для
минимизации риска пропуска отказов, связанных с эксплуатационным окружением
системы.
Системное тестирование может включать тесты, основанные на рисках или
спецификациях требований, бизнес-процессах, сценариях использование
системы, или других высокоуровневых текстовых описаниях или моделях
поведения системы, взаимодействия с ОС и системными ресурсами.
Системное тестирование должно заниматься исследованием функциональных и
нефункциональных требований к системе и качеством обрабатываемых данных.
Тестировщики также должны уметь выполнять свои обязанности в случае
неполных или недокументированных требований. Системное тестирование
функциональных требований начинается с тестирования на основе спецификаций
(тестирования методом черного ящика), для различных аспектов системы.
Например, таблица решений может быть создана на основе бизнес-правил
работы системы. Тестирование на основе структуры (тестирование методом
белого ящика) может использоваться для оценки тщательности тестирования
того или иного структурного элемента, такого как структура меню или навигация
веб-страницы ( см. Главу 4).
Системное тестирование чаще всего выполняет независимая тестовая команда.
2.2.4 Приемочное тестирование (K2)
Базис тестирования:
•
Пользовательские требования
•
Системные требования
•
Сценарии использования
•
Бизнес процессы
•
Отчеты об анализе степени риска
Типичные объекты тестирования:
•
Бизнес-процессы на полностью интегрированной системе
•
Процессы эксплуатации и обслуживания
•
Процедуры использования
•
Форы
•
Отчеты
Конфигурационные данные.
Приемочным тестированием системы чаще всего занимаются заказчики или
пользователи системы, а также другие заинтересованные лица.
Основная цель приемочного тестирования – проверка работоспособности
системы, частей системы или отдельных нефункциональных характеристик
системы. Поиск дефектов не является главной целью приемочного тестирования.

Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 33 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Приемочное тестирование оценивает готовность системы к развертыванию и
использованию, хотя это не обязательно самый последний уровень тестирования.
Например, крупномасштабные тесты по системной интеграции можно провести
именно во время приемочного тестирования системы.
Приемочное тестирование может проводиться в различные моменты ЖЦ
разработки, например:
•
Для коробочного продукта приемочное тестирование можно провести при
установке или интеграции
•
Приемочное тестирование удобства использования компонента можно
провести во время компонентного тестирования
•
Приемочное тестирование новой функциональности можно проводить до
системного тестирования
Типичные виды приемочного тестирования:
Пользовательское приемочное тестирование
Обычно проверяет готовность системы для использования в бизнесе.
Эксплуатационное (приемочное) тестирование
Приемочное тестирование, проводимое системными администраторами,
включает:
•
Тестирование резервного копирования \ восстановления
•
Восстановление после сбоев
•
Управление пользователями
•
Задачи сопровождения
•
Задачи загрузки и миграции данных
•
Периодическая проверка уязвимостей системы
Контрактное и правовое приемочное тестирование
Контрактное приемочное тестирование выполняется для проверки требований,
предъявляемых контрактом в к разрабатываемому ПО. Критерий приема должен
быть определен непосредственно в контракте. Приемочное тестирование на
соответствие стандартам выполняется для проверки соответствия стандартам
государственным, юридическим или стандартам безопасности.
Альфа и бета тестирование (или тестирование в условиях эксплуатации)
Разработчики рыночного, или коробочного, ПО часто хотят получить отзывы от
потенциальных или существующих заказчиков до того, как начнется продажа
продукта. Альфа тестирование выполняется организацией, разрабатывающей
продукт, но не группой разработчиков. Бета тестирование, или тестирование в
условиях эксплуатации, выполняется покупателями или потенциальными
заказчиками на их собственных мощностях.
В организации могут использоваться и другие термины приемочного
тестирования, такие как производственное приемочное тестирование и стороннее
приемочное тестирование для систем, которые проверяются до и после установки

Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 34 из 101
13 апреля 2011
© International Software Testing Qualifications Board
на стороне заказчика.

Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 35 из 101
13 апреля 2011
© International Software Testing Qualifications Board
2.3 Типы тестирования (K2)
40 минут
Терминология
Тестирование методом черного ящика, покрытие кода, функциональное
тестирование, тестирование взаимодействия, нагрузочное тестирование,
тестирование восстановления, тестирование производительности, тестирование
переносимости, тестирование надежности, тестирование безопасности, стресс
тестирование, структурное тестирование, тестирование удобства использования,
тестирование методом белого ящика.
Введение
Группы активностей тестирования могут быть направлены на проверку
работоспособности системы ( или части системы), принимая за основу различные
цели и причины для тестирования.
Типы тестирования определяются целями тестирования, которые могут быть
следующими:
•
Функция, выполняемая программой
•
Нефункциональная характеристика качества, такая как надежность или
удобство использования
•
Структура или архитектура программы или системы
Подтверждение изменений, т.е. подтверждение, что дефект был исправлен
(подтверждающее тестирование) и поиск непреднамеренных изменений
(регрессионное тестирование)
Модель программного обеспечения может быть разработана и\или использована
во время структурного (например, модель потока управления или модель
структуры меню), нефункционального тестирования например, модель нагрузки,
модель удобства использования, модель угроз безопасности) и функционального
тестирования ( например, модель бизнес-процессов, модель переходов состояний
или спецификация не естественном языке).
2.3.1 Тестирование функций (Функциональное тестирование) (K2)
Функции, которые выполняет система, подсистема или компонент, могут быть
описаны в таких артефактах процесса разработки как спецификация требований,
сценарии использования системы или функциональная спецификация, либо могут
быть недокументированны. Эти функции описывают, «что» эта система делает.
Функциональные тесты разрабатываются на основе функций и возможностей
системы (описанных в документах или понятных тестировщикам) и их
взаимодействия со специфичными системами и могут быть выполнены на всех
уровнях тестирования (например, тесты для компонентов могут основываться на
спецификациях компонентов).