Какой замечательный скриншот)

Какой замечательный скриншот)

фотка экрана на телефон :)

но мы не будем глумиться над этим, нет, нет, нет.

Мы не глумимся, мы ждем больше инфы. Если сайт открытый, то ссылку на него и как получить алерт

Какой замечательный скриншот)

это фильтр специальный)

это фильтр специальный)

+100 баллов Гриффиндору

Уж извините, на телефоне неудобно писать автотесты. А веб телегой не пользуюсь на работе.

Уж извините, на телефоне неудобно писать автотесты. А веб телегой не пользуюсь на работе.

так вы нам информацию по своему запросу дадите? Или удалось решить самостоятельно?

Уж извините, на телефоне неудобно писать автотесты. А веб телегой не пользуюсь на работе.

слабак

Уж извините, на телефоне неудобно писать автотесты. А веб телегой не пользуюсь на работе.

десктоп есть

у кого-то есть опыт написания end-to-end теста от бэк-энда до экрана мобильного устройства? вопрос в том, в каких местах и какие проверки целесообразно проставить для такого теста? в бек-энде 3 системы проходятся линейно (1 - создание, 2 - преобразование для системы выдачи, 3 - выдача по запросу с мобилы). потом данные запрашиваются мобильником

не совсем понял вопрос, но похоже на набор api и юнит тестов )))

Энд ту энд - это же пользовательский тест по сути.

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

у кого-то есть опыт написания end-to-end теста от бэк-энда до экрана мобильного устройства? вопрос в том, в каких местах и какие проверки целесообразно проставить для такого теста? в бек-энде 3 системы проходятся линейно (1 - создание, 2 - преобразование для системы выдачи, 3 - выдача по запросу с мобилы). потом данные запрашиваются мобильником

мне кажется вы не совсем понимаете что такое end-to-end

Возможно. Определения енд-ту-енд и интеграции регулярно смешиваются

Есть процесс создания и доведения информации до мобильного устройства. Необходимо реализовать тест, проверяющий, что системы корректно развёрнуты и способны выполнить данный процесс. Все - апи

попробуйте составить этот сценарий из запросов к апи

(если оно нужно)

мне кажется вы не совсем понимаете что такое end-to-end

++

Он составлен. Вопрос - какие узлы оптимально проверять?

попробуйте составить этот сценарий из запросов к апи

Он составлен. Вопрос - какие узлы оптимально проверять?

Пользуйтесь функцией "реплай" )

В ява-коде?)

в телеграме.

А, окей)

А в Джава-кода даже не знаю.

Он составлен. Вопрос - какие узлы оптимально проверять?

что хотите то и проверяйте

начните с конечного результата от вашего сценария

что хотите то и проверяйте

Уточню: нужно ли встраивать проверки между узлами для локализации проблемы в случае, если в мобилу ничего не придёт. Или это делается как-то иначе?

Уточню: нужно ли встраивать проверки между узлами для локализации проблемы в случае, если в мобилу ничего не придёт. Или это делается как-то иначе?

кому нужно то?

вам?

я вот честно не умею мысли читать

кому нужно то?

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

решайте проблемы по мере их поступления

если какие то моменты в сценарии по вашему неустойчивы, покройте их отдельными сценариями

если какие то моменты в сценарии по вашему неустойчивы, покройте их отдельными сценариями

Отдельное покомпонентное тестирование реализовано.

Здесь вопросы вызваны тем, что мне не совсем ясна необходимая степень детализации проверок при написании конкретно такого типа теста

Я могу просто проверить, что все пришло, и ок. Но вряд ли тогда получится быстро ответить на вопрос: «что не так?»

С другой стороны проверять корректность работы каждого запроса явно избыточно

энд ту энд тесты не должны отвечать на вопрос что не так. Энд ту энд тесты должны проверять работу всей цепочки, которая имеет два конца: пользователь что-то делает и пользователь что-то получает. Интеграции внутри проверяют интеграционные тесты. На энд ту энд тестах мы эмулируем работу пользователя и условия максимально приближенные к продовским. По возможности даже дату и окружения максимально близкие.

просто после того как поделал какие-то операции с элементом(ами) снова их найди

или используйте Selenide

энд ту энд тесты не должны отвечать на вопрос что не так. Энд ту энд тесты должны проверять работу всей цепочки, которая имеет два конца: пользователь что-то делает и пользователь что-то получает. Интеграции внутри проверяют интеграционные тесты. На энд ту энд тестах мы эмулируем работу пользователя и условия максимально приближенные к продовским. По возможности даже дату и окружения максимально близкие.

Спасибо! Значит одна проверка.

Привет всем! Кто использует в своей работе HP ALM? Какая у вас практика заполнения Expected result для каждого шага? Как вы к этому относитесь, если учесть, что в новой версии ALM (Octane) ушли от схемы шаг-проверка?

Уточню: нужно ли встраивать проверки между узлами для локализации проблемы в случае, если в мобилу ничего не придёт. Или это делается как-то иначе?

Проверки между узлами в функциональных тестах зло. Избегать максимально. Если в каком-то месте часто возникает ошибка, но это должен быть отдельных тест

Привет всем! Кто использует в своей работе HP ALM? Какая у вас практика заполнения Expected result для каждого шага? Как вы к этому относитесь, если учесть, что в новой версии ALM (Octane) ушли от схемы шаг-проверка?

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

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

Не, я про скелет кейсов :) Общепринятая практика - * набор шагов * * ожидаемый результат* В HP ALM - шаг - ожидаемый результат шаг - ожидаемый результат ...

Не, я про скелет кейсов :) Общепринятая практика - * набор шагов * * ожидаемый результат* В HP ALM - шаг - ожидаемый результат шаг - ожидаемый результат ...

да ладно? у нас - шаг - ожидаемый шаг - ожидаемый

например: Шаг: войти в систему под учётной записью с ролью "Оператор" Результат: Вход выполнен успешно. Система отображает...

это уже вопрос тест-дизайна.

да ладно? у нас - шаг - ожидаемый шаг - ожидаемый

и у нас так. интересно вот стало, есть ли те, кто делает иначе. По мне так это перегруз кейсов лишними проверками.

Проверки между узлами в функциональных тестах зло. Избегать максимально. Если в каком-то месте часто возникает ошибка, но это должен быть отдельных тест

Спасибо! Вот я и ищу оптимальный минимум

Коллеги, какое у вас отношение к такой идее: БЭ рендерит layout, и покрывает своими спецификациями (фактически тестами), а ФЭ уже отображает этот layout на клиентах.

Коллеги, какое у вас отношение к такой идее: БЭ рендерит layout, и покрывает своими спецификациями (фактически тестами), а ФЭ уже отображает этот layout на клиентах.

SPA? Никогда не понимал такой подход, хотя, возможно, он чем-то обоснован :) Типа мы ушли от генерации верстки на серваке, но блоки разметки все равно будем генерить там, вместо того, чтобы отдать это фронту)

SPA? Никогда не понимал такой подход, хотя, возможно, он чем-то обоснован :) Типа мы ушли от генерации верстки на серваке, но блоки разметки все равно будем генерить там, вместо того, чтобы отдать это фронту)

SPA это как минимум неклассический, про эту идею я впервые услышал сегодня

SPA это как минимум неклассический, про эту идею я впервые услышал сегодня

встречал такое частенько. типа пытаешься залогиниться на сайте, а он вместо того, чтобы в ответ послать json, шлет дивы с ошибками и кнопками)

встречал такое частенько. типа пытаешься залогиниться на сайте, а он вместо того, чтобы в ответ послать json, шлет дивы с ошибками и кнопками)

не, это не то

Очевидная проблема - придется всю логику перетащить на БЭ, вопрос в том, будет ли такая штука вообще работать?

Коллеги, какое у вас отношение к такой идее: БЭ рендерит layout, и покрывает своими спецификациями (фактически тестами), а ФЭ уже отображает этот layout на клиентах.

вообще ничего не понял

бэкэнд покрывает тестами шаблон?

вообще ничего не понял

посмотри картинку, вот так будут выглядеть тесты

бэкэнд покрывает тестами шаблон?

Да

зачем ?

SPA? Никогда не понимал такой подход, хотя, возможно, он чем-то обоснован :) Типа мы ушли от генерации верстки на серваке, но блоки разметки все равно будем генерить там, вместо того, чтобы отдать это фронту)

А что тут не понятного? Какая идея тебе претит?

зачем ?

Удобство тестирования - все тесты в одном месте

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

Прощай, высокоуровневые UI тесты

я вижу какой то BDD обернутый в гуи

но все равно не особо чтото понимаю

я вижу какой то BDD обернутый в гуи

Угу. BDD на БЭ тестирует всю логику - и БЭ и ФЭ

как можно тестировать логику фронтенда на бэкэнде ?

хотя стоп

откуда вообще во фронтенде логика?

как можно тестировать логику фронтенда на бэкэнде ?

Если на ФЭ остается только отображение, то можно

на фронте нужно верстку проверять и отображение данных корректное

А что тут не понятного? Какая идея тебе претит?

По мне так или используем шаблонизаторы и генерим бэком верстку или дергаем рест апи и получаем json, рисуя его фронтом под свои нужды. Но это оффтопик)

Почитайте внимательно для чего был придуман SPA и вопросы отпадут

Почитайте внимательно для чего был придуман SPA и вопросы отпадут

У меня отсутствуют вопросы, спрашивали отношение к такому подходу.

спрашивали про идеи тестирование темплейта html на беке, а не про SPA, так тестировать можно и static вебсайты, если че

поэтому про SPA - вы придумали себе сами ;)

поэтому про SPA - вы придумали себе сами ;)

возможно, наболело)

Привет, есть кто с JSON Schema шарит?