web-testing_ci-cd-cd-homework.pdf
176.7 KB
web-testing_ci-cd-cd-homework.pdf
web-testing_web-testing-test-api-homework.pdf
193 KB
web-testing_web-testing-test-api-homework.pdf
web-testing_web-app-architecture-homework.pdf
174.5 KB
web-testing_web-app-architecture-homework.pdf
web-testing_perfomance-testing-homework.pdf
227 KB
web-testing_perfomance-testing-homework.pdf
web-testing_estimation-testmetrics-homework.pdf
200.4 KB
web-testing_estimation-testmetrics-homework.pdf
📚 ProTestingInfo 🔷 Канал по тестированию 📚
#курсы
Материалы из бесплатного доступа, для ознакомления. С интересом слушала данный курс
Forwarded from Stanislav Vasenkov
Подборка сообществ в помощь QA automation инженеру
Java:
- @selenide_ru - для автоматизации UI (web, mobile)
- @rest_assured - для rest api
- @junit_ru (junit5) - библиотека менеджмента тестов
- @gradle - лучше чем maven :)
Python:
- @testing_in_python
- @selene_py_ru - порт selenide для python
- @pytest
- @robotframework_ru
Javanoscript:
- @js_for_testing
- @playwright
- @selenidejs, @selenidejs_ru - порт selenide для js
- @cypress_ru1
- @nightwatchjs
Мобильное тестирование:
- @qa_mobile_automation - мобильная автоматизация
- @appium_ru - мобильное тестирование с appium
- @MobileNinjas
- @kaspresso, @kaspresso_en
- @XCTest
Нагрузочное тестирование:
- @qa_load
- @loadland
Контейнеризация:
- @aerokube selenoid
- @aerokube_moon selenoid k8s
Отчеты и тест-менеджмент:
- @allure_ru
Визуальное тестирование:
- @visual_tracker
Прочее:
- @postman_by
- @jenkins_ru
- @devops_ru
- @xpath_help
- @bdd_ru
- @qa_hardware
- @testspro1c - тестирование 1с
Java:
- @selenide_ru - для автоматизации UI (web, mobile)
- @rest_assured - для rest api
- @junit_ru (junit5) - библиотека менеджмента тестов
- @gradle - лучше чем maven :)
Python:
- @testing_in_python
- @selene_py_ru - порт selenide для python
- @pytest
- @robotframework_ru
Javanoscript:
- @js_for_testing
- @playwright
- @selenidejs, @selenidejs_ru - порт selenide для js
- @cypress_ru1
- @nightwatchjs
Мобильное тестирование:
- @qa_mobile_automation - мобильная автоматизация
- @appium_ru - мобильное тестирование с appium
- @MobileNinjas
- @kaspresso, @kaspresso_en
- @XCTest
Нагрузочное тестирование:
- @qa_load
- @loadland
Контейнеризация:
- @aerokube selenoid
- @aerokube_moon selenoid k8s
Отчеты и тест-менеджмент:
- @allure_ru
Визуальное тестирование:
- @visual_tracker
Прочее:
- @postman_by
- @jenkins_ru
- @devops_ru
- @xpath_help
- @bdd_ru
- @qa_hardware
- @testspro1c - тестирование 1с
#полезныйматериал
#полезныессылки пришлю позже , как доберусь до компьютера, хочу удобно и красиво оформить
#полезныессылки пришлю позже , как доберусь до компьютера, хочу удобно и красиво оформить
Вопрос из Инстаграма:
❓❓Как провести нагрузочное тестирование, если имеем нагрузки только на проде?
Здесь очень много нюансов
Но здесь сможем дать следующий ответ:
Сделать запрос на создание отдельного окружения для нагрузочного тестирования, которое полностью бы повторяло продакшн окружение.
Ну это в идеале. Но так мало кто делает. Потому что иметь и обслуживать два продакшн окружения (одно из которых будет только для нагрузочного тестирования) обычно очень дорого.
Тогда что делать, если дорого?
Идти на разные хитрости.
Тестировать на том, что есть. Хотя бы приблизительно копировать архитектуру и конфигурацию продакшена. Исследовать влияние разной нагрузки на тестируемые запросы, чтобы понять их масштабируемость. Принимать риски того, что результаты скорее всего будут заметно отличаться от тех, что могли бы быть на проде. Самые отчаянные могут проводить тесты прямо на проде, но опять же есть риск все поломать, и тестируемое приложение может выйти из строя на неопределенное время, из-за чего пользователи будут очень недовольны. Последнее - это какая-то крайняя и отчаянная мера, но тоже возможно, если есть уверенность, что тесты безопасны.
Очень грубый пример. Сделаем окружение в 8 раз меньше, чем на проде. Если наше маленькое окружение потянет определенную нагрузку, то значит прод сможет выдержать в 8 раз больше, потому что он сам у нас в 8 раз мощнее. Но потребление ресурсов не всегда линейно, поэтому это и надо поисследовать, подавая разный уровень нагрузки для тестируемых запросов на тестовом окружении, чтобы оценить их масштабируемость производительности. Но на окружениях еще много чего может отличаться: настройки кэша, скорость и объем дисков, пропускная способность сети, где вообще территориально находится прод и тестовое окружение, и откуда подается нагрузка... Все это вносит погрешности в результаты, и это придется учитывать.
#ответынавопросы
❓❓Как провести нагрузочное тестирование, если имеем нагрузки только на проде?
Здесь очень много нюансов
Но здесь сможем дать следующий ответ:
Сделать запрос на создание отдельного окружения для нагрузочного тестирования, которое полностью бы повторяло продакшн окружение.
Ну это в идеале. Но так мало кто делает. Потому что иметь и обслуживать два продакшн окружения (одно из которых будет только для нагрузочного тестирования) обычно очень дорого.
Тогда что делать, если дорого?
Идти на разные хитрости.
Тестировать на том, что есть. Хотя бы приблизительно копировать архитектуру и конфигурацию продакшена. Исследовать влияние разной нагрузки на тестируемые запросы, чтобы понять их масштабируемость. Принимать риски того, что результаты скорее всего будут заметно отличаться от тех, что могли бы быть на проде. Самые отчаянные могут проводить тесты прямо на проде, но опять же есть риск все поломать, и тестируемое приложение может выйти из строя на неопределенное время, из-за чего пользователи будут очень недовольны. Последнее - это какая-то крайняя и отчаянная мера, но тоже возможно, если есть уверенность, что тесты безопасны.
Очень грубый пример. Сделаем окружение в 8 раз меньше, чем на проде. Если наше маленькое окружение потянет определенную нагрузку, то значит прод сможет выдержать в 8 раз больше, потому что он сам у нас в 8 раз мощнее. Но потребление ресурсов не всегда линейно, поэтому это и надо поисследовать, подавая разный уровень нагрузки для тестируемых запросов на тестовом окружении, чтобы оценить их масштабируемость производительности. Но на окружениях еще много чего может отличаться: настройки кэша, скорость и объем дисков, пропускная способность сети, где вообще территориально находится прод и тестовое окружение, и откуда подается нагрузка... Все это вносит погрешности в результаты, и это придется учитывать.
#ответынавопросы