Перед вами доклад Марии Зеленовой zelma — разработчика в Едадиле. За час Маша рассказала, в чём состоит тестирование программ, какие тесты бывают, зачем их писать. На простых примерах можно узнать про библиотеки для тестирования Python-кода (unittest, pytest, mock), принципы их работы и отличия между ними.


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

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

Я уже давно не брал в руки шашки и Selenium, поэтому пришлось немного покопаться в интернете и поискать — что в этой ситуации делают умные люди. Решение, которое меня устроило в итоге, собрало несколько технологий: Java + Selenium + Junit + Allure + ffmpeg + VideoRecorder (by Pirogov). Но поскольку я все таки честно копался, пытаясь найти лучшее решение проблемы, то нашлось еще несколько альтернативных моему и более простых способов — как можно сделать слепок экрана.

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

Давайте посмотрим, что нам предлагают сделать.

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.

Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.

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

В этом году вышло сразу несколько статей о практике работы с новой системой маркировки “Честный знак”. Написаны они “айтишниками” IT-отделов компаний-участников оборота, что отражает их взгляд на ход пилотного проекта и первые дни запуска боевой системы. Например, вот и вот.

Систему часто критиковали и критикуют, в основном из-за частых изменений API, багов личного кабинета и белых пятен в некоторых процессах.

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

Может показаться, что статья — каша, но маркировка в целом такая каша и есть, очень много аспектов сходятся в одном месте.

Автоматизация тестирования помогает постоянно контролировать качество IT-продукта, а также снижать затраты в долгосрочной перспективе. В автоматизации существуют различные подходы, например, Behavior Driven Development (BDD), разработка через поведение.

С этим подходом связаны инструменты cucumber, robot framework, behave и другие, в которых разделены сценарии выполнения и реализация каждой конструкции. Такое разделение помогает составить удобочитаемые сценарии, но требует значительных затрат времени и поэтому может быть непрактичным при написании реализации.

Рассмотрим, как можно упростить работу с BDD, используя подходящие инструменты – например, фреймворк Spock, который сочетает в себе красоту, удобство принципов BDD и особенности jUnit.

Women in Tech открыли школу для девушек, желающих получить IT-специальность. На курс записались 60 человек, половина из которых его успешно прошли. Записи вебинаров были выложены в сеть, и их посмотрели более 2500 тысяч человек. Курс можно посмотреть по ссылке в статье. Подробнее под катом.

Введение

Некоторое время назад передо мной поставили задачу разработать отказоустойчивый кластер для PostgreSQL, работающий в нескольких дата-центрах, объединенных оптоволокном в рамках одного города, и способный выдержать отказ (например, обесточивание) одного дата-центра. В качестве софта, который отвечает за отказоустойчивость, выбрал Pacemaker, потому что это официальное решение от RedHat для создания отказоустойчивых кластеров. Оно хорошо тем, что RedHat обеспечивает его поддержку, и тем, что это решение универсальное (модульное). С его помощью можно будет обеспечить отказоустойчивость не только PostgreSQL, но и других сервисов, либо используя стандартные модули, либо создавая их под конкретные нужды.

К этому решению возник резонный вопрос: насколько отказоустойчивым будет отказоустойчивый кластер? Чтобы это исследовать, я разработал тестовый стенд, который имитирует различные отказы на узлах кластера, ожидает восстановления работоспособности, восстанавливает отказавший узел и продолжает тестирование в цикле. Изначально этот проект назывался hapgsql, но со временем мне наскучило название, в котором только одна гласная. Поэтому отказоустойчивые базы данных (и float IP, на них указывающие) я стал именовать krogan (персонаж из компьютерной игры, у которого все важные органы дублированы), а узлы, кластеры и сам проект — tuchanka (планета, где живут кроганы).

Сейчас руководство разрешило открыть проект для open source-сообщества под лицензией MIT. README в скором времени будет переведен на английский язык (потому что ожидается, что основными потребителями будут разработчики Pacemaker и PostgreSQL), а старый русский вариант README я решил оформить (частично) в виде этой статьи.

Любому QA известен такой метод минимизации тест-кейсов, как Pairwise Testing — попарное тестирование. Метод отличный, достаточно простой и проверенный множеством команд. Но что делать, если после его применения кейсов остается слишком много?

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

Вы не знаете имён Норберта Ларки (Norbert D. Larky) и Дэвида Холмса (David D. Holmes), но почти наверняка тысячи раз видели результат их работы. Этот результат видели все люди, оставлявшие телевизор включенным на любом кабельном канале без трансляций по 24 часа в сутки. А иногда его можно было увидеть, когда на канале возникали неполадки и требовалось чем-то заполнить время трансляции. В начале 1950-х Ларки и Холмс изобрели один из самых известных тестовых паттернов, известных миру. Он вам знаком — это таблица из ярких цветных полос, которые сложно не заметить. Сегодня мы расскажем вам о ней и о других телевизионных тестовых паттернах.

Однажды мне нужно было протестировать ответ сервера и я решил что использовать для этого тяжеловесные швейцарские ножи вроде PhpUnit — обременительно. Осложнялось все тем — что инфраструктура была разбита на множество веб-микросервисов, которые в свою очередь работали на разных бэкендах(PHP, NodeJS, Python, GO). Посему я решил набросать простой класс, который на удивление оказался очень удобным инструментом для приемочного тестирования системы.

— Нам нужно быть уверенными что при каждом пуше у нас не сломается вся инфраструктура, сможешь сделать? -Легко!

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

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

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

Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных X5 Retail Group. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.

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

В настоящий момент наиболее популярными инструментами тестирования являются Gatling, MF LoadRunner, Apache JMeter. Все они обладают возможностями как генерации готовых отчетов по проведенному тестированию, так и отдельных графиков или сырых данных, на основе которых строится уже сам отчет.

На днях ресурс Phoronix опубликовал результаты тестов скорости работы разных дистрибутивов Linux на системе с Core i9 10980XE.

Тестирование проводилось со сборками Clear Linux 33540 (самая новая на момент теста), Clear Linux 31480 (конец 2019 года), Endeavour OS Rolling, openSUSE Tumbleweed 20200727, Debian Buster Testing, Ubuntu 20.04 LTS и тестовая сборка Ubuntu 20.10.

Подробности тестирования — под катом.

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

Как это работает?

В апреле 2020 года под руководством директора по сервису и клиентскому опыту Дарьи Юрасовой стартовал проект «Агенты Okko». Это сообщество пользователей, цель которого – сделать сервис лучше, привлекая действующих пользователей Okko к тестированию продукта.

Сообщество помогает находить проблемы удобства использования и выявлять технические недочеты платформы. Для этого предусмотрено 2 направления тестирования – юзабилити и техническое.

«Агенты Okko» тестируют сервис в различных форматах: онлайн-опросы, удаленные немодерируемые тесты, индивидуальные интервью и другие.

Как пользователи становятся Агентами?

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

Пользователи, прошедшие отбор, добавляются в сообщество, в котором они делятся опытом, общаются и задают вопросы по сервису. Приглашения на исследования участники получают по почте или с помощью каналов группы в Telegram и WhatsApp.

Пользовательские данные не являются разменной монетой. Компания Apple потратила значительные усилия для того, чтобы заслужить себе репутацию, стойко отбиваясь от ФБР и прочих представителей силовых структур, ищущих возможность произвольного сбора данных владельцев iPhone.

В 2016 г. Apple отказалась ослабить защиту iOS для того, чтобы ФБР могла разблокировать iPhone стрелка из Сан-Бернардино. Завладев смартфоном Сайеда Фарука и промахнувшись десять раз с набором четырехзначного PIN кода, правоохранители тем самым заблокировали смартфон. Тогда в ФБР потребовали, чтобы Apple создала специальную ОС, в которой возможно подобрать код безопасности методом перебора…

Привет, меня зовут Тимур, и я написал QA Game от SEMrush. Вы могли слышать об этой игре, если участвовали в Heisenbug online или видели анонсы игры в Telegram-чатах для тестировщиков. Если коротко, то в QA Game нужно проходить уровни с нарастающей сложностью и отлавливать баги, используя JavaScript.

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

Когда вы разрабатываете новый функционал с использованием базы данных, цикл разработки обычно включает следующие этапы (но не ограничивается ими):

Написание SQL миграции → написание кода → тестирование → релиз → мониторинг.

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

Поскольку мы в компании работаем с PostgreSQL, а серверный код пишем на Java, то примеры будут основаны на этом стеке, хотя большинство идей не зависят от используемой БД и языка программирования.

Всем доброго времени суток! Свою дебютную статью на habr хочу посвятить весьма интересной теме – системе контроля качества сети Интернет RIPE Atlas. Частично поле моих интересов затрагивают вопросы исследования Интернета или киберпространства (термин стремительно набирает популярность, особенно в научных кругах). Материалов по RIPE Atlas в интернете, в том числе на habr, предостаточно, но мне они показались недостаточно целостными. По большей части, в статье использовалась информация с официального сайта RIPE Atlas и собственные соображения. Время для чтения — 8 минут.

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