Выбрать страницу

Что такое тестирование Shift Left? И что это значит для DevOps?

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

 

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

Модель водопада

Водопад Модель Пол Hoadley. Используется в соответствии с лицензией Creative Commons.

 

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

 

Сдвиг Левое тестирование – Укладка фонда

К счастью, дорогостоящие уроки, извлеченные из предыдущих ошибок в разработке, помогли ввести метод сдвига влево. Организации поняли, что выявление проблем в конце игры было не только слишком дорогостоящим, но и рискованным. В статье TechRepublic от мая 2019 года сообщалось, что среднегодовые затраты на исправление визуальных ошибок в программном обеспечении составляет более $ 400000. Не совсем болван изменения.

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

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

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

 

Подъем сдвига левого тестирования и гибкой и DevOps

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

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

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

 

Типы сдвинутого левого тестирования

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

Традиционное левое тестирование shift

Традиционные Shift Левое тестирование Дон Firesmith. Используется в соответствии с лицензией Creative Commons.

Инкрементное смещение левого тестирования

Инкрементная смена левого тестирования Дон Firesmith. Используется в соответствии с лицензией Creative Commons.

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

Agile/DevOps shift оставили тестирование завершенным в коротких, итеративных спринтах и обычно проводится в тестировании разработки, а не в тестировании разработки. Это происходит после вовсяко-е дело системы.

Гибкое тестирование смены DevOps

Agile / DevOps Shift Левое тестирование Дон Firesmith. Используется в соответствии с лицензией Creative Commons.

Тестирование левой смены на основе модели

Модель на основе Shift Левое тестирование Дон Firesmith. Используется в соответствии с лицензией Creative Commons.

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

В последние годы термин DevOps стал более модным словом для маркетинга, программных продуктов и даже должностных инструкций. Проще говоря, DevOps является альтернативной основой в рамках гибкого подхода, который направлен на создание групп разработки и эксплуатации. Исторически сложилось так, что у каждого департамента были свои, иногда противоречивые, цели. Разработчики создают, проектируют и внедряют инновации. Операционные группы сосредотачиваются на инфраструктуре и «поддержании света» с постоянным мониторингом для обеспечения доступности. Аналогичным образом, DevOps был специально создан для того, чтобы добиться большего сотрудничества, обратной связи и гибкости между этими отделами. DevOps также упоминается, когда речь идет о CI/CD (непрерывная интеграция и непрерывное развертывание) и автоматизации, но тот факт, что организация использует CI/CD и автоматизацию, не делает их автоматически сертифицированными DevOps.

 

Загрузка Тестирование лучших практик для devOps среды

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

Непрерывное тестирование нагрузки.

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

Поделитесь ценными идеями.

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

Мониторинг всех слоев.

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

Базовый и эталонный.

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

 

Интеграция тестирования производительности в методологию shift Left

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

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

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

 

Платформа LoadView: Облачное тестирование нагрузки в реальных браузерах

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

LoadView Shift Левый инфограф

LoadView идеально подходит для раннего тестирования кода или веб-сервисов , чтобы помочь в тестировании характеристик производительности, поскольку он может легко раскручивать и имитировать высокие уровни нагрузки на серверную часть с помощью одного инжектора нагрузки, экономя ваше время и деньги по сравнению с другими инструментами. Это делает его идеальным для тестирования архитектур веб-API, таких как JSON, SOAP и REST. Кроме того, нефункциональные тесты обычно требуют более длительного времени настройки и сложных сценариев, которые требуют от разработчиков и инженеров знания конкретных языков программирования. Иногда это может быть трудно автоматизировать, поскольку они, как правило, работают только в экосистеме, специфичной для поставщиков. Это не так с LoadView.

 

Сценарий Сделано легко: EveryStep веб-рекордер

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

  • Определение базовых показателей времени отклика под конкретными номерами загрузки пользователей
  • Выявление узких мест в производительности
  • Поиск верхних пределов ваших текущих систем планирования емкости
  • Анализ производительности сервера (CPU, память, пропускная способность, диск I/O) и время отклика базы данных

Рекордер также поддерживает более 40 популярных настольных/мобильных браузеров и устройств, а также веб-технологии и языки программирования, такие как AJAX, HTML5, JavaScript, Flash, Silverlight и многое другое. LoadView использует эти скрипты для выполнения тестов по требованию стресса и нагрузки, из 13 “глобальных местах (Соединенные Штаты, Канада, южная Америка, Европа, и APAC), давая тест инженеров реальных данных о производительности от фактических браузеров. Помните, что выполнение внутреннего теста может сказать вам, насколько хорошо ваше приложение или сайт обрабатывает увеличение трафика из вашей собственной сети, но он никогда не будет отражать реальные условия. Приложения и сайты, которые не проверены должным образом и оптимизированы, могут негативно сказаться на конверсиях и, в конечном счете, на доходах.

 

LoadView: Гибкость для тестирования реальных сценариев

LoadView дает пользователям возможность распределять пользовательскую нагрузку между географическими местоположениями в зависимости от процента трафика на ваш сайт. Например, если вы знаете, что определенный процент ваших клиентов и пользователей являются из определенного географического местоположения, вы можете выбрать эти конкретные области для тестирования. Платформа использует Amazon Web Services (AWS) и Azure Cloud Services для создания виртуальных пользователей. Кроме того, пользователи могут еще на один шаг продолжить тестирование нагрузки, настроили тип кривой нагрузки. Это обеспечивает еще большую гибкость для инженеров-испытателей, в зависимости от их уникального сценария. Пользователи LoadView могут выбрать один из трех различных кривых нагрузки:

Кривая шага нагрузки

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

Кривая на основе цели

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

Динамическая регулируемая кривая

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

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

 

После сдвига влево, не забудьте сдвинуть направо

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

Мониторинг веб-служб

    • Время простоя и производительность веб-сервисов, таких как HTTP/S, SOAP/REST и многое другое

Мониторингвеб-страниц

    • Производительность веб-страницы в реальных браузерах, выявляя самые медленные и быстрые элементы с течением времени

Мониторингвеб-приложений

    • Мониторинг сложных веб-приложений, таких как AJAX, PHP, Ruby, Flash и многое другое

Мониторинг инфраструктуры

    • Функциональность и производительность интернет-серверов и протоколов, таких как HTTP/S, электронная почта, потоковое мультимедиа, VoIP и многое другое

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

 

Сдвиг Левое тестирование: Хорошо для бизнеса и мира разума

В заключение я хотел бы сказать, что как сдвиг влево, так и сдвиг правых концепций может быть чрезвычайно ценным не только в рамках цикла разработки программного обеспечения, но и в других департаментах и отраслях промышленности. Например, менеджеры по продуктам или менеджеры по работе с клиентами «смещаются влево» и все чаще работают с реальными клиентами, чтобы получить непрерывную обратную связь. Это позволяет организациям стать более гибкими и стать ближе к источнику информации и обратной связи, чтобы лучше понять своих клиентов. Просто подумай об этом. Не будете ли вы более склонны работать с кем-то, или продолжать делать бизнес с компанией, которая ценит ваш вклад? Итак, теперь, когда вы слышите, как кто-то говорит: “сдвиг влево” или “тест рано и часто”, это не просто модное модное слово, что они бросали вокруг. Это критический кусок клиента опыт головоломки и тот, который вы всегда должны держать в задней части вашего ума. Ваши пользователи и клиенты не только будут счастливы, но и получите эффективность, добьетесь лучших результатов и придасте вам и вашей организации душевное спокойствие.