Size: a a a

QA — Load & Performance

2020 December 23

СФ

Степа Фомичев... in QA — Load & Performance
Ну как минимум из того что вы написали я могу сделать вывод что у вас три компонента: нагрузочная станция, система, заглушка (например, вот тут есть разделение - Источник нагрузки и заглушку разрабатываете вы)
источник

СФ

Степа Фомичев... in QA — Load & Performance
У вас есть в доступе система, которую вы должны тестировать?
источник

NG

Natalia GUSKOVA in QA — Load & Performance
Степа Фомичев
У вас есть в доступе система, которую вы должны тестировать?
система из 3-х компонентов нагрузочная станция - тестируемый компонент - заглушка заменяющая внешний серв
источник

СФ

Степа Фомичев... in QA — Load & Performance
Да, я понял, что имелось в виду в задании:

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

Тут описываетс один процесс с разных сторон)
источник

NG

Natalia GUSKOVA in QA — Load & Performance
Степа Фомичев
Да, я понял, что имелось в виду в задании:

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

Тут описываетс один процесс с разных сторон)
мне нужно описать реализацию процесса
источник

NG

Natalia GUSKOVA in QA — Load & Performance
только я не совсем понимаю как описывать. надо ли уточнять используемые системы?
источник

NG

Natalia GUSKOVA in QA — Load & Performance
заглушка как я понимаю, это какой то условный веб серв, который по запросу пост - будет генерить мне клиента, с указаным в методе пост айдишником, что якобы этот клиент есть
источник

NG

Natalia GUSKOVA in QA — Load & Performance
или лучше гетом и ай ди в заголовке?
источник

СФ

Степа Фомичев... in QA — Load & Performance
Тогда отвечаю на вопрос:

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

1) Да, ваша заглушка должна генерить случайные значения для полей. Для этого вам следует иметь модель с типами данных и знать как эти данные валидируются (чтобы генерировать данные по каким-то правилам).
2) Если я правильно понял процесс, то проще всего это сделать так:
- заглушка получает запрос
- Кидает в очередь этого юзера
- Отвечает структурой данных user
- Раз в n-секунд из очереди вычитываются все юзеры и отправляются подтверждения.

Второй вариант:
- заглушка получает запрос
- Записывает в бд юзера со статусом типа: не_отправлено_подтверждение
- Отвечает структурой данных user
- Раз в n-секунд из бд вытаскиваются все юзеры с этим статусом, статус меняется на отправлено_подтверждение и отправляется запрос, соответственно
источник

СФ

Степа Фомичев... in QA — Load & Performance
Natalia GUSKOVA
заглушка как я понимаю, это какой то условный веб серв, который по запросу пост - будет генерить мне клиента, с указаным в методе пост айдишником, что якобы этот клиент есть
Ну я думаю запрос, который будет отправлять система не вам определять)
источник

NG

Natalia GUSKOVA in QA — Load & Performance
Степа Фомичев
Тогда отвечаю на вопрос:

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

1) Да, ваша заглушка должна генерить случайные значения для полей. Для этого вам следует иметь модель с типами данных и знать как эти данные валидируются (чтобы генерировать данные по каким-то правилам).
2) Если я правильно понял процесс, то проще всего это сделать так:
- заглушка получает запрос
- Кидает в очередь этого юзера
- Отвечает структурой данных user
- Раз в n-секунд из очереди вычитываются все юзеры и отправляются подтверждения.

Второй вариант:
- заглушка получает запрос
- Записывает в бд юзера со статусом типа: не_отправлено_подтверждение
- Отвечает структурой данных user
- Раз в n-секунд из бд вытаскиваются все юзеры с этим статусом, статус меняется на отправлено_подтверждение и отправляется запрос, соответственно
типы данных есть, я просто сюда их не кидала чтобы не перегружать вопрос
источник

NG

Natalia GUSKOVA in QA — Load & Performance
Степа Фомичев
Тогда отвечаю на вопрос:

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

1) Да, ваша заглушка должна генерить случайные значения для полей. Для этого вам следует иметь модель с типами данных и знать как эти данные валидируются (чтобы генерировать данные по каким-то правилам).
2) Если я правильно понял процесс, то проще всего это сделать так:
- заглушка получает запрос
- Кидает в очередь этого юзера
- Отвечает структурой данных user
- Раз в n-секунд из очереди вычитываются все юзеры и отправляются подтверждения.

Второй вариант:
- заглушка получает запрос
- Записывает в бд юзера со статусом типа: не_отправлено_подтверждение
- Отвечает структурой данных user
- Раз в n-секунд из бд вытаскиваются все юзеры с этим статусом, статус меняется на отправлено_подтверждение и отправляется запрос, соответственно
такс еще раз я повторю, (не то что вы сказали, а то что я услышала))
источник

NG

Natalia GUSKOVA in QA — Load & Performance
Степа Фомичев
Тогда отвечаю на вопрос:

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

1) Да, ваша заглушка должна генерить случайные значения для полей. Для этого вам следует иметь модель с типами данных и знать как эти данные валидируются (чтобы генерировать данные по каким-то правилам).
2) Если я правильно понял процесс, то проще всего это сделать так:
- заглушка получает запрос
- Кидает в очередь этого юзера
- Отвечает структурой данных user
- Раз в n-секунд из очереди вычитываются все юзеры и отправляются подтверждения.

Второй вариант:
- заглушка получает запрос
- Записывает в бд юзера со статусом типа: не_отправлено_подтверждение
- Отвечает структурой данных user
- Раз в n-секунд из бд вытаскиваются все юзеры с этим статусом, статус меняется на отправлено_подтверждение и отправляется запрос, соответственно
из нагрузочной системы я даю команду, на запрос клиента по айди. заглушка генерирует клиента с задаными значениями и отправляет обратно. здесь по статусу 200 я делаю парс ответа и отправляю полученого клиента в тестируемую систему. за этим уже туда я посылаю подтверждающий запрос что клиент получен и поля соответствуют сгенерированым
источник

СФ

Степа Фомичев... in QA — Load & Performance
здесь по статусу 200 я делаю парс ответа и отправляю полученого клиента в тестируемую систему
источник

СФ

Степа Фомичев... in QA — Load & Performance
Где "здесь"?)
источник

NG

Natalia GUSKOVA in QA — Load & Performance
ну мне на запрос приходит в ответ статус
источник

СФ

Степа Фомичев... in QA — Load & Performance
На целевую систему
источник

СФ

Степа Фомичев... in QA — Load & Performance
Правильно?
источник

NG

Natalia GUSKOVA in QA — Load & Performance
ну я же запрос из нее делаю, с помощью нагрузочной системы. нагрузочная система как элемент управления
источник

СФ

Степа Фомичев... in QA — Load & Performance
Вы же понимаете, что
1) Целевую систему вы не программируете
2) Заглушка не общается с нагрузочной станцией
источник