Инфраструктура тестирования обсуждается реже чем проблемы программирования или шестизначные зарплаты. Дьявол кроется в деталях, а если точнее, то дьявол сидит в процессах внутри команды. В небольших командах процессы устраиваются сами собой без обсуждения. Продуктивность команды снижается по мере роста команды и в условиях игнорирования процессов. Статью будет полезно прочитать, если команда испытывает следующие трудности:
тестирование становится бутылочным горлышком и замедляет работу;
Подскажите, какие можно использовать инструменты для реализации следующей цели:
есть веб-продукт, назовём его условно, интернет-магазин техники. Задача: выполнить нижеописанный алгоритм, одновременно, допустим, с сотни или тысяч авторизованных пользователей:
1. Войти на сайт.
2. Положить конкретную колонку марки и модели Samsung 000 в корзину.
3. Перейти в корзину.
4. Изменить количество на 3.
5. Изменить количество на 5
5. Нажать кнопку оплатить.
6. Ввести данные карты (0000 1111 2222 3333 4444)
7. Подтвердить покупку кнопкой "подтвердить".
8. Перейти в корзину.
Вижу что она пустая, т.к. заказ уже оформлен.
Предположим, что процесс занимает 100 шагов, и пока он выполняется каким-то инструментом (например, Jmeter/Selenium) от лица тысяч пользователей, я захожу вручную на тот же сайт, и делаю похожий процесс.
Цель: убедиться, что при использовании одних и тех же действий от лица сотен/тысяч (авторизованных с разных аккаунтов) пользователей ничего не ломается и весь процесс идёт без проблем, и никто никому не мешает своими параллельными действиями.
Подскажите, какие можно использовать инструменты, что почитать, как это использовать. Ранее неоднократно стояла подобная задача, но не знаю в какую сторону гуглить.
Selenium IDE (KatalonRecorder) эти инструменты не могут имитировать работу сотен пользователей. Только от имени одного (насколько я знаю). Вот если бы что-то подобное, только от лица большого числа пользователей было бы, это супер.
Если вы хотите понять,чем живетиндустрия тестирования, посетите конференциюHeisenbug 2022 Spring.Она пройдет с 30 мая по 1 июня.
Программа еще формируется, но в ней уже есть:
«Собственный нагрузчик для MongoDB. Ошибки, успехи, опыт». Доклад про нетривиальные проблемы нагрузочного тестирования и работу с replay-логами.
«Воркшоп: CI/СD глазами тестировщика». Воркшоп, на котором вы узнаете,почему CI/CD — это не только автоматический запуск тестов, какие метрики нужно включить в пайплайн и как контролировать качество с помощью Quality Gates.
«Уберите из своего резюме "разработка QA-фреймворка"». Выясним, почему «идеальный» фреймворк должен иметь около 4 публичных классов и почему иногда разработка собственного фреймворка скорее вредит.
Кроме того, 21 июня в Петербурге пройдет offline-день конференции. А этоэто дополнительная порция Q&A-сессий соспикерамии экспертами, тематических дискуссий и, конечно,докладов.
Для тех, ктопокупаетбилет за свой счет, действует скидка по промокоду: softwaretesting2022JRGpc. Она распространяется на online, online+offline и абонемент Full Pass, который открывает доступ ко всем конференциям JUG Ru Group весны и лета 2022. Помимо Heisenbug, этоDotNext, HolyJS, JPoint, Mobius, Hydra, C++ Russia.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
В этом месяце я решила сделать что-то новенькое! Обычно мои статьи нацелены на тестировщиков, которые хотят прокачать свои навыки и лучше размышлять о том, что тестировать. Но в этот раз я хочу обратиться к тем, кто нанимает тестировщиков.
Принятие правильных решений о найме – это очень важно. Оказаться с неэффективным тестировщиком на руках зачастую хуже, чем вообще без него, по следующим причинам:
Он, возможно, не сможет автоматизировать тесты вообще – все тестирование будет вручную, и это сильно замедлит релиз.
Он будет плохо автоматизировать тесты, и вы получите нестабильные тесты, которым нельзя доверять, нуждающиеся в постоянной поддержке.
Он будет плохо понимать технические концепции – другим членам команды придется тратить время, чтобы снова и снова объяснять их коллеге.
Он не сумеет создать тест-стратегию – в итоге тестироваться будет не то, что нужно, а то, что нужно, не будет проверяться вообще.
