Тестирование любят делить на разные виды, типы, методики и принципы. Сегодня мы расскажем о белом и черном ящиках. Названия звучат немного странно, но во время чтения статьи вы поймете, что за этим стоит.
Тестирование белого и черного ящиков в одном предложении
Вот самое простое определение: Тестирование белого ящика базируется на знаниях об устройстве системы. Тестирование черного ящика базируется на знаниях требований к системе.
Это и есть основной смысл и главное отличие между двумя подходами. Но в этой статье мы копнем глубже. Вот, что мы рассмотрим:
- Какие цели у тестирования белого и черного ящиков?
- В чем отличия между подходами?
- Какой подход выбрать для проекта?
Давайте открывать ящики и смотреть, что там внутри!
Что такое тестирование черного ящика?
Это подход, когда QA тестируют приложение, не зная, как оно устроено внутри, но с очень хорошим пониманием спецификации и требований. Тестирование черного ящика — это, в первую очередь, проверка того, что продукт соответствует функциональным требованиям. Такое тестирование проводится на основе документации.
Управление качеством ПО. Лекция 3 часть 3. Метод белого ящика
Тестирование черного ящика делится на:
- Функциональное тестирование — проверка функциональности приложения (“Что приложение делает?”)
- Нефункциональное тестирование — проверка производительности, безопасности, usability (“Как приложение работает?”)
В тестирование черного ящика также входит и так называемое тестирование на основе опыта (Experience-based testing). QA проверяет приложение, основываясь на интуиции и опыте тестирования других похожих проектов.
Какая цель у тестирования черного ящика?
Главная цель — проверить, что приложение разработано в соответствии с требованиями, соответствует ожиданиям клиента и не содержит ошибок.
Проводя тестирование черного ящика, нужно получить ответы на следующие вопросы:
- Работают ли все функции приложения правильно?
- Совпадает ли внешний вид приложения с макетами?
- Выполняются ли пользовательские сценарии?
- Корректны ли данные?
Как проводить тестирование черного ящика?
Проведение такого тестирования требует подготовки — вот, что нужно сделать заранее:
- Провести анализ требований и спецификаций
- Узнать о приложении в целом
- Подготовить тест-кейсы
- Подготовить тестовые данные (в том числе и для негативных сценариев)
Когда всё вышеперечисленное сделано, QA выполняет тест-кейсы и делает детальный отчет с результатами, сообщает о найденных ошибках и повторно тестирует после исправления багов разработчиками.
Все действия имеют одну важную цель: сравнить готовый разработанный продукт с требованиями и убедиться, что расхождений нет.
Как подготовить данные и тест-кейсы для тестирования черного ящика?
Глубокий анализ функциональности и вдумчивое и осознанное написание тест-кейсов позволяют значительно сократить количество тестов, которые нужно будет провести.
Черный, белый, серый ящик. Методы тестирования / Урок 11 / Тестировщик с нуля
Вот основные техники для разработки тест-кейсов для функционального тестирования:
Граничные значения
Граничные значения это входные или выходные данные (которые пользователь может вводить в поля), которые находятся в непосредственной близости от классов эквивалентности.
Классы эквивалентности
Классы эквивалентности это наборы входных данных, обработка которых приводит к одному и тому же результату.
Давайте отойдем от теории и попробуем понять, что это, на примере:
Представьте, что вам нужно протестировать поле “возраст” в форме приложения, предназначенного для людей от 20 до 30 лет. Поле принимает значения типа integer. Какие здесь будут классы эквивалентности и граничные значения?
Классы эквивалентности:
- 20-30 — позитивный тест
- От минус бесконечности до 19 и от 31 до плюс бесконечности — негативный тест
Граничные значения: 19, 20, 21, 29, 30, 31
- 20, 21, 29, 30 — позитивный тест
- 19, 31 — негативный тест
Таблица решений (Decision table)
Таблица решений показывает возможные комбинации входных данных и ожидаемых результатов. Используется для создания тест-кейсов.
Давайте рассмотрим ее на примере.
Вы тестируете онлайн магазин предлагает скидки и бесплатную доставку. Если вы размещаете заказ на сумму больше 10000 рублей, вы получаете 10% скидку. Если делать заказ на сумму больше 15000 рублей — 15% скидку. Если на сумму больше 20000 рублей — 20% скидку и бесплатную доставку. Таблица решений будет выглядеть следующим образом:
| Условия скидки | Т1 | Т2 | Т3 | Т4 |
| Заказы до 10 000 рублей | Да | |||
| Заказы больше 10 000 рублей | Да | |||
| Заказы больше 15 000 рублей | Да | |||
| Заказы больше 20 000 рублей | Да | |||
| Размер скидки | Т1 | Т2 | Т3 | Т4 |
| 10% | Нет | Да | Нет | Нет |
| 15% | Нет | Нет | Да | Нет |
| 20% | Нет | Нет | Нет | Да |
| Бесплатная доставка | Нет | Нет | Нет | Да |
Преимущества тестирования черного ящика
- QA проводит тестирование, пользуясь приложением так, как это делал бы конечный пользователь
- Позволяет найти несоответствия между спецификацией и разработанным приложением
- QA не должен глубоко погружаться в особенности разработки и архитектуры
- В рамках тестирования создается документация, включающая в себя тест-кейсы
- Тест-кейсы могут быть автоматизированы
Недостатки тестирования черного ящика
- Требования или спецификация могут быть неточными и/или непонятными, поэтому могут быть трудности с написанием тест-кейсов.
- Может быть сложно протестировать все части приложения.
Перейдем к тестированию белого ящика:
Что такое тестирование белого ящика?
Тестирование белого ящика (стеклянного ящика) проверяет исходный код и ставит целью убедиться, что он работает правильно. Инженер, занимающийся тестированием должен знать программирование на достаточном уровне. Часто такое тестирование проводят сами разработчики.
Два основных метода проведения тестирования белого ящика:
- Statement coverage testing — покрытие операторов. Во время тестирования покрывают код так, чтобы во время тестирования каждый оператор выполнился хотя бы один раз.
- Decision/Branch coverage testing — покрытие решений. Код покрывается тестами так, чтобы во время тестирования выполнились все ветки всех условных операторов.
Как подготовиться к тестированию белого ящика?
Есть много инструментов, библиотек и фрейворков для тестирования белого ящика. Мы сфокусируемся на JEST — библиотеке для тестирования JavaScript кода. То, что мы выбрали эту библиотеку не говорит о том, что она лучшая — просто на ней удобнее показывать примеры (прим.ред. — вот материал нашего читателя с подборкой best practices для Unit-тестирования фронтенда)
Рассмотрим JavaScript функцию:
function forTheArticle(a, b, c, d) < if (a >0) < if (b >0) < return a + b >else < if (c >a) < return c + a; >else < return d+b; >> > else < if (b >d) < return c + b >else < return d * a >> > module.exports = forTheArticle
Вы, скорее всего, заметили, что выполнение условий в функции будет зависеть от входных данных.
Чтобы легче понять все ветвления внутри функции, используем code2flow. Он поможет преобразовать код в граф:
Теперь мы можем приступить к написанию первого теста.
Как проводить тестирование белого ящика?
Покрытие операторов (Statement coverage testing)
Нужно подобрать входные данные и вызвать функцию таким образом, чтобы каждый из операторов выполнился хотя бы один раз. Для 100% покрытия достаточно сделать 2 теста и вызвать функцию со следующими параметрами:
const forTheArticle=require(‘./forTheArticle’) test(‘test instructions forTheArticle ‘,()=>< expect(forTheArticle(3,-4,5,0)).toBe(8) expect(forTheArticle(-1,5,0,3)).toBe(5) >)
Coverage-отчет выглядит следующим образом:
Покрытие решений (Decision coverage testing)
Из coverage-отчета на предыдущем изображении понятно, что строки 4, 9, 16 не покрыты. Чтобы покрыть их, нужно добавить тесты, которые при выполнении функции пойдут по веткам, содержащим эти непокрытые строки. Тестовые данные будут выглядеть следующим образом:
Тест будет выглядеть следующим образом:
const forTheArticle=require(‘./forTheArticle’) test(‘test decisions forTheArticle ‘,()=>< expect(forTheArticle(1,2,0,0)).toBe(3) expect(forTheArticle(3,-4,5,0)).toBe(8) expect(forTheArticle(2,-1,1,2)).toBe(1) expect(forTheArticle(-1,5,0,3)).toBe(5) expect(forTheArticle(-1,1,0,3)).toBe(-3) >)
Теперь наш coverage-отчет полностью зеленый:
Преимущества тестирования белого ящика
- Очень большая точность
- Просто автоматизировать
- Позволяет определить, где в коде произошла ошибка
- Для выполнения тестирования не нужен UI
Недостатки тестирования белого ящика
- Инженеры, выполняющие тестирование, должны знать программирование на достаточном уровне
- Иногда бывает невозможно протестировать каждый участок кода
- Фокус на тестировании кода может привести к ситуации, когда пропускаются баги, связанные с функциональностью. При этом код может работать правильно, но приложение не будет соответствовать требованиям.
Что лучше? Белый или черный ящик использовать?
Мир тестирования не черный и не белый — он серый Поэтому здесь нет правильного ответа и нет лучшего подхода.
Лучшее решение — комбинировать белый и черный ящик. Это гарантирует покрытие всего приложения тест-кейсами и качественную проверку как исходного кода, так и бизнес-функциональности.
Источник: testengineer.ru
Тестирование белой коробки — Различные инструменты и методы тестирования White Box
Тестирование является одной из важных частей разработки программного обеспечения, оно гарантирует, что все ошибки устранены, и программа работает так, как и предполагалось. Тестирование программного продукта может состоять из нескольких этапов и нескольких процедур. В этой статье мы рассмотрим один из важных подходов к процессу тестирования — тестирование «Белого ящика».
Что такое тестирование белого ящика?
Тестирование белого ящика также называется тестированием кода, тестированием прозрачного бокса, тестированием открытого бокса и структурным тестированием. Основная идея этого подхода к тестированию программного обеспечения заключается в рассмотрении внутренней структуры и кода программы для ее тестирования.
При тестировании Белого ящика тестер может видеть весь код программы, и ему поручено проверить последовательность работы входов и выходов в программе. В отличие от тестирования «черного ящика», которое в большей степени ориентировано на тестирование функциональности программы, White Box Testing занимается тестированием внутренних структур программы. Такой взгляд на программу позволяет нам работать над улучшением дизайна, удобства использования и повышением безопасности продукта.
Как вы можете догадаться, это называется тестированием белого или стеклянного ящика, потому что тестер может видеть код и другие части программы.
Что отличает тестирование белого ящика от тестирования черного ящика
Если в прошлом вы испытывали трудности при тестировании, я уверен, что вы сталкивались с тестированием Black Box. Самое большое различие между тестированием White Box и тестированием Black Box заключается в том, что в отличие от тестирования Black Box, которое проводится с точки зрения пользователя, тестирование White Box выполняется с точки зрения разработчика.
Другими словами, вместо того, чтобы смотреть на программу извне, подход White Box Testing видит внутренний код и тестирует его.
Как проводится тестирование белого ящика?
Как протестировать программу методом белого ящика
Главная Программы Тестирование программного обеспечения
Тестирование белого ящика (white box testing)
Подробности марта 30, 2016 Обновлено: 04 апреля 2016 Просмотров: 37963
В стратегии White Box (белый ящик) тестирования рассматривается внутренняя логика и структура кода. Его также называют стеклянным, структурным, открытым или прозрачным ящиком тестирования. Тесты, написанные на основе стратегии White Box тестирования включают покрытие написанного кода, ответвлений, путей, отчетности, внутренней логики кода и др.
В целях реализации метода тестирования белого ящика, тестировщик имеет дело с кодом, и, следовательно, ему необходимо владеть знаниями кодирования и логики т. е., внутренней работы кода. White Box тест также нужен в тестировщике, который взглянув на код может выяснить, какой блок/кусок кода работает неправильно.
Направления использования White Box тестирования
Крайне важно, чтобы тестер имел «структурные» знания о том, как система была внедрена. Не только код, но даже поток данных и поток управления должны быть оценены.
Участки кода, которые тестируются с помощью White Box тестирования являются:
- Покрытие кода
- Строковое покрытие
- Покрытие решений
- Покрытие условий
- Циклы
- Пути
- Покрытие потока данных
Есть три аспекта кодекса, которые проверяются в White Box тестировании, а именно:
- Было ли программное обеспечение разработано в соответствии с оригинальным дизайном программного обеспечения.
- Были ли внедрены меры безопасности в программное обеспечение и надежны ли они.
- Выяснить уязвимости указанного программного обеспечения.
Преимущества White Box тестирования
- Знание структуры внутреннего кодирования является предпосылкой при которой становится очень легко выяснить, какой тип ввода или какие данные могут помочь в эффективном тестировании приложений.
- Еще одно преимущество White Box тестирования заключается в том, что оно помогает в оптимизации кода.
- Помогает в удалении дополнительных строк кода, которые могут производить дефекты в коде.
Недостатки White Box тестирования
- Так как знание кода и внутренней структуры — это необходимое условие, то для осуществления данного вида тестирования необходим опытный тестер, а это, в свою очередь, увеличивает затраты на программное обеспечение.
- Почти невозможно заглянуть в каждый кусок кода, чтобы выяснить скрытые ошибки, которые могут создать проблемы, приводящие к сбою приложения.
Виды испытаний White/Glass Box тестирования
Модульное тестирование
Разработчик выполняет модульное тестирование, чтобы проверить, правильно ли работает конкретный модуль или блок кода. Модульное тестирование происходит на самом базовом уровне и осуществляется при разработке конкретного модуля или при встраивании определенной функции.
Статический и динамический анализ
Статический анализ состоит в просмотре кода, чтобы выяснить любые возможные дефекты в коде, динамический анализ предполагает выполнение кода и анализ выходных данных.
Строковое покрытие
В этом типе тестирования, код выполняется таким образом, что каждая строка приложения выполняется как минимум один раз. Это помогает в обеспечении, того что все инструкции выполняются без каких-либо побочных эффектов. Различные средства управления покрытиями используются, чтобы оценить процент исполняемых элементов, которые в настоящее время были протестированы. (Эти инструменты используются как строковые покрытия, а также как покрытие решений.)
Покрытие решений
Ни одно приложение не может быть написано в непрерывном режиме кодирования. В какой-то момент мы должны разветвить код для того, чтобы выполнить ту или иную функциональность. Тестирование покрытия решений помогает в проверке всех ветвей в коде, и помогает убедиться, что ветвление не приводит к непредсказуемому поведению приложения.
Тестирование утечки памяти
Когда код написан, есть вероятность, что в коде существует проблема утечки памяти, которая делает код неисправным. Поэтому, во время тестирования по методу белого ящика проверяется есть ли в коде утечка памяти. В случае утечки памяти, для программного обеспечения требуется больше памяти, и это влияет на скорость работы программного обеспечения, что делает его медленным.
Тестирование безопасности
Тестирование безопасности проводится для того, чтобы выяснить, насколько хорошо система может защитить себя от несанкционированного доступа, взлома (крекинг, любое повреждение кода и т.д.) которая имеет дело с кодом приложения. Этот тип тестирования требует сложных методов тестирования.
Мутационное тестирование
Это своего рода тестирование, в котором, приложение тестируется на код, который был изменен после фиксации определенного бага/дефекта. Оно также помогает выяснить, какой код и какая стратегия кодирования может помочь в разработке эффективной функциональности.
Кроме всех тех видов тестирования, которые приведенные выше, есть еще несколько типов, которые подпадают под оба вида стратегий тестирования черного и белого ящика, такие как: функциональное тестирование (что касается кода с целью проверки его эксплуатационных качеств), инкрементное тестирование интеграции (которая занимается тестированием добавленного в приложение кода), тестирование производительности и нагрузки (которая помогает выяснить, как тот или иной код управляет ресурсами и дает производительность) и др. Поскольку они подпадают под White Box, а также под Black Box трудно классифицировать их в любой из этих двух широких типов тестирования программного обеспечения.
Источник: juice-health.ru