TEST DESIGN

PART 1
ПЛАН И ЦЕЛИ КУРСА
o Лекция 1 - 1.5ч
o Лекция 2 - 1.5ч
o Финальный тест - 1.5ч
o ЦА – новые таланты, не ветераны тестирования
o Цели:
o познакомить с различными техниками тест дизайна
o развить навыки тестирования до более высокого уровня
ПЛАН ЛЕКЦИИ
o Цель и предпосылки создания курса
o Тест дизайн и зачем он нужен
o Тестовая модель и как с ней работать
o Как выбрать подходящую технику
o Black-box техники:
o Equivalence partitioning
o Boundary value analysis
o Практика
ЗАЧЕМ?
ОТВЕТЫ
o Как протестировать в сжатые сроки и при этом ничего не
пропустить?
o Что ответить клиенту на собеседовании, когда он просит
рассказать, как мы тестируем и как оптимизируем свои
тесты?
o Как обосновать клиенту, почему нужно проверить так много
кейсов или почему достаточно только нескольких?
o Как протестировать огромное приложение и с чего начать?
o Подготовиться к квалификации J
o Пройти сертификацию iSTQB
АУДИТЫ И КРИТЕРИИ
МИНУТКА САМОАНАЛИЗА

№ Группа Описание
1 Полнота покрытия Покрытие всех функций системы согласно доступным
требований требованиям/макетам и т.п. Если спецификации нет, приложение = =
спецификация
2 Оформление Грамотность
Внешний вид
Единый стиль оформления
3 Структура документа Корректное разбиение системы на модули и функции
4 Соблюдение процесса Проверено не менее 3х версий системы
Метаданные: кто, что и когда тестировал
Метаданные: привязка дефектов к Failed/Blocked тестам
% ПРОЕКТОВ С ОШИБКАМИ
ВСЕ ВИДЫ ДОКУМЕНТАЦИИ

17
20 60
Грамотность
14 Полнота покрытия
Разбиение на функции
Внешний вид
38 Единый стиль
Метаданные документа
42
Метаданные документа

55
% ПРОЕКТОВ С ОШИБКАМИ
TEST SURVEY, TEST CASES

19

25
70
Пропуск проверок
Ожидаемый результат
Дубликаты
25
Единый стиль
Противоречия
Приоритет

38
47
ТИПИЧНЫЕ ОШИБКИ
ПРИ РАБОТЕ С ТЕСТОВОЙ ДОКУМЕНТАЦИЕЙ

o Неполнота покрытия
o Проблемы с ожидаемыми результатами
o Дубликаты проверок
o Неконкретные шаги
o Внешний вид, метаданные
o Копирование спецификации
o Отсутствие приоритезации
EXHAUSTIVE TESTING
ИСЧЕРПЫВАЮЩЕЕ ТЕСТИРОВАНИЕ

o Много комбинаций входных параметров

o Много состояний системы
o Много вариантов окружений
o Дедлайн
КАК МЫ БУДЕМ
ТЕСТИРОВАТЬ?
ТЕСТ ДИЗАЙН
o Этап процесса тестирования ПО, на котором проектируются и
создаются тестовые сценарии в соответствии с определёнными ранее
критериями качества и целями тестирования.
o Цели:
o Создать такие тестовые сценарии, которые найдут ошибки в ПО
o Минимизировать количество тестов, необходимых, чтобы
обнаружить эти ошибки
ТЕСТ
ДИЗАЙНЕР

o Умение делать
декомпозицию
o Поиск требования к
продукту и их анализ
o Умение выделять
приоритеты
o Умение формулировать и
лаконично излагать свои
мысли
o Знание различных техник
тест дизайна
o Умение выбрать нужные и
применить их на практике
ЛЮБИМАЯ ЦИТАТА
О ТЕСТИРОВАНИИ

o Testing isn’t just operating a product and looking for bugs. Testing involves
modeling and questioning and studying, making inferences, challenging
beliefs.
С ЧЕГО НАЧАТЬ?
АЛГОРИТМ ДЕЙСТВИЙ
o Найти и изучить требования
o Сформировать тестовую модель
o Определить степень детализации
o Выбрать техники тест дизайна
o Создать тестовые сценарии
o Приоритезировать

Цена ошибки = пропуск бага

ТЕСТОВАЯ МОДЕЛЬ
o Тестовая модель – это логическая структура,
описывающая функциональность системы и поведение пользователя,
которая в дальнейшем наполняется проверками (тест-кейсами).
КАК ДЕКОМПОЗИРОВАТЬ СИСТЕМУ
ДЛЯ ПОСТРОЕНИЯ ТЕСТОВОЙ МОДЕЛИ

o Роли
o Внешний интерфейс: страницы сайта, модули
o Функции приложения и их варианты использования
o Состояния приложения/модулей/объектов
o Use cases или бизнес-процессы
o Декомпозиция в соответствии с единицей требований
КАКУЮ ТЕХНИКУ
ВЫБРАТЬ?
ТЕХНИК И ПРИЕМОВ МНОГО
Например:
o «Партизанское тестирование» - быстро и вредоносно
o «Съесть еду своей собаки» - внутри компании
o «Тестирование глупой обезьяны» - беспорядочные клики, случайные данные
o «Тестирование мыльной оперы» - в одном сценарии проверить как можно
больше всего
КЛАССИФИКАЦИЯ
o Black-box test techniques
o White-box test techniques
o Experience-based test techniques
BLACK-BOX TECHNIQUES
o Equivalence Partitioning (EP)
o Boundary Value Analysis (BVA)
o Decision Table Testing
o State Transition Testing
BLACK-BOX TEST TECHNIQUES
o основываются на требованиях, спецификации, use cases, user
stories, бизнес-процессах
o могут применяться как к функциональному, так и
нефункциональному тестированию
o концентрируются на входных и выходных значениях тестируемого
объекта, а не на его внутренней структуре (код)
BLACK-BOX

o Black-box testing != Monkey testing

o Проверка приложения с т.зр. конечного
пользователя
o Проверка на соответствие требованиям
EQUIVALENCE
PARTITIONING
ПРИМЕР
СОЗДАТЬ ТЕСТ-КЕЙСЫ ДЛЯ EVACUATION PLAN

*для упрощения примера возьмем неизменную цену

*и предположим, что этот пользователь может покупать
только Product = Evacuation plan
РАЗБИВАЕМ НА КЛАССЫ ВХОДНЫЕ ПАРАМЕТРЫ

Параметр Класс 1 Класс 2 Класс 3

Версия Standard Premium -
продукта
Количество (Q) Q<1 1 <= Q <= 99 Q > 99
СОЗДАЕМ ДЛЯ КАЖДОГО КЛАССА ПО 1 ПРОВЕРКЕ

Версия Кол-во Результат

продукта

Case 1 Standard 50 positive

Case 2 Standard -25 negative
Case 3 Standard 125 negative
Case 4 Premium 1 positive
Case 5 Premium 0 negative
Case 6 Premium 100 negative
EQUIVALENCE PARTITIONING
РАЗДЕЛЕНИЕ НА ЭКВИВАЛЕНТНЫЕ КЛАССЫ

Цель:
o сократить количество тестовых сценариев, сохраняя при
этом достаточное покрытие тестами
o провести в первую очередь наиболее приоритетные
проверки, которые с большей долей вероятности
обнаружат дефект
EQUIVALENCE PARTITIONING
Допущения:
o использование любого представителя класса приведет к
одинаковому результату
o код написан достаточно качественно
EQUIVALENCE PARTITIONING
Алгоритм использования техники:
o Выбрать компонент
o Разбить входные данные компонента на классы эквивалентности
o Написать один тестовый сценарий для каждого класса
эквивалентности
РАЗНЫЕ ПРИНЦИПЫ РАЗБИЕНИЯ НА КЛАССЫ

Параметр Класс 1 Класс 2 Класс 3

Версия Standard Premium -
продукта
Количество (Q) Q<1 1 <= Q <= 99 Q > 99
Дробные Целые -
Числа Не числа Пусто
ВАЖНОЕ ДОПОЛНЕНИЕ

o Valid классы можно/нужно объединять

в рамках 1 тест-кейса
o Invalid классы лучше не объединять
 EQUIVALENCE
PARTITIONING
В НАШЕЙ ЖИЗНИ
ВЫВОДЫ
o Классы могут быть как valid, так и invalid
o Любой класс можно бить на под-классы, если в этом есть
необходимость
o Каждое значение может принадлежать только одному классу
o Отлично подходит, если надо прогнать Smoke test (либо провести
тест на проде)
o Оптимально использовать вместе с Boundary Value Analysis
ОПАСНОСТИ
o Пропуск дефектов, если данные из класса все-таки обрабатываются
по-разному
o Ошибочное выделение классов:
o поле, которое принимает +/- числа
o не учтен класс
o Много классов – избыточные проверки, мало классов - пропуск
ВАША ОЧЕРЕДЬ
Параметр Класс 1 Класс 2 Класс 3 Класс 4
First name
Last name
Photo
Country
Language

Specification:
o text fields max length = 256
o images format = png, jpg
o all fields are obligatory
Параметр Класс 1 Класс 2 Класс 3
First name 1 <= длина строки <=256 длина строки >256 пусто

Last name 1 <= длина строки <=256 длина строки >256 пусто
Photo png, jpg другие форматы пусто
Country default другая -
Language default другая -
BOUNDARY VALUE
ANALYSIS
BOUNDARY VALUE ANALYSIS
АНАЛИЗ ГРАНИЧНЫХ ЗНАЧЕНИЙ

Цель:
o отловить ошибки, связанные с тем, что код не учитывает
обработку граничных значений

Предположение:
o большинство ошибок происходит именно на границах
(напр. 29 февраля, >= vs >)
Specification:
o 0 kg – ‘Good job! You’ve done it!’
o 1-10 kg – ‘to go. Keep on running!’
o 10-20 kg – ‘to go and this goal is
in the bag!
o 20-30 kg – ‘to go and Mommy will
be so proud of you’.
BOUNDARY VALUE ANALYSIS
Алгоритм использования техники:
o Выбрать компонент
o Разбить входные данные компонента на классы эквивалентности
o Выделить границы для каждого класса
o На каждую из границ создается 3 тест-кейса:
o первый проверяет значение границы
o второй – значение ниже границы
o третий – значение выше границы
ПРИМЕР
*можем покупать
все Products

0 99

Базовый Тест
Для успокоения нервов
Негативный Тест
Evacuation_Plan = {-1, 0, 1, 50, 98, 99, 100}
Risk_Assesment = {-1, 0, 1, 50, 98, 99, 100}

Находим все пары. В математике это Декартово 99

произведение:
Evacuation_Plan х Risk_Assesment =
{(a,b) | a ∈ Evacuation_Plan, b ∈ Risk_Assesment}
Evacuation_Plan х Risk_Assesment =
{ (-1,-1), (-1,0), (-1,1), (-1,50), (-1,98), (-1,99), (-1,100),
(0,-1), (0,0), (0,1), (0,50), (0,98), (0,99), (0,100),
(1,-1), (1,0), (1,1), (1,50), (1,98), (1,99), (1,100),
(50,-1), (50,0), (50,1), (50,50), (50,98), (50,99), (50,100),
(98,-1), (98,0), (98,1), (98,50), (98,98), (98,99), (98,100),
(99,-1), (99,0), (99,1), (99,50), (99,98), (99,99), (99,100),
(100,-1), (100,0), (100,1), (100,50), (100,98), (100,99), (100,100)}

Итого: 7х7 = 49 кейсов

Evacuation_Plan = {-1, 0, 1, 50, 98, 99, 100}

Risk_Assesment = {-1, 0, 1, 50, 98, 99, 100}
EP_Type = {Standard, Premium} 1
RA_Type = {Standard, Premium}

Количество кейсов = 7 * 7 * 2 * 2 = 196

1 99
ВЫВОДЫ
o Чаще всего используется для тестирования требований, которые
описывают какие-либо интервалы (числовые рейнджи, даты, время,
и т.п.), но не только
o Оптимально использовать вместе с Equivalence Partitioning
o BVA – гибкая техника (можно исключить проверки в зависимости от
приоритетов/покрытия, MAT)
ОПАСНОСТИ
o Те же, что и для EP:
o Неверное выделение границ
o Не учтен класс и его границы
o Относительность понятия «граница»:
o если граница $5, то проверяем $4, $5, $6
o если граница $5.00, то проверяем $4.99, $5.00, $5.01
ВАША ОЧЕРЕДЬ
Specification
o Cost range $0 - $500+

Use case
o If cost < $10, discount = 0%
o If $10 <= cost <=50, discount = 10%
o If cost > $50, discount = 20%
 10 50

%10 discount = {9.99, 10.00, 10.01, 20.00, 49.99, 50, 50.01}

ДОМАШНЕЕ ЗАДАНИЕ

Распишите эквивалентные классы и граничные

значения, которые бы вы проверяли для
процесса перевода денег через интернет-
банкинг.
Поля формы:
o Номер карты получателя - XXXX XXXX XXXX
XXXX
o Сумма перевода (BYN) – 0.00
ВЫВОДЫ ЛЕКЦИИ
o Тест дизайн - это важный и сложный этап, который нельзя
пропускать
o При всем изобилии техник главное - это уметь их применять с умом
в нужный момент
o Тестовая модель придет на помощь для сложных систем
o Black-box техники не примитивны
o EP + BVA = более оптимальное покрытие, чем по раздельности, но
далеко не полное
БОЛЬШОЕ
СПАСИБО!