Вы находитесь на странице: 1из 25

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

тестов :
1. Тестирование «белого ящика»
(white-box)
2. Тестирование «чёрного ящика»
(black-box)
3. Исследовательское
тестирование (exploratory
testing)
Осново:
• Первые три этапа:
– условия тестирования (состояние) – любой деталь
или событие компонента должно быть проверено с помощью
одного или более вариантов использования (например.
функциональности, атрибутов качества, элемент).
– тестовый случай – набор множествах входных данных,
“условия до исполнения“, ожидаемый Результат, "условия
послеисполнения “, созданных для одной состояния,
напоминающего больше упражнения.
– Процедура испытания – действий для выполнения
теста.
Схематическое изображение:
Основной базовый тест:
• Valid dates: {A..Z, ‘-’}
• Max length input = 20 char
тест
• Valid test case:
Mr Ion Craciun
Ms Ana-Maria Gutu
• Invalid test case:
Mr George1 Graf
Ms “Cort” Alina
Ms Popescu ‘Ana’
Black - box :
Black - box :
• В этом методе программа рассматривается как чёрный ящик.
Целью тестирования ставится выяснение обстоятельств, в
которых поведение программы не
соответствуетспецификации. Для обнаружения всех ошибок в
программе необходимо выполнить исчерпывающее
тестирование, то есть тестирование на всевозможных
наборахданных. Для большинства программ такое
невозможно, поэтому применяют разумное тестирование,
при котором тестирование программы ограничивается
небольшим подмножеством всевозможных наборов данных.
При этом необходимо выбирать наиболее подходящие
подмножества, подмножества с наивысшей вероятностью
обнаружения ошибок.
Приёмы тестирования чёрного ящика:

• Эквивалентное разбиение– equivalence


partitioning
• Анализ граничных значений – boundary value
analysis
• Таблицы принятия решений – decision table
testing
• Диаграмма состояний– state transition testing
• Вариант использования– use case testing
Эквивалентное разбиение:
• Основу метода составляют два положения:
– Исходные данные необходимо разбить на конечное число классов
эквивалентности. В одном классе эквивалентности содержатся такие
тесты, что, если один тест из класса эквивалентности обнаруживает
некоторую ошибку, то и любой другой тест из этого класса
эквивалентности должен обнаруживать эту же ошибку.
– Каждый тест должен включать, по возможности, максимальное
количество классов эквивалентности, чтобы минимизировать общее
число тестов.
Пример:
«Целое число принимает значение от 0 до 999», то существует один
правильный класс эквивалентности и два неправильных.
Valid class: {0..999}
Invalid class: {…….0}U{1000……}
Анализ граничных значений:
• Граничные условия — это ситуации, возникающие на
высших и нижних границах входных классов
эквивалентности.
• Анализ граничных значений отличается от
эквивалентного разбиения следующим:
– Выбор любого элемента в классе эквивалентности в качестве
представительного осуществляется таким образом, чтобы
проверить тестом каждую границу этого класса.
– При разработке тестов рассматриваются не только входные
значения (пространство входов), но и выходные
(пространство выходов).
– Метод требует определённой степени творчества и
специализации в рассматриваемой задаче.
Анализ граничных значений:
• Существует несколько правил:
– Построить тесты с неправильными входными данными для ситуации
незначительного выхода за границы области значений. Если входные
значения должны быть в интервале [-1.0 .. +1.0], проверяем −1.0, 1.0,
−1.000001, 1.000001.
– Обязательно писать тесты для минимальной и максимальной границы
диапазона.
– Использовать первые два правила для каждого из входных значений
(использовать пункт 2 для всех выходных значений).
– Если вход и выход программы представляет упорядоченное множество,
сосредоточить внимание на первом и последнем элементах списка.
– Анализ граничных значений, если он применён правильно, позволяет
обнаружить большое число ошибок. Однако определение этих границ для
каждой задачи может являться отдельной трудной задачей. Также этот
метод не проверяет комбинации входных значений.
Пример:
• В зависимости от заказанного количества
карандашей различается стоимость:
– 1 – 100 – 10 руб. за карандаш;
– 101 – 200 – 9 руб. за карандаш;
– 201 - 300 – 8 руб. за карандаш и т.д. С каждой
новой сотней, цена уменьшается на рубль.
– Максимально можно заказать – 1000 штук. Анализ
граничных значений очень интересуют границы
интервалов значений, на то он и «анализ
граничных».
Пример:
• Максимально можно заказать – 1000 штук. Анализ граничных значений очень
интересуют границы интервалов значений, на то он и «анализ граничных».
Используя метод эквивалентного разбиения, были выделены следующие классы:
• Невалидное значение: >1000 штук;
• Невалидное значение: <=0;
• Валидное значение: от 1 до 100;
• Валидное значение: от 101 до 200;
• Валидное значение: от 201 до 300;
• Валидное значение: от 301 до 400;
• Валидное значение: от 401 до 500;
• Валидное значение: от 501 до 600;
• Валидное значение: от 601 до 700;
• Валидное значение: от 701 до 800;
• Валидное значение: от 801 до 900;
• Валидное значение: от 901 до 1000.
Пример:
• Самое время взяться за граничные значения этих самых классов. Нужно брать не только
само граничное значение, но и отступать на шаг вверх/вниз (на самый, самый
малюсенький из возможных шажков). Для выше написанных классов получаем:
• 999; 1000; 1001;
• 1; 0; -1;
• 99; 100; 101;
• 199; 200; 201;
• 299; 300; 301;
• 399; 400; 401;
• 499; 500; 501;
• 599; 600; 601;
• 699; 700; 701;
• 799; 800; 801;
• 899; 900; 901;
• аналогично классу №1.
• Итак, получаем по 3 значения для границ, а также берем по одному значению из «тел»
классов эквивалентности, итого: 33 + 12 = берем для проверки 45 значений. М-м-м-м-м,
это больше 12, но гораздо меньше 1000. Да еще и проверяем не только валидные
значения, но и невалидные!
Таблица принятия решений:
• Таблица принятия решений (таблица решений) —
способ компактного представления модели со
сложной логикой. Аналогично условным операторам в
языках программирования, они устанавливают связь
между условиями и действиями. Но, в отличие от
традиционных языков программирования, таблицы
решений в простой форме могут представлять связь
между множеством независимых условий и действий.
• Таблицы принятия решений, как правило, разделяются
на четыре квадранта, как показано ниже.
Условия Варианты выполнения условий
Действия Необходимость действий
Таблица принятия решений:
• В простейшем случае здесь Условия — список
возможных условий, Варианты выполнения
условий — комбинация из выполнения и/или
невыполнения условий из этого
списка. Действия — список возможных
действий, Необходимость действий — указание
надо или не надо выполнять соответствующее
действие для каждой из комбинаций условий.
Например, для ситуации «неожиданно погас свет»
таблица принятия решений может быть такой:
Пример:
Диаграмма состояний:
• Диагра́мма состоя́ний — ориентированный
граф для конечного автомата, в котором
– вершины обозначают состояния
– дуги показывают переходы между двумя
состояниями
Пример: Диаграмма Бронирование
Вариант использования:
• Сценарий использования, вариант использования, прецедент или
же пользовательский сценарий (англ. Use Case) — в
разработке программного обеспечения исистемном проектировании это
описание поведения системы, которым она отвечает на внешние запросы.
Другими словами, сценарий использования описывает, «кто» и «что»
может сделать с рассматриваемой системой. Методика сценариев
использования применяется для выявления требований к поведению
системы, известных также как функциональные требования.
• В системном проектировании сценарии использования применяются на
более высоком уровне чем при разработке программного обеспечения,
часто представляя цели заинтересованных лиц или миссии. На
стадии анализа требований сценарии использования могут быть
преобразованы в ряд детальных требований и задокументированы с
помощью диаграмм требований SysML или других подобных механизмов.
Пример:
Тестирование «белого ящика» (white-
box)
• При тестировании белого ящика (англ. white-box testing,
также говорят — прозрачного ящика), разработчик теста
имеет доступ к исходному коду программ и может
писать код, который связан с библиотеками
тестируемого ПО. Это типично для юнит-
тестирования (англ. unit testing), при котором
тестируются только отдельные части системы. Оно
обеспечивает то, что компоненты конструкции —
работоспособны и устойчивы, до определённой степени.
При тестировании белого ящика используются
метрики покрытия кода или мутационное тестирование.
Тестирование «белого ящика» (white-
box)
Стратегия Белого ящика включает в себя следующие методы тестирования:

• покрытие операторов (подразумевает выполнение каждого оператора программы,


по крайней мере, один раз)
• покрытие решений (необходимо составить такое число тестов, при которых каждое
условие в программе примет как истинное значение, так и ложное значение)
• покрытие условий (если после составления тестов у нас останутся не покрытые
операторы, то мы должны дополнить свой набор тестов таким образом чтобы каждый
оператор выполняется не менее одного раза)
• покрытие решений и условий (необходимо составить тесты так, чтобы результаты
каждого условия выполнялись хотя бы один раз, результаты каждого решения так
же выполнялись хотя бы один раз, и каждый оператор должен быть выполнен хотя
бы один раз)
• комбинаторное покрытие условий (все возможные комбинации результатов
условий в каждом решении, а также каждый оператор выполнились по крайней мере
один раз)
Nota Bene: Покрытие кода
• Покрытие кода, по своей сути, является тестированием методом белого ящика.
Тестируемое ПО собирается со специальными настройками или библиотеками
и/или запускается в особом окружении, в результате чего для каждой
используемой (выполняемой) функции программы определяется
местонахождение этой функции в исходном коде. Этот процесс позволяет
разработчикам и специалистам по обеспечению качества определить части
системы, которые, при нормальной работе, используются очень редко или
никогда не используются (такие как код обработки ошибок и т.п.). Это позволяет
сориентировать тестировщиков на тестирование наиболее важных режимов.
• Тестировщики могут использовать результаты теста покрытия кода для
разработки тестов или тестовых данных, которые расширят покрытие кода на
важные функции.
• Как правило, инструменты и библиотеки, используемые для получения покрытия
кода, требуют значительных затрат производительности и/или памяти,
недопустимых при нормальном функционировании ПО. Поэтому они могут
использоваться только в лабораторных условиях.
Пример:
Решение: