Русский
Русский
English
Статистика
Реклама

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

Cypress и его место в нашей тестовой пирамиде

18.05.2021 08:17:48 | Автор: admin

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

Введение в Cypress

Если отбросить капитанское определение, что Cypress это JavaScript-фреймворк для тестирования, то важно отметить, что при работе с ним мы видим на экране браузер. Он не обязательно открыт, он может быть headless, но он есть, и он открывает особое приложение самого Cypress, которое состоит из нескольких фреймов: в одном фрейме открывается продукт, который мы тестируем, в другом фрейме запускаются тесты. Код тестов пишется на JavaScript, поэтому они могут выполняться непосредственно в браузере ведь это нативный для него язык.

Так с помощью JavaScript API производятся все манипуляции, которые делаются в тестах, то есть заполнение форм, клики и тому подобное.

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

Нет Selenium WebDriver

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

Selenium WebDriver это third-party сервис на Java, который обращается к браузеру по WebDriver протоколу. Это накладывает ограничения на работу с браузером в рамках протокола. Сетевое взаимодействие также вносит свой вклад во время выполнения тестов.

Изначально Selenium был создан не специально для тестов, а как общий инструмент автоматизации для браузера. Cypress, в отличие от него, сфокусирован на решении конкретной задачи, а именно, на создании end-to-end (е2е) тестов для интерфейса web-приложений.

Все в одном

Cypress не нужно собирать из кусочков он принес все достаточно современные "батарейки" с собой:

  • Синтаксис BDD (унаследовано из Mocha): describe(), context(), it().
    А также хуки: before(), beforeEach().
    Использовать такой DSL привычно для тех, кто уже писал юнит-тесты на JavaScript.

  • Библиотека ассертов (унаследовано из Chai). Например:
    expect(name).to.not.equal("Jane") ожидание того, что элемент не существует это не то же самое, что ожидание неудачи при проверке существования элемента. Если элемента нет, то это хорошо, это не нужно перепроверять, а нужно идти дальше.
    Такую задачу должен решать тестовый фреймворк, и этого нам очень не хватало в старой самописной библиотеке, при использовании которой многое ложится на плечи разработчика теста.

  • Перехват, отслеживание (spy) и подмена (mock) запросов браузера к бэкенду.

Development experience

Главное преимущество Cypress это отличный development experience. Написать первый тест для своего проекта (неважно, на каком языке написан сам проект) можно минут за 10. Потребуется добавить одну зависимость в package.json (npm install cypress), прочитать документацию про то, куда складывать файлы (cypress/integration/login.spec.js), и написать код в 5 строчек:

describe('Login', () => {it('should log in with credentials', () => {cy.visit('/login');cy.get('[name=login_name]').type(Cypress.env('login'));cy.get('[name=passwd]').type(Cypress.env('password'));cy.get('[name=send]').click();cy.get('.main-header').should('be.visible');});});

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

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

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

Одна из Best Practices говорит, что не нужно никогда писать таймаут типа "подождать 2 секунды". Абсолютно все таймауты должны ждать чего-то осязаемого, например, окончания Ajax-запроса. Можно подписаться на событие, которое случается в коде продукта. Например, когда нам через веб-сокет прилетает событие с бэкенда, то срабатывает определенный listener на фронтенде.

Вся документация Cypress и Best Practices находятся на одном сайте docs.cypress.io хотелось бы отдельно отметить высокое качество этой документации, а также мастер классов, которые команда разработки Cypress проводит и публикует в открытом доступе.

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

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

Тестовая пирамида

Когда говорят про тестовую пирамиду, то обычно приводят в пример анти-паттерн "перевернутая пирамида" или "стаканчик мороженого". То есть на нижнем уровне в таком примере количество юнит тестов стремится к нулю. Лично мне этот случай кажется невероятным для зрелого проекта: ведь в этом случае разработчики должны были полность отказаться писать самые простейшие тесты откуда тогда взялись сложные е2е тесты?

Как бы то ни было, к нам это не относится у нас несколько тысяч PHPUnit-тестов с покрытием около 12% строк кода.

В то же время у нас есть еще несколько тысяч е2е-тестов с Selenium, которые проверяют все возможные конфигурации продукта, занимают кучу времени (подмножество, запускаемое на каждый коммит, мы смогли оптимизировать до 40-60 минут), имеют довольно слабый уровень доверия (с вероятностью 30-40% тесты упадут, хотя коммит не содержит причины этого падения) и покрывают около 30% строк кода.

Получается, наше положение выглядит, как песочные часы нам не хватает среднего слоя в тестировании, где интеграционные тесты проверяют компоненты системы независимо друг от друга. Это горлышко песочных часов и хочется заполнить с помощью Cypress. При этом еще хочется что-то сделать с существующими е2е тестами, чтобы "заострить" вершину пирамиды. То есть, важный акцент здесь в том, что Cypress не является заместителем старого фреймворка: мы не хотим просто взять и переписать все тесты на Cypress иначе мы так и останемся на шарике мороженого. Цель тестов по-прежнему, проверять регрессию в продукте, но проверять на другом уровне, чтобы выполняться быстрее и получать результат раньше, а также быть легче в сопровождении.

Наш подход к написанию тестов

Проект, о котором идет речь, это контрольная панель Plesk. Она предоставляет пользователям интерфейс для управления хостингом веб сайтов. Функциональность панели доступна не только через UI, но и через API и CLI, которые используются для автоматизации.

Мы начали с того, что сделали следующие предположения:

  • Тесты на Cypress относятся чисто к UI. Мы не относим сюда тесты, у которых шаги выполняются через API или CLI.

  • Мы не проводим никакой дополнительной валидации, кроме той, что выполняется средствами UI. Например, если мы проверяем создание домена, то мы не отправляем запросы для проверки Web-сервера или DNS, мы считаем тест пройденным, если в UI появилось сообщение на зеленом фоне о том, что домен создан успешно. Такой подход избавляет нас от предварительной подготовки и написания тестовых сценариев.

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

Наш опыт работы с Cypress в сочетании с официальными рекомендациями привел нас к использованию следующего набора практик:

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

Мы сбрасываем состояние продукта до исходного перед запуском каждого набора тестов (Cypress рекомендует делать это перед запуском каждого теста, но мы используем облегченный вариант). Мы создаем дамп базы данных и восстанавливаем его перед прогоном каждого набора тестов (test suite / spec). Это занимает порядка 5 секунд.

before(cy.resetInstance);//=> test_helper --reset-instance//=> cat /var/lib/psa/dumps/snapshot.sql | mysql

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

Использовать фикстуры

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

cy.setupData(subscription).as('subscription');//=> test_helper --setup-data < {domains: [{ id: 1, name: "example.com" }]}

Такие объекты не будут выполнять полноценные пользовательские сценарии, но для тестирования UI их будет достаточно.

Использовать прямые URL

Мы не используем навигацию и попадаем в нужные места UI по прямым URL-ам. Мы вызываем свою специальную команду login, которая создает сессию, а затем переходим прямо на нужную страницу.

beforeEach(() => {cy.login();cy.visit('/admin/my-profile/');});

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

Фронтенд без бэкенда

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

const lastChecked = 'Jan 29, 2021 04:42 PM';cy.intercept('POST', '/admin/home/check-for-updates', {status: 'success',lastChecked,newVersion: null,whatsNewUrl: null,}).as('checkForUpdates');cy.get('[data-name="checkForUpdates"]').click();cy.wait('@checkForUpdates');cy.get('[data-name="lastCheckedDate"]').should('contain', lastChecked);

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

Стабильность тестов

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

Дожидаться выполнения Ajax-запроса

Многие формы в нашем продукте отправляются с помощью Ajax-запросов без перехода страницы. Чтобы тест гарантированно прошел, необходимо перехватить этот запрос и дождаться его завершения. Так как в Cypress мы проверяем только то, что происходит в UI, мы дожидаемся нужного нам сообщения.

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

cy.intercept('POST', '/admin/customer/create').as('customerCreate');cy.get('[name=send]').click();cy.wait('@customerCreate');cy.get('.msg-box.msg-info').should('be.visible');

Дожидаться исчезновения индикатора загрузки

Кое-где в нашем интерфейсе фоновые операции, например, обновление списка, сопровождаются анимированным индикатором загрузки ("крутилкой"). Именно на таких страницах после окончания Ajax-запроса случается ошибка "element has been detached from the DOM" при попытке Cypress кликнуть на элементы списка. Поэтому мы добавляем после Ajax-запроса дополнительную строку, которая проверяет, что индикатор загрузки не виден.

cy.get('.ajax-loading').should('not.be.visible');

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

Ajax-запросы после окончания теста

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

До того момента, когда следующий тест сделает первый вызов "cy.visit()", предыдущая страница остается открытой и может отправлять Ajax-запросы (например, периодическое обновление), которые будут падать из-за ошибки авторизации (куки нет, сессии нет).

В качестве workaround можно переходить на пустую страницу, чтобы браузер сбрасывал все активные Ajax-запросы. Для этого добавляем в support/index.js

afterEach(() => {cy.window().then(win => {win.location.href = 'about:blank';});});

Первые результаты

За 3 человеко-месяца (3 итерации) мы получили следующие результаты:

  • 335 тестов на Cypress (разбиты на 84 спеки)

  • Пайплайн полностью выполняется за 35-40 минут, из которых сами тесты занимают 20 минут

  • Запуск пайплайна на каждый пулл-реквест в блокирующем режиме (то есть нельзя мержить без успешного прохождения тестов)

  • Уровень доверия выше 95% (то есть вероятность flaky падения ниже 5%)

  • Покрытие интерфейса 35% (ниже расскажу подробнее)

Пайплайн для запуска тестов

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

Как и для большинства наших задач, пайплайн запускается в Jenkins и хранится в Jenkinsfile вместе с кодом проекта.

Линейный пайплайн

В первом заходе получился простой линейный пайплайн.

Мы запускаем Docker-контейнер с Plesk в фоновом режиме и ждем, когда он будет доступен в локальной сети. Потом запускаем другой контейнер с Cypress и кодом тестов, он подключается к Plesk и выполняет все тесты, а мы ждем его завершения (не делаем detach).

Мы запускали тесты на машине с 12 ядрами, которая используется у нас для сборки Plesk и ряда его служб. В течении рабочего дня у нас бывает до 20-30 сборок. В результате Load Average достигал 20, и многие соседние процессы "вставали". Мы добавили ограничение на количество исполняемых сборок до 3-5. Но и этого оказалось недостаточно, соседи по железу продолжали жаловаться на нагрузку.

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

Пайплайн с параллельными шагами

Чтобы как-то ускорить процесс, мы решили воспользоваться Jenkins EC2 Fleet plugin, который предоставляет Jenkins slave ноду по требованию из Autoscaling Group в AWS и уничтожает неактивные ноды после некоторого простоя. Такой подход позволяет тратить деньги на аренду ресурсов только тогда, когда они необходимы.

Переход на spot-инстансы позволил нам существенно сэкономить: вместо $150 в месяц за ondemand c5.xlarge, мы стали тратить около $60 за c5.xlarge и более мощные c5.2xlarge.

А главное, мы можем делать столько одновременных запусков, сколько нам нужно.

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

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

Пайплайн с параллельными тестами

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

cypress run --spec $(find 'cypress/integration' -type f -name '*.js' | awk '(NR - ${RUNNER}) % ${TOTAL_RUNNERS} == 0' | tr '\n' ',')

Получилась матричная сборка, где для каждой оси (axis) запускается свой контейнер с Plesk и свой контейнер с определенным набором тестов.

В итоге мы укладываемся в приемлемые 35-40 минут для всего пайплайна, а время одной пачки тестов занимает примерно 20 минут.

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

Измерение URL coverage

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

Для анализа тестового покрытия UI мы решили воспользоваться продуктовой аналитикой и сравнить данные, полученные от тестовых инсталляций, с данными от реальных пользователей. У нас уже был сервис, аналогичный Google Analytics, для сбора пользовательских метрик, а тестовые данные складывались отдельно и никем не использовались. Из множества метрик мы отфильтровали события о посещенных URL-ах (страницах) продукта, начали сохранять эти данные в удобном для нас виде в базу данных и составлять отчет по посещенным адресам.

По полученным данным, за счет всего автоматического и ручного тестирования внутри компании мы покрываем около 60% URL-ов, которые посещают реальные пользователи в течении месяца. Наши старые тесты покрывают около 25%, а новые тесты на Cypress уже достигли 35%.

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

Следующие шаги

Ускорить сборку Docker

Одна из проблем, над которой мы хотим поработать ускорение сборки контейнеров Docker. Как уже было сказано выше, мы создаем временный сервер в AWS (slave node) для каждой сборки Docker, и эта сборка на данный момент занимает в среднем 8 минут. Но поскольку каждый временный сервер новый, то мы совершенно не используем преимущества кэширования, а хотелось бы ими воспользоваться. Поэтому сейчас мы исследуем возможность использования BuildKit. Альтернативными решениями могут стать Kaniko или AWS CodeBuild.

Сократить количество е2е тестов

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

Основная идея: перенести все UI-тесты в Cypress, а в старом фреймворке оставить только CLI-тесты с детальными проверками. Поэтому для каждого UI-теста из старого фреймворка мы делаем следующее:

  1. Заменяем UI-шаги на CLI (если это возможно).

  2. Удаляем, если уже есть аналогичный тест с CLI.

  3. Если проверка возможна только через UI уносим ее в Cypress.

Например, при создании домена проверяется то, что он резолвится, и что на нем работают определенные скрипты. Эти проверки останутся только для создания домена через CLI. А тест на UI в Cypress будет проверять только появление сообщения о создании домена.

В результате мы избавимся от дублирования тестовых сценариев, сократим нагрузку на сервера с Selenium и в перспективе совсем от них избавимся, когда тестирование UI будет делать только Cypress.

Заключение

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

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

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

Подробнее..

Настраиваем нагрузочное тестирование с Artillery.io

30.05.2021 02:08:09 | Автор: admin

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

Шаг 1. Установка

npm install g artillery@latest

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

npm i artillery-plugin-expect

Шаг 2. Создаем config

Target url, environment

Файл конфигурации нагрузочного тестирования это все, что нам нужно сделать для запуска тестов:

config:  target: "https://yourapp.com/api"

Если вам нужно использовать разные environment в ваших тестах, они прописываются сразу после target url:

config:  target: "https://bestapp.com/api"  environments:    dev:      target: "https://bestapp.dev.com/api"    qa:      target: "https://bestapp.qa.com/api"

Фазы тестирования

Инструмент artillery позволяет использовать несколько вариантов последовательных нагрузок на ваше приложение. Фаза тестирования состоит из: duration время одной фазы; arrivalRate количество пользователей, добавляемых каждую секунду; ramptTo до какого количества пользователей в секунду будет нарастать нагрузка; name - имя для обозначения ваших фаз.

phases:    - duration: 30      arrivalRate: 1      rampTo: 20      name: test1

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

Плагины

Добавляем плагин для ожидаемого результата:

plugins:    expect: {}

Авторизация

Инструмент поддерживает базовую авторизацию с помощью username и password:

- get:    url: "/auth"    auth:      user: username      pass: password

Также можно вставить свой авторизационный header:

- post:    url: "/auth"    headers:      Authorization: Basic secretKey

Шаг 3. Первый тест

Все тесты пишутся в разделе scenarios. Каждый сценарий имеет название, метод (GET, POST, PUT, DELETE и др.), url для каждого endpoint, body в формате json, а также необходимые проверки.

Пример простого теста:

scenarios:    - name: "My first test"       flow:         - post:            url: "/endpoint1"            json:              id: value        expect:           - statusCode: 200          - contentType: json           - equals:              - respMessage: "OK"

В equals добавляются все проверки, основанные на ответе вашего бэкэнда.

Шаг 4. Запуск тестов

Запуск нагрузочных тестов очень простой:

artillery run yourConfig.yml

Эту строку можно добавить в раздел scripts в package.json для быстрого запуска тестов.

-e <env> - запускает тесты для различных environment,
--quiet убирает все полученные результаты из консоли,
-o result.json добавляет результаты тестирования в файл отчета.

Создание html отчета

Отчет создается буквально в одну строку:

artillery report result.json

Сравнение с K6

Главное преимущество artillery это очень легкая настройка первого запуска тестов. Не надо переписывать тесты в формате, определяемом для K6, не надо писать bat-файл для того, чтобы запускать несколько тестов и сохранять результаты в отдельную папку. Достаточно сконфигурировать один файл.

Artillery работает с node.js, поэтому скрипт для запуска можно вставить в package.json.

Можно импортировать переменные из cvs-файла, брать переменные из полученного результата.

Отчет с графиками и диаграммами добавляется в одну команду и входит в бесплатную версию artillery.

Подробнее..

Веб-сервис для психотерапии депрессии и болей в рекламе и маркетинге

21.05.2021 12:08:14 | Автор: admin

У меня скоро день рождения и я решил таки дописать статью, которую задумал лет 8 назад. Лучше поздняк пометаться, чем никогда, да и закрыть гештальт напрочь. Хотя сейчас мне нужно продолжать писать свои и чужие патенты, стартапы и статьи научные всякие, но очень хочется поделиться тем, что я вижу отчётливо, а другие не используют для полезностей и soft skills. Потом я ещё расскажу, что лечит боли клиентов на самом деле, без поверхностного подхода.

Не буду открывать USA, но всем ясно, что каждый самый хороший продаван, хоть на рынке у трассы или в Белом Доме или в автосалоне Bentley это великий психолог, если без непотизма, конечно. Самые успешные люди умеют понимать других и воздействовать на людей лучше остальных, иногда врождённо или бессознательно. Все самые популярные книги в рекламе и маркетинге написаны в реале психотерапевтами, которые называют себя почему-то всякими консультантами. По сути и кратко гутаря социальный и эмоциональный интеллекты для продаж важнее логики и IQ и поэтому почти все ненавидят чат-ботов (кроме тех, кто их делает и втюхивает, конечно).

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

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

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

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

Моя же родная аутогенная тренировка состоит и 2 основных групп методик релаксация и концентрация. Релаксация это способы повышения активности парасимпатической вегетативной неровной системы, что приводит к чувству покоя, расслабона, кайфа и рекреации вообще. Вопрос часто ли используют в рекламе креативщики образ отдыха, релакса и удовольствия? Удовлетворенность (Customer Satisfaction, CSAT) же - это таки из психологии, не?

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

А когнитивная терапия, особенно депрессии, построена на понятиях научение и на изменении нелогичных или нецелесообразных мыслей и убеждений человека. Что вообще всегда делает реклама, если не переучивает человека, предлагая ему новые убеждения и мысли? Вставляя в мозг хорошее) Ну и маркетинг также, обучает покупать самое правильное для удовлетворённости) Очень яркий аналог - это всем известная лояльность клиентов разве это не любовь и доверие к бренду или товару-услуге, которые через условные рефлексы прививают специалисты по customer experience marketing? Они не психотерапевты, как бы, но занимаются именно лечением болей и депрессии)

Кстати говоря, популярная сейчас ещё книга Джозефа Пайна II и Джеймса Гилмора неправильно названа после перевода, теми же людьми, которые меняют названия американских фильмов в нашем кинопрокате. У них не Экономика впечатлений, а экономика опыта, тоже понятие из когнитивной терапии это. Я уж молчу о том, что Customer Journey Map это применение техник эмпатия и отзеркаливание, а Customer Satisfaction Index (CSI, индекс удовлетворенности клиентов) вообще классика точных измерений в психодиагностике и психотерапии, одно слово антидепрессивное satisfaction наглядно вопиет об этом научном понятии) И т.д. и т.п.

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

Ну и ещё много всяких случайных совпадений аналогичных. Например, в маркетинге есть такое понятие Net Promoter Score (NPS) инструмент выявления степени приверженности клиентов к бренду, опираясь на личный опыт (когнитивный то есть) потребителя. Сбор данных для NPS осуществляется преимущественно посредством проведения опросов (психодиагностических то есть методов). Далее клиентов разделяют на три категории критики, нейтралы, промоутеры и проводится расчет. Если получен отрицательный или нейтральный индекс, то необходимо срочно вносить коррективы для изменения уровня удовлетворенности, менять маркетинговую (психотерапевтическую) стратегию.

Поэтому, когда я осознал эти многочисленные все схожести, лет 10 назад ещё, то заявился с проектом ФидбекПрофит на митап Greenfield-project, но очень плохо провёл презентацию и меня отругали, что такое есть уже) Из-за всяких дел мне пришлось забыть это, как и многие другие свои родные инновации, но в этом году терпелка кончилась и я решил таки написать патент на изобретение по теме и сдал его 3 дня назад в Роспатент.

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

Изобретение относится к области рекламы, в частности, к методам оценки и коррекции эффективности рекламных кампаний. Способ оценки эффективности рекламы, отличающийся тем, что проводят верифицированное анкетирование и голосование для подсчёта рейтинга и оценки отдельных характеристик рекламы. Пользователи через систему, состоящую из мобильного или стационарного устройства отображения информации, с помощью программы для ЭВМ 2021617263 Feedback: diagnosis, rating, correction идентифицируются в личном кабинете (ЛК) через авторизацию OAuth 2.0.

Затем проходят затем дополнительно верификацию по одному из пяти уровней, имеющим последовательно и пропорционально номеру далее увеличивающуюся степень повышения коэффициента получаемого за голосование и отзывы вознаграждения бонусами через: 1) электронную почту или социальные сети, 2) номер мобильного телефона, 3) аккаунт на Госуслугах, 4) банковское приложение, 5) электронную цифровую подпись.

Там они заполняют раздел целей: мечты, желания, задачи, планы покупок, выставляют в ЛК для них три параметра: временные отметки, степень потребности и поиск решений. Затем через носимое вычислительное устройство с сенсорным экраном фотографируют с разрешением от 3264 на 2448 пикселей, снимают на видеокамеру с разрешением от 640 на 480 пикселей, наблюдаемое и происходящее в данный момент рекламное сообщение.

Дальше отвечают в мобильном приложении сервиса через психотерапевтический опросник, состоящий из семи вопросов о параметрах повышения (увеличения) или понижения (уменьшения) или без изменений после получения рекламного сообщения: 1) положительных эмоций бодрости, работоспособности и стеничности, повышения личной самооценки, 2) биофильных эмоций (любовь к природе, животным, детям, близким, друзьям, искусству, знаниям, здоровью, пище, сексу и т.д.), 3) антидепрессивного и противотревожного эффекта, 4) юмористического действия, в том числе пранки и сатира, 5) искренность, лояльность, приверженность и доверие к рекламируемому бренду, товару или услуге, 6) мотивации купить рекламируемый объект, 7) согласиться и сделать предлагаемое в рекламе.

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

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

И после чего происходит подсчёт всех голосов и рейтингов, имеющих верифицированные идентификаторы в БД всей системы, о данной рекламе за минуту, час, день, месяц и год с делением их на затраченные финансовые средства за такой же промежуток времени по формуле - КЭР=(Р1 + Р2 + Pn) / Сn, где КЭР коэффициент эффективности рекламы, Р1 рейтинг, набранный рекламой за 1 промежуток времени, Рn набранный рейтинг за дополнительные отрезки времени измерения эффективности, а Сn- общая сумма денежных средств, затраченных на создание и показ данной рекламы за изучаемый промежуток времени.

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

Способ по получаемым через интерфейс прикладного программирования параметрам использует специальные методики медицинской психологии, психиатрии, психодиагностики, client-centered и cognitive therapy, аутотренинга, психогигиены, санологии, экологии человека, для увеличения персонализации и верификации target group, lifetime value и покупок клиентов в краткосрочных и долгосрочных планах, улучшения omni-channel brand health, customer experience marketing, cross-device service blueprint, programmatic backstage adverts, addressable, connected и advanced television, увеличивая индивидуализацию и пользу рекламы для целей и покупок потребителей.

Как вам такой веб-сервис и мобильное приложение? Я его отправил в несколько компаний, чтобы улучшить и масштабировать, надеюсь, что прокатит. Много фидбека не бывает))

Подробнее..

Перевод Как байпасить reCaptcha V3 с помощью Selenium Python?

10.06.2021 16:07:13 | Автор: admin

*bypass - обход

Мы будем использовать библиотеку python Selenium для байпаса google reCaptcha v3. Следуйте пошаговой инструкции, чтобы получить результат.

Для примера мы будем использовать демо-версию Google reCaptcha api.

Здесь ссылка: https://www.google.com/recaptcha/api2/demo

Сначала необходимо отключить настройку защиты контента в браузере Chrome.

Для этого зайдите в Настройки в Chrome. И напишите "настройки сайта" в строке поиска.

Перейдите в настройки сайта и найдите "Защищенный контент".

Перейдите к защищенному контенту и отключите его.

Теперь перейдем к части кодирования.

В этой статье мы будем работать с Python 3. Мы будем использовать две библиотеки. Если вы хотите настроить Selenium и узнать, как это сделать - изучите эту статью: https://medium.com/@mrabdulbasit1999/selenium-with-python-web-automation-f85dfa2e58fa

Двигаемся дальше,

Установите библиотеку Beautiful Soup для скрипта.

pip install beautifulsoup4

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

from selenium import webdriverfrom selenium.webdriver.common.keys import Keysfrom webdriver_manager.chrome import ChromeDriverManagerfrom selenium.webdriver.common.by import Byfrom http_request_randomizer.requests.proxy.requestProxy import RequestProxyimport os, sysimport time,requestsfrom bs4 import BeautifulSoup

Установите "delayTime" и "audioToTextDelay" в соответствии с вашей скоростью интернета. Установленные значения работают для всех.

delayTime = 2audioToTextDelay = 10

byPassUrl - это URL, на который вам нужно ориентироваться. Опция используется для выбора драйвера chrome, и ей передаются некоторые аргументы.

filename = 1.mp3byPassUrl = https://www.google.com/recaptcha/api2/demo'googleIBMLink = https://speech-to-text-demo.ng.bluemix.net/'option = webdriver.ChromeOptions()option.add_argument('--disable-notifications')option.add_argument("--mute-audio")

Остальная часть кода приведена ниже. Теперь я объясню, как это работает.

Когда скрипт запускается, проверяется поле I'm not a robot.

И дальше все появляется (как обычно).

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

И появляется вот это. После этого загружается аудио с именем "1.mp3".

Это займет несколько секунд, не волнуйтесь. После этого в браузере откроется новая вкладка, которая перейдет от речи watson к конвертеру в текст и загрузит файл.

Как видите, аудиофайл преобразуется в текст. Он копирует текст и вставляет его в текстовое поле.

И далее нажимается кнопка "Проверить".

Вот, смотрите... Проблема решена. Если у вас есть какие-либо проблемы и вопросы, пишите. Я отвечу на них как только смогу.

Код


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

- Demo Day курса "Python QA Engineer"

- Demo Day курса "Java QA Automation Engineer".

Подробнее..

Как подружить Redis Cluster c Testcontainers?

20.06.2021 12:09:43 | Автор: admin
В 26-м выпуске NP-полного подкаста я рассказывал, что начал переводить один из своих сервисов из Redis Sentinel на Redis Cluster. На этой неделе я захотел потестировать данный код, и, конечно же, выбрал Testcontainers для этого. К сожалению, Redis Cluster в тестовых контейнерах не завелся из коробки, и мне пришлось вставить несколько костылей. О них и пойдет речь далее.



Вводные


Сначала я бы хотел описать все вводные, а потом рассказать про костыли. Мой проект построен на Spring Boot. Для взаимодействия с редисом используется Lettuce клиент. Для тестирования testcontainers-java с JUnit. Версия обоих редисов 6. В общем, всё типичное, нет ничего особенного с точки зрения стека.

Если кто-то еще не знаком с testcontainers, то пара слов о них. Это библиотека для интеграционного тестирования. Она построена на другой библиотеке https://github.com/docker-java/docker-java. Тестконтейнеры, по сути говоря, помогают быстро и просто запускать контейнеры с разными зависимостями в ваших интеграционных тестах. Обычно это базы данных, очереди и другие сложные системы. Некоторые люди используют testcontainers и для запуска своих сервисов, от которых зависит тестируемое приложение (чтобы тестировать микросервисное взаимодействие).

Про Redis Cluster


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

В целом, про Redis Cluster есть две замечательных статьи на официальном сайте https://redis.io/topics/cluster-tutorial и https://redis.io/topics/cluster-spec. Большинство деталей описано там.

Для использования Redis Cluster в testcontainers важно знать несколько вещей из документации. Во-первых, Redis Cluster использует gossip протокол поэтому каждый узел кластера имеет TCP-соединение со всеми другими узлами. Поэтому, между нодами должна быть сетевая связность, даже в тестах.

Вторая важная штука, которую надо знать при тестировании это наличие в Redis Cluster bootstrap узлов для конфигурации. То есть, вы в настройках можете задать лишь подмножество узлов, которые будут использоваться для старта приложения. В последствие, Redis клиент сам получит Топологию кластера через взаимодействие с Редисом. Исходя из этого, получается вторая особенность тестируемое приложение должно иметь сетевую связность с теми Redis URI, которые будут аннонсированы со стороны редис кластера (кстати, эти адреса можно сконфигурировать через cluster-announce-port и cluster-announce-ip).

Про костыли с Redis Cluster и testcontainers


Для тестирования я выбрал довольно популярный docker-образ https://github.com/Grokzen/docker-redis-cluster. Он не подходит для продакшена, но очень прост в использовании в тестах. Особенность этого образа все Редисы (а их 6 штук, по умолчанию 3 мастера и 3 слейва) будут подняты в рамках одного контейнера. Поэтому, мы автоматически получаем сетевую связность между узлами кластера из коробки. Осталось решить вторую из двух проблем, связанную с получением приложением топологии кластера.

Я не хотел собирать свой docker-образ, а выбранный мной image не предоставляет возможности задавать настройки cluster-announce-port и cluster-announce-ip. Поэтому, если ничего не делать дополнительно, при запуске тестов вы увидите примерно такие ошибки:

Unable to connect to [172.17.0.3/<unresolved>:7003]: connection timed out: /172.17.0.3:7003


Ошибка означает, что мы со стороны приложения пытаеся приконнектится к Узлу редис кластера, используя IP докер контейнера и внутренний порт (порт 7003 используется данным узлом, но наружу он отображается на какой-то случайный порт, который мы и должны использовать в нашем приложении; внутренний порт, по понятным причинам, не доступен из вне). Что касается данного IP-адреса он доступен для приложения, если это Linux, и он не доступен для приложения, если это MacOs/Windows (из-за особенностей реализации докера на этих ОС).

Решение проблемы (а-ка костыль) я собрал по частичкам из разных статей. А давайте сделаем NAT RedisURI на стороне приложения. Ведь это нужно именно для тестов, и тут не так страшно вставлять такой ужас. Решение, на самом деле, состоит из пары строк (огромное спасибо Спрингу и Lettuce, где можно сконфигурировать практически всё, только и успевай, как переопределять бины).

public SocketAddress resolve(RedisURI redisURI) {    Integer mappedPort = redisClusterNatPortMapping.get(redisURI.getPort());    if (mappedPort != null) {        SocketAddress socketAddress = redisClusterSocketAddresses.get(mappedPort);        if (socketAddress != null) {            return socketAddress;        }        redisURI.setPort(mappedPort);    }    redisURI.setHost(DockerClientFactory.instance().dockerHostIpAddress());    SocketAddress socketAddress = super.resolve(redisURI);    redisClusterSocketAddresses.putIfAbsent(redisURI.getPort(), socketAddress);    return socketAddress;}


Полный код выложен на гитхаб https://github.com/Hixon10/spring-redis-cluster-testcontainers.

Идея кода супер простая. Будем хранить две Map. В первой маппинг между внутренними портами редиса (7000..7005) и теми, что доступны для приложения (они могут быть чем-то типа 51343, 51344 и тд). Во-второй внешние порты (типа, 51343) и SocketAddress, полученный для них. Теперь, когда мы получаем от Редиса при обновлении топологии что-то типа 172.17.0.3:7003, мы сможем легко найти нужный внешний порт, по которому сможем найти SocketAddress и переиспользовать его. То есть, с портами проблема решена. А что с IP?

С IP-адресом всё просто. Тут нам на помощь приходят Тест контейнеры в которых есть утилитный метод DockerClientFactory.instance().dockerHostIpAddress(). Для MacOs/Windows он будет отдавать localhost, а для linux IP-адрес контейнера.

Выводы


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

23 июня, 1900 онлайн-митап QAчественное общение

15.06.2021 14:10:21 | Автор: admin

Привет!

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее..

Что такое База Данных (БД)

08.05.2021 22:04:46 | Автор: admin

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

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

Содержание

Что такое база данных

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

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

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

Но покупатели хотят новинок, разных размеров. Да и самих покупателей становится все больше и больше. В шкаф коробки уже не влезают!

Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.

Тогда Катька решила орендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система тут босоножки, тут сапоги...

Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.

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

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

Как она выглядит

Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:

Это называется реляционная база данных набор таблиц, хранящихся в одном пространстве.

Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:

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

Пример базы Oracle Пример базы Oracle

Цель та же выделить отдельное место, чтобы у вас не была одна большая свалка:

  • заходишь в папку в винде видишь файлики только из этой папки

  • заходишь в пространство видишь только те таблицы, которые в нем есть

Хранение данных в виде табличек это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички словно в excel каждая запись хранится в виде объекта, вот так:

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

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

Да, базы бывают разные. Классификацию можно изучить, можно выучить. Но по факту от начинающего тестировщика обычно нужно уметь достать информацию из реляционной БД (обычно != всегда, если что).

Как получить информацию из базы

Нужно записать свой запрос в понятном для базы виде на SQL. SQL (Structured Query Language) язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:

  • select выбери мне такие-то колонки...

  • from из такой-то таблицы базы...

  • where такую-то информацию...

Например, я хочу получить информацию по клиенту Назина Ольга. Составляю в уме ТЗ:

Дай мне информацию по клиенту, у которого ФИО = Назина Ольга

Переделываю в SQL:

select * from clients where name = 'Назина Ольга';

В дословном переводе:

select -- выбери мне* -- все колонки (можно выбирать конкретные, а можно сразу все)from clients -- из таблицы clientswhere name = 'Назина Ольга'; -- где поле name имеет значение 'Назина Ольга'

См также:

Комментарии в Oracle/PLSQL мой перевод остается работающим запросом, потому что я убрала лишнее в комментарии

Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:

  1. Открыть файл с нужными данными (clients)

  2. Поставить фильтр на колонку ФИО Назина Ольга.

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

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

А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:

id_order

order (таблица order)

fio (таблица client)

phone (таблица contacts)

1

Пицца Маргарита

Иванова Мария

+7 (926) 555-33-44

2

Комбо набор 1

Петров Павел

+7 (926) 555-22-33

И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!

Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в базовое знание sql, которое требуется на собеседованиях.

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

Как связать данные между собой

Вот например, у нас есть интернет-магазин по доставке пиццы. Так выглядит его база данных:

  • В таблице client лежат данные по клиентам: ФИО, пол, дата рождения и т.д.

last_name

first_name

birthdate

VIP

Иванов

Иван

01.02.1977

true

Петрова

Мария

02.04.1989

false

Сидоров

Павел

03.02.1991

false

Иванов

Вася

04.04.1987

false

Ромашкина

Алина

16.11.2000

true

  • В таблице orders лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?

order

addr

date

time

Пицца Маргарита

ул Ленина, д5

05.05.2020

06:00

Роллы Филадельфия и Канада

Студеный пр-д, д 10

15.08.2020

10:15

Пицца 35 см, роллы комбо 1

Заревый, д10

08.09.2020

07:13

Пицца с сосиками по краям

Турчанинов, 6

08.09.2020

08:00

Комбо набор 3, обед 4

Яблочная ул, 20

08.09.2020

08:30

Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?

Тут есть несколько вариантов:

1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам... В целом удобно, открыл табличку и сразу видишь ага, это Васин заказ, а это Машин.

Но есть минусы:

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

  • Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.

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

Чтобы избежать дублей, таблицы принято разделять:

  • Клиенты отдельно

  • Заказы отдельно

  • Новые объекты отдельно

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

Нам надо у заказа сделать отметку о клиенте. Значит, таблица orders будет ссылаться на таблицу clients. Ключ можно поставить на любую колонку таблицы. Какую бы выбрать?

Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку... А если у нас два клиента Ивана? Или три Маши? Десять Саш... Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!

Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.

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

Здесь ключ id_orderЗдесь ключ id_order

Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным это значит, что он генерируется сам по алгоритму прошлое значение + 1.

Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем оставляем в гостинице!

Есть таблица постояльцев:

ID

name

year

1

Барсик

2

2

Пупсик

1

Тут привозят еще одного Барсика. Добавляем его в таблицу:

Имя Барсик, 5 лет! (мы не указываем ID)

Система добавляет:

ID

name

year

1

Барсик

2

2

Пупсик

1

3

Барсик

5

ID сгенерился автоматически. Последнее значение было 2, значит, новый Барсик получил номер 3. Обратите внимание Барсиков уже два, но их легко различить, ведь у них разные идентификаторы!

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

id_room

square

id_cat (ссылка на id в таблице котиков)

1

5

11

2

10

2

3

10

Мы видим, что в первой комнате живет котик с id = 1, а во второй с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.

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

И в таблице заказов! id_order пусть генерится сам и всегда будет уникален. А еще в таблицу заказов мы добавим колонку id_client и повесим на нее foreign key, ссылку на id_client в таблице клиентов.

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

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

Как ускорить запрос

Давайте представим, что у нас есть табличка excel. Если она небольшая (пара строк, пара колонок), то найти нужную ячейку не составит труда:

  1. Открыли файлик открывается моментально (если нет проблем с жестким диском)

  2. Нажали Ctrl + F, ввели запрос тут же нашли результат.

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

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

Что делать, чтобы запросы были быстрее? Тут есть несколько путей:

  1. На этапе создания таблицы добавить индексы

  2. На этапе написания запроса к большой таблице использовать хинты

  3. Пересобрать статистику базы

Есть и другие, но мы остановимся на этих трех.

Индексы в таблице

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

Индекс это как алфавитный указатель в библиотеке. Вот представьте, заходите вы в библиотеку и хотите найти Преступление и наказание Достоевского. А все книги стоят от балды, никакого порядка. Чтобы найти нужную, надо обойти все стелажи и просмотреть все полки!

Совсем другое дело, если книги отсортированы по авторам. А внутри автора по названию. Тогда найти нужную книгу будет легко!

Индекс играет ту же роль для базы данных. Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!

Хинты

Хинт это код, вставляемый в SQL-запрос, который позволяет изменить план выполнения запроса. Выглядит это примерно так:

SELECT /*+ NO_UNNEST( @SEL$4 ) */*FROM v;

Хинт идет внутри блока /* */.

А что еще за план выполнения запроса? Смотрите, когда вы выполняете любой запрос, что делает система:

  1. Строит план выполнения запроса (как ей кажется, оптимальный)

  2. Выполняет его

Посмотреть план можно через ключевые слова EXPLAIN PLANOracle):

EXPLAIN PLAN FOR -- построй мне план для...SELECT last_name FROM employees; -- вот такого запроса!

А если вы работаете через sql developer (графический интерфейс для обращения к базе Oracle), то можно просто выделить запрос и нажать F10:

Что мы видим на этой картинке? Запрос говорит: достань мне всю информацию из таблицы клиентов. Так как нет никаких условий where, то мы просто проходим фулл-сканом Table Access (full) по этом таблице. План показывает стоимость (cost) этого запроса 857 ms.

А теперь изменим запрос, сделав выборку по одному конкретному человеку по колонке с индексом:

Оп, цена запроса уже 5 ms. Это, на минуточку, в 170 раз быстрее!

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

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

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

Допустим, поступает жалоба от заказчика клиент открывает карточку в вебе, а она открывается минуту. Что-то где-то тормозит! Но что и где? Начинаем разбираться. Причины бывают разные:

  1. Тормозит на уровне БД тут или сам запрос долго отрабатывает, или статистику давно не пересобирали, или диски подыхают.

  2. Тормозит на уровне приложения тогда надо копаться внутри кода функции открыть карточку, что она там делает, получив ответ от Базы (и снова есть вариант подыхают диски, на которых установлено ПО).

  3. Тормозит на уровне сети сервер приложения и сервер БД обычно размещают на разных машинах. Значит, есть общение между ними по интернету. А интернет может тупить.

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

Собираете план, сохраняете в файлик и прикладываете в задачу в джире. Или отправляете по почте.

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

См также

17 Optimizer Hints в Oracle хинты в базе Oracle

Статистика

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

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

Найди мне всех клиентов, созданных в этом году,

У которых оператор связи в телефоне Мегафон

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

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

Так вот, в статистике по БД хранится в том числе информация о распределении данных и характеристики хранения таблиц и индексов. И когда вы запускаете запрос, база (а точнее, оптимизатор внутри нее) строит возможные планы выполнения. Для каждого плана рассчитывает примерное время выполнения, а потом выбирает лучшее.

Время же он рассчитывает, ориентируясь на статистику:

  • Сколько данных находится в таблице?

  • Есть ли индекс по колонке, по которой я буду искать?

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

См также:

Ручной и автоматический сбор статистики оптимизатора в базе данных Oracle

Преимущества базы данных

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

  1. Базы поддерживают требования ACID (по крайней мере транзакционные БД)

  2. Это единый синтаксис SQL, который используется повсеместно

Требования ACID

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

  • Atomicity Атомарность

  • Consistency Согласованность

  • Isolation Изолированность

  • Durability Надёжность

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

См также:

Требования ACID на простом языке подробнее об этих требованиях

Единый синтаксис SQL

Я спросила знакомого разработчика:

Ну и что, что единый синтаксис? В чем его плюшка то?

Ответ прекрасен, так что делюсь с вами:

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

Как разработчик пишет код? Написал, проверил на коленке. Если не работает думает, почему. Если непонятно, идет гуглить похожие ошибки. А что проще нагуглить? Ошибку распространенной БД, или сделанный на коленке костыль для работы с файлами? Вот то-то и оно...

Что знать для собеседования

Для начала я хочу уточнить, что я сама тестировщик. И мои статьи в первую очередь для тестировщиков ))

Так вот, тестировщика на собеседовании не будут спрашивать про базы данных. Разработчика ещё могут спросить, а вас то зачем? Вполне достаточно понимания, что это вообще такое. И про ключи могут спросить что такое primary или foreign key, зачем они вообще нужны.

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

В вакансии написано: уметь составлять простые SQL запросы. А простые это какие в народном понимании?

(inner, outer) join, select, insert, update, create, последнее время популярны индексы, group by, having, distinct.

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

Статьи и книги по теме

База данных

Википедия

Какие бывают базы данных

Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных.

SQL

Книги:

Изучаем SQL. Линн Бейли Обожаю эту линейку книг, серию Head First O`Reilly. И всем рекомендую)) Просто и доступно даже о сложном пишут.

Статьи:

Как изучить основы SQL за 2 дня

Полезные запросы

Тренажеры:

http://www.sql-ex.ru/ Бесплатный тренажер для практики

Ресурсы и инструменты для практики с базами данных | SQL

Задачка по SQL. Найти объединенные данные

Резюме

База данных это место для хранения данных. Они бывают самых разных видов, даже файловые! Но самые распространенные реляционные базы данных, где данные хранятся в виде таблиц.

Если посмотреть на информацию о таблице в БД, мы можем увидеть ее ключи и индексы. Что это такое:

1.PK primary key, первичный ключ. Гарантирует уникальность данных, часто используется для колонки с ID. Если ключ наложен на одну колонку каждое значение в ячейках этой колонки уникальное. Если на несколько комбинации строк по колонкам уникальны.

2.FK foreign key, внешний ключ. Нужен для связки двух таблиц в разных соотношениях (1:1, 1:N, N:N). Этот ключ указываем в "дочерней" таблице, то есть в той, которая ссылается на родительскую (в таблице с данными по лицевому счету отсылка на client_id из таблицы клиентов).

3.Индекс. Нужен для ускорения выборки из таблицы.

Транзакционные базы данных выполняют требования ACID:

  • Atomicity Атомарность

  • Consistency Согласованность

  • Isolation Изолированность

  • Durability Надежность

См также:

Что такое транзакция

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

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

См также:

Клиент-серверная архитектура в картинках

Чтобы достать данные из базы, надо написать запрос к ней на языке SQL (Structured Query Language). Разработчики пишут SQL-запросы внутри кода приложения. А тестировщики используют SQL для:

  • Поиска по базе правильно ли данные сохранились? В нужные таблицы легли? Это select-запросы.

  • Подготовки тестовых данных а что, если это значение будет пустое? А что, если у меня будет 2 лицевых счета на одной карточке? Можно готовить данные через графический интерфейс, но намного быстрее отправить несколько запросов в базу. Когда есть к ней доступ и вы знаете SQL =)

План-минимум для изучения: select, join, insert, update, create, delete, group by, having, distinct.

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Подробнее..

Как мы тестировали web систему с требованием в 42 000 пользователей

07.06.2021 08:09:22 | Автор: admin

Web-система. Ver 1.0

К нам обратился клиент, который хотел выполнить тестирование своей системы на возможность выдержать работу 42 000 пользователей. Они представили нам свой продукт и требования работы данного продукта:

  • Опросник международного уровня;

  • Содержал около 5 вкладок для перехода и переключение языка;

  • Срок работы опросника всего неделю, но судя по требованиям он должен был быть максимально стабильным и работать безотказно;

  • Ручное время выполнения сценария пользователем должно было составлять примерно 50 - 60 секунд по заявлениям заказчика.

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

И так, что же было у них под капотом:

  • Каждый переход по вкладке динамически загружал данные по технологии WebSocket;

  • На странице использовался JS, CSS;

  • Около 50 - 60 картинок;

  • Файл языкового пакета.

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

У нас новомодная технология и наша система высокопроизводительная... ?!

И так получив систему, мы были ознакомлены и с предоставляемым профилем нагрузки (клиент хочет, клиент платит - кто мы такие, чтобы спорить). Профиль нагрузки был амбициозный: начинаем с 625(!!!) пользователей и добавляем каждые 10 секунд еще столько же. Длительность теста 1 час.

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

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

375 пользователей и добавлять столько же каждые 2 секунды. Длительность выполнения теста 30 минут.

Я не понимаю на что они надеялись поменяв параметры теста таким образом. Но на удивление результат работы был следующим: есть успешно выполненные, но среднее время выполнения сценария около 24 минут. Фактически полностью успешно выполнялись только те, что стартовали вначале.

Провал

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

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

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

Web-система. Ver. 2.0

Более недели мы не получали от них никакой информации. Они к нам вернулись с полностью переработанным движком системы.

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

Мы все переделали. Уж теперь точно полетит?!

Попробовали выполнять более агрессивные профили нагрузки. Сразу запускали 20 000 пользователей, потом 10 000. Но такое большое количество одновременно подключаемых пользователей заваливало сервер сразу же. Новые сервера опять же не успевали загружаться. В результате длительных дискуссий пришли к следующему профилю нагрузки: 150 пользователей и добавлять по 150 каждые 5 секунд. Длительность теста 40 минут.

В результате среднее время выполнения сценария 1 минута 20 секунд. Удалось значительно снизить количество ошибок подключения к Web-системе.

Да, теперь первая страница грузится дольше, чем в первом варианте. Но время выполнения всего сценария сократилось с 22 минут до 1 минуты и 20 секунд. Сервера начинали выдавать ошибки 503 только когда количество одновременно работающих пользователей перешло отметку в 5 000. Таким образом количество пользователей увеличилось в 10 раз с 500 до 5 000.

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

Результат

В результате ими принято решение признать тест успешным. Им не удалось достичь показателя в 50 - 60 секунд на один сценарий, им не удалось достичь 42 000 пользователей. Но они смогли сократить среднее время выполнения сценария и увеличить количество одновременно работающих пользователей в один момент времени.

Заключение

В заключение хочется отметить два момента.

В свете динамических развивающихся frameworkов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать. В указанном мной случае исполнение кода JS на стороне клиента оказалось на много производительнее, чем исполнение кода на стороне сервера от множества пользователей.

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

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

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

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

Подробнее..

Перевод Лучшие практики автоматизации тестирования решение, что и когда автоматизировать

18.05.2021 20:09:49 | Автор: admin

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне 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-митапа чек-лист код-ревью для автотестов, data QA и не только

19.05.2021 10:20:52 | Автор: admin

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

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

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

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

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

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

Data QA test reporting

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

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

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

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

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

Подробнее..

Управление тестами в TestOps храните информацию, а не выводы

24.05.2021 12:21:25 | Автор: admin

Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в 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 и тестируйте как можно меньше. Практики, направленные на скорость, повторяемость и стабильность выполнения тестов, а не покрытие и оценку качества в широком смысле про это в свое время буду писать отдельные статьи. Поэтому, чтобы оставаться в мире, где тестирование отвечает за качество продукта, давайте вернемся к нашим папочкам и признакам. Создавая папочную структуру, мы изначально закладываем в хранилище тест-кейсов принятое решение о том, в каком виде хотим получать отчеты и видеть результаты. Проблема в том, что мы не знаем какие отчёты понадобятся в будущем.

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

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

Пример представлений, которые можно получить в Allure TestOps в пару кликов из базы размеченных тестов.Пример представлений, которые можно получить в Allure TestOps в пару кликов из базы размеченных тестов.

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

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

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

Подробнее..

7 QA-шных грехов, которые помогут или помешают тестировщику (стать тем, кем ты хочешь)

26.05.2021 10:15:20 | Автор: admin
image

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


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


Эгоизм


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

Я сам начинал с техподдержки. Без эгоизма в тех условиях не выжить. Каждый день на работе я задавал вопросы по личкам и получал очень информативные ответы: погугли, хз, наверное, делай как сам знаешь. Уже тогда я понимал, что что-то идёт не так. Все пеклись за себя и своё время. Помогать новым сотрудникам считалось зазорным: это была обуза, ответы давались без желания объяснить. Работал принцип Колизея: выжил значит можешь работать дальше.


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


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


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


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


Мораль главы: не будь эгоистом всегда уделяй время своим коллегам. Ты человек, и они тоже люди. Всем нужно общение и помощь. Помог ты, помогут и тебе. Я всё ещё верю в карму. Быть эгоистом это зазорно. Так что если ты собираешься в QA из Колизея оставь эгоизм, всяк сюда входящий :) А теперь немного о том, как войти в QA.


Нерешительность и страх перемен


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

В 2016 году я, будучи студентом 3-го курса технического университета, решил искать работу, которая как-то связана с ИТ. Друг предложил пойти с ним в техподдержку Skyeng. Честно говоря, я не сразу согласился: мне сложно коммуницировать с людьми, обычно боюсь первым начать разговор и чувствую себя неловко при общении с незнакомыми. Но затем рискнул и прошёл собеседование.


Уже через 3-4 месяца я точно понял, что мне нужно расти над собой и пойти во что-то более айтишное. Мой друг тогда перешёл в отдел QA. Общаясь с ним, я открыл для себя совершенно новую область в разработке тестирование ПО! С первого взгляда это было именно то, что мне нужно: я хотел набраться опыта, залезть с головой в программную часть и расти дальше ведь учился я на разработчика.


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


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

Решение мне далось не сразу. Около месяца я взвешивал все за и против. Руководить отделом в 22 и иметь долгосрочную стабильность (мне даже родные говорили: Да зачем тебе этот айти? Вон, начальником, может, будешь!) ну разве не кайф?


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


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


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


Непроактивность


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

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


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


Субъективно, я был достаточно неплохо подготовлен для джуна, но не имел большого практического опыта. Это плюс пара ошибок по теории привело к тому, что на первом собесе мне сказали: Не быть тебе QA!. Но! Я почти сразу попросил дать мне второй шанс. Следующие 2 недели я не только зубрил почти всё что можно, но и активно практиковался в тестировании полей, оплат, покупок, а также составлял тест-кейсы, чек-листы и тому подобное.


Но! Придя второй раз, я столкнулся далеко не с джуниорскими вопросами: спрашивали про пентестинг и всё такое. Кажется, со мной не захотели возиться. Но! Я написал другому тимлиду тестирования и сразу договорился о третьем собеседовании.


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


Моя проактивность резко упала. Я даже почти перегорел. Однако Через месяц я попросил о четвёртом собеседовании. И в этот раз решил пойти на отчаянный шаг попросился работать в QA на парт-тайме, хотя бы бесплатно. И ребята согласились. Теперь моей задачей было совмещать работу в техподдержке (8 часов в день) и параллельно работать Trainee QA на подхвате (4 часа в день). Я начал писать тест-кейсы, майндмэпы, тестировать что-то простое вроде правок в вёрстке, проходить тест-ран из 4000 кейсов. Сказать, что я был счастлив, ничего не сказать.


Приходилось потеть по 12 часов в день 5 (а иногда и 6) дней в неделю на протяжении месяца, но это того стоило. Когда испытательный срок длиною в месяц подошёл к концу, меня взяли в QA! Я даже был удивлён, потому что успел продолбать один критикал, но ребята сказали, что я не знал продукт, и поэтому они дали мне шанс всё исправить.


QA для меня было неизведанной областью, глаз не успел замылиться и я тут же увидел колоссальный фронт для нововведений. Естественно, процентов 90 моих предложений выкидывали в мусорку. Но хотя бы аргументированно :) Именно конструктив добавлял ещё больше сил генерировать идеи, к которым в итоге нельзя было подкопаться.


Из-за моего рвения постоянно улучшать процессы меня перевели в другой отдел, я стал тимлидом команды тестирования. Около года я лидил команду ручного тестирования, но параллельно сам проявил инициативу и совершенствовался в автоматизации, в чём мне очень помогал коллега Андрей AndrewQA777 Шальнев. Ну а год спустя я всё-таки решил идти в хард, поэтому перешёл на фуллтайм автоматизацию. Нетрудно догадаться, что в автоматизации мне тоже сиделось крайне неспокойно: в свободное время я начал обучать других ребят автотестам, ревьюить код коллег, советовался с разработчиками, как лучше что-то написать. В какой-то момент оказалось, что я по факту руководил уже 5 проектами в автоматизации. Я вырос из суетолога в лида, который может аргументированно проталкивать хорошие процессы и внедрять их. Конечно, не всё сразу получалось, т.к. в начале были проблемы с расфокусом на задачах, но я научился планировать и приоритизировать их. После этого лиды всей гильдии тестирования пришли к выводу, что пора отдать мне все проекты автоматизации, чтобы улучшения происходили повсеместно.


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


Недооценка себя


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

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


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


PDP заключался в доработке фреймворка автотестов (внедрение API-тестов в код), адаптации автотестов под тестовые окружения и расширении покрытия проекта автотестами. Я предоставил подробный отчёт, что покрыл, как это сделал, где добавил стабильности. Но после очередного 1-на-1 с тимлидом я узнал неприятную новость для всего проекта: нам жестко урезают бюджет, полностью останавливают найм новых сотрудников и, естественно, на повышение зарплаты средств нет и подавно. Я расстроился, но решил попробовать снова договориться о новом PDP, тоже сроком на 3 месяца. Все пункты я сделал ещё до конца срока PDP, но в итоге снова узнал, что бюджета на повышение ЗП не было.


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


На новом месте я сразу сказал, что для меня важны обязательства не только со своей стороны, но и со стороны проекта, в котором я работаю. И на меня сразу заложили бюджет на повышение ЗП на год. Я знал, что, выполнив поставленные задачи, получу то, что заслужил. Так и случилось. Happy end :)


Мораль этой истории следующая: надо любить то, что ты делаешь, но и не забывать любить себя.


Неумение превращать свои слабые стороны в сильные


Лень закаляет характер, если вспомнить, сколько требуется усилий, чтобы её побороть. (с) Тристан Бернар.

Сам по себе я очень ленивый человек. (с) я

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


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


По соседству был отдел автоматизации тестирования. Я был знаком оттуда с Андреем AndrewQA777 Шальневым ещё со времен работы в техподдержке, у нас сразу сложились хорошие отношения. Я стал интересоваться, как работает автоматизация, и, немного поговорив с ним, понял, что это:


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

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


Именно не желая день за днём щёлкать однотипные задачки, я закопался в многочисленные доклады, статьи и литературу (начиная с общей теории у Куликова и заканчивая описанием технической документации Jasmine, Protractor, WDIO, Selenium и др.) по теме автотестов. Так и началась моя карьера автоматизатора.


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


Зависть


Я уже не раз упоминал про своего друга. Настало время познакомиться с ним поближе. Его зовут Туан. Сейчас он возглавляет ключевую команду QA-core в компании. И с самого начала я ему завидовал конечно же, в хорошем смысле. В том плане, что равнялся на него.

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


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


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


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


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


Неудовлетворенность собой


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

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


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


Выгорание


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


Я сталкиваюсь с этим стабильно раз в 2-3 месяца. В основном из-за постоянного расфокуса. Моя проактивнось, постоянное желание сделать какой-то улучшайзинг текущих процессов приводят к тому, что я беру на себя кучу новых задач и бывает, что часть задач я не добиваю до конца. Просто потому, что резко может прийти более интересная задача, и моё внимание переключается уже на неё. А как только я закончу делать более интересную задачу, то уже через силу возвращаюсь к прошлой и могу потратить на её выполнение в 2-3 раза больше усилий. И бывает, на этом пути я понимаю, что всё И это чувство может не покидать меня неделями.


Как бороться с этим? Честно, я бы с радостью ответил, но еще не нашёл действенного решения для себя. Пока мне помогают следующие моменты:


  • почаще брать отпуск (на неделю раз в 2-3 месяца);
  • чаще менять локацию, из которой работаешь (на удалёнке это сделать проще);
  • строить диаграмму Ганта для своих задач (крутая практика, помогает чётко распланировать задачи на определённый срок);
  • планировать активности в календаре (например, с 10:00 до 11:00 я пишу код, с 11:00 до 12:00 на созвоне, с 12:00 до 14:00 ресёрчу новый инструмент и т.д.).

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


Отсутствие мотивации


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


Отсутствие поддержки


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


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


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

Подробнее..

Кто такой кросс-системный тестировщик и почему он не должен быть agile?

30.05.2021 18:13:46 | Автор: admin


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

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

Четыре пилотных проекта


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

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

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



Второй пилотный проект был организован полностью на базе и ролевой модели нового подразделения. Мы тестировали процесс формирования цифровых кодов товаров. Проект под названием Digital Content 2.0 продолжался 5 месяцев. Он затрагивал 15 систем, а для его реализации было разработано 114 тест-кейсов. В ходе этого пилота мы пришли к необходимости централизованного управления тестовыми средами и мастер-данными проектов и у нас была создана группа специалистов, поддерживающих работу всех команд в тестовой среде.



Третий пилотный проект MarketPlace выполнялся уже полностью самостоятельно, без участия подрядчика. Наша команда провела тестирование 15 систем, совместная работа которых позволила реализовать продажу товаров маркетплейса Goods на сайте М.Видео. Было разработано еще 209 тест-кейсов, но самое главное мы создали общий верхнеуровневый шаблон процесса кросс-системного тестирования, который можно было использовать на новых проектах.

В ходе MarketPlace мы начали вести тест-кейсы в Jira, собирать в удобной форме отчеты и статистику.



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

Четвертый пилот, после которого наша работа перешла в новое качество это тестирование мобильного приложения Эльдорадо. Тестирование под названием Eldo Mobile стало продуктовым то есть его заказчиком выступил не Projet Manager, а Product Owner. И хотя на этапе трехмесячного пилота мы протестировали только 16 связанных систем, новый подход позволил спланировать кросс-системное тестирование для каждого нового релиза мобильного приложения.

Работа подразделения кросс-системного тестирования сегодня


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



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

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

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

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

Качества кросс-системного тестировщика


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

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

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

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

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

Тестирование продуктов


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

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

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

Плюс централизованного подхода в том, что один тестер может работать сразу с несколькими проектами или продуктами. Например, мобильное приложение регулярно занимает 50 % времени у назначенных специалистов. Остальные 50 % они могут потратить на проверку других систем в соответствии с задачами тест-менеджеров.

Результаты работы нового подразделения


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

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

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

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

P.S. Наша команда расширяется. Нам нужны талантливые тестировщики. Если вы такой, добро пожаловать на борт!
Подробнее..

Тренды тестирования 2020-2021 правда и мифы

15.06.2021 16:19:06 | Автор: admin

Всем привет! Недавно я наткнулся на 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 получился скорее интересный, чем нет. Да, где-то есть призывы в духе "нормально делай нормально будет", но в целом рекомендую к ознакомлению. В отчете несколько десятков страниц, из которых я постарался сделать выжимку, так что каждый при внимательном изучении сможет найти интересные детали.

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

Подробнее..

Перевод Cypress VC Selenium

17.06.2021 18:06:38 | Автор: admin

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

Вот вам вопрос на миллион долларов: является ли 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.

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

Подробнее..

Полезные функции DevTools для тестировщиков

21.05.2021 18:18:17 | Автор: admin

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование - я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков).

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией :), решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

P.S.: Очередность пунктов в списке не говорит об их важности.

  1. Эмуляция android и ios, подключение android при отладке.

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

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

  2. Переопределение геолокации и подмена User-Agent.

    Продолжим рассматривать возможности DevTools для мобильных устройств. В вышеуказанных двух пунктах говорится о возможности изменять (подменять) геолокацию нахождения устройства и параметры юзер агента. Думаю, что многим тестировщикам частенько приходится воспроизводить какие-либо баги, которые были выловлены клиентами продукта не имея на то соответствующих технических возможностей. Подмена User-Agent поможет воспроизвести тот или иной баг, который был воспроизведен из какой-либо версии браузера или ОС. Закончив тестирование, никогда не забывайте возвращать данные User-Agent в исходное положение.

    Подмена User-AgentПодмена User-Agent
  3. Определение JS пути к строке.

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

  4. Изменение стилей CSS у элементов.

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

    Пример изменения размера поля элементаПример изменения размера поля элемента
  5. Неиспользуемые CSS и Javascript в вёрстке.

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

    Отчет о покрытии кодаОтчет о покрытии кода
  6. Немного интересного про debug JavaScript.

    Многим этот пункт покажется лишним, ведь дебажить код - это вещь, которой в основном занимаются разработчики для отладки кода. Но со своей стороны хочу сказать, что это умение для тестировщика, лишним точно не будет. Безусловно для отладки кода необходимо уметь его читать. Думаю, многие видели большое количество мемов про JavaScript, которые красноречиво говорят о том, что язык далеко не самый легкий, особенно для простого обывателя. С другой стороны, некоторые данные иногда формируются на фронте, проходя несколько функций и понять почему в переменной сформировалось определенное значение, бывает очень важно. Даже в мои 3 года опыта работы в тестировании я уже сталкивался с дебагом кода именно в Chrome. Безусловно, без помощи разработчика я бы вряд ли смог это сделать, но в этой ситуации я понял, что этот момент очень важен.

  7. Сохранение изменений в Chrome при перезагрузке страницы.

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

  8. Имитация медленного сетевого соединения.

    Эффект DevTools, который демонстрирует, как ведет себя страница при её загрузке на мобильных устройствах. Разработка, в 90% случаев, ведется при хороших условиях, связанных со скоростью интернета и его стабильностью, также как и тестирование, в связи с чем выловить баг, который воспроизводится у пользователя, становится возможным только полностью воспроизведя все окружение, в котором этот баг проявился. С появлением нового высокоскоростного интернета для мобильный устройств, возможно эта проблема будет не совсем актуальной, но пока этого не происходит. По крайней мере не во всех странах .

    Выбор скорости соединенияВыбор скорости соединения
  9. Настройка столбцов на вкладке Network.

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

    Список возможных столбцов в NetworkСписок возможных столбцов в Network
  10. Снимки экрана при загрузке страницы.

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

  11. Блокирование запросов.

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

  12. Все о cookies во вкладке applications.

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

Бонусы:

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

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

Всем спасибо за внимание!

Подробнее..

Идеальный пайплайн в вакууме

03.06.2021 22:22:36 | Автор: admin
Даже не зовите меня, если ваш pipeline не похож на это.Даже не зовите меня, если ваш pipeline не похож на это.

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

Каким, по вашему мнению, должен быть идеальный пайплайн от коммита до продашкена?/Опишите идеальный CI/CD / etc

Сегодня я хочу рассказать про своё видение идеального пайплайна. Материал ориентирован на людей, имеющих опыт в построении CI/CD или стремящихся его получить.

Почему это важно?

  1. Вопрос об идеальном пайплайне хорош тем, что он не содержит точного ответа.

  2. Кандидат начинает рассуждать, а в крутых специалистах ценится именно умение думать.

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

  4. Организационная проверка. Позволяет узнать, насколько широка картина мира у соискателя. Условно: от создания задачи в Jira до настроек ноды в production. Сюда же можно добавить понимание стратегий gitflow, gitlabFlow, githubFlow.

Итак, прежде чем перейти к построению какого-либо процесса CI, необходимо определиться, а какие шаги нам доступны?

Что можно делать в CI?

  • сканить код;

  • билдить код;

  • тестить код;

  • деплоить приложение;

  • тестить приложение;

  • делать Merge;

  • просить других людей подтверждать MR через code review.

Рассмотрим подробнее каждый пункт.

Code scanning

На этой стадии основная мысль никому нельзя верить.

Даже если Вася Senior/Lead Backend Developer. Несмотря на то, что Вася хороший человек/друг/товарищ и кум. Человеческий фактор, это все еще человеческий фактор.

Необходимо просканировать код на:

  • соотвествие общему гайдлайну;

  • уязвимости;

  • качество.

Мне нужны твои уязвимости, сапоги и мотоциклМне нужны твои уязвимости, сапоги и мотоцикл

Задачи на этой стадии следует выполнять параллельно.

И триггерить только если меняются исходные файлы, или только если было событие git push.

Пример для gitlab-ci

stages:  - code-scanning.code-scanning: only: [pushes] stage: code-scanning 

Linters

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

Самая важная задача линтеров приводить код к единообразию.

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

Инструменты

Инструмент

Особенности

eslint

JavaScript

pylint

Python

golint

Golang

hadolint

Dockerfile

kubeval

Kubernetes manifest

shellcheck

Bash

gixy

nginx config

etc

Code Quality

code quality этими инструментами могут быть как продвинутые линтеры, так и совмещающие в себе всякие ML-модели на поиск слабых мест в коде: утечек памяти, небезопасных методов, уязвимостей зависимостей и т.д, перетягивая на себя еще code security компетенции.

Инструменты

Инструмент

Особенности

Price

SonarQube

Поиск ошибок и слабых мест в коде

От 120

CodeQL

Github native, поиск CVE уязвимостей

OpenSource free

etc

Code Security

Но существуют также и отдельные инструменты, заточенные только для code security. Они призваны:

  1. Бороться с утечкой паролей/ключей/сертификатов.

  2. Cканировать на известные уязвимости.

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

Инструменты

Инструмент

Особенности

Price

gitleaks

Используется в Gitlab Security, может сканить промежуток от коммита "А" до коммита "Б".

Free

shhgit

Запустили недавно Enterpise Edition.

От $336

etc

Сканер уязвимостей необходимо запускать регулярно, так как новые уязвимости имеют свойство со временем ВНЕЗАПНО обнаруживаться.

Да-да, прямо как Испанская Инквизиция!Да-да, прямо как Испанская Инквизиция!

Code Coverage

Ну и конечно, после тестирования, нужно узнать code coverage.

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

Инструменты

Инструмент

Особенности

Price

go cover

Для Golang. Уже встроен в Golang.

Free

cobertura

Работает на основе jcoverage. Java мир

Free

codecov

Старая добрая классика

Free до 5 пользователей

etc

Unit test

Модульные тесты имеют тенденцию перетекать в инструменты code quality, которые умеют в юнит тесты.

Инструменты

Инструмент

Особенности

phpunit

PHP (My mom says I am special)

junit

Java (многие инстурменты поддерживают вывод в формате junit)

etc

Build

Этап для сборки artifacts/packages/images и т.д. Здесь уже можно задуматься о том, каким будет стратегия версионирования всего приложения.

За модель версионирования вы можете выбрать:

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

Инструменты для сборки образов

Инструмент

Особенности

docker build

Почти все знают только это.

buildx / buildkit

Проект Moby предоставил свою реализацию. Поставляется вместе с докером, включается опцией DOCKER_BUILDKIT=1.

kaniko

Инструмент от Google, позволяет собирать в юзерспейсе, то есть без докер-демона.

werf

Разработка коллег из Флант'а. Внутри stapel. All-in-one: умеет не только билдить, но и деплоить.

buildah

Open Container Initiative, Podman.

etc

Итак, сборка прошла успешно идем дальше.

Scan package

Пакет/образ собрали. Теперь нужно просканировать его на уязвимости. Современные registry уже содержат инструментарий для этого.

Инструменты

Инструмент

Особенности

Цена

harbor

Docker Registry, ChartMuseum, Robot-users.

Free

nexus

Есть все в том числе и Docker.

Free и pro

artifactory

Комбайн, чего в нем только нет.

Free и pro

etc

Deploy

Стадия для развертывания приложения в различных окружениях.

Деплоим контейнер в прод, как можем.Деплоим контейнер в прод, как можем.

Не все окружения хорошо сочетаются со стратегиями развертывания.

  • rolling классика;

  • recreate все что угодно, но не production;

  • blue/green в 90% процентов случаев этот способ применим только к production окружениям;

  • canary в 99% процентов случаев этот способ применим только к production окружениям.

Stateful

Нужно еще помнить, что даже имея одинаковый код в stage и production, production может развалиться именно из-за того, что stateful у них разный. Миграции могут отлично пройти на пустой базе, но появившись на проде, сломать зеленые кружочки/галочки в пайплайне. Поэтому для stage/pre-production следует предоставлять обезличенный бэкап основной базы.

И не забудьте придумать способ откатывания ваших релизов на последний/конкретный релиз.

Инструменты

Инструмент

Особенности

helmwave

Docker-compose для helm. Наша разработка.

helm

Собираем ямлики в одном месте.

argoCD

"Клуб любителей пощекотать GitOps".

werf.io

Было выше.

kubectl / kustomize

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

etc

На правах рекламы скажу что helmwav'у очень не хватает ваших звезд на GitHub. Первая публикация про helmwave.

Integration testing

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

Инструменты

Инструмент

Особенности

Selenium

Можно запустить в кубере.

Selenoid

Беды с образами. Требует Docker-in-Docker.

etc

Performance testing (load/stress testing)

Данный вид тестирования имеет смысл проводить на stage/pre-production окружениях. С тем условием, что ресурсные мощности на нем такие же, как в production.

Инструменты, чтобы дать нагрузку

Инструмент

Особенности

wrk

Отличный молоток. Но не пытайтесь прибить им все подряд.

k6.io

Cтильно-модно-JavaScript! Используется в AutoDevOps.

Artillery.io

Снова JS. Сравнение с k6

jmeter

OldSchool.

yandex-tank

Перестаньте дудосить конурентов.

etc

Инструменты, чтобы оценить работу сервиса

Инструмент

Особенности

sitespeed.io

Внутри: coach, browserTime, compare, PageXray.

Lighthouse

Тулза от Google. Красиво, можешь показать это своему менеджеру. Он будет в восторге. Жаль, только собаки не пляшут.

etc

Code Review / Approved

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

Список команд/ролей:

  • QA;

  • Security;

  • Tech leads;

  • Release managers;

  • Maintainers;

  • DevOps;

  • etc.

Очевидно, что созывать весь консилиум перед каждым MR не нужно, каждая команда должна появится в свой определённый момент MR:

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

  • QA перед release ветками;

  • DevOps'ов беспокоить, только если затрагиваются их компетенции: изменения в helm-charts / pipeline / конфигурации сервера / etc.

Developing flow

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

Это и не хорошо, и не плохо это специфика проекта. Есть мнения, что gitflow не торт. GithubFlow для относительно маленьких команд. А про gitlabFlow мне нечего добавить, но есть наблюдение, что его не очень любят продакты - за то, что нельзя отслеживать feature-ветки.

Если вкратце, то:

  • Gitflow: feature -> develop -> release-vX.X.X -> master (aka main) -> tag;

  • GitHubFlow: branch -> master (aka main);

  • GitLabFlow: environmental branches.

TL;DR

Общий концепт

_

Feature-ветка

Pre-Production -> Production

P.S.

Если я где-то опечатался, упустил важную деталь или, по вашему мнению, пайплайн недостаточно идеальный, напишите об этом мне сделаю update.

Разработчик создал ветку и запушил в нее код. Что дальше?

Оставляйте варианты ваших сценариев в комментариях.

Подробнее..

Recovery mode Способыхраненияданныхвавтотестах и автоматизациятестированияПО вавионке что будет на LoGeek Night QA

07.06.2021 18:08:54 | Автор: admin

17 июня в 18:00 состоится Online LoGeek Night QA. На нем наши тестировщики расскажут о плюсах и минусах разных способов хранения данных в автотестах с примерами на Java, а также об автоматизации высокоуровневого тестирования ПО в авионке.

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

Программа

18:00 18:50 Александр Гвоздев

Автоматизация высокоуровневого тестирования ПО максимального уровня безопасности для авионики (приборы первичной индикации, уровни A и B).

В докладе Александр рассмотрит:

Категории критичности отказных состояний бортового ПО и их влияние на аспекты сертификации;

Особенности верификации ПО максимального уровня безопасности;

Реализацию тестирования ПО первичной индикации;

Автоматизацию высокоуровнего тестирования ПО первичной индикации

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

18:50 19:40 Максим Власов

Способы хранения тестовых данных.

В докладе Максим расскажет о:

Двух способах хранить данные в авто тестах: данных в виде хардкода в файлах (json, xml, csv) и модуле внутри фреймворка, который данные генерирует;

О минусах и плюсах этих подходов с примерами на Java.

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

19:40 20:00 Розыгрыш призов

Как принять участие

Митап пройдет онлайн 17 июня, 18:00 (МСК).

Чтобы принять участие, нужно:

  • Зарегистрироваться насайте;

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

Будем рады вас видеть!

Подробнее..

Бенчмарки VKUI и других ребят из UI-библиотек

26.05.2021 12:10:08 | Автор: admin

Меня зовут Григорий Горбовской, я работаю в Web-команде департамента по экосистемным продуктам ВКонтакте, занимаюсь разработкой VKUI.

Хочу вкратце рассказать, как мы написали 8 тестовых веб-приложений, подключили их к моно-репозиторию, автоматизировали аудит через Google Lighthouse с помощью GitHub Actions и как решали проблемы, с которыми столкнулись.

VKUI это полноценный UI-фреймворк, с помощью которого можно создавать интерфейсы, внешне неотличимые от тех, которые пользователь видит ВКонтакте. Он адаптивный, а это значит, что приложение на нём будет выглядеть хорошо как на смартфонах с iOS или Android, так и на больших экранах планшетах и даже десктопе. Сегодня VKUI используется практически во всех сервисах платформы VK Mini Apps и важных разделах приложения ВКонтакте, которые надо быстро обновлять независимо от магазинов.

VKUI также активно применяется для экранов универсального приложения VK для iPhone и iPad. Это крупное обновление с поддержкой планшетов на iPadOS мы представили 1 апреля.

Адаптивный экран на VKUIАдаптивный экран на VKUI

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

Какие задачи поставили

  1. Выявить главные проблемы производительности VKUI.

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

  3. Сравнить производительность VKUI и конкурирующих UI-фреймворков.

Технологический стек

Инструменты для организации процессов:

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

Бенчмарки мы проводим через Google Lighthouse официальный инструмент для измерения Web Vitals. Де-факто это стандарт индустрии для оценки производительности в вебе.

Самое важное делает GitHub Actions: связывает воедино сборку и аудит наших приложений.

Библиотеки, взятые для сравнения:

Название

Сайт или репозиторий

VKUI

github.com/VKCOM/VKUI

Material-UI

material-ui.com

Yandex UI

github.com/bem/yandex-ui

Fluent UI

github.com/microsoft/fluentui

Lightning

react.lightningdesignsystem.com

Adobe Spectrum

react-spectrum.adobe.com

Ant Design

ant.design

Framework7

framework7.io


Мы решили сравнить популярные UI-фреймворки, часть из которых основана на собственных дизайн-системах. В качестве базового шаблона на React использовали create-react-app, и на момент написания приложений брали самые актуальные версии библиотек.

Тестируемые приложения

Первым делом мы набросали 8 приложений. В каждом были такие страницы:

  1. Default страница с адаптивной вёрсткой, содержит по 23 подстраницы.

    • На главной находится лента с однотипным контентом и предложением ввести код подтверждения (абстрактный). При его вводе на несколько секунд отображается полноэкранный спиннер загрузки.

    • Страница настроек, в которую входит модальное окно с примитивным редактированием профиля и очередным предложением ввести код.

    • Страница с простым диалогом условно, с техподдержкой.

  2. List (Burn) страница со списком из 500 элементов. Главный аспект, который нам хотелось проверить: как вложенность кликабельных элементов влияет на показатель Performance.

  3. Modals страница с несколькими модальными окнами.

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

Сделать 8 таких приложений поначалу кажется простой задачей, но спустя неделю просто упарываешься писать одно и то же, но с разными библиотеками. У каждого UI-фреймворка своя документация, API и особенности. С некоторыми я сталкивался впервые. Особенно запомнился Yandex UI кажется, совсем не предназначенный для использования сторонними разработчиками. Какие-то компоненты и описания параметров к ним удавалось найти, только копаясь в исходном коде. Ещё умилительно было обнаружить в компоненте хедера логотип Яндекса <3

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

Автоматизация

Краткая блок-схема, описывающая процессы в автоматизацииКраткая блок-схема, описывающая процессы в автоматизации

Подготовили два воркфлоу:

  • Build and Deploy здесь в первую очередь автоматизировали процессы сборки и разворачивания. Используем surge, чтобы быстро публиковать статичные приложения. Но постепенно перейдём к их запуску и аудиту внутри GitHub Actions воркеров.

  • Run Benchmarks а здесь создаётся issue-тикет в репозитории со ссылкой на активный воркфлоу, затем запускается Lighthouse CI Action по подготовленным ссылкам.

UI-фреймворк

URL на тестовое приложение

VKUI

vkui-benchmark.surge.sh

Ant Design

ant-benchmark.surge.sh

Material UI

mui-benchmark.surge.sh

Framework7

f7-benchmark.surge.sh

Fluent UI

fluent-benchmark.surge.sh

Lightning

lightning-benchmark.surge.sh

Yandex UI

yandex-benchmark.surge.sh

Adobe Spectrum

spectrum-benchmark.surge.sh


Конфигурация сейчас выглядит так:

{  "ci": {    "collect": {      "settings": {        "preset": "desktop", // Desktop-пресет        "maxWaitForFcp": 60000 // Время ожидания ответа от сервера      }    }  }}

После аудита всех приложений запускается задача finalize-report. Она форматирует полученные данные в удобную сравнительную таблицу (с помощью магии Markdown) и отправляет её комментарием к тикету. Удобненько, да?

Пример подобного репорта от 30 марта 2021 г.Пример подобного репорта от 30 марта 2021 г.

Нестабильность результатов

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

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

Предупреждения из отчётов Google LighthouseПредупреждения из отчётов Google Lighthouse

GitHub Actions по умолчанию выполняет задачи параллельно, как и в нашем воркфлоу с бенчмарками. Решение ограничить максимальное количество выполняющихся одновременно задач:

jobs.<job_id>.strategy.max-parallel: 1

Мы провели бенчмарк дважды, и вуаля результаты стали ощутимо стабильнее. Теперь можно переходить к результатам.

Результаты от 30 марта 2021 г.

VKUI (4.3.0) vs ant:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

ant

default

report

0.99

vkui (4.3.0)

modals

report

1

ant

modals

report

0.99

vkui (4.3.0)

list

report

0.94

ant

list

report

0.89

list - У ant нет схожего по сложности компонента для отрисовки сложных списков, но на 0,05 балла отстали.

VKUI (4.3.0) vs Framework7:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

f7

default

report

0.98

vkui (4.3.0)

modals

report

1

f7

modals

report

0.99

vkui (4.3.0)

list

report

0.94

f7

list

report

0.92

list - Framework7 не позволяет вложить одновременно checkbox и radio в компонент списка (List).

VKUI (4.3.0) vs Fluent:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

fluent

default

report

0.94

vkui (4.3.0)

modals

report

1

fluent

modals

report

0.99

vkui (4.3.0)

list

report

0.94

fluent

list

report

0.97

modals - Разница на уровне погрешности.

list - Fluent не имеет схожего по сложности компонента для отрисовки сложных списков.

VKUI (4.3.0) vs Lightning:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

lightning

default

report

0.95

vkui (4.3.0)

modals

report

1

lightning

modals

report

1

vkui (4.3.0)

list

report

0.94

lightning

list

report

0.99

list - Lightning не имеет схожего по сложности компонента для отрисовки сложных списков.

VKUI (4.3.0) vs mui:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

mui

default

report

0.93

vkui (4.3.0)

modals

report

1

mui

modals

report

0.96

vkui (4.3.0)

list

report

0.94

mui

list

report

0.77

default и modals - Расхождение незначительное, у Material-UI проседает First Contentful Paint.

list - При примерно одинаковой загруженности списков в Material-UI и VKUI выигрываем по Average Render Time почти в три раза (~1328,6 мс в Material-UI vs ~476,4 мс в VKUI).

VKUI (4.3.0) vs spectrum:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

spectrum

default

report

0.99

vkui (4.3.0)

modals

report

1

spectrum

modals

report

1

vkui (4.3.0)

list

report

0.94

spectrum

list

report

1

list - Spectrum не имеет схожего по сложности компонента для отрисовки сложных списков.

VKUI (4.3.0) vs yandex:

app

type (app link)

report

performance

vkui (4.3.0)

default

report

0.99

yandex

default

report

1

vkui (4.3.0)

modals

report

1

yandex

modals

report

1

vkui (4.3.0)

list

report

0.94

yandex

list

report

1

default - Разница на уровне погрешности.

list - Yandex-UI не имеет схожего по сложности компонента для отрисовки сложных списков.

modals - Модальные страницы в Yandex UI объективно легче.

Выводы из отчёта Lighthouse о VKUI

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

  • Одно из явных проблемных мест вложенные Tappable протестированы на большом списке. Единственная библиотека, в которой полноценно реализован этот кейс, Material-UI. И VKUI уверенно обходит её по производительности.

  • Lighthouse ругается на стили после сборки много неиспользуемых. Они же замедляют First Contentful Paint. Над этим уже работают.

Два CSS-чанка, один из которых весит 27,6 кибибайт без сжатия в gzДва CSS-чанка, один из которых весит 27,6 кибибайт без сжатия в gz

Планы на будущее vkui-benchmarks

Переход с хостинга статики на локальное тестирование должен сократить погрешность: уменьшится вероятность того, что из-за внешнего фактора станет ниже балл у того или иного веб-приложения. Ещё у нас в репортах есть показатель CPU/Memory Power и он немного отличается в зависимости от воркеров, которые может дать GitHub. Из-за этого результаты в репортах могут разниться в пределах 0,010,03. Это можно решить введением перцентилей.

Также планируем сделать Lighthouse Server для сохранения статистики по бенчмаркам на каждый релиз.

Подробнее..

Перевод Как найти все битые ссылки на странице с помощью Selenium

02.06.2021 14:09:29 | Автор: admin

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

Теперь с помощью этого java-кода вы можете проверить все ссылки. Эти ссылки могут быть ссылками pdf, изображения, видео или фотографии.

Шаг 1: В HTML мы связываем ссылки с помощью этого кода: <a href="Adress"></a> это означает, что мы должны собрать все ссылки на веб-странице на основе <a>. Для этого мы используем этот код:

List<WebElement> allLinks = driver.findElements(By.tagName(LINKS_TAG));

LINKS_TAG - это "a". В конце страницы я добавлю весь код.

Шаг 2: Определение и проверка URL-адреса

String urlLink = link.getAttribute(LINKS_ATTRIBUTE);

LINKS_ATTRIBUTE - это "href"

Шаг 3: Отправка HTTP-запроса и считывание кодов HTTP-ответов

Мы создаем HttpConnection с параметром URL. Я добавил также Connection Timeout.

URL url = new URL(urlLink);HttpURLConnection httpURLConnect=(HttpURLConnection)url.openConnection();httpURLConnect.setConnectTimeout(5000);httpURLConnect.connect();
  • Информационные коды ответов: 100-199

  • Коды успешного ответа: 200-299

  • Редирект коды: 300-399

  • Коды ошибок клиента: 400-499

  • Коды ошибок сервера: 500-599

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

import org.openqa.selenium.By;import org.openqa.selenium.WebDriver;import org.openqa.selenium.WebElement;import org.openqa.selenium.chrome.ChromeDriver;import org.openqa.selenium.chrome.ChromeOptions;import org.testng.annotations.AfterClass;import org.testng.annotations.BeforeTest;import org.testng.annotations.Test;import java.net.HttpURLConnection;import java.net.URL;import java.util.List;public class FindAllBrokenLinks {    public final String DRIVER_PATH = "Drivers/chromedriver";    public final String DRIVER_TYPE = "webdriver.chrome.driver";    public WebDriver driver;    public final String BASE_URL = "https://www.bbc.com/";    public final String LINKS_ATTRIBUTE = "href";    public final String LINKS_TAG = "a";    @BeforeTest    public void beforeTest(){        ChromeOptions options = new ChromeOptions();        options.addArguments("--disable-notifications","--ignore-certificate-errors","--disable-extensions");        System.setProperty(DRIVER_TYPE,DRIVER_PATH);        driver = new ChromeDriver(options);        driver.manage().window().maximize();        driver.get(BASE_URL);    }    @Test    public void FindAllBrokenLinks() throws Exception{        List<WebElement> allLinks = driver.findElements(By.tagName(LINKS_TAG));        for(WebElement link:allLinks){            try {                String urlLink = link.getAttribute(LINKS_ATTRIBUTE);                URL url = new URL(urlLink);                HttpURLConnection httpURLConnect=(HttpURLConnection)url.openConnection();                httpURLConnect.setConnectTimeout(5000);                httpURLConnect.connect();                if(httpURLConnect.getResponseCode()>=400)                {                    System.out.println(urlLink+" - "+httpURLConnect.getResponseMessage()+"is a broken link");                }                else{                    System.out.println(urlLink+" - "+httpURLConnect.getResponseMessage());                }            }catch (Exception e) {            }        }    }    @AfterClass    public void CloseDriver(){        driver.close();    }}

Я использовал URL веб-страницы BBC в качестве базового URL, но запуск этого кода занял 1 минуту и 49 секунд. :) Возможно, вам стоит выбрать другой сайт.

Вот некоторые результаты тестов:

https://www.bbc.com/sport OK

https://www.bbc.com/reel OK

https://www.bbc.com/worklife OK

https://www.bbc.com/travel Временно приостановил работу

https://www.bbc.com/future OK

https://www.bbc.com/culture OK

https://www.bbc.com/culture/music OK

http://www.bbc.co.uk/worldserviceradio/ Не доступен

http://www.bbc.co.uk/programmes/p00wf2qw Не доступен

https://www.bbc.com/news/world-europe-57039362 OK


Перевод подготовлен в рамках набора учащихся на курс "Java QA Automation Engineer". Если вам интересно узнать о курсе подробнее, а также познакомиться с преподавателем, приглашаем на день открытых дверей онлайн.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru