Тестирование методом “черного ящика”

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

В данной статье мы погрузимся в один из важных методов тестирования программного обеспечения, известный как «Black Box» тестирование. Метод «черного ящика» представляет собой уникальный подход к проверке приложений, основанный на исследовании их функциональности без предварительного знания внутренней структуры. Мы рассмотрим определение и назначение этого метода, его принципы и область применения, а также важные инструменты и разновидности «Black Box» тестирования. Давайте глубже погрузимся в мир тестирования программного обеспечения и узнаем, как этот метод способствует обеспечению качества и надежности программных продуктов.

Общие сведения

«Черный ящик» — это метод тестирования программного обеспечения, при котором тестировщик не имеет доступа к внутренней структуре, дизайну или реализации приложения. Вместо этого он ориентируется на требования и спецификации при разработке тест-кейсов. Следует отметить, что требования и спецификации не всегда могут существовать в письменной форме; тем не менее, при применении метода «черного ящика» мы можем опираться на устно переданные требования.

Тестирование по стратегии «черного ящика», также известное как функциональное тестирование, представляет собой метод исследования функциональности программного обеспечения без необходимости знания внутренней структуры его кода. Этот метод может быть применен на разных уровнях тестирования, но его основное применение находится на более высоких уровнях.

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

Это позволяет:

• оценить, как система реагирует на ожидаемые и неожиданные действия пользователя;
• измерить время реакции;
• оценить уровень удобства использования (юзабилити);
• выявить проблемы с надежностью.

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

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

Определение по терминологии ISTQB

По терминологии ISTQB, «черный ящик» (Black-box) тестирование представляет собой форму функционального и нефункционального тестирования, при которой нет доступа к внутренней структуре компонентов системы. Этот метод тестирования включает в себя процесс создания и выбора тестовых случаев на основе анализа спецификации (будь то функциональной или нефункциональной), компонентов или системы в целом, без необходимости знания их внутреннего устройства.

Область применения

В этом разделе мы рассмотрим наиболее часто встречающиеся сценарии использования данной методики на реальных проектах.

Интеграционное тестирование

Интеграционное тестирование — это процесс, при котором программные и аппаратные компоненты объединяются и проверяются с целью оценки их взаимодействия. В рамках метода «черного ящика» тестировщик проводит проверку того, как корректно работают все эти компоненты в совокупности, когда они интегрированы в более крупную систему.

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

Стресс-тестирование

Стресс-тестирование — это процесс, при котором система подвергается экстремальным нагрузкам, чтобы проверить ее способность выдерживать нагрузку, которая превышает нормальные рабочие условия. Например, если в документации к онлайн-букмекерской конторе указано, что система должна быть способной одновременно регистрировать 1000 пользователей, то стресс-тестирование включает в себя непрерывное создание автоматизированных аккаунтов, например, по крайней мере, 1000 регистраций в минуту, в течение 12 часов, чтобы оценить, как система справляется с такой экстремальной нагрузкой.

Usability-тестирование

Тестирование юзабилити (Usability-тестирование) — это процесс, в ходе которого анализируется удобство использования системы с точки зрения конечного пользователя. Например, если в онлайн-букмекерской конторе есть функция «Купон», то при проведении проверки работоспособности продукта и юзабилити можно измерить, сколько времени пользователю требуется для добавления ставки в купон, ввода суммы и завершения ставки, чтобы определить, насколько удобно и эффективно пользователь может использовать этот функционал.

Тестирование производительности

Тестирование производительности — это способ проверки, который позволяет оценить различные аспекты работы системы. Мы можем выявить, происходит ли утечка памяти, насколько быстро система обрабатывает данные и предоставляет обратную связь, а также определить, не потребляет ли наше программное обеспечение излишне много сетевого трафика и не создает ли избыточное количество сетевых подключений.

Приемочное тестирование

Приемочное тестирование — это этап, который наступает после завершения проверки программного обеспечения специалистами Q&A. На этом этапе заказчик запускает тесты «черного ящика» на основе ожидаемой функциональности. Обычно, набор тестов определяется самим заказчиком, и он имеет право отказаться от принятия продукта, если результаты тестирования не удовлетворяют его ожиданиям.

Регрессионное тестирование

Регрессионное тестирование проводится на протяжении всего процесса разработки программного продукта. Его основная цель — убедиться, что новый код не вызывает ошибок или не ломает уже существующей функциональности.

При выборе тестов для регрессии следует следовать определенным рекомендациям:

1. Создать набор тестов, который охватывает все функции программы.
2. Выбрать тесты, которые сосредотачиваются на тех программных компонентах или функциях, которые подверглись изменениям.
3. Использовать дополнительные тестовые случаи, с акцентом на функциях, которые, вероятно, могли бы быть затронуты изменениями.

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

Beta

Beta-тестирование — это метод проверки работоспособности продукта, при котором почти готовое программное обеспечение предоставляется пользователям для пробной эксплуатации до его официального выпуска конечным пользователям. Это позволяет выявить максимальное количество ошибок и проблем, еще до того, как продукт достигнет широкой аудитории.

Преимущества такого подхода включают:

1. Выявление непредвиденных ошибок, так как бета-тестеры могут использовать программное обеспечение в нестандартных сценариях.
2. Проведение тестирования в разнообразных средах, что сложно достичь другими методами, включая разные операционные системы, конфигурации и версии браузеров.
3. Экономию, так как часто работа бета-тестеров проводится на добровольной основе и без оплаты.

Этот метод позволяет разработчикам собрать ценные обратные связи и улучшить продукт до его официального выпуска.

Виды тестирования по принципу “Черного ящика”

На практике существует несколько подходов к тестированию методом «черного ящика», но если углубиться в основные категории, то можно выделить всего два основных типа: функциональное и нефункциональное тестирование.

Функциональное

Функциональное тестирование фокусируется на проверке соответствия функциональным требованиям или спецификациям приложения. На этом этапе проводятся проверки различных действий или функций системы, путем предоставления входных данных и сравнения полученного результата с ожидаемым.

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

К основным видам функционального тестирования относятся:

1. Smoke Testing (Дымовое).
2. Sanity Testing (Тестирование на здравый смысл).
3. Интеграционное.
4. Системное.
5. Регрессионное.
6. Приемочное.

Нефункциональное

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

Основные виды нефункционального тестирования включают:

• Юзабилити-тестирование, которое оценивает удобство использования приложения.
• Нагрузочное тестирование, направленное на оценку реакции системы при высоких нагрузках.
• Проверка работоспособности и производительности продукта, чтобы измерить скорость и эффективность приложения.
• Тестирование совместимости, чтобы убедиться, что приложение работает на разных платформах и браузерах.
• Стресс-тестирование, которое оценивает устойчивость системы при экстремальных условиях.
• Тестирование масштабируемости, чтобы определить, как система справляется с увеличением нагрузки или объема данных.

Регрессионное тестирование

Регрессионное тестирование — это процесс проверки функциональных компонентов программы с целью выяснить, не вызвала ли новая версия программы регрессию, то есть не ухудшила ли она свои функциональные возможности.

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

Методики тестирования Black Box

Методики проверки работоспособности продукта по стратегии «черного ящика» включают в себя следующие подходы:

Метод эквивалентного разделения

Вместо того чтобы тестировать все возможные входные данные, тестеры могут разделить их на группы и затем провести тестирование только на одной «представительной выборке» из каждой группы.

Например, если система требует ввода даты рождения пользователя и возвращает одинаковый результат для всех пользователей младше 18 лет и другой результат для пользователей в возрасте 18 лет и старше, то тестировщики могут протестировать только одну дату рождения в группе «младше 18» и одну дату рождения в группе «18 лет и старше».

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

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

Симуляция таблицы решений

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

Тестирование на изменение состояния

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

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

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

Поиск ошибок на основе опыта

В этом методе проводится проверка работоспособности продукта, учитывая часто встречающиеся ошибки, которые разработчики могут допустить при создании подобных систем. Например, специалисты Q&A могут проверить, была ли предусмотрена обработка значений null в поле, ввод текста в числовое поле или чисел в текстовое поле, а также очистку входных данных (например, наличие механизмов защиты от передачи вредоносного кода во входных данных пользователя, что может подвергнуть систему угрозам безопасности).

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

Поэтапное проведение тестирования

Постепенное проведение проверки работоспособности продукта играет важную роль в обеспечении высокого качества проверки проекта или приложения. Этот систематический процесс оказывает положительное воздействие на долгосрочные процессы проверки работоспособности продукта.

Один из ключевых этапов заключается в понимании спецификации требований к приложению. Здесь важно правильно задокументировать эти требования в виде спецификации требований к программному обеспечению (SRS).

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

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

Далее, после исправления дефектов, специалист по Q&A проводит повторное тестирование для проверки, были ли баги успешно устранены и не повторяются ли они.

Инструменты методики Black Box

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

Преимущества метода “Черного ящика”

Преимущества методики по типу «черного ящика» (Black-box):

• Не требуется технический опыт у тестировщика. Основное внимание уделяется проверке работоспособности продукта с точки зрения пользователя, что делает этот метод доступным даже для тех, кто не обладает глубоким техническим знанием.
• Тестирование может начаться после завершения разработки проекта или приложения. Специалисты по Q&A и разработчики могут работать независимо друг от друга, что не создает препятствий и позволяет им эффективно выполнять свои задачи.
• Этот метод более эффективен для больших и сложных приложений, где доступ к внутренней структуре может быть сложным и затруднительным.
• Возможность выявления дефектов и несоответствий на ранней стадии проверки работоспособности продукта помогает исправить проблемы до того, как они станут более критическими и дорогостоящими для исправления.

Недостатки

Недостатки метода «черного ящика» (Black-box):

• Отсутствие технических или программных знаний может привести к пропуску потенциально важных сценариев проверки работоспособности продукта , так как специалисту может не хватать понимания внутренней структуры системы.
• В ограниченное время тестирования может быть сложно охватить все возможные входные и выходные значения, что может привести к пропуску некоторых потенциальных проблем.
• Достижение полного охвата проверки работоспособности продукта (Test Coverage) оказывается невозможным для больших и сложных проектов, так как это требовало бы чрезмерных усилий и времени, и может быть несоразмерным с пользой, которую это принесет.

Сравнение между методами черного и белого ящика

В таблице ниже собраны основные сходства и отличия в этих методах тестирования:

Заключение

Метод «Black Box» представляет собой важную стратегию в области проверки программного обеспечения. Он основан на идее проверки работоспособности приложения без предварительного знания внутренних деталей его реализации. Этот метод сосредотачивается на функциональности приложения и его способности выполнять задачи согласно заявленным требованиям. Специалисты по Q&A, использующие «Black Box» метод, смотрят на программу как на «черный ящик», где важно только вход и выход, без необходимости знать, каким образом работает внутренняя структура.

Назначение «Black Box» проверки работоспособности продукта заключается в обеспечении качественной и надежной работы программного продукта. Этот метод позволяет выявить ошибки и дефекты, которые могли бы повлиять на пользовательский опыт. Метод «Black Box» может быть применено на разных этапах разработки и обеспечивает проверку как функциональных, так и нефункциональных аспектов приложения. Для успешного применения этого метода, важно следовать определенным принципам и использовать подходящие инструменты.

В области применения «Black Box» входят различные виды приложений, от веб-сайтов и мобильных приложений до сложных корпоративных систем. Этот метод помогает обнаруживать и устранять проблемы, обеспечивая надежность и эффективность программного обеспечения. Важно помнить, что «Black Box» тестирование дополняет другие методы, такие как «White Box» , и важно выбирать наилучший подход в зависимости от конкретных требований проекта.