ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 2576
Скачиваний: 13
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 26 из 101
13 апреля 2011
© International Software Testing Qualifications Board
LO-2.4.3. Описать роль регрессионного тестирования и анализа его воздействия в
период сопровождении (K2)
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 27 из 101
13 апреля 2011
© International Software Testing Qualifications Board
2.1 Модели разработки ПО (K2)
20 минут
Терминология
Коробочный программный продукт(COTS), итеративно-инкрементальная модели
разработки ПО, валидация, верификация, V-модель
Введение
Тестирование не является изолированным процессом, работы по тестированию
связаны с другими работами по разработке ПО. Различные модели разработки
ПО требуют различных подходов к тестированию.
2.1.1 V-модель (Последовательная модель разработки) (K2)
Хотя разновидностей V- модели существует много, все они используют четыре
уровня тестирования, соответствующие четырем уровням разработки.
Четыре уровня, используемые в данном пособии, это:
•
Компонентное (модульное) тестирование
•
Интеграционное тестирование
•
Системное тестирование
•
Приемочное тестирование
На практике V-модель может иметь большее или меньшее количество уровней
разработки и тестирования, все зависит от конкретного проекта и
разрабатываемого продукта. Например, компонентное интеграционное
тестирование может проводиться после компонентного, а системное
интеграционное после системного.
Артефакты программной разработки (такие как бизнес-сценарии или сценарии
использования, технические требования, документы по дизайну и код)
создающиеся во время процесса разработки часто используются для одного и
более уровней тестирования. Ссылки на оригинальные рабочие артефакты
можно найти в «Интегрированной модели зрелости процессов производства ПО»
(CMMI) и «Жизненном цикле программного обеспечения» (IEEE/IEC 12207).
Верификация и валидация (а также ранняя разработка тестов) могут быть
выполнены во время разработки ПО.
2.1.2 Итеративно-инкрементные модели разработки (K2)
Итеративно-инкрементный процесс разработки – это процесс, основывающийся
на требованиях, дизайне, сборке и тестировании системы, созданной в результате
серии коротких циклов разработки. Примеры: прототипирование, быстрая
разработка приложений (RAD), Rational Unified Process (RUP) и гибкие (agile)
методологии разработки. Система, получаемая в результате итерации, может
быть протестирована на нескольких уровнях в процессе разработки каждой
итерации. Доработка, добавляемая к разработанному ранее, провоцирует
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 28 из 101
13 апреля 2011
© International Software Testing Qualifications Board
расширение системы, которое также должно быть протестировано. Регрессионное
тестирование становится все более и более важным от итерации к итерации.
Верификация и валидация могут выполняться на каждом этапе доработки
системы.
2.1.3 Тестирование в модели ЖЦ ПО (K2)
В любой модели ЖЦ ПО имеется несколько характеристик качественного
тестирования:
•
Каждому процессу разработки соответствует свой процесс тестирования
•
Каждый уровень тестирования имеет свои цели тестирования
•
Анализ и дизайн тестов для какого-либо уровня тестирования должны
начинаться одновременно с соответствующей деятельностью
разработчиков
•
Тестировщики должны быть вовлечены в процесс просмотра и
рецензирования документов, как только становятся доступными их
предварительные версии.
Уровни тестирования могут быть объединены или реорганизованы в зависимости
от природы проекта или архитектуры системы. Например, для интеграции
коробочного продукта в какую-либо систему заказчик может выполнить
интеграционное тестирование на уровне системного тестирования (например,
интеграция с инфраструктурой и другими системами или развертывание системы)
и приемочного тестирования ( функциональное и\или нефункциональное, и
пользовательское и/или эксплуатационное).
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 29 из 101
13 апреля 2011
© International Software Testing Qualifications Board
2.2 Уровни тестирования (K2)
40 минут
Терминология
Альфа тестирование, бета тестирование, компонентное тестирование, драйвер,
тестирование в условиях эксплуатации, функциональные требования, интеграция,
интеграционное тестирование, нефункциональные требования, тестирование
надежности, заглушка, системное тестирование, тестовое окружение, уровень
тестирования, разработка, управляемая тестированием, пользовательское
приемочное тестирование.
Введение
Для каждого уровня тестирования может быть определено: цели, артефакты
процесса разработки, на основании которых будут разработаны тестовые
сценарии, объекты тестирования, типичные дефекты и отказы, которые могут
быть найдены во время тестирования, требования к тестовой обвязке,
инструментарий и ответственность участников.
Конфигурационные данные для тестирования системы нужно рассматривать во
время планирования тестирования, если такие данные необходимы.
2.2.1 Компонентное тестирование (K2)
Базис тестирования:
•
Требования к компонентам
•
Детальный дизайн
•
Код
Типичные объекты тестирования:
•
Компоненты
•
Программы
•
Программы конвертации и миграции данных
•
Модули БД
Компонентное тестирование (также известное как модульное) занимается поиском
дефектов и верификацией функционирования программных модулей, программ,
объектов, классов и т.п., которые можно протестировать изолированно. Это может
быть сделано изолированно от остальной части системы, в зависимости от
контекста ЖЦ разработки и системы. В процессе могут быть использованы
заглушки, драйвера и эмуляторы.
Компонентное тестирование может включать как тестирование
функциональности и специфичных нефункциональных характеристик, таких как
поведение ресурсов (например, поиск утечки памяти) или тестирование
надежности, так и структурное тестирование (например, покрытие кода). Тестовые
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 30 из 101
13 апреля 2011
© International Software Testing Qualifications Board
сценарии разрабатываются на основе артефактов процесса разработки, таких как
спецификация компонентов, дизайн или модель БД.
Обычно, компонентное тестирование производится с доступом к тестируемому
коду и с поддержкой рабочего окружения, такого как фреймворк модульного
тестирования или утилиты отладки. На практике компонентное тестирование
обычно производится разработчиками, которые пишут код. Дефекты обычно
исправляются сразу после того, как становятся известны, без занесения их в базу
дефектов.
Один из подходов к компонентному тестированию – составить
автоматизированные тестовые сценарии до кодирования. Это называется
разработкой, управляемой тестированием. Этот подход состоит из множества
итераций и основывается на циклах разработки тестовых сценариев, написании и
интеграции небольшого участка кода и выполнении компонентного тестирования,
корректируя любые проблемы и выполняя тесты, пока не будет получен
положительный результат.
2.2.2 Интеграционное тестирование (K2)
Базис тестирования:
•
Проект системы
•
Архитектура
•
Бизнес-процессы
•
Сценарии использования
Типичные объекты тестирования:
•
БД подсистем
•
Инфраструктура
•
Интерфейсы
Конфигурация системы
•
Конфигурационные данные
Интеграционное тестирование проверяет интерфейсы между компонентами,
взаимодействие различных частей системы, таких как операционная системы,
файловая система, аппаратное обеспечение, и интерфейсы между системами.
Интеграционное тестирование может состоять из одного или более уровней и
может быть выполнено на тестовых объектах разного размера следующим
образом:
1. Компонентное интеграционное тестирование проверяет взаимодействие
между программными компонентами и производится после компонентного
тестирования
2. Системное интеграционное тестирование проверяет взаимодействие между
системами или между аппаратным обеспечением и может быть выполнено
после системного тестирования. В этом случае, разработчики могут
управлять только одной стороной интерфейса. Однако, это может