Что такое тестирование по методу белого ящика? Что такое тестирование по методу черного ящика? Есть ли у них сходство? Чем они отличаются? Каковы технические особенности реализации каждого метода на практике?
Все эти вопросы мы рассмотрим в данной статье.
359 просмотров
Сходство тестирования по методу «черный ящик» и методу «белый ящик»
Парадоксальность в очевидности. Сходство этих двух методов заключается в том, что оба имеют общую цель – повышение качества программного обеспечения.
Действительно, в разработке программного обеспечения тестирование всегда направлено поиск ошибок. Приступая к тестированию программного обеспечения, тестировщик всегда имеет в голове какой-то тезис. И в процессе тестирования, этот тезис будет либо подтвержден, либо опровергнут.
По сути, оба метода – это как две дороги, которые ведут к одному пункту назначения под названием «качество ПО». Но это не альтернативные дороги. Чтобы добраться до заданного пункта, нужно пройти обе.
Тестировщик с нуля / Урок 6. Нефункциональное тестирование. Черный, белый и серый ящик
Различия в методах тестирования «черный ящик» и «белый ящик»
Являясь частью одного целого (т.е. обеспечения качества), тестирование по методу черного ящика и тестирование по методу белого ящика затрагивают разные аспекты качества и представляют совершенно разный подход к тестированию программного обеспечения. Если продолжить нашу аналогию с дорогой к пункту назначения, можно сказать, что это две дороги, которые, хотя и идут в одном направлении, имеют свои изгибы, ответвления и вехи.
Иными словами, данные методы тестирования имеют огромное различие в фокусном внимании.
Фокусное внимание «черного ящика»
Тестирование по методу черного ящика проверяет функциональность системы в целом, не задумываясь над тем, как и каким образом работают шестеренки в данной системе. То есть, фокусируется на том, как приложение ведет себя во время использования. Именно поэтому данный метод обычно называют поведенческим тестированием и считают низкоуровневым методом контроля качества.
Действительно, цель «черного ящика» – улучшить внешнее качество приложения. Единственное, что здесь имеет значение, это удобство дизайна для конечного пользователя, а также то, работают ли все модули должным образом, работоспособна ли заданная функциональность.
Здесь тестировщики имеют дело с так называемыми «вводами» и «возвращенными результатами». Иными словами, они проверяют каждый «ввод» и сравнивают фактически полученные результаты с ожидаемыми. Если эти два параметра совпадают для каждого «ввода» в отношении конкретной тестируемой функциональности, работа данной функции признается корректной.
Условно говоря, при тестировании по методу черного ящика важно лишь то, что «2+2=4». Не важно, почему это так и каким образом это достигается. Важно лишь то, что данный тезис должен быть подтвержден.
Фокусное внимание «белого ящика»
Тестирование по методу белого ящика, напротив, фокусируется на внутреннем устройстве приложения. Здесь тестировщик исследует исходный код, структуру каталогов, маршрутизацию, циклы и петли обратной связи и т.д.
Тестирование методом черного, белого и серого ящиков
Тестирование «белый ящик» нацелено на повышение внутреннего качества программного обеспечения и создание продукта, который:
- не имеет каких-либо «тупиков» и прочих антипаттернов,
- имеет достаточный потенциал для дальнейшего развития.
Определенно, невозможно получить информацию о вышеупомянутых аспектах, проверяя только взаимодействие ввода и возвращенного результата. Поэтому данный метод тестирования, по сути, является структурным тестированием или тестированием на основе кода и считается высокоуровневым методом контроля качества.
Особенности применяемых техник тестирования
Логично предположить, что при тестировании методами черного и белого ящиков используются совершенно разные техники. При этом, данные различия предъявляют определённые требования к навыкам тестировщиков. Так, для низкоуровневого контроля качества тестировщикам не обязательно уметь программировать. Им даже не нужно знать язык программирования, который используется для разработки этого приложения. Для проведения тестирования методом белого ящика, напротив, глубокие знания в области разработки программного обеспечения и реализованных в данном приложении технологий просто необходимы.
Техники тестирования по методу черного ящика
При тестировании методом «черного ящика» тестировщики сначала изучают спецификации тестирования программного обеспечения, после чего пробуют различные вводные данные, следуя заранее заданному набору тест-кейсов. Затем они просто сообщают разработчикам о выявленных ими проблемах, не вникая в причинно-следственные связи.
Условно говоря, здесь достаточно лишь констатировать факт, что в данной системе «2+2=5» вместо положенных «2+2=4». Установить точную причину выявленных проблем с функциональностью системы – есть задача разработчиков.
Среди техник тестирования по методу черного ящика, применяемых в нашей компании по разработке программного обеспечения, наиболее распространены:
- Анализ классов эквивалентности, при котором тестировщик группирует все возможные входные данные по классам (т.е. группам вводных данных, при которых программа возвращает результат определенного характера, без какой-либо вариативности) и проверяет фактически возвращаемый результат при взаимодействии с представителем каждого класса.
Например, при тестировании модуля расчета суммы подлежащих к уплате процентов в зависимости от срока кредитования, за класс эквивалентности мы берем все значения в одном из диапазонах сроков кредитования. Т.е., если известно, что при сроке кредитования от 180 до 360 дней ставка по кредиту составляет 10%, то для проверки правильности возвращаемых результатов достаточно ввести лишь одно значение из указанного диапазона (например, 240).
- Анализ граничных значений, где, как следует из названия, в качестве вводных данных используются только граничные значения, как по нижней, так и по верхней границе.
Так, для приведенного выше примера следует протестировать такие значения как 179, 180, 181, 359, 360 и 361.
- Предугадывание ошибок, где тестировщики используют свою экспертизу в определенной предметной области и пытаются имитировать действия и условия, которые могут привести к ошибке работы системы.
Для приведенного нами примера тестируемого модуля расчета суммы подлежащих к уплате процентов в зависимости от срока кредитования, вводами здесь могут быть нецелые значения, буквы и иные символы, а также ввода в виде диапазонов (например, 200-250).
- Нефункциональное тестирование (стресс-тесты, нагрузочные тесты и т.д.), когда проверяется производительность и масштабируемость системы, ее поведение при повышенных нагрузках, безопасность системы и т. д.
Техники тестирования по методу белого ящика
В процессе тестирования методом «белого ящика» тестировщики проверяют код, стремясь найти и исправить некорректные блоки. Как правило, для больших программ это происходит в форме написания автоматизированных тест-кейсов для обеспечения высокого уровня тестового покрытия. Однако, иногда используются и ручные тесты.
В нашей компании наиболее распространенными являются следующие техники тестирования по методу белого ящика:
- Тестирование потоков управления, при котором проверяется правильность логики кода и его способность возвращать результаты надлежащим образом. Здесь производится тестирование ветвей, операторов и путей (а также альтернатив), в процессе которого проверяется и подтверждается, что каждая ветвь, оператор и путь выполняются, срабатывают, проходятся хотя бы один раз;
- Тестирование потока данных, целью которого является поиск ошибок, ведущих к аномалиям и неправильному использованию данных и потоков данных.
Заключительный нюанс
Несмотря на то, что, говоря о методах тестирования, сначала говорится о методе «черного ящика», и только потом переходят к методу «белого ящика» (и данная статья – скорее подтверждение, нежели исключение этого паттерна), в реальной разработке последовательность применения данных методов кардинально противоположная.
Так, тестирование «черного ящика», как правило, проводится для проверки финальной сборки (как программы в целом, так и отдельного ее модуля). Это гарантирует, что взаимодействие пользователя с системой будет плавным, а реакция программы на каждое действие пользователя будет правильной и соответствующей требованиям программного обеспечения.
В свою очередь, тестирование методом белого ящика осуществляется непосредственно в процессе разработки, на завершающем этапе каждой итерации. Таким образом, ошибки кодирования могут быть обнаружены (и, соответственно, устранены) на ранней стадии разработки включительно.
Основная закономерность, которую мы определили для себя – чем лучше было проведено тестирование методом белого ящика, тем меньше ошибок будет выявлено при тестировании методом черного ящика. А следовательно, меньше доработок и исправлений.
Источник: vc.ru
Тестирование программы как «черного ящика»
Стратегия «черного ящика» — тестирование с управлением по данным или тестирование с управлением по входу-выходу. Программа рассматривается как «черный ящик». Ее цель — выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Тестовые данные используются только в соответствии со спецификацией программы (т. е. без учета знаний о ее внутренней структуре).
При таком подходе обнаружение всех ошибок в программе является критерием исчерпывающего входного тестирования. Последнее может быть достигнуто, если в качестве тестовых наборов использовать все возможные наборы входных данных.
Построение исчерпывающего входного теста невозможно. Это подтверждается двумя аргументами: нельзя создать тест, гарантирующий отсутствие ошибок; создание таких тестов противоречит экономическим требованиям (целью является максимизация числа ошибок, обнаруживаемых одним тестом).
Тестирование программы как «белого ящика»
Стратегия «белого ящика», или стратегия тестирования, управляемого логикой программы, позволяет исследовать внутреннюю структуру программы. Тестирующий получает тестовые данные путем анализа логики программы.
Исчерпывающему входному тестированию может быть поставлено в соответствие исчерпывающее тестирование маршрутов — программа проверена полностью, если с помощью тестов удается осуществить выполнение программы по всем возможным маршрутам ее графа.
- • число не повторяющих друг друга маршрутов в программе — астрономическое;
- • даже если каждый маршрут программы будет проверен, сама программа может содержать ошибки.
Источник: studref.com
Каковы правила тестирования программы как черного ящика
В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.
Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.
Что такое «черный ящик» согласно терминологии ISTQB?
Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.
Где используется метод «черного ящика»?
1. Интеграционное тестирование.
Тестирование, в котором программные и аппаратные компоненты объединяются и тестируются для оценки взаимодействия между ними. При использовании метода «черного ящика» тестировщик проверяет, корректно ли работают все компоненты в целом тогда, когда они интегрированы в большую систему. И действительно, нормальная работа каждой составляющей по отдельности – это еще не гарантия того, что они будут работать вместе в рамках всего проекта. Например, данные могут не отправиться через интерфейс, или интерфейс не отработает согласно документации. При планировании таких тестов тестировщики опираются на спецификацию.
2. Функциональное тестирование.
Используя этот метод, тестировщик проверяет, выполняет ли программное обеспечение все заявленные функции и требования клиента в полном объеме согласно документации.
3. Стресс-тестирование.
Предположим, что у нас есть букмекерская онлайн-контора, в документации к которой заявлена возможность одновременной регистрации 1000 пользователей. В этом случае стрессовым тестированием будет непрерывный поток автоматизированных регистраций (как минимум, 1000 регистраций в минуту) на протяжении 12 часов.
4. Usability-тестирование.
Пусть в упомянутой букмекерской конторе есть функционал «Купон»: мы проверяем, сколько времени уходит у пользователя для добавления ставки в купон, ввода суммы и завершения ставки.
5. Тестирование производительности.
Таким видом тестирования мы можем проверить: есть ли утечки памяти, насколько быстро система работает и выдает обратную связь, не потребляет ли наше ПО слишком много трафика и не создает ли избыточное количество подключений.
6. Приемочное тестирование.
После проверки ПО тестировщиками его отдают заказчику, который запускает приемочные тесты «черного ящика» на основе ожиданий от функциональности. Как правило, набор тестов в этом случае определяет сам заказчик, за ним же остается право отказаться от приемки (если его не устроили результаты тестирования).
7. Регрессионное тестирование.
Проводится на протяжении всего цикла разработки. Цель такого тестирования – проверить работоспособность нового кода и выяснить, не привел ли он к ошибкам или поломкам в старом функционале.
При выборе набора регрессионных тестов следует использовать следующие рекомендации:
- делаем репрезентативную выборку тестов, в которой используются все функции ПО;
- выбираем тесты, сосредоточенные на программных компонентах/функциях, которые подверглись изменениям;
- используем дополнительные тестовые примеры, уделяя основное внимание функциям, на которые с наибольшей вероятностью повлияли изменения.
Хочу обратить ваше внимание на то, что регрессионное тестирование не всегда проводится только методом «черного ящика»; для регресса также используется метод «белого ящика», особенно при поиске функций, на которые с большой вероятностью повлияли изменения.
8. Beta-тестирование.
Это тестирование также проводится методом «черного ящика». Практически готовое ПО отдают для «обкатки» желающим для выявления максимального количества ошибок еще до того, как оно попадет к конечному пользователю.
Что это дает:
- идентификацию непредвиденных ошибок (так как бета-тестеры используют ПО нестандартно);
- широкий набор окружений для проверки, который трудно обеспечить иными методами (разные операционные системы, разные настройки, разные версии браузеров);
- снижение расходов (так как работа бета-тестеров, как правило, не оплачивается).
Техники тестирования «черным ящиком»
1. Эквивалентное разбиение.
Эта техника включает в себя разделение входных значений на допустимые и недопустимые разделы и выбор репрезентативных значений из каждого раздела в качестве тестовых данных. Она может быть использована для уменьшения количества тестовых случаев. Допустим, у нас есть целая переменная N в диапазоне от -99 до 99: позитивными классами эквивалентности будут [-99, -10], [-9, -1], 0, [1, 9], [10, 99], а недействительными (негативными) – 99, пустое значение, нечисловые строки.
2. Анализ граничных значений.
Техника, которая включает в себя определение границ входных значений и выбор в качестве тестовых данных значений, находящихся на границах, внутри и вне границ. Многие системы имеют тенденцию вести себя некорректно при граничных значениях, поэтому оценка значений границ приложения очень важна. При проверке мы берем следующие величины: минимум, (минимум-1), максимум, (максимум+1), стандартные значения. Например, в том же случае -99
3. Тестирование таблицы переходов.
При данной технике сценарии тестирования выбираются на основе выполнения корректных и некорректных переходов состояний. Допустим, мы хотим записаться на прием к врачу и зарезервировать время своего приема: заходим в форму, выбираем удобное для нас время и нажимаем кнопку «Записаться». Сразу после этого выбранное нами время становится недоступно для другой записи, так как первая запись привела к изменению в базе.
4. Тестирование по сценариям использования.
Эта техника используется при написании тестов для индивидуального сценария пользователя с целью проверки его работы.
Достоинства метода
- Тестирование методом «черного ящика» позволяет найти ошибки, которые невозможно обнаружить методом «белого ящика». Простейший пример: разработчик забыл добавить какую-то функциональность. С точки зрения кода все работает идеально, но с точки зрения спецификации это – сверхкритичный баг.
- «Черный ящик» позволяет быстро выявить ошибки в функциональных спецификациях (в них описаны не только входные значения, но и то, что мы должны в итоге получить). Если полученный при тестировании результат отличается от заявленного в спецификации, то у нас появляется повод для общения с аналитиком для уточнения конечного результата.
- Тестировщику не нужна дополнительная квалификация. Часто мы пользуемся различными сервисами и приложениями, не очень в них разбираясь. Для того, чтобы открыть инстаграм и обработать свою фотографию, нам совсем не нужно знать способ реализации фильтров. Мы хотим открыть фотографию, выбрать фильтр и получить красивую картинку на выходе. Задача тестировщика, который тестирует эту функцию в инстаграм, – убедиться, что пользователь получит эту самую красивую картинку в соответствии с выбранным фильтром. При этом нам совсем не обязательно иметь какую-либо специализацию – нужны лишь телефон и инстаграм.
- Тестирование проходит «с позиции пользователя». Пользователь всегда прав, он конечный потребитель практически любого ПО, а значит, ему должно быть удобно, комфортно и понятно.
- Составлять тест-кейсы можно сразу после подготовки спецификации. Это значительно сокращает время на тестирование: к тому моменту, как продукт готов к тестированию, тест-кейсы уже разработаны, и тестировщик может сразу приступать к проверке.
Недостатки метода
- Основным недостатком метода «черного ящика» является возможность пропуска границ и переходов, которые не очевидны из спецификации, но есть в реализации кода (собственно, это и заставляет тестировщиков использовать метод «белого ящика»). Вспоминается случай, когда система получала котировки валют с биржи Forex и округляла до 3 знаков после запятой. Система успешно прошла тестирование методом «черного ящика» (так как ни одна валюта не выходила за соответствующие границы) и хорошо работала до тех пор, пока курс доллара к биткоин не вышел за границы 1000 долларов. Тестирование «белым ящиком» выявило бы ошибку: специалист увидел бы, что коэффициент конверсии валюты ограничен 3 знаками.
- Можно протестировать только небольшое количество возможных вводных (входящих) значений; многие варианты остаются без проверки.
- Тесты могут быть избыточными, если разработчик уже проверил данную функциональность (например, Unit-тестом).
- При отсутствии четкой и полной спецификации проектировать тесты и тест-сценарии оказывается затруднительно.
Подведем итоги
Из представленной информации мы можем сделать следующий вывод: метод «черного ящика» является эффективным при различных видах тестирования; но следует помнить, что некоторые ошибки невозможно найти, используя только этот метод (например, ошибки во внутренней структуре кода).
Проведение «black-box» тестирования увеличивает уверенность в том, что приложение надежно работает на широком диапазоне входных данных, так как набор тестовых данных зависит только от спецификации, а не от особенностей внутренней реализации продукта (как в случае применения методов «белого» и «серого» ящиков).
Метод «черного ящика» выгодно применять, если вы ищете:
- неправильно реализованные функции приложения или сервиса;
- ошибки в пользовательском интерфейсе;
- ошибки в функциональных спецификациях.
Для реализации наиболее полной проверки я рекомендую использовать методы «черного» и «белого» ящиков одновременно. Это позволит увеличить покрытие возможных сценариев, снизить риск пропуска ошибки, а также качественно улучшить результаты тестирования, так как приложение или сервис будет проверено двумя разными методами – с позиций пользователя и внутреннего устройства системы.
Источник: quality-lab.ru