Что такое тестирование Черного Ящика — это стратегия или метод тестирования, базируется только лишь на тестировании по функциональной спецификации и требованиям, при этом не смотря во внутреннюю структуру кода и без доступа к базе данных. Фактически мы знаем какой должен быть результат при определенном наборе данных, которые подаються на вход. Результат проверяем с юзер интерфейса на уровне простого пользователя. На данный момент такая стратегия является наиболее часто применима в IT компаниях.
Серый ящик (Grey box testing)
Чуть меньшее количество тестировщиков тестируют стратегией серого ящика, который подразумевает частичный доступ, например к структуре баз данных или наборов параметров, которые принимают сервисы.
Белый ящик (White box testing)
Наименьшая часть тестировщиков, способны анализироваь чужой код и заниматься написанием тестов даже не запуская программу или приложение а только базируясь на коде, эта стратегия называеться белым ящиком. Может использоваться в дополнение к черному и серому ящикам. Таких специалистов на рынке очень мало, и они скорее всего бывшие разработчики ушедшие в тестирование или увлекающиеся программированием.
Тестирование методом черного, белого и серого ящиков
Подробнее о черном ящике
Давайте подробнее разберем тестирование черного ящика. Суть заключается в том что для тестирования черным ящиком нам впринципе будет достаточно требований и функциональной спецификации для того чтобы протестировать программу, не заглядывая «внутрь» как же там все работает. Нам достаточно знать что должно быть при таком-то поведении пользователя и при таких-то наборах данных (зависит от специфики проекта).
Проанализировав требования и спеку мы легко можем определить тест кейсы для проверки различной функциональности. Потом, когда программа или приложение будет разработано просто пройдемся по шагам и проверим наш ожидаемый результат с тем что мы фактически имеем, при этом не заглядывая дальше юзер интерфейса нашей программы. Это самая типичная задача тестировщика, и это все можно назвать тестированием методом черного ящика.
- IevgeniiKucherenko
- 13 сентября 2014, 17:18
Источник: software-testing.org
Тестирование черный ящик программы
Существуют различные стратегии тестирования, которые используются для проверки системы против различных типов возможных ошибок. В этой статье я расскажу о стратегии тестирования черного ящика, а также различных ее видах, где тестеру не требует знаний внутренней логики или структуре кода программы.
Тестирование черного ящика — это тип тестирования, в котором функциональные возможности программного обеспечения тестируются без каких-либо ссылок на внутренний дизайн, код или алгоритм, используемый в программе.
Черный, белый, серый ящик. Методы тестирования / Урок 11 / Тестировщик с нуля
Тестовые случаи обычно построены вокруг требований и спецификации программного приложения. Тестирование «черного ящика» также иногда называют «Непрозрачное тестирование», «Функциональное/Поведенческое тестирование» и «тестирование Закрытого ящика».
Тестирование по стратегии чёрного ящика заключается в выборе соответствующих данных в соответствии с функциональными возможностями системы и ее тестирования в отношении функциональных спецификаций для того, чтобы проверить наличие нормального и ненормального поведения системы. В наше время многие компании для получения точных результатов передают испытание своих работ третьим лицам. Это происходит потому, что Разработчик системы очень хорошо понимает внутреннюю логику и кодирование системы, что делает его непригодным для тестирования его приложения.
В целях реализации стратегии тестирования черного ящика, тестировщик должен иметь полное представление о спецификации требований системы, и ее поведения в ответ на конкретные действия.
Различными типами тестирования, которые подпадают под стратегии тестирования черного ящика являются: функциональное тестирование, стресс-тестирование, тестирование на отказ и восстановление, объемное тестирование, тестирование приемлемости для пользователей (также известное как «Пользовательское приемочное испытание»), санитарное тестирование (проверка согласованности), дымовое тестирование, нагрузочное тестирование, юзабилити-тестирование, исследовательское тестирование, ad-hoc тестирование (тестирование без формализации самого процесса), альфа-тестирование, бета-тестирование и т.д.
Эти виды тестирования можно разделились на две группы:
а) тестирование, в котором пользователь выступает в роли тестера.
б) пользователь не требуется.
Методы тестирования, в которых пользователь не требуется
Функциональное тестирование (Functional Testing): в этом типе тестирования, программное обеспечение проверяется на соответствие функциональным требованиям, т.е. то, что система должна делать. Для этого пишутся тестовые сценарии, и проверяется: работает ли система должным образом.
Объемное тестирование (Volume Testing): в этом тестировании посредством приложения (которое проходит испытание) обрабатывается большой объем данных, чтобы проверить работу программы, в ситуациях, когда система может быть подвергнута большим потокам данных.
Стресс-тестирование (Stress Testing): приложение тестируется за пределами нормальных условий функционирования, таких как сложные численные значения, большое количество входов и запросов чтобы проверить нагрузку, которую приложение может выдержать.
Нагрузочное тестирование (Load Testing): приложение тестируется с большими нагрузками, такими как тестирование по всей базе данных, чтобы выяснить максимальную эксплуатационную мощность, а также загруженность которая ухудшает ее производительность.
Дымовое тестирование (Smoke Testing): это тестирование проводится с целью проверки наиболее важных функций приложения, работают ли они без сбоев, при ожидаемом уровне нагрузки. Оно проверяет стабильность системы и готова ли она для дальнейшего тестирования.
Санитарное тестирование (Sanity Testing): Также известно, как узкое регрессионное тестирование или проверка согласованности, определяет, будет ли приложение нормально работать после внесения незначительных изменений в код или функциональных возможности без внесения каких-либо новых ошибок.
Тестирование на отказ и восстановление (Recovery Testing): это делается, чтобы проверить, как быстро и хорошо приложение может восстановиться после любого типа аварии или сбоя оборудования. Тип или степень восстановления указана в спецификации требований.
Специальное тестирование (Ad hoc Testing): также известно, как тестирование в полном хаосе, этот тип тестирования проводится без какого-либо формального плана тестирования. Специальное тестирование помогает в определении объема и длительности других методов тестирования, а также помогает тестерам в изучении приложения до запуска каких-либо других испытаний.
Исследовательское тестирование (Exploratory Testing): это делается для того, чтобы узнать/изучить приложение, чтобы определить, как работает программа, и как она будет обрабатывать различные тестовые случаи.
Юзабилити-тестирование (Usability Testing): это тестирование называют также тестированием на удобство. Оно проводится, чтобы проверить, может ли предполагаемый пользователь удовлетворить свои требования через тестируемую систему.
Методы тестирования для которых требуется пользователь
Приемочное тестирование пользователями (User Acceptance Testing (UAT)): в этом типе тестирования, программное обеспечение передается пользователям чтобы определить, удовлетворяет ли оно их требованиям и ожиданиям и работает ли оно так как ожидается.
Альфа-тестирования (Alpha Testing): Альфа-тестирование проходит в центре разработки, где система тестируется пользователями или клиентами, чтобы проверить, все ли их требования были соблюдены. Любой тип аномального поведения в системе отмечается разработчиками и устраняется соответствующим образом.
Бета-тестирование (Beta Testing): в этом типе тестирования программа распространяется для пользователей в виде бета-версии. Они тестируют программное обеспечение на своих компьютерах/сайтах/устройствах и записывают любые ошибки или дефекты, с которыми они столкнулись во время процесса. Затем они сообщают о них разработчикам.
Источник: juice-health.ru
Home
В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.
Так называемое «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» тестирования увеличивает уверенность в том, что приложение надежно работает на широком диапазоне входных данных, так как набор тестовых данных зависит только от спецификации, а не от особенностей внутренней реализации продукта (как в случае применения методов «белого» и «серого» ящиков).
Метод «черного ящика» выгодно применять, если вы ищете:
- неправильно реализованные функции приложения или сервиса;
- ошибки в пользовательском интерфейсе;
- ошибки в функциональных спецификациях.
Для реализации наиболее полной проверки я рекомендую использовать методы «черного» и «белого» ящиков одновременно. Это позволит увеличить покрытие возможных сценариев, снизить риск пропуска ошибки, а также качественно улучшить результаты тестирования, так как приложение или сервис будет проверено двумя разными методами – с позиций пользователя и внутреннего устройства системы.
Источник: www.software-testing.ru