ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 2574
Скачиваний: 13
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 36 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Методы разработки тестов на основе спецификаций используются для
извлечения информации о тестовых условиях и тестовых сценариях из
функциональности программы или системы (см. Главу 4). Функциональное
тестирование рассматривает внешнее поведение программного обеспечения
(тестирование методом черного ящика).
Один из типов функционального тестирования, тестирование безопасности,
исследует функции (например, брандмауэр) касающиеся обнаружения угроз,
таких как вирусы, поступающих извне. Другой тип функционального тестирования,
тестирование возможности взаимодействия, оценивает способность
программного продукта взаимодействовать с одним или более указанными
компонентами или системами.
2.3.2 Тестирование нефункциональных характеристик
(Нефункциональное тестирование) (K2)
Нефункциональное тестирование включает, но не ограничивается, нагрузочное
тестирование, тестирование производительности, стресс-тестирование,
тестирование удобства использования, тестирование восстановления,
тестирование надежности и тестирование переносимости. Это тестирование того,
«как» система работает.
Нефункциональное тестирование может выполняться на всех уровнях
тестирования. Термин нефункциональное тестирование описывает тесты,
необходимые для оценки характеристик систем и программ, которые могут быть
количественно измерены, такие как время отклика при тестировании
производительности. Эти тесты могут ссылаться на модели качества, такие как
«Разработка программного обеспечения – Качество программного продукта» (ISO
9126). Нефункциональное тестирование рассматривает внешнее поведение
программного обеспечения и в большинстве случаев использует разработку
тестов методом черного ящика.
2.3.3 Тестирование структуры/архитектуры программного
обеспечения (Структурное тестирование) (K2)
Структурное тестирование (тестирование методом белого ящика) может
выполняться на всех уровнях тестирования. Структурные методы тестирования
лучше всего использовать после методов разработки тестов на основе
спецификации, чтобы измерить тщательность тестирования, используя измерения
покрытия структуры программы.
Покрытие – это часть структуры программы, которая была охвачена
тестированием, выраженная в процентах. Если покрытие не равно 100%, то
необходимо разрабатывать дополнительные тесты для покрытия пропущенных
участков программы. Методики покрытия описаны в главе 4.
На всех уровнях тестирования, особенно в компонентном и компонентном
интеграционном тестировании, могут использоваться инструментальные средства
для измерения покрытия кода. Структурное тестирование может основываться на
архитектуре системы, такой как иерархия вызовов.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 37 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Методы структурного тестирования могут быть применены на системном,
системном интеграционном и приемочном уровнях (например, применены к
бизнес-моделям или структурам меню).
2.3.4 Тестирование изменений: подтверждающее и регрессионное
тестирование (K2)
После того, как дефект обнаружен и исправлен, программу необходимо
перепроверить, чтобы убедиться, что исходный дефект успешно устранен. Это
называется подтверждением. Отладка (локализация и исправление дефекта)
относится к процессу разработки, а не тестирования.
Регрессионное тестирование – это повторное тестирование уже
протестированных программ после внесения в них изменений, чтобы обнаружить
дефекты, внесенные или пропущенные в результате этих действий. Эти дефекты
могут быть как в проверяемом компоненте, так и в связанном или несвязанным с
ним. Регрессионное тестирование выполняется, когда в программное
обеспечение или его окружение вносятся изменения. Глубина регрессионного
тестирования оценивается риском пропуска дефектов в программном
обеспечении, которое работало ранее.
Тесты должны быть повторяемыми, если они должны использоваться для
подтверждающего или регрессионного тестирования.
Регрессионное тестирование может выполняться на всех уровнях тестирования и
включает функциональное, нефункциональное и структурное тестирование.
Регрессионные наборы тестов запускаются множество раз и меняются медленно,
поэтому регрессионное тестирование является хорошим кандидатом на
автоматизацию.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 38 из 101
13 апреля 2011
© International Software Testing Qualifications Board
2.4 Тестирование в период сопровождения (K2)
14 минут
Терминология
Анализ влияния, тестирование в период сопровождения.
Введение
После установки система программного обеспечения обычно находится в
эксплуатации в течение многих лет. В это время сама система, ее конфигурация
или среда исполнения часто изменяются или расширяются. Ранее планирование
релизов крайне важно для успешного тестирования в период сопровождения. При
этом необходимо отличать запланированные выпуски и срочные исправления.
Тестирование в период сопровождения выполняется на текущей ОС и может быть
вызвано модификацией, переносом или прекращение эксплуатации данной
системы.
Модификация включает в себя запланированные изменения ( например, в рамках
релиза), корректирующие и срочные изменения, изменения в окружении, такие как
запланированные модификации ОС или СУБД, плановые модификации
коробочных продуктов, или патчи для исправления недавно выявленных слабых
мест в ОС.
Тестирование в период сопровождения при переносе (например, между
платформами) должно включать как эксплуатационные тесты нового окружения,
так и изменения в самой программе. Тестирование переноса также необходимо,
когда данные из какой-либо системы переносятся в сопровождаемую систему.
Тестирование в период сопровождения для прекращения эксплуатации системы
может включать в себя тестирование переноса данных или архивации, если
присутствуют данные за большие периоды времени.
В дополнение к тестированию изменений, тестирование периода сопровождения
включает регрессионное тестирование тех частей программы, которые не
подвергались изменениям. Граница области, которая будет включена в
тестирование, определяются риском изменений и отношением размера
существующей системы к размеру внесенных изменений. В зависимости от
вносимых изменений, тестирование в период сопровождения может проводиться
на любом из уровней или видов тестирования. Определение, каким образом
внесенные изменения могут повлиять на систему, называется анализом влияния и
используется при определении объема регрессионных тестов.
Тестирование в период сопровождения затруднено, если технические требования
являются устаревшими или отсутствуют вообще, либо тестировщики не обладают
достаточными знаниями предметной области.
Ссылки
2.1.3 CMMI, Craig, 2002, Hetzel, 1988, IEEE 12207
2.2
Hetzel, 1988
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 39 из 101
13 апреля 2011
© International Software Testing Qualifications Board
2.2.4 Copeland, 2004, Myers, 1979
2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004
2.3.2 Black, 2001, ISO 9126
2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1988
2.3.4 Hetzel, 1988, IEEE STD 829-1998
2.4
Black, 2001, Craig, 2002, Hetzel, 1988, IEEE STD 829-1998
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 40 из 101
13 апреля 2011
© International Software Testing Qualifications Board
3 Статические методы (K2)
60 минут
Цели изучения Статических методов тестирования
Цели определяют, что нужно знать для завершения каждого модуля.
3.1
Статические методы и Процесс тестирования (K2)
LO-3.1.1 Объяснять какие продукты ПО могут быть проверены с помощью
различных статических методов (K1)
LO-3.1.2 Охарактеризовать важность и значение статических методов для
оценки качества программных продуктов (K2)
LO-3.1.3 Объяснить разницу между статическими и динамическими методами,
рассматривая цели, типы дефектов, которые должны быть обнаружены,
а так же роль этих методов в жизненном цикле ПО (K2)
3.2
Процесс анализа (K2)
LO-3.2.1 Вспомнить действия, роли и обязанности при типичном формальном
рецензировании (K1)
LO-3.2.2 Объяснить отличия между различными типами анализа:
неформальным рецензированием, техническим анализом, сквозным
контролем и инспекцией (K2)
LO-3.2.3 Объяснить факторы успешного выполнения рецензирования (K2)
3.3
Статический анализ с помощью инструментальных средств (K2)
LO-3.3.1 Вспомнить типичные дефекты и ошибки, которые могут быть
обнаружены при статическом анализе, и сравнить с рецензированием и
динамическим тестированием (K1)
LO-3.3.2 Охарактеризовать на примерах типичные преимущества статического
анализа (K2)
LO-3.3.3 Перечислить типичные дефекты в коде и дизайне, которые могут быть
определены с помощью средств статического анализа (K1)