Основные техникиТЕСТ ДИЗАЙНА

для черноящичного тестирования

(С) М

алев

ич

Что скрывается в определении

“ТЕСТ ДИЗАЙН”?

Этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи.

ТЕСТ ДИЗАЙН

ОПТИМАЛЬНОЕ ТЕСТОВОЕ ПОКРЫТИЕ тестируемого приложения

Т.Е: 1) минимум тестов 2) максимум выявленных дефектов 3) ...поменьше слайдов этой презы

Цели

A Practitioner's Guide to Software Test Design

Lee Copeland

A Practitioner's Guide to Software Test Design

Lee Copeland

ПОПАРНОЕ ТЕСТИРОВАНИЕ

ЧТО ЭТО ?

PAIRWISE- методика тестирования, основанная на ПРЕДПОЛОЖЕНИИ, что большинство дефектов возникает при взаимодействии не более чем ДВУХ факторов. 

- ЭТО МАГИЯ?

- ЭТО ТЕОРВЕР, ДЕТКА

Простой пример: ПУСТЬ выпадение ЕДИНИЦ на кубиках - это БАГА

P(bug) = 1/6 =0.167

P2(bug) =0.167 * 0.167 = 0.028

Для нескольких событий – вероятность перемножается.

P(A*B) = P(A)*P(B)

P3(bug) = 0.167 * 0.167 * 0.167 = 0.005

Вероятность бага при комбинации 3х и более паметров так мала что ее можно и нужно отбрасывать

Тогда вероятность ее появления для 1-го кубика равна:

ЧТО ГОВОРЯТ СТАНДАРТЫ?

D. Richard Kuhn, Senior Member, IEEE,Dolores R. Wallace, Member,IEEE Computer Society

Oпубликовали исследование, проводимое IEEE для ПО отозванных в течении 15 лет мед. устройств. Вывод: 98% дефектов возникают при конфликте ПАР входных данных или ОДНОГО входного параметра (что PAIRWISE TESTING также покрывает)

КРАТКОЕ ОБЪЯСНЕНИЕ ТЕХНИКИ:

Приимер: есть три чекбокса

У каждого чекбокса по 2 параметра: UNCHECKED (0) и CHECKED(1). Т.Е. Количество тестов при комбинации всех параметров равно

23 = 8

Выпишем все комбинации для ПЕРВОГО и ВТОРОГО чекбоксов:

Добавим ТРЕТИЙ столбец так, чтобы во ВТОРОМ и ТРЕТЬЕМ столбце получились все 4 двоичные комбинации.

Теперь смотрим на ПЕРВЫЙ и ТРЕТИЙ столбец каких комбинаций ПАР между ними не хватает?

Добавим комбинации для ПЕРВОГО и ТРЕТЕГО столбцов. А в пустые места ВТОРОГО столба допишем НУЛИ (т.к. это не имеет значения)

Поменяем порядок комбинаций, получаем:

ЧЕТЫРЕ теста которые тестируют ВСЕ комбинации пар, вместа ВОСЬМИ изначальных. Выигрыш в 50% даже на таком простеньком примере.

В случае 13 входных параметров, каждый из которых принимает 3 значения, то количество комбинаций будет 313= 1 594 323. А ПОПАРНО, покрываются все входные значения за 15 тест кейсов!!!

* Чем больше параметров – тем эффективнее PAIRWISE техника

1) Это 2х мерный массив, в котором любые 2 столбца содержат все комбинации значений этих столбцов.

ОРТОГОНАЛЬНЫЙ МАССИВ

2) Если какая то пара значений  2х столбцов встречается несколько раз, то все возможные парные комбинации значений этих столбцов должны встретится столько же раз.

Форма записи:

1) ОПРЕДЕЛИТЕ ПЕРЕМЕННЫЕ (Необходимо выбирать входные данные, комбинации значений которых, могут логически существовать. Не исключая друг друга.)

ИСПОЛЬЗОВАНИЕ ОРТОГОНАЛЬНЫХ МАССИВОВ

3) СКОМБИНИРУЙТЕ ПАРАМЕТРЫ и постройте вручную ортогональный массив....

2) ОПРЕДЕЛИТЕ КОЛИЧЕСТВО ЗНАЧЕНИЙ для каждой переменной (Применяем разбиение на классы еквивалентности, пограничные заначения и др. простые техники для оптимизации)

Существует много инструментов работающих на алгоритме ALL-PAIRS. C данным алгоритмом можно ознакомится в книгах Lee Copeland’a.

Много из TOOLS есть тут:

http://www.pairwise.org/tools.aspЛично мне из-за удобного юая нравиться All-Pairs generator

ШУЧУ...3) ВОСПОЛЬЗУЙТЕСЬ ПРОГРАММОЙ

ГДЕ ПОДСТЕРЕГАЕТ “СЮРПРИЗ”?

1. Вы определили неверные входные значения 2. Вы определили неверные Expected Results 3. Вы не уделили внимание связям между переменными.

(!) РЕМЕМБА: Редкий, труднонаходимый и маловероятный баг, как правило, в случае проявления, имеет более серьезные последствия. (теория Н.Талеба “Черный Лебедь”)

АНАЛИЗ ОБЛАСТЕЙ ОПРЕДЕЛЕНИЯ

(DOMAIN ANALYSIS TESTING)

Equivalence Class Testing & Boundary Value Testing

Есть модуль для найма на работу Базируясь на возрасте - условия приема кандидата такие:

0–16 : Не нанимать16–18 : Можем нанять только на part time18–55 : Можем нанять на full time55–99 : Не нанимать

Данные внутри каждого возрастного диапазона (и за границами их) – это классы эквивалентности (тестируем их = Equivalence Class Testing)

Данные на границах каждого диапазона - это граничные значения (тестируем их = Boundary Value Testing)

Простой пример:

Но сперва...

ПОЧЕМУ ГРУППИРОВКА?

Equivalence Class Testing и Boundary Value Testing это тот-же самый вид тестирования, что и Domain Analysis Testing, но только для одномерногого пространства.

ТЕОРИЯ

Функция — это правило отражающее связь между параметрами (здесь: x и y)

В функции y = f (x),ОБЛАСТЬ ОПРЕДЕЛЕНИЯ ФУНКЦИИ — это все значения, которые может принимать x.

ВОТ И ВСЯ ТЕОРИЯ )))

Границы области определения (a и b) могут быть невключенными (a < x < b) или включенными (a <= x <= b) в область определения.

ПРАКТИКАВ случае тестирования функционала на который влияет 2 и более параметров, необходимо формировать тестовые данные, не только согласно классов эквивалентности и граничных значений каждого из параметров, но и учитывая логику влияния параметров друг на друга.

Делим данные на 4 типа : ON, OFF, IN, OUT

Мапим их на матрицу Биндера

ПРИМЕР

Тестируем модуль создания новой страницы. Пользователь может ввести ширину (Width) и высоту (Height) страницы (2 параметра). Ширина может иметь int от 10 до 150 включительно. Высота может иметь int от 25 до 200 включительно. Также рассчитывается отношение высоты к ширине (H/W) float

Действия:

1) Разобьем значения каждого параметра на классы эквивалентности

2) Определим строгие границы для каждого класса 3) Найдем ON, OFF, IN, OUT значения для каждой границы 4) Составим тесткейсы

ПОЛУЧАЕМ...

* Матрица Биндера – наглядный инструмент помогающий не запутаться в эквивалентнтных данных, в пограничных значениях и функциональной связи между параметрами. (Наше все!)

ИНТЕРЕСНЫЙ ФАКТ о баге в проде

Из-за неверно заданых границ области определения в функции навигационной системы истребителя F-16, при пересечения экватора, ультрасовременные на тот момент истребители самопроизвольно переворачивались вверх шасси, вниз кабиной, что стало следствием откладывания ряда военных кампаний.

Тестирование переходов состояний

State-Transition DiagramsРазберем пример резервации авиабилетов.

Клиент предоставляет информацию для резервации:место отправления, место прибытия, дату и время отправления.

• После этого резервация находится в состоянии “Made”

• После создания резервации, система запускает таймер. • Если таймер выходит, а билет не оплачен - система отменяет

резервацию.

• Если оплатили система приобретает состояние “Paid”

ГЛОССАРИЙ:

Состояние (state), круг на диаграмме - это состояние приложения, в котором оно ожидает 1 или более событий.

Переход (transition), стрелки на диаграмме - переход одного состояния в другое, происходящий по событию.

Событие (event) надпись над стрелкой - то, что заставляет приложение поменять свое состояние. События могут иметь параметры, например событие "payMoney" может иметь параметры "Cash", "Check","Credit Card“ в квадратных скобках “[]"

Действие (action) указано после "/" в надписи над преходом - это действие инициированное сменой состояния.

Точка входа - черная точка.Точка выхода - как мишень.

Продолжим...• Из состояния "Paid" - переход в состояние

"Ticketed“. ВНИМАНИЕ: при переходе в состояние "Ticketed“, авиабилет (Ticket) является входными данными состояния.

• Из состояния "Ticketed" - переход в состояние "Used" когда юзер отдает билет при посадке в самолет.

• Путь диаграммы заканчивается символом мишени.

• Если резервация не оплачена по истечению таймера, то она отменяется как неоплаченная- Cancelled Non Pay

• Отмена из состояния “Made” и “Paid” – “Cancelled By Customer”

• Отменить резервацию можно и с состояния "Ticketed”, но только если клиент вернет билет (это описывают параметры)

Но это еще не все...

Создание тест кейсовНеобходимо создать набор тест-кейсов, который должен пройти по всем переходам хотя бы раз.

* Каждое состояние диаграммы можно подробней описать в виде таблицы, и мы получим - Decision Table. * А описывая все переходы в виде сценариев, мы получим полноценные User Cases.

Вопросы или отдых?

Created by D. Protsenkoprotsenko@engineer.com