Краткий обзор:
Все мы имеем представление о функциональном и нефункциональном тестировании, но помните ли вы о том, что нефункциональное тестирование так же важно, как и функциональное? Временами мы склонны игнорировать нефункциональное тестирование, особенно в краткосрочных релизах, чего в идеале делать не следует.
Не имеет значения, предъявил заказчик такое требование или нет. Мы всегда должны принимать его во внимание как часть полного процесса тестирования даже для небольших релизов.
Из этого учебного пособия по объемному тестированию вы подробно узнаете, что это такое, его необходимость, важность, какие бывают чек-листы и другие инструменты.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
Содержание:
- Что такое объемное тестирование?
- Когда это тестирование является обязательным?
- Почему я должен стремиться к объемному тестированию?
- Каков мой контрольный список для этого тестирования?
- Объемное тестирование в сравнении с нагрузочным тестированием
- Как проводить это тестирование?
- Инструменты для объемного тестирования
- Заключение
Что такое объемное тестирование?
Объемное тестирование – это вид нефункционального тестирования. Его проводят для проверки объема данных, который способна обрабатывать система. Объемное тестирование помогает определить уровень производительности программного обеспечения при работе с огромными базами данных.
Размер базы данных растягивают до максимальных значений методом добавления в нее большого объема информации, затем проверяют реакцию системы.
Это была теория, позвольте мне привести нескольких практических примеров, чтобы помочь вам понять, в какой момент наступает очередь объемного тестирования.
Когда оно обязательно?
В идеале каждое программное обеспечение должно быть проверено на обработку объемов данных, но иногда, когда их объем не столь велик, мы стараемся избегать этого вида тестирования. В тех ситуациях, когда данные ежедневно обрабатываются в мегабайтах или гигабайтах, объемное тестирование, безусловно, должно быть проведено.
Ниже привожу несколько примеров из моего 8-летнего опыта:
Пример 1:
Одним из моих проектов была большая система, которая состояла из мобильного и веб-приложений. В веб-приложении было три модуля, над которыми работали три разные команды.
Иногда даже у нас система притормаживала в тот момент, когда мы все одновременно добавляли данные для тестирования. Это раздражало и мешало работе, из-за огромного объема данных для облегчения процесса нам приходилось достаточно часто очищать БД.
Объем данных, который обрабатывался веб-приложением, был достаточно велик, поэтому оно тестировалось очень часто. Чтобы не мешать другим участникам процесса, команда QA, работающая над веб-версией, разработала автоматизированные тесты, которые запускались по ночам.
Пример 2:
Другой пример – экосистема, в которой было не только веб-приложение, но и приложение SharePoint и даже программа установки. Все системные элементы обращались к одной и той же базе данных для передачи информации. Объем данных, обрабатываемый этой системой, был очень большим, и если по какой-либо причине БД замедлялась, даже установщик переставал запускаться.
Следовательно, объемное тестирование проводилось регулярно, а производительность БД постоянно отслеживалась на предмет возникновения любых проблем.
Точно так же мы можем взять в качестве примера приложения, которые мы используем ежедневно для покупок, заказа билетов, финансовых операций и т.д., которые работают с большими объемами данных и, следовательно, нуждаются в объемном тестировании.
С другой стороны, не всегда возможно провести идеальное объемное тестирование, поскольку в этом процессе имеются свои ограничения и проблемы.
Вот некоторые из них:
- Трудность в создании точной фрагментации памяти.
- Сложность процесса динамической генерации ключей.
- Создание идеального окружения.
- Влияние средств автоматизации, сетей и т.д. на результаты тестирования.
Теперь мы имеет представление о том, когда нам нужно проводить этот тип тестирования. Давайте также разберемся, для чего мы должны его проводить.
Зачем проводят объемное тестирование
Объемное тестирование помогает понять, как приспособить вашу систему под реальные условия, а также экономит финансы, которые впоследствии могут быть потрачены на техническое обслуживание.
Ниже приведены причины для проведения такого тестирования:
- Основная потребность – это анализ работы системы на фоне серьезного увеличения объема данных. Это помогает понять ее уровень производительности с точки зрения времени ответа, потери данных и т.д.
- Выявить проблемы, которые могут возникнуть при работе с огромными БД, и пороговую точку роста этих БД.
- Понять поведение системы за пределами пороговой точки, т.е. при сбое в работе БД (невосприимчивость, истечение времени ожидания).
- Реализовать решения для перегрузки БД и проверить их.
- Определить крайнюю точку БД (когда невозможно что-либо исправить), за пределами которой система выйдет из строя, и принять меры предосторожности.
- В случае присутствия более одного сервера БД, выявить проблемы с обменом данных между БД, т.е. установить, какие из них наиболее подвержены сбоям и т.д.
Теперь мы знаем, почему так важно проводить объемное тестирование.
Как только вы понимаете, что именно необходимо проверить для вашей системы или приложения, следующее, что нужно сделать – составить список того, “что” нужно протестировать.
Чек-лист для объемного тестирования
Перед тем, как перейти к примерам создания чек-листов для объемного тестирования вашего приложения или системы, давайте сначала разберем несколько моментов, которые следует при этом учесть.
О чем следует помнить:
- Держите разработчиков в курсе вашего плана тестирования, поскольку они многое знают о системе и могут помочь вам с исходными данными и проблемами возникновения узких мест.
- Перед разработкой стратегии тестирования хорошо изучите физические аспекты конфигурации сервера, оперативной памяти, процессора и т.д.
- Вникните в сложность БД, их процедур и скриптов и т.д. до такой степени, чтобы вы могли описать трудности всей системы в целом.
- Подготовьте инфографику, т.е. графики, таблицы данных и т.д., если это возможно, для корректной работы системы при нормальном объеме данных. Это поможет вам убедиться в том, что до того, как увеличится нагрузка на БД, производительность будет в порядке. Также вы сможете быть уверены в отсутствии проблем, требующих исправлений, перед тем, как вы перейдете к стрессовой части объемного тестирования.
Примеры проверок, которые можно использовать в чек-листах :
- Проверьте правильность методов хранения данных.
- Проверьте, имеются ли в системе необходимые ресурсы памяти или нет.
- Проверьте, есть ли риск превышения указанного объема данных.
- Проверьте и понаблюдайте за ответом системы на изменение объема данных.
- Проверьте, не теряются ли данные во время тестирования.
- Убедитесь, что если данные перезаписываются, то это происходит с предварительным уведомлением.
- Определите области, которые выходят за рамки обычного диапазона, например, большое количество атрибутов (доступных для поиска), поисковых таблиц, множество карт с геолокацией и т.д.
- Сначала проведите базовое тестирование, получив результаты при загрузке нормальным объемом данных, затем переходите к стрессовому.
Прежде чем мы перейдем к другим примерам, тест-кейсам и инструментам, давайте сначала разберемся, чем этот вид тестирования отличается от нагрузочного.
Сравнение объемного и нагрузочного тестирования
Ниже приведены основные различия между объемным и нагрузочным тестированием:
Объемное тестирование | Нагрузочное тестирование |
---|---|
Объемное тестирование выполняется для проверки производительности БД при большом объеме данных. | Нагрузочное тестирование проводится путем изменения пользовательской нагрузки на ресурсы и проверки их производительности. |
Основное внимание при тестировании уделяется "данным". | Основное внимание при тестировании уделяется "пользователям". |
База данных нагружена до максимального предела. | Сервер испытывает максимальную нагрузку. |
Пример - создание файла огромного размера. | Пример - создание большого количества файлов. |
Как провести это тестирование?
Объемное тестирование проводят как вручную, так и с использованием инструментов автоматизации. В целом, применение инструментов экономит время и усилия. Также, как показывает мой опыт, автоматизированное тестирование дает более точные результаты в сравнении с ручным.
Перед началом выполнения тест-кейсов убедитесь, что:
- Команда согласовала план данного тестирования.
- Другие команды вашего проекта хорошо информированы об изменениях в базе данных и их влиянии на работу.
- Тестовые стенды настроены на заданные конфигурации.
- Подготовлена тестовая база.
- Готовы конкретные объемы данных для тестирования (сценарии данных или процедуры и т.д.).
Рассмотрим примеры тест-кейсов:
Проверьте эти моменты для всех выбранных объемов данных:
- Можно ли успешно добавлять данные и отражаются ли они в приложении или на сайте.
- Удаление данных может быть успешно выполнено, и его результат отражается в приложении или на сайте.
- Обновление данных может быть успешно выполнено, и его результат отражается в приложении или на сайте..
- Не происходит потери данных, вся информация отображается в приложении или на сайте в соответствии с ожиданиями.
- Время ожидания загрузки приложения или веб-страниц не истекло из-за большого объема данных
- Ошибки сбоя не отображаются из-за большого объема данных.
- Данные не перезаписываются, отображаются соответствующие предупреждения.
- Другие модули сайта или приложения не выходят из строя или не прерывают работу при большом объеме данных.
- Время отклика БД находится в пределах допустимого диапазона.
Инструменты для тестирования объема данных
Как упоминалось выше, автоматизация тестирования экономит время и дает более точные результаты. Еще одним плюсом использования инструментов является возможность ночного запуска тестов, поэтому работа других команд или их членов не будет зависеть от объема данных БД.
У нас есть возможность запланировать тесты на утро и уже получить готовые результаты.
Список инструментов для объемного тестирования :
1. DbFit:
Инструмент с открытым исходным кодом, который поддерживает разработку через тестирование.
Фреймворк тестирования DbFit написан поверх Fitness, тесты пишутся с использованием таблиц и могут быть выполнены с помощью любого Java IDE или CI-инструмента.
2. HammerDb:
HammerDb – это также инструмент с открытым исходным кодом для сравнительного анализа баз данных. Он работает с SQL, Oracle, MYSQL и т.д.
3. JdbcSlim:
Команды JdbcSlim могут быть легко интегрированы в Slim Fitness, он поддерживает все базы данных с драйвером JDBC. Основной фокус направлен на разделение конфигурации, тестовых данных и SQL-запросов.
4. NoSQLMap:
Это инструмент Python с открытым исходным кодом, предназначенный для автоматического внедрения атак и нарушения конфигураций БД с целью анализа угроз. Он работает только для MongoDB.
5. Ruby-PLSQL-spec:
PLSQL может быть протестирован с помощью Ruby, поскольку Oracle доступен с открытым исходным кодом. Для этого используются две библиотеки: Ruby-PLSQL и Rspec.
Заключение
Объемное тестирование – это нефункциональное тестирование, которое проводится для анализа производительности базы данных. Оно может выполняться как вручную, так и с помощью инструментов автоматизации.
Если вы – QA инженер, не знакомый с этим видом тестирования, я бы посоветовал сначала попробовать поработать с инструментами или выполнить несколько тест-кейсов перед тем, как приступить к процессу. Это поможет вам лучше понять концепцию объемного тестирования,
Оно довольно сложное, со своими нюансами, поэтому очень важно глубоко понимать его суть, уметь создавать тестовые окружения и знать язык БД перед его проведением.
Надеюсь, это пособие добавило вам знаний по данной теме 🙂
Перевод статьи «Volume Testing Tutorial: Examples and Volume Testing Tools».
Пингбэк: 35 вопросов на собеседовании QA
Пингбэк: Тестирование производительности. Большой учебник
Пингбэк: 50+ вопросов и ответов на собеседовании по QA