Теория тестирования ПО просто и понятно Хабр

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

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

Основные виды тестирования производительности

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

В общих случаях тестирование производительности может служить разным целям. Высокоуровневая проверка функционала всей программы или системы в целом. Несколько лет назад мы в отделе проводили исследование и выяснили, что треть людей приходит к нам из разработки и администрирования, еще треть  из тестирования, а остальные «стартуют» с performance инженерии. Performance engineer постоянно работает с данными, иногда их очень много. Методики сбора и обработки, принципы работы с данными — все это маст хэв. Работа инженера производительности начинается на стадии сбора бизнес-требований.

Стрессовое тестирование (stress testing)

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

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

Регрессионное тестирование (Regression Testing)

О проблемах производительности думали в то время, когда компьютеры только начали появляться. Уже в 1968 году была опубликована классическая статья о влиянии скорости работы компьютерных систем на пользователя –Response time in man-computer conversational transactions Роберта Миллера. Компьютеры с тех пор стали другими, но человек устроен так же, поэтому требования, собранные в этой статье, до сих пор применяются при оценке производительности.

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

Модульное тестирование (unit testing)

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

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

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

Юзабилити тестирование (usability testing)

Нагрузка во время тестов должна базироваться исключительно на основе реального поведения пользователей. Только в таком случае вы сможете получить результат, соответствующий реальной производительности системы. Запуск любых других форм нагрузки – это пустая трата ресурсов и времени. Тестирование масштабируемости (scalability testing)[13] — данное тестирование производится для проверки возможностей масштабирования приложения под любым видом нагрузки. Также необходимо проверять производительность системы во время масштабирования. Работа с дисковой подсистемой может значительно влиять на производительность системы, поэтому сбор статистики по работе с диском может помогать выявлять узкие места в этой области.

Инструменты для тестирования продуктивности

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