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

Проверка кода (Code Scanning) автоматически обнаруживает ReDoS-уязвимости, но исправить их бывает не всегда просто. В этой статье описана 4-х этапная стратегия исправления багов ReDoS.

Что делать, если на тестирование вечно не хватает времени, разработчики не читают спеку, а мотивация работать ниже плинтуса? Оля Ерина, QA Lead red_mad_robot в Томске, рассказывает о хитрой методологии, которую можно использовать как на всём проекте, так и в QA-процессах. И даже в личной жизни!

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

Делимся опытом работы с автотестами в ОК: от подходов к постановке задач до схемы настройки окружения статического анализатора кода.

Материал подготовлен по мотивам доклада руководителя команды автоматизации тестирования ОК Эмилии Куцаревой и младшего инженера по автоматизации тестирования соцсети Евгения Буровникова на ИТ-конференции «Стачка».

Привет,  я Костя — QA Lead в tekmates. В статье расскажу про частые ошибки в планировании тестировании мобильных и веб- приложений, и, конечно, как их избежать. Кроме советов также покажу интересные кейсы: например, с помощью каких инструментов автоматизации мы сократили работу в рамках регресса с 2 часов до 20-25 минут.

Итак начнём. Вот какие проблемы я вижу.

Компонент «Предотвращение утечек API» расширяет функциональность ПО «Структура API» в области мониторинга скомпрометированных секретов (токенов) с дальнейшей возможностью блокировки таких токенов путём создания виртуальных патчей.Он предоставляет следующие возможности:

В конце прошлого года мы представили TestY, тест-менеджмент систему с открытым исходным кодом, которую разработала команда YADRO на замену TestRail.

Сегодня на связи я, Александр Зырянов, QA-менеджер в департаменте контроля качества YADRO и проектный менеджер TMS TestY. После первого текста о нашей системе вы обращались к нам с вопросами и пожеланиями. Некоторые предложения мы уже планировали в новый релиз, но были и те, что мы взяли в работу именно благодаря вашей обратной связи. В этой статье расскажу о фичах, вышедших в релизе 1.3, и отвечу на вопросы о TestY в комментариях.

Колесо крутится, но хомячок подписки помер. Оно просто крутится.

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

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

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

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

Привет!

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

Нам, людям, свойственно совершать ошибки, и это ок. Главное — проанализировать, что пошло не так. Чтобы вы извлекали вывод без вреда, вот вам ТОП-5 ситуаций, которых вы можете избежать в своём бизнесе во имя прибыли, а не убытка.

Два года назад во время работы в домашней сети со мной произошло нечто очень странное. Я эксплуатировал слепую уязвимость XXE, которая требовала внешнего HTTP-сервера для переправки файлов. Казалось, всё шло, как по маслу, но вдруг в моем лог-файле появилось нечто неожиданное...

Я уже писал историю о том, как создал и развил инфраструктуру, которую Amazon использует для проведения нагрузочного тестирования и тестирования производительности (TPSGenerator). Но я ещё не писал о том, как я её масштабировал.

Первая версия была довольно убогой и предназначалась только для одного хоста. Я запускал её как инструмент командной строки, указывал, сколько тысяч транзакций (“TPS”) в секунду мне нужно — и TPSGenerator порождал потенциально тысячи потоков, радостно потребляя все аппаратные ресурсы, которыми вы были готовы пожертвовать. В тщетной попытке избежать проблем с распределёнными системами я профилировал каждую строчку кода и оптимизировал её до последней степени. На обычной машине он мог генерировать несколько сотен тысяч TPS, что было достаточно для многих сервисов.

Но приближался день больших распродаж «Киберпонедельник» — в этот день совершалось самое большое количество покупок в году. По мере приближения даты всё больше команд стали спрашивать меня, как генерировать большую пропускную способность, чем та, на которую способна одна машина — чтобы убедиться, что их сервисы справятся с пиком.

Бывали ли вы когда-нибудь на демо, на котором разработчики с гордостью показывали экран за экраном JSON вывод API, а пользователи путались и отвлекались, потому что у них не получалось в этом разобраться? Вы когда-нибудь пытались использовать API в разработке и были разочарованы тем, как трудно найти правильную полезную нагрузку JSON и заголовки, чтобы протестировать фичу? Demo Front-End — это простой пользовательский интерфейс, предлагающий базовые возможности для демонстрации и ознакомления с таким API.

Использование Testcontainers кардинально улучшило процесс работы с тестовыми сценариями. Благодаря этому инструменту, создание окружений для интеграционных тестов стало проще (см. статью Изоляция в тестах с Кафкой). Хотя нагрузочное тестирование встречается реже, чем функциональное, оно может быть гораздо более увлекательным. Изучение графиков и анализ работы конкретного сервиса может доставить настоящее удовольствие. Такие задачи редки, но для меня они особенно захватывающие.

Цель данной статьи — продемонстрировать подход к созданию стенда для нагрузочного тестирования в том виде, в котором пишутся обычные интеграционные тесты: в форме spock-тестов с использованием Testcontainers в среде Gradle проекта. В качестве утилит нагрузочного тестирования используются Gatling, WRK и Yandex.Tank.

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

Михаил Абрамов, технический писатель платформы МТС Exolve, подготовил для начинающих специалистов чек-листы с основными правилами и процедурами тестирования.

Привет!)
Возникали ситуации, когда стандартных методов поиска веб-элементов не хватало для полноценной автоматизации? То кнопка не нажимается, то элемент перекрывается, то не подгружается. У всего этого есть разные причины и самые разные решения.
В этой статье как раз таки рассмотрим некоторые из таких проблем.

Привет! Меня зовут Любовь, я работаю QA‑инженером в компании iSpring. Моя команда и я занимаемся тестированием различных аспектов нашего продукта, включая его интеграции с другими сервисами.

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

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

Привет, меня зовут Роман Брылунов, я QA Automation в команде сервиса транспорта 2ГИС. Мы автоматизируем сервисы транспортных сценариев, таких как построение маршрутов для разных видов транспорта, построение пешеходных маршрутов, решение задачи коммивояжера. Основная часть наших тестов — функциональные тесты логики приложения.

С сервисами общаемся по HTTP, но есть и несколько внутренних сервисов со взаимодействием по gRPC. Все ответы, полученные от сервисов, мы предварительно валидируем перед обработкой в тесте. Для валидации используем библиотеку Pydantic. Это позволяет нам описывать формат взаимодействия с помощью моделей и обрабатывать ответы в виде Python-объектов вместо словаря после стандартного парсинга JSON. Тесты встроены в CI, успешное прохождение тестов является блокирующим условием для влития кода. Таким образом, чтобы внести изменения в API, необходимо актуализировать модели в тестах. В противном случае ответ от сервиса не пройдёт валидацию при прогоне тестов. 

Мы стараемся всесторонне подходить к контролю качества продукта, в том числе хотим, чтобы у продукта была красивая и актуальная документация. У наших сервисов была документация, но она обновлялась вручную. А у нас есть модели запросов и ответов, которые точно соответствуют текущему формату API. Мы подумали, что будет здорово использовать эти модели для формирования документации. Попробовали и успешно внедрили. Расскажу о том, как можно это сделать.

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

Меня зовут Ксения Бирюкова, я владелец продукта Платформы Сфера, разработанной холдингом Т1. В одном из моих проектов мы с командой пытались проводить нагрузочное тестирование. Тогда это казалось очень сложным: пробовали тестировать каждый модуль отдельно, связь с legacy-монолитом не помогала, возникали проблемы с написанием генератора псевдо-уникальных персональных данных и многое другое. И хотя результат был достигнут, ресурсов мы потратили гораздо больше, чем планировали. В итоге собрали список ошибок и задумались, как сделать нагрузочное тестирование менее болезненным. Разберём на своих и чужих примерах.