Стратегии архитектуры для тестирования

Применяется к этой контрольной рекомендации по операционному превосходству в Azure Well-Architected Framework:

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

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

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

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

Рекомендации по внедрению методик тестирования см. в статье-компаньоне: создание доверия к рабочим нагрузкам Azure с помощью эффективных методик тестирования.

Формализация стратегии тестирования и плана

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

Определение стратегии тестирования

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

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

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

Замечание

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

Создание плана

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

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

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

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

Тестовый план выпуска фокусируется на добавлении поддержки Apple Pay. Он определяет именно то, что нужно протестировать для Apple Pay в этом выпуске, выделяет ресурсы (два инженера и три устройства iOS), устанавливает четырехнедельное расписание и устанавливает четкие условия входа (код завершен и среда настроены) и условия выхода (все тесты проходят и не имеют критических ошибок).

Замечание

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

Тестирование ранних версий, частое тестирование, проверка того, что имеет значение

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

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

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

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

Замечание

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

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

Тестирование в рабочей среде с помощью гарантий

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

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

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

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

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

Применение многоуровневого подхода в тестовом охвате

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

Использование тестовой пирамиды в качестве руководства

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

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

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

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

Замечание

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

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

Отдельное тестирование приложений и инфраструктуры

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

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

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

Включение различных типов тестирования

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

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

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

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

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

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

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

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

Рассматривать тестовые ресурсы так же важно, как ресурсы кода

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

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

Структура и защита тестов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обслуживание и развитие тестов

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

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

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

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

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

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

Управление тестовой технической задолженностью

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

  • Приоритет исправления или удаления ненадежных тестов для поддержания целостности набора тестов. Меньший набор надежных тестов является более ценным, чем большой набор ненадежных тестов.

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

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

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

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

Расширение наблюдаемости в тестовой платформе

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

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

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

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

Используйте отраслевые стандартные инструменты покрытия и отчетности в рамках своего фреймворка:

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

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

Имитация реалистичных условий

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

Стратегическое расширение покрытия

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

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

Согласование с бизнес-целями и целями уровня обслуживания

Выровняйте тесты как с бизнес-целями, так и с целями уровня обслуживания (SLOS).

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

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

Использование репрезентативных тестовых данных

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

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

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

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

Имитация рабочей среды

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

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

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

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

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

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

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

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

Создание целенаправленных тестовых сред

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

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

Использование макетных служб

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

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

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

Упрощение функций Azure

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

Azure Pipelines позволяет интегрировать тестирование в конвейер CI/CD. Вы также можете использовать GitHub Actions , интегрированные с Azure.

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

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

Azure также предоставляет средства на основе платформы, поддерживающие надежность, производительность и тестирование безопасности.

Контрольный список операционной эффективности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список операционной эффективности

  • Последнее обновление: