Тестирование черным ящиком

1. Тестирование «черным ящиком»

(Black-box testing)

2. Модель

Вход (input)
magic
Выход (output)

3. Разные определения

• Testing and test design without knowledge of the code or without
usage of knowledge of the code. (BBST Foundation course)
• Тестирование черного ящика или поведенческое тестирование –
стратегия (метод) тестирования функционального поведения
объекта (программы, системы) с точки зрения внешнего мира,
при котором не используется знание о внутреннем устройстве
тестируемого объекта. Под стратегией понимаются
систематические методы отбора и создания тестов для тестового
набора. Стратегия поведенческого теста исходит из технических
требований и их спецификаций.

4.

Если вы пишете большие (особенно детальные) тест-кейсы, то
лучше основываться на их поведении с помощью черного ящика.
Программа может часто меняться (в случае рефакторинга), а
поведение программы должно оставаться прежним.
Если тест-кейсы привязывать по методу белого ящика, то их
постоянно нужно будет переписывать, увеличивать их количество.

5. Особенности внутренней реализации

• Взаимодействие с операционной системой.
• Внутренние алгоритмы.
• Взаимодействие частей системы между собой и ОС.
и др.

6. Ожидаемый результат

Ожидаемый результат обычно сравнивается
со спецификацией проекта или его требованиями
(если таковые имеются).
Нельзя описать общий ожидаемый результат.
Ожидаемый результат – это то, что ожидает
пользователь при выполнении каких-либо
действий в программе.
Пользователю не интересно что происходит
внутри программы.
Все остальное (не ожидаемые результаты) –
это результат работы программы и он не обязательно
может быть ожидаемым.

7. “Black-box” = ограничения

Зачем?
• Скиллы тестировщиков не позволяют применять иные методы
тестирования.
• Нет времени.
• Нет доступа к внутренней реализации.
• Нет смысла использовать что-то более продвинутое (слишком
дорого).
• И др.

8. Плюсы тестирования черным ящиком

• Быстрее (концентрация на главном, на массе).
• Дешевле (Меньше времени, дешевле специалисты).
• Достаточно одного специалиста или нескольких junior-ов.

9. Минусы тестирования черным ящиком

• Страдает качество тестирования.
• Не профессиональный подход к тестированию тормозит всю
разработку.

10.

Тестирование черным ящиком это такой метод, в котором
используются сознательные ограничения, которые вполне себе
могут быть оправданы контекстом проекта.

11. Виды тестирования «черного ящика»

• Функциональное тестирование. Затрагивает функциональные требования
приложения. На этом этапа тестируются различные действия или функции системы
путем представления входных данных и сравнения фактического результата с
ожидаемым.
• Основные типы функционального тестирования:
• Smoke Testing (Когда сборка готова, нужно проверить, что критически важные функции
работают как положено. Проводится перед более глубоким функциональным и
регрессионным тестированием.)
• Sanity Testing (Вид тестирования сборки ПО после изменений в коде или функциональности.
Цель – проверить, что старые ошибки исправлены, а новых не появилось. Если тест не
проходит – на доработку, а не на более тщательное тестирование. Предназначение –
убедиться, что разработчик не допустил базовых ошибок.)
• Интеграционное тестирование
• Системное тестирование
• Регрессионное тестирование
• Приемочное тестирование

12. Виды тестирования «черного ящика»

• Нефункциональное тестирование. Необходимо проводить для улучшения качества и
производительности приложения.
• Основные типы:
• Юзабилити-тестирование (определение того, насколько приложение является удобным и
простым для пользователя. В ходе такого тестирования привлекается небольшая группа
людей, которые используют приложение и находят проблемы, связанные с его удобством).
• Нагрузочное тестирование (цель – определение пиковой нагрузки, при которой система
полностью выйдет из строя)
• Тестирование производительности.
• Тестирование совместимости (цель – обеспечить бесперебойную работу ПО в различных
средах).
• Стресс-тестирование (проверка программы, используя очень большую нагрузку или много
запросов, пока программа не «сломается»).
• Тестирование масштабируемости (проверка на то, как По адаптируется к изменениям
количества пользовательских запросов. Иногда называют тестированием
производительности).

13. Эквивалентное разделение

Данная техника так же известна как разделение на классы
эквивалентности. Входные значения для приложения делятся на
различные классы или группы на основе сходства результатов.
Вместо использования каждого входного значения мы можем
выбрать только одно из группы/класса для тестирования
результата. Следовательно, сохраняется уровень тестового
покрытия при сокращении количества переделанных тест-кейсов и,
что наиболее важно, затрачиваемого времени.

14. Эквивалентное разделение

Текстовое поле “AGE” принимает только числа
от 18 до 60. Следовательно, можно выделить три
набора классов.
Два недопустимых класса будут следующими:
a) Меньше или равно 17.
b) Больше или равно 61.
Допустимый класс – от 18 до 60.
С помощью этого метода мы сократили
количество тест-кейсов до 3х, основанных на
сформированных классах, и тем самым охватили
все возможности тестирования данного поля.
Проведения проверки с любым одним значением
из каждого класса достаточно, чтобы проверить
описанный выше сценарий.

15. Анализ граничных значений

Фокусируемся на значениях на границах, поскольку было
установлено, что у многих приложений именно здесь возникает
больше всего проблем.
Границы относятся к значениям вблизи предела, при котором
меняется поведение системы. При анализе граничных значений для
проверки используются как валидные, так и невалидные входные
данные.
Если мы хотим протестировать поле, в котором допустим ввод
чисел от 1 до 100, мы выбираем граничные значения: 1-1, 1, 1+1,
100-1, 100 и 100+1. Вместо того чтобы использовать все значения
от 1 до 100, мы просто используем 0, 1, 2, 99, 100 и 101.

16. Тестирование таблицы решений

Такие таблицы используются везде, где есть логически связи
(if/else).
Затем тестировщик определит два выхода (действие 1 и действие 2)
для двух условий (True и False). Таким образом, на основе
вероятных сценариев составляется таблица решений для
подготовки тестовых наборов.

17. Тестирование таблицы решений

Возьмем пример банка XYZ,
который предоставляет
процентную ставку для
пожилых мужчин в размере
10% и 9% для остальных
людей.
В данном примере условие C1
имеет два значения true и
false, C2 также имеет два
значения true и false. Общее
количество возможных
комбинаций будет равно
четырем. С помощью
таблицы решений мы можем
создавать тестовые примеры.

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

Используется для тестирования различных
состояний проверяемой системы. Они
изменяются в зависимости от условий или
событий. Определенные события вызывают
разные состояния. Из них в результате
получаются сценарии, которые тестировщику
необходимо их протестировать.
Систематическая диаграмма переходов и
состояний дает четкое представление об
изменениях состояний, но она эффективна
для более простых приложений. Проекты
посложнее могут привести к созданию более
сложных диаграмм переходов, что делает ее
менее эффективной.

19. Предугадывание ошибок

Классический пример тестирования, основанного на опыте.
В этой технике тестировщик может использовать свой опыт как в отношении
поведения, так и функциональных возможностей приложения, чтобы угадать, какие
его модули наиболее подверженные ошибкам. Многие дефекты могут быть найдены с
помощью данной техники именно там, где большинство разработчиков их и
допускают .
Несколько распространенных ошибок, которые разработчики обычно забывают
устранить:
• Деление на ноль.
• Обработка нулевых значений в текстовых полях.
• Принятие кнопки Submit без какого-либо значения.
• Загрузка файла без вложения.
• Загрузка файла, размер которого меньше или больше установленного предела.

20. Методы тестирование на основе графов

Каждое приложение представляет собой совокупность объектов.
Все такие объекты идентифицируются, и составляется граф. Из
него определяются все связи между объектами, и для выявления
ошибок пишутся соответствующие тестовые примеры.

21. Сравнительное тестирование

В этом методе для тестирования используются различные
независимые версии одного и того же программного обеспечения,
которые сравниваются друг с другом.