При тестировании белого ящика разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.
При тестировании чёрного ящика тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идет правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе.
Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.
Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования».
Различают следующие виды тестирования:
Функциональное тестирование. Этот вид тестирования проверяет соответствие реализованных функций требованиям, техничесокму заданию, спецификациям, различным другим проектным документам и просто ожиданиям пользователя. Проверяется каждая из функций приложения и все они в комплексе. Исследуются все сценарии использования. Проверяется адекватность хранимых и выходных данных, методы их обработки, обработка вводимых данных, методы хранения данных, методы импорта и экспорта данных и т.д. в зависимости от специфики приложения.
Конфигурационное тестирование. Этот вид тестирования позволяет проверить как приложение ведет себя при различных разрешениях экрана, в различных браузерах, на различных операционных системах, с разным программным и аппаратным обеспечением.
Тестирование безопасности. Такой вид тестирования позволяет убедиться, что данные хранятся надежно, доступ к ним блокирован для посторонних лиц. Данные в процессе хранения, обработки и иной работы с ними не могут быть получены методами несанкционированного доступа. Проверяется защищенность БД, каналов связи, интерфейсов ввода и транспорта данных.
Нагрузочное тестирование. Этот вид тестирования позволяет выявить уровень критических нагрузок при работе с БД, интернет серверами, сетями и другими ресурсами. При помощи автоматизированных тестов можно воспроизвести типичные сценарии действий пользователя и многократно умножить их количество, смоделировав, таким образом, как поведет себя система при 100 или 10000 активных пользователях.
Тестирование usability. Проверяется удобство пользования продуктом. Исследуется на примере группы испытуемых как пользователь воспринимает продукт, как он представляет себе пути его использования, сколько времени затрачивает на то или иное действие, какие проблемы у него возникают и в состоянии ли он их решить.
Автоматизированное тестирование. Тестирование в автоматическом режиме при помощи программных скриптов позволяет автоматизировать процесс. Это удобно, когда продукт часто меняется, но при этом обладает большой функциональностью. Автоматизированное тестирование позволяет отслеживать, что все функции продукта стабильны после внесения в него изменений. Автоматизированное тестирование можно встраивать в цикл разработки приложений выполняя его после каждой новой сборки или при создании новой версии. При этом присутствие человека не требуется, скрипт может работать ночью, когда вы спите.
Автоматизированное тестирование
Автоматизированное тестирование, это не только и не просто выполнение тестов. Автоматизация может быть представлена в большинстве процессов тестирования, начиная от планирования и заканчивая тем самым запуском тестов.
Планирование и контроль. Здесь выполняется выбор необходимого объема тестов на основе рисков или иной методики; распределение тестов между сотрудниками; контроль за их выполнением; определение количества тестов, их состояния и свойств.
Анализ и отчётность. Подразумевается построение отчётов разных форм и направленности на основе данных о проводимой работе, как для нужд рабочей команды, так и для более высокого руководства.
Контроль ошибок. Сюда относятся багтрекинговые системы всевозможных вариаций.
Создание тестов. Имеется в виду предварительная автогенерация: на основе кода - для unit-тестов, на основе функциональных требований - для ручных тестов, генерация по принципу record’n’play и т.п.
Анализ покрытия / трассировка. Выполняется для оценки покрытия кода, требований или некоторого объема функциональности теми или иными типами тестов, созданных на предыдущем этапе.
Выполнение тестов. Запуск тестовых скриптов и анализ полученных результатов.
Цели автоматизированного тестирования:
Первое, и наиболее популярное, – это тестирование производительности во всех своих инкарнациях: нагрузочное, стрессовое, на стабильность. Популярное по той причине, что без автоматизации его выполнить невозможно. По этой же причине имеется широкий выбор инструментария от разных производителей и столь же высокие цены, даже в случае неудобного и слабофункционального инструмента.
Следующим идёт регрессионное тестирование. Что означает проверку ПО на корректность функциональности, выпущенной и тщательно протестированной в предыдущей версии. Выполняется с регулярной частотой, задаваемой в зависимости от условий: у кого-то с каждым новым билдом, у кого-то с каждой версией для заказчика.
Конфигурационное тестирование – выполнение одних и тех же тестов в разных условиях. То есть когда один или несколько компонентов архитектуры системы требуется проверить в разном окружении, обычно заявленном в изначальных требованиях. Например: поддержка СУБД от разных производителей, работа в разных клиентских браузерах, использование в нескольких ОС и т.п. То есть некий аналог регрессионного тестирования, но в рамках одной версии системы. Кроме средств контроля за выполнением работ, в данном случае, нелишней бывает возможность автоматического сравнения полученных результатов выполнения сценариев в разных конфигурациях.
Функциональное тестирование. Ясно, что это просто проверка нового функционала. Иногда бывает, что без автоматизации никак не обойтись. Даже если нужно выполнить тестирование только один раз. Обычно, впоследствии эти тесты и используются для регресса.
Установочное тестирование, как понятно из названия, выполняется для проверки условий инсталляции (и настройки) продукта с учётом тех или иных требований к системе от заказчика. В данном случае автоматизировать тесты удобно не только для проверки, как таковой, но и для их последующего использования ручными тестировщиками с целью уменьшить объём работ при установке очередного билда.
При всём многообразии перечисленных нами целей тестирования, поддающихся автоматизации, техник тестирования заметно меньше. И их применение часто зависит от поставленных целей, специфики тестируемого ПО и опыта ваших сотрудников.
Во-первых, это unit-тестирование. Не модульное в общем понимании, а техника написания тестов разработчиками на основе и для исходного кода. Наиболее активно сейчас о ней говорится в agile-методологиях. Хотя и в классических процессах разработки может приносить много пользы, если правильно начать использовать.
Сюда же относится тестирование web-интерфейса через запросы, посылаемые от браузера, которым иногда заменяют проверку пользовательского интерфейса. Наиболее удобно его использовать для нагрузочного тестирования. Но иногда имеет смысл совмещать и с функциональным тестированием, раз уж всё-равно приходится такие скрипты разрабатывать.
Тестирование GUI (пользовательского интерфейса) – то, о чём обычно идёт больше всего разговоров. И что далеко не всегда удается успешно внедрить. Обычно применяется на уровне системного тестирования для поиска регрессионной зависимости.
Автоматизированное тестирование всегда имеет как плюсы:
так и минусы:
Кроме того, после окончания разработки какого-то функционала все остальные прогоны разработанных для него автоматизированных скриптов будут лишь давать уверенность, что ничего не сломалось.
Иногда трудозатраты на разработку тестового окружения могут заметно превысить ручной вариант выполнения, даже если придётся тесты гонять каждый день. Некоторые тестовые случаи просто невозможно автоматизировать по разным причинам: