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

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

Большая часть кода в современном мире пишется в виде микросервисов. И хотя мне не сильно нравится сложившийся уклад, и я даже временами пытаюсь бороться с этой напастью, но жить приходится исходя из окружающей действительности, а потому многие вопросы приходится валидировать именно об этот факт. Спор о новом языке? А давайте посмотрим, как он подходит к микросервисам, какие плюсы даёт! Рассуждаем о тестировании? Отлично, но давайте делать это не в применении к тёплому-ламповому периоду начала века, а к современности! И в этом месте внезапно может оказаться, что те аргументы, что мы пытаемся отстаивать или выслушиваем в тех или иных постах, давно устарели, неактуальны, слабы.

В этой статье я хотел бы поговорить о тестировании в современном мире. О лютом энтерпрайзе и о предложениях перенести его (энтерпрайза) опыт в мир опенсорс.

Я разработал небольшое фулстек-приложение в качестве примера REST + WebSockets бойлерплейта на NestJS и Angular. В приложении используется PostgreSQL для хранения данных, Redis для кэширования и Minio для работы с файлами. Изначально целевой средой для развертывания был Kubernetes, но для ускорения разработки и тестирования MVP я решил использовать бесплатные облачные сервисы: Supabase для инфраструктуры и Vercel для деплоя бэкенда и фронтенда.

Представим ситуацию. 2010 год, вы сидите за компьютером и играете в Counter Strike или Call of Duty. В самый ответственный момент игра начинает подвисать или вы застреваете в текстурах, из-за чего сливаете миссию. Обидно, но такое бывает по 10 раз в день, поэтому вы смиренно начинаете снова. А теперь представим ту же ситуацию в 2025 году. Очевидно, что сейчас большинство пользователей, столкнувшись с нерешаемой проблемой в игре, в итоге просто забросят ее. Потому что паттерны людей и их требования к продукту меняются. Соответственно, должны меняться и подходы к обеспечению качества ИТ-продуктов.

Меня зовут Алексей Петров. Я директор по качеству в ОК. В этой статье я в легкой исторической перспективе рассмотрю основные тренды и подходы, которые использовались в недавнем прошлом и актуальны сейчас.

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

Я Роман Соловьев, ведущий ИТ‑инженер в отделе RnD и готовых решений управления развития продукта в СберТехе. Сегодня расскажу, с какими проблемами мы столкнулись при написании тестов к проекту на Go, активно использующему Docker‑контейнеры, и как нам удалось их решить.

Эта статья будет полезна тем, кто пишет модульные тесты на Go, особенно для проектов, использующих Docker‑контейнеры. Я постараюсь просто и понятно объяснить официальный code‑style для модульных тестов, а также подсветить подводные камни, с которыми можно столкнуться при их написании.

В Go есть три способа управления параллельностью тестов:

Короткий гайд о -p, -parallel и t.Parallel а также бонус для любителей параллельного программирования

Привет, Хабр!

Меня зовут Алена Метенева, я работаю старшим инженером по обеспечению качества в компании SM Lab в проекте «Кассы». Я тестирую бэкенд и интеграции и там, где это возможно, автоматизирую тесты на Java. Сегодня я хочу рассказать вам о том, как MongoDB помогает мне с этим процессом.

Что такое MongoDb

Думаю, многие работали с MongoDB (Монга) и знают, что это нереляционная СУБД, которая использует для хранения данных JSON-структуру: вместо таблиц и строк, как в реляционных базах данных, в MongoDB есть коллекции (набор документов, эквивалент таблицы реляционной базы данных) и документы (внутри коллекции они могут отличаться друг от друга размером, содержанием и количеством полей), которые состоят из пар «ключ–значение».

Для чего Монга тестировщику 

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

Что я имею в виду?

Представьте, что вы тестируете интеграцию с другой системой. Если все работает стабильно, то пройти позитивные сценарии будет проще всего. А если вы хотите протестировать кейс, в котором смежная система выдает ошибку 503 (Service Unavailable) – это будет уже сложнее. Хорошо, если вы управляете обеими системами и можете просто перезагрузить одно приложение и попытаться достучаться до него через второе. А если система не ваша? В таком случае принято использовать моки. Но есть и третий вариант: если ваше приложение для подключения к другому берет ссылку из MongoDB, то эту ссылку можно просто подменить, добавив в нее лишние символы, чтобы получить ту самую ошибку 503 или 404 (Not Found), например.

Независимо от масштаба компании (даже если вы запускаете Lean Startup), важно помнить: нет смысла создавать продукт, который никому не нужен. Часто идея кажется отличной, пока остаётся в наших мыслях, но реальность может преподнести сюрпризы.

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

Оптимальный способ проверки — разработка MVP.

В этой статье разберём, что такое минимально жизнеспособный продукт (MVP), какие его виды существуют и как создать его с минимальными затратами, чтобы протестировать идею.

Привет, Хабр! Меня зовут Александр Зырянов, я проектный менеджер TestY — тест-менеджмент системы с открытым исходным кодом, которую разрабатывают и поддерживают инженеры YADRO. Мы третий год работаем над системой и недавно выпустили в open source большое обновление TMS — Тesty 2.0. 

В TestY 2.0 мы проделали огромную работу над UX-дизайном и производительностью, а также заложили фундамент для будущих изменений. Под катом расскажу, как мы пришли к необходимости обновлений и что сделали, а также покажу скриншоты с обновленным интерфейсом.

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

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

Меня зовут Михайлов Михаил, я работаю руководителем отдела тестирования в команде Polymatica BI. Недавно мне пришлось привести в порядок регрессионное тестирование, что позволило сделать его компактным и эффективным. Оказалось, что несколько простых действий кратно сократят время, необходимое на приведение в порядок регрессионного прогона. В этой статье разберем пять ключевых шагов.

Анализ результатов нагрузочного тестирования k6 требует не только сбора метрик, но и их грамотной визуализации. Избыточный поток данных может усложнить процесс принятия решений, поэтому важно выбрать ключевые показатели и подходящий инструмент для их отображения. В этой статье рассмотрим, какие метрики стоит отслеживать, как их визуализировать с помощью Grafana, CSV, JSON и других форматов, а также поделимся рекомендациями по эффективному анализу производительности.

Мир тестирования ПО стремительно меняется, и чтобы оставаться востребованным специалистом, важно не просто следить за трендами, но и осваивать новые навыки. Давайте разберёмся, что будет актуально для QA-инженеров в ближайшие годы.

Привет, Хабр! С вами Ксения Бычкова и Ольга Султанова из отдела тестирования Рунити. В этой статье расскажем про пирамиду тестирования и как мы внедряли эту best practice в нашей компании.

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

Мы, Татьяна Лескова и Татьяна Коваль, UX‑исследователи в RuStore, в этой статье расскажем, что стоит учесть при обучении продуктовой команды быстрым тестам интерфейса.

Предусловие перед тем, как начать: надеюсь, у вас уже скачан sublimetext или скачайте sublimetext с официального сайта.

Load-testing-hub: эволюция сервиса аналитики нагрузочного тестирования

Ранее я рассказывал о load-testing-hub, инструменте для аналитики и агрегации данных по нагрузочным тестам. Тогда он находился в стадии MVP, а теперь прошел значительные улучшения.

Что изменилось?

— Добавлено больше информации и гибкости в настройках.
— Расширены возможности сравнения результатов.
— Реализованы детальные графики и аналитика по методам.
— Оптимизирован процесс выявления аномалий в производительности сервисов.

Один из практических кейсов — поиск по банковским операциям среди сотен миллионов записей. Load-testing-hub помог протестировать производительность, выявить узкие места и оптимизировать решение.

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

Привет, меня зовут Анна Куренова (@SavAnna), в IT я уже девять лет. Начинала как разработчик и тестировщик, потом начала искать уязвимости и перешла в ИБ. Сейчас работаю DevSecOps-инженером и веду телеграм-канал 8ug8eer. В этой статье поговорим о базовых вещах в вебе и некоторых простых уязвимостях, поиск которых под силу даже начинающим. Текст будет полезен новичкам в сфере безопасности и тестирования софта.

Нашим подопытным станет магазин соков под незамысловатым названием Juice Shop. Это уже готовое приложение, которое работает на HTTP/1.1. Я развернула его на своем домене, который содержит множество уязвимостей и отлично подходит для обучения.

Привет, меня зовут Иван, и я зануда.

Сразу скажу, что в моем понимании зануда в тестировании — не тот человек, который всех достал и которого все хотят удушить, а тот, который умеет показать людям, что нужно делать хорошо и не делать плохо, и добиться от них этого. Я считаю, что QA должно расшифровываться как Quality Assistant. Это даже не про Assurance, когда вы обеспечиваете качество, это именно про то, что вы как тестировщик и участник команды помогаете на каждом этапе от требований до выкатки в прод и работы с сопровождением и вашими коллегами добиться того, чтобы каждый этап проходил все лучше и лучше.

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

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

Привет, Хабр. Меня зовут Николай Борисенко. Я специалист по автоматизации тестирования в ОК, и я продолжаю наш рассказ о генерации тестов на основе спецификации API.

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

Привет, Хабр! Я Михаил Бибик, работаю в СберТехе QA-automation-инженером, пишу автотесты для СУБД Pangolin — это целевая СУБД в Сбере и не только. В прошлом году наша команда искала и нанимала QA-инженеров с различным опытом, в том числе совсем начинающих. Когда я провёл штук 15-20 собеседований, то понял, что могу обобщить некоторые наблюдения и составить простые советы по поводу составления тест-кейсов для начинающих (скорее, очень начинающих) тестировщиков. В этой статье я покажу, как применить теорию тестирования на техническом собеседовании. Для этого разберу реальную задачу с нашего собеседования. Проходите под кат.