VR
Вы так и пользовательские ошибки сделаете эталоном, а потом когда их поправят будете доказывать, что разработчики плохие опять сломали :)
Так это нормальный подход. Фиксируем, как есть сейчас и при изменениях смотрим.
Size: a a a
2018 October 30
NV
Вы так и пользовательские ошибки сделаете эталоном, а потом когда их поправят будете доказывать, что разработчики плохие опять сломали :)
ошибки можно отфильтровать. Главное, чтобы 200 осталось 200, а 302 тоже осталось или стало 200.
S
На сколько я помню, все подобные попытки сделать в лоб закончились ну не очень хорошо. Логи это источник для статистики. Оттуда можно взять данные для приоритета порядка реализации тестов. Можно выделить критичные зоны и соответствующие кейсы. А вот тупо повторять запросы.. ну это тупо :)
NV
а как же дубликаты запросов и тестов ?
как же оценка покрытия ?
то что вы хотите сделать как-то не совсем похоже на тестирование - просто эмитация запросов юзеров без каких либо качественных характеристик...
как же оценка покрытия ?
то что вы хотите сделать как-то не совсем похоже на тестирование - просто эмитация запросов юзеров без каких либо качественных характеристик...
Кроме этого будут ещё вручную написанные тесты по классам эквивалентности.
AT
а какой тогда профит от работы по распарсу логов и созданию кейсов на базе них ?
я пытаюсь понять, какую пользу вы планируете получить, от таких тестов, если в рамках обычного планирования тестирования у вас будут кейсы...
Выглядит так, как будто планированию тестирования - априори не доверяете...
я пытаюсь понять, какую пользу вы планируете получить, от таких тестов, если в рамках обычного планирования тестирования у вас будут кейсы...
Выглядит так, как будто планированию тестирования - априори не доверяете...
SM
Вот это не оно? https://github.com/Gonzih/log-replay ключевой слово replay
KK
А никто же не говорил, что они будут полностью заменять тестирование =)
SM
я думаю симулировать примерно сопоставимую нагрузку для стресса
AT
я думаю симулировать примерно сопоставимую нагрузку для стресса
не, вы тут явно не в том направлении тогда копаете:
нагрузка может быть на приложеньку, балансировщик, рендер или какое-то глубоко-расчетный механизм внутри приложеньки;
нужно понимать точку приложения усилий, а не брать за эталон рандомный кусок времени с рандомным интересом пользователей зависящим от кучи неуправляемых факторов...
нагрузка может быть на приложеньку, балансировщик, рендер или какое-то глубоко-расчетный механизм внутри приложеньки;
нужно понимать точку приложения усилий, а не брать за эталон рандомный кусок времени с рандомным интересом пользователей зависящим от кучи неуправляемых факторов...
AT
скажем так, лог запросов может дать примерное представление о зоне интереса пользователей;
типа как статистика - а вот расчитывать нагрузочное тестирование и искать допустимые пиковые нагрузки - нужно точечно, понимая какие механизмы и в каком количестве внутри приложения задействованы
типа как статистика - а вот расчитывать нагрузочное тестирование и искать допустимые пиковые нагрузки - нужно точечно, понимая какие механизмы и в каком количестве внутри приложения задействованы
SM
согласен, пытался @Nick_Volynkin помочь с его вопросом
NV
Но какая цель то внедрения такого инструмента?
Переносим огромный массив текста с реализации_А на реализацию_Б. Во имя SEO нельзя потерять ни одной ссылки.
NV
А ссылки у клиентов есть какие угодно. Из закладок, из старых постов на форумах, в кешах поисковиков, из старых версий продукта, из истории браузера, ЧПУ, не-ЧПУ, локализованные ЧПУ...
NV
Т.е. это инструмент в том числе для того, чтобы проанализировать и выделить кейсы, которые обычным здравым смыслом не выводятся.