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

Блог компании luxoft

Никогда не писали автотесты? Попробуйте Cypress

28.09.2020 20:13:28 | Автор: admin

Никогда не писали автотесты? Попробуйте Cypress


Автотесты на Cypress
Первое впечатление и встречающиеся проблемы


Дмитрий Кочергин, Lead Software Developer Luxoft

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

Статья будет интересна всем, кто интересовался автотестированием с нуля на JS, но боялся спросить.

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

Быстрый поиск по интернету дал более молодые и перспективные инструменты: WebDriver.IO, Pupeteer (а сейчас лучше Playwright) и Cypress. Выбрал последний, купился на красивые обещания и несколько комментов из холиваров по лучшим инструментам для автотестов.

Так выглядит окно браузера запущенного теста. Слева выполненные команды теста и статус, справа просмотр приложение во время исполнения теста:
image

Вот так выглядит код теста (в Cypress весь код на JS, а селекторы это обычные CSS селекторы):
image

В runtime выглядит так:
image

Пока искал инструмент для автотестов в голове у меня была картинка, что тесты можно создавать прямо в браузере, чтобы просто нажал на запись скрипта система записала мои действия (CSS селекторы элементов, на которые я нажимал). Потом я смотрю сгенерированный тест, подправляю селекторы если нужно, и сохраняю в Test Suite. Эх

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

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

Итак, Cypress, первая страница фреймворка говорит нам что это JavaScript End to End Testing Framework (cypress.io). Далее бегло читаем документацию, она действительно полная, и можно найти ответы практически на все вопросы (все остальное я быстро находил на StackOverflow):
image

Дальше по списку фичей с сайта:
  • Time travel каждый шаг выполнения теста в консоли можно нажать и вернуться на конкретное состояние всего приложения в прошлом, которое отображается прямо в браузере. И это не просто записанная картинка, а реальный DOM, можно откатиться и исследовать страницу через Chrome devtools.
  • Real time reloads как во всей модерн JS теме, поменяли исходники в тот же момент произошёл перезапуск теста в браузере (hot reload).
  • Automatic waiting многие инструкции теста асинхронные, как то переход на страницу, и Cypress сам автоматически дожидается окончания загрузки. Кроме конечно момента, когда вызовы сервера делает приложение.
  • Network traffic control Cypress может захватывать/видеть вызовы сервера и можно задать инструкцию, чтобы подождать ответ от сервера.
  • Screenshots and videos во время выполнения теста Cypress записывает видео экрана (MP4) браузера, вместе с инструкциями в окне.

Все это добро конечно же можно запускать и без открытого браузера на CI, используется headless Chrome или Electron.

Но были и некоторые проблемы.

По началу я не знал, что можно ждать окончания XHR запросов на сервер, и вставлял вместо них timeouts, и тесты рандомно падали. Поправил.
image

Потом через раз работал Hot Reload, постоянно приходилось перезапускать весь Cypress, потому что не было уверенности, что мои изменения применились. Оказалось, что в моей IDE (IntelliJ IDEA) есть такие нехорошие галочки, которые еще и включены по умолчанию, из-за которых получается что сохранение файла это не сохранение, а eventual сохранение.
image

Следующая проблема была в том, что мое приложение использовало window fetch для запросов на сервер, а Cypress видит только XHR запросы. Dirty hack из StackOverflow помог (я так понял, что метод fetch удаляется из window, чтобы браузер сделал fallback на XHR вместо fetch):
image

Далее встала проблема эмуляции мобильного браузера, просто в коде теста user agent перезаписать не получилось, но в отдельном специальном файле все получилось.
image

Далее решение CORSпроблемы:
image

Потом file upload, с наскоку не получилось, стандартные решения не сработали, зато помогла библиотека cypress-file-upload:
image

Единственная проблема которую я не смог решить это воспроизводимость теста. А именно стабильные и одинаковые начальные данные для запуска теста (fixtures), это более конфигурационная задача, а не Cypress, но все равно пока нерешенная.

В итоге, Cypress выглядит отличным инструментом для внедрения автотестирования в проект, если:
  1. Есть знание JS
  2. Нет необходимости тестировать во всех видах браузеров начиная с IE6 (на данный момент Cypress поддерживает Chrome, Chromium, Edge, Electron, Firefox). Вот обсуждение темы. Но могу сказать, что год назад, когда я начинал работать с Cypress он поддерживал только последнюю версию Chrome и Electron для запусков без UI.
  3. Хотите быстро сделать тесты и забыть о них, пока кто-то не сломает приложение :)

Cypress: берите и пользуйтесь!
Подробнее..

Как достичь полной автоматизации в Automotive тестировании и особенности Move конструктора узнаем 25 февраля

17.02.2021 20:19:33 | Автор: admin
image

На online-митапе LoGeek Night Automotive можно будет послушать и обсудить три доклада:

  • Automotive Software introduction. Специфика области и разработки Luxoft
  • Automotive Testing vs Test Automation
  • I like to move it, move it, посвященный Move и лямбда-функции

Под катом есть вся информация о докладах и регистрации.

Программа:


18:00-18:25 Александра Власова, Automotive Software introduction. Специфика области и разработки Luxoft.

Большинство статей по теме Automotive на данный момент носят больше новостной характер. Или это статьи для любителей электроники и embedded development по типу а сегодня мы ковыряемся в таком-то чипе. Александра же даст некоторое overview, чем может быть интересна область Automotive для нас, как специалистов IT-индустрии.

В докладе будут рассмотрены:

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

18:25 19:00 Николай Чертков, Automotive Testing vs Test Automation.

Особенности и актуальные вызовы тестирования в сфере Automotive и что ожидать в ближайшем будущем. Как достичь полной автоматизации в Automotive тестировании?

В докладе будут рассмотрены:

  • Что тестируют в Automotive;
  • Вызовы ближайшего будущего;
  • Какой уровень автоматизации тестирования достижим и от чего это зависит;
  • Фреймворки для автоматизированного тестирования (TAF)

19:00 19:35 Павел Цытович, I like to move it, move it

В докладе будут рассмотрены:

  • Понятие lvalue и rvalue;
  • Move конструктор;
  • Универсальные ссылки;
  • Свертывание ссылок;
  • Move и лямбда-функции.

19:35 19:45 Розыгрыш призов


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


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

Чтобы принять участие, нужно зарегистрироваться на сайте.

Будем рады вас видеть!
Подробнее..

Контроль сонливости водителя и кресла с учётом женской анатомии что нового в автомобильных технологиях безопасности?

09.06.2021 14:20:05 | Автор: admin

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

Active safety и ADAS

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

ADAS (Advanced driver-assistance systems) включает ряд функций, таких как адаптивный круиз-контроль, стабилизационные системы, автоматическое экстренное торможение, обнаружение слепых зон, предупреждение о столкновении, предупреждение о перекрёстном движении и система удержания полосы. Автомобили могут определить, покинули ли вы свою полосу движения, упустили ли из виду пешехода или животное на дороге, помогут с парковкой в неудобных ситуациях.

Эксперты считают, что автомобили, оснащённые ADAS, снизили количество аварий и спасли жизни. Согласно исследованию LexisNexis Risk Solutions, владельцы автомобилей с системой ADAS на 27% реже обращались по поводу телесных повреждений и на 19% реже обращались по поводу повреждения имущества.

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

Данные страхового института дорожной безопасности (IIHS) и производителей CCC Information Services, показывают, что автомобили, оснащённые ADAS, сокращают количество аварий на 20-50%. Институт прогнозирует резкое снижение аварийности в ближайшие 30 лет благодаря ADAS.

Automatic Emergency Braking

Одним из самых популярных и эффективных ADAS-решений для владельцев машин является автоматическое экстренное торможение (Automatic Emergency Braking). Американский страховой институт дорожной безопасности (IIHS) считает, что системы AEB предотвратят 28000 аварий к 2025 году.

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

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

20 автопроизводителей согласились включить в свои автомобили автоматическое экстренное торможение как стандартную опцию к 2022 году. По данным страхового института дорожной безопасности, некоторые компании выполнили обещание, хоть и не идеально. Среди них Audi, Mercedes-Benz, Volvo and Tesla, а также BMW, Hyundai, Mazda, Subaru, Toyota and Volkswagen. Некоммерческая организация Consumer Reports считает, что внедрение технологий для спасения жизней должно быть не добровольным, а обязательным. Они призывают внести в федеральный закон США необходимость оснащения уже созданными технологиями всех новых моделей автомобилей, поступающих на рынок. Компания указывает, что автопроизводители должны сменить вектор и перестать продавать safety technologies как очередную дорогостоящую надстройку, как люк на крыше или модные стереосистемы.

Какие ещё есть системы и приложения?

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

Адаптивное освещение

Ограниченная видимость может затруднить движение в ночное время, особенно по извилистым дорогам. Адаптивные фары улучшают ночное видение за счёт регулировки направления в зависимости от дороги впереди. AFS (Adaptive Front-Lighting System) использует датчики для измерения действий рулевого управления, затем система регулирует наклон и поворот фар, чтобы лучше видеть, куда вы собираетесь. Поэтому, когда водитель поворачивает, у него будет больше шансов понять, куда он направляется, вместо того, чтобы освещать обочину дороги. Кроме того, такая система позволяет избегать попадания прямых лучей на встречные автомобили.

Камера в салоне

К примеру, проект Honda CabinWatch, где используют камеру, чтобы помочь водителям минивэнов внимательно следить за детьми на заднем сиденье. Другие компании и сервисы экспериментируют с программным обеспечением для распознавания лица, чтобы разблокировать автомобиль или определить, когда водитель устаёт или отвлекается. К примеру, так делает Яндекс.Такси с их камерой Yandex Signal Q1, которая анализирует 68 точек на лице человека с помощью технологий компьютерного зрения и нейросети. Она фиксирует различные параметры, например, частоту и длительность моргания.

Мониторинг сонливости

У Jaguar разработана система контроля степени усталости водителя (Driver Condition Monitor), которая определяет признаки сонливости и предупреждает об этом. Она анализирует широкий ряд показателей: отклик системы электроусилителя руля, нажатие на педали газа и тормоза и общее поведение во время управления автомобилем. Алгоритмы изучают полученные данные, чтобы определить момент, когда водитель устаёт. Распознав признаки сонливости, система предлагает остановиться и отдохнуть.

Проекционный дисплей

Heads Up Display позволяет не спускать глаз с дороги, проецируя важную информацию на лобовое стекло автомобиля. Во время движения водитель видит скорость транспорта и GPS-навигацию на приборной панели. Такие дисплеи, например, есть у BMW.

Что может быть не так?

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

Ещё один момент стоимость обслуживания автомобилей с ADAS. Ремонт датчиков, сенсоров, радаров дорог, и иногда только производитель может им заняться.

Пассивная безопасность

Помимо ремней и подушек, к пассивной безопасности можно отнести зоны деформации, поглощающие энергию столкновения. Для введения этих технологий были организованы краш-тесты, которые проводились на телах умерших людей, животных, живых испытателях и манекенах. Помимо самих автопроизводителей, краш-тесты проводят такие ассоциации, как европейская Euro NCAP, Национальное управление безопасностью движения на трассах США (NHTSA) и страховой институт дорожной безопасности IIHS, и похожие ассоциации в Германии, Австралии, Китае и Японии. В разных странах они отвечают за рейтинг безопасности и вывод на рынок новых моделей автомобилей. Тесты проводятся с помощью манекенов и компьютерного моделирования.

Женские манекены

Как раз о манекенах мы и упомянем. В 2019 году статья Guardian Смертельная правда о мире, построенном для мужчин из жилетов к автомобильным авариям вызвала бурное обсуждение. Оказалось, что когда женщина попадает в ДТП, у неё на 47% больше шансов получить серьёзные травмы и на 71% больше шансов получить травмы средней степени тяжести. А всё потому, что в экспериментах никогда должным образом не использовали женский манекен. Он существует, но его тестируют чаще на месте пассажира, а не водителя. И это просто уменьшенная версия мужского манекена, которая не учитывает размеры и состояние грудной клетки, шейного отдела, вес, рост и возможность быть беременной.

Что изменилось за это время?

Шведские исследования показали, что современные сиденья слишком прочные, чтобы защитить женщин от хлыстовых травм: они выбрасывают женщин вперёд быстрее, чем мужчин. Закономерно, что в авангарде решений находится компания Volvo. Они создали инициативу EVA и согласно накопленным данным подготовили систему защиты от хлыстовой травмы WHIPS. Она сочетает прочный подголовник с продуманной конструкцией сиденья для защиты головы и позвоночника. По мнению Volvo, сейчас отсутствует разница в риске травмы между мужчинами и женщинами. Помимо этого, есть инновация SIPS (система защиты от боковых ударов) которая вместе с подушкой безопасности при боковом ударе снижает риск серьезных травм грудной клетки более чем на 50% для всех пассажиров. И не последнее решение от шведов они разработали первый в мире манекен среднего размера для краш-тестов для беременных. Это компьютерная модель, которая позволяет изучить, как движется пассажир, и как ремень безопасности и подушка безопасности влияют, среди прочего, на женщину и плод.

Новая линейка манекенов для краш-тестов под названием THOR доступна давно, но ещё не была официально принята системами оценки безопасности NHTSA или IIHS. По форме они больше соответствуют мужскому и женскому телу и имеют на 100 датчиков больше для сбора данных, чем семейство Hybrid III стандартных манекенов. Женская версия имеет тазовую кость и грудь женской формы.

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

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

Что нас ждёт?

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

Никакого алкоголя

Ожидается внедрение технологии, предотвращающей вождение водителями с опьянением Driver Alcohol Detection System for Safety (DADSS) это единственная технология, разрабатываемая для измерения или количественного определения точной концентрации алкоголя в крови. Это решение не позволит водителю, находящемуся в подвыпившем состоянии, завести двигатель автомобиля и управлять им в нетрезвом виде.

География авторынка

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

Кибербезопасность

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

Источники материала:

  1. https://www.forbes.com/sites/christopherelliott/2020/10/03/your-car-knows-best-these-new-auto-safety-features-will-surprise-you/

  2. https://www.erieinsurance.com/blog/best-car-technology-features-2020

  3. https://www.volvocars.com/mm/why-volvo/human-innovation/future-of-driving/safety/cars-safe-for-all

  4. https://www.theguardian.com/lifeandstyle/2019/feb/23/truth-world-built-for-men-car-crashes

  5. https://humanetics.humaneticsgroup.com/products/anthropomorphic-test-devices/frontal-impact/thor-5f

  6. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/cybersecurity-in-automotive-mastering-the-challenge#

  7. https://cccis.com/wp-content/uploads/2020/12/CCC-Crash-Course-2020.pdf

Если вы разбираетесь в теме технологий и вам нравится сфера автомотив, у нас открыты интересные вакансии. Мы ищем С/С++ разработчиков, QA автоматизаторов, архитекторов и других специалистов. Все вакансии в автомотив практике в Luxoft по ссылке

Подробнее..

DevOpsный C и кухонные войны, или Как я начал писать игры во время еды

22.10.2020 20:12:41 | Автор: admin

DevOpsный C++ и кухонные войны, или Как я начал писать игры во время еды


Я знаю, что ничего не знаю Сократ

Для кого: для IT-шников, которые плевали на всех разработчиков и хотят поиграть в свои игры!

О чем: о том, как начать писать игры на C/C++, если вдруг вам это надо!

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

Привет, меня зовут Андрей Гранкин, я DevOps в компании Luxoft. Разработка приложений это не моя рабочая специализация, но я стараюсь каждую неделю программировать. Потому что люблю игры!

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

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

настало время создавать свои миры, подвластные только мне. Миры, где я есть и Отец, и Сын, и Святой Дух!

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

В этой статье попробую рассказать, как начал писать небольшие игры на C/C++, каков процесс разработки и где нахожу время на хобби в условиях большой загруженности. Она субъективна и описывает процесс индивидуального старта. Материал о невежестве и вере, о моей личной картине мира в данный момент. Другими словами, Администрация не несет ответственности за ваши личные мозги!.

Практика


Знания без практики бесполезны, практика без знаний опасна Конфуций

Мой блокнот моя жизнь!


Итак, на практике могу сказать, что все для меня начинается с блокнота. Туда записываю не только свои повседневные задачи, в нем еще и рисую, программирую, конструирую блок-схемы и решаю задачи, в том числе математические. Всегда используйте блокнот и пишите только карандашом. Это чисто, удобно и надежно, ИМХО.
image
Мой (уже исписанный) блокнот. Вот так он выглядит. В нем повседневные задачи, идеи, рисунки, схемы, решения, черная бухгалтерия, код и так далее

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

  • Project 0: это 3D-сцена Architect Demo, написанная на C# с использованием игрового движка Unity. Для платформ macOS и Windows.
  • Game 1: консольная игра Simple Snake (всем известная как Змейка) под Windows. Написанная на C.
  • Game 2: консольная игра Crazy Tanks (всем известная как Танчики), написанная уже на C++ (с использованием классов) и тоже под Windows.

Project 0. Architect Demo


  • Платформа: Windows (Windows 7, 10), Mac OS (OS X El Capitan v. 10.11.6)
  • Язык: C#
  • Игровой движок: Unity
  • Вдохновение: Darrin Lile
  • Репозиторий: GitHub

image
3D-сцена Architect Demo

Первый проект реализован не на C/C++, а на C# с помощью игрового движка Unity. Этот движок был не так требователен к железу, как Unreal Engine, а также мне показался легче в установке и использовании. Другие движки я не рассматривал.

Целью в Unity для меня не была разработка какой-то игры. Я хотел создать 3D-сцену с каким-то персонажем. Он, а точнее Она (я смоделировал девушку, в которую был влюблен =) должна была двигаться и взаимодействовать с окружающим миром. Важно было только понять, что такое Unity, какой процесс разработки и сколько усилий требуется для создания чего-либо. Так родился проект Architect Demo (название придумано почти от балды). Программирование, моделирование, анимирование, текстурирование заняло у меня, наверное, два месяца ежедневной работы.

Стартовал я с обучающих видео на YouTube по созданию 3D-моделей в Blender. Blender это отличный бесплатный тул для 3D-моделирования (и не только), не требующий установки. И здесь меня ждало потрясение Оказывается, моделирование, анимирование, текстурирование это огромные отдельные темы, на которые можно книжки писать. Особенно это касается персонажей. Чтобы моделировать пальцы, зубы, глаза и другие части тела, вам потребуются знания анатомии. Как устроены мышцы лица? Как люди двигаются? Мне пришлось вставлять кости в каждую руку, ногу, палец, фаланги пальцев!

Моделировать ключицы, дополнительные кости-рычаги, для того чтобы анимация выглядела естественно. После таких уроков осознаешь, какой огромный труд проделывают создатели анимационных фильмов, лишь бы сотворить 30 секунд видео. А ведь 3D-фильмы длятся часами! А мы потом выходим из кинотеатров и говорим что-то вроде: Та, дерьмовый мультик/фильм! Могли сделать и получше... Глупцы!

И еще, что касается программирования в этом проекте. Как оказалось, самая интересная для меня часть была математическая. Если вы запустите сцену (ссылка на репозиторий в описании проекта), то заметите, что камера вращается вокруг персонажа-девочки по сфере. Чтобы запрограммировать такое вращение камеры, мне пришлось сначала высчитывать координаты точки положения на круге (2D), а потом и на сфере (3D). Самое смешное, что я ненавидел математику в школе и знал ее на три с минусом. Отчасти, наверное, потому что в школе тебе попросту не объясняют, как, черт возьми, эта математика применяется в жизни. Но когда ты одержим своей целью, мечтой, то разум очищается, раскрывается! И ты начинаешь воспринимать сложные задачи как увлекательное приключение. А потом думаешь: Ну чего же *любимая* математичка не могла нормально рассказать, где эти формулы прислонить можно?.
image
Просчет формул для вычисления координат точки на круге и на сфере (из моего блокнота)

Game 1. Simple Snake


  • Платформа: Windows (тестировал на Windows 7, 10)
  • Язык: по-моему, писал на чистом C
  • Игровой движок: консоль Windows
  • Вдохновение: javidx9
  • Репозиторий: GitHub

image
Игра Simple Snake

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

А что у нас простое и быстрое? Правильно, консоль и 2D. Точнее даже консоль и символы. Опять полез искать вдохновение в интернет (вообще, считаю интернет наиболее революционным и опасным изобретением XXI века). Нарыл видео одного программиста, который делал консольный тетрис. И по подобию его игры решил запилить змейку. С видео я узнал про две фундаментальные вещи игровой цикл (с тремя базовыми функциями/частями) и вывод в буфер. Игровой цикл может выглядеть примерно так:
int main()   {      Setup();      // a game loop      while (!quit)      {          Input();          Logic();          Draw();          Sleep(gameSpeed);  // game timing      }      return 0;   }

В коде представлена сразу вся функция main(). А игровой цикл начинается после соответствующего комментария. В цикле три базовые функции: Input(), Logic(), Draw(). Сначала ввод данных Input (в основном контроль нажатия клавиш), потом обработка введенных данных Logic, затем вывод на экран Draw. И так каждый кадр. В такой способ создается анимация. Это как в рисованных мультиках. Обычно обработка введенных данных отбирает больше всего времени и, насколько я знаю, определяет фреймрейт игры. Но тут функция Logic() выполняется очень быстро. Поэтому контролировать скорость смены кадров приходится функцией Sleep() с параметром gameSpeed, который и определяет эту скорость.
image
Игровой цикл. Программирование змейки в блокноте

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

Получение буфера экрана (если можно так сказать):
// create screen buffer for drawings   HANDLE hConsole = CreateConsoleScreenBuffer(GENERIC_READ | GENERIC_WRITE, 0,    NULL, CONSOLE_TEXTMODE_BUFFER, NULL);   DWORD dwBytesWritten = 0;   SetConsoleActiveScreenBuffer(hConsole);</code>Непосредственный вывод на экран некой строки scoreLine (строка отображения очков):<code>// draw the score   WriteConsoleOutputCharacter(hConsole, scoreLine, GAME_WIDTH, {2,3}, &dwBytesWritten);

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

Game 2. Crazy Tanks


  • Платформа: Windows (тестировал на Windows 7, 10)
  • Язык: C++
  • Игровой движок: консоль Windows
  • Вдохновение: книга Beginning C++ Through Game Programming
  • Репозиторий: GitHub

image
Игра Crazy Tanks

Выводить символы в консоль это, наверное, самое простое, что вы можете превратить в игру. Но тогда появляется одна неприятность: символы имеют разную высоту и ширину (высота больше, чем ширина). Таким образом, все будет выглядеть непропорционально, а движение вниз или вверх казаться гораздо быстрее, чем влево или вправо. Этот эффект очень заметен в Змейке (Game 1). Танчики (Game 2) лишены такого недостатка, так как вывод там организован через закрашивание экранных пикселей разными цветами. Можно сказать, я написал рендерер. Правда, это уже чуть сложнее, хотя и гораздо интереснее.

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

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

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

Но доступ к элементам массива происходит в двойном цикле, как будто это не одномерный, а двумерный массив. Так сделано потому, что мы все-таки работаем с матрицами.
image
Обход одномерного массива в двойном цикле. Y идентификатор строк, X идентификатор столбцов

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

Теперь о пикселях, цвете и выводе на экран. Для вывода используется функция StretchDIBits (Header: windows.h; Library: gdi32.lib). В эту функцию, помимо всего прочего, передается следующее: устройство, на которое выводится изображение (в моем случае это консоль Windows), координаты старта отображения картинки, ее ширина/высота и сама картинка в виде битовой карты (bitmap), представленной массивом байтов. Битовая карта в виде массива байт!

Функция StretchDIBits() в работе:

// screen output for game field   StretchDIBits(               deviceContext,               OFFSET_LEFT, OFFSET_TOP,               PMATRIX_WIDTH, PMATRIX_HEIGHT,               0, 0,               PMATRIX_WIDTH, PMATRIX_HEIGHT,               m_p_bitmapMemory, &bitmapInfo,               DIB_RGB_COLORS,               SRCCOPY               );

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

Создание битовой карты m_p_bitmapMemory:
// create bitmap   int bitmapMemorySize = (PMATRIX_WIDTH * PMATRIX_HEIGHT) * BYTES_PER_PIXEL;   void* m_p_bitmapMemory = VirtualAlloc(0, bitmapMemorySize, MEM_COMMIT, PAGE_READWRITE);

Грубо говоря, битовая карта состоит из набора пикселей. Каждые четыре байта в массиве это пиксель в формате RGB. Один байт на значение красного цвета, один байт на значение зеленого цвета (G) и один байт на синий цвет (B). Плюс остается один байт на отступ. Эти три цвета Red/Green/Blue (RGB) смешиваются друг с другом в разных пропорциях и получается результирующий цвет пикселя.

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

Итак, мы имеем числовую матрицу всего игрового поля с одной стороны и битовую карту для вывода изображения с другой. Пока что битовая карта пустая в ней еще нет информации о пикселях нужного цвета. Это значит, что последним этапом будет заполнение битовой карты информацией о каждом пикселе на основе числовой матрицы игрового поля. Наглядный пример такого преобразования на картинке ниже.
image
Пример заполнения битовой карты (Pixel matrix) информацией на основе числовой матрицы (Digital matrix) игрового поля (индексы цветов не совпадают с индексами в игре)

Также представлю кусок реального кода из игры. Переменной colorIndex на каждой итерации цикла присваивается значение (индекс цвета) из числовой матрицы игрового поля (mainDigitalMatrix). Затем в переменную color записывается сам цвет на основе индекса. Дальше полученный цвет разделяется на соотношение красного, зеленого и синего оттенка (RGB). И вместе с отступом (pixelPadding) раз за разом эта информация записывается в пиксель, формируя цветное изображение в битовой карте.

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

Заполнение битовой карты информацией на основе числовой матрицы игрового поля:
// set pixel map variables   int colorIndex;   COLORREF color;   int pitch;   uint8_t* p_row;    // arrange pixels for game field   pitch = PMATRIX_WIDTH * BYTES_PER_PIXEL;     // row size in bytes   p_row = (uint8_t*)m_p_bitmapMemory;       //cast to uint8 for valid pointer arithmetic   (to add by 1 byte (8 bits) at a time)      for (int y = 0; y < PMATRIX_HEIGHT; ++y)   {       uint32_t* p_pixel = (uint32_t*)p_row;       for (int x = 0; x < PMATRIX_WIDTH; ++x)       {           colorIndex = mainDigitalMatrix[y * PMATRIX_WIDTH + x];           color = Utils::GetColor(colorIndex);           uint8_t blue = GetBValue(color);           uint8_t green = GetGValue(color);           uint8_t red = GetRValue(color);           uint8_t pixelPadding = 0;            *p_pixel = ((pixelPadding << 24) | (red << 16) | (green << 8) | blue);           ++p_pixel;       }       p_row += pitch;   }

По описанному выше методу в игре Crazy Tanks формируется одна картинка (кадр) и выводится на экран в функции Draw(). После регистрации нажатия клавиш в функции Input() и последующей их обработки в функции Logic() формируется новая картинка (кадр). Правда, игровые объекты уже могут иметь другое положение на игровом поле и, соответственно, отрисовываются в другом месте. Так и происходит анимация (движение).

По идее (если ничего не забыл), понимание игрового цикла из первой игры (Змейка) и системы вывода пикселей на экран из второй игры (Танчики) это все, что вам нужно, чтобы написать любую свою 2D-игру под Windows. Без звука! ;) Остальные же части просто полет фантазии.

Конечно, игра Танчики сконструирована гораздо сложнее, чем Змейка. Я использовал уже язык C++, то есть описывал разные игровые объекты классами. Создал собственную коллекцию код можно посмотреть в headers/Box.h. Кстати, в коллекции, скорее всего, есть утечка памяти (memory leak). Использовал указатели. Работал с памятью. Должен сказать, что мне очень помогла книга Beginning C++ Through Game Programming. Это отличный старт для начинающих в C++. Она небольшая, интересная и неплохо организована.

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

В завершение практической части пульну несколько сканов моего блокнота. Чтобы показать, что именно я записывал, рисовал, считал, проектировал
image
Проектирование изображения танков. И отпределенеи того, сколько пикселей каждый танк долже занимать на экране
image
Просчет алгоритма и формул по обороту танка вокруг своей оси
image
Схема моей коллекции (той самой, в которой есть memory leak, скорее всего). Коллегкция создана по типу Linked List
image
А это пщетные попытки прикрутить к игре искусственный интеллект

Теория


Даже путь в тысячу миль начинается с первого шага (Древнекитайская мудрость)

Перейдем от практики к теории! Как же найти время на свое хобби?

  1. Определить, чего вы действительно хотите (увы, это самое сложное).
  2. Расставить приоритеты.
  3. Пожертвовать всем лишним в угоду высшим приоритетам.
  4. Двигаться к целям каждый день.
  5. Не ждать, что появится два-три часа свободного времени на хобби.

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

Существует некое золотое правило: never have a 0% day! О нем я узнал в статье одного indie-разработчика. Если работаете над каким-то проектом, то делайте по нему что-то каждый день. И неважно, сколько вы сделаете. Напишите одно слово или одну строчку кода, посмотрите одно обучающее видео или забейте один гвоздь в доску просто сделайте хоть что-то. Самое сложное это начать. Как только начнете, то наверняка сделаете немного больше, чем хотели. Так вы будете постоянно двигаться к своей цели и, поверьте, очень быстро. Ведь основной тормоз всех дел это прокрастинация.

И важно помнить, что не стоит недооценивать и игнорировать свободные опилки времени в 5, 10, 15 минут, ждать каких-то больших бревен длительностью в час или два. Стоите в очереди? Продумайте что-то по вашему проекту. Поднимаетесь по эскалатору? Запишите что-то в блокнот. Едите в автобусе? Отлично, прочтите какую-то статью. Используйте каждую возможность. Хватит смотреть котиков и собачек на YouTube! Не засоряйте себе мозг!

И последнее. Если, прочитав эту статью, вам понравилась идея создания игр без использования игровых движков, то запомните имя Casey Muratori. У этого парня есть сайт. В секции watch -> PREVIOUS EPISODES вы найдете чудесные бесплатные видеоуроки по созданию профессиональной игры с полнейшего нуля. За пять уроков Intro to C for Windows вы, возможно, узнаете больше, чем за пять лет обучения в университете (об этом кто-то написал в комментариях под видео).

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

Удачи вам на выбранном пути! И давайте сделаем мир профессиональней.

Автор: Гранкин Андрей, DevOps

Подробнее..

Алгоритмы аллокации памяти, автономное зрение и специфика работы в модели Software House

20.04.2021 18:08:31 | Автор: admin

На митапе 28 апреля С++ программисты из Luxoft расскажут о своих разработках в Automotive и банкинге.

На online-митапе LoGeek NightC++ можно будет послушать и обсудить три доклада:

  • Особенности предоставления сервисов в формате Software House на примере одного из крупнейших поставщиков Tier-1 для крупного корейского производителя автомобилей

  • Карты высокого разрешения и высокоточная локализация для автономного вождения

  • Heap Manager. Алгоритмы аллокации памяти

Программа:

18:00-18:40 Евгений Польченко, Program Manager, Особенности предоставления сервисов в формате Software House на примере одного из крупнейших поставщиков Tier-1 для крупного корейского производителя автомобилей.

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

В докладе будут рассмотрены:

Разница подходов Software House & Program как объединение проектов;

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

Уровни автоматического управления автомобилем

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

18:40-19:20 Виктор Крухмалёв, ведущий программист, Карты высокого разрешения и высокоточная локализация для автономного вождения

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

В докладе будут рассмотрены:

Что такое автомное вождение

Что такое карты высокого разрешения и как это связано с локализацией

Задачи, с которыми сталкивается разработчик.

19:20-20:00 Михаил Горшков, Chief Programmer, Heap Manager. Алгоритмы аллокации памяти

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

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

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

Чтобы принять участие, нужно зарегистрироваться на сайте.

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

Подробнее..

Recovery mode Usability Testing от А до Я подробный гид

25.06.2020 14:15:14 | Автор: admin
Непрерывный процесс получения и обработки обратной связи от пользователей, а также своевременная реакция на нее ключ к успеху проекта. Такой процесс необходим при любых сценариях: будь то разработка ПО с нуля или улучшение уже существующего.

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



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

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

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

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

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


Определение цели


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

  • Что для вас в исследовании будет важным? Какие роли пользователей или их конкретные задачи стремитесь протестировать?
  • Что надеетесь зафиксировать в заметках? К примеру, хотите использовать видеосъемку, а в протоколах помечать интересные моменты с привязкой к видео для быстрого поиска и обработки обратной связи.
  • Планируете ли изучить рабочее пространство пользователей? Есть случаи, когда оно влияет на организацию интерфейса.
  • Есть ли необходимость в фото- или видеосъемке в процессе наблюдения за пользователем? Возможно, какие-то сценарии проще записать на видео. Например, при проектировании мониторинговой системы скважин необходимо понять, с какими устройствами передачи данных взаимодействует Service Supervisor и какое количество мониторов он использует.
  • Какие метрики будут использованы в тестировании? Количественные и/или качественные? Это зависит от того, что вам в исследовании интересно и что проверяете. Если работаете над приложением, предназначенным для рабочего процесса пользователя, вряд ли вас будет интересовать степень его вовлеченности. Вы, очень вероятно, будете заинтересованы в скорости прохождения сценариев, количестве пользовательских ошибок, выполненных сценариев и степени удовлетворенности пользователя.


Создание плана тестирования



Для формирования плана тестирования нужно прежде всего определить:
  • Какой продукт или продукты планируете изучить? Например, закрытая Product Experience Management веб-платформа, обеспечивающая управление всей информацией о товаре/изделии.
  • Что будет предметом тестирования? К примеру, та же веб-платформа или кликабельный адаптивный прототип ее новой версии.
  • Какие типы устройств будут использованы? Например, персональный компьютер (ПК), планшет и мобильный телефон.
  • Какие роли и функции пользователей будут протестированы? Допустим, роль: PDM-администратор. Функции/задачи: создание шаблона для товара или изделия, проверка шаблона товара, утверждение шаблона.

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

Для наблюдения я, как правило, готовлю документ для каждого пользователя дорожную карту, которая рассказывает, что и как делать и на какие вопросы отвечать. Документ называется UX testing plan & script и состоит из таких элементов:
  • вступление;
  • погружение пользователя в контекст решаемых задач;
  • описание задач и список шагов с возможностью занесения комментариев по каждому из них;
  • список вопросов к каждой задаче;
  • заключительный раунд вопросов.

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

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

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

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



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

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

Задача для качественных исследований: найдите на сайте отчет за первый квартал 2019 года.

Задачи для количественных исследований:

А. Используя глобальный поиск на сайте, найдите отчет за первый квартал 2019 года.
В. Используя раздел Reports на сайте, найдите отчет за первый квартал 2019 года.

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

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

Пример сценария: клиент попросил вас подготовить отчет, и вы хотите начать с поиска информации в рамках сайта www.sample.com.

Задача: пожалуйста, войдите в систему, используя свой логин и пароль.

Шаги:
  • Открыть браузер.
  • Ввести в адресную строку www.sample.com.
  • Ввести электронную почту в поле Email.
  • Ввести символы в поле Password.
  • Нажать кнопку Вход.


Альтернативные шаги:

  • Открыть браузер.
  • Ввести в адресную строку www.sample.com.
  • Нажать ссылку Забыли пароль.
  • Ввести свою электронную почту.
  • Открыть почтовый клиент.
  • Найти письмо от сервера об авторизации.
  • Перейти по ссылке.
  • Ввести новый пароль.
  • Повторить пароль.
  • Нажать кнопку Сменить пароль.


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

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

Определение количества исследователей



Для качественного проведения наблюдения необходимо иметь следующие роли:

  • Интервьюер проводит юзабилити-тестирование, используя UX testing plan & script. Часто такая роль достается самому проектировщику интерфейса.
  • Наблюдатель уточняет детали и углубляется в них по мере протекания тестирования. В данной роли могут выступить продакт-оунер, эксперты предметной области или проектировщики интерфейса.
  • Модератор должен придерживаться тайминга и следить за тем, чтобы все сценарии были воспроизведены пользователем. С этим хорошо справляются проджект- и продакт-менеджеры, скрам-мастеры. Еще приглашают на эту роль проектировщика интерфейсов.


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

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

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

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

Определение целевой аудитории



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

Например, вы работаете над финансовым продуктом и планируете изучить деятельность брокера в рамках создания CLO (collateralized loan obligation) бизнеса на американском рынке. В данном случае нужно понять алгоритмы взаимодействия инвест-банкира с другими финансовыми ролями.

Определиться с целевой аудиторией помогут предварительные опросники. Их создают как в бесплатных сервисах, например Google Forms, так и в платных SurveyMonkey, Typeform и других.

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

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

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

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


Можно использовать дихотомические вопросы (да/нет ответы), чтобы определить, на какой следующий вопрос будет отвечать респондент. Это несложно делается, к примеру, с помощью Google Forms.



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



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

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



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


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

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

На сегодня есть калькуляторы для вычисления количества пользователей. Они базируются на средней вероятности обнаружения ошибки в одном исследовании. Однако проблема в том, что разные исследователи получают разные показатели этой вероятности. К примеру, Якоб Нильсен в свое время получил значение, равное p=0.31, в то же время исследования Спула и Шредера приводят к результату p=0.16.

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

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

До сих пор в мире спорят о том, какое же минимальное количество участников подходит для тестирования. По мнению Якоба Нильсена, это 5 человек, а по мнению Лауры Фолкнер 10.

Я рекомендую начинать с 5-10 тестирований одного прототипа для проверки гипотез в качественных исследованиях и 10-20 тестирований для количественных. Если ошибки начинают повторяться, это свидетельствует о том, что выборка пользователей однородная. Также допускается использовать метод итеративных изменений RITE, когда правки вносятся в интерфейс по мере обнаружения проблем. Проводится тестирование одного пользователя.

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

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

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



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

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

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

Пример:

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

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

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

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

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

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


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

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

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

Организация доступа


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

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

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

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

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

Проведение наблюдения


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

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


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

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

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

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

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



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

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

Делайте заметки с помощью предварительно подготовленной структуры. В UX testing plan & script обычно использую колонку для записи пользовательских комментариев к каждому шагу сценария. Во время выполнения задач делаю небольшие заметки в виде прошел/не прошел сценарий, возникали/не возникали сложности. Эти заметки можно привязать к соответствующим моментам видео, и вы сможете легко вернуться к ним позже.

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

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

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

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

Анализ



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

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


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

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

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

Метод RBT состоит из следующих показателей:

  • Rose то, что работает хорошо или что-то положительное; зеленая карточка.
  • Bud область возможностей или идей, которые еще предстоит изучить; синяя карточка.
  • Thorn что-то не работает или что-то негативное; красная карточка.




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

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

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



Задайте рейтинг найденным проблемам (Thorn) по шкале:

  • Критическая ошибка. Не работает какая-то кнопка, если это не исправить, пользователи не смогут завершить сценарий. Например, человек ищет отели на сайте-агрегаторе, но не может залогиниться или не отображается результат.
  • Серьезная ошибка. Пользователи будут расстроены, если мы не исправим ошибку. Также есть вероятность, что они сдадутся и не пройдут сценарий. Например, выдача в поиске на сайте бронирования отелей занимает 10 секунд. Многие юзеры не заходят ждать и уйдут на другие ресурсы.
  • Минорная ошибка. Пользователи будут раздражены, но это не помешает им завершить сценарий. Например, ожидание отображения результатов сократится до 5 секунд. Это продолжит раздражать, но человек, скорее всего, останется на сайте, так как он уже потратил свое время и не пойдет искать другой сайт, несмотря на то, что ожидание результатов на нем может быть немного меньшим.


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

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

При анализе обратной связи стоит задуматься над такими вопросами:

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

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

Заключение



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

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

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

Автор: Eugenia Grubaya, Senior Usability Architect
Источник: dou.ua/lenta/articles/usability-testing-guide

Подробнее..

Как мы реализовали параллельный запуск Cucumber-сценариев на разных хостах

11.02.2021 22:07:58 | Автор: admin

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

Наш тестовый фреймворк реализован на базе Cucumber (Java). Основной фокус автоматизация GUI тестирования Swing-приложений (используем AssertJ Swing), а также взаимодействие с БД (SQL), REST API (RestAssured) и web UI (Selenide).

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

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

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

Обзор реализации

Для нашей задачи мы решили использовать паттерн master-worker с коммуникацией посредством очереди сообщений.

Компоненты схемы:

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

  • JMS server (для простоты развертывания мы поднимаем свой ActiveMQ Artemis, встроенный в Dispatcher).

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

Master-хост при этом может одновременно выполнять роль одного из агентов (для этого запускаем на нем и Dispatcher, и FeatureExecutor).

Dispatcher при старте получает на вход директорию с features, считывает список файлов, и отправляет их в JMS очередь сценариев.

FeatureExecutor считывает сценарий из очереди и отправляет команду в Test Framework на выполнение этого сценария.

Как получить общий отчет по результатам прогона со всех хостов?

Как мы знаем, Allure складывает файлы с результатами по каждому сценарию в директорию resultsDir (по умолчанию это build/allure-results).

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

FeatureExecutor после каждого сценария архивирует содержимое resultsDir и в виде BytesMessage отправляет в эту очередь, откуда их считывает Dispatcher и распаковывает в resultsDir уже на мастер-хосте.

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

Что, если один из агентов упал?

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

Для решения этой проблемы мы добавили в Dispatcher сервис HealthChecker, который в фоновом потоке через RMI-интерфейс по шедулеру вызывает метод isAlive() на каждом зарегистрированном агенте (список агентов мы загружаем из конфигурации на старте).

Реализация метода на агенте примитивна:

@Overridepublic boolean isAlive() {return true;}

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

Такое условие было реализовано по принципу минимальных вложений в первой версии нашего механизма.

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

Альтернативные опции:

  1. По аналогии с RMI использовать REST API.

  2. Создать отдельную JMS очередь для сообщений типа heartbeat, которые будут отправлять агенты. А на стороне Dispatcher проверять, что от каждого агента мы получаем минимум один heartbeat в 5-10-30 минут (конфигурация по вкусу).

Как быть с тестами, которые не могут выполняться параллельно?

Например, использующие общие ресурсы.

Наше решение стилизовано под специальный Cucumber тег в feature-файле @NoParallel. Почему стилизовано? Потому что читаем мы этот тег средствами java.nio.file, а не через Cucumber. Зато он красиво вписывается в файл сценария:

@NoParallel(PrimaryLicense)@TestCaseId("876123")Scenario: 001 Use of shared resource

Если два сценария используют общий ресурс (обозначенный в теге @NoParallel) они не должны запускаться параллельно.

Для управления ресурсами у нас реализован ResourceManager на стороне Dispatcher с двумя методами в API:

public boolean registerResource(String resource, String agent);public void unregisterResource(String resource, String agent);

Когда FeatureExecutor получает сценарий из очереди с тегом @NoParallel, он вызывает метод registerResource().

Если метод возвращает true ресурс успешно зарегистрирован, продолжаем выполнение сценария.

Если получаем false ресурс занят. Сценарий возвращается в очередь.

После выполнения сценария ресурс освобождается через unregisterResource().

Взаимодействие с ResourceManager у нас реализовано через RMI.

Как вариант, можно использовать REST API.

Summary

  1. Данное решение стоило нам 0 изменений в тестовом фреймворке.

  2. Как следствие имеем полную обратную совместимость. Автотесты могут запускаться и старым, и новым способом без изменений в коде.

  3. Не нужно заботится о потокобезопасности тестов. Они изолированы, поэтому нет разницы, запускаются они параллельно или нет.

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

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

Подробнее..

Jenkins, покрытие кода, байткод и девопс что будет на Luxoft TechFest 4

28.05.2021 10:14:13 | Автор: admin

3 июня пройдёт Luxoft TechFest #4: бесплатное онлайн-мероприятие с тремя докладами по Java и DevOps. Под катом полные описания докладов и другая информация о мероприятии, а сначала суть вкратце для тех, кто торопится:

  • Олег Ненашев разрабатывает Jenkins. И расскажет, как в 2021-м правильнее анализировать code coverage с его помощью.

  • Евгений Мандриков разрабатывает JaCoCo (инструмент, связанный опять же с code coverage). А поговорит о том, как компиляторы Java, Scala и Kotlin преобразуют исходный код, и в чём разница полученного от них байткода.

  • Александр Селезнев уже четыре года вовлечён в DevOps. Но у него будет не тысячный доклад как надо применять DevOps, а наоборот: речь пойдёт о том, как НЕ надо и к каким провалам это может приводить.

Программа

18:00 Приветственное слово

18:05 Scala, Kotlin, Java и Code Coverage: показать все, что скрыто (Евгений Мандриков)

Знаете ли вы, что Scala-компилятор помещает внутрь ваших class-файлов? А чем отличается байт-код, производимый Scala-компилятором, от байт-кода, производимого Java и Kotlin компиляторами? А готовы поспорить?

В этом докладе Евгений поделится исследованием конструкции байт-кода и изучит, как Scala-компилятор и другие преобразуют исходный код. За основу будет взята реализация самого популярного инструмента для анализа покрытия байт-кода тестами JaCoCo.

О спикере: Участник проектов с открытым исходным кодом. Спикер международных конференций. Ведущий разработчик в проекте JaCoCo и лид в отмеченном наградами проекте EclEmma, который интегрирует JaCoCo в Eclipse IDE. В SonarSource Евгений разрабатывает статический анализ исходного кода для Java, C/C++, C#, JavaScript.


18:55 Продвинутый анализ Code Coverage с Jenkins (Олег Ненашев)

В 2016 на конференции Heisenbug Олег рассказывал, как с помощью Jenkins Pipeline, библиотек и сторонних плагинов анализировать тестовое покрытие исходного кода. Сейчас многие типовые задачи решаются плагинами из коробки. В этом докладе речь пойдет о современных подходах к code coverage в Jenkins.

Олег рассмотрит Jenkins Pipeline, Code Coverage API Plugin, поддержку форматов Cobertura, JaCoCo и gcov, параллелизацию тестов и интеграцию с GitHub Checks API и другими сервисами. Он расскажет, как анализировать code coverage в Jenkins, как он помогает с code review и возможно ли использовать преимущества code coverage в Jenkins без самого Jenkins.

О спикере: Разработчик в CloudBees. Состоит в core-команде проекта Jenkins. C 2008 года занимается автоматизацией, инфраструктурой и фреймворкостроением для крупных программно-аппаратных проектов с помощью Jenkins и десятков других инструментов. Пишет код, поддерживает ядро и плагины Jenkins, организует митапы в Питере и других городах.


19:45 Карго-культ вокруг DevOps: Как навредить проекту из лучших побуждений (Александр Селезнев)

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

Доклад затронет:

  • Что такое DevOps на самом деле и кому он нужен (а кому нет);

  • Провал 1 Infrastructure as Code;

  • Провал 2 Kubernetes;

  • Провал 3 CI/CD/CT.

О спикере: Работает в Luxoft. Прошел путь от инженера компьютерного класса до релиз-менеджера. Последние 4 года активно занимается DevOps во всех его аспектах: от решения технических задач до трансформации проектов.

20:35 Закрытие


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

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

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

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

  • Перейти по ссылке в письме от Личного Кабинета JUG Ru Group;

  • Войти в личный кабинет (или создать новый);

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

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

Подробнее..

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, которую вы получите за сутки и за час до начала митапа на почту.

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

Подробнее..

Сбор метрик SpringBoot-приложения в AWS CloudWatch

28.07.2020 16:18:22 | Автор: admin
Привет! Меня зовут Артем Арешко, я являюсь ведущим Java разработчиком в компании Luxoft на Fin-Tech проекте. Сегодня поговорим о метриках, Spring Boot и облаках Amazon.

В качестве вступления...


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

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

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

О чем речь


Проект, на котором я участвую, как раз использует сервисы и развернут в AWS (Amazon Web Services). Основная масса сервисов построена с использованием Java 8+, Spring Boot и Docker. Доклад, прошедший на Luxoft IT Sreda #7 и данная статья выросли из нужд и задач проекта.

Моя цель рассмотреть практическую сторону сбора метрик приложения, использующего Spring Boot, и экспорт их в AWS CloudWatch. Это будет, по сути, step-by-step guide с пояснениями, разбором нюансов и возможных граблей.

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

Рассмотрим, из чего состоит наш сегодняшний контекст:
  1. Как данность, наше приложение или сервис основано на Spring Boot. В качестве сборщика Maven, Java 8+
  2. Docker. Однако, его использование не является критическим моментом. Важно, что для приложения, запущенного в docker все тоже будет работать
  3. AWS EC2 это наша инфраструктура, где запускается приложение. По своей сути это виртуальная машина в рамках AWS.
  4. AWS CloudWatch система мониторинга, являющаяся приборной панелью AWS-инфраструктуры.

Spring Boot


Перейдем к SpringBoot и его возможностям, которые могут нам помочь. Первое и самое важное, что есть в арсенале Actuator. Этот модуль дает возможность заглянуть внутрь работающего приложения и, до определенной степени, настроить его поведение. Например:
  • Health check: информация о состоянии приложения в целом и его компонентов по отдельности
  • Узнать настройки логирования и, при необходимости, скорректировать в runtime.
  • Получить сведения о бинах, поднятых в контексте
  • Считать метрики, производимые приложением, такие как: данные о памяти, процессорных ресурсам, поведению GC.
  • ...

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

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

Сбор и предоставление метрик реализован через библиотеку micrometer, которая является продуктом компании Pivotal (ныне часть VMware), той же, что занимается разработкой Spring. micrometer позиционируется как вендорно-независимый фасад для экспорта метрик Java-приложений.

Для подключения actuator потребуется следующий starter:
<dependency>   <groupId>org.springframework.boot</groupId>   <artifactId>spring-boot-starter-actuator</artifactId></dependency>

Spring Cloud


Далее нам потребуется модуль из Spring Cloud, а именно spring-cloud-starter-aws.

У каждого модуля из семейства Spring Cloud свое версионирование и будет правильным использовать не конкретную версию модуля, а BOM spring-cloud-dependencies определенной версии (release train), где собраны совместимые версии модулей. На момент написания это Hoxton.RELEASE.

Кроме вкусных автоконфигураций, для работы с AWS, spring-cloud-starter-aws, в качестве транзитивной зависимости, дает aws-java-sdk.

В разделе dependencyManagement помещаем
<dependencyManagement>...   <dependencies>       <dependency>          <groupId>org.springframework.cloud</groupId>          <artifactId>spring-cloud-dependencies</artifactId>          <version>Hoxton.RELEASE</version>          <type>pom</type>          <scope>import</scope>       </dependency>   </dependencies>...</dependencyManagement>

А в зависимости:
<dependency>   <groupId>org.springframework.cloud</groupId>   <artifactId>spring-cloud-starter-aws</artifactId></dependency>

Micrometer registry


Теперь у нас есть micrometer в составе Spring Actuator и aws-java-sdk. Из коробки, micrometer не умеет экспортировать данные в AWS CloudWatch, для этого требуется соответствующая реализация MeterRegestry абстракции micrometer для сбора метрик. По умолчанию подставляется SimpleMeterRegistry, хранящий данные в памяти. Нужная реализация подключается вместе с micrometer-registry-cloudwatch. На момент написания, актуальная версия 1.3.5.
<dependency>   <groupId>io.micrometer</groupId>   <artifactId>micrometer-registry-cloudwatch</artifactId>   <version>1.3.5</version></dependency>

Итоговый pom.xml, в нашем случае, имеет следующий вид: github.com/MrArtemAA/blog-demos/blob/master/export-metrics-to-cloudwatch/pom.xml

app.properties


Перейдем к настройке свойств приложения, которые в нашем случае играют немаловажную роль:
1. management.metrics.export.cloudwatch.namespace: нужно указать namespace, под которым в CloudWatch будут сохранятся метрики. Т.к. в самой метрике нет информации от какого именно инстанса приложения пришли данные, namespace как раз и будет определять метрики конкретного инстанса. В противном случае, если для нескольких инстансов определить один namespace, данные метрик будут перемешаны и не понятно откуда какие пришли.

image

2. management.metrics.export.cloudwatch.batch-size: требуется явно установить значение свойства batch-size равным 20. Что это за параметр и почему именно 20? Метрики посылаются клиентов Amazon CloudWatch асинхронно, партиями (batch) по 20 (это ограничение AWS) за раз.
3. cloud.aws.stack.auto=false: нужно отключить автоопределение AWS CloudFormation стека, т.к. по умолчанию оно имеет значение = true. Это свойство отвечает за то, будет ли приложение пытаться автоматически получить название стека для конфигурации приложения под облачное окружение (в парадигме infrastructure-as-code). При развертывании на EC2, как на обычной виртуалке, этой информации нет.

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

Разбор полетов


batch-size


Еще раз вернемся к свойству management.metrics.export.cloudwatch.batch-size и необходимости выставить его равным 20. Казалось бы, это все можно сделать на уровне соответствующих библиотек, работающих с AWS. Действительно, в micrometer-registry-cloudwatch есть интерфейс CloudWatchConfig с default методом, который корректно проверяет значение и кидает исключение при превышении 20. Однако, если посмотреть
org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchExportAutoConfiguration, увидим, что конфигурация происходит с помощью org.springframework.cloud.aws.autoconfigure.metrics.CloudWatchPropertiesConfigAdapter:@Bean@ConditionalOnMissingBeanpublic CloudWatchConfig cloudWatchConfig(CloudWatchProperties cloudWatchProperties) {  return new CloudWatchPropertiesConfigAdapter(cloudWatchProperties);}

Адаптер, в свою очередь переопределяет batchSize() как
@Overridepublic int batchSize() {  return get(CloudWatchProperties::getBatchSize, CloudWatchConfig.super::batchSize);}

Это значит, что если в CloudWatchProperties свойство определено оно будет взято оттуда. Как раз в нем нет нужных проверок и, если свойство не выставлено явно, значение по умолчанию будет 10000.

Запросы к AWS


Приложение (сервис) не может просто так делать запросы к сервисам Amazon. Они [запросы] должны содержать учетные данные. Для этого в AWS SDK есть цепочка провайдеров учетных данных, которую и рекомендуется использовать. Среди этих провайдеров есть Instance Profile, который как раз может получить данные на основе метаданных EC2. Чтобы это работало, необходимо убедиться, что к EC2 привязана роль.



Роль должна предоставлять права на выполнение запросов к CloudWatch и быть доступной для EC2. Роль можно указать как при создании нового EC2 instance, так и прикрепить к существующему. Применение роли происходит на лету.

Отключение метрик


Для локальной сборки или тестового окружения экспорт метрик может быть излишним. Установка свойства management.metrics.export.cloudwatch.enabled=false позволяет отключить экспорт метрик в CloudWatch, при этом сам сбор метрик будет производится и, если у вас подключен модуль web, то по endpoint /metrics они все также будут доступны.

Micrometer собирает и поставляет большое количество метрик. Если какие-то из них не нужны, их можно отключить. Можно отключать как индивидуально, так и целыми категориями. Так, например, свойство management.metrics.enable.some.metric=false, отключит все метрики, чьи id будут начинаться с some.metric. Имейте ввиду: отключенные метрики не будут собираться вообще.

Запуск все AWS


Еще один сюрприз поджидает, если попытаться запустить приложение с минимально необходимыми настройками все AWS. Для работы необходимые данные региона, где работает приложение. Как мы уже знаем, все что не указано явно, AWS SDK будет пытаться получить из метаданных которых нет. Поэтому явно указываем нужный регион через свойство cloud.aws.region.static=us-east-2. Как и в случае с названием стека (свойство cloud.aws.stack.auto), имеет место быть свойство cloud.aws.region.auto равное true по умолчанию. Но просто выставление значения в false нам не поможет, т.к. нужно именно значение региона.

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

Передача через свойства приложения выглядит следующим образом:
cloud.aws.credentials.access-key=YOUR_ACCESS_KEY
cloud.aws.credentials.secret-key=YOUR_SECRET_KEY


Итоги


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

Самое важное как раз кроется в деталях. Библиотеки (фреймворки) такие, как Spring, AWS SDK, пытаются облегчить жизнь и максимально сделать всю работу за нас, но при этом любой шаг в сторону может привести к появлению stacktrace, попыткам понять, почему метрики никуда не идут, почему приложение вообще не запускается и как это все исправить. Раздел с разбором нюансов и описание некоторых деталей работы сервисов EC2 и CloudWatch, надеюсь, облегчат ваше понимание происходящего.

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

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

Ссылки


Обмен опытом позволяет нам быстрее осваивать различные подходы инструменты, технологии и двигаться вперед. Поэтому не могу обойти стороной наиболее полезные материалы по теме, на которые не было ссылок по ходу статьи:
Spring Boot: Metrics With Micrometer and AWS CloudWatch
Spring Cloud. Using Amazon Web Services. Spring Boot auto-configuration
Spring in Action 5, Craig Walls, Manning
Популярно об Amazon Web Services

Готовый проект можно найти на GitHub.

Автор: Артем Арешко, Lead Java Developer

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    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