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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример: Для системы оформления заказа в электронной коммерции стратегия тестирования устанавливает согласованный подход ко всем релизам. Он определяет, что потоки платежей всегда задаются приоритетами, указывают средства тестирования для системы, например Selenium для тестирования пользовательского интерфейса, JMeter для нагрузочного тестирования и OWASP ZAP для тестирования безопасности, а также определяет обязанности группы по различным типам тестов. Тестовый план для выпуска версии 2.5 посвящен добавлению поддержки Apple Pay. Он определяет именно то, что нужно протестировать для Apple Pay в этом выпуске, выделяет ресурсы (два инженера и три устройства iOS), задает четырехнедельное расписание и устанавливает четкие условия входа (код завершен и настроена среда) и условия выхода (все тесты проходят, ноль критически важных ошибок и двухсекундное соглашение об уровне обслуживания).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связанные ссылки

• Рекомендации по тестированию производительности
• Рекомендации по тестированию надежности
• Рекомендации по тестированию безопасности

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

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