OK
Пул пользаков в тестовой среде обычно в процессе жизни функционала в проме приходится увеличивать итерационно.
а как их менеджить? Я имею ввиду креды просто сохранить куда то в файл?
Size: a a a
2020 October 01
M
Логины в пуле, пароль у всех один, например.
M
Текстового файлика будет для обычных авторизаций достаточно.
M
Если есть протухающие, но с большим сроком жизни (1 час или больше) авторизационные токены, можно бд прикрутить.
OK
Логины в пуле, пароль у всех один, например.
спасибо!
S7
спасибо!
авторизация это входная точка, поэтому как по мне нет смысла отдельно тестировать эндпоинты без авторизации, т к в реальных условиях максимальная производительность эндпоинтов в сценарии будет равна макс производительности наименее производительного эндпоинта.
VG
Sam 7
авторизация это входная точка, поэтому как по мне нет смысла отдельно тестировать эндпоинты без авторизации, т к в реальных условиях максимальная производительность эндпоинтов в сценарии будет равна макс производительности наименее производительного эндпоинта.
А ещё выполнение люьой операции тратит часть ресурсов системы, так что нужно тестировать всеми значимыми операциями одновременно
:)
:)
S7
А ещё выполнение люьой операции тратит часть ресурсов системы, так что нужно тестировать всеми значимыми операциями одновременно
:)
:)
👍
AG
А ещё выполнение люьой операции тратит часть ресурсов системы, так что нужно тестировать всеми значимыми операциями одновременно
:)
:)
не, ну если все на микросервисах висит, то их можно на стадии разработки потригерить)
AG
но это отдельные случаи
VG
Alex Grishutin
не, ну если все на микросервисах висит, то их можно на стадии разработки потригерить)
Это скорее для отладки можно грузить отдельный микросервис
Или для поиска узкого места в конкретном микросервисе
А когда тестируется система - бить по микросервисам не гуд, ведь БД-то у них одна.
Легко можно пропустить дедлоки или блокировки если тестить по частям
Или для поиска узкого места в конкретном микросервисе
А когда тестируется система - бить по микросервисам не гуд, ведь БД-то у них одна.
Легко можно пропустить дедлоки или блокировки если тестить по частям
S7
Alex Grishutin
не, ну если все на микросервисах висит, то их можно на стадии разработки потригерить)
это в большей мере нужно для дальнейшего сравнения оптимизации или деградации производительности отдельного микрика после обновления
AG
Не, я же говорю, что на стадии разраьотки. А в итогге целиком систему в любом случае грузить надо.
Вон, у меня сейчас на проекте один конкретный запрос систему валит при 1 рпсе... Все остальные работают прямо отлично)
Вон, у меня сейчас на проекте один конкретный запрос систему валит при 1 рпсе... Все остальные работают прямо отлично)
ΙΤ
Это скорее для отладки можно грузить отдельный микросервис
Или для поиска узкого места в конкретном микросервисе
А когда тестируется система - бить по микросервисам не гуд, ведь БД-то у них одна.
Легко можно пропустить дедлоки или блокировки если тестить по частям
Или для поиска узкого места в конкретном микросервисе
А когда тестируется система - бить по микросервисам не гуд, ведь БД-то у них одна.
Легко можно пропустить дедлоки или блокировки если тестить по частям
У каждого мс должна быть своя бд по хорошему
ΙΤ
Sam 7
это в большей мере нужно для дальнейшего сравнения оптимизации или деградации производительности отдельного микрика после обновления
+
AG
У каждого мс должна быть своя бд по хорошему
ууу, ну это в идеальном мире)
AG
прямо в вакууме)
VG
Не уверен, что это идеальная ситуация
VG
Если есть 100500 метаданных по клиентам системы - их что, дублировать в каждой бд?
А если они часто меняются - ресурсы и время тратить на синхронизацию?
А если они часто меняются - ресурсы и время тратить на синхронизацию?
ΙΤ
Хороший кейс для продуктовых команд это бенчмаркать мс на каких то более менее значим релизах