Тестирование программного обеспечения обычно разделяют на множество типов.
Здесь вы найдете функциональное тестирование, модульное тестирование, тестирование безопасности и многое другое.
Есть также редкие подтипы, такие как юзабилити-тесты или тестирование локализации.
Но загадочное для многих нагрузочное тестирование всегда стояло особняком.
Одной из основных причин этого являются высокие требования к уровню технических знаний инженера, решившего проверить работоспособность продукта под нагрузкой и его возможность масштабирования.
Предлагаем вам вместе с нами глубже разобраться в вопросе в этой статье.
Нагрузочное тестирование — основы
Если усреднить сухие определения из Интернета, то окажется, что нагрузочное тестирование направлено на эмуляцию нагрузки, создаваемой большим количеством пользователей или операций.И его цель: найти максимальные значения производительности тестируемого ПО, за пределами которых его работа перестает быть стабильной.
Нет ничего сложного в том, чтобы взять, например, легковой автомобиль, посадить в него пять человек, положить в багажник три мешка картошки, завести его и ехать по прямой.
Гораздо важнее понять, какое расстояние он сможет проехать с таким грузом, как поведет себя на разных дорожных покрытиях и когда ему потребуется технический осмотр.
И потребуются ли здесь конструктивные изменения.
Определение таких вещей гораздо важнее для качества продукта, чем просто нахождение предельных значений.
Поэтому мы предлагаем договориться о следующем определении: нагрузочное тестирование — это определение качества работы продукта под определенной нагрузкой в течение заданного интервала времени.
Звучит не очень ясно, правда? Попробуем расширить эту идею: наша задача — определить, насколько изделие выдерживает повышенную нагрузку, как оно ведет себя при длительной эксплуатации, какие узкие места обнаруживаются и как их можно устранить.
Продолжая аналогию с нашей несчастной легковушкой, получается, что наша задача не просто нагружать ее до тех пор, пока машина не сможет сдвинуться с места, а, постепенно добавляя нагрузку, проверить ее поведение в как можно большем количестве жизненных сценариев.
Они сели на борт пассажиров и попытались тронуться.
Получилось хорошо, а значит основная функция продолжает нормально работать.
Что будет, если мы будем ездить так весь день? Если мы потратим на 30% больше бензина, это приемлемо или нет? А если в пять раз больше, то что? Как поведет себя машина при подъеме на гору с уклоном 12 градусов? Что делать, если дорога не асфальтированная, а грунтовая, и идет дождь? Ехали в гору, а как поведут себя тормоза на спуске и какой будет тормозной путь? Вот и может оказаться, что мешки с картошкой класть не будет смысла, потому что.
наша машина перестала выполнять свои функции уже с четвертым пассажиром, и загружать ее уже нет смысла.
Роль нагрузочного тестирования в жизни продукта
Является ли нагрузочное тестирование таким же важным и необходимым, как, скажем, проверка основных функций продукта? Ведь на первый взгляд это выглядит исключительно как акт доброй воли: товар работает, мы довольны качеством его основных показателей, и все в порядке.
Но время и ресурсы для дополнительных проверок у нас еще остались, так что давайте придумаем себе еще работу и проведем тесты под нагрузкой! Здесь лучше максимально честно ответить на вопрос: «Что будет, если мы не проведем нагрузочные тесты, и с последствиями этого решения столкнется конечный пользовательЭ» Особенность нагрузочного тестирования в том, что когда пользователь приближается к тем самым крайностям, которые мы можем заранее определить, расширить или ограничить, результат взлетает настолько, что не кажется таким уж плохим.
Если наш продукт в какой-то момент просто перестанет работать (у автомобиля заглохнет двигатель или отвалятся все колеса), мы легко отделаемся.
А если это повредит обрабатываемые данные (отвалилось только одно колесо, машина врезалась в столб и водитель погиб), то что? Прежде всего, мы должны думать о безопасности людей и их данных.
Подобные вещи могут привести к огромным репутационным и финансовым потерям, которые в будущем могут даже привести к закрытию компании.
Для продуктов, предназначенных для небольших компаний или объемов данных, нагрузочное тестирование действительно может быть не столь критичным.
Но когда компания выходит на рынок корпоративных клиентов, где нагрузка на продукт может быть в десятки раз выше, а финансовые риски измеряться сотнями миллионов долларов, лучше было бы освоить это направление знание.
Правда, любой опытный тестировщик вам скажет (и будет абсолютно прав), что так называемый краш-тестирование необходимо проводить в любом случае.
Хотя бы знать, что происходит во время пиковой нагрузки, и спать немного спокойнее.
Но, опять же, если, грубо говоря, это происходит раз в пять лет и можно пережить неприятный момент, просто заняв выжидательную позицию, это одно.
Волна прошла, недовольные роптали, ситуация стабилизировалась, и можно продолжать работать.
С другой стороны, вспомните себя в тот момент, когда выходит онлайн-игра, которую вы ждали много лет. Вы купили его, скачали заранее, выгнали всех из дома, чтобы никто не смог помешать вам в полной мере насладиться моментом, и вдруг вы видите, что вы стоите 100500-м в очереди на подключение к серверу, и вам приходится грустно подождите несколько часов.
Могли ли разработчики предвидеть наплыв игроков при релизе? Конечно, они могли.
Справились ли они с этой ситуацией? Да и нет. С одной стороны, серверы продолжают работать и выполнять свою основную функцию.
С другой стороны, игроки вынуждены стоять в очереди.
Что, в свою очередь, не только предотвращает сбои серверов, но и мешает многим получать удовольствие от игры.
Было ли это осознанное решение или просто так произошло? Это абсолютно совершенно взвешенный и обдуманный шаг.
Момент освобождения – классическая пиковая нагрузка.
Чтобы его сгладить, нужно купить много оборудования.
Но что с ним делать после того, как пик спадет? Как компенсировать эти затраты? К таким неочевидным вопросам может привести такое понятие, как нагрузочные тесты.
В какой момент к нам подключается команда нагрузочного тестирования?
Как выглядит классический жизненный цикл любого продукта: нужно собрать требования, формализовать их в виде технического задания, на основе которого разработчики будут писать код, а результаты их деятельности будут проверены QA. Затем выносится вердикт об уровне качества конечного продукта.Сразу становится понятно, что время на нагрузочные тесты у нас есть только в самом конце, потому что… Зачем тестировать нестабильный продукт под нагрузкой, если его поведение может измениться в любой момент? Все выглядит очень логично, если бы не одно важное «но»: в современном мире любое программное обеспечение представляет собой сложную многокомпонентную систему, состоящую из разных модулей, функций и сервисов.
Когда мы добавляем в эту систему что-то новое, это может настолько повлиять на общую архитектуру, что весь продукт перестанет работать под нагрузкой.
Поэтому новые функции необходимо проверять заранее и отдельно.
Как только появилась более-менее стабильная версия, уже в этот момент ее следует отдать на нагрузочные тесты.
Потому что если архитектурная проблема всплывет в самом конце, то на ее исправление и новые проверки придется потратить несоразмерно больше сил и ресурсов, чем если бы она была замечена на начальных этапах.
Однако системное и регрессионное тестирование перед релизом никто не отменял.
Если сначала проверять каждый компонент отдельно, то в конце необходимо проверить все изделие в целом.
Обычно это достаточно сложная и кропотливая работа, поскольку загрузка всех компонентов одновременно — это не то же самое, что просто включить все имеющиеся у нас тесты и снять метрики.
Конкретно в случае с нашим Veeam Backup & Replication финальные тесты занимают около месяца.
То есть строится отдельная лаборатория, в которой используется максимально возможное количество функций и отслеживается ее поведение.
Испортить такой длинный тест, мягко говоря, обидно.
Загрузчики пишут ошибки?
Результатом работы «классического» тестировщика зачастую является список обнаруженных им проблем в продукте и предлагаемых улучшений.
Что остается после нагрузочного тестирования кроме красивых графиков, из которых можно сделать осмысленные выводы? По сути, это тоже ошибки, просто они не могут быть обнаружены другими методами тестирования и несут в себе метрики времени и нагрузки.
Например: очень долго открывается интерфейс при большом количестве объектов, резкий скачок загрузки ЦП при определенных условиях, утечки памяти при длительной работе и так далее.
Плюс, как мы говорили вначале, только после нагрузочных тестов мы можем констатировать предельные значения, при которых проверялась работа продукта.
Вы проверяли одновременное резервное копирование 10 000 машин? Отлично, значит, мы можем смело писать это в документации.
Мы обработали миллион объектов инфраструктуры — еще одна галочка.
Мы смогли одновременно работать с тысячей серверов — пишем для клиента лучшие практики, как повторить это дома.
Или вы думали, что последние были написаны на основе каких-то умозрительных вещей? Нет, это все результат тестирования с вдумчивым анализом результатов.
Автотесты против нагрузочных тестов
Бытует мнение, что для нагрузочного тестирования достаточно взять существующие автотесты и просто добавить к ним небольшой файл.
Если у нас есть автотест, где мы проверяем, как работает резервное копирование на одной виртуальной машине, то в нагрузочном тесте их должна быть тысяча, и каждая должна быть размером с дом.
Мы создали этот груз, это груз! Вот какие мы молодцы! И этот подход имеет полное право на существование.
Особенно в моменты регрессионного нагрузочного тестирования, о которых мы говорили ранее.
Автотесты действительно очень важны при анализе стабильных версий продуктов.
И сразу становится понятно их главное отличие: задача автотестов — охватить максимальное количество функций в максимальном количестве их вариантов, чтобы вынести вердикт о работоспособности продукта.
Грубо говоря, у нас есть функция резервного копирования виртуальных машин.
Внутри этой функции имеется огромное количество вариантов настроек и их комбинаций.
И чем больше таких комбинаций мы проверим, тем увереннее будем в качестве итоговой функции.
Это задача автотестов.
С другой стороны, нагрузочные тесты не ставят перед собой задачу проверить все возможные комбинации условий и настроек.
Зачастую это невозможно из-за сложности и продолжительности экспериментов.
Поэтому нам предстоит выбрать ключевые сценарии.
Теоретически может случиться так, что изменение незначительной настройки приведет к глобальному падению производительности, но это уже история о поиске иголки в стоге сена.
Хотя нагрузочное тестирование невозможно без элементов автоматизации, доля ручных действий в нем остается большой.
Вот пример: задача — проверить работу изделия при определенной нагрузке.
Мы пишем сценарий, который разворачивает лабораторию, и сценарий, который запускает тест, а затем ждем результатов.
Если все хорошо и полученные показатели соответствуют нашим требованиям, то все молодцы и в результате получается хороший продукт. Но что будет, если все сломается? Отрицательный результат — это тоже результат, поэтому наша задача — найти, что именно сломалось, почему сломалось и как это можно исправить.
Вы не можете просто написать ошибку и отправить ее разработчикам.
Они займут позицию за себя и кто знает, как долго они будут ее удерживать в поисках причин.
Потом сделают исправление, начнут проверять, и все это может тянуться бесконечно долго.
Поэтому засучим рукава, собираем логи, дампы и начинаем сами искать ошибки.
Легко может оказаться, что проблема не в продукте, а в самой лаборатории.
Либо в операционной системе какой-то сбой.
Или, например, заканчивается свободная память и вам нужно понять, сколько требуется дополнительной памяти или как можно уменьшить использование имеющейся памяти.
Это все ручная исследовательская работа, которую невозможно автоматизировать.
По крайней мере, на данном этапе развития технологий.
Правда, в сфере веб-серверов возможностей для автоматизации нагрузочного тестирования может быть значительно больше.
К счастью, веб-разработка уже много лет находится в тренде, и найти что-то действительно уникальное бывает сложно.
Даже если готового теста онлайн для нужного вам профиля нагрузки нет, вы всегда можете его доделать или собрать из имеющихся у вас в избытке кирпичиков.
Как стать специалистом по нагрузочному тестированию
Нагрузочное тестирование — область на стыке нескольких профессий.Здесь вы найдете «классическое» тестирование, системное администрирование, автоматизацию и проектирование систем.
Опыт работы в любой из этих областей поможет вам быстрее справиться с «нагрузкой».
Может быть полезно поработать пару лет системным администратором, чтобы развить взгляд на ИТ и технический опыт. Это отличная стартовая позиция, особенно если вы еще не определились, чем именно хотите заниматься в IT. Но даже молодой инженер, любящий технологии, может прийти в отдел нагрузочного тестирования и научиться всему прямо на месте.
Как ни странно, в отрасли контроля качества существует довольно много таких же подходов к обеспечению качества.
Они могут быть настолько разными, что, поработав в одной компании и добившись там определенных высот, этот человек просто не может работать в другой компании из-за разных взглядов на одни и те же вещи.
Поэтому в QA принцип «Легче научить молодого специалиста, чем нанять готового» остается актуальным, как и много лет назад. Это подводит нас к еще одному интересному вопросу.
Философия нагрузочного тестирования
Как всем точно известно, суть работы QA не в поиске ошибок и не в попытках сломать продукт. Их основная задача — представить, как будет использоваться тестируемый продукт, и убедиться, что производительность продукта соответствует ожиданиям пользователей.
То есть это история о попытках залезть в чужую голову и умении предугадывать желания, о которых сам пользователь еще даже не задумывался.
Теперь займемся нагрузочными тестами.
Кажется, здесь нет игры в угадайку, а просто чистый прагматизм: собираем ТЗ на основе запросов клиентов, накидываем немного сверху и начинаем методично проверять нужные метрики.
Но все рушится, как только перед нами встает задача протестировать совершенно новый продукт, которым еще никто не пользовался.
На этом этапе задача прогнозирования поведения пользователей переходит из чисто функциональной сферы в количественную, что зачастую связано с чисто техническими ограничениями.
И перед нами стоит задача, во-первых, понять эти ограничения, во-вторых, найти оптимальные методы работы при заданных параметрах.
При этом мы должны постоянно напоминать себе, что решаем техническую задачу не ради технологий, а ради удобства конечного пользователя.
У этой ситуации есть и плохая, и хорошая стороны.
Плохо то, что если мы сделаем что-то новое, чего раньше никто не делал, мы можем потратить бесконечное время на решение проблем, важность которых еще не доказана на практике.
Есть, например, аналитик, который прогнозирует, что так и должно быть.
А рядом с ним сидит другой аналитик, который требует того же, но в два раза больше.
А третий вообще говорит, что это никому не нужно и достаточно делать это чисто номинально.
Хорошая новость заключается в том, что новый продукт обычно имеет в запасе итерации сбора отзывов и улучшений.
Если вы не правильно указали пару параметров, не беда, исправим в патче или следующем релизе.
Главное, что продукт успешно решает проблему на глобальном уровне.
А субъективные метрики из области юзабилити никто не отменял.
В какой момент медленный пользовательский интерфейс можно считать проблемой? Насколько вы готовы мириться с задержками в ответ на клики? Что такое медленный пользовательский интерфейс? Некоторые думают, что проблема начинается, когда после щелчка возникает задержка в одну секунду, а для других можно подождать семь секунд, если мы говорим о моменте пиковой нагрузки.
Получается, что нагрузочное тестирование — это вершина эволюции QA?
Нет-нет и еще раз нет. Это всего лишь одна ветвь на дереве возможностей.Между ними нет ранжирования по важности из-за разницы в уровнях сложности при входе или чего-то в этом роде.
Если специалист хочет работать в функциональном тестировании, он развивается в этом.
Если ему нужно больше кода, он идет на автотесты.
Если ему нужен только код, он идёт на тестирование кода (да, есть такое).
Если миру нужны большие цифры и дымящиеся серверы, он переходит к нагрузочному тестированию.
И так до бесконечности.
QA — это область, где довольно легко найти применение своим желаниям.
Да, нагрузочное тестирование требует большего погружения в технологии и предъявляет более высокие требования к знанию стороннего программного обеспечения, чем другие виды тестирования.
Но это не делает его лучше или хуже других методов, где больше внимания уделяется, например, функционально-аналитической части.
Технологичность всего процесса — это просто особенность, которая для некоторых может стать решающим фактором при выборе направления роста.
Теги: #qa #testing #Тестирование веб-сервисов #Тестирование мобильных приложений #Тестирование ИТ-систем #Тестирование игр #нагрузочное тестирование #veeam
-
Модель Ноутбука G550 От Lenovo
19 Oct, 24 -
Компьютерный Учебный Центр
19 Oct, 24 -
Теория Информации
19 Oct, 24 -
Статический Анализатор Кода Pc-Lint
19 Oct, 24
