Spike load - сколько угодно. Ultimate Thread Group позволяет его организовать. Свежи-сочни Throughput Shaper - тоже.

Данные с удаленной машинки я тоже предпочел бы собирать по-другому. Но увы - нормального универсального решения без агента не нашлось. Хотя в начале я очень-очень хотел без агента обойтись. Но ведь без этого решения в ЖМетре вообще ничего нет! Плюсы перевешивают.

Оу, значит пропустил. Надо будет покопаться на досуге.

Насчет агента... можно без него обойтись, но это уже будет не совсем JMeter, а скорее совсем не. То есть получить данные с каждой стороны принимающей участие можно без лишнего шума. "Склеить" тоже. Тут в общем-то единственный вопрос - экспорт в разные форматы данных собранных JMeter. По дефолту там очень мало, но сносно. Вот тут как раз готовых решений не очень много на поверхности (если покопать то много, но не все халявные достаточно гибкое представление данных дают). То есть да, там в плагинах в эту сторону хорошее движение по "склейке" графиков уже есть, но я не думаю что это решение само по себе хорошее, потому как завязано на jmeter со всеми вытекающими ограничениями.

Я, кстати, вспомнил чего в тех плагинчиках еще не хватает. Не все нужные паттерны нагрузки можно сделать. То есть пресловутый spike load никак. Хотя может я туда давно не смотрел просто.

И данные с удаленной машинки я бы все же предпочел собирать другими средствами. Ставить агента конечно ОК решение, но сразу возникает ряд вопросов о вносимой погрешности.

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

Ух ты. А я все думал как про это и без матов написать.

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

А чтобы отбрыкиваться от таких задач надо обладать опытом/знаниями, которых зачастую нет, потому как за свои 2-3-5 лет в тестировании многие просто не видели никогда в какой адочек это все может превратиться или не осознавали что за адочек творится вокруг.

Почему я пропустил эту ошибку?

Потому что я искал другие ошибки. Тысячи их. А когда в продукте очень много ошибок почему-то очень много времени уходит на его тестирование. Сильно меньше чем когда в продукте мало ошибок. Сильно страдает эффективность тестирования как такового. TDD, CI, Code Review (не отмазки типа "я посмотрел, вроде ок"), Testability, раннее вовлечение пользователей в работу над продуктом, отличные логи, отличный мониторинг работы продукта, никаких головняков с установками и переконфигурацией, хорошие инструменты для тестирования - это может помочь улучшить качество поставляемого на тестирование продукта, но не спасет. Чтобы лучше находить баги, чтобы их было проще диагностировать и чинить - Testability.

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

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

Пропуск ошибок это зачастую не проблема отдела тестирования. Просто очень сложно построить качественный продукт, когда нет хорошей культуры качества. Когда каждый член команды работающей над продуктом не делает все возможное чтобы сделать качественный продукт. Часто это системная проблема. Программист знал что где-то могут быть проблемы, но не посчитал нужным сообщить. Или он написал код, достаточно сложный для того чтобы при последующих изменениях в нем никто не мог понять где же оно рухнет. Или код простой, но этот простой код внутри выстраивается в такие сложные цепочки взаимодействия, что ряд изменений (обычных последнее время) надо делать долго и аккуратно, внося его всюду. И в итоге что-то забывается и код не работает. Это возникает потому что программист нерадивый или потому что над ним сидит менеджер который по самые уши напортачил с планированием или наобещал ге-то с три короба и теперь заставляет команду работать в очень сжатые сроки воспитывая парадигму вида "после нас хоть потоп". Или менеджер жрет время команды на бесполезную активность вроде отчетов которые ему на самом деле не нужны (или он не объяснил команде просто и доступно зачем они нужны и тем самым деморализует ее). Или дурацкие митинги. Или менеджер игнорирует жалобы команды разработки просто говоря что-то вроде "keep going that way"? Или тестировщики занимаются не эффективным тестированием? Может они не видят под носом шаблонов в ошибках? Не могут их хорошо диагностировать и не представляют что как работает и зачем оно нужно коду/проекту/бизнесу? Или они заняты игрой в бюрократию и пишут тонны бесполезной тестовой документации вместо того чтобы тестировать? Или это просто плохие тестировщики которые умеют только жмакать на случайные кнопочки и бить кувалдой по монитору? Или эти тестировщики просто проверили что все что написано в ТЗ продукт делает и успокоились?




Это не спора ради, это я так, дополнить)

А сообщать о потенциальных и очень даже актуальных проблемах и дефектах на проекте разве не наша работа?

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

С условиями фишка такая -- вы сообщили о "дефекте в условиях", и ждёте, пока его исправят.
Но пока не исправили -- работать-то всё равно надо. Поэтому приходится искать воркэраунды.

Почему ждем? Мы же решения не принимаем, так что ждать тоже смысла нет. Наша работа предоставлять информацию о рисках и проблемах. И в этом плане memory leak это точно такая же проблема и точно такой же риск как и изъяны в рабочем процессе. Проблемы с Testability могут жрать не меньше времени чем регулярно падающая установка продукта. Про игнорирование постоянно повторяющихся шаблонов дефектов и проблем порождаемых многочисленными заплатками на них я вовсе молчу. И как правило никто не будет счастлив если я заберусь в код и начну себе хуки там делать для тестирования или просто сяду и перепишу (хотя мне так уже приходилось делать я все еще не вижу в этом ничего хорошего). И я не иду править код который приводит к утечкам памяти. Точно так же не пойду делать за менеджера/аналитика/архитектора/кого-то-еще-с-красивым-названием-должности его работу.

Мы можем тестировать быстрее, но...
Мы можем тестировать более эффективно, но...
Мы можем сообщать более качественную информацию о дефектах, но...

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

Там в портфолио еще бывшие и нынешние работадатели почему-то указаны... Нет, для портфолио ок, наверное, но осадочек остается.

Если ошибка сильно искажает смысл - то в комменты. А то может это и не ошибка вовсе. Если просто опечатки и т.п. то обычно игнорирую.

Когда он поймет, что надо изучить для проведения этого тестирования :) А может, есть более приоритетные задачи? На текущий момент? Глупо ведь отдавать неработающую по функциям систему, но зато "она выдержит 1000 юзеров сразу!". Приоритеты, расставляйте приоритеты!

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

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

Нененнененене! Врагу не пожелаю заниматься функциональщиной через нагрузочные инструменты!

Угу. Очень ок.

Для начала спасибо. Flexible File Writer как минимум
Ну и вопросы:
Raw Data Source?

А посмотрите в коде странички что с ним должно случаться на mouseOver, если интересно

3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.

10 часов по секунде это всего 36к кортежей, если все в одну кучу. Ну если расстараться то больше, но линейно и не сильно, почти наверняка. Это плюш, честно.
К тому же 10 часов на один тест это совсем не торт. Много такого редко надо. А после прогона можно результаты и обработать как следует.

зы: для анализа еще матмоды ок.

Андрей, кстати, было бы круто если бы кто-нибудь (например ты %)) собрал все эти материалы в одном месте и еще чтобы с камментами, картинками, линкой на то чтобы скачать лунапарк и все такое)

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

Я понимаю что вопросов сильно меньше не станет, но в меру ленивому мне было бы удобно. Ну а в целом для ознакомления публики, т.к. очень круто искать когда ты знаешь что искать тебе надо, но я готов поспорить что вопросы по прошлогоднему докладу из Ебурга про мяско просто так далеко не всем в голову придут.

http://jakarta.apach...tep_by_step.pdf

Мы просто сидим вместе в одном кабинете, планируем вместе, ревьювим всякое вместе и далее по списку. Очень удобно.

Скорее в цену незнания. Это не обязательно должны быть ошибки.

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

Зачем?

FFS? //div[@id='ui-datepicker-div']/div/div/select[2]

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

У меня есть PageObject. У меня в нем нормально, структурировано описаны все нужные мне элементы и действия на странице. У меня есть тесты, где никаких локаторов нет и быть не должно.
ЧЯДНТ? Зачем туда еще и конфиги? Зачем плодить сущности?