Тестирование веб-сервисов *

Electron — фреймворк с открытым исходном кодом для создания кросс-платформенных десктопных приложений с помощью JavaScript, HTML и CSS. Это крутая технология, но с ней связаны многие ИБ-риски.

В статье я разберу основы безопасной работы с этим фреймворком и расскажу:

• как анализировать структуру десктоп-приложений на Electron и находить в них уязвимости;
• какие распространенные ошибки допускают при работе с фреймворком и насколько он защищен.

Начнем с инструментов и методов, с помощью которых я провожу анализ кода приложений. Затем продемонстрирую конкретные примеры эксплуатации уязвимостей на примере специальных приложений-мишеней: DVEA, Electro-xxs и Notable.

Всем привет! Сегодня расскажу о том, как удобно организовать Page Object для большого проекта с использованием Playwright и библиотеки Dorama. Большинство современных веб-проектов имеют сложный интерфейс с переиспользуемыми компонентами. Причем компоненты могут переиспользоваться как на разных страницах, так и в рамках одной страницы. Поэтому важно грамотно оформить POM с самого начала, чтобы можно было добраться до любого локатора любого компонента на странице. Это упростит написание тестов и улучшит читаемость кода. При формировании страниц и компонентов мы будем использовать как наследование, так и композицию. Перейдем к делу.

Создание и настройка необходимых компонентов без дублирования кода

Отправка HTTP-запросов в тестируемую систему без дублирования кода

Настройка Spring MVC Test framework, при написании модульных тестов для Spring MVC REST API с помощью JUnit 5.

Когда мы используем автотесты, то оптимизируем процесс выявления багов за счет сокращения ручного труда. И если основная потребность бизнеса в контексте тестирования — экономить деньги, минимизируя ущерб от каждого бага, то задача автотестирования: выявить наиболее полную картину багов с минимальными затратами на разработку автотестов и их поддержание. Соответственно, чтобы выполнить эту задачу, необходимо обеспечить прозрачный механизм написания тестов и их покрытия.

Под катом мы подготовили практический шаблон, который поможет вам в этом.

Когда мы используем автотесты, то оптимизируем процесс выявления багов за счет сокращения ручного труда. И если основная потребность бизнеса в контексте тестирования — экономить деньги, минимизируя ущерб от каждого бага, то задача автотестирования: выявить наиболее полную картину багов с минимальными затратами на разработку автотестов и их поддержание. Соответственно, чтобы выполнить эту задачу, необходимо обеспечить прозрачный механизм написания тестов и их покрытия.

Под катом мы подготовили практический шаблон, который поможет вам в этом.

Понятие Quality Gate (дословно ворота качества), предполагает автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки CI/CD.

Использование принципа Quality Gates помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Так, в частности выявив ошибки в коде на начальных этапах разработки мы потратим меньше времени на тестирование исправленного варианта кода, что в конечном итоге позволит снизить общие расходы на разработку.

Quality Gate также можно назвать контрольными точками качества, и именно это понятие мы и будем дальше использовать.

Итак, контрольные точки качества - это промежуточные этапы цикла реализации проекта. И хотя, контрольные точки качества необходимы для создания высококачественного программного обеспечения, многие специалисты не совсем правильно понимают принципы работы данного механизма проверки кода.  Давайте попробуем разобраться, что из себя представляют контрольные точки качества и чем они могут помочь QA при тестировании качества кода.

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

Понятие Quality Gate (дословно ворота качества), предполагает автоматические проверки качества, которые устанавливают пороговые значения для продвижения продукта по конвейеру разработки CI/CD.

Использование принципа Quality Gates помогает решать проблемы в коде на ранних этапах, до того, как он обрастёт зависимостями. Так, в частности выявив ошибки в коде на начальных этапах разработки мы потратим меньше времени на тестирование исправленного варианта кода, что в конечном итоге позволит снизить общие расходы на разработку.

Quality Gate также можно назвать контрольными точками качества, и именно это понятие мы и будем дальше использовать.

Итак, контрольные точки качества - это промежуточные этапы цикла реализации проекта. И хотя, контрольные точки качества необходимы для создания высококачественного программного обеспечения, многие специалисты не совсем правильно понимают принципы работы данного механизма проверки кода.  Давайте попробуем разобраться, что из себя представляют контрольные точки качества и чем они могут помочь QA при тестировании качества кода.

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

В этой статье мы рассмотрим лучшие практики модульного тестирования. Сначала я объясню, что такое модульное тестирование и почему мы должны использовать его в наших проектах. Затем мы рассмотрим лучшие практики модульного тестирования. Я приведу пример кода с использованием фреймворка xUnit для написания модульных тестов в проектах на .Net.

Безопасность играет важную роль в программном обеспечении. В конечном итоге каждому необходимо повысить безопасность своего проекта. В этой статье мы рассмотрим, как протестировать аутентификацию и авторизацию приложений Spring Boot. Мы рассмотрим как приложения-сервлеты MVC, так и реактивные приложения WebFlux.

Spring Security хорошо интегрируется с фреймворками Spring Web MVC и Spring WebFlux. Он также имеет комплексную интеграцию с Spring MVC Test и Spring WebTestClient.

В данной статье мы рассмотрим следующие темы вопросов по Appium на собеседовании:

• Основы Appium

• Концепции автоматизации Appium

• Продвинутые возможности Appium

• Устранение неполадок и лучшие практики

Многие сервисы в различных отраслях генерируют печатные формы счетов, отчётов и прочего в формате PDF. И, конечно, перед специалистами тестирования встаёт вопрос о проверке этих документов.

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

В этой статье мы познакомим вас с инструментом, который достаточно просто может закрыть потребность в проверке содержания PDF-файлов. Это инструмент с открытым исходным кодом — pdf-test. Он по сути является обёрткой pdfbox и позволяет из коробки использовать основные мэтчеры, не задумываясь о том, чтобы писать свои или о том, как именно парсить документ. Рассмотрим далее его применение на языке Java.

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

Вместо эталонных скриншотов мы будем использовать эталонное окружение. Это означает, что в качестве референса будем использовать полноценно поднятый проект с продакшн кодом (тот, который находится в гите в master/main). Конечно, здесь должен быть хорошо настроенный CI, который будет давать возможность тестам обращаться к тестируемому экземпляру приложения и к референсу. Не будем углубляться в детали, это тема для отдельного разговора. Расскажу только кратко, как это может выглядеть.

Можно ли сегодня сказать что-то новое про браузерное тестирование в Ruby и Rails, когда придумано, казалось бы, всё, что можно: и Selenium, и Capybara, и SitePrism?

А вот и можно.

С развитием веба сайты превратились в сложные приложения, которыми ежедневно пользуются десятки и сотни миллионов людей: почта, облачные хранилища, соцсети, маркетплейсы, стриминговые платформы и т. д. И каждое из них должно работать корректно. Как это сделать? Конечно писать хороший код, а потом и тестировать его. Хотя кто‑то обходится без тестов, тем не менее тестирование — важная часть инженерных практик наравне с мониторингом. Оно помогает нам заблаговременно находить и исправлять баги (или незапланированные фичи) в приложениях. Основная цель тестирования — получить гарантию корректной работы любого ПО .

При этом тестировать современный фронтенд сложно: неуправляемая асинхронность (событийная модель браузера), различие браузеров, тяжелое окружение — это лишь малая часть сложностей. Можно ли все возложить на ручных тестировщиков или исправлять баги после жалоб пользователей? Однозначно нет. В большинстве случаев такой подход в скором времени приведет к оттоку пользователей: не все пишут о багах, просто уходят к конкурентам. Безусловно, ручное тестирование остается важным элементом разработки, но тестировщики не могут держать сотни или тысячи сценариев, которые нужно пройти перед релизом или запуском новой фичи. Так где нам получить гарантии, что ключевые сценарии приложения работают корректно? Автоматическое тестирование.

Всем привет! Меня зовут Миша, работаю фронтэнд‑разработчиком в VK в команде Облака Mail.ru, и я хочу разобрать различные виды тестов, дать их сравнительный анализ и применимость. Сразу скажу, тут не будет практики написания тестов. Потому что это нереально сделать внутри одной статьи, необходимо разобрать: теорию тестирования, классов эквивалентности, различие подходов/методов к тестированию, комбинаторику состояний, правильное использование моков и стабов, понимание чистых функций, знание архитектуры приложения. Поэтому предлагаю сконцентрироваться на видах тестирования и начать с «идеального теста».

Упростите свою работу с Госуслугами, используя PyCades! В этой статье мы предложим простые шаги для автоматизации работы с заявлениями через API Госуслуг, устраним рутину с формами и сделаем проще взаимодействие с информационными системами. 🛠️🤖

Сегодня мы поделимся навыком тестирования сайтов и веб-приложений с помощью Cypress. Автоматизируем поиск книг по тестированию и добавим их в избранное на сайте Литрес!

Что нам необходимо для установки и запуска автотестов:

1. Браузер Chrome актуальной версии;
2. Редактор кода VS Code;
3. Терминал или Командная строка (PowerShell) по умолчанию есть на macOS и Windows;
4. Доступ к терминалу есть также внутри программы VS Code;
5. Node.js и Cypress мы установим через Терминал (Командную строку).

На компьютер необходимо установить 3 программы (Chrome, VS Code и Node.js)
Остальные установки будут происходить внутри Терминала на вашем компьютере.

Одним из важнейших аспектов тестирования наряду с поиском ошибок в приложении является время, необходимое для его проведения. Если тестирование приложения занимает от нескольких минут до нескольких часов, то оно не подходит для разработки с использованием быстрого цикла обратной связи (fast feedback loop), и разработчики могут проводить его не так часто, как следовало бы.

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

С точки зрения того, что именно представляет собой CI/CD: непрерывная интеграция программного обеспечения — это процесс, целью которого является максимально проверенный дистрибутив.

Хотя характеристику «максимально проверенный» можно интерпретировать по-разному, я полагаю, что это сводится к использованию такого количества тестов, которое позволяет бюджет, а бюджет — это деньги и время.

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

Уже немало копий поломали в поиске грааля идеального способа интеграционного тестирования с использованием БД.

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

Всем привет! Меня зовут Виктория Исаева, я старший специалист по тестированию ГК Юзтех. В этой статье я хочу поделиться нашим опытом внедрения фреймворка Karate для автоматизации ручного тестирования на проекте.