Нагрузочное тестирование

Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) - это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком либо общем (разделяемом ими) ресурсе.

Основными целями нагрузочного тестирования являются:

• Оценка производительности и работоспособности приложения на этапе разработки и передачи в эксплуатацию

• Оценка производительности и работоспособности приложения на этапе выпуска новых релизов, патч-сетов

• Оптимизация производительности приложения, включая настройки серверов и оптимизацию кода

• Подбор соответствующей для данного приложения аппаратной (программной платформы) и конфигурации сервера

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

• Если интересует исследование производительности приложения, а именно времена отклика для операций на разных нагрузках в довольно широких диапазонах, включая стрессовые нагрузки то это все-таки тестирование производительности (Performance Testing)

• Если целью является понимание насколько приложение устойчиво в режиме длительного использования (исключение утечек памяти, некорректных конфигурационных настроек и т.д.) со средним уровнем нагрузки то проводится долгий (многочасовой) нагрузочный тест - это тестирование стабильности (Stability Testing). При этом анализ времен отклика может иметь место, но не быть первым приоритетом, главное чтобы система "не упала".

• Стресс тестирование (Stress Testing) имеет своей целью проверить возвращается ли система после запредельной нагрузки (и как скоро) к нормальному режиму, также целями стрессового тестирования могут быть проверки поведения системы в случаях когда, один из серверов приложения в пуле перестаёт работать, аварийно изменилась аппаратная конфигурации сервера базы данных и т.д. Отметим также, что при стрессовом тестировании проверяется не производительность системы, а её способность к регенерации после сверх нагрузки. Условия стресс-тестирования приложения обычно формируются исходя из критических бизнес-процессов его функциональности, определенными на стадии разработки требований и анализа рисков группой, ответственной за производительность.

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

В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование чёрного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing, также говорят — прозрачного ящика), разработчик теста имеет доступ к исходному коду программ и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определённой степени. При тестировании белого ящика используются метрики покрытия кода.

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

Серый ящик. Комбинация предыдущих.

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

Если мы рассматриваем все тестирование, которое можем и должны провести с программой, от начала и до конца, тестирование черного ящика занимает 35-65% от общего времени. Относительная полезность тестирования черного ящика зависит от проекта. Если в проекте все характеристики жестко запрограммированы с использованием специальной логики, то превалирует стратегия белого ящика. Когда проект основан на использовании общих алгоритмов, чье специфическое поведение определяется при помощи таблиц данных или параметров вызова, то преобладает тестирование черного ящика.