Автоматизация тестирования производительности: основные положения и области применения

Тестирование производительности

Предлагаю вашему вниманию статью, написанную в соавторстве с ведущим специалистом по автоматизации тестирования производительности «EPAM Systems» Владимиром Марченко.

Статья была опубликована в журнале «Информатизация образования» (#2, 2012) как способ обратить внимание педагогического сообщества на востребованное направление подготовки студентов. Поскольку, на мой взгляд, статья представляет интерес и для более широкой аудитории, публикую её здесь. Заодно будет для студентов и магистрантов хороший пример текста в научном стиле 🙂

Итак…

Введение

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

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

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

В настоящей статье представлены основные технические решения, направленные на обеспечение качества программных средств по показателю производительности.

Виды тестирования производительности

В настоящий момент наиболее исследованными направлениями тестирования, затрагивающими показатели производительности программных средств, являются [1]:

  • тестирование производительности  (performance testing) – исследование показателей скорости реакции приложения на внешние воздействия при различной по характеру и интенсивности нагрузке;
  • нагрузочное тестирование (load testing) – исследование способности приложения сохранять заданные показатели качества при нагрузке в допустимых пределах и некотором превышении этих пределов (определение "запаса прочности");
  • стрессовое тестирование (stress testing) – исследование поведения приложения при нештатных изменениях нагрузки, значительно превышающих расчётный уровень;
  • объёмное тестирование (volume testing) – исследование производительности приложения при обработке различных (как правило, больших) объёмов данных.
  • Цели каждого из рассмотренных видов тестирования [2] производительности представлены в таблице 1.

Таблица 1 – Цели различных видов тестирования производительности

Вид тестирования производительности Цели
Тестирование производительности
  • оценка времени выполнения операций при определённой интенсивности и очерёдности выполнения этих операций;
  • оценка реакции на изменение количества пользователей, одновременно работающих с приложением;
  • оценка границ интенсивности нагрузки, при которых производительность выходит за рамки приемлемой;
  • оценка показателей масштабируемости приложения.
Нагрузочное тестирование
  • оценка скорости реакции приложения на различные значения нагрузки в допустимых пределах;
  • оценка использования приложением системных ресурсов при различных значениях нагрузки;
  • оценка изменения со временем поведения приложения при сохранении допустимой нагрузки длительное время.
Стрессовое тестирование
  • оценка реакции приложения на нестандартные и стрессовые случаи изменения нагрузки, в т.ч.: резкое непредсказуемое изменение интенсивности нагрузки, значительное превышение предельно допустимой нагрузки,  интенсивное использование функций приложения, являющихся "узким местом" в производительности.
Объёмное тестирование
  • оценка показателей производительности приложения в случаях приёма, обработки и генерации данных различного объёма и с различными показателями вычислительной сложности обработки;
  • оценка способности приложения обрабатывать большие объёмы данных в условиях высокой загрузки системных вычислительных ресурсов;
  • оценка способности приложения обрабатывать большие объёмы данных при недостатке оперативной памяти.

Анализ данных, представленных в таблице 1, позволяет сделать вывод о том, что прямыми или косвенными целями любого тестирования, так или иначе затрагивающего вопросы производительности, является:

  • определение "узких мест" системы (функций программно-аппаратного комплекса, обращение к которым приводит к наибольшему падению показателей производительности);
  • определение лучшей архитектуры системы, выбор наилучшей платформы, средств и языков реализации;
  • определение оптимального способа хранения файлов;
  • оценка и оптимизация схемы базы данных в контексте повышения производительности;
  • оценка максимальной и минимальной производительности системы и условий их достижения;
  • определение характера увеличения времени отклика системы при увеличении нагрузки;
  • определение максимального числа одновременно работающих пользователей, превышение которого делает использование системы невозможным;
  • определение влияния конфигурации системы на производительность;
  • оценка показателей масштабируемости системы;
  • оценка соответствия сетевой инфраструктуры требованиям производительности.

Важность тестирования производительности

Тестирование производительности является неотъемлемым этапом оценки качества программных средств в силу следующих причин.

Низкую производительность приложения замечает большинство пользователей, что негативно влияет на такой показатель удобства использования как "мера пользовательской реакции". В конечном итоге пользователи предпочитают более производительное программное обеспечение.

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

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

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

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

Основные тесты производительности

В рамках нагрузочного тестирования и тестирования производительности, как правило, выполняются следующие основные тесты.

Тест на определение максимальных возможностей системы (capacity test) позволяет определить т.н. "точку насыщения системы" (system saturation point) – уровень нагрузки, при котором дальнейшее наращивание числа пользователей ведёт к увеличению времени отклика системы либо ухудшению стабильности системы, но не к увеличению в единицу времени количества полезных операций, обработанных системой. Данный тест направлен на оценку производительности системы как аппаратно-программного комплекса, поскольку учитывает доступные аппаратные ресурсы и эффективность их использования.

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

Низко-, средне- и высоконагруженная работа (low-, mid-, high-load tests) – позволяет оценить время отклика (response time) системы в некоторых заданных диапазонах нагрузки. Данная информация может быть использована при составлении перечня требований к условиям эксплуатации системы.

Тест на выживаемость (longevity test) показывает способность системы работать длительное время под высокой нагрузкой. Одной из наиболее опасных проблем, выявляемых данным тестом, является утечка памяти и иное снижение эффективности использования аппаратных ресурсов из-за накапливающихся со временем ошибок в работе приложения.

Тест "часа пик" (rush hour test) позволяет оценить реакцию системы на резкое изменение нагрузки. Во время теста проверяется способность системы выдержать скачкообразное увеличение нагрузки во время "часа пик", а также способность системы вернуться к изначальным показателям производительности после завершения "часа пик" (восстановления исходных показателей нагрузки на систему). Такой тест позволяет выявить проблемы с синхронизацией выполнения отдельных участков кода, а также проблемы с управлением всеми видами межкомпонентного взаимодействия (в т.ч. сетевых и локальных соединений) на всех уровнях системы.

Тест "точки рандеву" (rendezvous point test) подразумевает такую настройку профиля нагрузки и поведения виртуальных пользователей, чтобы в некоторый момент все они одновременно выполняли одну и ту же операцию: как правило, синхронную операцию сохранения, записи, и т.п. В отличие от теста "часа пик" этот тест не подразумевает увеличения числа одновременно работающих с системой пользователей, а подразумевает исследование ситуации конкуренции пользователей за некоторые ресурсы, совместное использование которых не представляется возможным или сопряжено с повышенной нагрузкой на системные ресурсы. В частности, этот тест позволяет выявить проблемы с разделением ресурсов на уровне баз данных.

Экспериментальная оценка максимальных возможностей системы

В качестве наиболее показательного примера рассмотрим тест на определение максимальных возможностей некоторой гипотетической системы, а также выводы, которые можно сформулировать на основе проведения данного теста [3].

Для анализа максимальных возможностей системы были выбраны следующие показатели:

  • количество виртуальных пользователей, одновременно работающих с приложением;
  • время отклика приложения на поступивший запрос;
  • количество полезных (не являющихся сообщениями об ошибках) ответов приложения в единицу времени;
  • использование приложением системных ресурсов, в контексте которого наиболее показательным является использование центрального процессора (CPU, central processor unit).

Вариант 1: идеальная система

На рисунке 1 представлены графики изменения вышеперечисленных показателей при проведении теста определения максимальных возможностей некоторой гипотетической идеальной системы. Следует отметить, что в реальности такие системы не встречаются, однако результаты данного виртуального эксперимента могут служить отправной точкой при анализе результатов реальных экспериментов.

Исследование представленных на рисунке 1 графиков позволяет сделать вывод о том, что система достигает точки насыщения при десяти одновременно работающих пользователях, после чего система идеально сохраняет свои показатели производительности, увеличивая время отклика на запрос прямо пропорционально количеству одновременно работающих пользователей.

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

Рисунок 1 – тест на определение максимальных возможностей идеальной системы

Вариант 2: высококачественная система

На рисунке 2 представлены данные эксперимента, проведённого с высококачественной системой.

Рисунок 2 – тест на определение максимальных возможностей высококачественной системы

В отличие от идеальной системы, данная система показывает характерные отклонения от идеальных показателей производительности и использования системных ресурсов.

Колебания графиков времени отклика системы, количества ответов в секунду и использования CPU вызваны неизбежным влиянием операционной системы на производительность тестируемого приложения. Тем не менее, исследуемая система демонстрирует высокую способность сохранять заданные показатели производительности при значительном превышении нагрузки, характерной для точки насыщения: использование системных ресурсов близко к 100%, количество ответов в единицу времени и увеличение времени отклика носят линейный характер.

Вариант 3: низкокачественная система

На рисунке 3 представлены данные эксперимента, проведённого с низкокачественной системой.

Рисунок 3 – тест на определение максимальных возможностей низкокачественной системы

Как следует из представленных на рисунке 3 результатов эксперимента, после достижения точки насыщения все характерные показатели производительности системы носят ярко выраженный случайный характер.

Это позволяет прийти к выводу о том, что исследуемая система неэффективно использует аппаратные ресурсы и при некотором повышении нагрузки придёт в состояние, не позволяющее обрабатывать приемлемое количество запросов в единицу времени.

Такие результаты эксперимента могут быть трактованы как показание к проведению дополнительных исследований и реализации серии мер по оптимизации производительности. В случае игнорирования результатов эксперимента разработчик системы может оказаться в ситуации, когда на стадии эксплуатации системы проявятся симптомы, свидетельствующие о несоответствии системы требованиям заказчика.

Вариант 4: крайне низкокачественная система

На рисунке 4 представлены данные эксперимента, проведённого с крайне низкокачественной системой.

Рисунок 4 – тест на определение максимальных возможностей крайне низкокачественной системы

Основной результат эксперимента – система вышла из строя через 170 секунд после начала эксперимента.

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

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

Экспериментальная оценка реакции системы на ситуацию "час пик"

При проведении теста "часа пик" основное внимание уделяется реакции системы на оказанную нагрузку как в момент наибольшей загруженности, так и непосредственно после снижения нагрузки.

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

В отличие от теста на выявление максимальных возможностей системы тест "часа пик" подразумевает резкое скачкообразное изменение нагрузки на тестируемую систему, что позволяет выявить следующий ряд потенциальных проблем:

  • недопустимо длительная инициализация и деинициализация работы с отдельным пользователем или соединением;
  • проблемы с освобождением незадействованных ресурсов (оперативной памяти, дескрипторов и т.п.);
  • конфликты конкурентного доступа к ресурсам (при котором некоторые процессы системы не успевают выполнить свои задачи за отведённое время);
  • блокировка внешних источников данных (таблиц баз данных, объектов файловой системы, соединений с внешними сервисами и т.п.)
  • лавинообразный захват исследуемым приложением системных ресурсов, ведущий к нарушению стабильной работы операционной системы (нехватка оперативной и виртуальной памяти или дескрипторов);
  • неэффективное использование оперативной и виртуальной памяти, проблемы фрагментации файловой системы и т.п.

На рисунке 5 представлены экспериментальные результаты теста "часа пик", выполненного с высококачественной системой. В процессе эксперимента нагрузка на систему была увеличена в шесть раз, после чего она была возвращена к исходному уровню.

Рисунок 5 – тест "часа пик" высококачественной системы

Результаты эксперимента можно трактовать как "удовлетворительные", т.к. результирующее поведение системы (после эксперимента) отличается от исходного (до эксперимента). Однако низкая дисперсия показателей времени отклика, количества ответов в единицу времени и процентной нагрузки на CPU позволяет сделать вывод о том, что исследуемая система способна выдержать нагрузку "часа пик", сохранив основные показатели производительности на приемлемом уровне.

Заключение

Тестирование и оптимизация производительности позволяет на ранних стадиях разработки программного средства выявить широкий спектр потенциальных проблем, не выявляемых иными направлениями тестирования.

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

Тот факт, что тестирование и оптимизация производительности способны в том числе улучшить показатели удобства использования, защищённости, безопасности и живучести системы позволяет прийти к выводу о необходимости внедрения тестирования и оптимизации производительности как неотъемлемой составляющей обеспечения качества современных информационных систем.

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

Таки образом, исследование и оптимизация производительности является перспективным направлением в производстве программного обеспечения и новым востребованным направлением в образовательном процессе, позволяющим подготавливать более квалифицированных специалистов по разработке и обеспечению качества программных средств.

Литература

1. Тестирование производительности / "Habrahabr.ru"
2. Типы тестов производительности / "Про Тестинг"
3. Тестирование производительности / "Software-Testing.ru"

© 2012 Svyatoslav Kulikov, Vladimir Marchenko