Автоматизация тестирования ПО

Основные понятия Нагрузочное Тестирование Автоматизация функционального тестирования

Практикум Пишем систему автоматизации тестов "с нуля" PageObjects pattern PageObjects pattern + Selenium (Java) Работа со статическими ресурсами Запуск Selenium Server Модель нагрузки, как отправная точка при тестировании... Конфигурация тестового стенда для нагрузочного тестирования Создание скриптов для нагрузочного тестирования Запуск скриптов: Java Test Runner Automation Test Framework (ATFwk)

Раздел: Автоматизация > Практикум > Конфигурация тестового стенда для нагрузочного тестирования

Конфигурация тестового стенда для нагрузочного тестирования

Введение

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

Конфигурация vs Производительность

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

Конфигурация тестового стенда

Отметим те части конфигурации, которые требуют особого внимания:

• Hardware
  • процессор (тип, частота, количество ядер и т.д)
  • оперативная память (тип, объем, тайминг, эффективная частота и т.д.)
  • жесткие диски (тип, скорость и т.д.)
• Software
  • Операционная система
  • Драйвера
• Network
  • топология сети
  • пропускная способность
  • протокол передачи данных
• Application
  • Архитектура
  • База данных (структура + данные)
  • программное обеспечение, необходимое для работы приложения (например, для Java приложений - JVM)

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

1. Сложность дублирования дорогого серверного железа для тестовых нужд
2. Ограничения на использование лицензий требуемого программного обеспечения
3. Закрытость архитектуры приложения со стороны заказчика по соображениям безопасности
4. Трудность воссоздания или транспортировки базы данных приложения
5. Сложность воссоздания требуемой архитектуры сети
6. и многое другое (всё перечислить крайне сложно из-за большого количества нюансов, влияющих на конфигурацию системы)

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

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

Требуется конфигурация: Proc Intel Clarkdale Core I5, 16 Gb памяти DDR3-800, OS SLES11

Конфигурация тестового стенда: Proc AMD Deneb Phenom II X4, 16 Gb DDR2-800, OS SLES10

Казалось бы отличия незначительны, однако есть нюансы:

1. Разные типы процессоров
2. Разный тип памяти
3. Разные версии операционной системы

Итак:

Cравним процессоры [3]:

Название ядра	Intel Clarkdale Core I5	AMD Deneb Phenom II X4
Тактовые частоты, Мгц	2800-3600	2800-3000
Частоты системной шины, Мгц	2500	2000-1800
Пропускная способность шины процессор-чипсет	2 ГБ/сек (1 ГБ/сек в одном направлении)	14.4-16 ГБ/сек (7.2-8 ГБ/сек в одном направлении)
Размер кэша L1, Кб	64 х2	128 х4
Размер внутреннего кэша L2, Кб	256 x2	512 х4
Ширина шины L2 кеша, бит	256 (двунаправленная)	256 (по 128 в каждом направлении)
...	...	...

Примечание: Не правда ли, непросто будет сравнивать без помощи специалистов? Тем более вывести коэффициент на сколько какой процессор быстрее и по каким параметрам.

Cравним память [4]:

Стандартная задержка (latency) типичная для DDR2 5-5-5-15, а для DDR3 памяти 7-7-7-15. Однако даже с большей задержкой DDR3 память (в отличие от старого стандарта DDR2) обладает большей пропускной способностью (bandwidth) из-за более высокой тактовой частоты (clock speed). Что становится причиной того, что DDR3 память работает немного медленнее, чем DDR2 с такой же частотой 800MHz.

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

Cравним операционные системы

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

Таким образом предположим, что SLES 11 будет незначительно быстрее SLES 10.

Удивлены таким большим количеством различий? (Причем это только для трех элементов конфигурации: процессора, памяти и операционной системы. В реальности их намного больше) Легко ли будет сделать выводы о том, как будет работать приложение на требуемой конфигурации? (Я думаю, что практически невозможно) Однако далее мы попробуем все таки найти пути для решения этой проблемы, рассмотрев некоторые практические приемы.

Анализ результатов при разных конфигурациях

Как же быть с тем фактом, что приложение будет протестировано на одной платформе, а работать ему придется на другой? Как провести анализ результатов? Как сделать окончательные выводы и спрогнозировать работу приложения под нагрузкой в будущем?

Использование переходного коэффициента

В своей статье [1] Вячеслав Берзин, предложил при анализе результатов использовать “переходный коэффициент”, показывающий численно отличие производительности тестовой платформы от промышленной:

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

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

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

Использование экспертной оценки

Рассмотрим мнение Андрея Широбокова [2] (сертифицированный специалист в области нагрузочного тестирования, имеющий более 15 лет рабочего опыта в IT):

"Идеально ключевые моменты должны совпадать, пишу по убыванию важности:

1. конфигурация (кол-во и тип процессоров х память)
2. версия ОС и статс паки
3. версия и тип СУБД
4. версия серверов приложений и патчей

Естественно, что версия тестируемого приложения должна быть актуальна.

Если совпадает платформа (ОС и тип процессоров), то допускается "пропустить" конфигурацию, например, в случае если проведены эксперименты на конфигурациях 8х16 (8 прц х 16 Гб) и 32х64 (32 прц х 64 Гб), то можно "аппроксимировать" недостающую конфигурацию 24х48 (24 прц х 48 Гб). Обратим внимание, что памяти для такой методики должно пропорционально быть в 2 раза больше во всех случаях.

Если не совпадает платформа, ОС, типы процессоров, объемы памяти, то можно делать только очень общие выводы, наподобие: "В реальности будет не хуже". Но времена откликов и другие детали могут быть малозначимы."

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

Выводы

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

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

Литература

1. Технология нагрузочного тестирования информационных систем с большим объемом данных , Вячеслав Берзин, Oracle Magazine, [01.12.04]
2. Блог Андрея Широбокова (http://ashirobokov.blogspot.com)
3. Сравнение характеристик процессоров
4. DDR3 RAM and DDR2 Memory Comparison

Автор: Алексей Булат

Обсудить статью в блоге автора

Наверх