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

Для работы бывает полезно иметь несколько копий одной реальной базы для экспериментов, фикстур или просто тестовых приложений. База растет и время копирования через разворачивание дампа или с помощью шаблона также возрастает до утомительных величин. Для решения этого кейса уже описаны варианты использования файловой системы с поддержкой CoW - Btrfs. В интернете находил  такие инструкции, они сводятся к тому, что делается снепшот всего сервера. И для работы второго "скопированного" нужно перегенерировать pid и сменить порт для предотвращения конфликтов. Этот способ довольно универсальный относительно конфигурации баз на сервере, но кажется имеет ограничение для неопределенного кол-ва параллельных снепшотов серверов.

В этой статье предлагаю свой вариант реализации снепшотов на одном экземпляре сервера postgres и одной базы, на произвольное кол-во копий.

Инструкция linux only, про поддержку CoW файловых систем на Windows не в курсе.

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

На старт

Через полгода после старта работ выяснилось, что дизайны не соответствуют текущим реалиям, так что разработку заморозили на полгода. В это время команда не скучала, развивалась и реализовала небольшой проект — Web-приложение для управления электронными подарочными картами. И вот появились дизайны, появились концепция и большой файлик в Excel с примерно 800 строками. Каждая строка — это фича, которую надо реализовать на сайте. Фичи были как маленькие (отображать баннер и другой блок на сайте), так и большие (реализовать корзину).

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

С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).

Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!

Всем привет! На связи Николай Мезинов, разработчик фронтенда в продуктовой команде DevPlatform. Хочу поделиться опытом, как мы ускоряли прохождение e2e-тестов на Cypress в пайплайнах GitLab.

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

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

Но что, если обновлений насчитывается 250+ типов? А если поддерживаемых ОС — порядка 250? И для тестирования требуется 7500+ тестовых машин? Такой вот типичный хайлоад. Который должен постоянно масштабироваться…

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

Человеческий мозг обычно лучше воспринимает информацию из изображений, чем из текстов. И в инструментах, подобных Flame Graph, этот принцип блестяще реализован. Поэтому в Percona его используют в рамках работы группы поддержки. Чаще всего в тех случаях, когда нужно получить всестороннее представление о том, что и как долго проделывает MySQL. Так можно лучше понять, какие операции стоят за конкретной рабочей нагрузкой и каким образом лучше исправлять возникающие проблемы. И это можно использовать и для оптимизации, и для устранения неполадок.

Давайте воспользуемся их опытом и разберемся, откуда брать и как подготавливать образцы для визуализации данных. А после этого — как из них генерировать Flame Graph и как с этим работать.

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

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

Возможно, вы уже читали наши статьи про Gatling: первую и вторую. Они успели устареть, поэтому мы решили вернуться с обновленной информацией.

Андрей Лушников выступил у нас на Heisenbug с докладом о Playwright ещё в 2020-м. Но похоже, что с тех пор тема доклада стала только актуальнее: 34 000 звёзд проекта на GitHub ясно показывают, что он пришёл к популярности. А Андрей по-прежнему остаётся одним из главных контрибьюторов Playwright. Поэтому мы решили сделать для Хабра текстовую версию его доклада.

Конечно, за два года проект успел уйти вперёд (обзавёлся своим тестраннером и локаторами), но база осталась прежней, так что информация по-прежнему может быть полезной. Если вы ощущаете, что и вам пора приобщиться к этому инструменту — вот материал от того, кто точно глубоко разбирается в теме.

Видео и расшифровка — под катом. Далее повествование будет вестись от лица спикера.

Привет! Меня зовут Антон, я ведущий инженер по тестированию в Ozon: занимаюсь созданием и поддержкой end-to-end Go-тестов бэкенда для QA.

Мы довольно долго писали тесты в основном на Python. Go – молодой язык, и популярных устоявшихся инструментов у него пока немного. В Python есть pytest, в Java – JUnit и TestNG, в Go – пока что весьма свободно. 

Однажды, в очередной раз переписав группу старых Python-тестов, я решил, что надо что-то менять. Эта мысль в итоге привела меня к созданию нашей собственной опенсорс-библиотеки – с поддержкой Allure без перегрузки интерфейса, инфраструктурой для хранения тестов как в одних репозиториях с сервисами, так и в отдельных, репортами в Slack и разными другими штуками.

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

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

Общепринятой практикой в индустрии является использование тест кейсов в качестве основы для автоматизации тестирования. QA инженеры разрабатывают их на основе user stories в рамках обычного тестирования, а затем автоматизируют эти тесты. С каждой итерацией тестируется больше историй, автоматизируется больше тестовых случаев, и набор автоматических тестов становится всё больше. Руководители продвигают такие метрики, как, например, «процент покрытия» и хвалят команды с высокими показателями. Некоторые компании даже специально нанимают «инженеров по автоматизации», чья единственная работа состоит в том, чтобы брать тест кейсы и автоматизировать их.

К сожалению, автоматизация тест кейсов и навязывание «процента покрытия» — это антипаттерн обеспечения качества, который неизбежно приводит к раздутым и сложным в обслуживании наборам тестов, которые приносят мало пользы. Хотя автоматизация имеет решающее значение для agile delivery, этот чрезмерно упрощенный подход «фабрики автоматизации» не является хорошим способом автоматизации тестирования.

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

Издержки и преимущества автоматизации тестирования

Чтобы понять, почему автоматизация существующих тест кейсов настолько проблематична, нам нужно вернуться назад и немного проанализировать теорию автоматизации. В частности, нам нужно изучить издержки и преимущества автоматизации, посмотреть на ожидаемую ценность автоматизированных тестов во времени, а затем оценить, как ожидаемая ценность меняется в различных типах тестов. Затем мы сможем увидеть, как автоматизация тест кейсов с использованием простого подхода «фабрики автоматизации» повлияет на тестирование в целом.

Aloha всем хабравчанам! Я Влад, системный администратор Cloud4Y. В этой статье расскажу, как мы выбирали продукт сканирования на уязвимости, почему важно контролировать, какие сервисы доступны извне и зачем необходимо проводить постоянный аудит состояния сети. Чай, кофе, па-а-а-аехали!

Привет, Хабр! Меня зовут Александр, я разработчик в юните, который является центром экспертизы по качеству в Авито. Мы помогаем командам с внедрением эффективных и современных подходов тестирования, а также разрабатываем инструменты для тестирования и управления качеством. 

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

Как тестировать React-компоненты? Какую библиотеку использовать? Как тестировать компоненты, которые берут данные из Redux, а не из пропсов? Как тестировать компоненты, в которых используется роутинг с помощью React-router-dom? Что делать, если в компоненте есть асинхронный код?

...Мои вопросы, когда на работе впервые попросили покрыть тестами компонент. Я, разумеется, стал гуглить тестирование React-компонентов в связке с Redux и React-router-dom, и понял, что в сети есть много ответов на вопрос, зачем нужно тестирование, но мало кто объясняет, как написать тесты. А если и объясняет, то в  общих чертах на абстрактных примерах. Мне не хватало статьи, вооружившись которой, начинающий разработчик мог бы выполнить тест на реальном продукте. Поэтому я решил написать ее сам.

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

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

Сайт с багами – горе для бизнеса. Всего одна 404-я или 500-я ошибка может лишить вашу компанию солидной суммы денег и хорошей репутации. Но есть способ избежать этого: тестировать сайт. О том, как это сделать, расскажет данная статья. Прочитав её, вы узнаете, как тестировать код на Django, создать своего пользователя-тестировщика и много чего еще. Добро пожаловать под кат.

Привет, хабровчане!

Меня зовут Нурыев Асхат, я ведущий инженер по автоматизации в DINS. За время работы в компании я участвовал в решении множества сложных задач. В этой статье я поделюсь историей улучшения процесса и автоматизации тестирования высокой доступности и восстановления после отказа подсистемы API, состоящей из множества компонент. 

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

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

Началось все как обычно: одним прекрасным утром ко мне подошел менеджер и спросил, не хочу ли я заняться одной интересной задачей. К тому времени у меня уже был опыт организации перфоманс-тестирования и вообще улучшения процессов в команде, так что я, конечно, согласился. А когда он объяснил, чем именно предстоит заняться, глаза у меня загорелись!  Только подумайте: построить HA тестирование целой подсистемы —  есть где развернуться, проявить изобретательность!

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

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

Как и обещали, возвращаемся с записью первого QA-митапа от Ozon Tech. Поговорили об уровнях изоляции компонентов и комбинаторике. Ещё при регистрации можно было задать вопрос о тестировании, как это устроено у нас — мы получили почти полсотни любопытных вопросов и успели ответить на большинство из них.

Видео и презентации — под катом.