У нас в команде результаты тестов производительности сохраняются в Allure. В yaml-файле заданы лимиты. И после теста отельная утилита проверяет соответствие результатов теста лимитам из yaml-файла. Статусы сохраняется в Allure TestOps, как тесты
Такие тесты (yaml-файл с лимитами) заданы в декларативном виде
Сегодня обсуждали фичу, что надо заводить баги по части таких тестов и делать тестам Mute, пока баг не исправлен. Звучало так, что нужно усложнить интеграцию
Сделал такое с JUnit5 и Allure библиотеками. Как эксперимент. В этом случае тест производительности уже задан не в декларативном виде, а кодом. В нем есть механизм Mute, ссылки на Issue. Коллеги имеют опыт работы с такими тестами. Их понятно как отлаживать и писать. Мне кажется, что сложнее не стало
В таким подходе тест на k6 не является тестом — это пререквизит, в ходе которого формируется файл с метриками. А потом уже тест-тест загружает этот файл и применяет Assertion-ы к значениям метрик
Использовал: k6, gson, assertj, junit5, Allure TestOps
Такие тесты (yaml-файл с лимитами) заданы в декларативном виде
Сегодня обсуждали фичу, что надо заводить баги по части таких тестов и делать тестам Mute, пока баг не исправлен. Звучало так, что нужно усложнить интеграцию
Сделал такое с JUnit5 и Allure библиотеками. Как эксперимент. В этом случае тест производительности уже задан не в декларативном виде, а кодом. В нем есть механизм Mute, ссылки на Issue. Коллеги имеют опыт работы с такими тестами. Их понятно как отлаживать и писать. Мне кажется, что сложнее не стало
В таким подходе тест на k6 не является тестом — это пререквизит, в ходе которого формируется файл с метриками. А потом уже тест-тест загружает этот файл и применяет Assertion-ы к значениям метрик
Использовал: k6, gson, assertj, junit5, Allure TestOps
tgoop.com/qaload/97
Create:
Last Update:
Last Update:
У нас в команде результаты тестов производительности сохраняются в Allure. В yaml-файле заданы лимиты. И после теста отельная утилита проверяет соответствие результатов теста лимитам из yaml-файла. Статусы сохраняется в Allure TestOps, как тесты
Такие тесты (yaml-файл с лимитами) заданы в декларативном виде
Сегодня обсуждали фичу, что надо заводить баги по части таких тестов и делать тестам Mute, пока баг не исправлен. Звучало так, что нужно усложнить интеграцию
Сделал такое с JUnit5 и Allure библиотеками. Как эксперимент. В этом случае тест производительности уже задан не в декларативном виде, а кодом. В нем есть механизм Mute, ссылки на Issue. Коллеги имеют опыт работы с такими тестами. Их понятно как отлаживать и писать. Мне кажется, что сложнее не стало
В таким подходе тест на k6 не является тестом — это пререквизит, в ходе которого формируется файл с метриками. А потом уже тест-тест загружает этот файл и применяет Assertion-ы к значениям метрик
Использовал: k6, gson, assertj, junit5, Allure TestOps
Такие тесты (yaml-файл с лимитами) заданы в декларативном виде
Сегодня обсуждали фичу, что надо заводить баги по части таких тестов и делать тестам Mute, пока баг не исправлен. Звучало так, что нужно усложнить интеграцию
Сделал такое с JUnit5 и Allure библиотеками. Как эксперимент. В этом случае тест производительности уже задан не в декларативном виде, а кодом. В нем есть механизм Mute, ссылки на Issue. Коллеги имеют опыт работы с такими тестами. Их понятно как отлаживать и писать. Мне кажется, что сложнее не стало
В таким подходе тест на k6 не является тестом — это пререквизит, в ходе которого формируется файл с метриками. А потом уже тест-тест загружает этот файл и применяет Assertion-ы к значениям метрик
Использовал: k6, gson, assertj, junit5, Allure TestOps
BY 📢 Load & Performance
Share with your friend now:
tgoop.com/qaload/97