ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 2587
Скачиваний: 13
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 51 из 101
13 апреля 2011
© International Software Testing Qualifications Board
4.1 Процесс разработки тестов (K2)
15 минут
Терминология
спецификация тестовых сценариев, проектирование теста, расписание
выполнения тестов, спецификация процедуры тестирования, автоматизированный
сценарий тестирования, трассируемость.
Вводная информация.
Процесс, описанный в этом разделе, может быть выполнен различными
способами - от крайне неформальных с минимальным документированием или
полным отсутствием документации, до крайне формальных, как описано ниже.
Уровень формализации зависит от контекста тестирования, включающего в себя
организацию, зрелость процессов тестирования и разработки, ограничений по
времени и квалификации вовлеченных сотрудников.
Во время анализа тестирования базис тестирования анализируется с целью
определить, что будет тестироваться, то есть определяются тестовые условия.
Тестовые условия определяются как сущности или события, которые будут
проверяться одним или несколькими тестовыми сценариями (например, функция,
транзакция, характеристика качества или структурный элемент).
Установление трассируемости от тестовых условий назад к спецификациям и
требованиям позволяет как определить последствия при изменяющихся
требованиях, так и установить покрытие требований набором тестов. При анализе
тестирования реализуется детализированный подход к тестированию с целью
выбора методов проектирования тестов, основываясь, в том числе, на
выявленных рисках (см. Главу 5).
Во время проектирования тестов определяются и специфицируются тестовые
сценарии и тестовые данные.
Тестовый сценарий состоит из набора входных значений, предусловий
выполнения, ожидаемых результатов и постусловий, определяемых для покрытия
определенных тестовых условий (или тестового условия) или целей (цели)
тестирования. Содержание спецификаций проектирования тестов (включая
тестовые условия) и спецификаций тестовых сценариев описывается в стандарте
«Документация при тестировании программ» (IEEE STD 829-1998)
Ожидаемые результаты должны создаваться как часть спецификаций тестовых
сценариев и включать в себя выходные данные, изменения в данных и
состояниях, и любые иные последствия теста. Если ожидаемые результаты не
были определены, правдоподобные, но ошибочные результаты могут быть
приняты за корректные.
В идеальных условиях ожидаемые результаты должны быть определены до
момента выполнения теста.
Во время реализации теста тестовые сценарии разрабатываются, реализуются,
получают приоритеты и формируют спецификацию процедуры тестирования
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 52 из 101
13 апреля 2011
© International Software Testing Qualifications Board
(IEEE STD 829-1998). Процедура тестирования (или ручной сценарий
тестирования) описывает последовательность действий для выполнения теста.
Если тесты запускаются с использованием инструмента выполнения тестов,
последовательность действий описывается автоматизированным тестовым
сценарием.
Различные процедуры тестирования и автоматические тестовые сценарии
собираются в расписание выполнения тестов, определяющее, в какой
очередности, когда и кем эти тестовые процедуры и сценарии должны быть
выполнены.
Расписание выполнения тестов должно учитывать такие факторы, как
регрессионные тесты, приоритеты и технические и логические зависимости.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 53 из 101
13 апреля 2011
© International Software Testing Qualifications Board
4.2 Категории методов проектирования тестов
(К2)
15 минут
Терминология
Разработка тестов методом черного ящика, разработка тестов методом белого
ящика, метод создания тестов на основе опыта, метод разработки тестов на
основе спецификации, структурный метод разработки тестов.
Введение
Целью метода проектирования тестов является определение тестовых условий и
тестовых сценариев. Классическим является разделение методов тестирования
на методы черного и белого ящиков. Методы черного ящика (включающие в себя
методы разработки тестов на основе спецификаций и на основе опыта) – это
способ определить и выбрать тестовые условия или сценарии для компонента
или системы (как функциональные, так и не функциональные), на основе анализа
базиса тестирования и опыта разработчиков, тестировщиков и пользователей, без
отсылки к внутренней структуре компонента или системы. Методы белого ящика
(также называемые структурными, или основанными на структуре) основываются
на анализе структуры компонента или системы. Оба этих метода могут быть
объединены с методом создания тестов на основе опыта, чтобы использовать
опыт разработчиков, тестировщиков и пользователей для определения того, что
должно быть протестировано. Некоторые методы могут быть однозначно
отнесены к определенной категории, другие же сочетают в себе несколько
категорий.
Данная программа относит подходы, основанные на спецификациях или опыте к
методам черного ящика, и подходы, основанные на структуре – к методам белого
ящика. Также рассматриваются методы создания тестов на основе опыта.
Общие признаки подходов, основанных на спецификациях:
•
Для описания задач, которые должны быть решены, программных
продуктов или их компонентов, используются модели - формальные или
неформальные.
•
Из этих моделей систематически выводятся тестовые сценарии.
Общие признаки подходов, основанных на структуре:
•
тестовые сценарии выводятся на основе информации о том, как
спроектировано программное обеспечение (например, на основе
программного кода и подробного описания проектного решения).
•
для программного обеспечения может быть измерена величина покрытия
для имеющихся тестовых сценариев, и последующие тестовые сценарии
могут разрабатываться для систематического увеличения покрытия.
Общие признаки методов на основе опыта:
•
для определения тестовых сценариев используются человеческие знания и
опыт.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 54 из 101
13 апреля 2011
© International Software Testing Qualifications Board
•
знания тестировщиков, разработчиков, пользователей и заинтересованных
лиц о программном продукте, его использовании и окружении, являются
одним из источников информации.
•
знания о вероятных дефектах и их распределении являются другим
источником информации
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 55 из 101
13 апреля 2011
© International Software Testing Qualifications Board
4.3 Методы, основанные на спецификациях,
или методы черного ящика (К3)
150 минут
Терминология
Анализ граничных значений, тестирование таблицы решений, эквивалентное
разбиение, тестирование таблицы переходов, тестирование по сценариям
использования.
4.3.1 Эквивалентное разбиение (К3)
Входные данные для программного обеспечения или системы разбиваются на
группы, от которых ожидается сходное поведение, то есть они должны
обрабатываться аналогичным образом. Эквивалентные области (или классы)
могут быть определены как для валидных, так и для невалидных данных, то есть
тех значений, которые должны отвергаться. Области также могут быть
определены для выходных данных, внутренних значений, значений, зависящих от
времени (например, до или после некоторого события) и для параметров
интерфейса (например, во время интеграционного тестирования). Тесты могут
разрабатываться для покрытия всех валидных и всех невалидных классов.
Эквивалентное разбиение применимо на всех уровнях тестирования.
Эквивалентное разбиение может быть использовано с целью покрытия входных и
выходных данных. Оно может применяться при ручном вводе данных, при
передаче данных через интерфейсы в систему, или при проверке параметров
интерфейсов в интеграционном тестировании.
4.3.2 Анализ граничных значений (К3)
Поведение на границах эквивалентных областей имеет наибольшие шансы быть
некорректным, таким образом границы являются потенциальным источником
дефектов. Минимальные и максимальные значения сегмента являются
граничными значениями. Граничное значение для валидного сегмента является
валидным граничным значением, для невалидного сегмента – невалидным. Тесты
могут разрабатываться для покрытия как валидных, так и невалидных граничных
значений. При разработке тестовых сценариев выбирабтся тесты для каждого
граничного значения.
Анализ граничных значений может применяться на всех уровнях тестирования. Он
относительно легок в применении и эффективен при поиске дефектов. Для
выделения интересующих нас границ крайне полезны подробные спецификации.
Данный метод часто рассматривается как дополнение к методу эквивалентного
разбиения. Он может использоваться для классов эквивалентности данных,
вводимых на экране, так и, например, для классов эквивалентности временных
диапазонов (например, таймауты или требования по быстродействию транзакций)
или для размерности таблиц (например, размер таблицы 256*256).