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

Тестирование — штука очень разнообразная. Пока кто-то пишет юнит-тесты для мобильного приложения, другой в это время занимается нагрузками в бэкенде, а третий — вообще безопасностью… О чём тогда должны быть доклады на конференции по тестированию?

Обо всём этом, поэтому программа Heisenbug тоже очень разнообразная. В октябре на конференции поговорят и о сокращении времени UI-тестов на iOS, и о применении AI в автоматизации тестирования. Сейчас программа уже известна, поэтому публикуем все описания докладов на Хабре единым постом.

Если вы ищете более эффективный способ выполнения и отладки e2e-тестов, обратите внимание на Playwright с функцией UI Mode. В этом гайде мы рассмотрим возможности режима UI Mode в Playwright и покажем, как использовать их при автоматизации тестирования.

В этой статье мы покажем:

• как в разных ситуациях манипулировать веб-сайтом таким образом, чтобы он передавал пользователям вредоносный JavaScript.
• как скомпрометировать администратора сайта, отправив ему личное сообщение;
• как атаковать разом всех пользователей при помощи комментария под статьей;
• как заставить пользователя отправить запрос на действия, которые он не собирается выполнять;
• как прослушивать WebSocket-соединения;
• и коротко объясним, как предотвратить все эти безобразия.

В общем, под катом вас ждет рассказ про распространенные уязвимости на стороне клиента и некоторые методы Client-Side защиты.

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

В этой статье я хочу познакомить читателей с одним из необычных open source проектов, над которым мы работаем последние несколько месяцев. Наш проект посвящен разработке Mimock — инструмента, который помогает создавать моки REST API эндпоинтов для тестирования UI-приложений локально или в CI/CD-пайплайнах. Mimock представляет собой основанное на перехвате данных решение, позволяющее разработчику создавать или обновлять моки без необходимости перезапускать приложения.

Итак, мы с вами добрались до третьей, самой «хардовой» части цикла. Сегодня поговорим про gRPC.

Что такое gRPC? 

Сам RPC — удалённый вызов процедур (иногда вызов удалённых процедур; RPC от англ. remote procedure call) — класс технологий, позволяющих программам вызывать функции или процедуры других программ, делая это так, как если бы они находились в одном адресном пространстве. Буква g в названии — это гугловая реализация этих технологий.

Разберем это все на примере.

Допустим, что вы — программист и сидите в монолитной репе. У вас одно приложение. Сам проект открыт в IDE и вы в нем работаете. В репе реализован определенный класс (например, на Kotlin), у которого есть метод, возвращающий вам данные по пользователю.

Мы в API отказались от большого количества unit-тестов в пользу большого количества интеграционных/системных, чтобы тестировать меньшим количеством кода большее количество функций, а также наблюдать за взаимодействием разных частей системы.

На самом деле мы просто решили писать тесты не на отдельные классы/методы, а на интерфейс api, которым пользуются клиенты - на сервисы этого API. Тестируя их, мы убиваем двух зайцев: проверяем логику работы сервисов api + форматирование результата.

А такое тестирование сопряжено с несколькими проблемами.

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

В мире современной разработки программного обеспечения, взаимодействие между различными приложениями через интерфейсы приложений (API) стало неотъемлемой частью разработки. Однако, прежде чем мы можем строить сложные взаимодействия, необходимо убедиться, что наш API работает корректно и предоставляет ожидаемые результаты.

И вот на сцену выходит Postman - мощный и интуитивно понятный инструмент, предназначенный специально для тестирования и разработки API. В этой статье рассказывается о самых базовых вещах, с которых следует начать свое знакомство с Postman.

Отправка HTTP-запросов, создание тестов, организация запросов в коллекции, работа с переменными - все это лишь часть функциональности Postman, которая облегчает процесс тестирования и повышает его эффективность. Если вы только начинаете свой путь в изучении этого инструмента, не волнуйтесь! Этот гайд поможет вам разобраться с базовыми принципами работы с Postman и покажет, как сделать ваш процесс тестирования API гораздо более эффективным и приятным.

Готовы начать? Давайте вместе погрузимся в увлекательный мир тестирования API с Postman!

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

Так вот, здравствуйте, на этой неделе это — я. Пять лет опыта тестирования, перескакивание с одной области (мобилки) в другую (веб/энтерпрайз). Даже хорошие отзывы о моей работе были, мамой клянусь!

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

Однажды передо мной возник некий «чёрный ящик» — Шина, которая отвечает за преобразование данных из внешнего формата во внутренний. Какие внутри происходят преобразования, какие процессы, как идут запросы, потому что они очень большие, — непонятно. Логи есть, но они ограничены, к тому же часто запросы не логируются, потому что некоторые данные пользователей нельзя показывать. В попытках решить проблему и возник мок-сервер, как решение задачи понять, как работает «ящик», на каких принципах, и понять, правильно ли он работает. 

План статьи:

— Проблематика черного ящика и почему его вообще нужно вскрывать.
— Варианты решения проблемы.
— Подробно про мок-сервер, как один из вариантов решения проблемы: зачем нужен, в чём польза и как выбрать между готовыми и самописными решениям.
— Как написать свой мок-сервер.
— Посмотрим как он работает на реальной задаче. 
— Закрепляем материал в блоке «Польза мок-сервера».

Привет! Продолжаем цикл статей про тестирование не-REST-бэкенда, в прошлый раз мы говорили о GraphQL, теперь пришло время WebSocket.

Итак, что такое WebSocket?

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

Что тут важно — что это протокол (со всеми вытекающими последствиями для протокола), который использует постоянное соединение.

Работу по WebSocket в обычной жизни можно представить примерно так.

Вы живете в квартире вместе с семьей, решили поработать, ушли в отдельную комнату и закрыли за собой звуконепроницаемую дверь (ну а как еще работать-то). В общем, сидите, работаете, и вообще не слышите происходящего в квартире. Заметите только, если вам кто-то постучить в дверь.

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

ОК, что вам делать в такой ситуации?

Привет, меня зовут Александр Беляков, я инженер по тестированию Альфа-Банка. В 2021 году пришёл в IT из медицины и четыре месяца стажировался в Альфа-банке. Хотел бы рассказать о внедрении автотестов REST API с JSON-schema на проекте, на котором я стажировался с нуля и без опыта: с чего начать, как подготовиться, что необходимо знать и как быть с ошибками. Статья будет полезна начинающим тестировщикам, как я, которые только хотят начать работать в тестировании. Но и начинающим лидам я скромно рекомендую уделить статье время. У вас уже достаточно опыта и вы всё знаете, но, возможно, не помните, каково это ничего не знать.

Apache JMeter — это инструмент для проведения нагрузочного тестирования, представляющий собой десктопное приложение с открытым исходным кодом на базе Java. JMeter позволяет определить, может ли тестируемое веб-приложение удовлетворять требованиям высокой нагрузки или нет. Он также помогает проанализировать работу всего сервера под высокой нагрузкой.

Привет! Меня зовут Сергей, я один из разработчиков продукта «Сервис персонализации» в компании Sportmaster Lab, и в этом посте я расскажу про SonarQube – платформу для непрерывного анализа и измерения качества программного кода, разработанную компанией SonarSource.

Сейчас SonarQube является чем-то вроде отраслевого стандарта. В частности, это стандарт центра компетенций Sportmaster Lab. В своей работе SonarQube использует статический анализ кода: реальное его выполнение не требуется, так как анализируются именно «исходники». Предмет анализа этого инструмента — потенциальные ошибки и уязвимости, стандарты оформления кода, наличие тестов и уровень покрытия ими, а также дублирование кода и его поддерживаемость. SonarQube поддерживает большое количество языков программирования, его можно встраивать в конвейер CI/CD и в вашу среду разработки. А еще — файлы отчетов сторонних инструментов (Eslint, Stylelint, OWASP Dependency Check и многие другие).

В этой статье вы узнаете:

• как работать с SonarQube;

• как он может помочь вам в работе и сделать ваш код лучше.

Эта статья — мой сугубо личный опыт работы с SonarQube в качестве пользователя, поэтому я не буду останавливаться на таких «административных» моментах, как развертывание SonarQube, создание в нем нового проекта и настройка его интеграции с GitLab.

Чем браузерные расширения могут помочь в тестировании? А какие именно? И все ли они безопасны? Весной на нашей конференции Heisenbug об этом всём рассказывали Юлия Атлыгина и Татьяна Дроздова. А теперь, пока готовится следующий осенний Heisenbug, публикуем на Хабре текстовую версию их доклада.

1.5 годовое исследование IT‑курсов открыло мне глаза на 3 вещи:

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

2. Есть огромный, почти в 10 раз, разрыв в статистике трудоустройства выпускников между худшими и лучшими QA-курсами.

3. У худших по трудоустройству курсов зачастую лучшие отзывы.

При этом IT‑компании, как и прежде, ищут квалифицированных джунов и редко находят.

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

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

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

Привет, Хабр! Меня зовут Константин Боковиков, я Chapter QA Lead в онлайн-кинотеатре KION. Я занимаюсь организацией процессов тестирования в командах и оценкой их зрелости, а потому часто использую в работе автотесты. К слову, автотесты нужны не всем: для некоторых задач и команд они просто не подходят. В этой статье я постараюсь показать наш опыт использования этого инструмента и расскажу, кому, на мой взгляд, можно обойтись без него, а кому точно стоит его освоить.