Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

Нагрузочное тестирование. Нагрузочное тестирование (Load Testing) или тестирование производительности (Performance Testing) -

Фундаментальные концепции | Семантика передачи сообщений | Актуальность в настоящий момент | Социальный компьютинг | IdeaManagement | Сферы применения | С чего начать | Ограничения | Системное тестирование программного обеспечения | Функциональное тестирование |


Читайте также:
  1. Интеграционное тестирование
  2. КОМПЛЕКСНОЕ ТЕСТИРОВАНИЕ НА ВЫЯВЛЕНИЕ ЯЗЫКОВОЙ КОМПЕТЕНЦИИ
  3. Модульное тестирование
  4. Нагрузочное тестирование
  5. Нагрузочное тестирование
  6. Письменное тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Дата добавления: 2015-08-27; просмотров: 90 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
Виды тестов регрессии| ПО как объект авторского права

mybiblioteka.su - 2015-2024 год. (0.009 сек.)