Mendel

У вас есть выбор. Или провести нагрузочное тестирование, или использовать JMeter. Если вы не будете использовать JMeter, то есть небольшой шанс провести нагрузочное тестирование. Если будете использовать - шансов нет.

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

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

Тот же jmeter вполне может подавать нужную нагрузку если хорошо понимаешь как он это делает и что нужно.

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

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

В случае с базой данных, у вас с 99% уже есть возможность понять какие запросы тормозят, где и какие локи берутся и во что вы упираетесь. Начните с этого, это скорее всего будет очень полезно. Для генерации "правильной" нагрузки на базу, вам понадобится ОЧЕНЬ хорошо подбирать очередность, параметры запросов и объём тестовых данных в базе, в противном случае, результаты не будут биться с реальностью. Кстати какую БД тестируете?

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

Обычно да, но не всегда. Особенно часто эти исключения случаются среди разработчиков выросших из тестировщиков

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

Ощущение "элитарности", редко бывает обоснованным. Само IT сложно отнести к элите с какой стороны не посмотреть. Деньги, техническая сложность, социальный статус - все серединка на половинку. Интересная область, но нос задирать причин нет. Но даже внутри, настоящие гуру как правило и в operations умеют, и код способны написать и тестами его обнести. В какой то области они особенно хороши. Специально сохранил, на случай если когда то элитарность зачешется - https://www.youtube....h?v=MTuLj1GKrvs

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

 

........ Вы любите придумывать и проводить функциональные тесты? ->

 - поиск технически сложных багов, в ПО с повышенными требованиями к качеству

 

 

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

"Эпичный" баг - что это? Падение в полнолуние? Утечки памяти? Зависание при овер 9000 запросов? Чтобы до этого дошло нужно, чтобы программа так или иначе, для начала, сделала то, что нужно пользователю, и не сделала того, что не нужно... и кстати, срочно :-) Это гораздо важнее, остальное потом, может быть.. когда-нибудь.

 

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

 

Мои слова - не придирки к формулировке и не попытка "наехать" на "опозиционный" взгляд. Я отлично понимаю поднятую вами проблему. Обобщение на всё функциональное тестирование действительно не уместно.

Всё что ниже исключительно мой взгляд.

В любой области очень неприятно быть "overqualified". Для человека который на ночь глядя коммитит в апстрим модной базы или какой то опен сорс операционки, нужно прилично поломать себя для того что бы покрыть тестами очередной "портальчик" на работе - это скучно и трудно морально. А ещё это верный путь к выгоранию. Но для человека который только входит в область, это ново, и это интересно. Он вполне может получать удовольствие от тестирования бизнес требований. Дальше, тот кому интереснее результат - будет больше "управлять". Тот кому интереснее постоянно учиться и разминать мозг, двинет в автоматизацию(а может и в разработку в итоге) или вот в такое тестирование как я описал выше. И те и те сменят работу если бизнес такие задачи им не сможет предложить(ну или выгорят).

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

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

"Эпичный баг"? Например рэйс кондишен при работе с памятью в какой нибудь системе реалтайм биржевых торгов, трудно поймать, и ошибку всего на 0.01% может дать(в абсолютных значениях будет гораздо страшнее). Или вот к примеру недавно наткнулся, внешне всё кажется правильным, а часть полезной работы не делается(tcpdump явно показал, одно из действий завершается таймаутом, но система это обратывает и выдаёт внешне правильный ответ + ничего не пишет в логи). Много можно привести, хотя я функциональным давно не занимаюсь.

А вот парочка разборов с следствиям:

https://habrahabr.ru...io/blog/310862/

https://habrahabr.ru...io/blog/307788/

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

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

Там ведь те же проблемы, и решаются они так же, те кто перерос ищут работу интереснее.

Вы любите придумывать и проводить функциональные тесты? -> Да, мне нравится проводить тесты, находить, описывать и перепроверять баги

Это не совсем честно.

Вопрос поставлен примерно как: Любите ли вы программировать? -> Да, мне нравится клепать однотипные сайтики на php.

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

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

Никто не мешает, тестировать алгоритмы или математически сложные системы на уровне API или кода. Или может быть заняться тестированием ПО для спецжелезок?

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

Людям как минимум может нравиться:

 - результат, т.е. влияние которое они оказывают на продукт

 - поиск технически сложных багов, в ПО с повышенными требованиями к качеству

Diadema, имхо вам надо кардинально менять либо подход к работе, либо запросы. Всё просто, требуемые навыки надо уметь получать самостоятельно (есть компании которые помогают с этим, но в первую очередь учат тех кто доказал умение учиться). На практике, у массы людей это прекрасно получается. Найти для себя оправдания очень просто. Но пока вы ищете оправдания, вы будете работать у тех кто не способен нанять более сильных специалистов. Как результат, ваш рост будет тормозиться ещё и слабым работодателем.
В вашем конкретном случае, вам надо:

 - проанализировать вашу текущую работу и вывести по пунктам из этого ваши умения - это то что вы будете продавать.

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

Но главное - поменять подход. Сейчас это выглядит как: "Я работаю N лет и толком не понимаю что делаю и зачем. В других местах хотят linux и автоматизацию, но не ясно ни что это такое, ни что сделать что бы знания сами материализовались в голове". С таким подходом, я бы вас на работу не взял. Даже интересно, а кто нибудь бы взял?