[Перевод] Лидерство в тестировании: управление тестированием производительности
Добро пожаловать в серию статей «Лидерство в тестировании» от гуру тестирования программного обеспечения и консультанта Пола Джеррарда. Эта серия предназначена для того, чтобы помочь тестировщикам с многолетним опытом работы, особенно в agile командах, преуспеть в своей роли руководителя тестирования и менеджера.
В предыдущей статье мы рассмотрели тестирование сервисов и его основные компоненты: тестирование производительности, тестирование на отказоустойчивость и управляемость. Как и было обещано, здесь мы рассмотрим тестирование производительности более подробно.
Цель этой статьи — дать несколько советов и рекомендаций по управлению важнейшим компонентом тестирования сервисов, упомянутым в этой статье, а именно, барабанная дробь, … тестированием производительности!
Мы рассмотрим:
Начнем.
Цели тестирования производительности
В кратком изложении мы можем определить основную цель тестирования производительности следующим образом:
«Чтобы продемонстрировать, что система функционирует в соответствии со спецификациями с приемлемым временем отклика при обработке требуемых объемов транзакций в базе данных продакшн размера».
Ваша среда тестирования производительности — это испытательный стенд, который можно использовать для других тестов с более широкими целями, которые мы можем обобщить следующим образом:
Оценка способности системы к росту (если вы не уверены, какое программное обеспечение может удовлетворить ваши потребности, вам поможет наш список лучших решений для управления базами данных.)
Ваша стратегия тестирования должна определять требования к тестовой инфраструктуре, которая позволяет достичь всех этих целей.
Четыре обязательных условия для тестирования производительности
«Если какие-либо из этих требований отсутствуют, будьте очень осторожны, прежде чем приступать к выполнению тестов и публикации результатов. Использование средств автоматизации контроля качества может помочь обеспечить выполнение этих требований. Тесты могут оказаться трудными или невозможными для выполнения, а достоверность любых публикуемых вами результатов может быть серьезно подорвана, и ее легко подорвать.
1. Количественные, актуальные, измеримые, реалистичные и достижимые требования
В качестве основы для всех тестов следует согласовать требования к производительности (цели) до начала тестирования, чтобы можно было определить, соответствует ли система этим требованиям.
Требования к пропускной способности системы или времени отклика, которые могут быть использованы в качестве основы для сравнения результатов производительности, должны соответствовать следующим параметрам. Они должны быть:
Часто требования к производительности являются расплывчатыми или вообще отсутствуют. По возможности найдите все документированные требования. Если есть пробелы, возможно, вам придется задокументировать их ретроспективно.
Прежде чем можно будет определить и спроектировать тест производительности, необходимо согласовать требования к:
Так как требования к производительности часто определяются расплывчато — они часто основаны на предположительных прогнозируемых объемах бизнеса, поэтому может потребоваться, чтобы бизнес-пользователи реалистично оценивали требования к производительности.
Возможно, вам также придется провести некоторый анализ требований самостоятельно и задокументировать эти требования в качестве целевых показателей эффективности.
2. Стабильная система
Если система работает с ошибками и ненадежна, с тестированием производительности вы далеко не продвинетесь. Тесты производительности в той или иной степени затрагивают все архитектурные компоненты. Но для того, чтобы тестирование производительности дало полезные результаты, система и техническая инфраструктура должны быть достаточно надежными и отказоустойчивыми с самого начала.
3. Реалистичная среда тестирования
Тестовую среду необходимо настроить таким образом, чтобы тест был полноценным. Вероятно, вы не сможете воспроизвести целевую или производственную систему, но тестовая среда должна быть полностью или частично сопоставима с конечной производственной средой. Вам нужно будет согласовать с разработчиком системы, какие компромиссы приемлемы, а какие нет, или, по крайней мере, как можно было бы интерпретировать результаты тестирования.
Создание реалистичной тестовой среды необходимо для проведения значимых тестов производительности. Инструменты, которые помогут вам смоделировать реальные условия, можно найти в нашей подборке платформ для тестирования программного обеспечения.
4. Контролируемая среда тестирования
Тестировщикам производительности требуется стабильность. Не только с точки зрения надежности и отказоустойчивости аппаратного и программного обеспечения, но и с точки зрения минимизации изменений в среде или тестируемом программном обеспечении. Например, при малейшем изменении интерфейса тестовые сценарии, предназначенные для управления пользовательскими интерфейсами, могут немедленно выйти из строя.
Любые изменения в среде должны строго контролироваться. Если изменения исправляют ошибки, которые вряд ли повлияют на производительность, вы можете отказаться от релиза. Могут быть приняты только изменения, направленные на повышение производительности или надежности.
Набор инструментов для тестирования производительности
Ваш набор инструментов для тестирования производительности состоит из пяти основных инструментов:
Создание/сопровождение тестовых данных — для создания больших объемов данных в базе данных, которые потребуются для тестирования. Мы ожидаем, что это будет утилита на базе SQL или, возможно, продукт на базе ПК, такой как Microsoft Access, подключенный к вашей тестовой базе данных.
Генерация нагрузки — в обычных инструментах используются тестовые драйверы, которые имитируют виртуальные клиенты, отправляя HTTP-сообщения на веб-серверы.
Инструмент запуска приложения — управляет одним или несколькими экземплярами приложения с помощью интерфейса браузера и записывает измерения времени отклика. (Обычно это тот же инструмент, который используется для генерации нагрузки, но не обязательно).
Мониторинг ресурсов — утилиты, которые отслеживают и регистрируют системные ресурсы клиента и сервера, сетевой трафик, активность базы данных и т. д.
Процесс тестирования производительности
На рисунке ниже показан общий процесс тестирования производительности и настройки. Настройка на самом деле не является частью процесса тестирования, но она является неотъемлемой частью задачи повышения производительности и надежности. Настройка может включать изменения в архитектуре инфраструктуры, но не должна влиять на функциональность тестируемой системы.
Теперь мы рассмотрим, как разработать, выполнить, проанализировать и отчитаться о результатах теста производительности.
Поэтапная разработка тестов
Разработка тестов обычно выполняется в четыре этапа:
По мере роста нагрузки разрабатываемая платформа тестирования постоянно совершенствуется, отлаживается и становится более надежной. Опыт работы с инструментами тоже растет.
Когда последний сценарий интегрирован в нагрузочный тест, тест выполняется как «пробный запуск», чтобы убедиться в его полной повторяемости и надежности, а также в готовности к формальным тестам.
Промежуточные тесты могут дать полезные результаты»
Выполнение части нагрузочного теста и тестовых транзакций может привести к проблемам с производительностью. Тесты с малыми объемами загрузки также могут обеспечить раннее выявление сетевого трафика и потенциальных узких мест при расширении масштабов тестирования.
Низкое время отклика может быть вызвано плохим дизайном приложения и может быть исследовано и устранено разработчиками ранее. Ранние тесты также могут выполняться в течение длительного времени в качестве промежуточных тестов.
Выполнение теста
Выполнение теста требует определенного управления этапами или координации. Вам следует поддерживать связь со вспомогательными участниками, которые будут следить за системой во время выполнения тестов. Команда «мониторинга тестирования» может быть распределена, поэтому вам необходимо держать их в курсе, чтобы тестирование прошло гладко и результаты были получены правильно.
Помимо координации действий различных членов команды, выполнение тестов производительности обычно выполняется в соответствии со стандартной процедурой.
Запуск мониторинга процессов (сети, клиентов и серверов, базы данных).
Если используется отдельный инструмент, при стабильной нагрузке запустите инструмент тестирования приложения и измерения времени отклика.
Если инструменты для запуска теста не останавливаются автоматически, завершите тест по истечении периода тестирования.
Координация действий различных членов команды во время выполнения теста может быть сложной задачей. Упростите этот процесс, внедрив передовые инструменты управления тестированием, разработанные для Jira, которые предлагают такие функции, как совместная работа в режиме реального времени и создание отчетов.
Настройка обычно следует за тестированием, когда возникают проблемы или когда известны возможные варианты оптимизации. Если тест является повторным, важно, чтобы любые изменения в среде регистрировались. Это делается для того, чтобы любые различия в поведении системы и, следовательно, в результатах производительности можно было сопоставить с изменениями в конфигурации.
Когда дело доходит до управления тестовыми примерами для тестирования производительности, программное обеспечение для управления тестированием может кардинально изменить ситуацию. Это позволяет лучше организовать, отслеживать и даже автоматизировать тест кейсы.
Как правило, целесообразно изменять только что-то одно за раз, чтобы при обнаружении различий в поведении можно было проследить их связь с внесенными изменениями.
Анализ результатов и отчетность
В наиболее типичном отчете для тестового запуска эти измерения суммируются, и для каждого выполненного измерения указывается следующее:
Инструмент генерации нагрузки из вашего инструментария должен записывать количество транзакций каждого типа за период тестирования. Деление этих значений на продолжительность теста дает фактически достигнутую скорость транзакций или пропускную способность.
Количество транзакций — это нагрузка, приложенная к системе. Это предполагает, что пропорции выполняемых транзакций соответствуют профилю нагрузки, который вы пытаетесь применить.
Применяемая нагрузка должна соответствовать моделируемому профилю нагрузки, но может и не соответствовать, если система реагирует медленно, а транзакции выполняются с разной скоростью.
Обычно выполняется серия тестовых запусков при различных нагрузках. Используя результаты серии тестов, постройте график времени отклика для транзакции в зависимости от приложенной нагрузки.
Инструменты мониторинга ресурсов обычно содержат статистические или графические отчеты, которые отображают использование ресурсов с течением времени. Расширенные отчеты об использовании ресурсов в зависимости от нагрузки очень полезны и могут помочь выявить узкие места в архитектуре системы.
