пятница, 26 января 2018 г.

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


Черный ящик (black box testing)

Тестирование черного ящика — это когда мы не знаем, как система устроена внутри. У нас нет доступа к коду или мы не умеем его читать. Поэтому ориентируемся только на внешнее поведение или ТЗ.

Это начинающий автомобилист. Заглянуть под капот? Ой, там слишком страшно, будем верить приборам и точка.



Это основной вид тестирования, с которого все начинают. Перед тем, как залезть в код, стоит научиться писать тесты на основе сценариев использования и знаний про тест-дизайн и классы эквивалентности.


Если я сейчас открою любой сайт:

И начну его тестировать: «А что, если платьюшко именно красное поискать? А красное с белым? А книгу по автору? А если спецсимволы вбить?», и так далее → это как раз тестирование черного ящика. Доступа к коду у меня нет, я просто проверяю, как программа работает.

У меня либо есть ТЗ (как в случае Users, вот тех задание), либо его нету, как в случае интернет-магазина или форума. Составляю тесты, выполняю через интерфейс, типичный black box.

Плюсы такого подхода — так как вы не знаете код, то не верите ничему на слово. Все проверяете по ТЗ, каждое слово. А бывает такое, что разработчик упустил в требованиях какое-то условие и просто его не сделал, или сделал, но не так, как надо. Если читать сам код, то все работает правильно. Но это не совсем то, что было нужно.



Белый ящик (white box testing)

Тестирование белого ящика — это когда у нас есть доступ к коду, и мы его тестируем. Читаем сам код (статическое тестирование), запускаем в дебаге, пишем автотесты...

Если сравнивать с автомобилистом, то тут уже не новичок, а прошаренный. Сломалось что-то? Нафиг приборы, сразу лезем под капот, где все устройство чуть ли не наизусть уже знаем. Роемся там, ищем причину...


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

Как пример открытого проекта — Folks, его можно скачать, запустить, и даже написать свои автотесты, прогон которых как раз и будет тестированием самого кода, белого ящика. User interface у folks нет и не будет, так что тестирование черного ящика там недоступно.

Плюсы подхода — можно писать меньше тестов. Мы ведь знаем, что тут и тут будет работать одинаково, видим по коду. Но иногда настолько углубляемся в код, что читаем именно его, а не ТЗ, и можем пропустить какие-то баги (см плюсы черного ящика)


Серый ящик (gray box testing)

Тестирование серого ящика — это совмещение. Мы смотрим в код и понимаем, как он устроен. А потом открываем само приложение и проверяем, как этот код отображается уже в нем, но ориентируемся уже больше на ТЗ.

На примере автомобилиста это самый распространенный сценарий. Чтобы получить права, мы должны пройти специальный курс, на котором рассказывается, как устроена машина внутри → это знание кода, white box. Но потом мы начинаем кататься на своей машине и в основном ориентируемся на приборы → user interface, black box. При этом мы трактуем показания приборов на основе знаний кода.


Если говорить про тестирование, то это любое тестирование системы через интерфейс, когда у вас есть доступ к коду, но нет знаний разработчика. Да, вы можете подсмотреть в коде какие-то простейшие вещи: какой тип данных у этого значения, какие настройки у полей итд. Но вот потроха сложных методов остаются за гранью )))

В итоге мы вроде знаем, как это все устроено, но частично. Поэтому перепроверяем по черному ящику, где-то напишем чуть больше тестов для перестраховки... Вообще самый оптимальный метод тестирования: вы и в коде баги можете найти, и по ТЗ проверить!

Главное, чтобы доступ к коду дали, хотя бы частичный ツ

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

Но смысл один: мы что-то из кода знаем, а что-то нет.


См также:
White/Black/Grey Box-тестирование — тоже хорошая статья на эту тему!


PS: Статья написана в помощь студентам моей Школы для начинающих тестировщиков.

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

6 комментариев:

  1. Отличная статья, Оль. Супер.

    Я попробую собраться с силами и дополнить ее отдельной статьей (для комментария там текста многовато).

    ОтветитьУдалить
    Ответы
    1. Спасибо! Давай, ждем ))) В книге мне все равно до этой темы еще далекооооо, время есть)))

      Удалить
  2. Если коротко, эти термины больше особо не нужны. Я закончил очередной этап по классификации видов тестирования. Год назад. Такие дела.

    ОтветитьУдалить
    Ответы
    1. Да я вообще не вижу особого смысла в этой классификации. Нет, в целом, прикольно, когда есть какой-никакой опыт. Круто думать "о, я это делаю, и то, и то", плюс узнаешь новые слова... В общем, раскладываешь по полочкам.

      Но ведь это у джунов на собеседованиях спрашивают... Эх! Лучше бы задачки давали))

      Удалить
    2. Знаешь, Оль... Я отказался от собеседований. И чтения резюме.
      В последний раз пригласил двоих, рассказал чем занимаемся, техдир объяснил условия. И сразу было сделано предложение: "Если согласны, выходите в любой день. Хоть сегодня." И они вышли на работу в этот же день.

      Что касается задачек... Пришлите мне 5 багрепортов, составленных вами. А резюме оставьте себе. А на собеседовании попросить найти несколько багов. Например, в экспорте списка багов из Jira в Excel. Там этих багов довольно много.

      Удалить
    3. Ну нет, к такому я не готова, про отказ от собеседования))

      Удалить