ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 2581
Скачиваний: 13
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 56 из 101
13 апреля 2011
© International Software Testing Qualifications Board
4.3.3 Тестирование таблицы решений (К3)
Таблицы решений – хороший метод для сбора системных требований,
содержащих логические условия и документирования внутреннего дизайна
системы. Они могут использоваться для записи сложных бизнес-правил, которые
должна реализовывать система. Анализируются спецификации и определяются
условия и действия системы. Входные условия и действия чаще всего
формулируются таким образом, чтобы они могли принимать логические значения
«истина» или «ложь».
Таблица решений содержит триггерные условия, обычно комбинации значений
«истина» и «ложь» для всех входных условий, и результирующие действия для
каждой комбинации условий. Каждый столбец таблицы соотносится с бизнес-
правилом, определяющим уникальную комбинацию условий и результат
выполнения действий, связанных с этим правилом. Стандартом покрытия для
тестирования таблицы решений обычно является наличие хотя бы одного теста
для каждой колонки, что обычно включает в себя покрытие всех комбинаций
триггерных условий.
Сильной стороной тестирования таблицы решений является то, что она создает
комбинации условий, которые могли бы быть не проверены в ходе тестирования
иным способом. Этот метод может быть применен ко всем ситуациям, в которых
действие программного продукта зависит от нескольких логических альтернатив.
4.3.4 Тестирование таблицы переходов (К3)
Система может показывать различные отклики в зависимости от текущих условий
или предшествовавшей истории состояний. Данный метод позволяет
тестировщику рассматривать систему с точки зрения её состояний, переходов
между состояниями, входов или событий, активизирующих изменения состояний
(переходы) и действия, к которым приводят эти переходы. Состояния системы или
тестируемого объекта разделяемы, определяемы и конечны.
Таблица состояний демонстрирует связи между состояниями и входами и может
подсказать возможные некорректные переходы.
Тесты могут разрабатываться для покрытия типовой последовательности
состояний, для покрытия каждого состояния, для выполнения каждого перехода,
для выполнения определенных последовательностей переходов или же для
тестирования некорректных переходов.
Тестирование таблицы переходов чаще всего используется в индустрии
встроенного программного обеспечения и автоматизации в целом. Однако эта
методика также подходит для моделирования бизнес-объектов, имеющих
определенные состояния, или тестирования последовательностей диалоговых
блоков (т.е. интернет-приложений или бизнес-сценариев).
4.3.5 Тестирование по сценариям использования (К2)
Тесты могут базироваться на сценариях использования. Сценарий использования
описывает взаимодействия между участниками (включая пользователей и
систему) приводящие к полезным результатам для заказчика или пользователя
системы. Сценарии использования могут быть описаны на уровне абстракций
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 57 из 101
13 апреля 2011
© International Software Testing Qualifications Board
(бизнес сценарий использования, уровень бизнес-процессов, не связанный с
технологией) или на системном уровне (сценарий использования системы на
уровне системного функционала). Каждый сценарий использования имеет
предусловия, необходимые для успешного выполнения сценария. Каждый
сценарий использования завершается постусловиями, являющимися
наблюдаемыми результатами и итоговым состоянием системы после выполнения
сценария. Сценарий использования обычно имеет основной (наиболее
вероятный) сценарий и альтернативные сценарии.
Сценарии использования описываются как «потоки процессов» в системе,
основанные на типовом предполагаемом использовании. Таким образом,
тестовые сценарии, построенные на основе сценариев использования, являются
наиболее полезными для выявления дефектов в потоках процессов во время
реального использования системы. Сценарии использования очень полезны для
разработки приёмочных тестов с участием заказчика или пользователей. Также
они могут выявить дефекты интеграции, вызванные взаимодействием различных
компонентов, не выявляемые индивидуальным тестированием компонентов.
Проектирование тестовых сценариев на основе сценариев использования может
быть объединено с другими методами, основанными на спецификации.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 58 из 101
13 апреля 2011
© International Software Testing Qualifications Board
4.4 Тестирование на основе структуры, или
методы белого ящика (К3)
60 минут
Терминология
Покрытие кода, покрытие альтернатив, покрытие операторов, тестирование на
основе структуры.
Введение
Тестирование на основе структуры, или тестирование методом белого ящика,
основывается на конкретной структуре программного продукта или системы, как
рассмотрено в следующих примерах:
•
Компонентный уровень: структура компонента программного обеспечения,
т.е. операторы, альтернативы, ветви или определенные пути
•
Интеграционный уровень: структура может быть представлена деревом
вызовов (диаграмма, в которой модули вызывают другие модули)
•
Системный уровень: структура может представлять собой структуру меню,
бизнес-процессов или же схему веб-страницы.
В этом разделе рассматриваются три метода проектирования тестов на основе
структуры для покрытия кода: основанные на операторах, ветвях и
альтернативах. Для визуализации тестирования альтернатив может
использоваться диаграмма потока управления.
4.4.1 Тестирование операторов и покрытие (K3)
В компонентном тестировании покрытие операторов - это доля операторов,
проверенных во время выполнения набора сценария тестирования. При
тестировании операторов тестовые сценарии создаются таким образом, чтобы
выполнять определенные операторы и обычно увеличивать покрытие операторов.
Величина покрытия операторов определяется как отношение числа выполняемых
операторов, покрытых тестовыми сценариями (разработанными или
выполненными) к общему числу операторов в тестируемом коде.
4.4.2 Тестирование альтернатив и покрытие (К3)
Покрытие альтернатив, связанное с тестированием ветвей - это доля результатов
альтернатив (например, вариантов «Истина» и «Ложь» для оператора «Если»),
проверенных набором сценариев тестирования. В методе тестирования
альтернатив тестовые сценарии создаются для выполнения определенных
результатов альтернатив. Ветви исходят из точек альтернатив в программном
коде и показывают передачу управления различным участкам кода.
Покрытие альтернатив определяется отношением числа всех результатов
альтернатив, покрытых разработанными или выполненными тестовыми
сценариями к числу всех возможных результатов альтернатив в тестируемом
коде.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 59 из 101
13 апреля 2011
© International Software Testing Qualifications Board
Тестирование альтернатив - это вид тестирования потока управления, так как оно
описывает прохождение определенного потока через точки альтернативы.
Покрытие альтернатив более строгое, чем покрытие операторов: 100% покрытие
альтернатив обеспечивает 100% покрытие операторов, но не наоборот.
4.4.3 Другие методы, основанные на структуре (К1)
Имеются и более высокие уровни покрытия структуры после покрытия
альтернатив. Например, покрытие условий и покрытие множественных условий.
Принцип покрытия также может быть применен на других уровнях тестирования.
Например, на уровне интеграции процент модулей, компонентов или классов,
проверенных набором тестовых сценарием, может быть выражен как покрытие
модулей, компонентов или классов.
Для структурного тестирования крайне полезна инструментальная поддержка.
Сертифицированный тестировщик
Программа обучения Базового уровня
International
Software Testing
Qualifications Board
Версия 2011
Страница 60 из 101
13 апреля 2011
© International Software Testing Qualifications Board
4.5 Методы, основанные на опыте (К2)
30 минут
Терминология
Исследовательское тестирование, атака (на недочеты)
Введение
Когда тесты создаются на основе мастерства тестировщика, его интуиции и опыте
работы с подобными приложениями или технологиями, это называется
тестированием, основанным на опыте. Данный вид тестирования полезен как
дополнение более систематических методов для разработки специальных тестов,
не всегда очевидных при использовании более формальных методик, особенно
когда используется после таких методик. Однако полезность этого метода может
сильно варьироваться в зависимости от опыта тестировщика.
Наиболее часто используемым методом, основанным на опыте, является
предположение об ошибках. Зачастую тестировщики ожидают дефекты, исходя из
своего опыта. Организованным подходом к предположению об ошибках является
создание списка возможных дефектов и разработка тестов для атаки этих
дефектов. Данный подход называется атакой, или атакой на недочеты. Списки
дефектов и отказов могут быть созданы на основе опыта, доступной информации
о дефектах и отказах и общего представления о том, почему программное
обеспечение может отказать.
Исследовательское тестирование - это параллельная разработка тестов, их
выполнение, протоколирование тестирования и изучение, основанные на
концепции тестирования, включающей в себя цели тестирования, и проводимые в
определенных временных рамках. Данный подход наиболее полезен при наличии
неполных или неактуальных спецификаций и жестких временных ограничений,
или при усилении или дополнении более формального тестирования. Он может
служить проверкой процесса тестирования для уверенности в том, что наиболее
важные дефекты обнаружены.