Ретест делается после поправки какой либо ошибки Регрессионка, грубо говоря, повторяя проверка уже по готовым сценариям

Я ж и говорю что неидеальное пояснение, правильное описание ре-теста в третьем пункте, однозначно

Я ж и говорю что неидеальное пояснение, правильное описание ре-теста в третьем пункте, однозначно

Согласен

Но если включить немного СПГС, и предположить что тест-кейсы пишутся в процессе тестирования фичи, то после фикса ты по сути прогоняешь тест снова

То же самое что надо сделать в третьем пункте, предположить что баг найден именно регрессией

регрессия находит баги, точка. если она их находит, то регрессия случается раньше ретеста :) никакого противоречия

Ставлю на первый

Исходя из определения ретестинга, это не правильный вариант

а свой нельзя написать?)

Правильно было бы описание ре-теста из третьего пункта, а регрессии из первого

Re-testing is executing a previously failed test against new software to check if the problem is resolved. After a defect has been fixed, re-testing is performed to check the scenario under the same environmental conditions. During Re-testing, testers look for granular details at the changed area of functionality, whereas regression testing covers all the main functions to ensure that no functionalities are broken due to this change.

Ретест не первый вариант

Я ошибся, исправил сообщение

Как тут уже сказали выше я - не настоящий тестировщик, но вставлю свои 5 копеек. На мой взгляд (и он может отличаться от общепринятых положений) регрессия и ретест идут последовательно. Приведу пример что я имею ввиду: 1. Приходит билд или обновление. Мы гоняем стандартный набор проверок и регрессию, чтобы определить, что ничего старого не раздолбали. 2. После того как пункт 1 завершен мы ждем фикса на найденные баги. Когда этот фикс приходит мы проводим ретест в рамках валидации багов. Он может иметь меньший объём чем регрессия.

Ну он в любом случае меньше, да

Правильно было бы описание ре-теста из третьего пункта, а регрессии из первого

Согласен, нет идеального варианта (как ты выше и писал) Но я более склонен ко второму варианту из перечисленных

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

Правильно было бы описание ре-теста из третьего пункта, а регрессии из первого

при чем тут определения? :) у вас есть какие то утверждения. они могут быть определениями, а могут быть свойствами

в третьем пункте факт про регрессионное тестирование - не определение, а свойство

Относительно регрессии, то она может (и будет) так же проводиться ПОСЛЕ ре-тестов. После очередного билда / перед очередным релизом

И после нее снова будут фиксы и ре-тесты

это очевидно, потому что есть SDLC

Именно

И сложно сказать что раньше в нем происходит

Правильным будет засчитан 1 вариант, т. к. остальные методом исключения отбрасываются

Правильным будет засчитан 1 вариант, т. к. остальные методом исключения отбрасываются

Можно подробнее? У меня он был последним вариантом. И после обсуждение склонен к 3му варианту

Ретестинг там точно верный, регрессия немного спорно, но она выполняется как раньше так и позже

В идеале позже

Ретестинг там точно верный, регрессия немного спорно, но она выполняется как раньше так и позже

Вот именно, что нет ограничения по времени, можно и раньше, и позже, поэтому не очень близкий вариант

- re-testing is running a test again - регрессия гонимая в CI точно также "running test again" - regression is fiding side effects - вообще, любого рода тестирование продукта, это обращение внимания на сайд-эффекты (шок!)

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

Во втором - ретестинг сайт эффекты не ищет

Общем да, с вероятностью 99% правильным будет 1ый вариант =)

4-й вообще не имеет отношения к определениям

Можно даже нагуглить ответ

А в первом - совершенно не противоречит определениям)

Это из Sample Paper ISTQB тест, построение вопроса и ответов по крайне мере идентичное)

Всем привет. Подскажите пожалуйста, есть ли чат по Performance testing?

Боже, вы все еще это обсуждаете?

рассуди нас, о мудрейший!

Всем привет. Подскажите пожалуйста, есть ли чат по Performance testing?

Обычно тут и обсуждают, может еще в автомейшене. Но я там не сижу

рассуди нас, о мудрейший!

Это слишком бессмысленно даже по моим меркам.

Пгостите, всегда хотел узнать, а в чём смысл таких чотких формулировок и споров по ним?

Спасибо всем за обсуждение

https://www.softwaretestinghelp.com/istqb-foundation-level-exam-sample-paper-ii/ тут это вопрос 26

вы действительно в общении уточняете, что будете делать именно ретест, а не регрессию?

ответ А =)

done

консоль браузера для перфоманс тестинга вполне можно использовать? Или это сейчас не модно?

Пгостите, всегда хотел узнать, а в чём смысл таких чотких формулировок и споров по ним?

Сдать экзамен ISTQB

например смотреть сколько времени идёт запрос на выборку данных

консоль браузера для перфоманс тестинга вполне можно использовать? Или это сейчас не модно?

Использую активно

по сути только вкладка нетворк там нужна и всё

Ну есть еще вкладка Performance, но она про client-side

а если я хочу например отправить 1000 запросов и посмотреть минимальное и максимальное время, среднее, то это уже жметр?

А так да, обычно нетворка хватает

Ну или другая тула

Если прям от жмитра воротит (бывает такое)

а если я хочу например отправить 1000 запросов и посмотреть минимальное и максимальное время, среднее, то это уже жметр?

это в жметре делается за 20 секунд, зачем мудрить?)

это в жметре делается за 20 секунд, зачем мудрить?)

так никто и не мудрит, я сам за жметр спросил

а если я хочу например отправить 1000 запросов и посмотреть минимальное и максимальное время, среднее, то это уже жметр?

Если только это, тогда есть на выбор множество утилит. Жметер удобен для создания сложных сценариев

Я про то что браузерная консаоль не дает сделать это нативно, может и можно как то закостылить, но для этого есть самый популярный инструмент, зачем искать решения? :)

Если только это, тогда есть на выбор множество утилит. Жметер удобен для создания сложных сценариев

например каких?

Я про то что браузерная консаоль не дает сделать это нативно, может и можно как то закостылить, но для этого есть самый популярный инструмент, зачем искать решения? :)

я согласен что жметром это всё можно сделать, но вдруг есть решение получше :)

чарльз наверняка может такое сделать

Тут вопрос в том, хочешь ли ты при этих 1000 запросах нагрузить сервак, или просто 1000 лупов для сбора статы

берп какой нить

Да можно хоть фиддлером

Вопрос в том, что жмитр даст при этом самый читабельный отчет

Тут вопрос в том, хочешь ли ты при этих 1000 запросах нагрузить сервак, или просто 1000 лупов для сбора статы

для сбора статы

вот просто хочу посмотреть, что такой-то вопрос выполняется не более N секунд

при последлвательном обращении к серверу, т.е. 1 запрос за раз

Ну тогда реально жмитр. За пару минут создал самплер и лупанул его 1000 раз тредом

понял, спасибо

Главное лисенеры не забыть повесить)

а почему консоль не советует запускать тесты в гуи моде?

Переполнение памяти произойдет

вот прям когда запускаешь жметр там написано что гуи мод используйте только для создания и редактирования тестов

например каких?

Да тот же apache benchmark.

потому что нагрузочное тестирование в гуи моде намного больше юзает памяти

Гуй много данных в памяти хранит

вот прям когда запускаешь жметр там написано что гуи мод используйте только для создания и редактирования тестов

Рекомендую Taurus. Простые тесты вообще влёт создаются. Там внутри по дефолту жметер

Например лисенеры просто капец засирают ее

Но 1000 лупов можно и в гуе

А если дружите с nodejs, есть хороший тул artillery.

А если с пайтоном то Locust

Если питон - locust

Но в жмитре это все равно быстрее и проще

хз, имхо жметр проще изза гуи чем таурус

В Таурус текст по той задаче, что выше - делается быстрее

Отчёт красивее)

И никто не мешает скормить таурусу готовый jmx

Его надо курить, как и любую новую тулу. Если знаешь жмитр, то зачем еще заморачиваться чем-то. Тем более для такой задачи

Согласен.

Тогда просто жметер. Универсально.

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

гугли user story

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

в виде простецкого тестплана на основе коллективного анализа продукта

в виде простецкого тестплана на основе коллективного анализа продукта

В тест план пихать ТЗ - это какое-то очень иезуитское коварство.

Тест-план - это тест-план. Документация по проекту - это документация по проекту. Не надо всё в одну кучу.