😇
На testengineer.ru мы не размещаем рекламу, но над сайтом регулярно работают несколько человек. Поддержите нас, подписавшись на телеграм-канал "Тестировщик от бога"!
ДомойОбучениеАвтоматизированное тестированиеЧто такое объемное тестирование?

Что такое объемное тестирование?

Автор

Дата

Категория

Что такое тестирование объема

Чаще называется «объемным тестированием», а также «тестированием объемов», или просто «volume testing», иногда «flood testing». Это проверка поведения приложения/сайта при получении очень большого объема данных (поэтому такое название). В первую очередь оценивается время ответа приложения (время отклика). Как источник данных может использоваться база данных, или файл описания интерфейса большого размера, и с ним производятся операции записи/чтения.

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

Свойства

● Производительность, как правило, ухудшается пропорционально объему обрабатываемых данных.

● Тестовые данные генерируются специальной программой (здесь подробнее о генераторах).

● На первых этапах разработки приложения, как правило, задействуется небольшой объем; поэтому реальное поведение приложения неизвестно до момента объемного тестирования.

● Тестовые данные при таком тестировании должны быть корректными и более-менее соответствовать реальным данным в пользовательском окружении.

● Они используются только для тестирования.

● Объемное тестирование, помимо основной своей задачи (следующий пункт), позволяет проконтролировать, что важные пользовательские данные не будут потеряны.

● Оценивается в первую очередь время ответа приложения, и в целом его поведение.

● Оценивается качество хранения данных при большой нагрузке (и надежность места хранения).

Цели

Определение «емкости» приложения — получение инсайтов (предположений) по вероятному количеству поступающих данных в тестируемом продукте и реакции на это; это количество должно быть обработано без сбоев и отказов. Знание «емкости» приложения, то есть его «пределов выносливости» — поможет планировать расширяемость (масштабируемость) и упростит создание планов на случай непредвиденных ситуаций (contingency-планов), и просто большого наплыва пользователей.

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

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

Предотвращение потерь данных — Единственный возможный способ проверить сохранность данных при многократном увеличении размера баз данных и нагрузки на них.

Минимизация операционных затрат благодаря раннему обнаружению проблем — Контроль времени отклика помогает QA-команде вовремя зафиксировать признаки назревающего отказа. В реальных приложениях компании реагируют на скачки нагрузки динамически, изменением дискового пространства или размера баз данных, при превышении некоего «порога нагрузки».

Создание планов масштабирования — Объемное тестирование помогает анализировать будущие эффекты масштабирования инфраструктуры, то есть правильно спланировать расширение существующей инфраструктуры или добавление новых компонентов.

Анализ производительности под разными нагрузками — Помогает анализировать производительность под низкой/средней/высокой нагрузкой, и гарантировать что система работает без проблем. Снижает риск потери данных и/или их перезаписи при высоких нагрузках. Объемное тестирование помогает предотвратить классическую проблему переполнения буфера и сопутствующие проблемы с безопасностью.

Точки контроля в объемном тестировании

Время ответа — В объемном тестировании определяется время ответа/отклика. Система отвечает за положенное время или нет? Если время отклика повысилось до недопустимого или случился отказ, систему «дорабатывают».

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

Качество хранения данных — Проверяет, безопасно ли хранятся данные. Если нет, они переносятся в правильное место.

Перезапись данных — Недопущение случайной перезаписи данных без предупреждения.

Сложности

Неконтролируемое «разбухание» баз данных — Это проблемно в случае реляционных баз, из-за их мощной структуры и десятков связанных баз.

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

И конечно огромные объемы данных — Тестировщик, привлеченный к «тестированию объемов», должен уметь справляться с невероятно большими объемами данных, по сравнению с другими видами тестирования производительности. Обслуживание больших дата-сетов требует умений, времени, опыта, и усложняет автоматизацию. Также разработчики должны манипулировать данными, сохраненными с более «стандартных» тестов.

Сравнение нагрузочного и объемного тестирования

Нагрузочное тестированиеОбъемное тестирование
Сосредоточено на стабильности приложенияСосредоточено на емкости приложения
Система тестируется в нормальных условияхСистема тестируется в нормальных И ненормальных условиях
Главное внимание — безопасностиГлавное внимание — хранению данных и их потере
Анализ производительности приложенияАнализ времени ответа и поведения при экстремальном объеме
Делает систему (продукт) готовой к использованию конечным пользователемГотовит к использованию, дает инсайты

Указания по объемному тестированию

● Остановите серверы и проверьте все логи

● Перед тестом выполните сценарий приложения вручную

● Немного подрегулируйте количество пользователей, по ситуации

● Если в платном продукте есть ограничения в лицензии по количеству пользователей, попробуйте обойтись меньшим объемом

● Тестируйте новые билды и регулярно

●   При достижении базовой линии (то есть целевой нагрузки), проанализируйте use-case и скорректируйте его

Выгоды объемного тестирования

● Экономия средств компании, своевременным обнаружением проблем с нагрузкой на серверы. Сэкономленные средства направляются на улучшение системы

● Быстрое создание планов масштабирования

● Идентификация проблемных точек и прочих сложностей на ранней стадии

● Система готовится к реальному применению достаточно быстро и эффективно

Недостатки объемного тестирования

● Не удастся гарантировать идеально точное выделение памяти/дискового пространства во всех реальных ситуациях

● QA-команда должна быть с опытом в тестировании баз данных

● Сделать копию реального окружения может быть сложно и долго

● Требуется много времени на покрытие всех тестовых условий, написание и выполнение сценариев, это может затянуть релиз

● В небольших системах огромный объем данных вряд ли возможен. Следовательно, такое сложное тестирование не обязательно нужно небольшим, не очень популярным приложениям

● Не всегда возможно эмулировать нужный тип поступающих данных

Инструменты

HammerDB — открытый инструмент; полученные результаты используются как бенчмарки в глобальной индустрии баз данных. Прозрачная статистика по приложениям; нет виртуальных ограничений. Практические все ведущие ИТ-компании используют этот инструмент. Поддерживает Oracle, MYSQL, SQL Server, PostgreSQL и пр. Есть дружелюбная поддержка и полная документация. Совместим со всеми Linux и Windows-платформами.

DbFit — тоже открытый инструмент, с поддержкой «разработки через тестирование» (TDD). Работает как «действующая выполняемая документация (executable documentation) по поведению системы». Хорошо поддерживает Agile-практики, TDD, рефакторинг. Улучшает качество, дизайн и обслуживание системы. Легко читаемый синтаксис, понятный людям, далеким от ИТ. Поддерживает SQL Server, Oracle; онлайн-документация с примерами.

JDBCSlim — базы данных и запросы интегрируются в Slim Fitnesse. Фокус на конфигурациях, тестовых данных и SQL-командах. Фреймворк поддерживает все распространенные базы данных; с ним могут работать разработчики, тестировщики, и бизнес-пользователи, хорошо владеющие SQL (прим.: с SQL может помочь соответствующий канал в Телеграме). 

NoSQLMap — открытый инструмент на Python. Умеет автоматически вставлять «скачки нагрузки» и прерывать конфигурации баз, что помогает оценить вероятные проблемы.

Примеры объемного тестирования

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

Компания желает оценить возможности инфраструктуры, имея перспективы расширения — Объемное тестирование поможет в планировании аппаратной части инфраструктуры — процессоров и дискового пространства, памяти и сети.

Создание планов на случай непредвиденных обстоятельств — Важно знать «красные флажки» инфраструктуры, после которых точно будет отказ. Такое тестирование позволит команде подобрать паттерны поведения системы при увеличении нагрузки. Это полезно при contingency-планировании (так называемый «План В», «Если что-то пошло не так»).

Итак

  • Тестирование объема помогает оценить поведение системы при экстремальной нагрузке, давая инсайты и паттерны поведения.
  •  Относится к нефункциональному типу, то есть не затрагивает основную функциональность приложения/сайта. 
  • QA-команда должна иметь готовый чек-лист объемного тестирования.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии
$1100*
медианная зарплата в QA в ноябре 2021

*по результатам опроса QA-инженеров в нашем телеграм-канале

Последние публикации

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать

Последние комментарии