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

Тестирование API — неизменная задача при разработке продуктов. Проблема, с которой сталкиваются многие компании, — большой ручной регресс. Появляется автоматизация, но покрытие огромного количества API‑методов требует ресурсов, которых часто нет. Кроме того, в большинстве случаев написание API‑тестов — монотонная работа, которой никто не любит заниматься. Как решить эти проблемы?

Привет, Хабр. Меня зовут Елизавета Андреева. Я инженер по автоматизации тестирования в ОК.Tech. Мы с коллегами в ОК разработали и внедрили автогенерацию API‑тестов, благодаря которой мы сокращаем ручную работу и время на написание однотипных автотестов, оставляем QA‑инженерам для покрытия только кейсы на бизнес логику. И в этой статье (которая станет первой в серии из двух частей) я начну рассказ о том, как мы реализовали наш генератор и каких результатов нам удалось достичь.

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

Меня зовут Кирилл Поляков, я ведущий инженер по тестированию Lamoda Tech. В этом тексте я поделюсь своими ответами, основанными на 12-летней практике в тестировании. Разберем, как связаны чистая архитектура и пирамида тестирования, расскажу нюансы выстраивания стратегии на разных уровнях тестирования, дам рекомендации для QA-инженеров, которые помогут улучшить процесс проверки кода.

Привет, читатель!
Меня зовут Дмитрий Евсюков, я работаю в Купере старшим специалистом по тестированию. Когда я только пришёл в свою команду, то всё тестировал руками и не мог найти время на автоматизацию. Это приводило к тому, что я не успевал протестировать все задачи в полном объёме и многое откладывалось в техдолг. Сейчас я выработал более умный подход, который помогает мне своевременно разрабатывать автотесты и быстро поставлять функционал на прод без снижения качества.

В этой статье я хотел бы поделиться своим опытом по внедрению поддержки временных зон в фулстек-приложение, построенное на NestJS и Angular. Мы узнаем, как сохранить настройки таймзоны пользователя в базе данных и правильно использовать их при взаимодействии с сервером через REST и веб-сокеты.

Всем привет! Недавно в блоге выходила статья, в которой мой коллега Александр Волков рассказал про применение практик хаос-инжиниринга, продемонстрировал поведение системы при сбоях на примере демосервиса, оценил его отказоустойчивость и предложил стратегии для улучшения архитектуры. А в этой части я, Екатерина Ильина — QA-инженер Cloud.ru, расскажу, как мы решили собственноручно сломать наши сервисы, чтобы сделать их отказоустойчивее.

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

С увеличением масштабов и сложности программного обеспечения требования к его качеству становятся всё выше. Ранее использовавшиеся подходы к обеспечению качества (QA) уже не всегда справляются с текущими вызовами, особенно когда речь идет об интеграции тестирования в рамках непрерывной разработки и доставки (DevOps). Появление подхода QAOps знаменует собой новый этап в эволюции тестирования: это попытка обеспечить максимально тесную интеграцию QA и DevOps, где тестирование становится неотъемлемой частью каждого шага разработки.

Привет, Хабр! Меня зовут Алексей, я QA-специалист в компании SimbirSoft. Моя статья будет полезна:

- QA-инженерам, которые хотят улучшить свои навыки и узнать о новых подходах в тестировании, 

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

- руководителям, которые ищут способы улучшить процессы разработки и тестирования в своих командах,

- всем, кто интересуется современными трендами в области разработки и тестирования программного обеспечения.

Анализ сетевого трафика сайта example.com с использованием Wireshark: установка, захват, фильтрация.

27 ноября 2024 года была выявлена критическая уязвимость в Zabbix с CVSS-оценкой 9.9, представляющая собой SQL-инъекцию в одном из эндпоинтов API Zabbix. Уязвимость позволяет атакующему, имеющему доступ к API, выполнить произвольные SQL-запросы. При определённых настройках Zabbix, которые разрешают удалённое выполнение команд через агентов, эта уязвимость может быть использована для полной компрометации инфраструктуры, находящейся под мониторингом Zabbix.

В предыдущей статье мы рассмотрели тестирование сервисов и его основные компоненты: тестирование производительности, тестирование на отказоустойчивость и управляемость. Как и было обещано, здесь мы рассмотрим тестирование производительности более подробно. 

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

Всем привет! Я Светлана Кирдяйкина, старший инженер по тестированию в Авито. Если вы задумываетесь про оптимизацию своего времени и улучшении тестирования — эта статья точно будет вам интересна. Здесь я постаралась простым языком описать факторы, на которые стоит обратить внимание перед тем, как начинать автоматизацию.

Обучение на разработчика в 32 года в техникуме Испании. Личный опыт. 1 триместр.

Начала обучение не с нуля. В СОШ 254 Кировского района СПб закончила физмат в 2008 году, потом 6 лет учебы на юрфаке СПбГУ, 10 лет работы юристом, в 2023 коду Яндекс.Практикум Тестировщик 4 месяца, ISTQB FL сертификат, EDX основы Python. А еще у меня папа, все дедушки и одна бабушка, а также муж инженеры. Отягощенная наследственностью склонность к логическим рассуждениям, можно сказать душнила.

Рассказываю о программе обучения, об экзаменах. Буду рада вопросам.

Привет, Хабр! Я – Мария Скрипачева, тестировщик в АйТи-Балансе. Сегодня почти все компании применяют тестирование, и мы не исключение: наши проекты проходят несколько стадий проверок до развёртывания. На нынешнем месте работы я иногда встречаю вопрос, с которым не раз сталкивалась на предыдущих: «а нужен ли GitHub тестировщику?». Эта дискуссия не нова. Я решила внести свою лепту в обсуждение, опираясь на мой опыт и опыт моих коллег, и заодно рассказать о фундаментальных вещах. Поехали🚀

Когда мы в NTechLab первый раз задумались о проведении нагрузочных тестов для наших продуктов, выбор инструмента для нас был очевиден: JMeter имел мощное комьюнити, обширный набор доступных плагинов и возможность написать свой при необходимости. Немаловажным фактором стало и то, что в интернете масса статьей о том, как начать работать с JMeter.

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

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

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

Все началось пару дней назад, когда ко мне в предложку ВК попал мой первый руководитель, с которым мы не виделись уже несколько лет. Перейдя в профиль, я увидел, что он учился в Сомалийском Университете Пиратства и Абордажного Судозахвата. Мы всегда пользовались и пользуемся лицензионным ПО, поэтому я сразу смекнул, что ни на какого пирата он не учился. Дальше я попробовал через веб-интерфейс в своем профиле поставить такое же высшее образование, но такого университета в списке доступных не нашлось... Но откуда тогда взялся университет пиратства?

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

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

Привет, Хабр! Меня зовут Вика. В СберТехе я занимаюсь разработкой продукта Platform V Works:Test Data Management (TDM). Инструмент помогает QA генерировать необходимые синтетические тестовые данные по клику, а не обращаться к смежным командам и тратить на это время. Менеджерам TDM помогает сокращать time‑to‑market продуктов, поэтому лететь на другую планету ради тестов больше не придётся. В этом материале я расскажу, как мы поняли, что нам нужен отдельный инструмент для генерации, какие показатели у нас были в начале пути и к чему пришли сейчас. Поехали!

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

Я Александр Волков — QA Lead в Сloud.ru. В статье на примере демосервиса онлайн-магазина покажу, как мы применили практики хаос-инжиниринга, проверили поведение нашей системы при сбоях, оценили ее отказоустойчивость и в итоге выработали стратегии для улучшения архитектуры.

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

В этом посте я добавлю в NestJS-приложении валидацию REST-запросов и их отображение в формах Angular-приложения.