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

• Определение
• Цели и свойства
• Важные моменты
• Преимущества и недостатки
• Проблемы в процессе
• Чем отличается от нагрузочного
• Указания по проведению
• Инструменты
• Примеры

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

Чаще называется «объемным тестированием», а также «тестированием объемов», или просто «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-команда должна иметь готовый чек-лист объемного тестирования.