Перейти к содержимому

Фотография

Реализация санити тестирования


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 17

#1 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 27 марта 2018 - 14:42

Доброго времени суток, коллеги! 

Прошу всех неравнодушных поделиться опытом в следующей жизненной ситуации начинающего тестировщика!

 

Требования заказчика:

- реализовать санити тестирование (цикличное, т.е. в назначенное время) по заданным параметрам

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

- сохранение вышеуказанных результатов для последующего анализа

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

 

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

 

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

 

Краткая информация по системе и серверной части:
- вебприложение на жабе; ADF фреймворк

- до 11 реальных серверных машин 

- БД оракл
- HTTP; SOAP


  • 0

#2 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 28 марта 2018 - 15:21

Я честно предпринял две попытки вам ответить но не смог прорваться через сарказм и гиперболы.

 

Давайте начнем с простого вопроса. Какую проблему пытается решить заказчик?

 

И нет, jmeter вам на все не хватит. он в таких системах в лучшем случае как исполнительный механизм генерирующий нагрузку. Учитывая сколько всего собирается с серверов - времена ответов зачастую тоже собираются из логов.


  • 0

#3 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 28 марта 2018 - 15:45

и это кстати нагрузочное тестирование, а не "Sanity testing"

 

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


  • 0

#4 Thudull

Thudull

    Новый участник

  • Members
  • Pip
  • 4 сообщений
  • ФИО:E.Kovalcov

Отправлено 29 марта 2018 - 05:46

 

 

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

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

http://skrinshoter.ru/s/290318/7T5oP0
https://www.guru99.c...ty-testing.html


  • 0

#5 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 29 марта 2018 - 06:57

Я честно предпринял две попытки вам ответить но не смог прорваться через сарказм и гиперболы.

 

Давайте начнем с простого вопроса. Какую проблему пытается решить заказчик?

 

И нет, jmeter вам на все не хватит. он в таких системах в лучшем случае как исполнительный механизм генерирующий нагрузку. Учитывая сколько всего собирается с серверов - времена ответов зачастую тоже собираются из логов.

Позвольте спросить, и почему же Вас посетил сарказм и остальные вытекающие из этого? Если в силу моей некомпитентности, то это не есть хорошо! - ибо в обличении и научении есть польза, а вот в троллинге нет! :)

Перехожу непосредственно к ответу:

Изначально была задача нагрузочного и перфоманс тестирования. Далее увидев подробные результаты анализа, заказчику пришла идея мониторить таким образом производительность системы и выйти на какие либо косяки.
Тоесть проводить санити, с подробным отображением и логированием результатов для последующего сравнения. К примеру это может пригодится для выявления соотношения количества пользователей в данный момент и времени респонса.
Судя по требованиям заказчика jmeter вполне должно хватить, в связке с jenkins может быть?


  • 0

#6 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 29 марта 2018 - 06:58

и это кстати нагрузочное тестирование, а не "Sanity testing"

 

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

Вы все правильно поняли - именно санити (цикличное) с подробным отображением нужных результатов.


  • 0

#7 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 29 марта 2018 - 07:05

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


  • 0

#8 baxatob

baxatob

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Юрий
  • Город:Riga

Отправлено 29 марта 2018 - 08:13

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

Проекту не хватает реал-тайм анализа производительности системы. 

 

 

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


  • 0

#9 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 29 марта 2018 - 08:46

 

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

Проекту не хватает реал-тайм анализа производительности системы. 

 

 

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

 

Спасибо за ответ! Да вы правильно поняли. Но настоящее санити на проде стоит, и это не обязанность проекта.
Я не знаю как там это реализовано (и реализовано скорее всего так как нужно). В частности для проектной команды, нужно сделать некий инсрумент, для анализирования проблем (в отчетность к заказчику это никак не идет. Требование заказчика в этом случае звучит скорее всего так "проводите оптимизацию системы и предоставьте результаты анализа") То есть нужны результаты анализа (от тестеров), а уж решение соответсвенно с девелоперов.
Я понимаю что это решает задачу только с серверной части (и части БД) системы, но по крайней мере хотя бы так


  • 0

#10 baxatob

baxatob

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Юрий
  • Город:Riga

Отправлено 29 марта 2018 - 09:00

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


  • 0

#11 baxatob

baxatob

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Юрий
  • Город:Riga

Отправлено 29 марта 2018 - 09:08

 

 

Я понимаю что это решает задачу только с серверной части (и части БД) системы, но по крайней мере хотя бы так

 

Тогда не понятно какой реалтайм вы хотите? Делайте обычное нагрузочное тестирование, смотрите логи, выявляйте узкие места.


  • 0

#12 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 29 марта 2018 - 09:24

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

В рамках вашего ответа, от меня следует вопрос: посоветуйте листнеры, которые соберут базовые метрики и отобразят их в нужном формате + каким образом результаты можно архивировать


  • 0

#13 baxatob

baxatob

    Опытный участник

  • Members
  • PipPipPipPip
  • 258 сообщений
  • ФИО:Юрий
  • Город:Riga

Отправлено 29 марта 2018 - 10:18

Попробуйте начать с Summary Report. Думаю дефолтной конфигурации вам хватит. Сохраняйтесь в csv файл, например.


  • 0

#14 checo

checo

    Опытный участник

  • Members
  • PipPipPipPip
  • 400 сообщений
  • Город:Н.Новгород

Отправлено 29 марта 2018 - 12:13

 

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

В рамках вашего ответа, от меня следует вопрос: посоветуйте листнеры, которые соберут базовые метрики и отобразят их в нужном формате + каким образом результаты можно архивировать

 

 

Первый вариант: смотрите в сторону готовых решений, например, Graphite+Grafana или InfluxDB+Grafana. Graphite более популярен, но несколько специфичен в настройке (надо знать джангу, и под виндой развернуть проблемно), InfluxDB в качестве коллектора данных может оказаться попроще.

 

Джейметровцы даже сделали отдельные листенеры для них: http://jmeter.apache...me-results.html. Но этого недостаточно, т.к. эти листенеры собирают показатели с джейметра, а мониторинг ресурсов надо прикручивать к Графане отдельно. Готовых рецептов не подскажу, т.к. в реальных проектах не было случая использовать

 

Второй вариант: если не заведется или некогда изучать, на крайний случай можно писать данные из листенера Simple Data Writer (для самих тестов) и из плагинчика PerfMon Metrics Collector (для мониторинга ресурсов) в локальные файлы, и потом велосипедить отображение отчетов.


  • 0

#15 BadMF

BadMF

    Специалист

  • Members
  • PipPipPipPipPip
  • 809 сообщений
  • ФИО:Dmitry Petrov

Отправлено 30 марта 2018 - 05:39

Доброго времени суток, коллеги! 

Прошу всех неравнодушных поделиться опытом в следующей жизненной ситуации начинающего тестировщика!

 

Требования заказчика:

- реализовать санити тестирование (цикличное, т.е. в назначенное время) по заданным параметрам

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

- сохранение вышеуказанных результатов для последующего анализа

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

 

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

 

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

 

Краткая информация по системе и серверной части:
- вебприложение на жабе; ADF фреймворк

- до 11 реальных серверных машин 

- БД оракл
- HTTP; SOAP

 

это не тестирование в принципе, это мониторинг работы продакшона, начнём с этого.

 

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

 

Для начала вам надо определить узкие места, и уже от положения узкого места использовать подходящий инструмент. У вас их может быть как минимум 3. Для БД используется свой инструмент, для SAOP HTTP свой и тд.

 

Оракл вполне позволяет собственными средствами мониторить времена выполнения запросов.

 

 

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


  • 0

#16 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 30 марта 2018 - 08:10

 

Доброго времени суток, коллеги! 

Прошу всех неравнодушных поделиться опытом в следующей жизненной ситуации начинающего тестировщика!

 

Требования заказчика:

- реализовать санити тестирование (цикличное, т.е. в назначенное время) по заданным параметрам

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

- сохранение вышеуказанных результатов для последующего анализа

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

 

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

 

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

 

Краткая информация по системе и серверной части:
- вебприложение на жабе; ADF фреймворк

- до 11 реальных серверных машин 

- БД оракл
- HTTP; SOAP

 

это не тестирование в принципе, это мониторинг работы продакшона, начнём с этого.

 

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

 

Для начала вам надо определить узкие места, и уже от положения узкого места использовать подходящий инструмент. У вас их может быть как минимум 3. Для БД используется свой инструмент, для SAOP HTTP свой и тд.

 

Оракл вполне позволяет собственными средствами мониторить времена выполнения запросов.

 

 

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

 

Спасибо за компитентный ответ! Я понимаю, в какую сторону вы клоните и да, подписываюсь под вашими словами. Ибо если заниматься метриками и анализом, то это далеко не jmeter... 
Но все же, предыдущие ответы от коллег по цеху, не были бесполезными, так как исходя из них я нашел ответы на некоторые моменты. Полагаю что в ближайшее время, я смогу предоставить проекту минимальные показатели (контроль) происходящего. 


  • 0

#17 Gregory_Lenni

Gregory_Lenni

    Новый участник

  • Members
  • Pip
  • 9 сообщений
  • ФИО:Gregory

Отправлено 30 марта 2018 - 08:11

 

 

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

В рамках вашего ответа, от меня следует вопрос: посоветуйте листнеры, которые соберут базовые метрики и отобразят их в нужном формате + каким образом результаты можно архивировать

 

 

Первый вариант: смотрите в сторону готовых решений, например, Graphite+Grafana или InfluxDB+Grafana. Graphite более популярен, но несколько специфичен в настройке (надо знать джангу, и под виндой развернуть проблемно), InfluxDB в качестве коллектора данных может оказаться попроще.

 

Джейметровцы даже сделали отдельные листенеры для них: http://jmeter.apache...me-results.html. Но этого недостаточно, т.к. эти листенеры собирают показатели с джейметра, а мониторинг ресурсов надо прикручивать к Графане отдельно. Готовых рецептов не подскажу, т.к. в реальных проектах не было случая использовать

 

Второй вариант: если не заведется или некогда изучать, на крайний случай можно писать данные из листенера Simple Data Writer (для самих тестов) и из плагинчика PerfMon Metrics Collector (для мониторинга ресурсов) в локальные файлы, и потом велосипедить отображение отчетов.

 

Благодарю за конструктивный ответ!


  • 0

#18 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 30 марта 2018 - 14:34

Я честно предпринял две попытки вам ответить но не смог прорваться через сарказм и гиперболы.
 
Давайте начнем с простого вопроса. Какую проблему пытается решить заказчик?
 
И нет, jmeter вам на все не хватит. он в таких системах в лучшем случае как исполнительный механизм генерирующий нагрузку. Учитывая сколько всего собирается с серверов - времена ответов зачастую тоже собираются из логов.

Позвольте спросить, и почему же Вас посетил сарказм и остальные вытекающие из этого? Если в силу моей некомпитентности, то это не есть хорошо! - ибо в обличении и научении есть польза, а вот в троллинге нет! :)
Перехожу непосредственно к ответу:
Изначально была задача нагрузочного и перфоманс тестирования. Далее увидев подробные результаты анализа, заказчику пришла идея мониторить таким образом производительность системы и выйти на какие либо косяки.
Тоесть проводить санити, с подробным отображением и логированием результатов для последующего сравнения. К примеру это может пригодится для выявления соотношения количества пользователей в данный момент и времени респонса.
Судя по требованиям заказчика jmeter вполне должно хватить, в связке с jenkins может быть?

Потому, что вы пытаетесь решить системную задачу, владея одним инструментом, для решения этой задачи не предназначенным.
Судя по описанному вас просят сделать мониторинг производительности прода, аналитическую систему. Генератор нагрузки там не нужен от слова совсем, нагрузку дают пользователи. Времена ответов берутся из логов. Загрузка прода собирается "стандартными" средствами. А вот как все это отобразить, чтобы из этого можно было делать выводы, вот это задача.
  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных