Разобрано на пальцах несколько техник из книги Lee Copeland "A Practitioner's Guide to Software Test Design". Все что касается BlackBox Testing - cгруппированo в три раздела. Oбъяснены секреты магии Pairwise, почему тестирование областей определения переворачивает самолеты и дана краткая инструкция, как вернуть деньги за билет, если в связи с предыдущим пунктом, вы передумали лететь.

1. Основные техники
ТЕСТ ДИЗАЙНА
для
черноящичного
тестирования

2. Что скрывается
в определении
“ТЕСТ
ДИЗАЙН”?

3. ТЕСТ ДИЗАЙН
Этап процесса тестирования
ПО, на котором проектируются
и создаются тестовые случаи.

4. ОПТИМАЛЬНОЕ ТЕСТОВОЕ
ПОКРЫТИЕ тестируемого приложения
Т.Е: 1) минимум тестов
2) максимум выявленных дефектов
3) ...поменьше слайдов этой
презы
Цели

5. A Practitioner's Guide to
Software Test Design
Lee Copeland

6. A Practitioner's Guide to
Software Test Design
Lee Copeland

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

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

9. - ЭТО МАГИЯ?
- ЭТО ТЕОРВЕР, ДЕТКА

10. Простой пример: ПУСТЬ выпадение
ЕДИНИЦ на кубиках - это БАГА
Тогда вероятность ее появления для 1-го кубика равна:
P(bug) = 1/6 =0.167
Для нескольких событий – вероятность перемножается.
P(A*B) = P(A)*P(B)
P2(bug) =0.167 * 0.167 = 0.028
P3(bug) = 0.167 * 0.167 * 0.167 = 0.005
Вероятность бага
при комбинации 3х и
более паметров так
мала что ее можно
и нужно
отбрасывать

11. ЧТО ГОВОРЯТ СТАНДАРТЫ?
D. Richard Kuhn, Senior
Member, IEEE,
Dolores R. Wallace, Member,
IEEE Computer Society
Oпубликовали исследование,
проводимое IEEE для ПО
отозванных в течении 15 лет
мед. устройств.
Вывод: 98% дефектов возникают
при конфликте ПАР входных
данных или ОДНОГО входного
параметра (что PAIRWISE
TESTING также покрывает)

12. КРАТКОЕ ОБЪЯСНЕНИЕ ТЕХНИКИ:
Приимер: есть три чекбокса
У каждого чекбокса по 2 параметра:
UNCHECKED (0) и CHECKED(1).
Т.Е. Количество тестов при
комбинации всех параметров равно
23 = 8

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

14. Добавим ТРЕТИЙ столбец так, чтобы
во ВТОРОМ и ТРЕТЬЕМ столбце
получились все 4 двоичные комбинации.
Теперь смотрим на ПЕРВЫЙ и
ТРЕТИЙ столбец каких комбинаций
ПАР между ними не хватает?

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

16. Поменяем порядок комбинаций, получаем:
ЧЕТЫРЕ теста которые тестируют ВСЕ
комбинации пар, вместа ВОСЬМИ изначальных.
Выигрыш в 50% даже на таком простеньком
примере.
В случае 13 входных параметров, каждый из которых
принимает 3 значения, то количество комбинаций будет
313= 1 594 323.
А ПОПАРНО, покрываются все входные значения за 15
тест кейсов!!!
* Чем больше параметров – тем эффективнее
PAIRWISE техника

17. ОРТОГОНАЛЬНЫЙ МАССИВ
Форма записи:
1) Это 2х мерный массив, в котором
любые 2 столбца содержат все
комбинации значений этих столбцов.
2) Если какая то пара значений 2х столбцов
встречается несколько раз, то все
возможные парные комбинации значений
этих столбцов должны встретится
столько же раз.

18. ИСПОЛЬЗОВАНИЕ ОРТОГОНАЛЬНЫХ МАССИВОВ
1) ОПРЕДЕЛИТЕ ПЕРЕМЕННЫЕ (Необходимо
выбирать входные данные, комбинации значений
которых, могут логически существовать. Не
исключая друг друга.)
2) ОПРЕДЕЛИТЕ КОЛИЧЕСТВО ЗНАЧЕНИЙ
для каждой переменной (Применяем разбиение на
классы еквивалентности, пограничные заначения
и др. простые техники для оптимизации)
3) СКОМБИНИРУЙТЕ ПАРАМЕТРЫ
и постройте вручную ортогональный
массив....

19. ШУЧУ...
3) ВОСПОЛЬЗУЙТЕСЬ ПРОГРАММОЙ
Существует много инструментов работающих на
алгоритме ALL-PAIRS. C данным алгоритмом можно
ознакомится в книгах Lee Copeland’a.
Много из TOOLS есть тут:
http://www.pairwise.org/tools.asp
Лично мне из-за удобного юая нравиться All-Pairs generator

20. ГДЕ ПОДСТЕРЕГАЕТ “СЮРПРИЗ”?
1. Вы определили неверные входные значения
2. Вы определили неверные Expected Results
3. Вы не уделили внимание связям между
переменными.
(!) РЕМЕМБА: Редкий,
труднонаходимый и
маловероятный баг, как
правило, в случае
проявления, имеет более
серьезные последствия.
(теория Н.Талеба “Черный
Лебедь”)

21. АНАЛИЗ ОБЛАСТЕЙ ОПРЕДЕЛЕНИЯ
(DOMAIN ANALYSIS TESTING)

22. Но сперва...
Equivalence Class Testing &
Boundary Value Testing
Простой пример:
Есть модуль для найма на работу
Базируясь на возрасте - условия приема кандидата такие:
0–16 : Не нанимать
16–18 : Можем нанять только на part time
18–55 : Можем нанять на full time
55–99 : Не нанимать
Данные внутри каждого возрастного диапазона (и за
границами их) – это классы эквивалентности
(тестируем их = Equivalence Class Testing)
Данные на границах каждого диапазона - это граничные
значения (тестируем их = Boundary Value Testing)

23. ПОЧЕМУ ГРУППИРОВКА?
Equivalence Class Testing и Boundary
Value Testing это тот-же самый вид
тестирования, что и Domain Analysis
Testing, но только для одномерногого
пространства.

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

25. ПРАКТИКА
В случае тестирования функционала на который
влияет 2 и более параметров, необходимо
формировать тестовые данные, не только согласно
классов эквивалентности и граничных значений
каждого из параметров, но и учитывая логику
влияния параметров друг на друга.
Делим данные на 4 типа : ON, OFF, IN, OUT
Мапим их на матрицу Биндера

26. ПРИМЕР
Тестируем модуль создания новой страницы. Пользователь может
ввести ширину (Width) и высоту (Height) страницы (2 параметра).
Ширина может иметь int от 10 до 150 включительно.
Высота может иметь int от 25 до 200 включительно. Также
рассчитывается отношение высоты к ширине (H/W) float
Действия:
1) Разобьем значения каждого
параметра на классы
эквивалентности
2) Определим строгие границы
для каждого класса
3) Найдем ON, OFF, IN, OUT
значения для каждой границы
4) Составим тесткейсы

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

28. ИНТЕРЕСНЫЙ ФАКТ о баге в проде
Из-за неверно заданых границ области определения в функции
навигационной системы истребителя F-16, при пересечения
экватора, ультрасовременные на тот момент истребители
самопроизвольно переворачивались вверх шасси, вниз кабиной, что
стало следствием откладывания ряда военных кампаний.

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

30. State-Transition Diagrams
Разберем пример резервации авиабилетов.
Клиент предоставляет информацию для резервации:
место отправления, место прибытия, дату и время
отправления.
• После этого резервация находится в состоянии “Made”
• После создания резервации, система запускает таймер.
• Если таймер выходит, а билет не оплачен - система
отменяет резервацию.
• Если оплатили система приобретает состояние “Paid”

31. ГЛОССАРИЙ:
Состояние (state), круг на диаграмме - это состояние
приложения, в котором оно ожидает 1 или более событий.
Переход (transition), стрелки на диаграмме - переход одного
состояния в другое, происходящий по событию.
Событие (event) надпись над стрелкой - то, что заставляет
приложение поменять свое состояние. События могут иметь
параметры, например событие "payMoney" может иметь
параметры "Cash", "Check","Credit Card“ в квадратных скобках “[]"
Действие (action) указано после "/" в надписи над преходом - это
действие инициированное сменой состояния.
Точка входа - черная точка.
Точка выхода - как мишень.

32. Продолжим...
• Из состояния "Paid" - переход в состояние
"Ticketed“. ВНИМАНИЕ: при переходе в
состояние "Ticketed“, авиабилет (Ticket)
является входными данными состояния.
• Из состояния "Ticketed" - переход в состояние
"Used" когда юзер отдает билет при посадке в
самолет.
• Путь диаграммы заканчивается символом
мишени.

33. Но это еще не все...
• Если резервация не оплачена по истечению таймера, то она
отменяется как неоплаченная- Cancelled Non Pay
• Отмена из состояния “Made” и “Paid” – “Cancelled By
Customer”
• Отменить резервацию можно и с состояния "Ticketed”, но
только если клиент вернет билет (это описывают параметры)

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

35. Вопросы или отдых?
Created by D. Protsenko
protsenko@engineer.com