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

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

В нашем арсенале более 150SKU умной техники, которой можно управлять через приложение на смартфоне. Для корректной работы и выполнения всех функций мало сконструировать девайс, нужно его хорошенько протестировать. Разумеется, по одному экземпляру невозможно сделать вывод о качестве всей партии продукции, а значит, проводить все манипуляции вручную крайне ресурсозатратно. Так какой же выход?

Мы решили, что лучше всего создать инструмент, который позволит максимально избавить все процессы от ручных проверок. Таким инструментом стали стенды автоматического тестирования (САТы).

Это уникальный проект компании Ready For Sky. САТы разрабатываются, чтобы значительно сэкономить рабочее время отдела тестирования и при этом увеличить результативность и качество.

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

При построении автоматизации функционального тестирования (АФТ) в разных командах, проектах, компаниях могут возникать одни и те же проблемы, универсального решения которых не существует. Я, Василий Соколов, руководитель направления разработки ИТ-решений ДОМ.РФ, расскажу, как мы два года назад начали строить АФТ и каких результатов удалось достичь.

Всем привет! Это команда тестирования производительности Тинькофф, и мы продолжаем цикл статей о Gatling. 

В предыдущей статье мы рассмотрели базовые возможности инструмента Gatling, узнали, как быстро создать шаблон gatling-проекта, и познакомились с новыми функциями библиотеки gatling-picatinny. Сегодня расскажем, как при помощи этих инструментов создать проект для тестирования HTTP-протокола.

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

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

Меня зовут Максим Бугров, я больше 8 лет работаю в тестировании ПО. На Московскую Биржу я пришел летом 2021 года на позицию начальника отдела тестирования. Наш департамент преимущественно разрабатывает софт, который связывает клиентов и торгово-клиринговые системы Биржи. И я расскажу, как мы начали превращать мороженку в пирамиду — нас ждал огромный ледник задач.

Всем привет, до этого не было дайджестов для QA инженеров, я решил закрыть эту нишу, присылайте интересные статьи и будем делать дайджест вместе!

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

Я работаю уже 10 лет в компании Тензор, за это время число тестировщиков приблизилось к четырём сотням. И все эти 10 лет у нас в компании проводились различные хакатоны для студентов, соревнования для разработчиков, наши безопасники участвовали в CTF, проводились конкурсы на лучшее фото из отпуска, турниры по настольному теннису, шахматам, волейболу, пауэрлифтингу... Ну вы поняли. Всё что угодно, но не соревнования, в которых можно померяться своим навыком в нахождении ошибок. Причём не геймификацию процесса, не дружеские посиделки с ноутбуками, а по-хорошему злые забеги. Собственно такие соревнования мы и организовали и успешно проводим второй год подряд (2020 не считается за год :)). О нашем опыте, сложностях, удачах и выводах  как раз и хочу рассказать.

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

Стандартный вариант

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

Друзья, всех приветствую!

В этой статье я покажу вам как использовать airmon-ng (скрипты из пакета aircrack-ng) для обнаружения беспроводных сетей вокруг нас. Затем мы деаутентифицируем клиентов определенной беспроводной сети, чтобы перехватить handshake, а затем расшифруем его, чтобы найти пароль WiFi.

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

Прежде чем приступить к работе, давайте посмотрим, что нам понадобится.

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

Так, при разработке API нашей команде довелось сверять в тестах многомерные массивы, которые занимают несколько экранов. Наличие этих массивов в коде теста сделало бы разработку и чтение тестов крайне неудобными, поэтому появилась необходимость вынести тестовые данные из кода теста. При этом вынести их надо недалеко от самого теста, чтобы разработчику было удобно просматривать и редактировать эти данные.

В результате был написан скрипт, который позволяет извлекать массивы данных из php-файлов, а также из обычных текстовых файлов, и подставлять эти данные в код теста. Позже этот скрипт был оформлен в php-пакет test-data-provider.

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

Как часто видите вы рекламу различных курсов, предлагающих за скромную разумную плату обучиться "перспективнейшей востребованной специальностью" тестировщика и зарабатывать от 100500 тыщ в месяц? А сколько ваших знакомых, прошедших такие курсы, смогли трудоустроиться и зарабатывать хотя бы 30 тыс. рублей на первых порах? Расскажу о собственной статистике - из 10 пришедших с курсов только 2 трудоустраиваются. Остальные, чаще всего, возвращаются к профессии, из которой планировали уйти.

Почему так происходит? Все просто! Во-первых, чаще всего курсы покупают те, кто не способен/не хочет искать информацию самостоятельно. Для таких людей курсы что-то вроде золотого билета в мир больших зарплат айтишников и удаленки. Во-вторых, люди, которые предпочитают курсы, потому что они сильно мотивируют. От многих я слышал подобные фразы - "Сам не могу себя заставить учиться, а потраченные деньги сильно мотивируют". Для многих это основополагающий фактор в покупке курсов. Опять же, если вы не интересуетесь темой, которую изучаете, вам нужна дополнительная мотивация к действиям, тогда есть смысл задуматься - а надо ли оно вам вообще?! Если такой человек все же попадает на работу, он или очень быстро выгорает, или топчется на одном уровне, пока ему не предложат повышение/увольнение, или через месяц-другой сам увольняется.

Всем привет! Меня зовут Андрей Попов, я Middle QA Engineer Auto-test в Утконос Онлайн. В этой статье хочу поделиться, почему мы выбрали Apache JMeter для нагрузочного тестирования, как выглядит этот инструмент, для чего он был нам нужен, и как мы используем его для нестандартных задач. Поехали.

Часто пользователи рассказывают о сбое базы данных по вине Out Of Memory Killer. Он завершает процессы PostgreSQL и остается причиной большинства отказов этой БД. Память на хост-компьютере может закончиться по нескольким причинам. Наиболее распространены из них четыре. Во-первых, может быть плохо настроена память на хост-компьютере. Во-вторых, могут быть ограничения глобальной переменной work_mem. Например, если у вас 32Гб RAM и work_mem=1Гб, то больше 32 соединений вы никогда не запустите. Каждое соединение PostgreSQL будет выделять этот размер памяти.

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

Представляем вам перевод статьи от Jobin Augustine, который работает в Percona старшим инженером службы поддержки. Более 20-лет он был консультантом, архитектором, администратором и инструктором по PostgreSQL, Oracle и другим технологиям баз данных. Сегодня поговорим о том, как можно защититься от OOM с помощью HugePages и разберем насколько они важны и почему нужны.

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

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

Задачи стали проходить тестирование быстрее. Я просто добавил на сервер...

Здравствуйте! Под катом, опыт небольшой команды из Челябинска, которая делала релизы не вовремя, а потом изобрела велосипед. Если вы только строите процессы или вас мучает совесть из-за отложенных релизов, возможно этот опыт пригодиться. Также буду рад критике. Добро пожаловать!

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

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

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

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

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

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