Виды тестирования Дизайна

1.

Планирование тестовых случаев
Это этап процесса тестирования ПО, на котором проектируются и
создаются тестовые случаи (тест кейсы), в соответствии с определёнными
ранее критериями качества и целями тестирования. Задача сводится к
тому, чтобы, используя различные стратегии и техники тест-дизайна,
создать набор тестовых случаев, обеспечивающий оптимальное тестовое
покрытие тестируемого приложения.

2.

Понятие тестового покрытия
Тестовое покрытие — это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами
требований либо исполняемого кода. Существуют следующие подходы к оценке и измерению тестового покрытия: покрытие
требований (Requirements Coverage), покрытие кода (Code Coverage), тестовое покрытие на базе анализа потока управления.
Каждый из подходов позволяет оценить различные аспекты качества тестирования и выбрать наиболее подходящий метод
можно исходя из целей и задач проекта.

3.

Подходы к оценке тестового покрытия
Покрытие требований (Requirements Coverage) — оценка покрытия
тестами функциональных и нефункциональных требований к продукту,
путём построения матриц трассировки (traceability matrix).
Покрытие кода (Code Coverage) — оценка покрытия исполняемого кода
тестами, путём отслеживания непроверенных в процессе тестирования
частей программного обеспечения.
Помогает выявить потенциальные уязвимости и недочёты в
программном обеспечении.
Тестовое покрытие на базе анализа потока управления - оценка покрытия
основанная на определении путей выполнения кода программного модуля
и создания выполняемых тест кейсов для покрытия этих путей

4.

Виды рецензирования
Рецензирование (review) — это действия,
предпринимаемые одним или несколькими
лицами для исследования продукта с целью
обнаружить дефекты и улучшить возможности.
Неформальное рецензирование (informal review) — рецензирование,
которое не основано на формальной (документированной) процедуре.
Технический анализ (technical review) — обсуждение, имеющее целью
выработать единый подход к техническому процессу, и проводимое
равноправными участниками.
неформальное рецензирование (informal review) - рецензирование,
которое не основано на формальной (документированной) процедур.
разбор (walkthrough) - это форма экспертной оценки, в которой
программист ведет процесс проверки, а другие члены команды задают
вопросы и выявляют возможные ошибки в отношении стандартов
разработки и другие проблемы.
инспекция (inspection) - тип равноправного анализа, основанный на
визуальной проверке документов для поиска ошибок. Например,
нарушение стандартов разработки и несоответствие документации
более высокого уровня. Наиболее формальная методика
рецензирования и поэтому всегда основывается на документированной
процедуре

5.

Статический анализ
Статический анализ — анализ артефактов разработки программного
обеспечения, таких как требования или программный код, проводимый
без исполнения этих программных артефактов.

6.

Статический анализ
Статический анализ обычно выполняется при
помощи вспомогательных инструментов.
Поток управления (control flow) — последовательность событий
(путей) в процессе выполнения компонента или системы. Анализ
потока данных и потока управления позволяет выявить
потенциальные ошибки и уязвимости в коде до его выполнения.
Поток данных (data flow) — абстрактное представление
последовательности и возможных изменений состояния объектов
данных, при котором состояние объекта это: создание,
использование либо уничтожение.
стандарты кодирования/метрики кода - количество строк кода,
цикломатическая сложность, анализ функциональных точек,
количество ошибок на 1000 строк кода, степень покрытия кода
тестированием, покрытие требований, количество классов и
интерфейсов, связность

7.

White-box тестирование
White-box — тест-дизайн, основанный на технике белого ящика —
процедура написания или выбора тест-кейсов на основе анализа
внутреннего устройства системы или компонента.

8.

Виды
Строковое покрытие (Statement Coverage) — в этом типе тестирования
код выполняется таким образом, что каждая строка приложения
выполняется как минимум один раз. Этот подход позволяет выявить
логические и синтаксические ошибки, которые могут быть пропущены
при использовании других методов тестирования.
Покрытие пути (Path Coverage) — все возможные пути в коде были
пройдены. Покрытие решения (Branch/Decision Coverage) — в
соответствии с этим критерием необходимо составить такое число тестов,
при которых каждое условие в программе примет как истинное
значение, так и ложное значение.
Покрытие условия (Condition Coverage) — данный критерий является
более эффективным по сравнению с предыдущими.
Покрытие операторов (Statement Coverage) — этот метод гарантирует, что
каждый исполняемый оператор в программе будет выполнен хотя бы
один раз в процессе тестирования.

9.

Experience-based подходы
Experience-based — предугадывание ошибки (Error Guessing — EG) — это когда тестировщик использует свои знания системы и
способность к интерпретации спецификации на предмет того, чтобы «предугадать», при каких входных условиях система может
выдать ошибку.
Исследовательское тестирование (Exploratory testing) — такое тестирование определяется как одновременное обучение,
проектирование теста и его исполнение.
checklist-based - это тип тестирования программного обеспечения, основанный на заранее запланированном списке задач,
который называется чек-листом. Профессиональные тестеры, которые имеют достаточный технический опыт, обычно
заполняют эти листы.

10.

Классы эквивалентности
Это техника, при которой мы разделяем функционал (часто диапазон
возможных вводимых значений) на группы эквивалентных по своему
влиянию на систему значений. Такое разделение помогает убедиться в
правильном функционировании целой системы — одного класса
эквивалентности, проверив только один элемент этой группы. Эта
техника заключается в разбиении всего набора тестов на классы
эквивалентности с последующим сокращением числа тестов.
Техника рекомендует проведение тестов для всех классов
эквивалентности, хотя бы по одному тесту для каждого класса. Техника
анализа классов эквивалентности стремится не только сокращать
количество тестов, но и сохранять приемлемое тестовое покрытие.

11.

Классы эквивалентности
●Необходимо определить класс эквивалентности. Это главный шаг
техники. От него во многом зависит эффективность её применения.
●Затем нужно выбрать одного представителя от каждого класса. На этом
шаге из каждого эквивалентного набора тестов мы выбираем один тест.
●Нужно выполнить тесты, на этом шаге мы выполняем тесты от каждого
класса эквивалентности.
Пример: Функцию подсчета комиссии при отмене бронирования
авиабилетов. Размер комиссии зависит от времени до вылета, когда
совершена отмена:
●за 5 суток до вылета комиссия составляет 0%
●меньше 5 суток, но больше 24 часов – 50%
●меньше 24 часов, но до вылета – 75%
●после вылета – 100%

12.

Граничные значения
Входное или выходное значение, которое находится на грани
эквивалентной области или на наименьшем расстоянии от обеих сторон
грани, например, минимальное или максимальное значение области.
Данная техника тест дизайна применима для написания тест кейсов в
первую очередь для диапазонов значений, для определения
корректности их срабатывания на границах этих диапазонов.
Используя данную технику в качестве тестовых данных используют:
●1 - граничное значение
●2 - значение перед границей
●3 - значение после границы

13.

Граничные значения
Пример: Функцию подсчета комиссии при отмене бронирования
авиабилетов.
Размер комиссии зависит от времени до вылета, когда совершена
отмена:
●за 5 суток до вылета комиссия составляет 0%
●меньше 5 суток, но больше 24 часов – 50%
●меньше 24 часов, но до вылета – 75%
●после вылета – 100%

14.

Граничные значения
Эта техника добавляет в технику анализа классов
эквивалентности ориентированность на конкретный тип
ошибок. То есть, техника анализа классов эквивалентности
просто говорит нам о том, что нужно разбить все тесты на
классы и провести тестирование всех классов. А техника
граничных значений ориентирована на обнаружение
конкретной проблемы – возникновения ошибок на границах
классов эквивалентности.
Но, как и для техники анализа классов эквивалентности,
эффективность техники анализа граничных значений зависит
от правильности ее использования. Мы должны приложить
усилия, чтобы правильно определить классы эквивалентности
и их границы. Если мы отнесемся к этому поверхностно, то
рискуем пропустить ошибки.

15.

Переход состояний (State-Transition)
Способы представления:
●диаграмма состояний (state-transition diagram)
●таблица переходов (state-transition table)
Компоненты:
●состояния, в которых система может находиться
●переходы из одного состояния в другое (не все переходы
разрешенные)
●события, вызывающие переход
●действия, которые являются результатом перехода
Модели состояний идеально подходят для описания
поведения отдельного объекта. Самым большим
недостатком является то, что они не очень хороши для
описания поведения, связанного с несколькими объектами,
для этих случаев используют диаграмму взаимодействия
или диаграмму активности.

16.

Спасибо за внимание!
Спасибо за внимание. В этой презентации мы рассмотрели основные подходы к планированию и оценке тестового покрытия, а
также познакомились с различными методами анализа и тестирования кода. Мы надеемся, что представленная информация
будет полезна для повышения качества вашей работы.