Каковы распространенные заблуждения при тестировании производительности?
Каковы распространенные заблуждения при тестировании производительности?

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

1. Знать, как использовать инструменты и проводить тестирование производительности.

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

1.1. Некоторые ИТ-менеджеры предприятия (в основном те, кто мало занимается тестированием) считают, что если предприятие самостоятельно разработает или приобретет хорошую инструментальную платформу, то оно сможет решить проблемы качества работы ИТ-системы предприятия.

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

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

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

1) Инструменты и платформы тестирования производительности являются необходимыми базовыми условиями для проведения тестирования производительности.

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

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

2. Настройка — единственное выражение ценности тестирования производительности.

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

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

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

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

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

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

1) Для менеджеров, решать проблемы - это ключ,Одно лишь тестирование производительности не может решить проблему.,Только что нашел проблему.

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

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

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

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

Из всего процесса Тестирование производительностиУмение находить проблемы – это основа,Его важность нельзя игнорировать. Настройка производительности的目的是更好地решать проблемы,Это обеспечивает производительность системы и стабильность производства.

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

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

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

3.1. Аварий на производстве не было, система относительно стабильна, поэтому нет необходимости в тестировании производительности.

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

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

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

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

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

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

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

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

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

1)Меры предосторожности,проходить Тестирование производительность Получите данные о производительности системы и сделайте свою работу хорошо предосторожности Работа。

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

3)Просмотрите позже,Просмотрите позже несчастные случаи на производстве, пройди следующий этап итерационного тестирования, продолжи оптимизацию, Меры предосторожности。

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

A: Сосредоточьтесь только на одном показателе.

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

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

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

C: игнорировать влияние внешних зависимостей.

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

D: Не учитываются реальные сценарии использования.

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

E: Пройдите все тесты одновременно.

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

F: Чрезмерная зависимость от автоматизированных инструментов

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

G: игнорировать управление конфигурацией

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

H: Отсутствие эффективного механизма мониторинга

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

I: Чрезмерное упрощение результатов

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

J: Забыл записать подробные логи

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

boy illustration
Учебное пособие по Jetpack Compose для начинающих, базовые элементы управления и макет
boy illustration
Код js веб-страницы, фон частицы, код спецэффектов
boy illustration
【новый! Суперподробное】Полное руководство по свойствам компонентов Figma.
boy illustration
🎉Обязательно к прочтению новичкам: полное руководство по написанию мини-программ WeChat с использованием программного обеспечения Cursor.
boy illustration
[Забавный проект Docker] VoceChat — еще одно приложение для мгновенного чата (IM)! Может быть встроен в любую веб-страницу!
boy illustration
Как реализовать переход по странице в HTML (html переходит на указанную страницу)
boy illustration
Как решить проблему зависания и низкой скорости при установке зависимостей с помощью npm. Существуют ли доступные источники npm, которые могут решить эту проблему?
boy illustration
Серия From Zero to Fun: Uni-App WeChat Payment Practice WeChat авторизует вход в систему и украшает страницу заказа, создает интерфейс заказа и инициирует запрос заказа
boy illustration
Серия uni-app: uni.navigateЧтобы передать скачок значения
boy illustration
Апплет WeChat настраивает верхнюю панель навигации и адаптируется к различным моделям.
boy illustration
JS-время конвертации
boy illustration
Обеспечьте бесперебойную работу ChromeDriver 125: советы по решению проблемы chromedriver.exe не найдены
boy illustration
Поле комментария, щелчок мышью, специальные эффекты, js-код
boy illustration
Объект массива перемещения объекта JS
boy illustration
Как открыть разрешение на позиционирование апплета WeChat_Как использовать WeChat для определения местонахождения друзей
boy illustration
Я даю вам два набора из 18 простых в использовании фонов холста Power BI, так что вам больше не придется возиться с цветами!
boy illustration
Получить текущее время в js_Как динамически отображать дату и время в js
boy illustration
Вам необходимо изучить сочетания клавиш vsCode для форматирования и организации кода, чтобы вам больше не приходилось настраивать формат вручную.
boy illustration
У ChatGPT большое обновление. Всего за 45 минут пресс-конференция показывает, что OpenAI сделал еще один шаг вперед.
boy illustration
Copilot облачной разработки — упрощение разработки
boy illustration
Микросборка xChatGPT с низким кодом, создание апплета чат-бота с искусственным интеллектом за пять шагов
boy illustration
CUDA Out of Memory: идеальное решение проблемы нехватки памяти CUDA
boy illustration
Анализ кластеризации отдельных ячеек, который должен освоить каждый&MarkerгенетическийВизуализация
boy illustration
vLLM: мощный инструмент для ускорения вывода ИИ
boy illustration
CodeGeeX: мощный инструмент генерации кода искусственного интеллекта, который можно использовать бесплатно в дополнение к второму пилоту.
boy illustration
Машинное обучение Реальный бой LightGBM + настройка параметров случайного поиска: точность 96,67%
boy illustration
Бесшовная интеграция, мгновенный интеллект [1]: платформа больших моделей Dify-LLM, интеграция без кодирования и встраивание в сторонние системы, более 42 тысяч звезд, чтобы стать свидетелями эксклюзивных интеллектуальных решений.
boy illustration
LM Studio для создания локальных больших моделей
boy illustration
Как определить количество слоев и нейронов скрытых слоев нейронной сети?
boy illustration
[Отслеживание целей] Подробное объяснение ByteTrack и детали кода