Сервис Sentry позволяет удаленно мониторить баги в фронтенд-приложениях, написанных на JavaScript.

Попытка устранить проблемы в фронтенд-приложениях на JavaScript может оказаться непростой задачкой, поскольку они возникают в браузере пользователя, к чему, зачастую, у вас нет доступа. Однако, Sentry дает возможность удаленно мониторить баги.

Как Web Scraping помог собрать нам данные по официальным коллекциям как у Белгазпромбанка.

Web Scraping — один из самых популярных методов считывания различных данных, расположенных на веб-страницах, для их систематизации и дальнейшего анализа. По сути, это можно назвать “парсингом сайтов”, где информация собирается и экспортируется более удобный для пользователя формат будь то таблица или API.

Есть задача нагрузочно потестировать фронтальные веб рест апи. Ресты защищены OAuth с Authorization Code Grant. Значит появляется необходимость наличия валидного токена для Authorization: Bearer TOKEN.
Вопрос — как его взять? И так это сделать красиво и правильно? Вот тут я не знаю.

В этой статье я описал то быстрое решение к которому я пришел и которое мне не вполне нравится. Выглядит костыльным, хотя я и не нагуглил ничего серебряного. Поэтому, если вы знаете лучшее решение — обязательно скажите об этом в комментарии… Итак…

Есть обычная типовая система с веб рест фронтом и типовым Single-Page-Application браузерным клиентом на JS. Аутентификация и авторизация — KeyCloak с Authorization Code Grant + brokering.

Надо обеспечить регулярное нагрузочное тестирование фронтовых рест сервисов.

Приглашаем на онлайн-митап DINS QA EVENING, он состоится 9 июля в 19:00.

Этим вечером Дмитрий Красильников из DINS расскажет, почему именно тестировщик должен построить CI/CD, и объяснит, как это сделать. Дмитрий Борисов из Nexign поговорит об эволюции инструментов и подходов обеспечения качества на большом проекте.

Для участия, пожалуйста, зарегистрируйтесь.

Подробная программа и информация о спикерах — под катом.

Кейси Розенталь (Casey Rosenthal), CEO и сооснователь Verica.io, выступил на митапе Test in Production. Кейси развенчал некоторые мифы о надёжности и объяснил, что многие интуитивные действия по увеличению надёжности систем на самом деле контрпродуктивны. Более того, он объяснил, как концепция непрерывной проверки (Continuous Verification) помогает разработчикам избегать таких подводных камней.

Полное выступление Кейси:

Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.

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

Было ли у вас ощущение, что ради тестирования вы делаете код труднее для чтения? Допустим, у вас есть код, который ещё не тестировался. У него есть ряд побочных эффектов, и вас просят сначала прогнать тесты. Вы начинаете следовать советам вроде передачи глобальных переменных в виде параметров или извлечения проблемных побочных эффектов, чтобы сделать вместо них заглушки в тестах.

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

Вы останавливаетесь и задумываетесь: «Допустимо ли менять сигнатуры кода ради тестирования? Тестирую ли я реальный код или совершенно другой класс, в котором не происходит то, что нужно?» Перед вами может возникнуть дилемма. Вы уверены, что стоит и дальше придерживаться этого подхода? Или это потеря времени?

Вопрос на миллион: для устаревшего кода нужно писать модульные тесты или интеграционные?

CI (Continuous Integration) — в дословном переводе «непрерывная интеграция». Имеется в виду интеграция отдельных кусочков кода приложения между собой. Чем чаще мы собираем код воедино и проверяем:

• Собирается ли он?
• Проходят ли автотесты?

Тем лучше! CI позволяет делать такие проверки автоматически. Он используется в продвинутых командах разработки, которые пишут не только код, но и автотесты. Его спрашивают на собеседованиях — хотя бы понимание того, что это такое. Да, даже у тестировщиков.

Поэтому я расскажу в статье о том, что это такое. Как CI устроен и чем он пригодится вашему проекту. Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

В четверг 2 июля собираемся обсудить очередной опыт распила монолита и рассказать, как Unit-тестирование сокращает время разработки. Старт в 16:00 мск, в 17:00 по Ижевску.

Участие бесплатно, нужна регистрация.

«Упрощаем себе жизнь с помощью Unit-тестирования»

Юнит-тесты повышают скорость разработки согласны?

• расскажу, почему нетестируемые проекты увеличивают сроки релизов;
• приведу аргументы в пользу написания юнит-тестов. Рассмотрим, почему хороший дизайн тестируемый, а обратное — неверно;
• плохие юнит-тесты хуже, чем ничего. Поговорим про требования к юнит-тестам. Например, почему важна изолированность или скорость выполнения тестов;
• расскажу про лучшие практики юнит-тестирования с примерами на NUnit.

Салют, хабровчане. Сегодня мы продолжаем серию переводов, приуроченных к запуску курса «Java QA Engineer».

---

Эпизод 3 — isDisplayed

В результате диалога, произошедшего в последние выходные января 2020 года, который был посвящен одной из проблем в Selenium, где кто-то сказал мне «почему ты просто не сделаешь так…» в ответ на объяснение проблемы, я решил написать серию статей, объясняющих команды в Selenium WebDriver и почему мы в итоге пришли к дизайну, который имеем сегодня.

Я буду повторять это в каждом эпизоде этой серии — много, иногда до безумия много размышлений и продумывания было вложено в работу каждой мельчайшей детали Selenium.

В этом эпизоде ​​мы рассмотрим значительную часть механизмов, заложенных в isDisplayed(). Эти же механизмы используются в командах взаимодействия, поэтому будет полезно понять, как они работают, и как другие команды могут их использовать. С технической точки зрения это моя любимая команда (из-за того как она работает).

JDI — это семейство фреймворков для автоматизации тестирования. На данный момент состоит из JDI Light для UI автоматизации, JDI Dark для бэкэнд автоматизации и JDI Mobile. Название расшифровывается как Just do it: главная идея JDI — в том, чтобы с помощью него было легко тестировать и поддерживать тесты, а все удачные рабочие находки – сохранять и аккумулировать.

Selenium Grid — это кластер, состоящий из нескольких Selenium-серверов. Он предназначен для организации распределённой сети, позволяющей параллельно запускать много браузеров на большом количестве машин. Имеется выделенный сервер, который носит название «хаб» или «коммутатор», а остальные сервера называются «ноды» или «узлы».

Sentry — трекинг java exception в Java

Стандартно Java разработчики мониторят ошибки, exception через логи. Но есть и другой способ, а именно отправка exception в Sentry.

Sentry — инструмент мониторинга исключений (exception), ошибок в ваших приложениях.

Преимущества использования Sentry:

• не нервничать при размещении приложений на боевом сервере,
• быстро находить причины возникших проблем,
• устранять баги раньше, чем о них вам сообщат тестировщики, коллеги из саппорта, пользователи, ПМ или директор,
• выявлять незаметные остальной команде проблемы, которые портят жизнь пользователям и снижают эффективность вашего продукта,
• бесплатен,
• легко интегрируется в проект,
• ловит ошибки и в браузере пользователя, и на вашем сервере.
• Если в ELK один и тот же exception происходит несколько раз, то они идут как отдельные записи, занимают место на диске и в ОЗУ. Если в Sentry один и тот же exception происходит несколько раз, то поле EVENTS увеличивается, тем самым экономя место на диске и в ОЗУ.
  
  Пример
  
  

Юнит тесты — обязательная часть моих проектов. Это база, к которой добавляются другие виды тестов. В статье Тестирование и экономика проекта я рассказал почему тестирование выгодно для экономики проекта и показал, что юнит тестирование лидирует с экономической точки зрения. В комментариях было высказано мнение, что тестирование требует больших усилий, и даже юнит тестирование неприемлемо из-за этого. Одной из причин этого является неопытность команды в тестировании. Чтобы написать первую тысячу тестов команда тратит много времени, пробуя и анализируя различные подходы.

В этой статье я расскажу о лучших практиках, к которым я пришел за более чем 10 лет тестирования различных проектов. Эти практики позволят начать юнит тестирование без заметного снижения производительности программистов.

И снова здравствуйте. В июле Otus запускает новый курс «Нагрузочное тестирование». В преддверии старта курса традиционно делимся с вами полезным материалом.

---

Поскольку 5 миллиардов человек во всем мире самоизолируются, все больше и больше наших ежедневных взаимодействий происходят через интернет. Ритейлеры по всему миру переводят обслуживание своих клиентов из офисов в онлайн, школы и учебные заведения пытаются находить альтернативы в интернете, и даже общение в кругу семьи переносится на Zoom и Webex вместе с нашими рабочими встречами (с детьми и домашними животными на фоне).

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

Для тех из вас, кто ищет ответы на вопросы о том, как тестировать производительность вашего сайта, чтобы правильно подготовиться к предстоящим неделям, вот 8 советов, которые мы вынесли из работы с нашими клиентами по нагрузочному тестированию за последние 10 лет.

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

Сейчас в Тинькофф мы активно занимаемся развитием тестирования производительности наших сервисов, в том числе развиваем инструменты для тестирования. В качестве основного инструмента для генерации нагрузки используем Gatling. Вот его основные преимущества:

• Плагин Gatling SBT позволяет очень просто запускать тесты из CI-систем.
• Gatling хорошо подходит для командной работы над проектами. Cкрипты представляют собой человекочитаемый код на Gatling DSL, его удобно хранить в git и версионировать.
• В дополнение к стандартному функционалу Gatling существует возможность использовать любой Scala/Java-код внутри проекта, а также подключать зависимости от любых доступных библиотек Scala/Java, что позволяет создавать тесты для специфичных протоколов и выполнять дополнительные действия по подготовке тестовых данных или расширенному анализу результатов.

В этой статье расскажу о двух проектах, которые позволяют нам переиспользовать часто применяемые типовые решения и ускорить разработку проектов Gatling.

Какие проблемы решаем

«Я делаю то, за что мне платят» — стандартный капиталистический подход к работе «на дядю» в Западной части нашего мира. В момент свет гаснет, станки останавливаются и все расходятся по своим делам. Интересно, что методологи в стиле Скрам и Канбан, которые говорят о командной работе, также жестко проводят черту между ролями и тем, кто, что и когда делает. Но это там! А у нас? А у нас роль в команде (буду говорить о тестировщиках (QA)) коррелирует со знаниями из разных сфер, важностью морального и душевного равновесия в коллективе и ответственностью за проделанную работу. Все это адаптирует методологии в командах немного под другим углом, отличным от запада.

Привет, Хаброжители! Хотите повысить свою эффективность в разработке корпоративных и облачных Java-приложений?

Увеличьте скорость и простоту разработки микросервисов и сложных приложений, избавившись от забот по конфигурации Spring.

Используйте Spring Boot 2 и такие инструменты фреймворка Spring 5, как WebFlux, Security, Actuator, а также фреймворк Micrometer, предоставляющий новый способ сбора метрик.

Этой статьей мы завершим небольшой цикл о построении процесса безопасной разработки на основе SAST — статического анализа кода на безопасность. В первой части мы разобрали основные вопросы, возникающие при внедрении SAST в процесс разработки. Во второй части остановились на технических аспектах внедрения и разобрали несколько примеров выстраивания SSDLC на практике. В последней части расскажем об организационных моментах.

Для большинства компаний использование SAST — это новый процесс, а уязвимость — новая сущность. Уязвимость — это не баг и не функциональное требование, и нужно выстраивать процесс работы с новой сущностью. Нельзя забывать про историческое разделение безопасности и разработки, которое особенно обостряется, когда в процесс разработки нужно внедрять что-то новое. Масла в огонь подливают и технические особенности статического анализа, о которых мы говорили во второй части.

Вводная

Ранее на Хабре очень подробно освещалась тема Автоматизации десктопных GUI приложений на Python. В то время меня очень сильно привлекла эта статья, потому что в ней раскрываются элементы, схожие с элементами создания роботов. А так как по роду своей профессиональной деятельности я занимаюсь роботизацией бизнес-процессов компании (RPA — область, в которой не было полнофункциональных OpenSource аналогов до недавнего времени), данная тема была очень актуальна для меня.

Всем привет! Меня зовут Паша Лесюк, я работаю мобильным тестировщиком в компании Циан. В этой статье я расскажу о возможностях управления яблочными симуляторами из командной строки.