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

Для начала разберёмся, что такое Race Condition и почему эта уязвимость заслуживает внимания.

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

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

Перейдём к тому, какие виды этой уязвимости вообще бывают.

Можно выделить 3 вида:

Тестирование функциональности Direct I/O — задача сама по себе нетривиальная. Сложность возрастает, если проверить работу функциональности можно только на ненагруженной базе данных, а тестируемое приложение предназначено для работы с высоконагруженными системами.

Можно, конечно, ограничиться проверкой того, что на неактивной базе приложение не использует кеш. Но это не даёт ответа на главные вопросы клиента: «Будет ли реальная выгода в промышленной эксплуатации и не случится ли так, что активное резервное копирование снизит производительность базы данных?»

Меня зовут Наталья Лабчук, я занимаюсь тестированием Platform V CopyWala — системы резервного копирования и восстановления данных от СберТеха. Расскажу, как мы убедились в том, что функциональность Direct I/O в CopyWala при снятии резервной копии с высоконагруженной базы не ухудшает производительность кластера. Надеюсь, что почитать об этой задаче будет полезно тем, кто работает в разработке и тестировании Postgres-подобных баз данных, а также инженерам, которые отслеживают производительность и администрируют PostgreSQL.

testing в Go даёт только примитивы. Разбираем, почему автотесты в Go быстро превращаются в боль, и какого слоя исполнения в нём не хватает.

Разрабатывая приложения, мы стараемся не злоупотреблять дублированием кода. Из часто встречающегося кода мы формируем библиотеки, а для их соединения в инфраструктуре ASP.NET Core приложения используем DI-контейнер. Инфраструктура тестирования для ASP.NET Core API, как правило, тоже повторяется, но какие инструменты помогают нам переиспользовать тестовый код?
Разработчики Python решают эту задачу с помощью pytest.fixtures, однако в dotnet-экосистеме (xUnit) хорошего аналога пока нет.
В статье рассмотрим пример, как в несколько строк собрать полноценное интеграционное окружение с изолированной БД, фейковым временем и случайностью, а также как донастроить это окружение для отдельно взятого теста.

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

Если вы пишете на C#, но хотите добавить тестам элегантности Python — добро пожаловать.

Я прошёл тест на hh.ru с помощью ИИ. Мне не поверили и обвинили во лжи. Я прошёл его ещё раз. Под катом немного рассуждений, немного оскорблений и 30-минутный видеопруф.

Разбираемся, как работает robots.txt, почему его часто путают с инструментами индексации и какую роль он играет в эпоху ИИ-сканеров.

Не совсем пятничное чтиво, но…

Как-то так случилось, что решил разобраться для себя лично – какие подвижки появились в вопросе внедрения искусственного интеллекта в сфере сайтостроительства. ИИ действительно показал себя неплохо в отдельных задачах, но есть у него и минусы. Всё это тема для отдельного обсуждения, но здесь – только обзор реальной картинки. Делюсь бесплатно и без SMS ))

Привет, Хабр! Меня зовут Станислав Кулагин, я ведущий инженер отдела сертификационного тестирования компании YADRO. Я разработал ATS Studio — Flask-приложение, которое позволяло запускать автотесты в TestY TMS из браузера, не проставляя статусы руками. За полгода приложение стало популярным в нашей компании теперь экономит по 40 часов в месяц коллегам из KVADRA. 

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

и как не утонуть между БКИ, Госуслугами и тремя платформами одновременно?

Один QA. Три платформы. Шесть внешних сервисов. Легаси-код. И огромное количество неопределённости — в требованиях, в поведении интеграций, в том, что вообще считать корректным результатом. Рассказываю, как выстроить тестирование сложного финансового процесса так, чтобы до релиза добиралось не более 5–7 багов — и все они были известны заранее.

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

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

Сегодня мы поговорим о нагрузочном тестировании. Той самой дисциплине, которая требуется в каждом проекте, но вспоминают о ней только тогда, когда система уже горит, а менеджеры уже успели пообещать клиенту, что «это не повторится».

Сразу — не надо так!

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

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

Дано:

* Растущее количество ручных тестов (иногда переваливающее за тысячи), которые сложно поддерживать.

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

* Рассинхронизация между автотестами и ручными кейсами, приводящая к спорам о том, какой тест считать актуальным (главным).

* Сложности с параллельной работой в ветках, ревью изменений и плохой аудит удалений, где один клик может снести целую группу тестов.

Найти:

* Единый источник правды для всех тестов на проекте.

* Механизм, обеспечивающий прозрачный процесс работы с разными ветками, ревью изменений и т.д.

Привет, Хабр. Меня зовут Виталий Стародубцев. Я ведущий QA-инженер в СберЗдоровье — MedTech-компании №1 в России.

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

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

Всем привет! Продолжаю цикл статей про применение ИИ в тестирование. Сегодня поговорим про тестирование требований, а именно про первый и самый важный этап — подготовку контекста. 

В своей статье под контекстом я буду подразумевать структурированную информацию о продукте: описания компонентов, бизнес-правила, сценарии использования, связи между сущностями — то есть всё то, что нужно ИИ для понимания предметной области.

Git — один из базовых инструментов современного QA Engineer. Даже если тестировщик не пишет production-код, ему всё равно приходится работать с репозиториями, ветками, pull request и merge conflict.

В статье разберём:
— как устроен Git;
— какие команды реально нужны тестировщику;
— как работать с ветками;
— как не ломать чужой код;
— и как Git помогает QA в ежедневной работе.

Материал подойдёт начинающим и middle QA, а также будет полезен при подготовке к собеседованиям.

Разбираемся с терминологией Test Doubles без лишней воды. В чем реальная разница между Mock, Stub и Fake? В статье разберем классификацию на живых примерах: поднимем умный стаб-сервер на FastAPI, напишем мок-шпион для проверки сайд-эффектов и ускорим тесты с помощью фейковых БД.

Можно много рассуждать, как здорово было бы тестировать продукты в вакууме, когда есть время всё продумать, покрыть тестами каждый сценарий и только потом выкатывать в прод. Но в реальности это так не работает.

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

Привет! На связи Саша Мищенко, тимлид платформенной команды, и Света Чекунова, Senior QA Auto. Нам кажется, что мы нашли этот баланс.

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

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

Привет, Хабр. На связи Маша Лещинская, Head of QA в Surf. Мы все любим пет-проекты, и еще больше — пет-проекты на AI. Но есть нюанс: большинство таких штук забываются через неделю, потому что их сложно и дорого поддерживать. Я сделала проект, который живёт уже третий месяц, и причина не в каких-то крутых технологиях, а в том, что цена поддержки стала минимальной.

Привет, Хабр! Это команда Яндекс Практикума. В этом году мы переосмыслили, актуализировали и переупаковали курсы по тестированию: изменили методики и обновили программы с учётом изменений на рынке. Рассказываем самое важное.