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

В своей книге "Методы тестирования программного обеспечения" Борис Бейзер описывает парадокс пестицидов. В контексте тестирования программного обеспечения - независимо от того, какой метод тестирования вы выберете, вы все равно пропустите более незаметных “вредителей”, то есть баги.

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

Как же с этим справиться? Расширить охват тестирования, добавив в свой процесс фаззинг.

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

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

Около 90% наших проектов связаны с доменом, поэтому сначала поговорим про работу с Active Directory. Начнем с терминологии и затем перейдем к практике.

В Bazel есть две крайне полезные фичи: stamping — позволяет встроить в артефакт данные о том, от какого коммита можно собрать аналогичный артефакт и remote cache и remote build — позволяет иметь общий кэш между сборщиками или даже собрать артефакты на ферме.

Ранее, к сожалению, эти фичи были взаимоисключающими, но с версии Bazel 7.0 можно использовать stamping с remote cache при помощи scrubbing-а. А сегодня вышла версия Bazel 7.1, в которой появилась возможность использовать stamping с remote build.

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

После нескольких попыток на другом конце провода ответили. Взволнованный Стив Возняк, едва сдерживая смех, произнес: «Это Генри Киссинджер, я должен немедленно поговорить с Папой Римским. Я должен признаться в своих преступлениях». 

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

13 февраля 2024 года компания Microsoft выпустила предупреждение для своих пользователей о критической уязвимости в пакете Office, которая позволяет злоумышленникам удаленно выполнять вредоносный код.

Уязвимость затрагивает несколько продуктов Microsoft Office, включая приложения 365 Enterprise, Office 2016 и 2019, а также Office LTSC 2021.

Уязвимость была обнаружена исследователями компании Check Point и получила идентификатор CVE-2024-21413.

Check Point в своем отчете объясняют, что уязвимость, которую они назвали "Moniker Link", позволяет обойти встроенные средства защиты Outlook от вредоносных ссылок в электронных письмах. Для этого используется протокол file:// и специальный символ ! в ссылке для доступа к удаленному серверу злоумышленников.

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

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

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

Привет друзья! Я Александр Леонов, и вместе с отделом аналитиков Positive Technologies мы подготовили для вас дайджест трендовых уязвимостей за прошедший месяц.

Вы, наверно, сразу спросите: а что это за уязвимости такие — трендовые? Это опасные уязвимости, которые активно используются в атаках или с высокой вероятностью будут использоваться в ближайшее время.

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

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

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

Расскажем, как разрабатывали фирменный тестовый пакет test-suite, с какими проблемами столкнулись и как мы их решили. Также покажем наши стенды, на которых тестируем все выпускаемые продукты.

Интересно? Ныряйте под кат.

Привет, Хабр! Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

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

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

В известном смысле это основы тестирования, но по моему опыту как раз из-за этого (“это база, ну что там может быть такого”) о подобных вещах на практике забываешь чаще, чем хотелось бы. К тому же в любом домене есть свои тонкости, в случае проверки систем оплат – налоги, чеки, возвратные чеки, регионы, экономические зоны. Кажется, для насмотренности может быть полезно разобраться, как тест-дизайн адаптируется под эти нюансы. 

Приступим!

Интересуетесь, как ускорить автоматизированные UI тесты? Узнайте эффективные и действенные советы, которые помогут вам быстрее и эффективнее выполнять UI автотесты.

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

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

Труднее всего тестировщику приходится в ситуациях, где даже не подозреваешь, что действуешь неправильно.

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

Привет, Хабр! Меня зовут Катерина. Недавно я опубликовала подборку ресурсов для питонистов и, поскольку ее неплохо приняли, решила поделиться еще и ресурсами для QA-специалистов. Я не систематизировала их по важности или популярности, просто разбила на статьи, YouTube- и Telegram-каналы.

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

Значение тестирования

1. Обеспечение соответствия требованиям: Тестирование помогает убедиться, что программное обеспечение соответствует всем функциональным и нефункциональным требованиям, выдвигаемым заказчиками или пользователями продукта. Это обеспечивает, что программное обеспечение выполняет только необходимые функции и работает в соответствии с ожиданиями.

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

В software-разработке с автоматизацией обычно все неплохо: более-менее понятно, как настроить CI и автоматизировать отдельные этапы CI-конвейера. Есть множество готовых решений и практик. Но, когда речь заходит об автоматизации тестирования на «железе», появляется множество нюансов. Например, не всегда понятно как автоматизировать процессы, которые обычно делают люди, — банальную перезагрузку устройства в другом городе. Или другая особенность — целевые аппаратные ресурсы масштабируются не так хорошо, как софт, поэтому приходится придумывать свои подходы к распределению времени доступа к стенду для СI-конвейеров и инженеров.

Меня зовут Игорь Большевиков, я инженер по системному программированию систем на кристалле в YADRO В статье я расскажу о нашем опыте автоматизации процессов, связанных с разработкой на FPGA-стенде: удаленной загрузке плат, бронировании аппаратных ресурсов и решении вопросов по координации для распределенной команды. Я опишу ключевые этапы задачи без лишних технических деталей. Возможно, статья будет полезна тем, кто занимается или кому предстоит заняться автоматизацией работ с FPGA.

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

«Дедушка российского тестирования», тестировщик с 50-летним стажем Александр Александров объясняет, почему классическая научная литература по тестированию по-прежнему актуальна и с каких основополагающих текстов стоит начинать свой путь в этой профессии.

Всем привет! Я Настя — QA команды, которая занимается развитием и поддержкой публичного API hh.ru. В этой статье расскажу, как мы проверяем OpenAPI-документацию в тестах при помощи автогенерации классов и валидации.

Всем привет! Меня зовут Артём. Последние два с половиной года я активно ввожу за руку ребят в мир IT через плоскость тестирования веб-систем. Не так давно, используя накопленный опыт и практику я создал собственный курс, где обучаю ребят любых возрастов тестированию с нуля.

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