🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 16.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
В этой статье мы поговорим про тестирование по методу черного ящика: что это такое, как все работает, и почему оно важно при запуске сайтов.
Содержание:
- Что такое тестирование по методу черного ящика
- Тестирование по методу черного, белого и серого ящика
- Способы тестирования по методу черного ящика
- Как проводится тестирование по методу черного ящика
- Инструменты для обратной связи (ручное/UAT-тестирование)
- Плюсы и ограничения тестирования по методу черного ящика
- Заключение
Что такое тестирование по методу черного ящика
Тестирование по методу черного ящика — это методика для проверки работоспособности сайта или приложения без знания внутреннего кода. Таким образом, тестировщик, не обладающий знаниями о внутреннем устройстве системы, может оценить корректность ее работы.
Тестировщик просто добавляет входные условия и смотрит, что получается на выходе, а затем сравнивает полученные результаты с ожидаемыми.
В чем важность тестирования по методу черного ящика
Реальным пользователям при работе с приложением нет дела до того, как структурирован код. Им важно одно: чтобы приложение работало так, как надо. А тестирование по методу черного ящика помогает команде проверить функционал, отловить баги в юзабилити и гарантировать общее качество продукта.
Характеристики тестирования по методу черного ящика
Этот вид тестирования помогает тестировщикам взаимодействовать с приложением точно также, как это бы делали реальные пользователи. Вот четыре основные характеристики данного метода:
1. Главный акцент – на пользователей
Тестирование по методу черного ящика отражает опыт конечного пользователя. Тестировщики взаимодействуют с пользовательским интерфейсом: нажимают кнопки, отправляют формы, перемещаются по информационной архитектуре приложения (не касаясь кода). Их цель – проверить функционал, юзабилити и последовательность операций с точки зрения пользователей.
2. В основе – требования, а не реализация
Тест-кейсы разрабатываются по пользовательским и бизнес-требованиям. Внутренняя архитектура и логика в расчет не берутся. Если по задумке пользователи загружают файлы в приложение, а затем видят сообщение об успешной загрузке, то в тесте проверяется именно это (вне зависимости от процессов на бэкенде).
3. Не зависит от внутреннего кода
Тестировщикам не нужно понимать поток данных, API или логику, лежащую в основе функционала. QA-тестировщики, конечные пользователи или стейкхолдеры просто тестируют систему на наличие багов.
4. Может проводиться на нескольких уровнях
Тестирование по методу черного ящика может выполняться на многих этапах жизненного цикла разработки:
- Фаза тестирования системы – комплексные тесты всего приложения
- На этапе пользовательского приемочного тестирования (UAT) – проверка функционала на соответствие бизнес-целям
- Регрессионное тестирование – проследить, чтобы новые доработки в коде не повлияли на уже существующий функционал
Представим себе ситуацию. Вы руководите креативным агентством, и клиент хочет протестировать процесс оформления заказа на новом сайте. Клиенту не важно, как высчитывается налог на бэкенде, или как хранятся данные в корзине. Его интересует, сможет ли пользователь добавить товары в корзину, применить скидку и успешно оформить заказ.
Тестирование по методу черного, белого и серого ящика
Краткая характеристика:
- Тестирование по методу черного ящика проверяет работу сайта без знания его внутренних процессов или структур
- В тестировании по методу белого ящика предоставляется полный доступ к исходному коду, логике и структуре
- А тестирование по методу серого ящика – это нечто среднее. Тестировщики знают о внутренних процессах, но не в курсе всех нюансов
Сравнение разных видов тестирования и их роль на этапах разработки:
| Аспект | Тестирование по методу черного ящика | Тестирование по методу белого ящика | Тестирование по методу серого ящика |
|---|---|---|---|
| Назначение | Тестирует внешнее поведение приложения/ПО | Тестирует внутреннюю логику, поток данных и ветви кода | Тестирование проводится с частичным знанием внутреннего кода |
| Пример | Тестировщик заполняет форму и проверяет, что высветилось сообщение об успешной отправке | Тестировщик проверяет, насколько корректно оператор if обрабатывает пограничные случаи | Тестировщики проверяют API, зная его схему, но не зная реализации |
| Кем выполняется | QA-тестировщики, клиенты, конечные пользователи | Разработчики, SDET (инженеры-тестировщики) | QA-инженеры, тестировщики безопасности, тестировщики с ограниченным доступом |
| Когда используется | UAT-тестирование; системное, регрессионное функциональное и нефункциональное тестирование | Покрытие кода, аудиты безопасности | Интеграционные тесты, пентесты, тестирование безопасности и производительности |
| Для чего оно нужно | Проверка функционала с точки зрения пользователя | Проверка корректной работы внутренней логики | Золотая середина между пониманием внутренней структуры и знаниями на уровне пользователя; помогает выявлять более глубокие проблемы |
Для более полного тестового покрытия команды часто комбинируют сразу три вида тестирования. Так они могут находить баги, ошибки в юзабилити и уязвимости в граничных значениях.
Способы тестирования по методу черного ящика
Команда разработчиков не должна гадать над тем, что нужно протестировать. Они разрабатывают эффективные тест-кейсы для выявления ошибок, проверки пользовательского опыта и улучшения качества продукта с помощью проверенных методик.
Вот список самых популярных методик тестирования и принципы их работы:
1. Эквивалентное разделение
Эквивалентное разделение разбивает входные данные на группы или «классы», в которых каждый элемент должен вести себя одинаково. Таким образом, чтобы узнать, корректен ли полученный результат, достаточно протестировать по одному значению из каждого класса.
Например, форма принимает значение возраста от 18 до 60. Поэтому вместо тестирования каждого числа, тестировщик объединяет значения по следующему признаку:
- Допустимый диапазон: 25 (значение должно быть принято)
- Ниже допустимого диапазона: 17 (значение не должно быть принято)
- Выше допустимого диапазона: 65 (значение не должно быть принято)
Этим способом тестируется реакция системы на допустимые и недопустимые входные данные без написания избыточных тестовых сценариев.
2. Анализ граничных значений
Сталкиваясь с пограничными значениями во входных данных, большинство систем ведут себя по-разному. Анализ граничных значений как раз и занимается этими пограничными значениями, проверяя, не сломается ли код.
В качестве примера рассмотрим поле со вводом зарплаты на сайте. Оно принимает значения от $30 000 до $100 000. Тестировщики проверяют, что произойдет, если ввести $29 999 (чуть ниже граничного значения), $30 000 (в пределах диапазона), $100 000 (в пределах диапазона) и $100 005 (чуть выше граничного значения).
Благодаря таким граничным значениями можно проверить, что приложение или сайт корректно принимает и отклоняет входные значения.
3. Тестирование через таблицы решений
Таблицы решений очень эффективны, если на поведение системы влияет множество разных условий. Этот метод позволяет составить схему правил и результатов, в зависимости от сочетания условий. Далее такая таблица используется при тестировании.
Например, нужно протестировать систему оплаты подписок. Стоимость подписки зависит от двух входных параметров:
- Тип подписки (ежемесячная или годовая).
- Применен ли код скидки (Да или Нет).
В данном случае таблица решений выглядит так:
| Состояние | Правило 1 | Правило 2 | Правило 3 | Правило 4 |
|---|---|---|---|---|
| Тип подписки | Ежемесячная | Ежемесячная | Годовая | Годовая |
| Применен ли код скидки? | Нет | Да | Нет | Да |
| Ожидаемый результат | Полная стоимость | скидка 10% | скидка 15% | скидка 25% |
Каждое правило становится отдельным тест-кейсом. Кроме того, каждое правило позволяет отловить логические ошибки в том случае, если система обрабатывает сложные решения, в зависимости от нескольких входных значений.
4. Тестирование переходов состояний
Некоторые системы меняют свое поведение, исходя из своего текущего состояния (например, блокировка учетной записи после неудачных попыток входа). Этот способ проверяет, как ведет себя приложение при смене состояний. Обычно после 5 ошибок при вводе пароля аккаунт блокируется.
Для такой проверки тестировщики разрабатывают следующие тест-кейсы:
- Проверить, что пользователь сможет зайти в систему, если ошибется во вводе логина-пароля не более 5 раз
- Убедиться, что на шестой неудачной попытке входа система заблокирует доступ
- Проследить, появится ли после неудачной попытки опция «сброс пароля».
Этот метод помогает протестировать последовательности действий и системные правила, которые зависят от времени, количества попыток или условий.
5. Тестирование на основе юзкейсов
Тестирование по юзкейсам помогает конечным пользователям проверить сценарии использования от и до. Этот метод проверяет, правильно ли работает система на реальных процессах и цепочках операций.
Например, покупатель заходит на сайт онлайн-магазина, добавляет товары в корзину, применяет промокод и оформляет заказ. В данном методе сначала проверяется каждый этап по отдельности, а потом – их отлаженная работа вместе.
6. Предугадывание ошибок
Предугадывание ошибок зависит от опыта: QA-тестировщики должны мыслить как разработчики, а затем – стараться сломать систему, задействуя самые типичные ошибки. Пример: вы тестируете поле для ввода емейла в форме регистрации. Вы можете:
- Оставить поле пустым (пустой ввод)
- Ввести 300 символов (ограничение по длине)
- Ввести только цифры
- Напечатать символы или фрагменты кода
и в каждом случае нажимать Enter, чтобы намеренно вызвать сбой приложения или спровоцировать непредвиденное поведение. Именно это вы и хотите увидеть.
Рассмотрим пример с приложением Butter:
Сравним со скриншотом ниже (с валидацией емейла):
В этом типе тестирования выявляются проблемы на бэкенде, которые затем передаются разработчикам.
Как проводится тестирование по методу черного ящика
1. Соберите требования (что должна делать система?)
Перед запуском любого теста нужно собрать функциональные и нефункциональные требования. Функциональные требования – это то, что система должна делать, а к нефункциональным относятся скорость, совместимость, ожидания по части безопасности и т.д.
Это ваши базовые параметры, и все тест-кейсы будут сравнивать их с тем, что фактически происходит в программе.
Рассмотрим пример. Вы тестируете страницу входа. Базовое требование: «получить доступ к дашборду могут только зарегистрированные пользователи, которые ввели правильные логин и пароль».
Это требование служит главным ориентиром при проверке каждой комбинации ввода/вывода и оценке прохождения теста.
2. Определите входные данные и ожидаемые результаты на выходе
Определившись, что должна делать система, вы начинаете понимать, какие данные допустимы на входе и выходе. К входным данными относится все, с чем взаимодействует пользователь:
- Нажатие кнопки
- Ввод в текстовое поле
- Загрузка файла
- API-запрос
- Выбор значения из выпадающего списка
Результат – это ответ системы:
- Сообщение с подтверждением
- Редирект
- Изменения в интерфейсе
- Уведомление на почту
- Сообщение об ошибке
Пары «входные данные – результат» компонуются в тест-кейсы и помогают проверять разное поведение системы на основе заданных условий.
3. Разработайте тест-кейсы (по методам из предыдущего раздела)
Вы определились с требованиями, входными и выходными значениями. Пора переходить к тест-кейсам. Каждый тест-кейс должен придерживаться простой структуры:
- ID тест-кейса
- Входные данные
- Ожидаемые результат
- Фактические результат (заполняется в процессе тестирования)
- Статус: прохождение/непрохождение
Для разработки надежных тест-кейсов пользуйтесь методами выше. Например, классы эквивалентности помогут разделить входные данные на допустимые и недопустимые категории и определиться с результатом по каждой из них.
Через анализ граничных значений можно проверить пограничные случаи, которые чуть выше, по границе или чуть ниже допустимых ограничений. Например, в поле пароля можно ввести от 6 до 12 символов. Протестируйте ввод 5, 6, 12 и 13 символов.
Не забывайте про таблицу принятия решений. Через нее можно перечислить все условия и ожидаемые результаты и полностью охватить логическую цепочку. Пример: бесплатная доставка предусмотрена только для заказов от $50 и только для адресов в зоне доставки. Протестируйте, что произойдет с заказом в каждом из этих случаев. То есть, если сумм заказа выше $50, или заказ меньше $50, но адрес не входит в радиус доставки.
4. Запустите тесты и зафиксируйте результаты
Дописав тест-кейсы, можно перейти к их выполнению. Неотступно следуйте каждому тест-кейсу: используйте только определенные входные данные, выполняйте те же самые действия, а затем сравнивайте полученный результат с ожидаемым.
Кроме того, будьте объективны. Пусть даже результат похож на правильный, но если он не соответствует ожидаемому результату на 100%, вам следует заносить его как ошибку. Таким образом, каждый тест может быть:
- Пройденным, ЕСЛИ полученный результат на 100% соответствует ожидаемому
- Непройденным, ЕСЛИ результат неполный/неверный
- Заблокированным, ЕСЛИ вы не смогли выполнить тест (например, страница не открывается или выдает ошибку)
Запускать эти тесты в масштабе можно с помощью инструментов для автотестирования (Selenium, Cypress и т.д.). Для UAT и QA-задач присмотритесь к инструментам для ручного тестирования (Marker.io и т.д.)
5. Сообщайте об ошибках и повторно тестируйте после исправлений
При непрохождении теста вам нужно максимально подробно сообщить об этом, чтобы разработчики могли воспроизвести ошибку и исправить ее. Корректный отчет об ошибках содержит следующую информацию:
- Что вы сделали (пошагово, чтобы можно было воспроизвести)
- Что ожидали получить
- Что получили в итоге
- Визуальное подтверждение ошибки (скриншоты, записи экрана, информация о браузере и т.д.)
Всю эту информацию можно собирать через Marker.io. Если на сайте установлен виджет обратной связи, то тестировщики смогут напрямую с сайта сообщать о таких проблемах, как неработающие ссылки, 404 ошибки, проблемы со стилями или доступностью. Кроме того, к скриншотам можно добавлять аннотации:
На каждом скриншоте есть информация о браузере, логи из консоли, окно просмотра, операционная система и другая важная информация, которая поможет разработчикам воспроизвести ошибку. По каждому сообщению сразу создается тикет/задача в системе управления проектами:
Затем для более быстрого решения вопроса руководитель проекта может назначить на задачу разработчика.
Как только разработчик исправит ошибку, нужно заново проверить непройденные тестовые сценарии. Это часть регрессионного тестирования, цель которого:
- Убедиться, что ошибка действительно исправлена
- Проследить, что это исправление ничего не сломало
Инструменты для процесса тестирования по методу черного ящика
Правильно подобранный инструментарий поможет без труда автоматизировать тесты и отловить баги вручную. Вот список самых эффективных решений для разных задач.
Инструменты автоматизированного тестирования
Эти инструменты позволяют имитировать разные действия пользователей (нажатие кнопок, заполнение формы, навигация по страницам и т.д.) и проверяют работоспособность сайта, не влезая во внутренний код.
1. Selenium
Selenium — это гибкий инструмент с открытым кодом. Он поддерживает несколько браузеров и языков, а также отлично подходит для выполнения повторяемых тестов в сложных системах.
2. Cypress
Cypress – быстрый и надежный инструмент для современных веб-приложений. Он запускается напрямую в браузере, в котором тестируется приложение, поэтому идеально подходит для проверки UI и обнаружения визуальных регрессий.
3. Playwright
Playwright похож на Cypress, но в него сразу заложена поддержка кроссбраузерного тестирования (Chrome, Firefox, Safari). Хорошо подходит для сценариев сквозного тестирования.
Инструменты управления тестированием
Чтобы структурировать тест-кейсы, отслеживать прогресс и связывать тесты с требованиями/отчетами об ошибках, вам понадобятся инструменты для управления тестированием. Есть несколько достойных вариантов.
4. TestRail
TestRail помогает QA-командам управлять запусками тестов, следить за результатами и видеть информацию по тестовому покрытию. Это крайне полезно для регрессивного тестирования и планирования UAT.
5. Zephyr
Zephyr нативно интегрируется с Jira и позволяет централизованно управлять тестовыми циклами, привязывать сториз к тест-кейсам, отлавливать баги и добавлять решения.
Инструменты для обратной связи (ручное/UAT-тестирование)
6. Marker.io
Marker.io помогает технически неподкованным тестировщикам и клиентам сообщать об ошибках при ручном или UAT-тестировании. Пользователи могут отправлять ошибки напрямую сайта и добавлять в них важные для разработчиков сведения: скриншоты, логи из консоли, информацию об устройстве и даже 30-секундное видео.
Все эти данные попадают в Jira, Trello, ClickUp или другие системы управления проектами, за счет чего сокращается количество писем, которыми обычно обмениваются, пытаясь понять, что вызвало ошибку.
Плюсы и ограничения тестирования по методу черного ящика
Тестирование по методу черного ящика позволяет четко понять поведение программы снаружи. Это – главный плюс и минус данного метода тестирования.
Плюсы тестирования по методу черного ящика
- Ориентация на пользователя: Тестирование по методу черного ящика позволяет четко понять поведение программы снаружи. Это – главный плюс и минус данного метода тестирования.
- Независимость от команды разработчиков. Поскольку вам не нужно вникать по внутренний код, поучаствовать в таком тестировании может любой. Это снижает зависимость от разработчиков и ускоряет циклы тестирования.
- Широкое применение. Тестировать можно почти на всех этапах разработки сайта или приложения. Кроме того, этот метод подходит для модульного (через API), системного, регрессионного, UAT и даже нефункционального тестирования (проверка производительности или совместимости).
Минусы и ограничения тестирования по методу черного ящика
- Нельзя отловить баги на уровне кода. Тестировщики не знают внутренней структуры и поэтому не могут проверить логику, поток данных или пути управления. А разные проблемы по типу мертвого кода, утечек памяти, брешей в безопасности могут так и остаться незамеченными.
- Монотонно и затратно по времени. Ручное тестирование по методу черного ящика выполняется небыстро, особенно в крупных мобильных приложениях или сайтах с обилием юзер-флоу. Вам нужно охватить всевозможные комбинации входных данных, поэтому много времени уходит на выполнение и аналитику.
- Высокий риск пропустить граничные случаи. Если нет понимания внутренней структуры, то тесты могут выстраиваться на ожидаемом поведении пользователей. В перспективе, таким образом можно пропустить редкие или сложные сценарии ошибок. Именно поэтому всецело полагаться на результаты таких тестов довольно сложно, особенно если нет хорошо продуманных тест-кейсов.
Заключение
Тестирование по методу черного ящика помогает проверить, как сайт или приложение реагирует на ожидаемые и неожиданные действия пользователей. Это простая и масштабируемая процедура для выявления сбоев в потоках операций, проблем с юзабилити и регрессий, чтобы разработчики смогли все починить.
Данный вид тестирования не показывает проблем с кодом, но его можно сочетать с тестированием по методу белого ящика. Так вы будете полностью уверены в надежности поведения системы и ее структуры кода.
Когда лучше проводить тестирование по методу черного ящика? Перед запуском сайта/приложения, во время UAT или при любых задержках в пользовательском опыте.
Перевод статьи «What is Black Box Testing? A Practical Guide».