Еще я не понимаю, почему вы называете это атомарными тестами? Мне кажется к UI это мало применимо, потому что подготовка к проверке (пройтись по странице, ввести что-то и только потом проверить), влечет кучу одинаковых действий и то, что вы вынесли все повторения в функции, не сильно делает их атомарными. Возможно вы плохо раскрыли суть "атомарности", но профита и разницыы 2 и 3 варианта я особо не вижу
Locust сильно проще k6, но сценарии пишутся на чистом Python, что очень хорошо, когда вам надо нагрузить чуть сложнее, чем десяток GET запросов на сайте.
У locust неплохой real time интерфейс (ui), графики реалтаймные и т.п. По поводу миллиона запросов, он отлично скейлится по серверам, просто запускаете воркеры 1 командой и все. Я запускал его на 64 ядрах (8 серверов по 8 ядер)
Запихнуть в k6 дополнительные либы, то еще приключение
Каждый раз, открывая статью подобного вида, надеюсь увидеть что-то новое, но нет, все они заканчиваются двумя вариантами: мы стали запускать тесты параллельно; мы стали запускать тесты выборочно
После чтения кучи статей про стратегию тестирования, для себя я решил, что индустрия не имеет единого мнения, что это такое, для чего и как хоть примерно это должно выглядеть. Также, как и необходимость его. Потому что хорошо составленная стратегия тестирования, повторяет/заменяет описание всего процесса разработки
Абсолютно согласен, 6 лет использовали BDD, за это время ни один не qa не сделал ни одной правки туда, ни разу их не запустил. Зато кучу реализаций примерно одного функционала было.
скорее интересует в готовом устройстве по сравнению с чем-то прям качественным или промышленным
А что с показателем CO2? Насколько они верные? Сравнивали с чем-то промышленным, проверенным?
Судя по всему, вы переизобретаете BDD.
Еще я не понимаю, почему вы называете это атомарными тестами? Мне кажется к UI это мало применимо, потому что подготовка к проверке (пройтись по странице, ввести что-то и только потом проверить), влечет кучу одинаковых действий и то, что вы вынесли все повторения в функции, не сильно делает их атомарными. Возможно вы плохо раскрыли суть "атомарности", но профита и разницыы 2 и 3 варианта я особо не вижу
Нагрузочное тестирование бывает не только для http :)
Мне из практики надо было:
нагружать amqp
нагружать базы данных
библиотека криптографические, для тестирования блокчейнов
В locust для выведения отчетов можно передавать данные и руками, как хотите, у него для этого эвенты есть.
в k6 скрипт пишется почти на javascript, но нет уверенности что любая библиотека заведется (там свой движок js) + подключение ее не простое дело.
locust - обычная python библиотека, куда просто поставил любой пакет и используешь.
Шире не раскрою, с k6 мало опыта
Locust сильно проще k6, но сценарии пишутся на чистом Python, что очень хорошо, когда вам надо нагрузить чуть сложнее, чем десяток GET запросов на сайте.
У locust неплохой real time интерфейс (ui), графики реалтаймные и т.п. По поводу миллиона запросов, он отлично скейлится по серверам, просто запускаете воркеры 1 командой и все. Я запускал его на 64 ядрах (8 серверов по 8 ядер)
Запихнуть в k6 дополнительные либы, то еще приключение
А почему не забирать картинку просто через rtsp поток? на HiWatch он есть
Спасибо, отличная статья
а где скачать сие чудо? гуглится только странный домен https://www.portingkit.com/download который не выглядит эпловым
так Армения новая столица российских ИТ проектов, в РФ все умерло (по мнению многих)
а не думали переехать на playwright? в нем меньше проблем с совместимостью webdriver
Да я сам противник курсов (да и после 12 лет опыта, не нужны), но хотел итог какой-то :D
После длинного вступления, все ждал таблицу с результатами, какие же курсы лучшие.
Красиво рассказываете, но показали б вилки зарплат, потому что много отзывов, что платите вы очень мало (сильно ниже рынка).
Каждый раз, открывая статью подобного вида, надеюсь увидеть что-то новое, но нет, все они заканчиваются двумя вариантами: мы стали запускать тесты параллельно; мы стали запускать тесты выборочно
Очень не хватает информации, почему роскосмос не отдает спутники, что говорит?
Почему это названо "как профессионал"? Вы ничего нового или крутого не показали
Почему выбран Cypress? "Это делает его отличным инструментом для автоматизации API." - ПОЧЕМУ?
Зачем используется вообще Cypress, который все таки специализируется на UI тестировании?
А дайте ссылку на fullstack framework Pinecone? Гуглится только векторная база данных. А то первая два в списке - это скорее ui фреймворки
После чтения кучи статей про стратегию тестирования, для себя я решил, что индустрия не имеет единого мнения, что это такое, для чего и как хоть примерно это должно выглядеть. Также, как и необходимость его. Потому что хорошо составленная стратегия тестирования, повторяет/заменяет описание всего процесса разработки
Абсолютно согласен, 6 лет использовали BDD, за это время ни один не qa не сделал ни одной правки туда, ни разу их не запустил. Зато кучу реализаций примерно одного функционала было.