Lecture 06 11/15/2010 5:36:00 PM Техники тестирования. Black

Lecture 06
1/25/2016 5:27:00 PM
Техники тестирования.
Black Box testing

Техника нацеленая на функциональность определённую в спецификациях или документированой
модели системы. Техника также известная как BlackBox (or specification-based)
Черный ящик (Blackbox testing/Specification-based testing)
Основная идея в тестировании системы, как черного ящика состоит в том, что все материалы, которые
доступны тестировщику: требования на систему, описывающие ее поведение и сама система, работать с
которой он может только подавая на ее входы некоторые внешние воздействия и наблюдая на выходах
некоторый результат. Все внутренние особенности реализации системы скрыты от тестировщика, таким
образом, система и представляет собой «черный ящик», правильность поведения которого по отношению к
требованиям и предстоит проверить.
С точки зрения программного кода черный ящик может представлять с собой набор классов (или
модулей) с известными внешними интерфейсами, но недоступными исходными текстами.
Основная задача тестировщика для данного метода тестирования состоит в последовательной проверке
соответствия поведения системы требованиям. Важно понимать, что требования или спецификации не
определяют (и не должны определять) как система должна достигнуть желаемого поведения. В
спецификациях описывается желаемый результат, то что система должна делать. Описание же того «как»
система должна работать содержиться в описании архитектуры (design) системы. При тестировании чёрного
ящика проверяется именно «что» делает система.
Очень важно помнить, что не все системы созданы по чётким спецификациям. В некоторых случаях
спецификации отсутсвуют и тестеру приходится самостоятельно через общение с Project Manager’ом и
девелоперами составлять модель системы. И лишь затем эти модели используются как основа тестов.
Существует 5 техник тестирования основаных на спецификациях:
 Equivalence partitioning (Классы эквивалентности)
 Boundary value analysis (Граничные условия)
 Decision table testing
 State transition testing
 Use case testing
Equivalence partitioning (Классы эквивалентности)
При разработке тестовых примеров может возникнуть такая ситуация, в которой различные входные
значения приводят к одним и тем же реакциям системы. Если при этом такие входные значения имеют что-то
общее, то возможно объединение таких значений в классы эквивалентности, т.е. выполнение
эквивалентного разбиения множества допустимых входных значений.
Разбиение на классы эквивалентности - в первую очередь, способ уменьшения необходимого числа
тестовых примеров. Обычно, если в тест-требованиях специально не оговорено иное, при тестировании
достаточно выполнить только один тестовый пример для каждого класса эквивалентности. Разбиение на
классы эквивалентности особенно полезно, когда на вход системы может быть подано большое количество
различных значений; тестирование каждого возможного значения привело бы к слишком большому объему
тестирования.
1
Lecture 06
1/25/2016 5:27:00 PM
Рассмотренные выше граничные условия могут служить примером классов эквивалентности:
1. Значение из середины интервала.
2. Граничные значения.
3. Недопустимые значения за границами интервала.
Вместо того, чтобы тестировать все недопустимые значения, выбираются только соседние с
граничными.
При определении классов эквивалентности следует руководствоваться следующими правилами:
1. Всегда будет, по меньшей мере, два класса: корректный и некорректный
2. Если входное условие определяет диапазон значений, то, как правило бывает три класса: меньше чем
диапазон, внутри диапазона и больше чем диапазон. (Значения на концах диапазона могут
трактоваться как граничные значения.)
3. Если элементы диапазона обрабатываются по-разному, то каждому варианту обработки буду
соответствовать разные требования.
Другим примером разбиения на классы эквивалентности может служить тестирование открытия файла
по его имени. В результате тестирования необходимо определить, все ли варианты имен обрабатываются
системой согласно следующим тест-требованиям:
1. Проверить, что в случае присутствия в имени файла символов, не являющимися буквами
латинского алфавита и цифрами, система выводит сообщение об ошибке.
2. Проверить, что в том случае, когда длина имени файла превышает 11 символов, система выдает
сообщение об ошибке
3. Проверить, что система не различает регистр символов имени при открытии файла.
4. Проверить, что при открытии файлов с именами, не противоречащими требованиям 1-3, система
открывает файл.
Входными значениями тестового примера являются различные имена файлов, выходными – реакция
системы (ошибка или успешное открытие). Можно выделить следующие классы эквивалентности:
По длине имени:
1. Длина имени меньше 11 символов
2. Длина имени равна 11 символам
3. Длина имени больше 11 символов По символам:
4. Имя, состоящее из цифр и букв смешанного регистра
5. Имя, состоящее из цифр и букв нижнего регистра
6. Имя, состоящее из цифр и букв верхнего регистра
7. Имя, состоящее только из цифр
8. Имя, состоящее только из букв
9. Имя, включающее знаки препинания (не буквенно-цифровые символы)
10. Имя, включающее управляющие символы (не буквенно-цифровые символы)
Эти классы эквивалентности иллюстрируют, что проверки на границах интервалов применимы не
только для тестирования арифметических операций и операций сравнения. Практически для любых данных,
даже текстовых, можно определить «минимальные» и «максимальные» допустимые значения.
Exercise: Предположим, что у вас есть банк предоставляющий кредит с плавающей процентной ставкой:
2
Lecture 06
1/25/2016 5:27:00 PM
1.5 % если сумма не превышает $1000
1% если сумма кредита не превышает $2000
0.5% если сумма кредита не превышает $3000
Вам нужно убедиться, что банк правильно обрабатывает ваши запросы на кредиты. Какие классы
эквивалентности тут можно выделить?
Также могут выделяться классы эквивалентности выходных данных. Подход обратный классу
эквивалентности входных данных: на выходе будет получена процентная ставка в 1.5% если в качестве
кредита была использована сумма от $1 до $1000.
Boundary value analysis (Граничные значения)
Анализ граничных значений. Помимо ошибок вызываемых каким-то значением из списка допустимых часто
возникают ошибки на околограничных значениях: значениях наиболее приблежённых к граничным, но в
допустимой зоне, непосредственно граничное значение (всё ещё допустимо) и недопустимые значения
приближённые к граничному значению.
Ошибки граничных значений могут быть вызваны неправильными заданием типа принимающей
переменной, неправильной валидацией и т.п.
То есть, предположим, что программа принимает в качестве допустимых значения от 1 до 99. Минимально
допустимое значение 1, максимально допустимое 99. Это граничные значения. Проверка граничных
значений подразумивыает тест 0, 1, 2 и 98, 99, 100.
Например, температура кипения воды – граничные значения, которые необходимо было бы проверить – 99,
100 и 101 градус.
►Exercise:
Для оценки результатов проведения собеседований была введена стобалловая система. 100 – максимум, 1 –
минимум.
Собеседование считается пройденым при 40 баллах. Существует следующая градация:
1 - 40 баллов – отказать
41 – 60 – добавить в базу данных потенциальных сотрудников в будущем
61 – 100 – принять на работу
Каковы здесь граничные значения?
Decision table testing (таблица принятия решений)
Часто спецификации описывают функциональность, которая становится доступной при выполнении
некоторых условий. Если рассматривать какую-то одну конкретную функциональность, то список логических
условий обычно коротким, но если брать какую-то комплексную функциональность список логических
условий может быть достаточно большим.
Таблица принятия решений перечисляет все возможные условия, которые могут влиять на функциональность
и непосредстенно действия, которые будут иметь место при различных комбинациях условий.
3
1/25/2016 5:27:00 PM
Lecture 06
Структура Decision table
Business rule 1
Business rule 2
Business rule 3
Condition 1
True
False
True
Condition 2
True
True
True
Condition 3
True
-
False
Action 1
Yes
No
Yes
Action 2
No
Yes
Yes
Для Business rule 1 – если выполняются все три Conditions то происходит Action 1.
Action 2 – не происходит.
В реальности количество условий, которые приводят к каким-то действиям может быть очень большим, но
список условий влияющих непосредственно на одно действие не так велик.
То есть для того чтобы ограничить список тестируемых условий и сконцентрироваться на нужной части
выбираются только необходимые условия для получения action. Условия, которые также могут быть
выполнены в программе, но не имею непосредственного отношения к выбраной функциональности
упускаются.
Пример:
Таблица принятия решений для системы скидок в супермаркете.
Business rule 1
Business rule 2
Business rule 3
False
True
False
-
-
True
Скидка
No
Yes
No
Очки за лояльность
No
Yes
No
Выдать loyalty card
No
Yes
Yes
Conditions:
Клиент c loyalty card
Потрачено более 1000 лей
Actions:
4
Lecture 06
1/25/2016 5:27:00 PM
Основываясь на этой таблице приниятия решений составляются тест кейсы. Благодаря таблице мы уверены,
что покроем все комбинации и напишем кейсы с необходимым покрытием.
 ПРИШЁЛ ПОКУПАТЕЛЬ И СОВЕРШИЛ ПОКУПКИ НА 5000 ЛЕЙ С LOYALTY CARD. ЧТО СДЕЛАЕТ СИСТЕМА?
State transition testing (тестирование изменения состояния)
Предыдущие подходы были применимы в сетуациях когда разная комбинация условий приводит к
действиям.
Рассмотрим подход, применяемый к системам в которых действия провоцируются изменением состояния.
Другими словами, поведение зависит от текущего и предыдущего состояния. И это изменение провоцирует
действие.
Диаграмы state transition
Для построения state transition diagram используются следующие символы:
Первый:
State 1
Cимвол состояния. Система находится в указаном состоянии и изменится только если произойдёт какое-то
событие.
Второй:
Символ изменения одного состояния в другое. Изменением может быть вызвано событием (например,
нажатием кнопки). Этот символ будет сопровождаться описанием действия, которое произошло (например,
была нажата кнопка “Ok”)
К событиям также можно отнести какой-то input данных, например, было проапдейтчено поле в базе
данных.
5
1/25/2016 5:27:00 PM
Lecture 06
Пример
Надо обратить внимание на то, что не все действия приводят к изменению состояния.
Помимо создания схем существует близкий подход. Создаются таблицы состояния (state table). State Table
описывает все возможнные события и все возможные статусы.
State tables являются промежуточным слоем между state transition diagram и непосредствено созданием
кейсов.
State Table основаный на диаграме описаной выше
Mode
Alt
Set
Set Hrs
Mode = Time
N
Mode = Altimeter/Change
Display to Altimeter
Mode = Altimeter
N
Mode = Time/Change
Display to Time
Set Hrs
Set Mins
N
Set Mins/Change
Display to Mins
N
Set Hrs/Add 1 to Hrs
Mode = Time/Change
Display time
N
Set Mins/Add 1 to Mins
6
Lecture 06
1/25/2016 5:27:00 PM
Use case testing
Эти тест сценарии описывают взаимодействие между «пользователем» и системой. Под «пользователем»
здесь подразумивается определённый тип пользователя. Use cases – тест сценарии направленые на
симуляцию действий пользователя определённого типа (или просто пользователя)
Например, существует приложение по удалённому преподаванию через интернет. У этой системы будут как
минимум два пользователя:
- Учитель – создаёт курс
- Студент – изучает курс, сдаёт экзамен.
То есть в зависимости от типа пользователя будет использоватся определённая функциональность. Или одна
и та же функциональность но с разными целями.
7