Очень интересно! Чем-то напомнило "Роковые кости" (Дэвид Бишов).
Предложение по решению задачи в поставленных условиях (без поиска багов):
Первые 10 км — любая тяга (тут уже предлагали драконью, но можно и обычную водяную с бесконечным волшебным источником воды, или взять идею из "Бена и Холли" и накастовать "Желе! Желе! Желе!").
Вот тут начинается интересное… С одной стороны, если мир имеет много общего с текущим, но размер мельчайших элементов с "фалангу пальца", то что мешает автору повторить те же химические реакции, что используются сейчас в ракетостроении? С другой стороны не совсем понятна степень и тип разрушений, предусмотренных в виртуальном мире. Если это физика частиц (воксели), то тут возможны допущения на то, что разрушения будут не похожи на те, что в жизни. Т.е. если взять металическую бочку без дна, поместить в нее взрывчатку, то будет создана тяга, а часть энергии уйдет в разрушение бочки (расщепление на воксели в зависимости от характеристик прочности материала), а не в ее искареживание. Тогда тяговый двигатель можно собрать из цепи таких бочек, которые будут взрываться в цепочке (каскаде), саморазрушаться, совбождая место для следующего эшелона, и таким образом создавать необходимую тягу для достижения необходимой для полета к "луне" скорости.
Торможение, опять таки, можно построить на волшебной тяге.
У меня есть один вопрос — если Земля и Луна созданы по подобию настоящих, используются ли для этого реальные параметры Космоса, в котором они находятся и взаимодейстуют? Т.е. какие характеристики у пространства между Землей и Луной? Вряд ли космические полеты предполагались по сценарию фентезийной игры и поэтому вряд ли программисты уделяли внимание этому пространству, а Луна для экономии ресурсов вращалась бы скорее всего по определенной траектории со смещением. Тогда, возможно, можно было бы использовать как-то неопределенные свойства неопределенной среды (пустоты).
И второй вопрос — это телепорт. Если между Землей и Луной есть пространство без магии, как тогда переносятся тела игроков? Получается что либо у магии нет границ, либо это какой-то жесткий хак программистов (но тогда это противоречие миру), либо есть какие-то скрытые свойства среды, которыми можно воспользоваться.
Теперь понятнее стало, спасибо. Решается, вероятно, задача генерации unit-тестов, т.е. тестирование непосредственно программных функций приложения, а не генерация комплексных функциональных и/или нагрузочных тестов, где каждый кейс — это реальный пользовательский кейс с определенной последовательностью вызовов функций приложения через доступные только пользователям каналы взаимодействия (например, трафик http) и связью между этими шагами (сохранение сессий, сквозная передача параметров и пр.)
Спасибо за разъяснение. Но это не совсем то, что я хотел узнать.
Есть несколько моментов:
Кол-во кейсов все таки ограничено количеством функций системы, которые разрабатываются программистами (а значит, их конечное число).
Если программа генерирует лог в определенном формате, не проще ли написать преобразователь этого формата в конечные кейсы (или хотя бы в транзакции, которые потом можно будет объединять)?
Кейсы тестирования все таки должны подразумевать параметризацию — те же входящие данные могут различаться для одного и того же паттерна поведения, а какие-то данные различаться не должны (например, идентификатор открытой вкладки). Как планируете разрешать эти вопросы?
Непонятно на счет Gerkin скрипта, т.к. для его работы должны быть расписана логика действия (что выполняется и при каких параметрах). Как я понял, генерацию этой части приведенное решение не включает?
Если вы решаете задачу генерации тест кейсов по логам приложения, то мне непонятна роль описанного классификатора на нейросети и не понятно, почему не справится предложенный мной в первом комментарии классификатор (тем более что и данные не с промышленной среды, а с тестовой, и их не много).
Тем более, что, если я правильно понял, вы предлагаете по сути "прокликать" функционал в системе, собрать лог, отправить его в нейросеть для распознавания уже известных паттернов? Или для генерации новых, но не понятно по каким данным?
Честно, я несколько раз перечитал статью. Примеры в статье немного синтетичные, из конкретики только два метода на стороне приложения, в которых обозначено логирование, а так же пример работы нейросети, которая обучается складывать числа. Как это транслировать на реальную системы, я вот никак не пойму.
Извините, но не понятно, для чего в описанной вами задаче нужна нейронная сеть? Приложение пишет логи и по сути сохраняет операцию и ее входящие данные (возможно, даже исходящие). И, как я понял, вы хотите выделять отдельно кейсы для последующего преобразования их в кейсы. Что мешает при логировании сохранять вместе с записью лога еще и сессию пользователя и потом просто разбивать логи по сессиям и паузам между действиями пользователя? Сами кейсы разделяются по "паттерну поведения", т.е. последовательности определенных действий или определенных входящих/исходящих данных, что можно задать заранее или преобразовывать все найденные таким образом кейсы, а потом группировать их по схожести "паттернов". Это достаточно простые шаги для простого перебора логов. Или я как-то неправильно понял цели или задачу? Поясните пожалуйста, потому что тема интересная.
Победители, как я понимаю, уже есть.
Интересно, сколько человек завтра в точке Х соберутся и не сойдет ли это за несанкционированный митинг? :)
А еще интересно, стоит ли туда идти. Так то от метро не близко, а народ тут рабочий в основном. И это даже не обеденное время.
Вопросов много…
Комментарий к моему комментарию:
Комментарий выше был оставлен еще 18.11.2017, но так случилось, что его приняли только спустя 3 дня. За это время комментарий уже потерял свою свежесть и актуальность, т.к. похожее мнение высказывалось выше пользователем ARD8S, и может показаться что я дублирую чье-то мнение. Это не так, просто «имеем, что имеем».
Мое мнение, люди боятся неизвестности в первую очередь, а не конкретных «предметов страха».
Почему мы (городские) не боимся автомобилей? Потому что понимаем природу автомобилей, как они двигаются, где зоны риска, что может пойти не так, и что мы можем сделать не так.
Почему мы при этом боимся пауков и диких животных? Потому что не знаем их природу — кто из них ядовит, кто опасен, на сколько опасен, как он двигается, как охотится и т.д. Разного рода научно-популярные передачи и СМИ только подогревают наши страхи, рассказывая о наиболее ярких экземплярах. Ну в самом деле, кто будет посвящать передачу домашним паукам, когда можно рассказать о тарантуле, черной вдове и об Австралии? Т.е. мы получаем только информацию об опасности, но не о природе опасности.
Еще один пример — многие люди старшего поколения боятся компьютеров и гаджетов. Кому-нибудь знает случаи, когда человек пострадал (физически) от нажатия не на ту кнопку? Они боятся непредсказуемости, непонимания последствий от производимых ими действий. И стресса от нового, непонятного, неизученного (ими).
Ну и контр примеры — когда люди побороли свои страхи, изучив природу страха. Каждый, думаю, найдет такой пример в себе.
Еще вопрос — есть ли у Вас (или может планируется) какое-то API, чтобы можно было выполнять хотя бы часть простых действий (запуск теста, например) из вне?
Отлично, это очень здорово) В основном именно отсутствие возможности автоматической синхронизации данных теста с данными утилизации меня отпугивало от применения JMeter. Спасибо!
Я так понимаю, что метрики собираются постоянно в Graphite, и потом Вы смотрите, какая утилизация была во время теста. Но не совсем понятно, у Вас в текущей реализации метрики утилизации HW, полученные из Graphite, как-то сливаются и отображаются в Analyzer? Можно ли получить среднюю утилизацию и утилизацию с шагом за период нагрузочного теста, чтобы можно было их так же сравнивать с прошлыми тестами, по аналогии с временами отклика?
Удивительно, что до сих пор никто не прокомментировал. Очень большую работу вы проделали, и достигли уже хороших результатов. Вы же наверняка видели как устроен LoadRunner? Чем-то Ваше решение напоминает Performance Center.
Как минимум появился интерес снова "потыкать" JMeter.
Но т.к. опыта работы с JMeter у меня мало, интересует такой вопрос:
Вы как-то собираете метрики утилизации HW во время тестов? Какие-нибудь сборщики интегрированы у вас (PerfMon, sar/top через ssh, Zabbix...)?
Интересно было бы узнать, как вы решили или будете решать такую задачу.
Посыл моего комментария несколько шире, чем несколько хотелок. Речь о том, что сервис очень плохо развивается, а иногда еще и деградирует, уступая позиции конкурентам.
Я понимаю, что не все выгодно сервису Яндекса. Я и не прошу работать в убыток ради хотелок пользователей. Но ведь речь совсем о мелочах:
1) Автоматизировать вызов такси в указанное пользователем время. Т.е. нажать за пользователя в час Х кнопку вызвать такси. К слову, только после того, как исчезла эта функция у Яндекса, я стал пользоваться другим известным агрегатором, у которого эта функция работает.
2) А по поводу вызова такси на другой номер телефона (т.е. для другого человека с возможностью выбора оплаты за него или чтобы он сам наличными оплатил) — идея на столько на поверхности уже несколько лет…
К счастью, про то, что у людей бывает больше чем 1 ребенок, для которого нужно кресло/бустер, в Яндексе все же осознали (недавно).
Ту схему, что вы описали, была до полной отмены возможности заказать такси к определенному времени. Но мне помнится, что несколько лет назад схема работала иначе: заказывая такси на раннее утро, я уже вечером видел, какая машина приедет. Т.е. мой заказ висел в системе и таксист мог его принять и позже отклонить, чтобы другой таксист мог принять. Более того, я мог наблюдать за передвижениями таксиста, когда он выезжал на мой заказ.
Так же я не соглашусь с Вами, что функция заказа к определенному времени нарушит логику.
Ответьте, чем отличается заказ такси за 10 минут до нужного времени пользователем или самой системой автоматически?
Мне кажется, Вы путаете необходимость пользователей услуги такси к самоорганизации и автоматизации процесса заказа такси в критичное время (отъезд, как пример) и какую-то мифическую логику распределения заказов, до которой пользователю в общем-то нет дела.
Я уже неоднократно писал в поддержку приложения с конкретными кейсами. Не поленюсь их привести: заказ для других людей (пример TimsTims), невозможность заказать такси из-за риска отсутствия связи (причин множество — от слабого заряда смартфона, до отсутствия интернета на месте), элементарная самоорганизация, когда нужно сосредоточиться на сборах (например), а не сидеть с трубкой и ждать, когда же заказ такси подтвердится. Я не понимаю, почему такие очевидные кейсы для меня, как для пользователя, отвергаются Яндекс.Такси, но активно используются конкурентами.
Позволю еще себе некоторые комментарии к реализации проекта (на правах «imho»):
Метод hello() не нужен, т.к. он полностью дублирует функцию метода page() с пустым параметром. Лучше добавить условие в обработку параметра или задавать сразу значение по-умолчанию из конфига.
Оптимизировав таким образом наше приложение до одной вьюхи, можно с уверенностью избавляться от остальных функций (проверка на наличие файла, конвертация в html и объединяющая их функция получения контента), т.к. все эти функции вызываются ровно один раз и логика в одном фрагменте будет прозрачнее, нежели разбросанная по функциям.
И еще я бы конфиг занес в код приложения (в шапку) и избавился таким образом еще от одной функции разбора конфига.
В итоге от проекта можно оставить 2 файла — файл приложения с одной вьюхой и параметрами и файл шаблона.
Очень интересно! Чем-то напомнило "Роковые кости" (Дэвид Бишов).
Предложение по решению задачи в поставленных условиях (без поиска багов):
У меня есть один вопрос — если Земля и Луна созданы по подобию настоящих, используются ли для этого реальные параметры Космоса, в котором они находятся и взаимодейстуют? Т.е. какие характеристики у пространства между Землей и Луной? Вряд ли космические полеты предполагались по сценарию фентезийной игры и поэтому вряд ли программисты уделяли внимание этому пространству, а Луна для экономии ресурсов вращалась бы скорее всего по определенной траектории со смещением. Тогда, возможно, можно было бы использовать как-то неопределенные свойства неопределенной среды (пустоты).
И второй вопрос — это телепорт. Если между Землей и Луной есть пространство без магии, как тогда переносятся тела игроков? Получается что либо у магии нет границ, либо это какой-то жесткий хак программистов (но тогда это противоречие миру), либо есть какие-то скрытые свойства среды, которыми можно воспользоваться.
Теперь понятнее стало, спасибо. Решается, вероятно, задача генерации unit-тестов, т.е. тестирование непосредственно программных функций приложения, а не генерация комплексных функциональных и/или нагрузочных тестов, где каждый кейс — это реальный пользовательский кейс с определенной последовательностью вызовов функций приложения через доступные только пользователям каналы взаимодействия (например, трафик http) и связью между этими шагами (сохранение сессий, сквозная передача параметров и пр.)
Если можно, давайте на конкретном примере разберем.
Есть сайт Яндекс.Почта (или любая другая почта).
Возмем базовые кейсы:
Что мне интересно:
Спасибо за разъяснение. Но это не совсем то, что я хотел узнать.
Есть несколько моментов:
Если вы решаете задачу генерации тест кейсов по логам приложения, то мне непонятна роль описанного классификатора на нейросети и не понятно, почему не справится предложенный мной в первом комментарии классификатор (тем более что и данные не с промышленной среды, а с тестовой, и их не много).
Тем более, что, если я правильно понял, вы предлагаете по сути "прокликать" функционал в системе, собрать лог, отправить его в нейросеть для распознавания уже известных паттернов? Или для генерации новых, но не понятно по каким данным?
Честно, я несколько раз перечитал статью. Примеры в статье немного синтетичные, из конкретики только два метода на стороне приложения, в которых обозначено логирование, а так же пример работы нейросети, которая обучается складывать числа. Как это транслировать на реальную системы, я вот никак не пойму.
Извините, но не понятно, для чего в описанной вами задаче нужна нейронная сеть? Приложение пишет логи и по сути сохраняет операцию и ее входящие данные (возможно, даже исходящие). И, как я понял, вы хотите выделять отдельно кейсы для последующего преобразования их в кейсы. Что мешает при логировании сохранять вместе с записью лога еще и сессию пользователя и потом просто разбивать логи по сессиям и паузам между действиями пользователя? Сами кейсы разделяются по "паттерну поведения", т.е. последовательности определенных действий или определенных входящих/исходящих данных, что можно задать заранее или преобразовывать все найденные таким образом кейсы, а потом группировать их по схожести "паттернов". Это достаточно простые шаги для простого перебора логов. Или я как-то неправильно понял цели или задачу? Поясните пожалуйста, потому что тема интересная.
Интересно, сколько человек завтра в точке Х соберутся и не сойдет ли это за несанкционированный митинг? :)
А еще интересно, стоит ли туда идти. Так то от метро не близко, а народ тут рабочий в основном. И это даже не обеденное время.
Вопросов много…
Комментарий выше был оставлен еще 18.11.2017, но так случилось, что его приняли только спустя 3 дня. За это время комментарий уже потерял свою свежесть и актуальность, т.к. похожее мнение высказывалось выше пользователем ARD8S, и может показаться что я дублирую чье-то мнение. Это не так, просто «имеем, что имеем».
Почему мы (городские) не боимся автомобилей? Потому что понимаем природу автомобилей, как они двигаются, где зоны риска, что может пойти не так, и что мы можем сделать не так.
Почему мы при этом боимся пауков и диких животных? Потому что не знаем их природу — кто из них ядовит, кто опасен, на сколько опасен, как он двигается, как охотится и т.д. Разного рода научно-популярные передачи и СМИ только подогревают наши страхи, рассказывая о наиболее ярких экземплярах. Ну в самом деле, кто будет посвящать передачу домашним паукам, когда можно рассказать о тарантуле, черной вдове и об Австралии? Т.е. мы получаем только информацию об опасности, но не о природе опасности.
Еще один пример — многие люди старшего поколения боятся компьютеров и гаджетов. Кому-нибудь знает случаи, когда человек пострадал (физически) от нажатия не на ту кнопку? Они боятся непредсказуемости, непонимания последствий от производимых ими действий. И стресса от нового, непонятного, неизученного (ими).
Ну и контр примеры — когда люди побороли свои страхи, изучив природу страха. Каждый, думаю, найдет такой пример в себе.
Еще вопрос — есть ли у Вас (или может планируется) какое-то API, чтобы можно было выполнять хотя бы часть простых действий (запуск теста, например) из вне?
Отлично, это очень здорово) В основном именно отсутствие возможности автоматической синхронизации данных теста с данными утилизации меня отпугивало от применения JMeter. Спасибо!
Я так понимаю, что метрики собираются постоянно в Graphite, и потом Вы смотрите, какая утилизация была во время теста. Но не совсем понятно, у Вас в текущей реализации метрики утилизации HW, полученные из Graphite, как-то сливаются и отображаются в Analyzer? Можно ли получить среднюю утилизацию и утилизацию с шагом за период нагрузочного теста, чтобы можно было их так же сравнивать с прошлыми тестами, по аналогии с временами отклика?
Удивительно, что до сих пор никто не прокомментировал. Очень большую работу вы проделали, и достигли уже хороших результатов. Вы же наверняка видели как устроен LoadRunner? Чем-то Ваше решение напоминает Performance Center.
Как минимум появился интерес снова "потыкать" JMeter.
Но т.к. опыта работы с JMeter у меня мало, интересует такой вопрос:
Вы как-то собираете метрики утилизации HW во время тестов? Какие-нибудь сборщики интегрированы у вас (PerfMon, sar/top через ssh, Zabbix...)?
Интересно было бы узнать, как вы решили или будете решать такую задачу.
Я понимаю, что не все выгодно сервису Яндекса. Я и не прошу работать в убыток ради хотелок пользователей. Но ведь речь совсем о мелочах:
1) Автоматизировать вызов такси в указанное пользователем время. Т.е. нажать за пользователя в час Х кнопку вызвать такси. К слову, только после того, как исчезла эта функция у Яндекса, я стал пользоваться другим известным агрегатором, у которого эта функция работает.
2) А по поводу вызова такси на другой номер телефона (т.е. для другого человека с возможностью выбора оплаты за него или чтобы он сам наличными оплатил) — идея на столько на поверхности уже несколько лет…
К счастью, про то, что у людей бывает больше чем 1 ребенок, для которого нужно кресло/бустер, в Яндексе все же осознали (недавно).
Так же я не соглашусь с Вами, что функция заказа к определенному времени нарушит логику.
Ответьте, чем отличается заказ такси за 10 минут до нужного времени пользователем или самой системой автоматически?
Мне кажется, Вы путаете необходимость пользователей услуги такси к самоорганизации и автоматизации процесса заказа такси в критичное время (отъезд, как пример) и какую-то мифическую логику распределения заказов, до которой пользователю в общем-то нет дела.
Я уже неоднократно писал в поддержку приложения с конкретными кейсами. Не поленюсь их привести: заказ для других людей (пример TimsTims), невозможность заказать такси из-за риска отсутствия связи (причин множество — от слабого заряда смартфона, до отсутствия интернета на месте), элементарная самоорганизация, когда нужно сосредоточиться на сборах (например), а не сидеть с трубкой и ждать, когда же заказ такси подтвердится. Я не понимаю, почему такие очевидные кейсы для меня, как для пользователя, отвергаются Яндекс.Такси, но активно используются конкурентами.
У Яндекса есть Танк (https://github.com/yandex/yandex-tank), но это утилита попроще чем выше обозначенные.
В итоге от проекта можно оставить 2 файла — файл приложения с одной вьюхой и параметрами и файл шаблона.