Когда мы начинаем погружаться в нагрузочное тестирование, первая мысль обычно такая: «Сейчас я напишу сценарий, запущу кучу виртуальных пользователей — и вот она, настоящая нагрузка!». Но очень быстро приходит понимание: без подготовленных данных результаты будут далеки от реальности.
Здесь на сцену выходит сидинг (от англ. seeding). Это понятие часто вызывает вопросы у начинающих инженеров по тестированию производительности: «Что это за зверь такой и зачем он нужен?». На самом деле, сидинг — один из тех невидимых, но критически важных этапов подготовки, от которого напрямую зависит качество и честность ваших нагрузочных тестов.
В этой статье мы разберёмся:
что такое сидинг и почему без него нагрузочное тестирование часто "врет";
какие бывают подходы к подготовке данных;
почему правильный выбор метода сидинга может сэкономить вам часы (а иногда и дни) отладки;
и что делать, чтобы ваши сценарии выглядели как реальная работа пользователей, а не как набор искусственных действий.
Привет! Я Наталья, QA в команде инкассации. Моя система умеет планировать маршруты для инкассаторов T-Банка. Поделюсь докладом моего коллеги — архитектора Boxy SDK Дмитрия Кузнецова, — который услышала на конференции Heisenbug.
Доклад привлек меня нестандартным взглядом на классическую пирамиду тестирования и монументальным подходом к работе с требованиями.
Взгляд архитектора на проблемы тестового покрытия привносит структуру в этот анализ, подсвечивает интересные места в архитектуре, наталкивает на мысли и желание попробовать самим расщеплять требования на производные и смотреть, что из этого получится.
Мне, как QA, близка ситуация, когда тестов на проекте вроде написано много, но они пропускают проблемы. Поэтому тема пробелов и понимание их природы кажется мне важной. Я расшифровала доклад с целью привнести свежий и глубокий взгляд на нашу повседневную работу.
Тестирование — это наука не о том, чтобы доказать, что программа работает корректно, а о том, чтобы доказать, что она работает НЕкорректно.
И если доказать это не удалось, то с какой-то вероятностью программа работает корректно. Остается некоторый пробел. Давайте рассмотрим, что за это за пробелы, откуда берутся и как можно их минимизировать.
Кэширование — это невоспетый герой современных приложений: оно повышает производительность и сокращает время загрузки. Но в автоматизированном тестировании этот же герой может превратиться в нарушителя порядка, вызывая нестабильность и несогласованность результатов. Кэши на фронтенде — такие как хранилище браузера или service workers — и на бэкенде — например, CDN или кэширование запросов к базе данных — могут сделать тесты ненадёжными, если с ними неправильно обращаться. В этой статье мы рассмотрим влияние кэширования на автоматизацию тестирования, выделим основные проблемы и предложим практические стратегии, которые помогут обеспечить стабильную работу тестов при каждом запуске.