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

Преимущества тестирования черного ящика

• 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

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

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

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

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

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