Изображение: Flickr
В нашем блоге на Хабре мы продолжаем рассказывать о построении DevOps-культуры в компании — например, в одном из последних топиков мы описывали то, какие задачи решаем с помощью системы SaltStack. Сегодня речь пойдет о другой интересной теме — автоматизации нагрузочного тестирования с помощью связки нескольких готовых инструментов.Читать полностью »
Кадр из фильма «Дом у озера». Встреча (www.kinopoisk.ru)
Джим ещё не знал, как подойти к ней, с чего начать разговор и на каком языке его вести. Но он видел многое, владел языками и имел в рукаве не один козырь. И будучи уверенным в помощи верных друзей (это мы с вами) и забыв про сомнения, шёл на встречу судьбе.
Ниже рассказ о том, как Джим завоёвывал снова и снова сердце незнакомой системы. Не подумайте, что незнакомок было несколько. Она была одна, единственная, но такая разная, и от того истории будут следовать одна за другой.
Читать полностью »
Плагин упрощает загрузку встроенных ресурсов, позволяет параллельно выполнять указанные GET-запросы. Делая тест максимально близким к работе браузера по составу загружаемых ресурсов и по способу загрузки этих ресурсов.
TailSampler выручает если нужно:
Среднее качество работы парсеров (для семи сайтов)
Предлагаю:
Как гласит народная мудрость: Верить верь, но…
Читать полностью »
Наверняка каждый, кто пользовался стандартными листенерами в JMeter, сталкивался со следующими ограничениями:
Чтобы обойти данные ограничения, было принято решение переработать формирование лог-файлов с помощью нового плагина CsvLogWriter.
Читать полностью »
В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.Читать полностью »
Так сложилось, что последние полгода я активно занимался тестами производительности и мне кажется, что в этой области IT царит абсолютное непонимание происходящего. В наше время, когда рост вычислительных мощностей снизился (vertical scalability), а объем задач растет с прежней скоростью, проблема производительности становится всё острее. Но прежде, чем броситься на борьбу с производительностью, необходимо получить количественную характеристику.
Краткое содержание статьи:
Однажды, путешествуя в поезде, я захотел посчитать, каково расстояние между столбами электропередач. Вооружившись обычными часами и оценивая среднюю скорость поезда 80-100км/ч (25 м/с), я засекал время между 2-мя столбами. Как ни странно, этот наивный метод давал очень удручающие результат, вплоть до 1.5-2 кратной разницы. Естественно метод несложно было исправить, что я и сделал, достаточно было засечь 1 минуту и посчитать количество столбов. И не важно, что мгновенная скорость на протяжении минуты может варьироваться и даже не важно посчитаем мы последний столб или минута истечет посередине, потому как измерений вполне достаточно для требуемого результата.
Смысл теста в том, чтобы получить убедительные для себя и для других измерения.
Эта история мне напоминает то, что происходит с тестированием производительности в Software Engineering. Достаточно частое явление — запуск 1-2 тестов, построение графиков и получение выводов о scalability система. Даже, если есть возможность применить МНК или узнать стандартную ошибку, это не делается за «ненадобностью.» Особенно интересная ситуация, когда после этих 2 измерений, люди обсуждают насколько быстрая система, как она масштабируется и сравнивают её с другими системами по личным ощущениям.
Конечно, оценить, насколько быстро выполняется команда, не сложно. С другой стороны, быстрее не значит лучше. Системы ПО имеют свыше 10 различных параметров, от hardware на котором они работают до input, которые вводит пользователь в разные моменты времени. И зачастую 2 эквивалентных алгоритма могут давать совершенно разные параметры масштабируемости в разных условиях, что делает выбор совсем не очевидным.
С другой стороны результаты измерений всегда остаются источником спекуляций и недоверий.
— Вчера мы меряли было X, а сегодня 1.1*X. Кто-то что-то менял? — 10% — это нормально, у нас теперь больше записей в БД.
— При проведении теста был отключен антивирус, скайп, анимация заставки?
— Не-не, для нормальных тестов нам надо закупить кластер серверов, установить микросекундную синхронизацию времени между ними… удалить ОС, запускать в защищенном режиме…
— Сколько пользователей мы поддерживаем? У нас 5000 зарегистрированных пользователей, вдруг 20% из них залогинится, надо запускать тесты с 1000 параллельными агентами.
Крупные распределенные информационные системы зачастую состоят из более мелких модулей (подсистем) и разрабатываются группами программистов с использованием разных платформ и подходов. Часто, обмен данными в таких системах происходит в асинхронном режиме и предпочтительно использование промежуточного программного обеспечения, ориентированного на обработку сообщений (англ. Message-Oriented Middleware, MOM).
Для модульного и интеграционного тестирования таких систем удобно использовать старый добрый Apache JMeter.
Для примера выделим небольшой стандартный модуль такой системы. Допустим, есть некий адаптер, который читает XML сообщение из очереди входящих сообщений, выполняет преобразование структуры XML сообщения и публикует преобразованное сообщение в очередь исходящих сообщений. В качестве MOM, в данном случае, используется Websphere MQ 7.5.
Читать полностью »
В статье пойдет речь о тестировании в условиях сжатых сроков с использованием таких инструментов, как Selenium и JMeter, а так же о том, как не запороть проект тестирования в условиях дефицита компетентных сотрудников.
Как тестировщик, я люблю когда всё по порядку, но жизнь переполнена грязными хаками. Я люблю автоматизировать, подвязав Selenium к Python, но когда встречаюсь с проблемой ограниченности ресурсов, бросаюсь за тот инструмент, который позволяет сделать «всё то же самое, но быстрее». В этом посте я расскажу, что JMeter — прекрасный инструмент как для нагрузочного, так и для функционального тестирования.
Читать полностью »
Добрый день, Хабрахабр.
Вы, вероятно, знакомы с JMeter. Если в кратце — очень удобный инструмент для проведения нагрузочного тестирования, имеет огромный функционал и много-много полезных фишек. Но статья не о нем.
В нашем проекте есть довольно нагруженный узел, JMeter помогал долгое время. Проффилирование и оптимизации дали свой профит, но все уперлось в маленькую проблему. JMeter не мог создать очень большой трафик, а если более точно, то после 10 секунд нужного нам режима, происходил OutOfMemory и тестирование прекращалось, в некоторых случаях проблемы не было, но скорость отправки запросов заметно уменьшалась, при этом загрузка CPU — 400%, решалось перезапуском программы. Пользоваться было крайне не удобно.
Итак, мы имеем проблему, и ее нужно решить, первое, что пришло в голову — сделать свой мини-тест, отвечающий минимальным требованиям. Давно было интересно попробовать Go на вкус. Так родилось приложение go-meter. При написании возникало очень много вопросов, ответов на которые либо не было, либо они не объясняли проблему, поэтому я решил поделиться опытом и примером рабочего кода, если Вам интересно, прошу подкат.
Читать полностью »
