😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеUnit-тестированиеТестирование белого ящика vs тестирование черного ящика

Тестирование белого ящика vs тестирование черного ящика

Автор

Дата

Категория

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

Тестирование белого и черного ящиков в одном предложении

Вот самое простое определение: Тестирование белого ящика базируется на знаниях об устройстве системы. Тестирование черного ящика базируется на знаниях требований к системе.

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

  • Какие цели у тестирования белого и черного ящиков?
  • В чем отличия между подходами?
  • Какой подход выбрать для проекта?

Давайте открывать ящики и смотреть, что там внутри!

Что такое тестирование черного ящика?

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

Тестирование черного ящика делится на:

  • Функциональное тестирование — проверка функциональности приложения (“Что приложение делает?”)
  • Нефункциональное тестирование — проверка производительности, безопасности, usability (“Как приложение работает?”)

В тестирование черного ящика также входит и так называемое тестирование на основе опыта (Experience-based testing). QA проверяет приложение, основываясь на интуиции и опыте тестирования других похожих проектов.

Какая цель у тестирования черного ящика?

Главная цель — проверить, что приложение разработано в соответствии с требованиями, соответствует ожиданиям клиента и не содержит ошибок.

Проводя тестирование черного ящика, нужно получить ответы на следующие вопросы:

  • Работают ли все функции приложения правильно?
  • Совпадает ли внешний вид приложения с макетами?
  • Выполняются ли пользовательские сценарии?
  • Корректны ли данные?

Как проводить тестирование черного ящика?

Проведение такого тестирования требует подготовки — вот, что нужно сделать заранее:

  • Провести анализ требований и спецификаций
  • Узнать о приложении в целом
  • Подготовить тест-кейсы
  • Подготовить тестовые данные (в том числе и для негативных сценариев)

Когда всё вышеперечисленное сделано, QA выполняет тест-кейсы и делает детальный отчет с результатами, сообщает о найденных ошибках и повторно тестирует после исправления багов разработчиками.

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

Как подготовить данные и тест-кейсы для тестирования черного ящика?

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

Вот основные техники для разработки тест-кейсов для функционального тестирования:

Граничные значения

Граничные значения это входные или выходные данные (которые пользователь может вводить в поля), которые находятся в непосредственной близости от классов эквивалентности.

Классы эквивалентности

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

Давайте отойдем от теории и попробуем понять, что это, на примере:

Представьте, что вам нужно протестировать поле “возраст” в форме приложения, предназначенного для людей от 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 теста и вызвать функцию со следующими параметрами:

TC 1 [3, -4, 5, 0]

TC 2 [-1, 5, 0, 7]

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 не покрыты. Чтобы покрыть их, нужно добавить тесты, которые при выполнении функции пойдут по веткам, содержащим эти непокрытые строки. Тестовые данные будут выглядеть следующим образом:

TC 1: [1, 2, 0, 0]

TC 2: [3, -4, 5, 0]

TC 3: [2, -1, 1, 2]

TC 4: [-1, 5, 0, 3]

TC 5: [-1, 1, 0, 3]

Тест будет выглядеть следующим образом:

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

Недостатки тестирования белого ящика

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

Что лучше? Белый или черный ящик использовать?

Мир тестирования не черный и не белый — он серый 🙂 Поэтому здесь нет правильного ответа и нет лучшего подхода.

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

3 КОММЕНТАРИИ

Подписаться
Уведомить о
guest

3 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
Михаил Авдеев
Михаил Авдеев
1 год назад

Главное не сыграть в ящик)
Статья конечно основы основ, но спасибо — для новичков то, что надо.

andy
andy
1 год назад

Не тестирование ящика, а тестирование методом белого ящика. Исправьте, пожалуйста.

Anny
Anny
1 год назад

Я как раз новичок, крутая статья, без воды. Как раз перед прочтением, посмотрела вебинар на эту тему длительностью 2 часа и, ни слова больше, чем описано в этой статье, не сказали.
Спасибо!

$1100*
медианная зарплата в QA в ноябре 2021

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

💬 Telegram-обсуждения

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

Последние комментарии